跳到主要内容

从语言到行动 — 智能体如何进入闭环

这一章讲三件事: 「让机器代人做事」是个老梦想,为什么直到最近几年才第一次真的跑起来; 一个会行动的系统要满足哪些看起来琐碎、实则致命的设计条件——任务怎么定义、什么时候该停下来问人、失败长什么样; 以及同一个模型装进不同外壳为什么表现差出一个数量级——决定成败的那一层叫驾驶舱。

它在全书链条里的位置:前十章都在回答「模型会什么」,从这一章起换问题——怎么把模型组织成一个真正完成任务的系统。 第 07 章的推理模型会在「思考」这一步作为可选档位再次出现;工具与环境的细节留给第 12 章, 记忆、计划与多角色协作留给第 13 章,训练与评测的完整展开在第 14 章。

顶层全景:一个闭环和它的三层护栏​

        ┌────────────────────────────────────────┐
        │   观察(env)→ 思考(LLM)→ 行动(action)→ 反馈(state)   §3
        └───────▲────────────────────────────────┘
                │ 反馈重新进入下一轮
   任务护栏 §5–§7: 任务/环境/状态定义清楚 · 部分可观测留确认预算 ·
                  自主性分层 + 可逆优先 + 写死的退出条件
   过程护栏 §8–§9: 时间成本工具都要过预算 · 失败分四类 · 伪成功靠验证点拦
   工程护栏 §10–§11: 驾驶舱六件事(循环/调度/上下文/安全/记忆/日志)
                  + 技能层(把一类任务的套路沉淀下来)

图说: 这一章的所有名词都挂在同一条闭环上。四步循环是发动机; 三层护栏是底盘——没有护栏的闭环不是智能体,是一台会翻车的敞篷车。

1. 为什么现在才成​

「让机器代人完成任务」并不新鲜,新鲜的是三个关键条件第一次同时具备1:

  1. 基础大模型足够强了——能在开放环境里读懂指令、归纳状态、生成中间计划;
  2. 外部世界第一次大规模「接口化」——网页、API(别的系统留给外人调用的门口)、文档、软件界面都成了可以被访问的对象;
  3. 推断成本降到足以支撑频繁试错(这笔账正是第 10 章算的),工具生态也成熟了。

少任何一条,智能体都只能停在概念上。书里还有一段很清醒的话:以前的自动化系统 (规则系统、流程引擎)不是不想做这件事,而是它们的套路是「写死规则」——环境一复杂就得写出大量分支规则; 大模型的价值恰恰是把「写死规则」替换成「在更开放的状态空间里做近似判断」, 原来只有人能接住的灰色地带,变成了模型和系统能共同处理的区域2。

但书里同时按住了过度乐观:我们正处在能力阈值刚刚被跨过的阶段——闭环能跑起来, 而脆弱性、评测困难和治理难题都非常明显;今天的智能体是被这个时间点「凑齐」出来的, 不是已经成熟了的产物3。

2. 工作流与智能体的分水岭​

今天很多系统都带点「智能体味」,但不是每个自动化流程都配这个名字。最容易混淆的是工作流 (workflow):预先定义好步骤的流程——先检索、再总结、再生成邮件、再发审批, 每一步做什么、先后顺序怎样,大多由人提前写死,模型只是其中某个环节的执行器4。

智能体的差别不在「有没有用模型」,而在一处:下一步做什么由谁挑。 智能体要根据环境变化做条件性决策——浏览网页发现页面结构和预期不同, 它得自己决定是重新搜索、换关键词、点别的入口,还是退一步重新规划。 书里管这叫「边看边改」,并把这条定为智能体和工作流的分水岭5。

实战中最稳的姿态是两者的组合而非二选一:用工作流包住智能体—— 高风险强约束的部分做成明确流程,需要局部适应和探索的部分才交给智能体; 结构化约束本身就是可靠性的来源,不是所有问题都值得扔给开放式决策6。

3. 闭环的四步​

理解智能体最方便的方式,是把它看成一个循环:

  • 观察:接收环境状态——可能是一段用户指令、一页网页、一个终端输出、一张截图或某个工具返回的结果;
  • 思考:基于目标和已有状态,决定下一步做什么;
  • 行动:调用工具、点击按钮、发起搜索、修改文件、提交表单;
  • 反馈:重新读取行动后的结果,判断动作是否有效,再进入下一轮7。

这个循环和纯对话的本质差别在于错误的形态。纯对话错一次,顶多那句话不好看; 闭环里的错误会被放大:一次误读页面、一次错误点击、一次不必要的工具调用,都可能在后续回合中被滚大8。 由此推出本章最重要的判断之一:决定智能体能力的,除了推理强不强,更在于闭环能否稳定—— 一个很会解释问题的模型未必是好的智能体;有些系统开放问答不惊艳, 却因为观察-行动-反馈这条链设计得稳,在真实任务里反而可靠9。

顺带纠正一个流行误解:智能体不是「更会思维链的大模型」。 复杂任务确实需要中间决策,但真正把系统推到另一个层级的, 是在外部环境中持续纠偏的能力;决定成败的是观察粒度够不够、动作接口稳不稳、反馈能不能验证, 而不是推理文字有多长10。至于「思考」这一步要不要花得更深,那是可选档位: 同一个闭环里,可以把普通模型换成推理模型来执行思考步,代价和收益见第 07 章。

4. 三种代表范式​

抽象闭环在研究上有几条具体实现路径,记住三个名字就够了11:

范式一句话它省的是什么
ReAct(2022)想一步、做一步、看反馈再调整;推理痕迹和动作交替出现在同一串生成里最贴近闭环原始定义
ReWOO(2023)先一次性写出整套计划(列出要调的工具和变量),再分别执行,最后合成答案ReAct 每步把全部上下文塞回模型的词元成本;工具失败时也更容易换路重试
CodeAct(2024)把动作统一为可执行的 Python 代码JSON(一种固定的结构化文本格式)参数表达不了的多工具组合、中间变量保留、动态修改方案

三者不是互相替代关系:ReAct 强调推理与行动交替,ReWOO 强调规划与观察解耦, CodeAct 强调用代码承载行动——今天的产品里常常同时能看到三者的影子12。 CodeAct 那条线还顺手回答了一个时代问题:为什么 2025 年之后编程智能体格外重要—— 代码既是被处理的对象,也渐渐变成智能体行动的通用中介13。

