每位工程师必须掌握的 15 种 AI 代理设计模式

每个构建 AI 代理的团队都会遇到同样的瓶颈。

你从一个提示词和几个工具开始。

它运行得很好。

然后需求增长。更多的边缘情况。更多的团队。更多的风险。

突然之间，你的“代理”变成了一个 3000 字的系统提示词，试图同时完成五项工作。

解决方法不在于更多的提示工程。

而在于选择正确的模式。

以下是每个生产级代理系统所构建的 15 种模式——以及何时使用每一种。

在选择模式之前

并非每个任务都需要代理。

当一个任务需要代理时，是因为：

→ 单次模型调用无法产生可靠结果

→ 模型必须在运行时在工具或数据源之间做出选择

→ 任务需要规划、验证或迭代优化

→ 工作流中存在无法硬编码的真正不确定性

当输入到输出的路径是可预测的时，任务通常不需要代理。

摘要。分类。简单提取。模板化生成。

这些任务作为直接模型调用更快、更便宜、更可靠。

用代理包装它们只会增加延迟和故障点，没有任何好处。

模式 1 — 单代理

最简单、最常见的起点。

一个模型。一个系统提示词。一组有限的工具。

模型决定调用哪个工具，观察结果，并继续下去，直到获得足够的信息来回答。

真实示例： 一个客户支持代理，用于查找订单状态、检查物流情况，并在无法解决问题时创建工单——仅使用 2-3 个工具和一个明确的任务。

何时使用： 任务定义明确，工具集较小，一个代理可以掌握完整的上下文而不会混淆。

何时失效： 当你不断添加工具，系统提示词超过一页时。这是你需要不同模式——而不是更长的提示词——的信号。

模式 2 — 多代理顺序执行

专门的代理按固定顺序运行。每个代理的输出作为下一个代理的输入。

真实示例： 合同审查流程——一个代理提取义务，下一个识别风险，第三个为采购起草摘要。顺序永远不会改变。

何时使用： 工作流具有清晰、可重复的阶段，每个阶段产生下一个阶段所需的内容。

何时失效： 当顺序需要根据流程中发现的内容而变化时。顺序管道假设路径是固定的——如果不是这样，你需要更动态的东西。

模式 3 — 多代理并行执行

独立的子任务同时运行，然后合并为一个整体视图。

真实示例： 凌晨 2 点的生产事故。三个代理同时调查日志、指标和最近的部署——而不是一个接一个——因为在宕机期间每一分钟都很重要。

何时使用： 子任务真正独立且速度很重要。

何时失效： 当任务实际上依赖于彼此的结果时。将依赖的工作强制并行执行只会导致竞态条件和不完整的上下文。

模式 4 — 循环

重复一系列步骤，直到满足退出条件。

真实示例： 一个数据清洗代理，分析杂乱无章的 CSV 数据，提出清洗计划，检查是否通过质量标准，如果不通过则重试——最多循环指定次数。

何时使用： 任务需要多次尝试，并且你可以定义一个明确、可检查的停止条件。

何时失效： 当没有可靠的退出条件时。没有退出条件，你将面临失控的成本和一个可能永远不会终止的系统。

模式 5 — 审查与批评

一个裁判代理审查另一个代理的输出，对其进行批评，并给出具体的可操作反馈。

真实示例： 生成的报告由单独的“评论家”代理审查，该代理在报告到达人类之前标记出薄弱的主张、缺失的证据或不清晰的章节。

何时使用： 质量比速度更重要，并且你希望在系统中内置第二意见，而不是事后附加。

何时失效： 当批评代理与生成代理存在相同的盲点时。基于相似假设训练的审查者不会发现相同的错误。

模式 6 — 迭代优化

一个带有质量评分阈值的反馈循环。生成器不断改进，直到达到阈值。

真实示例： 一个营销文案生成器，根据品牌指南对自己的草稿进行评分，并不断重写，直到达到最低质量分数——不仅仅是单次通过/失败检查，而是分级的改进。

