构建高效智能体

作者把整篇文章组织成一条自上而下的决策链，每一节都在回答「上一节的答案成立时才继续往下」。

这条链的排列不是叙述方便，而是作者反复回到的同一个判断：复杂度只在可证明地改善结果时才加。开篇讲「找最简单的可行方案，必要时才增加复杂度」，中间讲框架时又说「它们会让人忍不住加复杂度，而简单设置本来够用」，结尾收在「成功不在于构建最精密的系统，而在于构建适合你需求的那个系统」。三处同义反复，构成这篇文章的骨架。

值得注意的是，这条链上没有一节是正面讲「怎么把智能体做好」。通读全文会发现它的重心落在两端：最前面讲「什么时候不该用」，最后面讲「工具怎么设计」。中间那五种模式只是目录。

从增广语言模型这个基座出发，逐级增加复杂度，铺出五种工作流模式，最后抵达自主智能体。

这个排列本身就是判据。每往下一级，路径的确定性就少一分，模型承担的决策就多一分。五种工作流模式之间不是并列可选的菜单，而是按「子任务能否预先知道」这一条轴排开的：能预先知道，就落在前四种里的某一种；不能预先知道且要动态拆解，用编排者-工作者；连拆解方式本身都难以预设，才轮到评估者-优化者与自主智能体。

作者给这条模式的适用条件只有一句话：任务能被容易且干净地分解成固定子任务。目标是用延迟换更高的准确率，因为每个子任务更简单，模型出错的机会就少了。

它的关键设计是闸门：在任意中间步骤加程序化检查，确认流程还在轨道上。这个细节容易被略过，但它是提示链区别于「让模型一口气干完」的全部价值所在。闸门把错误拦在早期，而不是让它顺着链条一路传到底。典型用法有两类：先生成营销文案再翻译；先写文档提纲、检查提纲是否符合标准、再照着写正文。第二个用法的结构值得单独看——检查环节不是让模型自己满意，而是让程序按明确标准判断。

路由解决的是一个具体的性能问题。客服场景里，通用咨询、退款请求、技术支持如果共用一套提示，调好其中一类就会让另一类变差。分类之后，各走各的提示、工具与流程，互不干扰。

作者举的第二种用法比第一种更有意思：把简单常见的问题路由到更小更便宜的模型（Haiku 4.5），把困难少见的路由到更强的模型（Sonnet 4.5），以成本换性能。这是把「模型选择」也当成路由的一个分支。路由器不只分发任务，也分发算力。

作者把并行拆成两种变体。分区把任务拆成互不依赖的子任务并行处理，适用场景有两个：护栏与主响应分离，一个模型实例处理用户请求、另一个筛查不当内容；自动化评估，每次调用评估模型表现的一个不同方面。

投票是同一任务跑多遍拿到多样化的输出。适用场景是代码漏洞审查，多个不同提示各自审查并标记问题；内容合规评估，多个提示评估不同方面，或要求不同投票阈值以平衡假阳性与假阴性。投票不只是「多数决」——不同维度可以设不同阈值，某些维度严格些才算问题，某些宽松些。阈值可调意味着你可以按误报代价与漏报代价的不对称来分配严格度。

适用场景的共性是子任务的数量和内容都不可预测。原文举的两个例子都指向这一点：编程产品每次要改的文件数量与改动性质取决于任务本身；搜索任务要从多个来源收集与分析信息，可能需要多少轮搜索事先不知道。

作者用「地形相似，但关键区别在于弹性」来描述它与并行的差别。并行的中心只是分发任务，编排者的中心还要做判断：判断该派什么活、派给谁、收到的结果怎么合。这比并行多了一层要求，代价是中心成了单点。编排者拆错了，所有下游都错。

这个模式的成立需要两个信号同时出现，作者把它们写得明确。第一，人把反馈讲清楚之后，模型的输出能确实变好。第二，模型自己能给出这种反馈。缺任何一个，循环就空转：模型批评得不准，或者批评了但改进方向对不上。

作者拿人类写作者反复打磨文章的过程类比这个循环。这个类比用得准：写作者的第一稿确实需要第二双眼睛，而这双眼睛不必是另一个人的，也可以是模型。适用场景有两个：文学翻译，译者模型可能漏掉细微之处而评估模型能给出有用批评；需要多轮搜索与分析的复杂检索任务，评估者决定是否还需要继续搜。

作者对智能体工作方式的描述非常朴素：它通常就是一个基于环境反馈循环使用工具的语言模型。所有让它显得复杂的机制——规划、暂停、执行、检查点，都是为了支撑这个循环。

运行机制的三个要素各司其职。规划与执行分离：任务明确后智能体独立规划和执行，必要时返回向人求助，起点必须是人给的命令或交互式对话，智能体不自己发明任务。每一步都要拿到地面真相：工具调用结果、代码执行输出这类来自环境的真实反馈，是智能体判断进展的依据，没有它模型只能靠想象往下走。检查点与停止条件：智能体可以在检查点或遇到阻塞时暂停等人介入，任务通常在完成时终止，但通常还要设停止条件来保持控制。作者特别强调：自主性适合在可信环境中做规模化任务，代价是更高成本与错误累积，因此建议在沙箱充分测试并配以护栏。

作者在正文中只留了一句重话，然后把它展开成附录。「构建 SWE-bench 智能体时，我们花在优化工具上的时间比优化整体提示词更多。」这句话是全文对工程优先级的最强表态——工具设计不是收尾工作，而是主要工作量。

作者先指出一个容易被忽略的事实：同一个动作往往有多种描述方式。文件修改可以写成 diff，也可以重写整个文件；结构化输出可以把代码放在 markdown 里，也可以放在 JSON 里。在软件工程里这些差异是表面的、可无损互转，但对模型来说，有些格式明显更难写。写 diff 需要在写新代码之前就知道 chunk 头里要改多少行；把代码放进 JSON 相比 markdown 需要额外转义换行和引号。方法论层面的核心类比是：把智能体与计算机的接口当成人机接口来对待，投入同等认真的力气。由此推出四条——把自己放到模型的位置上看工具是否显然可用、像给初级开发者写接口文档那样写、测试模型怎么用你的工具、对工具做防错设计（poka-yoke）。

最后这条作者给了实测案例，也是全文最具体的一个工程细节：他们发现模型在使用相对路径的工具时会犯错，尤其是在智能体已经移出根目录之后。解决办法是把工具改成强制要求绝对路径，然后模型使用这个方法毫无差错。这个案例示范了防错设计的完整逻辑：错误是环境的结构性特征导致的，那就消除环境里的这个特征，而不是在提示词里反复叮嘱模型小心。

这三条与前面的决策链是同一件事的三个侧面。「保持简单」管的是不做什么，「优先透明」管的是让人看见它在做什么，「精心设计接口」管的是它做得对不对。

关于框架，作者的最终建议是：框架能帮你快速起步，但不要犹豫减少抽象层、在走向生产时用基础组件构建。