5. 把任务定义清楚​

闭环搭好之后,决定它能认真做事的是最不起眼的一层:任务、环境、状态这三个词各自指什么14。

  • 任务规定了目标:「订一张机票」「把周报整理成幻灯片」「修好这个报错并提交补丁」;
  • 环境规定可观察对象和可执行动作:浏览器页面、操作系统、代码仓库、数据库或企业内部系统;
  • 状态记录当前发生了什么、还剩什么没做、哪些信息拿到了、哪些还不确定。

三者看似平淡,却决定了设计边界:任务含糊,中途必偏航;环境接口不清,模型不知道什么动作可信; 状态管理混乱,系统就会忘记自己做过什么、在长任务里反复试错。 书里有句判词值得贴在每个失败项目的事后复盘上:很多所谓「智能体不稳定」,根子往往在任务定义、 环境接口和状态表示没有被设计清楚,而未必是模型本身不够聪明15。

环境还直接决定动作空间的好坏:设计得好,模型清楚地知道每个动作的前置条件、副作用和失败时能否重试; 设计得差,模型就在模糊按钮和不可预测的反馈之间瞎摸16。(这个主题第 12 章会展开成整整一章。)

另一手准备是把关键状态显式外置:当前计划步骤、已调用的工具列表、关键中间结果、失败次数, 都存成结构化的对象,而不是全靠模型在上下文里「自己记着」——既方便调试,也减少脆弱性17。 记忆怎么分层外置,第 13 章 §2 讲。

6. 部分可观测与确认成本​

真实世界不会把自己全部摊开给你看:网页有折叠区域和异步(不阻塞、慢慢加载)的部分,操作系统有前台后台之分, 企业流程里还有大量只写在制度和惯例里的隐含约束。智能体看到的永远只是世界的一部分—— 这叫部分可观测(partially observable)问题18。

它的直接后果是状态歧义:按钮为什么是灰的?可能是权限不足,也可能是网络没响应; 一条报错可能指向参数写错,也可能说明依赖服务挂了;检索到的一条说法可能是现行规则,也可能只是过期页面19。 书里指出一个非常常见的死因:把模糊信号过早压成确定结论,后续步骤不断放大误判—— 不少智能体败在太早把不确定的世界当成确定的状态,而不是某一步「想错了」20。

对策朴素得可爱:为「确认」本身留预算。拿不准就补一次观测、做个二次验证、换一个信息源, 或者干脆把当前判断标为「待确认」,而不是当成既定事实往下走;给关键信号设置信度门槛, 宁可慢一点,换更低的状态污染概率21。观察能力因此有两半: 一是能看到多少,二是能识别出自己其实还没看清楚22。

7. 什么时候该停下来问人​

一旦系统代你做事,就有三件纠缠在一起的事必须答清楚:它能替你做到什么程度、以谁的名义在做、做错了怎么收手23。

自主性不是开关,是分层。 从几乎完全由人主导、模型只给建议; 到能在明确约束下自动完成一小段流程;再到长时间独立推进复杂任务——层级越高,省下的人工越多, 小错误滚成大问题的风险也越大24。实践中的分界线朴素的出奇: 可回滚、有自动校验的动作放手交给模型;支付、删除、对外发布这类不可逆的高风险动作,保留一道人工确认——自主层级就卡在这条线上25。

授权是一组逐层展开的委托关系,不是一个开关。 读、写、支付、对外发消息、继续委托给别人, 最好分开声明;成熟系统把授权做成可检查、可撤销、可降级的状态,而不是一句含糊的「你去帮我办吧」26。

退出机制和授权一样重要。 没有退出机制的智能体,会在不确定状态下继续行动, 把局部可控的问题推向更大后果。书里给的硬条件示范非常具体,可以直接抄进需求文档27:

  • 连续两次工具调用失败 → 暂停;
  • 预算耗去八成 → 回到人工;
  • 遇到授权清单之外的动作 → 立刻交还控制权。

最后是这个领域最漂亮的工程判断之一:动作分两类,信息不足时优先做可逆的那类。 补充检索、读取状态、生成候选、沙箱(与真实系统隔离开的试验环境)里试跑,几乎没有外部副作用; 覆盖文件、发送邮件、提交订单则会直接改变外部世界。不确定性高的时候先做前者, 把后者推迟到证据和目标都更清晰之后——这不是保守,是提高总成功率的算术: 越早进入不可逆状态,后面每一步修正的代价越高28。

8. 预算:每一次重试都在花钱​

纯问答里「多想几步」只是多生成一些文本;智能体里「再试一次」意味着重新占用资源、 重新等待反馈,甚至再次暴露于副作用风险29。时间、成本、工具调用次数,全是有限资源, 成熟的智能体会按任务价值和剩余预算决定行动强度: 低价值低风险的任务也许只值一次检索加一次执行;高价值高风险的任务,反而应该在预算尚充足时先花成本澄清和比较候选30。

工具预算还藏着第二层账:不同工具的代价结构完全不同——有的烧词元,有的烧外部 API 费, 有的烧人工审批时间和下游调用额度。区分不出这些代价的系统,会在「工具很多」的表象下粗放行动。 稳妥的做法是显式分组:哪些适合频繁探索,哪些只在证据充分时触发,哪些一碰就要进严格的审计确认流程31。 工具使用的问法就此升级:从「会不会调」变成「值不值得在这个时刻调、调完之后代价由谁承担」32。

预算意识因此成了成熟度的标志:记不记得已消耗的重试次数、知不知道剩余的上下文余量、 会不会在长任务中主动压缩状态、能否在成本异常时自动降级或暂停——这些决定了它像谨慎的执行者, 还是不断扩张开销的失控流程33。

9. 失败的样子​

看懂一个智能体,要看它通常怎么失败。书里给出四类34:

类别长什么样后果
观察错误读错页面、误解终端输出、把局部信息当全局事实后续推理再精巧也是在错误前提上盖楼
计划错误目标拆解不合理、优先级失真、该验证的信息被当成前提方向错了,执行力越强偏得越远
行动错误参数填错、点到相似的错误按钮、草稿当成正式提交、覆盖不该动的文件有累积性和外部后果:一次小错污染环境,后续所有步骤都建立在被污染的地基上

