文章探讨从简单Agent Loop到复杂后端架构的演进提出Agent需要“新后端”来连接真实业务系统如浏览器、沙箱。介绍了Worker、Function、Trigger概念强调运行时能力发现和统一Trace的重要性旨在构建可发现、可恢复、可追踪的Agent工程体系。模型看任务选择工具程序执行工具把结果写回上下文再进入下一轮。几十行代码就能跑起来。Demo 通了以后确实挺有成就感。但写完以后我一直觉得还有一块没讲透这个 loop 真的进了业务系统外面那层后端应该怎么配合它工具从哪里来浏览器、沙箱、Python 服务、Rust 服务、队列、状态、HTTP 入口怎么放在同一条调用链里Agent 临时需要一个新能力能不能动态拉起一个 worker用完再退出出了问题以后能不能沿着同一条 trace 看清楚模型、工具、队列、状态和服务之间发生了什么这次我想顺着这个问题再往后端方向推一层。这条线其实是接着前面几个文章往下走。前面我们聊过 Harness 的 6 个关键模块也拆过 Claude Code 长任务 runtime、上下文工作集、Subagents。那些文章看的是同一件事的不同侧面模型外面那层系统正在变得越来越重要。最小 loop 让 Agent 动起来。Harness 让它能被约束、能恢复、能验证。再往后看就会遇到今天这个问题Harness 里那些承重的东西最后会不会沉到后端里带着这个问题读 Mike Piccolo 在 Heavybit 的文章再看配套的开源运行时线索会变得具体很多browser、sandbox、不同语言 worker可以通过同一套连接方式进入系统。顺着这条线看问题会自然落到后端架构能力如何出现、如何下线、如何被追踪。可以先看看这个图。iii配图左边是很多 worker 之间互相连右边是共享运行时和实时能力发现。这张图把问题从连线数量带到了能力如何被发现和管理。它背后是一个更贴近日常工程的问题Agent 后端只靠一份静态工具列表会越来越吃力。它需要一套能反映当前系统状态的运行时能力目录。先把我的理解放前面30 分钟手搓 Agent看到的是 loop模型、工具、观察、下一轮。后来聊 Harness看到的是 loop 外面那层工程系统上下文、工具、状态、权限、恢复和验证。再看长任务 runtime、上下文工作集和 Subagents会发现很多边界已经不适合只放在对话窗口里。这篇继续往后一层当 Agent 真要接业务系统Harness 会开始承担后端职责。原文里讲的Worker / Function / Trigger我更愿意翻译成三个朴素的工程词参与者、能力、入口。参与者可以是 Agent、浏览器、沙箱、队列、Python 服务、Rust 服务能力是它能做什么入口是它什么时候被调用。代码层面我更想看 worker 连接、注册、重连、清理、trace 传播这些生命周期细节API 名字反倒是次要的。如果把这套思路借到我们自己的系统里我会先看四件事能力目录、生命周期管理、触发入口、统一 trace。边界也要提前摆出来中心 engine 可用性、能力目录治理、动态 worker 安全、上下文工程和不同 trigger 的失败语义都不能靠一句“统一抽象”带过去。30 分钟 loop 只看到一半我们之前手搓 Agent 时主循环大概是这样async function runAgent(task: string) { const messages [{ role: user, content: task }]; for (let step 0; step 8; step) { const response await model.create({ messages, tools }); if (!response.toolCall) { return response.text; } const observation await runTool(response.toolCall); messages.push({ role: tool, content: observation }); } return Stopped: step limit reached.; }这段代码很小但能帮我们看见 Agent 的骨架。模型不会自己读文件、跑命令、搜网页。模型只是在上下文里表达“我下一步想调用什么工具”。实际执行工具、校验参数、裁剪输出、记录日志、限制权限、处理失败的是模型外面的运行系统。当时的demo里我故意把工具收得很窄只留list_files、read_file、run_command这一类动作。这么收窄工具是想让边界露出来模型的能力要跟验证、回滚、权限一起长。否则工具越多系统越像把一堆开关递给模型。所以那篇文章最后落在一句话最小循环让 Agent 动起来Harness 关系到它能不能长期稳定地干活。但这个说法还有半句没展开。Harness 如果只在 Agent 进程里做很快会遇到后端问题。比如一个 Coding Agent 先读仓库再开浏览器查文档再进沙箱跑测试再调用一个 Python 分析服务最后把结果写进状态存储。这些动作如果各走各的 SDK、各写各的日志、各管各的重试Agent loop 本身写得再漂亮排查起来也会很费劲。iii.dev 有一个很粗糙但好用的提醒agents^2 * services。1 个 Agent 接 5 个后端系统还只是 5 条路径。4 个 Agent 接 5 个后端系统组合路径就会变成 80 条。这个公式不必当数学定律看。它更像是在提醒我们过去后端的复杂性大多来自确定的服务边界Agent 进来以后复杂性会多一层运行时组合。问题会从“Agent 能不能调用工具”走向“后端能不能让这些工具以一种可发现、可恢复、可追踪的方式参与进来”。这也是我理解“新后端”的起点。这里说的新后端传统后端那些东西还在HTTP、队列、数据库、权限、日志都还在。变化在于后端要多接住一类新调用方会探索、会组合、会长时间执行、也会带来更多不确定性的 Agent。把后端重新翻译成三个词原文和项目文档都反复讲三个词原文里的词我自己的理解放到 Agent 系统里怎么看Worker参与者能连接到运行时、注册能力的进程Function能力一个有稳定 ID 的工作单元Trigger入口什么事情会触发这个能力运行这三个词本身不复杂。但它们把很多原来分散的东西放到了一张图里。TypeScript API 服务是参与者。Python 数据处理脚本是参与者。Rust 微服务是参与者。浏览器 tab 可以是参与者。沙箱可以是参与者。Agent 也可以是参与者。它们不需要在概念上分成“后端服务”“工具”“队列消费者”“Agent 框架”“沙箱产品”好几类。只要能连接到运行时注册自己能做什么就可以进入同一套系统。读到这里我的关注点就从项目本身转到了后端。它先把问题放回后端后端能不能把所有参与者、能力和入口放到同一张运行时目录里。代码里能看到这个方向SDK 的最小用法很直接import { registerWorker } from iii-sdk; const runtime registerWorker(ws://localhost:49134); runtime.registerFunction(hello::greet, async (input) { return { message: hello ${input.name} }; }); runtime.registerTrigger({ type: http, function_id: hello::greet, config: { api_path: /greet, http_method: POST }, }); const result await runtime.trigger({ function_id: hello::greet, payload: { name: world }, });如果只看代码表面它像是在注册一个远程函数。放到架构里看它在做三件事当前进程先登记成一个 worker这个 worker 暴露hello::greet这个能力这个能力既能被 HTTP 触发也能被另一个 worker 通过 function ID 调用。换到 Agent 里工具就从一段 prompt 说明变成运行时里注册出来的能力。官方 AGENTS 文档里有一句话讲得很直An agent is a worker. Its tools are functions. Its memory is state. Its orchestration is triggers.这句话放到工程里可以拆成这样Agent 本身也是后端系统里的一个参与者它用到的工具不一定都在自己进程里它的记忆可以落到状态层它的编排不一定只靠一个for循环也可以被 HTTP、队列、cron、状态变化这些入口触发。这和 30 分钟手搓版的差别很明显。最小 loop 里工具通常是这样const tools [ readFile, listFiles, runCommand, ];这对教学很好。但真实长任务里Agent 不一定在启动时就知道自己会用到哪些能力。今天可能需要浏览器明天需要沙箱后天需要临时拉起一个 Python worker 做数据清洗。所以我觉得Agent 后端第一步要补一份可靠的能力目录再去谈更复杂的 prompt。运行时目录和工具列表不是一回事官方 discovery 文档里有一个细节很关键worker 连接时engine 把它的 functions 和 triggers 加进 live registry。worker 断开或注销 function 时registry 立刻变化。同一个 registry 支持两类动作查询当前系统里有哪些 worker、functions、triggers订阅能力变化比如有新 functions 出现或旧 worker 下线。这和我们熟悉的服务发现有点像但对 Agent 来说更具体。服务发现告诉程序“服务在哪里”。运行时能力目录告诉 Agent“此刻系统实际能做什么”。这两句话差别挺大。如果 Agent 拿的是一份启动时写死的工具菜单它看到的是“理论上可用的工具”。如果它查的是运行时目录它看到的更接近“现在活着、能被调用、能被追踪的能力”。我按自己的理解画了一张小图放在这里更容易对齐上下文。从工具列表到运行时能力目录MCP 可以放在旁边一起看。MCP 已经解决了很大一块问题它降低了 Agent 连接外部工具的成本。之前聊 [MCP]和 [Skills] 时我更关心的是“经验和工具怎么被模型稳定复用”。到了这里问题又往下走了一层工具背后的进程是不是在线版本是不是对权限是不是允许调用结果能不能回到同一条链路。运行时目录继续往后看一层工具背后的 worker 是不是活着function 能不能被发现trigger 谁来送达调用和结果能不能进同一条 trace。两者可以同时存在关注点不同。我想借鉴的是四个设计动作如果今天要给一个内部 Agent 系统做第一版架构开源实现只能做参照方案还得回到自己的系统边界。看完原文和代码后有四个动作我会认真借鉴。第一把工具从“函数数组”升级成“能力目录”。工具要有 ID、描述、输入输出 schema、owner、版本、权限和观测信息。这个目录可以先很简单甚至就是一个数据库表或配置文件。重要的是团队先把这件事想清楚工具不是 prompt 里的文字说明它是系统可治理的运行时能力。第二把 worker 上下线当成正常路径。Agent 系统里worker 断开、重启、超时、重复注册、半失败都会很常见。代码里有两个细节值得记一下SDK 断线重连后会重新发送 function 和 trigger 注册engine 里维护了function_owners和external_function_owners处理旧 worker 清理和新 worker 注册之间的竞态。它听起来不炫但很接近生产问题。第三把视角从“Agent 主动调用工具”扩到业务事件触发。Agent 也可能被 HTTP 触发被 cron 触发被队列触发被状态变化触发。比如线上告警进入pending状态触发agents::incident_triage每晚 cron 触发agents::release_notes用户上传文件后队列触发agents::document_reader审批通过后状态变化触发sandbox::execute_plan。当 Agent 既能主动调用别人也能被业务事件触发它就开始进入后端执行模型。第四trace 要从协议层开始设计。在engine/src/protocol.rs里InvokeFunction和InvocationResult都携带traceparent和baggage。这类字段平时不显眼排障时会很有用。Agent 的执行路径常常会跨语言、跨进程、跨队列、跨工具。没有统一 trace最后只能靠“把所有日志 grep 一遍”来猜。如果一个浏览器 worker 连上来browser::navigate、browser::screenshot变成可调用能力一个 sandbox worker 连上来sandbox::run变成可调用能力一个 Python worker 连上来analysis::summarize_csv变成可调用能力。这些能力可以来自不同语言、不同进程、不同生命周期。它们能落在同一条调用链里排障会轻松很多。边界也要提前想从工程落地看至少有几个边界要提前想。第一中心 engine 的可用性。当 routing、registry、trigger、observability 都向同一个运行时收拢这个运行时自己就变成承重点。部署、水平扩展、状态后端、备份恢复都需要提前有方案。第二统一原语不等于统一语义。HTTP、队列、cron、状态变化都可以被建模成 trigger但它们的失败语义不一样。HTTP 关心延迟和响应队列关心重复消费和死信cron 关心锁和错过执行窗口。抽象能减少需要理解的东西但替不了这些工程事实。第三能力目录会膨胀。如果每个 worker 都随意注册 functionAgent 看到的目录会越来越乱。命名规范、版本策略、owner、权限、废弃流程都要跟上。第四动态创建 worker 很强也很危险。Agent 拉起 sandbox、浏览器、临时服务这件事很诱人。但只要涉及执行代码、访问网络、读取文件、调用内部 API就要有 RBAC、沙箱隔离、资源配额和审计。第五许可证和生态边界也要看清。当前 engine 是 Elastic License 2.0SDK 是 Apache 2.0。内部研究、验证思路、学习架构都没问题商业化二开和分发要单独看许可证条款。第六上下文工程不会自动消失。运行时目录能告诉 Agent 系统里有哪些能力不能替它决定当前任务该看哪段上下文。我们前面讲上下文更像工作集讲 Subagents 隔离探索过程底下都连着这个问题。能力接进来了只是第一步。下一步仍然要设计哪些事实进入窗口哪些状态留在 session 外哪些探索过程交给独立工作区哪些结果需要回到主线。再回到 30 分钟手搓 Agent现在再看我们之前的 30 分钟手搓 Agent我会把它放在更清楚的位置上。它解决的是第一层问题让 Agent 的 loop 跑起来。后面聊 Harness、长任务 runtime、上下文工作集和 Subagents是第二层问题让这个 loop 在真实任务里跑得稳一点。这次代码和访谈提醒我的是第三层问题这个 loop 怎么进入一个真实后端系统和浏览器、沙箱、状态、队列、不同语言服务一起工作。一个很小的 Agent loop配上一组受控工具可以让我们看清 Agent 怎么行动。再往前走一步工具、状态、触发、worker、trace、权限就很难一直散在 loop 外面。它们会慢慢变成后端设计的一部分。这就是我理解的“Harness 成为新后端”。如果把它放回日常工程里看后端要开始给 Agent 提供可发现的能力、可恢复的状态、可审计的权限、可追踪的链路以及能随运行时变化的工具目录。所以下次再做 Agent 系统时我可能会先把框架选择放一放。我会先问自己一句我们的后端离一个 Agent 能理解、能参与、能恢复、能追踪的系统还有哪些缺口这个问题我会继续盯着。它不一定给出最后答案但能让我们更早看到后端边界正在怎么变。大模型的知识又多又杂到底怎么学做这行久了被问最多的问题就一个大模型的知识又多又杂我到底先学啥翻了一堆资料看啥都像重点结果啥都没学进去。今天把我自己一路摸出来的顺序捋一遍零基础、应届生、转行的都适用。跟着走至少方向不乱、不瞎忙学完拿得出手。第一阶段10天初阶应用这一阶段就一个目标把大模型真正玩明白不是只会聊天那种而是能调教它、能用代码把大模型和业务接起来。大模型 AI 能干什么大模型是怎样获得「智能」的用好 AI 的核心心法大模型应用业务架构大模型应用技术架构代码示例向 GPT-3.5 灌入新知识提示工程的意义和核心思想Prompt 典型构成指令调优方法论思维链和思维树Prompt 攻击和防范…第二阶段30天高阶应用这阶段正式进实战目标很实在做出两个能拿出手的东西——一个私有知识库一个 agent 对话机器人。为什么要做 RAG搭建一个简单的 ChatPDF检索的基础概念什么是向量表示Embeddings向量数据库与向量检索基于向量检索的 RAG搭建 RAG 系统的扩展知识混合检索与 RAG-Fusion 简介向量模型本地部署…走完这 30 天Python 或 JavaScript 背景的基本能独立做一套 RAG 应用简历上也敢写大模型应用开发了。第三阶段约20天动手微调学到这你已经开始 “造” 模型了 —— 通过微调搞出垂直领域的专用小模型。为什么要做 RAG什么是模型什么是模型训练求解器 损失函数简介小实验2手写一个简单的神经网络并训练它什么是训练/预训练/微调/轻量化微调Transformer结构简介轻量化微调实验数据集的构建…恭喜你如果学到这里你基本可以找到一份大模型 AI相关的工作自己也能训练 GPT 了通过微调训练自己的垂直大模型能独立训练开源多模态大模型掌握更多技术方案。到此为止大概2个月的时间。你从 “只会用” 变成 “能造” 的 AI 小子。那么你还想往下探索吗想要入局AI大模型赛道、抢占行业红利的朋友微信扫描下方CSDN官方认证二维码即可100%免费领取全套学习资料第四阶段20天商业闭环部署落地技术学完落地才算数。这阶段带你搞明白大模型怎么真正跑起来、用起来。硬件选型带你了解全球大模型使用国产大模型服务搭建 OpenAI 代理热身基于阿里云 PAI 部署 Stable Diffusion在本地计算机运行大模型大模型的私有化部署基于 vLLM 部署大模型案例如何优雅地在阿里云私有部署开源大模型部署一套开源 LLM 项目内容安全互联网信息服务算法备案…想要入坑大模型的朋友给大家准备了一份2026 年最新 AI 大模型全套学习资料1、大模型系统化学习路线2、大模型学习视频教程3、大模型学习书籍电子文档4、AI大模型最新行业报告5、大模型项目实战配套源码6、2026大模型大厂面试真题7、为什么要学习大模型我国在A大模型领域面临人才短缺,数量与质量均落后于发达国家。2023年人才缺口已超百万凸显培养不足。随着AI技术飞速发展预计到2025年,这一缺口将急剧扩大至400万,严重制约我国AI产业的创新步伐。加强人才培养,优化教育体系,国际合作并进是破解困局、推动AI发展的关键。8、适合谁学传统后端 / Java / 前端开发想转型 AI 应用大学生、应届生想拿更好的 offer产品经理、运营想武装职业竞争力技术负责人想给团队落地提效学习是反人性的但回报是真金白银。技术会更新赛道会切换但只要你先动手机会就永远站在你这边。9、这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。想要入局AI大模型赛道、抢占行业红利的朋友微信扫描下方CSDN官方认证二维码即可100%免费领取全套学习资料好了就写到这。路线是死的人是活的卡住了随时来问我。觉得有用就点个收藏别让它进收藏夹吃灰——动起来比啥都强。