AI 智能体设计模式：从简单开始，执行前验证

“对话一结束，你的 AI 就把一切都忘了。”这描述的是没有持久化上下文的无状态应用，并不适用于所有 AI 产品。对话内状态与跨会话记忆是两种不同的能力，应用都可以自行提供。LangChain 记忆机制概览

不过，记忆并没有回答下一个架构问题：智能体可以凭借记住的信息做什么？客服助手可能需要之前的对话来理解投诉，但不能把记忆中的“我是管理员”当成发起退款的授权。关于跨会话的信息提取、更新和遗忘，请参阅Supermemory 实施指南。本文讨论的是执行流程的选择。

对 AI 智能体来说，每一份复杂度都应该有充分理由。我的起点是能够满足任务验收标准的最小系统。Anthropic 同样建议先尝试简单方案，再权衡额外的智能体行为所带来的延迟和成本。Anthropic 的有效智能体设计建议

本文根据故障类型比较五种实用模式。它们是可以组合的架构选择，不是完整分类标准，也不是必须逐级升级的五层成熟度模型。尤其要明确：验证是风险控制，不是架构足够复杂之后才配备的功能。资料核查日期为 2026 年 9 月 17 日。以下示例和验收场景是设计建议，不是客户项目的实测结果。

哪一种 AI 智能体设计模式能解决你的故障？

增加模型调用之前，先找出最早被违反的要求。缺少上下文，可能需要改进上下文管理；业务流程可以预先确定，可能只需要编写固定工作流。这两种情况都不自动意味着需要自主循环。

最后一行可以适用于其他任何一行。一次模型调用产生的付款建议，同样需要授权。反过来，一个只读摘要功能也不会仅仅因为增加了规划器就变得更好。

1. 单次调用：只要有效，就保留简单基线

单次调用模式把范围明确的任务发送给模型一次，然后返回输出，不运行自主工具循环。严格来说，它是基础 LLM 工作流；按照要求模型动态选择动作的定义，它未必属于智能体。

它适合从已提供的投诉中提取字段、给请求分类、总结已批准的文档，或在上下文齐全时起草回复。必要的数据可以在调用之前通过确定性的程序准备好，并不需要让模型自己决定如何检索。

示例：把客服消息转换成类别、紧急程度和简短摘要，再用普通应用代码验证数据结构。缺少必填字段时，应返回验证失败或请求人工检查，而不是编造订单号。

优势是应用层执行路径很小。局限在于：不改变架构，模型就无法查看一个结果后再自主决定查询另一项来源。一次调用也不天然意味着结果确定、成本低或答案正确；这些都取决于模型、上下文和任务。只要测得的质量足够，就保留这一基线。对于精确计算或固定转换，首先考虑普通代码，而不是模型。

2. ReAct：当观察结果改变下一步动作时，再增加循环

ReAct 交替进行决策、行动和观察。工具结果会影响下一步选择，而不只是填充预先固定的步骤。原始论文研究了推理与环境动作相结合的方法。ReAct 原始研究论文

示例：客服助手查询订单。如果发现运输异常，就继续检查配送事件；如果退货已经完成，就查询退款状态。只看用户最初的消息，无法预先确定哪一次后续查询最有价值。

这不同于每次都读取订单、获取同一份政策，然后生成摘要的固定流程。对于后者，显式应用代码可能比让模型选择执行路径更容易测试。

首次实施时，应设置最大步骤数、总运行时限和工具调用预算。识别没有获得新证据的重复查询。区分可重试的传输故障与业务拒绝；预算耗尽时，明确返回“未完成”状态。记录工具名称、参数、结果和简短决策说明，不要要求访问模型隐藏的内部思考过程。

工具观察结果是数据，不是新的授权来源。敏感读取之前要检查访问权限，工具参数必须验证，每一次会产生重要后果的写操作都要经过控制。检索页面中出现“忽略政策”，不能因此改变实际政策。

3. 规划器与执行器：把任务规划和实际执行分开

Planner-executor 模式为规划和执行分配不同责任。规划器提出步骤，执行器完成步骤。这是 LangChain 最初介绍该模式时的核心思路，不是效果必然提升的保证。规划与执行分离的架构说明

当长任务反复遗漏交付物、丢失依赖关系或难以从中断处恢复时，可以考虑这种模式。例如，市场研究报告需要先收集证据，再分析，最后形成建议。流畅的最终文字不应该掩盖缺失的研究步骤。

每个拟定步骤都应明确输入、预期输出、依赖关系和完成检查。把已完成工作保存为显式状态。只有当证据推翻原有假设时才重新规划，而不是因为模型还能生成另一份计划。限制重新规划次数，并向负责人展示被阻塞的步骤。

规划与执行不要求使用不同模型，也不要求多个智能体。一个执行器就可以依次完成计划。只有任务真正独立时，并行工作单元才有意义；共享写入和相互依赖的输出需要协调。如果步骤已知且稳定，预定义工作流通常是更小的设计。

