1. 为什么 Anthropic 这篇架构笔记，值得每个开发智能体的人重读三遍
先说我自己的感受。这几年智能体赛道有多热不用我重复了，团队里聊的是 agent，开源社区里卷的是框架，技术大会上走秀的是 demo。可当我真正动手做一个智能体，从 "能跑通一个循环" 到 "能交付一个稳定可靠的系统"，中间那条路远比我预想的长。问题不在模型能力，而在架构选择。
直到我读到 Anthropic 关于构建有效智能体的那篇工程笔记，才把很多模糊的判断理清了。它没有讲复杂的算法，也没有给花哨的架构图，而是回答了三个最本质的问题：智能体和工作流到底差在哪里、什么场景真正需要智能体、以及如何用最小成本设计出可靠的系统架构。
标题里"讲清楚"这三个字，我觉得特别准确。因为市面上讲 agent 的资料，大多数要么停在"给你看个炫酷案例"，要么堆了一堆框架名词。而 Anthropic 这篇笔记的价值在于：它把智能体架构从"玄学"拉回到了"工程决策"的层面——你要做的不是选一个最"智能"的方案，而是选一个复杂度匹配你业务场景的方案。
这篇文章适合谁看？如果你正准备从零搭建一个智能体但不确定该用工作流还是 agent；如果你已经用框架搭了 demo，却在生产环境里频繁翻车；或者你只是想搞清楚"agent 架构到底是怎么回事"——那这篇笔记都值得你静下心读完。我会结合自己的落地经验，把笔记里的核心逻辑拆开讲透，顺便补充一些原文没写但实际工程中一定会遇到的细节。
提示：Anthropic 这篇文章的核心观点可以浓缩成一句话——**能不用智能体就不用智能体，能用简单工作流解决的，绝不为了炫技而上 agent。**这句话我一开始不以为然，踩了大半年坑之后才心服口服。
2. 工作流和智能体：先分清这两个概念，架构才不会走偏
2.1 Anthropic 的定义其实很反直觉
很多人一听"智能体"就觉得是"让模型自己规划、自己决策、自己执行"，一听"工作流"就觉得是"比较低级的东西"。但 Anthropic 在笔记里的定义跟直觉恰恰相反：
- 工作流（Workflow）：通过预设的代码路径，来编排大语言模型（LLM）和各类工具。每一步做什么、什么时候做、结果给谁，这些都是开发者在代码里写死的。LLM 只负责完成单个步骤里的"生成"任务，不负责决定流程走向。
- 智能体（Agent）：由大语言模型动态决定自己的流程、使用哪些工具、按什么顺序执行，并且会基于环境的反馈不断调整行动，直到任务完成。流程的控制权在模型手里，而不在开发者手里。
我一开始觉得这个区分太简单了。但后来发现，正是这个简单区分，决定了你在工程上所有后续决策：要不要设计状态机、要不要做人工审批节点、怎么处理失败重试、怎么控制 token 成本、怎么做可观测性。工作流和智能体的架构成本完全不是一个量级。
2.2 用流水线和实习生来类比
如果你觉得上面的定义还是抽象，我用一个生活化的类比。
工作流就像工厂里的流水线：每个工位做固定的事，物料从 A 传到 B 再传到 C，顺序永远不会乱。你给流水线加一个"智能环节"，比如某个工位用 LLM 来写一段文案、做一次翻译，那它的本质还是一个可预测的、确定性的流程。它的优点是可测试、可控制、成本可预估；缺点是遇到流程里没定义过的情况，它不会自己绕路。
智能体则像一个能力很强但需要你来带的实习生：你给他一个目标，他会自己琢磨怎么拆解任务，遇到问题会翻工具书、会去查资料、会尝试不同的方法，甚至会在中途改变策略。他的优点是有很强的自主性，能处理没遇到过的情况；缺点是你不能完全预期他会走哪条路，需要花更多精力"带"他——这就是架构上的成本。
所以关键点来了：你不是在所有场景都想要一个"自主的实习生"，很多场景你只想要一条稳定可靠的流水线。Anthropic 的整篇笔记，本质上就是在帮你做这个判断。
2.3 为什么"能选工作流就不要选智能体"是一条黄金法则
这个观点说出来可能会被一堆 agent 狂热者吐槽，但它是工程经验的真实总结。
第一，工作流的失败模式可以预测。流水线上任何一环出了问题，你只需要排查那一个环节。而智能体一旦在某个中间步骤产生幻觉、误调用工具、或者陷入循环，排查的难度是指数级上升的——你面对的不再是一个线性流程，而是一棵可能不断分叉的决策树。
第二，工作流的成本更容易控制。每一步调用多少次模型、用多大的模型、总共消耗多少 token，基本是可以估算出来的。而智能体的 token 消耗取决于它自己决定思考多少轮、调用多少次工具，预算很容易失控。我见过一个"智能客服 agent"，理想情况下 2 轮对话能解决问题，模型偶尔抽风时会来回检索十几次，月底账单直接翻了三倍。
第三，工作流对延迟更友好。并行化、缓存、裁剪 prompt 这些优化手段，在确定性的流程里都好做。智能体的循环是动态的，你很难把"思考次数"压缩，因为那是模型自己决定的。
所以当你在设计一个系统时，你要问自己的第一个问题不是"要不要用 agent"，而是"我的任务路径是不是基本固定的"。如果答案是肯定的，老老实实选工作流；只有当你明确遇到了"需要根据不确定信息动态做决策"的任务，才有必要考虑 agent。后面我会详细拆解什么情况算"真正需要 agent"。
3. 五种工作流模式：Anthropic 给的最实用工具箱
3.1 这五种模式不是让你挑一个，而是让你组合
Anthropic 笔记里花了大量篇幅讲的，是五种常见工作流模式：Prompt Chaining（提示词链）、Routing（路由）、Parallelization（并行化）、Orchestrator-Workers（编排者-执行者）、Evaluator-Optimizer（评估者-优化者）。我一开始以为这是五种并列的方案，后来才领悟：它们是五种架构元素，可以在同一个系统里叠加组合。
这跟盖房子很像。你不会只用一个结构元素，你会同时用梁、柱、楼板。同样，在真实的 Agent 系统里，入口可能是 Routing，中间可能包含 Parallelization，最后输出前可能套一个 Evaluator-Optimizer 做质量把关。理解每个模式的本质，你才有能力组合出适合自己的方案。
我先用一个表把五种模式的要点列出来，再逐个展开讲适用场景和实现细节：
| 模式 | 核心思路 | 一句话适用场景 | 关键注意点 |
|---|---|---|---|
| Prompt Chaining | 大任务拆成 sequential 小任务，前一步输出喂给后一步 | 任务可以自然分阶段，每阶段用一个精简 prompt | 每步独立提高准确率；可单步重试 |
| Routing | 先分类，再分发给专门的 prompt 或流程 | 输入类型差异大，不同类别需要不同处理 | 分类本身可以用小模型省成本 |
| Parallelization | 多个 LLM 同时干活，或分块处理、或多方案投票 | 任务可并行、或需要多角度交叉验证 | 收益来自延迟降低和相互纠正 |
| Orchestrator-Workers | 一个中心模型拆任务，多个 worker 模型执行 | 复杂任务需要动态拆分成子任务 | 不要让中心模型决定它不理解的领域 |
| Evaluator-Optimizer | 生成器和评估器循环，直到质量达标 | 有明确质量反馈标准、能迭代改写的任务 | 评估标准必须具体，否则白费 token |
3.2 Prompt Chaining：把"一步登天"改成"步步为营"
Prompt Chaining 是我自己用得最多、也最适合大多数团队起步的模式。它把一个复杂的提示词任务，拆成多个顺序执行的子任务，前一个 LLM 调用的输出，成为后一个调用的输入。
举个内容生成的例子。假设你要做一个"产品介绍生成器"，一次性 prompt 让模型"写一篇高质量的产品介绍"，结果往往平庸：结构流于模板、卖点不突出、结尾没有号召力，模型还容易在一段长输出里犯逻辑错误。但如果你拆成三步：
- 步骤一：让 LLM 提炼产品的核心卖点、目标人群、用户痛点；
- 步骤二：让 LLM 基于这些素材写出正文初稿，prompt 只聚焦"结构清晰、信息准确"；
- 步骤三：让 LLM 担任"资深文案编辑"，审核初稿并改写开头和结尾。
每一步的任务边界都很窄，模型不需要"既要又要"，输出质量会明显上升。
为什么这样有效？因为每一步的 prompt 只有单一职责，模型的注意力能集中。而且工程上还有一个隐性好处：你可以针对某一步单独优化和重试。如果第三步的编辑效果不好，你可以只换第三步的 prompt，不用动整个链路。这在调试阶段的体验非常好。
我在做客户报告自动生成系统的时候，就用了四段链：数据整理 → 分析解读 → 报告撰写 → 格式润色。每一步一个 prompt 调用，整体准确率提升非常明显，尤其是第二步"分析解读"单独调整后，整条链的输出质量马上改观。这比让一个大 prompt 从头干到尾，可维护性强太多了。
3.3 Routing：让最该干活的模型，干它最擅长的活
Routing 是我特别推崇的一种"省钱模式"。它的核心思路是：先用一个分类器判断用户的输入属于哪一类，再把它分发给对应的专用流程。
这个分类器不一定非要用很强的模型。Anthropic 笔记里特别提到，简单分类任务用更小、更便宜的模型就足够。举例来说，一个客户支持系统的入口，可以先用小模型判断用户的问题是"账单相关"、"技术故障"还是"退换货"，然后分别转给三个不同的专业工作流去处理。
我实测过这个小模型方案的效果。用一个大模型做分类，和用一个小模型做分类，准确率差距在几个点以内，但成本可能差 5 到 10 倍。而且分类任务本身就是低上下文复杂度的任务，小模型完全足够。
Routing 也可以用在模型选择上。一类输入走 Claude 这类强模型，一类走轻量模型，一类甚至不需要 LLM 而直接用预设规则回答。模型不是越强越好，而是在每个环节里"够用且最优"。这句话我是在被账单教育过之后才记住的。
3.4 Parallelization：两条路走通并行化
Anthropic 笔记里把并行化分成了两种形态，这个分类我觉得非常实用。
第一种是Sectioning（分块并行）：把一个大任务切成几个独立的小块同时处理，最后聚合成一个结果。比如做内容分析时，把一本书拆成多个章节，每个章节用独立的 LLM 调用生成摘要，再让另一个 LLM 把所有摘要聚合成全书总结。这样做的好处有两个：一是快，多路并行让总延迟大幅下降；二是绕开了上下文窗口限制，不需要把整本书塞进一个上下文。
第二种是Voting（投票并行）：同一个任务让多个独立的 LLM 调用分别给出回答，然后选一个"最佳答案或达成多数共识"。这类似于让多个专家独立评审。我自己用的一个经验是，在代码审查场景下，用三个不同 temperature 设置的模型分别检查，再让一个模型综合它们的意见，能明显提高 bug 检出率。代价是多了三倍 token 和接近三倍的延迟，它更适合"质量优先、延迟不敏感"的场景。
我建议，如果你还没有并行化经验，先从 Sectioning 开始。它在工程实现上非常直观：拆任务、并发调用、聚合成最终结果。Voting 则更适合你已经有了稳定的评估标准，想让结果更鲁棒的场景。
3.5 Orchestrator-Workers：中心化拆解，但不做万能裁判
Orchestrator-Workers 是接近"智能体"感觉的工作流模式：一个中央的 Orchestrator（编排者）模型负责分析任务、拆解子任务、分发给多个 Worker（执行者）模型，Worker 回来后再由 Orchestrator 汇总结果。
它和 Parallelization 的区别在于：Parallelization 是提前确定好拆什么、怎么并的；Orchestrator 则是由模型动态决定要不要拆、拆成什么。所以它的灵活性和复杂度都比前面的模式高。
使用 Orchestrator-Workers 最容易犯的错，我在团队里见过不少次——让 Orchestrator 承担了它不理解的判断。比如中心模型是通用的对话模型，你却让它去评估医药领域的子任务结果，那它根本判断不了 Worker 干得好不好。我的做法是：给 Orchestrator 提供明确的"任务描述模板"和"子任务验收标准"，让它专注于任务管理，而不是去充当领域专家。
另外还有一个工程细节：Orchestrator 同时发起的 Worker 数量不宜太多。一方面并发调用会受 API 限流影响，另一方面子任务过多时，Orchestrator 汇总信息的质量会下降。我一般控制在 5 到 10 个以内，再多就考虑分层分组。
3.6 Evaluator-Optimizer：把"写得好不好"变成一个可循环的题目
Evaluator-Optimizer 是我认为最容易被忽略、但收益极明显的一种模式。它的结构是：一个 LLM 负责生成答案，另一个 LLM 负责评估这个答案的质量，如果评估不过关就把反馈传给生成器进行新一轮改写，直到通过或达到迭代上限。
它的适用场景有两个特征：一是任务有明确的"好坏标准"，二是结果可以反复迭代修改。比如翻译、学术写作、营销文案、代码优化，这些任务天然适合这种"生成—评估—再生成"的循环。
但这里有个大坑：评估器的 prompt 如果不够具体，整个循环就是在空转烧钱。你让它评估"这段文案好不好"，它可能永远觉得"不错，还可以更好"，然后无限迭代。我自己写评估 prompt 时的经验是，把评估维度切成可打分的项，比如：
- 事实准确性：信息是否有据可依；
- 结构完整性：是否包含背景、进展、风险、建议四大部分；
- 表达精炼度：是否有冗余表达；
- 目标适配度：是否针对目标读者做了措辞调整。
每个维度给出明确说明和评分标准后，评估器才能给出真正有用的反馈，而不是模糊的"还可以"。同时要设置最大迭代次数，一般 3 轮就够，再多性价比就非常低了。
提示：Evaluator-Optimizer 在 Anthropic 原文里是一个典型工作流，但我在实践中发现它可以作为"质检模块"嵌入到其他工作流里，比如在 Prompt Chaining 的最后一步加一个评估环节，质量立刻有改观。它不一定非得独立存在。
4. Agent 模式什么时候真正上线：当"灵活性需求"压过"稳定性需求"
4.1 判断的核心标准：路径可控性
看完了五种工作流，你可能会问：那到底什么时候才需要上真正的 Agent？Anthropic 笔记里的判断标准，我用一句话总结：当你在设计系统时无法提前穷举出所有执行路径，并且系统需要在执行过程中根据环境反馈实时调整行动路径时，你才真正需要 Agent。
什么是"无法提前穷举路径"？我用实际例子说明。
- 一个文档摘要系统：输入是文档，输出是摘要。它可能有长有短，但处理路径基本固定——不需要 Agent。
- 一个小红书文案生成器：输入产品信息，输出种草文案。路径也固定——不需要 Agent。
- 一个自动管理任务的个人助理：你告诉它"帮我安排明天的会议，顺便整理会议资料发给参会人，还要查一下明天交通状况"。它能自己规划步骤、调用日历工具、调用搜索工具、遇到冲突自己调整——这才需要 Agent。
第一个和第二个任务，路径是可预知的，你穷举也就是那么几种情况。第三个任务则完全不一样，用户指令千变万化，外部环境（日历冲突、搜索结果的更新）也在变化，系统的路径必须动态生成。
4.2 Agent 的核心：模型驱动的"感知—决策—执行—观察"循环
Agent 不是"一个更聪明的模型"，而是一种运行时架构。这个架构的核心是一个循环：
- 感知：把当前任务、环境信息、可用的工具列表，一起打包给 LLM；
- 决策：LLM 决定下一步采取什么行动（调用哪几个工具、或用哪个工具的参数）；
- 执行：系统执行这个工具调用，拿到真实的结果；
- 观察：把工具结果以文本形式回传给 LLM，更新它的上下文；
- 回到第 2 步，直到模型判定"任务完成"或触发终止条件。
Anthropic 笔记里把 Agent 描述为"处理开放式问题的扩展系统"——它的流程不是预先画好的，而是在运行时被模型自己"画"出来的。工程上，这要求你的架构具备几个基础能力：
- 工具调用（Function Calling）：模型能输出结构化的工具调用指令，而不是光说"我建议你去做某事"；
- 工具解析与执行层：系统能把模型的输出解析成真实的 API 调用，并处理好参数校验和错误返回；
- 循环控制器：管理"调用模型 → 执行工具 → 结果回填 → 再调用模型"的循环，并设置最大迭代次数等终止条件。
这也是为什么热词里会出现"识的llm智能体自主容错控制:构建可靠ai系统的工程实践"——Agent 的可靠，很大程度上不是一个"聪明模型"能保证的，而是由循环控制、错误恢复、工具健壮性这些系统工程决定的。
4.3 工具层的设计决定了 Agent 的天花板
我见过不少团队 Agent 效果差，第一反应是"换个更强的模型"，其实问题往往出在工具设计上。Anthropic 笔记也强调了工具是 Agent 连接世界的触角。
工具设计有四个我总结出来的关键点：
第一，工具的描述要极其清晰。模型是通过你的工具 description 来决定什么时候调用、参数传什么的。你写"获取天气信息"，模型会不知道能查城市列表；你写"根据城市名获取未来 7 天天气预报，参数 city 为中文城市名，如'北京'"，模型就非常明确。
第二，工具的输入要做严格校验。千万不要把模型输出的参数直接透传给后端接口。模型可能输出一个不存在的城市名，也可能把"温度"字段传给了"城市"字段。在前端做一层校验和标准化，能省掉大量脏数据问题。
第三，工具的执行要幂等或可重试。Agent 在循环中可能因为超时而重试同一个工具调用，如果你的工具不是幂等的（比如"创建订单"接口），就会造成重复操作。我在实际项目里对这类工具，都会要求后端在参数里加一个幂等键（idempotency key），保证同一次任务的重试不会产生副作用。
第四，关键操作要设置权限护栏。完全信任模型自主执行高影响操作，是在给自己埋雷。我的做法是在工具层做"人工确认"钩子：标记工具是否需要人工审批，如果涉及发送邮件、付款、删除数据等操作，系统会先暂停循环，把待确认信息发给管理员。这个"人在环路"的设计，在 Anthropic 笔记里也被多次强调，它是 Agent 系统里最重要的安全网，没有之一。
4.4 自主容错控制：Agent 不是"永不失败"，而是"失败后可恢复"
这里延伸一下热词里提到的"自主容错控制"问题。我在做生产级 Agent 时发现，容错不是"让模型更准"，而是在系统层面建立失败恢复机制。
- 工具调用失败：模型请求的 API 超时或返回错误，系统应该把错误信息作为 observation 回传给模型，让模型自己决定是重试还是换一个替代方案。而不是简单地让整个循环崩溃。
- 模型输出格式非法：模型偶尔会返回不合 JSON 规范的输出，解析失败不等于任务失败。我的做法是给循环控制器加两次重试机会：把"我无法解析你的输出，请按指定格式重新生成"作为反馈再次请求模型，通常第二次就能修正。
- 死循环保护：无论模型多么"自主"，都要设置最大循环次数（比如 20 轮）和最长执行时间。到达上限强制终止，而不是让它无限烧 token。这个简单规则，能帮你避免很多噩梦。
有一句话我在团队里反复讲：Agent 生产化的过程，就是不断把"模型可能搞砸的地方"用系统机制兜住的过程。如果你只是把一个模型裸奔在循环里，它迟早会在意想不到的地方翻车，而且翻车姿势五花八门。
5. 成本、延迟与"伪 Agent"：架构选择的现实约束
5.1 每一个决策点，都是真金白银
Agent 比工作流"智能"，但每一个"智能"都有价格。不是钱的问题，是 token 消耗和延迟的问题。
Anthropic 笔记里没有回避这一点。每个 Agent 决策循环都意味着一次完整的 LLM 调用，而每次调用都要消耗上下文 token——包括系统 prompt、工具描述、历史消息、工具返回结果，这些都会累积。一个看似"最终只调用 3 次工具"的 Agent，实际可能因为上下文越来越长，消耗了相当于 10 次基础的 token 量。
我给你一个大概的体感估算：一次简单的工具调用类 Agent 任务，token 消耗可能是同等功能工作流的 5 到 20 倍。20 倍是什么概念？如果你的业务每天有 10 万次请求，成本差异就会让人非常肉疼。
延迟也一样。工作流可以做并行、可以做缓存，Agent 必须串行决策——思考、调工具、看结果、再思考。一个 3 步工具调用就是 4 次模型往返，延迟通常在几秒到几十秒之间，跟你平时用工作流做单次问答的体感完全不同。
所以架构设计的本质其实是一个成本预算题。你要问自己：这个任务的决策点上，我付出的额外 token 和延迟，换来的"自适应能力"是否值得？大多数情况是不值得的。
5.2 很多"Agent"，其实是披着 Agent 外衣的工作流
我观察到一个很有意思的现象：市面上很多标榜"智能体"的产品，拆开看都是固定流程加几个 LLM 调用节点。它们叫 Agent，但架构上就是 Prompt Chaining 或者 Routing。
这本身不是坏事，甚至可能是正确选择。我说的"伪 Agent"不含贬义，反而是一个务实判断：如果一个系统能用工作流可靠地实现你要的效果，那它就是很好的系统，你不需要去追求"真正的 Agent"这个标签。
判断一个系统是"真 Agent"还是"伪工作流"，可以参考三个指标：
- 决策点数量：系统里有几个地方允许模型自主选择下一步动作？如果只有一个结果分支判断（if 条件），那是工作流；如果每个循环里模型都能选择 5 个以上工具之一并自行决定顺序，那是 Agent。
- 任务多样性：系统处理的输入变化是否足够大？固定模板化的输入，不需要 Agent；开放式指令，才需要 Agent。
- 失败重试的自由度：出错时，系统只能走预设的失败分支，还是能动态换一条策略？前者是工作流，后者才接近 Agent。
我自己做系统设计时，会把"用工作流实现 80% 场景 + 少数复杂分支交给 Agent"作为一个默认思路。先把主干跑稳，再在真正需要灵活性的节点引入 Agent，这是成本最可控的路径。
5.3 Agent 也不是单体：控制面与执行面的分离
热词里出现了"分布式架构"和"微服务架构"，这两个词背后其实也关系到 Agent 系统怎么落地。
Agent 在架构上不是"一个大模型包办一切"的单体。把一个 Agent 系统放到微服务的语境里看，它天然分成了两大部分：
- 控制面（Controller）：负责决策的循环控制器，管理状态、工具调度、终止条件；
- 执行面（Executors）：被控制的工具服务，可能是文档检索服务、数据库服务、外部 API 网关、内部业务系统。
我推荐这个架构思路的原因很简单：如果你把 Agent 的所有逻辑都塞在同一个服务里，后续扩展和排查会非常痛苦。控制面和执行面分离后，你可以单独扩缩容工具服务、单独做缓存、单独监控每个工具的延迟和错误率，这些都是生产环境必须的。
在具体实现里，控制面可以直接调用后端微服务的内部接口。工具既可以是 HTTP 接口，也可以是 RPC 调用。关键是，每个被暴露给模型的工具都要有清晰的契约——名字、描述、参数 schema、返回结构，这相当于给模型做了一套"API 目录"，让它能正确选择。
另外，关于"平台搭建的智能体与用 Python 搭建的智能体有什么不同"这个问题——本质上也落在架构层面。平台通常把控制面的实现封装成了可视化编排，你又快又省力，但定制边界受平台约束；用 Python 从零搭，控制逻辑完全在自己手里，改造成本高但灵活度大。我的建议是：demo 和验证阶段用平台，快速试错；有明确规模预期后，再迁到代码自建，你才能真正掌控成本、延迟和故障排查。
6. 从 Demo 到生产，我踩过的几个坑和应对办法
Anthropic 笔记讲了原则和模式，但有一条它没有展开讲：任何 Agent 或者工作流架构，从 Demo 到生产之间的距离，往往比从想法到 Demo 更远。最后我用自己实际踩过的坑作为收尾，这些经验都是原文里没有的。
6.1 可观测性与调试：没有 trace，等于断案没有证据
Agent 系统不像传统的后端接口，返回个 4xx、5xx 就能定位问题。它的问题可能出在：模型理解错了用户意图、工具选择不当、参数传错、中间某一步的返回内容误导了模型、上下文太长导致模型忘了最初目标。
要应对这些，你需要在第一天就把完整的 trace 体系搭起来。每一步 LLM 调用的输入和输出、每次工具调用的请求和响应、每一步的 token 数、延迟、模型的推理过程（如果有的话），全部落盘。我通常会把这些结构化地存储下来，在调试页面上按 session 查看树状 trace。
没有这套体系，Agent 出问题你只能靠复现和猜，效率极低。Agent 系统生产化的第一优先级，不是模型调优，而是做好可观测性。无法观测的系统，就无法优化，也无法信任。
6.2 评估不是"肉眼看好坏"，而是 golden set 回归
传统开发有单元测试，LLM 应用没有，这是很多人觉得 Agent 工程"玄"的核心原因。我的做法是建立一套回归评估集（golden set）：
- 收集历史上真实用户输入和期望输出，做成几十上百条的固定测试集；
- 每次修改 prompt、工具或流程，都跑一遍测试集；
- 用 LLM 作为 judge，按固定评估标准给每个输出打分，对比工具箱前后的得分差异。
这比"人工看一眼效果不错"可靠太多。我团队里现在改任何一个 prompt，都要先跑回归测试再上线。哪怕判断比较主观，一个相对稳定的分数趋势也好过拍脑袋。
6.3 让模型做更少的决策，而不是更多
最后一条是认知层面最大的转变。在我早期设计 Agent 时，总希望模型"更聪明一点"，多自主判断一些事情。后来的教训是：模型越少做决策，系统越稳定。
具体实践是：把那些可以通过规则、代码、状态机实现的部分，全部用代码实现，绝不交给模型。比如"任务执行完要不要进入人工审核"这个判断，你可以让模型决定，但更好的做法是：定义好什么级别的影响需要人工审批，用代码判断；只有"面对未定义情况时怎么处理"这类真正需要语义理解的判断，才留给模型。
Anthropic 笔记里有一句话给我的印象特别深：不要为了增加"智能"而增加复杂度。一个好的系统，应该是智能恰到好处地出现在它该出现的地方，其他地方则用确定性逻辑来兜底。这个理念我执行得越彻底，系统就越可靠，Debug 也越轻松。
落到我个人经验上，现在设计任何一个智能体系统，我都会先画一张表：左边列任务步骤，右边标"代码逻辑"还是"模型决策"。如果模型决策点超过 30%，我会停下来重新审视——是不是可以通过更好的拆分、更明确的工作流，把一部分决策转移到确定性逻辑里。这不是反对 Agent，而是把 Agent 用在刀刃上。
希望这篇文章能帮你把 Anthropic 的架构笔记真正用到自己的项目里。如果读完之后你只记住一件事，就记住那句话：先想清楚任务路径是固定的还是开放的，再决定用工作流还是智能体；而无论选哪种，把工程兜底做扎实，永远比追求"更智能"更重要。
