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生成器和评估器循环直到质量达标有明确质量反馈标准、能迭代改写的任务评估标准必须具体否则白费 token3.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 判断的核心标准路径可控性看完了五种工作流你可能会问那到底什么时候才需要上真正的 AgentAnthropic 笔记里的判断标准我用一句话总结当你在设计系统时无法提前穷举出所有执行路径并且系统需要在执行过程中根据环境反馈实时调整行动路径时你才真正需要 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 的架构笔记真正用到自己的项目里。如果读完之后你只记住一件事就记住那句话先想清楚任务路径是固定的还是开放的再决定用工作流还是智能体而无论选哪种把工程兜底做扎实永远比追求更智能更重要。 工作流与智能体：Anthropic架构笔记的LLM系统设计实践
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生成器和评估器循环直到质量达标有明确质量反馈标准、能迭代改写的任务评估标准必须具体否则白费 token3.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 判断的核心标准路径可控性看完了五种工作流你可能会问那到底什么时候才需要上真正的 AgentAnthropic 笔记里的判断标准我用一句话总结当你在设计系统时无法提前穷举出所有执行路径并且系统需要在执行过程中根据环境反馈实时调整行动路径时你才真正需要 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 的架构笔记真正用到自己的项目里。如果读完之后你只记住一件事就记住那句话先想清楚任务路径是固定的还是开放的再决定用工作流还是智能体而无论选哪种把工程兜底做扎实永远比追求更智能更重要。