第四类最阴险:伪成功。流程完整、解释充分、日志漂亮,但实际上并没有完成任务—— 只是一套非常像成功的叙述。它在智能体场景比对话场景危险得多,因为系统会自动结束流程、自动汇报, 人类很容易把「看起来做完了」误当「真的做完了」35。 所以智能体系统几乎都需要三样东西兜底:显式验证点、可检查的完成条件、必要的人工抽检36。

由此引出一个价值观层面的分野:系统到底在追求「看起来很会」,还是追求「做完之后可以被验证」? 书里的答案是后者的全面胜利——接工具、接环境、接状态层,就是把「会说」转化成「可验证的推进」: 搜了什么看日志,改了什么看 diff,提没提交看页面状态,测试过没过看返回结果37。 没有这些外部锚点,偶尔成功也无法积累成稳定系统;有了锚点,模糊的「能力问题」就能转化成工程问题、 评测问题和治理问题。评测也跟着变:五步做完和绕二十步、错三次最后改对,答案一样, 过程稳定性天差地别——所以近年的评测基准(SWE-bench 修真实仓库 bug、GAIA 考通用助手、 WebArena 考网页操作等)共同转向了评整条轨迹,而不只是最终答案38。这套评测体系的全貌在第 14 章展开。

10. 驾驶舱:决定成败的那层外壳​

一个光秃秃的模型只是个能响应输入的大脑:不会主动做事、不会循环、不会记忆、不会处理错误。 让它成为能干活的智能体的,是一层业界称为驾驶舱(Harness)的工程外壳—— 词源就是马具:把野马套上缰绳才能拉车39。典型驾驶舱至少干六件事40:

组件干什么
循环控制不停地问模型「下一步做什么」,执行,把结果喂回去,直到完成——闭环的实际执行者
工具调度把模型嘴里的 search(...) 解析成真正的函数调用(让程序真去执行那个函数),处理返回值、错误、超时
上下文管理决定每一步给模型看什么,哪些历史保留、哪些压缩丢弃
安全检查拦截删文件、发邮件、下单这类操作并要求确认;过滤外部内容里的注入企图
记忆管理分拣什么沉淀为长期记忆,什么用完即弃
日志与回放记录每一步决策与结果,出错可复盘,也是训练数据的来源

驾驶舱是工程,不是算法,但它决定同一个引擎跑出来的是跑车、货车还是扫地车。 近年反复被观察到的一个现象,值得当作行业共识收下:同一组权重不变,仅把驾驶舱的结构、 反馈方式或工具组织重新打磨一遍,整体可靠性就可能拉开明显差距—— 智能体能力的提升空间,相当一部分不在模型,而在驾驶舱这一层41。 而且只要开始替人操作真实系统,驾驶舱就同时是一套责任边界: 谁提出目标、谁授予权限、谁复核结果、出了问题谁收尾;没有责任边界的驾驶舱很难进高价值流程42。 复杂系统常把「生成」和「评估」拆给不同角色(一个写、一个挑错,模型很难既当作者又当审稿人), 具体做法留到第 13 章 §10。

11. 技能:比工具列表更重要的一层​

工具列得再多,模型仍可能每次都从零拼流程——没法复用上次把发票转成报销单的成熟套路。 于是近年来出现了一层新抽象:把做某类任务的一整套方法打包成一个目录, 里面放说明、脚本、模板、检查清单和资源,需要时模型只加载相关部分, 再和工具调用、代码执行组合使用。这类打包物被称为 Agent Skills43。 书里的厨房比喻极好记:工具像锅铲(单个原子动作),协议——事先约定好的连接规矩——像供电供水, 技能像菜谱加备料清单(把一类任务做对的完整套路)44。

这条线的要点是一个反直觉判断:工具列表的长度本身并不关键;稳定性更依赖常用任务能否沉淀成可复用技能、 并在正确时机被调用45。

补充(不在书里,依据我们的协议书架):Agent Skills 已有公开规范, 定义了技能目录的结构——说明书(SKILL.md)放元数据(描述这个技能「是什么」的标签信息)与用法,辅助脚本、模板与参考资料随目录分发, 渐进式披露(先读名字和描述,任务相关时才读全文)是其核心机制。 依据: shelf=ai-protocol-reference/agent-skills-spec#01-spec-format.md @220633fbcac0fcbf9980858781acdab9d086a8e2 事实=规范把技能定义为含 SKILL.md 的目录,frontmatter 只暴露 name/description 等元数据, 正文与附属文件按需加载,与本节「只加载相关部分」的说法一致。

这条规范线和原书的判断在同一天线上:工具解决「单步怎么做」,技能解决「一类事怎么稳定做成」。

12. 智能体推断负载的特殊性​

智能体场景下的推断负载和聊天很不一样:请求碎片化——短而频繁的决策调用、结构化输出、 工具参数生成、网页观察总结、失败后的重规划混在一起46。这带来三个具体后果47:

  1. 很多调用不要长文本,要的是低时延+稳定的结构化输出:生成一段 JSON 工具参数, 超时几百毫秒就会拖慢整条任务链;
  2. GPU 的计算和外部 I/O 交错出现:显卡经常在等浏览器返回、等数据库查询、等审批人点击—— 不能只优化「模型一直在算」这一个理想状态;
  3. 强弱模型混用成为常态:弱模型做路由过滤,强模型处理关键决策,推断系统越来越像一个多级运行时。

所以优化目标也随之改变:不再只是让单个回答更快,而是让整条任务链的平均完成时间更短、 失败重试成本更低、关键节点成功率更高——面向智能体的推断,优化的是闭环效率,不是单次生成速度48。 这正是第 10 章那套运行时的第二份考卷。

13. 现实中的产品形态​

成品已经落地。按场景分,今天能用的形态大致五类,各自的「人机分工」不一样49:

编程智能体是走得最远的,原因很有意思:代码这个世界天然适合机器协作——Git 让每次改动可追溯, 单元测试把「功能正确」变成可以判真假的说法,编译器即时报语法错,持续集成(每次提交自动跑测试)流水线自动告诉你有没有弄坏别人的代码。 这些为人类协作搭的基础设施,恰好给了智能体一条现成的行动-反馈闭环50。 部署位置又分三条路径:端到端工程智能体(如 Devin,从 issue 直达 PR,可靠性门槛最高); 命令行本地形态(如 Claude Code CLI,跑在你终端里,人类仍在环上,主控权在程序员手里); IDE 内嵌与云端异步形态(如 Cursor)51。它们共同的甜区是边界清晰、可自动验证的任务; 共同的盲区是「重构得更优雅」「架构合不合理」这类没有客观判据的开放任务52。