需要警惕的故障是：计划格式漂亮，内容却不正确。执行前检查范围和前置条件，完成后验证真实输出，不要把打勾的清单当成成功证据。

4. 反思：改善初稿，不要把自我认可当成证明

反思模式在初次输出之后增加批评和修订。Self-Refine 使用模型生成的反馈来修改初稿，并报告了在受测任务上的改进。该结果不能被解释为普遍准确性保证。Self-Refine 研究论文

采用具体的评判标准：是否回应了每个问题？是否区分事实与假设？是否只使用批准的来源？“再认真想一想”不是验收标准。先增加一轮修改，再与未经修改的基线比较。

示例：一份客服回复草稿事实正确，却没有说明下一步。批评阶段可以指出这一遗漏，并要求补充清晰说明。对于代码，批评可以提出改进建议，但编译、测试和人工审查仍然是独立检查。

关于内在自我纠错的研究发现，受测模型在没有外部反馈时可能无法修正推理，甚至让结果变差。这是针对特定任务和模型的警示，不代表所有后续系统都不可能改善。无外部反馈条件下的自我纠错研究

实际区别很直接：反思问的是“初稿能否改善”，验证检查的是“要求是否真的得到满足”。第二个模型表示同意，依然无法证明用户拥有某项权限，也无法证明账户余额正确。

5. 验证器门控：将提出动作与授予执行权限分开

验证器门控执行会阻止动作生效，直到独立控制允许它执行。OWASP 建议在下游系统实施授权、限制权限，并对高影响操作要求人工批准，而不是让 LLM 自行决定权限。OWASP 关于过度自主权的建议

“独立”意味着智能体不能绕过检查、改写检查政策或自行伪造证据。验证器可以包括结构校验、规则引擎、可信系统查询、确定性计算或人工审批。另一个模型可以提供参考意见，但不应成为唯一的授权边界。

对于退款建议，我会要求应用确定已认证的操作主体与租户，从权威业务系统读取当前订单，验证金额和币种，检查剩余可退款额度，并确认所需审批。这些是工程控制建议，不是一套完整的支付实现。

审批必须绑定到确切动作，包括收款方、金额、币种和相关记录版本。建议发生变化，就需要重新验证。OWASP 的交易授权指南要求服务端强制执行，并在执行前进行最终授权检查。OWASP 交易授权指南

证据缺失、验证器响应格式错误或验证器超时，都应该阻止执行或转交审核。业务拒绝不能演变成无限重试。对不确定结果设计幂等与对账机制：支付超时并不能证明付款没有发生。再次写入之前，应先检查当前状态。

门控必须放在每个相关副作用之前，包括中间步骤的工具调用，而不只是最终答案之前。执行后还要核对真实结果。执行前授权与执行后验证解决的是不同问题。

客服助手不需要同时使用全部五种模式

假设客户询问一笔延迟配送的订单，并希望了解是否可以退款。这是设计练习，不是客户部署案例。先采用单次调用分类和只读工作流。只有当后续调查取决于之前的查询结果时，才引入 ReAct。

规划器是可选的：简单的订单状态查询通常不需要它。只有调查涉及多个相互依赖的交付物时，才考虑加入。反思同样可选，适用对象是回复草稿，而不是支付授权。

退款路径则不同。将执行凭据保留在模型之外，验证结构化建议，获得必要批准，通过范围有限的接口执行，并核对结果。无论建议由一次模型调用还是多次调用生成，这一边界都不变。

持久化安全恢复所需的状态，但不要把聊天记录等同于执行台账。对敏感追踪数据进行脱敏，并测试重启行为。OWASP 的智能体安全指南进一步讨论了工具限制、记忆保护和运维控制。OWASP AI 智能体安全检查指南

如何判断增加一轮循环是否值得？

使用相同的代表性任务，对比基线和一项拟议改动。尽可能保持模型配置与评估标准一致，记录不可避免的差异，并进行多次试验。否则，所谓的架构进步可能只是换了模型，或者测试样本更简单。

衡量通过验收的结果、无依据的陈述、未授权动作、人工审查投入、超时，以及端到端 p50/p95 延迟。计算全部模型和工具调用，包括重试和修订。成本核算方法见AI 智能体单次动作成本指南。这里要决定的是：增加的步骤是否充分减少了那个具体故障，足以抵偿额外运维负担。

安全控制不是可以在真实用户身上随意取消的实验选项。授予写入权限之前，应先在沙箱或影子模式中测试会产生重要后果的流程。不能因为无门控的测试更快，就移除授权。

运行时、故障恢复和运维责任，可参考智能体运行控制层架构指南。对于具体实现，Wavect 的AI 开发服务将执行流程与产品要求、验收检查连接起来。我们的从原型到企业试点的交付案例是另一项独立实践，不能作为这些模式已在该项目中完成对比测试的证据。

可以用上线前软件 QA 检查清单定义发布标准，或讨论你的智能体流程具体出现了什么故障。准备一条失败追踪、一个成功示例，以及系统绝对不能在未获批准时执行的动作。