Agent 设计模式全解析：从工作流到智能体的 9 种架构怎么选

用大模型构建应用，绕不开一个架构决策：流程控制权交给代码，还是交给模型。《System Design Newsletter》作者 Neo Kim 在 4 月的一期通讯里，把这个决策拆成了 9 种 Agentic Design Patterns（智能体设计模式）：4 种由代码控制流程的工作流模式，4 种把决策权交给模型的智能体模式，外加一个负责可靠性兜底的评估-优化循环。这套分类与 Anthropic 那篇被广泛引用的《Building Effective Agents》一脉相承，但补充了大量真实产品案例和失败模式分析。本文完整梳理这套框架，并补充国内落地的参考信息。

先回答”要不要用”：大多数任务连工作流都不需要

原文开篇就泼了盆冷水：大多数任务不需要 Agent（智能体），甚至不需要工作流。默认方案应该是能跑通的最简单架构，只有在它确实失效之后才升级。

起点是对 LLM 的一次直接 API 调用。这一层能覆盖的任务比多数人预期的多：摘要、分类、信息抽取、改写、翻译，以及规格清晰的代码生成。很多团队跳过这一层跳得太快了。

从直接调用API到多智能体的架构升级阶梯 — 图1：架构升级阶梯——默认停在能跑通的最低一级，失败了再上爬（据原文示意图重绘）

往上一级是工作流模式。升级的条件是：任务包含多个步骤，且每一步的专注处理确实能改善输出。步骤之间要设置校验门（validation gate）——在结果传给下一步之前先验证它是否正确。工作流的判定特征只有一句话：系统运行之前，你能把每一步都写下来。控制流归代码，细节归模型。

再往上才是智能体模式，适用于步骤的数量和类型在运行前无法确定的场景。原文举了个客服的例子：用户要取消订单，Agent 事先不知道自己需要查退款政策、查物流状态，还是转交人工——下一步取决于上一步查到了什么。判断该切换的信号也很具体：处理错误和异常的代码比干正事的代码还多，或者你在不停地为模型遇到的意外情况打补丁。只要还能在运行前写出全部步骤，就留在工作流。

原文还点了一个常见误判：原型做到七八成，很多人就认定是架构不够用了。实际上问题通常出在提示词质量或者缺校验门上。升级架构的前提是简单方案已经实际失败，而不是它”感觉受限”。

工作流模式：代码控制流程

这一组的共同点是代码决定步骤、顺序和检查点，LLM 只负责执行每一步的具体内容。

1. 提示词链（Prompt Chaining）

把任务拆成一串 LLM 调用，每次调用接收上一步的输出，中间用校验门把关。搭过 CI/CD 流水线的人对这个结构不会陌生：编译、代码检查、测试、打包，每一步通过了才走下一步，测试挂了整条流水线就停。

提示词链模式：多次LLM调用之间用校验门把关 — 图2：提示词链——每步之间设校验门，未通过即终止（据原文示意图重绘）

法律合同审查是典型应用：先从合同里抽取全部条款，再给每条按风险分级，最后把高风险条目汇总成摘要交人工复核。Thomson Reuters 的 CoCounsel 和 Robin AI 跑的都是这类流水线的变体——每一步一个目标收窄的提示词，配一道校验门。

代价有两条：延迟随步骤线性增长，五步就是五个来回；错误会向后传导，第二步分错了条款，后面三步处理的就全是脏数据。校验门能提前拦截失败，但它只能拦住你事先写得出判断条件的那部分。

2. 路由（Routing）

先对输入分类，再把它分发给对应的处理器——不同的提示词、不同的模型，或者不同的子工作流。类比是医院分诊台：前台看症状把病人分给对应科室，前台不看病，医生也不管挂号。

Sierra AI 用这个模式在 15 个以上的模型之间做分发：分类任务给一个模型，工具调用给另一个，回复生成再给第三个。客服平台 Intercom Fin 则按用户意图和情绪路由，决定交给 AI 还是转人工。省钱的逻辑内建在模式里：简单请求走便宜快速的模型，复杂请求才动用昂贵的大模型。

风险可以浓缩成一个词：误分类。复杂问题分给了便宜模型，答案质量差；简单问题分给了贵模型，纯属浪费。路由器是整个系统的单点故障，它的准确率就是系统的上限。

3. 并行化（Parallelization）

并行化在 LLM 场景下有两个变体，解决的是不同的问题。

切分（Sectioning）：把任务拆成独立的部分同时跑，最后合并结果——像一支施工队，电工、水管工、木工在同一栋楼里各干各的。GitHub Advanced Security 就是这么工作的：CodeQL 和 Snyk、Semgrep 等第三方工具并行扫描同一个 Pull Request，各自独立产出安全告警。

