每个构建 AI Agent 的团队都会碰到同样的瓶颈。
开始时只是一个提示词加几个工具。
还能用。
然后需求增加了。更多的边缘情况。更多的团队。更多的风险。
突然间你的 "Agent" 变成了一个 3,000 字长的系统提示词，试图同时完成五项工作。
解决方案不是更多的提示词工程。
而是选择正确的模式。
这里有 15 个所有生产级 Agent 系统都基于的模式——以及每种模式的具体适用场景。
在选择模式之前
并非每个任务都需要一个 Agent。
当一个任务满足以下条件时，才需要 Agent：
→ 单次模型调用无法产生可靠结果
→ 模型必须在运行时在工具或数据源之间做出选择
→ 任务需要规划、验证或迭代优化
→ 工作流中存在无法硬编码的真实不确定性
当输入到输出的路径可预测时，任务通常不需要 Agent。
摘要、分类、简单提取、模板化生成。
这些任务作为直接的模型调用更快、更便宜、更可靠。
将它们包装在 Agent 中只会增加延迟和故障点，而没有任何好处。
模式 1 — 单 Agent
最简单、最常用的起点。
一个模型、一个系统提示词、一组有限的工具。
模型决定调用哪个工具，观察结果，并持续进行直到获得足够的信息来回答。
实际案例： 一个客户支持 Agent，可以查询订单状态、检查物流信息，如果无法解决问题则创建工单——只需 2-3 个工具和一个明确的任务。
适用场景： 任务定义明确，工具集很小，且单个 Agent 能够掌握完整上下文而不会混淆。
失效场景： 当你不断添加工具，系统提示词超过一页时。这表示你需要换一种模式，而不是更长的提示词。
模式 2 — 多 Agent 顺序执行
专业化的 Agent 按照固定顺序运行。每个 Agent 的输出作为下一个 Agent 的输入。
实际案例： 一个合同审查流程——一个 Agent 提取义务条款，下一个识别风险，第三个为采购部门起草摘要。顺序从不改变。
适用场景： 工作流具有清晰、可重复的阶段，并且每个阶段都能精确地产生下一个阶段所需的内容。
失效场景： 当执行的顺序需要根据处理过程中发现的情况而变化时。顺序管道假设路径是固定的——如果不是，你需要更动态的方案。
模式 3 — 多 Agent 并行执行
独立的子任务同时运行，然后将结果整合到一个视图中。
实际案例： 凌晨 2 点的生产事故。三个 Agent 同时调查日志、指标和最近的部署——而不是一个接一个——因为在故障期间每一分钟都很重要。
适用场景： 子任务真正独立，且速度至关重要。
失效场景： 当任务实际上依赖于彼此的结果时。强制将有依赖关系的工作进行并行执行只会造成竞态条件和不完整的上下文。
模式 4 — 循环
重复执行一系列步骤，直到满足退出条件。
实际案例： 一个数据清洗 Agent，它会分析杂乱的 CSV 数据，提出清洗方案，检查是否通过质量标准，如果不通过则重试——最多尝试固定轮次。
适用场景： 任务需要多次尝试，并且你可以定义一个清晰、可检查的停止条件。
失效场景： 当没有可靠的退出条件时。没有退出条件，你将面临失控的成本和一个可能永远无法终止的系统。
模式 5 — 审查与批评
一个裁判 Agent 审查另一个 Agent 的输出，提出批评意见，并给出具体、可操作的反馈。
实际案例： 一份生成的报告在被人工审阅之前，先由一个独立的 "评论家" Agent 进行审查，标记出薄弱的论点、缺失的证据或不清晰的段落。
适用场景： 质量比速度更重要，并且你希望将第二种意见内置于系统中，而不是事后附加。
失效场景： 当批评 Agent 与生成 Agent 存在相同的盲点时。基于相似假设训练的审查者无法发现相同的错误。
模式 6 — 迭代优化
一个带有质量分数阈值的反馈循环。生成器不断优化直到达到标准。
实际案例： 一个营销文案生成器，根据品牌准则评估自己的草稿，并持续重写直到达到最低质量分数——不仅仅是一次通过/失败的检查，而是逐级改进。
适用场景： 输出质量确实可变，且 "足够好" 有一个可衡量的阈值。
失效场景： 当评分函数模糊或可被操控时。如果模型可以在没有实际改进的情况下提高自己的分数，那么这个循环只是在浪费 token。
模式 7 — 协调器
一个中央路由 Agent 根据实际请求内容将任务分发给专门的 Agent。
实际案例： 支持工单被路由给账单、技术支持、账户、物流或欺诈专家——每个专家拥有狭窄的上下文，而不是一个试图无所不知的 Agent。
适用场景： 你拥有真正不同类型的请求，这些请求需要不同的上下文、工具或决策逻辑。
失效场景： 当路由本身变得模糊时。如果请求不能清晰地归入一个类别，协调器本身就会成为新的瓶颈和错误路由的源头。
模式 8 — 层次化任务分解
一个根 Agent 将一个复杂目标分解为更小的子目标，将它们委派给专业的 Worker，然后将所有内容综合成一个答案。
实际案例： "明年我们应向哪 3 个国家扩张？" 被分解为竞争分析、法规研究、物流可行性和市场规模评估——每个部分由不同的专家处理，然后合并结果。
适用场景： 问题过于宽泛，无法通过一次推理完成，但可以清晰地分解为独立的专业领域。
失效场景： 当子目标并非真正独立时。如果各个工作流需要实时相互沟通，预先分解会丢失这种交互。
模式 9 — 群体
多个专家 Agent 参与共同讨论，挑战彼此的假设，由一个协调者综合出最终建议。
实际案例： 公司是否应该推出订阅服务？研究、工程、财务和支持 Agent 分别从各自角度进行多轮辩论，然后由协调者权衡利弊。
适用场景： 没有单一的 "正确" 答案——你需要一个由真正竞争性观点塑造的、经过深思熟虑的决策。
失效场景： 当你需要一个快速、确定的答案时。群体模式本质上是缓慢和探索性的——如果你需要速度，那你就选错了工具。
模式 10 — ReAct（推理与行动）
Agent 交替进行推理和行动：决定要调查什么，调用工具，观察结果，判断是否有足够证据。
实际案例： "队列处理器似乎卡住了"——Agent 搜索文档，检查服务健康状态，关联发现，然后才提出修复方案。调查路径不是预先定义的；它取决于 Agent 在过程中发现什么。
适用场景： 通向答案的路径确实无法提前规划——它取决于每一步揭示的信息。
失效场景： 当调查时间过长而无法收敛时。务必限制推理-行动循环的次数，否则你有陷入无限探索的风险。
模式 11 — 人在回路中
Agent 进行调查并提出建议，但由人类对任何有风险或模糊的事项做出最终决定。
实际案例： 退款审批——低风险、清晰明了的案件自动处理。高金额、欺诈信号或政策例外情况会暂停，等待人工审核后再最终确定。
适用场景： 决策涉及真正的财务、法律或声誉风险，且完全自动化尚不可接受。
失效场景： 当你将此仅仅视为一个 UI 功能，而非架构功能时。你需要持久状态、审核员分配、超时处理和升级路径——而不仅仅是一个 "暂停" 按钮。
模式 12 — 计划与执行
一个规划 Agent 在执行任何操作之前，先创建一个完整的、结构化的、可审查和可修改的计划。然后由执行 Agent 按步骤执行。
实际案例： "将工作进程池从 10 个实例扩展到 20 个，验证队列是否清空，更新操作手册。" 完整的计划在执行开始前是可见的，这与 ReAct 模式（路径逐步浮现）不同。
适用场景： 你希望在采取任何行动之前能够审查或批准计划——对于有实际后果的操作至关重要。
失效场景： 当环境变化速度超过计划执行速度时。盲目执行过时计划比没有计划更糟糕。
模式 13 — 反思
Agent 评估自己的失败，反思哪里出了问题，并将该记忆带入下一次尝试。
实际案例： 一个代码生成 Agent 编写脚本，运行时失败，Agent 分析实际错误，记录要修复的内容，然后重试——每次尝试都变得更聪明，而不是重复同样的错误。
适用场景： 失败具有信息量，且自我修正确实能改进下一次尝试。
失效场景： 当失败模式是随机或互不相关时。反思只有在存在真正可学习的模式时才有帮助。
模式 14 — 自定义逻辑
一种混合体：确定性代码处理绝不能出错的规则，而模型则处理判断、起草和异常处理。
实际案例： 一个退款工作流，其中购买验证和欺诈检查作为硬性确定性规则运行——绝不委托给模型——而客户回复的草拟和路由建议则保持 Agent 化。
适用场景： 工作流具有真正的分支逻辑，涉及法律或财务后果，并且你需要精确区分哪些是确定性的，哪些是灵活的。
失效场景： 当团队模糊了界限，让模型做出本应是硬编码规则的决策时。资格判断、权限和资金流动绝不应仅由模型决定。
模式 15 — 事件驱动型 Agent
Agent 不会等待被请求。它订阅事件流，并在条件触发时立即行动。
实际案例： 一个欺诈检测 Agent，在可疑交易事件触发时立即做出反应——而不是等到支持工单最终上报时，那时损失已经造成。
适用场景： 时机比什么都重要，等待人工请求意味着错失行动窗口。
失效场景： 当触发条件定义不明确时。一个带有模糊触发器的高噪音事件流会使系统变成不断 "狼来了" 的状态——或者更糟，错过真正的信号。
模式选择——匹配不确定性，而非赶时髦
正确的模式应与你工作中不确定性的形态相匹配：
→ 不确定使用哪个工具 → 单 Agent 或 ReAct
→ 不确定路由到哪里 → 协调器
→ 不确定质量 → 审查与批评 或 迭代优化
→ 不确定执行路径 → 计划与执行 或 ReAct
→ 不确定如何自我纠正 → 反思 或 循环
→ 不确定商业风险 → 人在回路中 或 自定义逻辑
→ 不确定问题结构 → 层次化分解 或 群体
→ 等不及请求 → 事件驱动型 Agent
如果任务只需要一次可靠的工具调用，群体并不比单 Agent 更高级。
如果你的计划在第三步就过时了，计划与执行也并非 ReAct 的升级版。
最可靠的生产系统并非那些最自治的系统。
它们将自治权精确地放在能创造价值的地方——并在其他地方加以约束。
生产级 Agent 系统的 10 条规则
- 从能起效的最小模式开始。一个拥有清晰工具合约的单 Agent 胜过拥有薄弱合约的多 Agent 系统。
- 像写合同一样写工具描述。模型只能从描述中知道工具的功能——而不是根据你的意图。
- 限制每次请求的迭代次数、工具调用次数和花费。没有预算限制的 Agent 是一个负债，迟早会出现在你的账单上。
- 记录完整的操作轨迹。工具调用、参数、输出、最终决策。没有这些，事故调查就是瞎猜。
- 将不可逆的操作置于确定性检查或人工审批之后。绝不能让模型成为资金流动或生产变更的唯一关卡。
- 使用真实的失败案例进行评估，而不仅仅是完美路径。完美路径的正确性只是原型。边缘情况的正确性才是产品。
- 在系统提示词变得难以阅读之前，按职责分离提示词。"但是当 Y 时不要做 X" 出现你的提示词中，意味着 Agent 在做两份工作。
- 将多 Agent 系统视为分布式系统。部分故障、超时、重试和可观察性不是可选项。
- 模型审查不能替代确定性验证。使用裁判来提高质量。使用测试和权限检查来强制执行正确性。
- 选择更简单的模式——不是因为简单总是更好，而是因为你节省下来的复杂性预算可以用于更好的工具、更好的提示词、更好的评估。
全部 15 种模式介绍完毕。
大多数团队的失败不是因为选错了模式。
他们失败是因为从未问过自己，他们实际上是在解决哪种不确定性。
选择模式。匹配问题的形态。不要在无法体现其价值的地方增加自治权。
如果本文对你有帮助：
→ 转发分享给你团队中每个构建 Agent 的工程师
→ 关注 @sairahul1 获取更多类似深度解析
→ 收藏本文——每次开始新的 Agent 项目时，你都会回来看。
我撰写关于 AI、产品构建以及无需你操心即可运作的系统的文章。
