先划清模型与代码职责，再决定是否用Agent

用户只想要 5 条文档摘要，系统却先规划，再让研究、写作、审核等多个 Agent 依次接手，最后还要判断审核是否通过。原文用这个场景提出一个架构问题：到底哪个决策需要 Agent 自己做？

作者的结论是，先把明确的规则写进代码，把难以理解的内容交给模型；只有系统需要自主选择、调整下一步时，才引入 Agent。这篇值得读的地方，是提供了一套判断复杂度是否必要的方法，能直接用来检查正在做的 AI 功能。

哪些交给模型，哪些必须写进代码

原文以发票处理为例，区分了两类工作。

从陌生版式中找到供应商名称、理解商品描述、提取格式不统一的字段，需要解释不规整的信息，适合让模型参与。但发票号码是否存在、金额是否算对、供应商是否注册、是否重复处理、当前用户是否有审批权限，都有明确的判断依据。

合理的流程是：模型提取字段，代码校验结果，后端检查权限和重复记录，再把发票交给人审批。

模型负责理解，应用负责执行规则。

退款判断也是一样。若退款资格已经由一组明确条件定义，就不该把整个决定交给一句「读取订单，判断能否退款」。后端应逐项执行条件，模型可以解释结果，或者指出哪些信息还需要人工确认。

这样做的价值很具体：规则可以测试，决策可以审计，政策变更也有明确的修改位置。模型生成了一段有说服力的解释，并不能替代真实的权限检查。

工作流和 Agent，差别在谁决定下一步

作者给出的区分很实用：工作流按预先定义的路径执行；Agent 会根据观察到的结果，选择下一步。

例如排查仓库里的 Bug，可能先搜索文件，再复现问题、检查依赖；一个假设失败后，还要换方向。这里「接下来查什么」就是任务的一部分，自主性有实际用途。

相比之下，把通过校验的表单写入数据库，通常已有确定流程。给它增加规划和任务分派，未必能解决新的问题。

因此，选架构前先把业务步骤写出来。原文的客服邮件场景包括查询账户信息、寻找适用政策，以及将敏感情况交给人工审批。拆开以后，再分别判断：哪些步骤需要语言理解，哪些只是数据库查询，哪些按业务规则执行。

你可能只需要在受控流程里放少量模型调用。

作者援引 Anthropic 的指导，建议从简单方案开始，再增加复杂度。不过，原文没有提供具体任务的效果数据。这是一条设计建议，不能据此断言所有固定工作流都比 Agent 更好。

多一个 Agent，要多证明什么

「增加一个审核 Agent」听起来能提高可靠性，但作者要求先回答几个问题：它负责什么、需要哪些信息、产出什么、如何验证，以及与其他 Agent 意见不同时怎么办。

其中最关键的是验证方式。

第二个模型赞同第一个模型，不构成答案正确的独立证据。

计算结果应该用计算核验，数据库状态应该直接查询，代码行为应该运行有意义的检查。审核 Agent 如果没有明确标准，也拿不到相关证据，就很难证明它增加了多少价值。

多 Agent 更适合相对独立、可以并行推进的子任务，例如分别研究不同问题，最后合并结果。如果每一步都严重依赖上一步，拆分只会增加交接。原文给出的交接约定如下，用来明确接收什么、交付什么、何时算结束：

Input:
The question and relevant evidence.

Output:
Findings with source references and uncertainties.

Completion:
Required checks satisfied or a clear blocked status.

要留意 Completion：完成条件既可以是必要检查已经通过，也可以是明确报告阻塞状态。不能只要求每个 Agent 交一段看起来完整的文字。

如何判断这些成本划不划算？作者建议先建立简单基线，可以是普通函数、一次模型调用、固定顺序的模型调用，或者一个只配少量工具的 Agent。用代表性样例跑过之后，再让复杂方案处理同一批样例，只有改善值得额外投入时才保留。

评价还要落到用户体验上：结果是否有用、等待多久、花费多少、失败能否恢复，以及中间进度是否值得展示。原文没有给出具体指标或测试集，需要团队按自己的业务补齐。

我的判断

我赞同作者对规则执行和模型解释的划分。对前端、全栈团队来说，最容易踩的坑，是把现有后端已经能准确判断的事情，再交给模型判断一次。这样既增加不确定性，也让真正的决策位置变得模糊。

但「一个函数就够了」更像提醒，不能直接作为所有项目的答案。一个函数能处理退款资格检查，却未必能覆盖非标准材料的理解；固定流程容易约束步骤，也可能无法预先覆盖复杂排障中的每条路径。选择仍取决于任务有多少未知，以及系统是否需要改变行动方向。

原文没有展示作者团队的实测结果，也没有提供成功率、延迟、成本或失败恢复的对照数据。关于多 Agent 交接成本、单 Agent 优化可能取得相近效果的判断，应当视为经验性指导。

它最有用的贡献，是要求每份复杂度都拿出理由。与直接套用规划、执行、审核的角色模板相比，先列业务流程、找出不确定步骤，更容易得到可以验证的方案。

能拿来做什么

• 做 Node 发票或退款接口时，把字段理解交给模型，把金额校验、重复记录、权限和资格检查保留在后端，并让模型根据真实检查结果生成说明。
• 给文档摘要或客服辅助功能加 Agent 前，先画出固定执行步骤，检查少量模型调用能否完成任务，避免为每个步骤都设置一个角色。
• 用 AI 排查代码问题时，允许它根据搜索、复现和检查结果调整方向，同时要求结论附带相关证据，并用实际检查验证代码行为。
• 准备增加审核或研究 Agent 时，先写清输入、输出、完成条件和分歧处理方式，再用同一批代表性样例比较效果、等待时间、成本与失败恢复表现。