浏览器与电脑操作智能体让模型直接看屏幕、动鼠标:Anthropic 的 Computer Use、Google 的 Project Mariner、 OpenAI 的 Operator(2025 年并入 ChatGPT agent)。共同的挑战是把「看屏幕」和「操作」结合得足够可靠—— 弹窗、布局变化、登录失效都会让它失稳;它看见一个蓝色按钮,得知道那是「提交」 还是「同意把银行卡交给陌生网站保管」53。

通用任务智能体(Manus、早期 AutoGPT/BabyAGI)接受开放目标,自主拆解搜索记录交付; 先驱们当年常常走进死循环、忘记目标,今天这类产品正从「概念烟花」走向「可以交付一点成果的工具」54。 开源与本地优先关心另一个维度:智能体属不属于你——记忆可见、权限可控、离线可跑、每一步留痕; 当云端助手越来越集中,这条路线提醒市场,用户要的不只是最强的助手,也是真正属于自己的助手55。 企业智能体则嵌进业务系统(Salesforce Agentforce、Microsoft 365 Copilot、RPA 编排——把固定流程串成自动化), 逐步重写报销审批、数据迁移这类流程清晰、重复性强的工作56。

最后一层容易被忽略的身份感:同一个底座模型可以被配成客服小慧、资深前端 Devin 或孩子的故事大王—— 这种身份配置(persona)靠一组互相印证的设定撑着:身份背景、能力边界、语气风格、知识时效、行为协议; 工程上常见三种做法:只写在系统提示里(轻快但容易被长对话冲掉)、单独微调(稳但贵)、或两者混合—— 大多数商业产品走混合路线57。

14. 智能体式模型怎么训出来​

刚预训练完的语言模型其实很不擅长做事:喋喋不休地解释而不是简洁地调工具、一口气把所有步骤写完 而不是做一步看一步、对调用格式挑三拣四。把它训成能用的智能体,靠专门的后训练,书里拆成三步58:

  1. 从范例里学风格:喂大量高质量轨迹(好智能体面对某类任务每一步想什么、调什么工具、 怎么处理返回),模仿出「做事的样子」。轨迹一部分来自人工标注(贵但准), 一部分来自更强模型生成再过滤(便宜但要清洗);
  2. 从结果里学策略:在模拟环境里跑真实任务,按最终是否完成给奖励。教出的是长程目标导向—— 为了最终成功愿意在中途绕远路,失败时不卡死而是换路再试。难处也在奖励:代码任务可以用单元测试跑通给分, 开放任务(比如写研究报告)连奖励怎么定义都是研究问题59;
  3. 专门学会用工具:见过大量调用样本、错误样本、组合样本,面对陌生工具才会合理使用, 工具报错也不慌——今天的智能体模型擅长用工具,靠的是见得多,未必是推理本身变强了60。

训出来的这一类模型被称为智能体式模型(agentic model)。书里给它画了一个精准的肖像: 它和编程模型走得很近,因为最成功的智能体场景都离不开代码—— 说它是「会说话的程序员」并不夸张;反过来,不擅长代码的模型做智能体, 就像不会看地图的人送外卖,嘴上答应得很爽快,上路就把奶茶送到隔壁小区61。 但书里也钉了边界:编程只是当前最易验证的一类智能体形态,未来客服、医疗、教育、创作场景的智能体不必都长得像编程助手62。

全章收束在一个三方协同公式上:模型决定能力上限,驾驶舱决定产品形态,训练决定具体场景下的表现; 好驾驶舱要配懂它约定的模型,训好的模型也要靠驾驶舱兜住它的能力——这种协同迭代, 正是智能体领域能不断刷新能力边界的根本原因63。

主走查:把这个报错修好并提交​

这条走查贯穿本章。 输入是一条 issue:「用户上传 .heic 图片时报 TypeError, 重现率约十分之一(此概率是为演示编的)。」跟一个编程智能体走完整个闭环。

① 观察。(§3 §6)它读 issue 正文和附带的堆栈:TypeError: cannot read property 'width' of undefined, 出自图片解码模块;再打开仓库定位到第 142 行附近(行数为演示设定)。 关键动作藏在看不见的地方:.heic 的解码器是懒加载的,网络慢时 promise 未完成就被读取—— 这是部分可观测:issue 里一个字都没提,但它注意到报错时间戳集中在弱网用户上(演示推演)64。 它没有急着下结论,先补了一次观测:在本地复现、打了条日志——这就是 §6 说的「为确认留预算」。

② 思考。(§3 §4)推理在这一步成形:「懒加载未等待」是假设 A,「格式解析库版本缺陷」是假设 B。 选 ReAct 式的走法:想做交错,因为两个假设都需要中途观察来裁决;若是五个已知步骤的机械迁移, ReWOO 式的一次性计划会更省(§4 的选择逻辑落到了实处)。

③ 行动第一轮:改三行。(§7)修改方式刻意挑了可逆动作:编辑器里改成 await 等待解码完成再加三行防御检查 ——不升级依赖、不动构建配置、不碰无关文件。按 §7 的原则,不确定时可逆动作优先。

④ 反馈第一轮:测试挂了。(§3 §9)它跑测试套件,17 个用例里 1 个挂了(演示数): 老版本的 Safari 不支持新的解码 API——「懒加载」假设的对立面出现了新证据。 一次行动错误没有扩散:因为它只改了三行,回滚只需丢弃本次修改,环境没有被污染(§9 的累积性对照)。

⑤ 换一条路,再跑。(§8 §9)第二次尝试:改用兼容写法,同时按预算纪律收敛探索—— 它记录着自己已消耗两轮尝试、剩余预算充足(§8),这次跑完,38 个用例全绿(演示数)。

⑥ 提交前,停下问人。(§7)修复涉及对一个公开函数行为的变更,超出「修 bug」的字面授权范围。 驾驶舱的安全检查组件弹出确认:附上 diff 与测试结果,等人点头。支付、删除、发布类动作不经确认不发生; 这里的提交虽然可回滚,但属于对外可见的动作,驾驶舱把它配置进了人工确认清单(§10 六件事里的安全检查)。