投票（Voting）：同一个任务用不同提示词跑多遍，再合并答案——像陪审团，每个人看同样的证据独立给出意见，最后集体裁决。典型用法是安全审查：三个提示词分别分析同一段代码改动，两个以上都报告问题才标记。跑多遍当然更贵，但误报会明显减少。

一句话区分：切分是每人干不同的活，投票是每人干同一件活。成本随并行分支数成倍增长；更麻烦的是部分失败——某个分支挂了，是重试、带着剩余结果继续，还是整体失败？这必须在设计阶段就定下来，没有通用答案，选错的代价很高。

4. 编排者-工作者（Orchestrator-Workers）

前三种模式的步骤都是预先定好的，这一种不同：由一个中心 LLM 在运行时把任务拆成子任务，分派给各个工作者 LLM，再合并结果——子任务是什么，事先并不知道。原文的类比是建房的总承包商：开工前不可能列全所有分包商，水管工发现结构问题，承包商就得临时请结构工程师进场，工作计划随着项目暴露的新问题不断调整。

Cursor 的 agent mode 是现成的例子：一个 Agent 加测试，另一个更新文档，第三个重构共享工具代码。你信任的不再只是”模型把活干好”，而是”模型自己判断有哪些活要干”。

要注意它虽然用了多个 LLM，但不算多智能体架构——中心 LLM 始终掌控全局。真正的多智能体系统里，Agent 之间可以直接互相调用，控制权可以转移。编排者自身的失败模式有三种：忘掉原始目标、把简单任务拆得过碎，以及工作者干完了它却合并不过来，自己成了瓶颈。

四种模式的梯度很清楚：链和路由便宜且可预测，运行前就知道会发生什么；并行化省时间但费钱；编排者-工作者能处理无法预判的问题，代价是引入了同样无法预判的失败模式。原文的判断是：多数生产系统做到并行化就足够了。

智能体模式：模型控制流程

切到智能体模式后，你不再定义步骤和顺序，改为定义约束：模型能用哪些工具、最多花多少钱、什么时候必须停。模型自己观察、推理、决定下一步。

工作流模式定义路径，智能体模式定义边界 — 图3：两类模式的分野——工作流定义路径，智能体定义边界（据原文示意图重绘）

需要说明的是，原文从这里进入付费墙，只完整给出了第一个模式的定义：反思（Reflection），即 LLM 生成输出后审查自己的工作，再修复发现的问题。其余几种模式原文仅在目录中列出，以下框架按业界公开资料（Anthropic《Building Effective Agents》、ReAct 论文等）补全，供参考：

工具使用（Tool Use）：由模型自行决定何时调用哪个外部工具——查数据库、调 API、执行代码——并根据返回结果决定后续动作。
ReAct：推理（Reasoning）和行动（Acting）交替进行的循环，模型每走一步都先写出思考再执行动作，观察结果后进入下一轮，是目前多数 Agent 框架的默认执行方式。
规划（Planning）：先让模型把目标拆成一份完整计划，再逐项执行，执行中可根据实际情况修订计划，适合步骤多但相互依赖强的任务。
评估器-优化器（Evaluator-Optimizer）：一个模型生成、另一个模型评估，不合格就带着反馈重新生成。原文把它单独列为可靠性层，强调必须配上迭代次数上限和成本控制，否则循环本身会失控。

落地参考：几个原文没展开的问题

校验门具体怎么写？原文反复强调校验门却没给实现。常见做法有三档：规则校验（正则、长度、枚举值检查，零成本但覆盖有限）、结构校验（约束输出为 JSON Schema 并做格式验证，拦截结构性错误）、模型评审（LLM-as-judge，用另一次调用给输出打分，成本最高但能判断语义质量）。生产系统通常三档叠着用，便宜的放前面。

路由模式在国内的适配空间更大。国产模型的价格梯度比海外更陡——DeepSeek-V3 这类模型的调用成本只有旗舰推理模型的零头，简单请求分流给它们的节省比例相当可观。框架层面，LangGraph、Dify、字节 Coze 都能直接搭出文中的链、路由和编排者结构，不需要从零手写。

最容易踩的坑是把 Agent 当默认起点。照原文的升级阶梯反着走——一上来就上 Agent 框架——会同时放大三个问题：token 消耗不可控、调试时无法复现执行路径、效果无法归因。对刚起步的团队，提示词链和路由两种模式的投入产出比最高，出问题也查得清。想看一个循序渐进的升级实例，可以参考站内的《AI Agent 搭建实战：从手动排障到全自动运维的十步演进路线》，其演进路线与本文的升级阶梯一致。

原文发布于 Substack（newsletter.systemdesign.one），国内网络环境无法直接访问，完整版需要付费订阅；免费可读的部分已覆盖全部四种工作流模式的细节。想继续深入的话，Anthropic 官网的《Building Effective Agents》一文免费公开，框架高度重合，可以作为替代读物。