何时使用： 输出质量确实可变，并且“足够好”有一个可衡量的阈值。

何时失效： 当评分函数模糊或可被利用时。如果模型可以在没有真正改进的情况下提高自己的分数，循环只会浪费令牌。

模式 7 — 协调器

一个中央路由代理根据实际请求内容将请求定向到专门的代理。

真实示例： 支持工单被路由到计费、技术、账户、物流或欺诈专家——每个专家只有狭窄的上下文，而不是一个试图了解一切的代理。

何时使用： 你有真正不同的请求类型，需要不同的上下文、工具或决策逻辑。

何时失效： 当路由本身变得模糊时。如果请求不能清晰地归入一个类别，协调器就会成为新的瓶颈和错误路由的来源。

模式 8 — 分层任务分解

一个根代理将复杂目标分解为较小的子目标，将其委托给专业工作者，然后将所有内容综合成一个答案。

真实示例： “明年我们应该扩展到哪 3 个国家？”被分解为竞争分析、法规研究、物流可行性和市场规模——每个由不同的专家处理，然后合并。

何时使用： 问题过于宽泛，无法通过一次推理完成，但可以清晰地分解为独立的专业领域。

何时失效： 当子目标实际上并非独立时。如果工作流需要实时相互通知，预先分解会失去这种交互。

模式 9 — 群体

多个专业代理贡献于一个共享讨论，质疑彼此的假设，并由一个协调者综合出最终建议。

真实示例： 公司是否应该推出订阅层级？研究、工程、财务和支持代理各自从自身角度进行多轮讨论，然后由协调者权衡利弊。

何时使用： 没有单一的“正确”答案——你需要一个由真正竞争观点塑造的、经过深思熟虑的决策。

何时失效： 当你需要快速、确定的答案时。群体模式故意放慢速度并进行探索——如果需要速度，则是错误的工具。

模式 10 — ReAct（推理与行动）

代理在推理和行动之间交替：决定调查什么，调用工具，观察结果，判断是否有足够的证据。

真实示例： “队列处理器似乎卡住了”——代理搜索文档，检查服务健康状态，关联发现，然后才建议修复。调查路径不是预定义的；它取决于沿途发现的内容。

何时使用： 通往答案的路径确实无法预先规划——它取决于每一步揭示的内容。

何时失效： 当调查长时间运行而不收敛时。始终限制推理-行动循环的次数，否则你可能会陷入无限探索。

模式 11 — 人在环中

代理进行调查和推荐，但人类对任何有风险或模糊的事项做出最终决定。

真实示例： 退款审批——低风险、明确的情况自动处理。高金额、欺诈信号或策略异常在使用任何内容之前暂停供人工审查。

何时使用： 决策具有真正的财务、法律或声誉风险，而完全自动化尚不可接受。

何时失效： 当你将其仅视为 UI 功能而非架构功能时。你需要持久状态、审查者分配、超时处理和升级路径——而不仅仅是一个“暂停”按钮。

模式 12 — 计划与执行

一个规划代理事先创建完整的结构化计划——可审查和可修改——然后执行代理在采取任何行动之前进行。然后执行者依次运行各步骤。

真实示例： “将工作节点从 10 个扩展到 20 个实例，验证队列排空，更新运行手册。”执行开始前整个计划可见，这与 ReAct 不同，ReAct 的路径是逐步出现的。

何时使用： 你希望计划在采取任何行动之前可审查或可批准——对于具有实际后果的操作很重要。

何时失效： 当环境变化快于计划执行时。盲目执行过时的计划比没有计划更糟糕。

模式 13 — 反思

代理评估自己的失败，反思出错的原因，并将该记忆带入下一次尝试。

真实示例： 一个代码生成代理编写脚本，运行时失败，代理分析实际错误，记录要修复的内容，并重试——每次尝试都变得更聪明，而不是重复同样的错误。