⑦ 收尾留下痕迹。(§9 §10)整个过程的轨迹——两次尝试、一次回滚、一轮确认——被完整记进日志与回放, 既是复盘材料,也是下一轮智能体训练的数据(§14 第一步需要的正是这种轨迹)。 issue 最终状态不是「模型说了句漂亮话」,而是仓库里一个可查的 commit 和一套变绿的测试: 这就是「可验证的推进」和「表演性叙述」的区别。

作者的判断与证据​

书里给了明确证据或可核事实的地方:

  • 「同一组权重,驾驶舱不同,可靠性差一个数量级」出自开篇;驾驶舱打磨拉开差距的现象被标注为研究和实践的反复观察141;
  • 三条范式的提出时间线(2022-10 ReAct / 2023-05 ReWOO / 2024-02 CodeAct)与其各自动机,与文献一致11;
  • SWE-bench、GAIA、WebArena、Terminal-Bench 这些评测基准的名字与定位,是可查的公开基准38;
  • 产品事实(Devin 发布时间、Claude Code CLI 随 Claude 3.7 发布、Operator 并入 ChatGPT agent 的时间线)给出了具体月份5153;
  • 智能体训练三步法的划分,书里明确说是「粗粗看可以分成三步」的经验归纳而非严格分类58。

书里标成立场或判断的地方:

  • 「闭环稳定比推理强弱更决定成败」「很多不稳定根子在任务定义不清」——作者的工程判断,论证充分但无单一实证;
  • 退出机制的三条硬条件(连续两次失败暂停/预算八成回人工/越权交还)被明确写成「工程上常见」的做法示范,承认是约定俗成而非标准27;
  • 「工具列表长度本身并不关键,技能沉淀才关键」——作者的架构判断45;
  • 「智能体式模型≈会说话的程序员」——作者自嘲式的类比判断,随后立即自我设限(不等于所有智能体都以代码为中心)6162。

判断(我们的,不是书里的): 本章暗含的最大风险其实写在习题册旁:若每一步成功率为 95%, 连跑 50 步的整体成功率只剩约 7.7%——可靠性随链条长度指数衰减,这是闭环的本征数学。 全章给出的解药(验证点、退出条件、检查点、人在环——关键一步留给人拍板)本质都在缩短「无监督连续链条」的长度, 而非提高单步成功率。据此我们认为:评价智能体框架时,「单步成功率」只是个好看但会骗人的数字, 真正该比的是「无人工干预下的最长可靠链条长度」。 如果错,会错在: 若某类训练方法能让单步成功率逼近 99.9% 以上, 指数衰减的威胁大幅减轻,链条长度将不再是稀缺资源——书里 §14 提到的「面向任务结果的强化学习」 正是朝这个方向使劲的路,它能否把单步推过那个门槛,目前证据不足。

边界与局限​

  • 对应关系: 本章对应原书第 10 章全文。原书把产品形态和训练简介都收在本章;本组拆解保持了这个安排,训练的系统展开推迟到第 14 章。
  • 没展开的: 人机协同四种深度的完整矩阵在第 13 章 §16;工具与环境的设计规范整章属于第 12 章;多角色协作为何昂贵、何时收缩回单主体,同样在第 13 章;评测基准的具体构成与跑法在第 14 章。
  • 术语提醒: 原文地图里的「驾驶舱(harness)」在社区也译作「挽具」「套件」,本文统一用「驾驶舱」;「身份配置(profile/persona/角色卡)」同义,统一用前者。
  • 时效声明: 书中产品名(Devin/Claude Code/Cursor/Operator/Mariner/Manus/Agentforce)的归属与档期截至成书;名称会漂,三条部署路径的分野与人机分工的逻辑不易漂。

可带走的​

  1. 智能体成立的三个条件: 模型够强、世界接口化、推断便宜——2020 年代初第一次凑齐。
  2. 分水岭只有一道: 下一步由谁挑。人提前写死每一步的是工作流,边看边改的才是智能体;工程最优解是用工作流包住智能体。
  3. 闭环四步:观察→思考→行动→反馈;三个范式一句话: ReAct 边想边做,ReWOO 先规划后执行(省词元、抗失败),CodeAct 用代码承载动作(可组合、留变量)。
  4. 「智能体不稳定」的第一嫌疑人是任务定义和环境接口,不是模型不够聪明。
  5. 拿不准就补观测——把模糊信号过早压成结论,是最常见的死因;确认本身要预留预算。
  6. 可逆动作优先,不可逆动作延迟;自主层级卡在「不可逆动作要不要人工确认」这条线上。
  7. 退出条件要写死: 连续两次失败暂停、预算八成回人工、越权动作交还控制权。
  8. 失败分四类:观察错、计划错、行动错、伪成功——第三类污染地基,第四类腐蚀信任,伪成功只能靠外部验证点拦截。
  9. 驾驶舱六件事 + 技能层: 循环、调度、上下文、安全、记忆、日志;同一组权重换个外壳,可靠性差一个数量级。工具像锅铲,协议像水电,技能像菜谱——列表长度不重要,套路沉淀才重要。
  10. 能力上限来自训练,产品形态来自驾驶舱,气质边界来自身份配置;推断负载更碎、更短、更显卡等外部返回——优化目标是任务链效率,不是单次速度。

原文地图​

