每一个运行中的 AI Agent，底层都依赖以下 9 种架构模式之一。

大多数 AI 开发者遇到的瓶颈，并不是技术能力不足，而是架构模式选择不当。

同一个 Agent 循环，处理简单任务时可能表现优异；但当任务复杂度上升时，它可能变得成本高昂、脆弱且难以调试。更关键的是，并不存在一种能通吃所有场景的"万能架构"。

从简单的"思考→行动→观察"循环，到多 Agent 协作、批评、委派和路由的复杂系统——把一个 Agent 连接起来的方式，本质上只有 9 种。

多数开发者只掌握其中一两种，跑通后就止步不前。问题恰恰从这里开始：选错模式意味着不必要的 API 调用、失控的循环、浪费的 Token，或者一个看似完美但经不起真实测试的系统。

这篇文章不做抽象的架构图，而是把 9 种模式逐一讲透：它们做什么、何时有效、何时失效、你该在什么时候切换架构。

这份清单的来源

Anthropic 的技术报告《Building Effective Agents》为开发者提供了一个实用起点：一组可复用的 AI 系统构建模式，从简单的 Prompt 链到更自治的 Agent。

但真正有意思的是后续发展。随着 Agent 系统日益复杂，开发者开始探索多 Agent 之间的协作方式——让它们互相委派任务、评估结果、共享工作负载。

于是我们整理了这 9 种值得深入了解的模式。

你不需要全部背诵，更不应该全部用上。真正的核心能力在于：知道每种模式解决什么问题——以及准确识别出你当前的架构何时已经不再适用。能让你的第一个 Agent 跑起来的架构，恰恰也可能成为第十个 Agent 失败的原因。

Workflow vs Agent：这个区别会改变一切

在深入 9 种模式之前，有一个区分比任何其他区分都重要。

Workflow 按照你预先设定的路径执行。下一步做什么由代码控制，而非模型决定。Prompt chaining、Routing 和 Parallelization 都属于 workflow。它们可预测、易于调试、运行成本更低。

Agent 在执行过程中自行决定路径。模型会根据刚观察到的结果，自主决定下一步行动。ReAct、Reflexion 和 Orchestrator-workers 都属于这一类。

两者没有绝对优劣。当步骤明确时，workflow 占优；当步骤无法提前预知时，Agent 才更有价值。选错类型，是这份清单里最常见的错误。

1. ReAct：思考、行动、观察、循环

这是最基础的 Agent 循环。模型先推理该做什么，执行一个动作，观察结果，再基于新信息重新推理。

ReAct 来自 Shunyu Yao 等人在 2022 年发表的研究论文。至今它仍是几乎所有单 Agent 系统的默认起点——原因很简单：它有效且易于实现。

适用场景：30 步以内的通用任务，推理与工具使用交替进行的场景。

2. Reflexion：会自我反思的 Agent

Reflexion 在 ReAct 循环之上增加了一个步骤：每次尝试后，Agent 会写一段简短的自我批评笔记，把经验带入下一次尝试。

这个模式来自 Noah Shinn 等人 2023 年的论文。它每步额外增加一次模型调用，所以比纯 ReAct 更慢、成本更高，但能显著减少重复错误。

适用场景：Agent 反复犯同类错误的任务，尤其是编程和数学推理。

3. Prompt Chaining：流水线

把大任务拆成顺序执行的小步骤，每一步的输出成为下一步的输入。

你可以在任意两步之间加入检查点，尽早发现错误，避免在后续链路中传播。

适用场景：步骤清晰且固定的任务，比如"先写大纲→规则检查→按大纲写初稿"。

4. Routing：接待员

一个前置步骤读取请求，将其分发到合适的专家模块。调度器本身不做复杂处理。

典型用法是把简单请求分配给快速低成本的模型，把复杂请求分配给更强但更慢的模型。仅此一项决策，规模化后就能节省可观成本。

适用场景：可清晰分类、且不同类别需要不同处理方式的请求。

5. Parallelization：并行处理或投票

同时运行多个模型调用，而非顺序执行。两种形式：Sectioning 把大任务拆成独立子任务；Voting 对同一任务运行多次并对比结果。

适用场景：彼此独立、无依赖关系的子任务，或需要通过多次运行提升置信度的情况。

6. Orchestrator-workers：项目经理

主 Agent 先理解任务，动态拆分为更小的子任务，分发给专门的 Worker Agent，最后整合结果。

与 Prompt Chaining 不同：Chain 的步骤是预设固定的，而 Orchestrator 在运行时动态决定如何拆分。Coding Agent 就是典型案例——它无法提前知道哪些文件需要修改，因此在运行时判断并分配工作。

适用场景：复杂任务，且开始前无法预测会拆出哪些子任务。

7. Evaluator-optimizer：作者与编辑

一个 Agent 生成初稿，另一个 Agent 按标准评分，前者根据评分修改，循环直到通过。

这就像作者与编辑的协作：写初稿、给反馈、修改、重复，直到真正准备好。它能发现单次执行容易遗漏的问题，尤其在准确性和合规检查方面。

适用场景：对输出质量有严格要求的场景——代码审查、合规检查、法律或金融写作。

8. Graph Orchestration：地铁线路图

不是直线 Chain，而是把 Agent 和步骤作为图节点，通过预定义的路径连接，包含循环和分支。你可以精确追踪每次请求走了哪条路径。

像 LangGraph 这样的框架内置了这种模式。当需要精确调试"到底发生了什么"时，这是首选方案。

适用场景：带条件逻辑的生产系统，可调试性优先于简单性。

9. Swarm：无中心协作

多个 Agent 以平等身份协作，没有中央调度者。它们读写一块共享白板，每个 Agent 都能更新，就像团队在共享白板上贴便签。

这是清单中风险最高的模式。没有监督者将行为拉回目标，Agent 可能偏离方向或陷入空转循环。必须对运行时长设置严格限制。

适用场景：探索性工作，如早期研究或头脑风暴；当你尚不清楚如何拆分任务时。

组合使用：生产级 Agent 的真实形态

没人会只用一种模式就上线产品。真实系统通常叠加两三种模式。

以文档审查工具为例：Routing 先对进入的文档分类（合同、政策更新、内部备忘录），Parallelization 把长文档按部分并行处理，Evaluator-optimizer 在交给人工前做质量检查。三种模式各司其职，共同组成一个系统。

这就是大多数生产级 Agent 系统的真实形态：不是某个聪明的单一架构，而是几个简单架构各司其职。

从小处开始，按需增加复杂度

有一条建议比任何单独的模式都更重要：先构建最简单的版本。

大多数团队在单个 ReAct Agent 还没触碰到极限时，就直接跳到了多 Agent 系统——这是本末倒置。

在实践中测量它具体在哪里失效，然后只添加能解决那个特定弱点的一种模式，不要多加。一个由三种精心挑选的模式构成的系统，几乎总是比为了炫耀而堆砌全部 9 种模式的系统更强大。