何时使用： 失败具有信息性，自我纠正确实能改进下一次尝试。

何时失效： 当失败模式随机或彼此无关时。反思只有在存在真正可学习的模式时才有帮助。

模式 14 — 自定义逻辑

一种混合模式：确定性代码处理绝不能出错的部分，而模型处理判断、起草和异常处理。

真实示例： 一个退款工作流，其中购买验证和欺诈检查作为硬性确定性规则运行——绝不委托给模型——而客户回复的起草和路由建议保持代理性。

何时使用： 工作流具有真正的分支逻辑，涉及法律或财务后果，并且你需要精确区分哪些是确定性的，哪些是灵活的。

何时失效： 当团队模糊界限，让模型做出本应是硬编码规则的决定时。资格、权限和资金流动绝不应仅由模型决定。

模式 15 — 事件驱动代理

代理不等待被请求。它订阅事件流，并在条件触发时立即行动。

真实示例： 一个欺诈检测代理，在可疑交易事件触发时立即反应——而不是等待支持工单最终上报，到那时损害已经造成。

何时使用： 时机比什么都重要，等待人类请求意味着错过行动窗口。

何时失效： 触发条件定义不当。具有模糊触发器的嘈杂事件流会导致系统不断“喊狼来了”——或者更糟，错过真正的信号。

模式选择——匹配不确定性，而非炒作

正确的模式匹配你工作中不确定性的形状：

→ 不确定使用哪种工具 → 单代理或 ReAct → 不确定路由到哪里 → 协调器 → 不确定质量 → 审查与批评或迭代优化 → 不确定执行路径 → 计划与执行或 ReAct → 不确定如何自我纠正 → 反思或循环 → 不确定业务风险 → 人在环中或自定义逻辑 → 不确定问题结构 → 分层分解或群体 → 不能等待请求 → 事件驱动代理

如果任务只需要一个可靠的工具调用，那么群体并不比单代理更高级。

如果计划到第三步就过时了，那么计划与执行并不比 ReAct 更高级。

最可靠的生产系统不是最自主的系统。

它们将自主性放在能创造价值的地方——并在其他地方加以约束。

生产级代理系统的 10 条规则

• 从最小的可行模式开始。具有清晰工具契约的单代理胜于具有薄弱契约的多代理系统。

• 将工具描述写成交互契约。模型只能从描述中了解工具的用途——而不是你的意图。

• 限制每次请求的迭代次数、工具调用次数和花费。没有预算限制的代理就是一份随时会出现在账单上的负债。

• 记录完整的行为轨迹。工具调用、参数、输出、最终决策。没有这些，事故调查就是猜测。

• 将不可逆操作置于确定性检查或人工批准之后。绝不让模型成为资金流动或生产更改前的唯一关卡。

• 使用真实的失败案例进行评估，而不仅仅是理想路径。理想路径的正确性是原型。边缘情况的正确性才是产品。

• 在系统提示词变得难以阅读之前，按职责分离提示词。“但是当 Y 时不要做 X”悄然出现在你的提示词中，意味着代理正在做两项工作。

• 将多代理系统视为分布式系统。部分失败、超时、重试和可观测性不是可选项。

• 模型审查不能替代确定性验证。使用裁判来提高质量。使用测试和权限检查来强制正确性。

• 倾向于更简单的模式——不是因为简单总是更好，而是因为你节省下来的复杂度预算可以用于更好的工具、更好的提示词、更好的评估。

以上就是全部 15 种模式。

大多数团队的失败不是因为他们选择了错误的模式。

而是因为他们从未问过自己实际上在解决哪种不确定性。

选择模式。匹配问题的形状。不要在自主性不能发挥作用的地方增加它。

如果本文对你有帮助：

→ 转发分享给你团队中每位构建代理的工程师 → 关注 @sairahul1 获取更多类似的内容 → 收藏本文——每次启动新的代理项目时你都会回来查看

我撰写关于人工智能、产品构建以及无需你就能运行的系统。