主题原书节原文位置
动手的开端10 引言text/11-ch10.txt:5(搜““动手做事””) · text/11-ch10.txt:7(搜“差出一个数量级”)
三个阶段10 引言text/11-ch10.txt:10(搜“提示工程的时代”) · text/11-ch10.txt:11(搜“上下文工程（Context Engineering）”) · text/11-ch10.txt:13(搜“驾驶舱工程（harness engineering）”)
为什么现在能行10.1.1text/11-ch10.txt:39(搜“老目标，智能体接续的也是这个梦想”) · text/11-ch10.txt:43(搜“频繁试错”)
近似判断替换写死规则10.1.1text/11-ch10.txt:47(搜“近似判断”) · text/11-ch10.txt:52(搜““凑齐””)
工作流定义10.1.2text/11-ch10.txt:57(搜“预先定义好步骤”) · text/11-ch10.txt:58(搜“某个局部环”)
分水岭10.1.2text/11-ch10.txt:62(搜“条件性决策”) · text/11-ch10.txt:65(搜“分水岭”) · text/11-ch10.txt:66(搜“包住智能体”)
闭环四步10.1.3text/11-ch10.txt:72(搜“把它看成一个闭环”) · text/11-ch10.txt:75(搜“反馈，系统要重新读取”)
错误放大与闭环稳定10.1.3text/11-ch10.txt:82(搜“在后续回合中被放大”) · text/11-ch10.txt:83(搜“更在于闭环能否稳定”)
不是更会思维链10.1.3text/11-ch10.txt:87(搜“更会思维链的大模型”) · text/11-ch10.txt:90(搜“观察粒度够不够”)
三种范式10.1.3text/11-ch10.txt:94(搜“ReAct（2022-10）”) · text/11-ch10.txt:100(搜“ReWOO（2023-05）”) · text/11-ch10.txt:104(搜“CodeAct（2024-02）”)
任务环境状态10.2.1text/11-ch10.txt:120(搜“围绕某个任务”) · text/11-ch10.txt:124(搜“数据库或企业内部系统”） · text/11-ch10.txt:125(搜“哪些信息还不确定”)
不稳定的根子10.2.1text/11-ch10.txt:128(搜“忘记已经做过什么”) · text/11-ch10.txt:129(搜“而未必是模型本身不够聪明”)
显式外置状态10.2.1text/11-ch10.txt:136(搜“一部分状态显式外置”) · text/11-ch10.txt:140(搜“减少“全靠模型自己记着””)
部分可观测10.2.2text/11-ch10.txt:146(搜“partially observable”） · text/11-ch10.txt:148(搜“恰恰会决定行动后果”)
状态歧义10.2.2text/11-ch10.txt:149(搜“状态歧义”) · text/11-ch10.txt:151(搜“过早压成确定结”)
确认预算10.2.2text/11-ch10.txt:155(搜“为“确认”本身留预算”) · text/11-ch10.txt:158(搜“置信门槛”) · text/11-ch10.txt:161(搜“还没看清楚”)
目标澄清与成功判据10.2.3text/11-ch10.txt:165(搜““任务到底算不算完成”") · text/11-ch10.txt:167(搜“行动能力本身反倒不是瓶颈”) · text/11-ch10.txt:176(搜“可检查的终态”)
自主性分层10.2.4text/11-ch10.txt:189(搜“不是单一开关，而是分层结构”) · text/11-ch10.txt:193(搜“带工具的助手”)
授权与退出10.2.4text/11-ch10.txt:207(搜“逐层展开的委托关系”) · text/11-ch10.txt:215(搜“耗去八成”) · text/11-ch10.txt:215(搜“连续两次工具调用都失败就暂停”)
可逆优先10.2.4text/11-ch10.txt:226(搜“优先做可逆动作”) · text/11-ch10.txt:227(搜“提高总成功率的工程方法”) · text/11-ch10.txt:229(搜“修正的代价就越高”)
预算意识10.3.1text/11-ch10.txt:245(搜“暴露于副”) · text/11-ch10.txt:247(搜“行动强度”) · text/11-ch10.txt:252(搜“代价结构并不相同”) · text/11-ch10.txt:263(搜“失控流程”)
四类失败10.3.2text/11-ch10.txt:268(搜“观察错误”) · text/11-ch10.txt:269(搜“计划错误”) · text/11-ch10.txt:271(搜“参数填错”) · text/11-ch10.txt:277(搜“伪成功”)
会说 vs 可验证10.3.2text/11-ch10.txt:283(搜“追求做完之后可以被验证”) · text/11-ch10.txt:286(搜“可验证的推进”) · text/11-ch10.txt:287(搜“可以看 diff”)
评测轨迹化10.3.2text/11-ch10.txt:304(搜“SWE-bench”) · text/11-ch10.txt:307(搜“整条轨迹”) · text/11-ch10.txt:310(搜“像样的答案还不够”)
基本组成10.4.1text/11-ch10.txt:317(搜“模型核心”) · text/11-ch10.txt:320(搜“停止条件和异常处理”)
驾驶舱命名10.4.2text/11-ch10.txt:339(搜“驾驶舱（Harness）”) · text/11-ch10.txt:340(搜“马具”或“安全带”)
六件事10.4.2text/11-ch10.txt:346(搜“循环控制”) · text/11-ch10.txt:348(搜“实际的函数调用”) · text/11-ch10.txt:353(搜“提示注入”) · text/11-ch10.txt:355(搜“日志与回放”)
权重不变外壳定生死10.4.2text/11-ch10.txt:377(搜“驾驶舱有多成熟，而非底层模型本身”) · text/11-ch10.txt:379(搜“拉开明显差距”)
责任边界10.4.2text/11-ch10.txt:382(搜“责任边界”) · text/11-ch10.txt:384(搜“接管和追责”)
技能10.4.2text/11-ch10.txt:391(搜“Agent Skills”) · text/11-ch10.txt:393(搜“锅铲”) · text/11-ch10.txt:397(搜“并不关键”)
推断负载特殊性10.4.3text/11-ch10.txt:402(搜“碎片化”) · text/11-ch10.txt:409(搜“等浏览器返回”) · text/11-ch10.txt:411(搜“多级推断运行时”) · text/11-ch10.txt:416(搜“闭环的效率”)
编程智能体为什么先行10.5.1text/11-ch10.txt:429(搜“练手的天堂”) · text/11-ch10.txt:430(搜“适合机器协作”)
三条部署路径10.5.1text/11-ch10.txt:438(搜“Devin”) · text/11-ch10.txt:442(搜“Claude Code CLI”) · text/11-ch10.txt:446(搜“Cursor”)
共同甜区与盲区10.5.1text/11-ch10.txt:451(搜“边界清晰、可自动验证”) · text/11-ch10.txt:453(搜“客观判”)
浏览器智能体10.5.1text/11-ch10.txt:459(搜“Computer Use”) · text/11-ch10.txt:467(搜“银行卡交给陌生网站保”)
通用与本地优先与企业10.5.1text/11-ch10.txt:474(搜“死循环、忘记目标”) · text/11-ch10.txt:479(搜“是不是属于你”) · text/11-ch10.txt:484(搜“属于自己的助手”) · text/11-ch10.txt:489(搜“报销审批到数据迁移”)
身份配置10.5.1text/11-ch10.txt:506(搜“persona、角色卡”) · text/11-ch10.txt:509(搜“两者混合”)
训练三步10.5.2text/11-ch10.txt:519(搜“从范例里学风格”) · text/11-ch10.txt:525(搜“从结果里学策略”) · text/11-ch10.txt:527(搜“奖励从哪里来”) · text/11-ch10.txt:532(搜“专门学会用工具”)
智能体式模型10.5.2text/11-ch10.txt:538(搜“agentic model”) · text/11-ch10.txt:541(搜“会说话的程序员”) · text/11-ch10.txt:542(搜“送外卖”)
三方协同10.5.2text/11-ch10.txt:547(搜“模型决定能力上限，驾驶舱决定产品形态”) · text/11-ch10.txt:549(搜“协同迭代”)

Footnotes​

  1. 出处:「10.1.1」第 39 段(text/11-ch10.txt:39,搜「老目标，智能体接续的也是这个梦想」)与第 43 段(text/11-ch10.txt:43,搜「频繁试错」);开篇的「数量级」判断在第 7 段(text/11-ch10.txt:7,搜「差出一个数量级」)。 ↩ ↩2

  2. 出处:第 47 段(text/11-ch10.txt:47,搜「近似判断」)。 ↩

  3. 出处:第 50 段(text/11-ch10.txt:50,搜「刚刚被跨过的阶段」)与第 52 段(text/11-ch10.txt:52,搜「“凑齐”」)。 ↩

  4. 出处:「10.1.2」第 57 段(text/11-ch10.txt:57,搜「预先定义好步骤」)。 ↩

  5. 出处:第 62 段(text/11-ch10.txt:62,搜「条件性决策」)与第 65 段(text/11-ch10.txt:65,搜「分水岭」)。 ↩

  6. 出处:第 66 段(text/11-ch10.txt:66,搜「包住智能体」)。 ↩

  7. 出处:「10.1.3」第 72 段(text/11-ch10.txt:72,搜「把它看成一个闭环」)与第 74 至 76 段(搜「第三步是行动」)。 ↩

  8. 出处:第 82 段(text/11-ch10.txt:82,搜「在后续回合中被放大」)。 ↩

  9. 出处:第 83 段(text/11-ch10.txt:83,搜「更在于闭环能否稳定」)。 ↩

  10. 出处:第 87 段(text/11-ch10.txt:87,搜「更会思维链的大模型」)与第 90 段(text/11-ch10.txt:90,搜「观察粒度够不够」)。 ↩

  11. 出处:「闭环范式的三种代表」第 94 段(text/11-ch10.txt:94,搜「ReAct（2022-10）」)、第 100 段(text/11-ch10.txt:100,搜「ReWOO（2023-05）」)、第 104 段(text/11-ch10.txt:104,搜「CodeAct（2024-02）」)。 ↩ ↩2

  12. 出处:第 109 段(text/11-ch10.txt:109,搜「彼此并不互斥替代」)与第 112 段(text/11-ch10.txt:112,搜「三者的影子」)。 ↩

  13. 出处:第 107 段(text/11-ch10.txt:107,搜「通用中介」)。 ↩

  14. 出处:「10.2.1」第 120 段(text/11-ch10.txt:120,搜「围绕某个任务」)与第 124 段(text/11-ch10.txt:124,搜「数据库或企业内部系统」)。 ↩

  15. 出处:第 129 段(text/11-ch10.txt:129,搜「而未必是模型本身不够聪明」)。 ↩

  16. 出处:第 130 段(text/11-ch10.txt:130,搜「动作空间」)与第 132 段(text/11-ch10.txt:132,搜「凭经」)。 ↩

  17. 出处:第 136 段(text/11-ch10.txt:136,搜「一部分状态显式外置」)与第 140 段(text/11-ch10.txt:140,搜「全靠模型自己记着」)。 ↩

  18. 出处:「10.2.2」第 146 段(text/11-ch10.txt:146,搜「partially observable」)。 ↩

  19. 出处:第 149 段(text/11-ch10.txt:149,搜「状态歧义」)与第 150 段(text/11-ch10.txt:150,搜「依赖服务已经失效」)。 ↩

  20. 出处:第 151 段(text/11-ch10.txt:151,搜「过早压成确定结」)。 ↩

  21. 出处:第 155 段(text/11-ch10.txt:155,搜「留预算」)与第 158 段(text/11-ch10.txt:158,搜「置信门槛」)。 ↩

  22. 出处:第 161 段(text/11-ch10.txt:161,搜「还没看清楚」)。 ↩

  23. 出处:「10.2.4」第 185 段(text/11-ch10.txt:185,搜「替你做到什」)。 ↩

  24. 出处:第 189 段(text/11-ch10.txt:189,搜「不是单一开关」)与第 198 段(text/11-ch10.txt:198,搜「同步上升」)。 ↩

  25. 出处:第 199 段(text/11-ch10.txt:199,搜「可回滚性相匹配的」)与第 203 段(text/11-ch10.txt:203,搜「卡在这条线上」)。 ↩

  26. 出处:第 207 段(text/11-ch10.txt:207,搜「逐层展开的委托关系」)与第 210 段(text/11-ch10.txt:210,搜「可降级的状态」)。 ↩

  27. 出处:「退出机制和授权一样重要」段(text/11-ch10.txt:215,搜「连续两次工具调用都失败就暂停」)与第 215 段(text/11-ch10.txt:215,搜「耗去八成」)。 ↩ ↩2

  28. 出处:「可逆动作优先，不可逆动作延迟」段(text/11-ch10.txt:226,搜「优先做可逆动作」)与第 227 段(text/11-ch10.txt:227,搜「提高总成功率的工程方法」)。 ↩

  29. 出处:「10.3.1」第 245 段(text/11-ch10.txt:245,搜「重新等待反馈」)。 ↩

  30. 出处:第 247 段(text/11-ch10.txt:247,搜「行动强度」)与第 249 段(text/11-ch10.txt:249,搜「先花成本做澄」)。 ↩

  31. 出处:第 252 段(text/11-ch10.txt:252,搜「代价结构并不相同」)与第 256 段(text/11-ch10.txt:256,搜「审计和确认流程」)。 ↩

  32. 出处:第 259 段(text/11-ch10.txt:259,搜「值不值得在这个时刻调」)。 ↩

  33. 出处:第 260 段(text/11-ch10.txt:260,搜「成熟的重要标志」)与第 263 段(text/11-ch10.txt:263,搜「失控流程」)。 ↩

  34. 出处:「10.3.2」第 268 段(text/11-ch10.txt:268,搜「观察错误」)、第 269 段(text/11-ch10.txt:269,搜「计划错误」)、第 271 段(text/11-ch10.txt:271,搜「参数填错」)。 ↩

  35. 出处:第 277 段(text/11-ch10.txt:277,搜「伪成功」)与第 279 段(text/11-ch10.txt:279,搜““看起来做完了””)。 ↩

  36. 出处:第 280 段(text/11-ch10.txt:280,搜「显式验证点」)。 ↩

  37. 出处:第 283 段(text/11-ch10.txt:283,搜「追求做完之后可以被验证」)与第 287 段(text/11-ch10.txt:287,搜「可以看 diff」)。 ↩

  38. 出处:第 301 段(text/11-ch10.txt:301,搜「BLEU、F1」)与第 304 段(text/11-ch10.txt:304,搜「SWE-bench」)、第 307 段(text/11-ch10.txt:307,搜「整条轨迹」)、第 310 段(text/11-ch10.txt:310,搜「像样的答案还不够」)。 ↩ ↩2

  39. 出处:「10.4.2」第 339 段(text/11-ch10.txt:339,搜「驾驶舱（Harness）」)与第 340 段(text/11-ch10.txt:340,搜「马具」)。 ↩

  40. 出处:六件事清单第 346 至 355 段(text/11-ch10.txt:346,搜「循环控制」;text/11-ch10.txt:348,搜「实际的函数调用」;text/11-ch10.txt:353,搜「提示注入」;text/11-ch10.txt:355,搜「日志与回放」)。 ↩

  41. 出处:第 377 段(text/11-ch10.txt:377,搜「驾驶舱有多成熟，而非底层模型本身」)与第 379 段(text/11-ch10.txt:379,搜「拉开明显差距」)。 ↩ ↩2

  42. 出处:第 382 段(text/11-ch10.txt:382,搜「责任边界」)。 ↩

  43. 出处:「驾驶舱之上还有一层：可复用技能」段(text/11-ch10.txt:391,搜「Agent Skills」)与第 392 段(text/11-ch10.txt:392,搜「检查清单和资源」)。 ↩

  44. 出处:第 393 段(text/11-ch10.txt:393,搜「锅铲」)。 ↩

  45. 出处:第 397 段(text/11-ch10.txt:397,搜「并不关键」)。 ↩ ↩2

  46. 出处:「10.4.3」第 402 段(text/11-ch10.txt:402,搜「碎片化」)。 ↩

  47. 出处:第 407 段(text/11-ch10.txt:407,搜「超时几百毫秒就影响整条任务链」)与第 409 段(text/11-ch10.txt:409,搜「等浏览器返回」)、第 410 段(text/11-ch10.txt:410,搜「弱模型做路由和过滤」)。 ↩

  48. 出处:第 416 段(text/11-ch10.txt:416,搜「闭环的效率」)。 ↩

  49. 出处:「10.5.1」第 427 段(text/11-ch10.txt:427,搜「几类代表形态」)。 ↩

  50. 出处:第 429 段(text/11-ch10.txt:429,搜「练手的天堂」)与第 430 段(text/11-ch10.txt:430,搜「可追溯」)。 ↩

  51. 出处:第 438 段(text/11-ch10.txt:438,搜「Devin」)、第 441 至 443 段(text/11-ch10.txt:442,搜「Claude Code CLI」)、第 446 段(text/11-ch10.txt:446,搜「Cursor」)。 ↩ ↩2

  52. 出处:第 451 段(text/11-ch10.txt:451,搜「边界清晰、可自动验证」)与第 453 段(text/11-ch10.txt:453,搜「客观判」)。 ↩

  53. 出处:第 459 段(text/11-ch10.txt:459,搜「Computer Use」)、第 461 段(text/11-ch10.txt:461,搜「Operator」)、第 467 段(text/11-ch10.txt:467,搜「银行卡交给陌生网站保」)。 ↩ ↩2

  54. 出处:第 473 段(text/11-ch10.txt:473,搜「AutoGPT」)与第 474 段(text/11-ch10.txt:474,搜「死循环、忘记目标」)。 ↩

  55. 出处:第 478 段(text/11-ch10.txt:478,搜「开源与本地优先」)与第 484 段(text/11-ch10.txt:484,搜「属于自己的助手」)。 ↩

  56. 出处:第 486 段(text/11-ch10.txt:486,搜「Salesforce Agentforce」)与第 489 段(text/11-ch10.txt:489,搜「报销审批到数据迁移」)。 ↩

  57. 出处:第 506 段(text/11-ch10.txt:506,搜「persona、角色卡」)与第 509 段(text/11-ch10.txt:509,搜「两者混合」)。 ↩

  58. 出处:「10.5.2」第 518 段(text/11-ch10.txt:518,搜「分成三步」)与第 519 段(text/11-ch10.txt:519,搜「从范例里学风格」)。 ↩ ↩2

  59. 出处:第 525 段(text/11-ch10.txt:525,搜「从结果里学策略」)与第 527 段(text/11-ch10.txt:527,搜「奖励从哪里来」)。 ↩

  60. 出处:第 532 段(text/11-ch10.txt:532,搜「专门学会用工具」)与第 534 段(text/11-ch10.txt:534,搜「拧螺丝」)。 ↩

  61. 出处:第 541 段(text/11-ch10.txt:541,搜「会说话的程序员」)与第 542 段(text/11-ch10.txt:542,搜「送外卖」)。 ↩ ↩2

  62. 出处:第 545 段(text/11-ch10.txt:545,搜「不一定都长得像今天的编程助手」)。 ↩ ↩2

  63. 出处:第 547 段(text/11-ch10.txt:547,搜「模型决定能力上限，驾驶舱决定产品形态」)与第 549 段(text/11-ch10.txt:549,搜「协同迭代」)。 ↩

  64. 弱网线索与时间戳分析是本走查为演示构造的情节;书内支撑是「部分可观测」与「确认预算」两条机制(text/11-ch10.txt:146,搜「partially observable」、:155,搜「留预算」)。 ↩