生产级 AI Agent 架构模式：6 种经实际验证的设计

TL;DR：生产环境中的智能体能work，是因为它们的自主性是被限制的，而非因为它是无限的。将智能体决策放入可预测的工作流中，为每个循环设置上限，根据后果限制工具使用，对状态打检查点，尽可能用代码验证，只在高影响的行动上才要求人类审批。如果安全只存在于提示词中——或者成功与否是以一个精美的演示来衡量的——那你的智能体还不具备生产就绪性。

自主性演示与生产环境的鸿沟

一个可用的定义，因为这个词已经被用烂了

模式 1：有限循环

模式 2：工作流骨架，智能体内核

模式 3：工具授权分层

模式 4：检查点与恢复

模式 5：批评循环（谨慎使用）

模式 6：不破坏价值的人工门槛

反模式：演示软件的名人堂

生产环境智能体的一个参考形态

自主性演示与生产环境的鸿沟

智能体演示现在已是一种流派，它的惯例和十四行诗一样死板：给模型一些工具，让它边规划边出声，看着它链式调用六次来完成订会议、修 bug 或对账，然后在意外出错之前结束。演示的力量恰恰来自于它省略的东西——第三步返回空结果、智能体 hallucinate 了一个替代品的那次运行；循环了四十分钟的那次运行；"好心"给客户发了邮件的那次运行。

我已经交付和审查了足够多的智能体系统，现在持有一个坚定的、略带叛逆的立场：智能体演示软件和智能体生产软件的区别在于，生产系统在设计预算中把大部分精力花在了约束演示所庆祝的自主性上。不是消灭它——而是约束它，而且是刻意地、在特定的关节处加以约束。下面的模式就是这些关节：工作团队在哪里放置了结构、预算、授权和人类，以及每个放置决策为何值得它带来的复杂性。

一个可用的定义，因为这个词已经被用烂了

"智能体"目前含义广泛，从一个带单个工具的提示词到一个自我委托流程的舰队，这使得架构对话几乎无法进行。让这些模式变得清晰可读的定义是：智能体是一个由模型选择下一个行动——使用哪个工具、传入什么参数、是否继续——而不是执行固定流程的系统。这种选择能力既是价值的来源（它处理了你没有枚举过的情况），也是风险的来源（它以你没有枚举过的方式处理它们）。

因此设计问题从来不是"要不要用智能体"，而是选择在哪里发生、由什么来约束它。下面的每个模式都是对约束这一半的回答。

模式 1：有限循环

每个智能体核心的原语——观察、决策、行动、重复——只有在为每个可能失控的维度都包装了明确预算后，才能交付到生产环境：

class LoopBudget:
    max_steps: int = 12          # 每个任务的行动数，硬性停止
    max_tokens: int = 150_000    # 每个任务的消费上限
    max_wall_clock: int = 300    # 秒数；智能体不能比用户更有耐心
    max_tool_errors: int = 3     # 连续失败次数，超限则放弃
    max_repeats: int = 2         # 相同的工具+参数=可能的循环

# 任何一项超出：停止，记录检查点状态，诚实展示部分成果 —
    # 绝不要静默截断，绝不要静默永久重试。

其中两项特别值得特别说明，因为团队往往会忽略它们。重复检测（max_repeats）捕获了智能体的标志性病症——用完全相同的参数永久重试一个完全相同的失败行动；记录最后几次工具调用的指纹几乎不花什么代价，却能彻底终结这个病症。投降协议比上限本身更重要：一个达到预算的智能体必须报告——它尝试了什么、在哪里停下、还有什么未完成——因为带诚实边界的部分答案是功能，而没有解释的超时只是一个工单。预算突破不是错误路径；它是一等公民的结果，值得有对应的用户体验。

来自生产环境的校准说明：大多数有用的任务类别在出人意料的低步骤数（5–15 步）就收敛了。如果你的智能体经常需要 40 步，你不是遇到了自主性问题——你遇到的是分解问题，那就是下一个模式要处理的事情。

模式 2：工作流骨架，智能体内核

这个类型中单值最高钱的结构性决策。完全开放的智能体——一个循环，所有工具，"自己搞定"——最大化了灵活性和方差；固定流程则同时最小化了二者。生产的最佳平衡点是一个确定性工作流骨架，其各个阶段是智能化的：

骨架贡献了模型不擅长的东西：保证的顺序、阶段作用域的工具访问、阶段之间确定性的门槛，以及一个可读懂的进度模型（"它处于分析阶段"比"它正在思考"好得多）。智能阶段贡献了管道不擅长的东西：处理一个步骤内部的无限多样性——运行哪些搜索、如何解释一个混乱的结果、修复应该是什么。

团队总是从两个方向殊途同归地到达这个形态：开放智能体在方差造成麻烦后加上了骨架；僵化管道在边缘情况造成麻烦后将各阶段智能化。从最佳平衡点起步可以跳过这两种麻烦。判断阶段归属的诊断标准：任何你能写出确定性检查的地方（"我们有足够的证据继续了吗？"），你就找到了一个门槛；门槛之间的部分就是模型做选择的地方。

模式 3：工具授权分层

智能体真正的能力表面是它的工具列表——生产中的核心罪过是把一个没有差异化的工具箱交给一个概率性的选择器。工具必须按后果分层，且分层必须在模型之外执行：

Tier 0 —— 观察：读取、搜索、获取、列出。自由可用；最坏情况不过是浪费预算。

Tier 1 —— 可逆操作：起草、暂存、评论、在沙箱中创建。循环内可用；错误可撤销。

Tier 2 —— 有后果的操作：发送、合并、部署到预发环境、修改共享状态。在执行前需要确定性前置条件检查（验证规则、状态断言）——模型发起请求，策略层做决定。

Tier 3 —— 不可逆或高冲击范围：付款、删除、生产部署、大规模外部通信。需要人工门槛（模式 6）或直接从智能体的世界中缺席。

两个执行细节区分了真正的实现和做样子的实现。首先，分层存在于工具执行器中，而不是提示词中——"请谨慎使用发送工具"是一个愿望；一个在满足前置条件失败时拒绝 Tier 2 调用的执行器才是控制。其次，参数根据请求者的授权而非智能体的授权进行验证——代表用户 X 行事的智能体只能触碰 X 能触碰的资源；智能体按任务继承 scoped credentials，而不是手握 god-token。这是普通的最少权限工程，但令人惊讶的是，智能体的热度让团队经常忘记他们早就知道这一点。提示词注入使这成为必选项：任何读取外部内容的智能体（网页、邮件、文档）最终都会读到针对它的指令，而分层系统正是使那成为一个花絮而非事故的原因。

模式 4：检查点与恢复

演示智能体为一次辉煌的不间断运行而活。生产任务跨越分钟到小时，遇到不稳定的工具，因部署而重启，被它们服务的人类打断。模式：将智能体的任务状态——计划、已完成步骤、工具结果、待处理意图——在每个步骤边界处外部化到一个持久存储中，使循环本身无状态且可恢复。

这些收益在崩溃恢复之外还有复合效应。可恢复性将模型提供商的 hiccup 从任务失败转化为暂停。检查点给你审计能力——智能体行动时确切知道什么的完整重建——这是你的 postmortem（可能还有你的合规团队）会想要的东西。人工门槛（模式 6）不再是尴尬的阻塞调用，而成为等待输入的检查点状态——智能体停泊，人类几小时后回复，任务在上下文完整的情况下恢复。检查点 diff 是智能系统产生的最佳调试产物："在第 6 步和第 7 步之间，计划从 X 变成了 Y"将行为错误定位到了原始 transcript 掩埋的地方。

持久化执行框架（Temporal 类）天然适合智能体，这并非偶然：智能体是一个在运行时选择下一步的工作流。已经在使用此类基础设施的团队应该在上面运行智能体循环，而不是在应用代码中重新发明检查点机制。

模式 5：批评循环（谨慎使用）

Generate-then-critique——第二轮模型对第一轮输出基于评分标准进行审查的模式——在具有可检验属性的任务上可测量地提升质量：代码是否编译并通过测试、摘要是否只引用现有事实、计划是否只触及授权系统。这个模式有两个尖锐的注意事项，使其在模式目录中占有一席之地，而演示中往往省略了这些。

首先，批评者在检验比执行更容易的地方有效。代码审查之所以有效，是因为执行和测试提供了可供批评的客观事实。开放式判断任务（"这个分析有洞察力吗？"）只会得到批评剧场——第二个模型自信地为第一个模型的相关错误背书。把批评预算花在有可验证属性的地方；在任何可能的地方使用确定性验证器（更便宜，而且真正可靠）。

其次，将循环限制在一轮。Generate-critique-revise 在大多数真实任务中在一轮迭代内收敛；更多轮次会产生振荡（修订撤销了上一轮修复的内容），同时成本线性增长。演示中展示的多轮自改进大部分只是 token 消耗。一轮生成、一轮批评、一轮修订，然后是一个门控——确定性的或人工的——才是生产环境的形态。

Pattern 6: 不会毁掉价值的Human Gates

每个重大决策的智能体都需要某处有人类批准，天真的放置会毁掉经济学——一个每项任务中断确认八次的智能体只是在你原本的推理成本之上叠加了一个更慢、更冗长的形式。设计原则是把批准当作稀缺的 UX 预算：

在结果边界而非步骤边界设置门控。对完整的提议操作集批准一次（"发送这 3 封邮件，提交这 2 个工单——批准？"）胜过五次顺序的微批准，无论从吞吐量还是从审查者注意力质量来看都是如此。

让批准产物丰富且呈 diff 形态。人类在看到将要变更的内容时批准良好——收件人、金额、前后状态——而当面对一堵智能体推理记录时会盖章。通过代码审查的方式设计批准视图，而非记录转录。

按累积的信任等级分层门控。新智能体（或新任务类别）：在 Tier 2+ 门控一切。随着可衡量的性能积累，扩大自动批准范围——先从低风险操作类型开始，通过采样审计而非全面审查来监控。这种渐进式自主是团队从"人类批准一切"到真正杠杆而无需跨越信任飞跃的方式。

永远不要让门控悄然成为瓶颈。排队的批准会老化；停在人类那里的任务需要 SLA、提醒和升级，否则智能体系统的吞吐量会悄然变成一个心不在焉的审查员的注意力跨度。

Anti-Patterns: Demo-Ware 名人堂

反复出现的形态，可靠地预测生产痛苦：自委托 swarm（智能体生成智能体——将本文中每个失败模式乘以扇出，以交换换来协调开销，而且几乎不是业务任务所需要的；带有并行阶段的工作流骨架在不使用无政府状态的情况下捕获并行性）；上帝上下文循环（将每个观察追加到一个不断增长的上下文中，直到模型淹没在自己的历史中——检查点状态与摘要记忆正是为了防止这种情况而存在的）；提示词强制安全（任何形如"模型被指示不..."的句子作为控制手段呈现）；以及演示指标（"在我们的测试中完成了任务"但没有分母——生产智能体需要完成率、干预率和每个已完成任务的成本，在真实流量上测量，否则你就是在凭逸事导航）。

生产智能体的参考形态

组合起来的模式，在真实系统中会是什么样子——一个调查并解决账户问题的支持运营智能体：

工作流骨架包含四个阶段（分诊 → 调查 → 提议 → 执行），每个阶段是一个在 LoopBudget 下的智能体循环，工具按阶段分层：调查只获取 Tier 0；提议构建 Tier 1 草稿；执行持有特定账户的范围化 Tier 2 凭证，退款和关闭置于 Tier 3 人类门控之后，以 diff 形式呈现。每个步骤边界在持久存储中设置状态检查点；人类门控是一个带有 4 小时 SLA 的停放检查点。一轮批评在门控前根据账户状态验证提议。遥测发出完成率、干预率、每次解决的花费和步骤数分布——这四个数字告诉你这个东西是否赚回了它的复杂性。

这些都不奇特；每一片都是已知的工程材料。关于强智能体架构的独特之处在于判断模型自主权应该放在哪里、必须在哪里被隔开——而这也正是 AI 优先的设计面试现在探测的东西。朝着这些系统的架构师级别所有权构建的工程师，可以在 AI Architect track 的技能矩阵和场景评估中压力测试那个判断——"能连接一个智能体循环"和"能决定门控放在哪里"之间的差距，正是那些评估构建来暴露的差距。

预算作为事后考虑。循环发布时没有步骤上限、没有重复检测、没有投降协议——然后在某个周末遇到第一个病态输入。

一个工具箱，没有分层。能起草回复的模型也能发送它们；第一次注入或幻觉会立即发现这一点。

自主权放在了本该用 pipeline 的地方。如果步骤是已知且固定的，智能体只会为一个已解决的问题增加方差和成本；只对需要判断的阶段进行智能体化，而不是对不需要判断的序列。

阻塞性人类门控。同步批准调用使人类成为延迟组件；停放的检查点使他们成为工作流阶段。

在不可验证的任务上进行批评循环。两个相关的模型达成一致不是验证。

凭借逸事成功发布。没有真实流量上的完成率/干预率/成本率，你就无法区分一个工作的智能体和一个曾经工作过的智能体。

为每个循环包裹明确的多轴预算，包含重复检测和设计的投降路径。

将任务结构化为确定性骨架与智能体阶段，由可检查的条件门控。

按后果对工具分层；在执行器中强制执行分层和参数作用域，使用每任务最小权限凭证。

在步骤边界检查点状态；使恢复、审计和停放的人类门控从同一机制中自然产生。

只在验证比生成更难的场景应用批评者，且限制在一轮。

在结果边界花费批准-UX 预算，使用 diff 形态的产物，随着可衡量的信任积累扩大自主权。

从第一天起就仪表化完成率、干预率和每个已完成任务的成本。

生产智能体架构是在特定关节约束自主权的学科——预算、骨架、分层、检查点、门控——而不是最大化它。

带有智能体阶段的工作流骨架形态是这类别的最佳平衡点；两个极端在生产痛苦后会迁移向它。

在执行器中强制执行的工具分层（而不是在提示词中）是承重的安全机制，而提示词注入使其成为必须。

外部化、检查点的状态将崩溃、中断和人类批准从失败模式转换为工作流状态。

没有完成率遥测的智能体是一个带有部署管道的演示。

什么时候任务需要智能体而不是固定 pipeline？当路径在每个实例中真正变化时——调查、诊断、多源综合——以至于枚举分支不可行。如果高级工程师能完全 flowchart 这个任务，就构建那个 flowchart；它在每个生产指标上都会胜过智能体。

多智能体架构如何适应这些模式？大多作为阶段：专门的智能体作为一个骨架中的阶段（一个研究阶段，一个起草阶段）干净地继承所有 containment 机制。相比之下，对等智能体协商会乘以不可验证的交互，而且很少有业务需求来证明其合理性——将其视为研究姿态，而非生产默认。

循环的选择应该运行在什么模型层？选择（规划、工具选择）比执行从最强模型中受益更多——那里的错误在每个后续步骤中复合。常见的生产经济学：计划/决定步骤使用旗舰模型，阶段内的提取和摘要使用小模型，符合标准成本设计的路由逻辑。

如何在真实流量之前测试智能体？基于回放的评估：记录真实任务输入和工具调用记录，然后用模拟工具响应（包括记录的失败——空结果、超时、格式错误的数据）运行智能体。智能体是工具响应空间中生活着硬用例的系统，所以你的测试工具必须控制那个空间。

这些模式是否专门适用于编程智能体？直接回答——编程智能体是这套模式的最佳案例，因为验证成本很低（编译、测试、lint = 确定性的关卡；沙箱 = 天然的一级防线；PR = 已经存在的、形状为 diff 的人工关卡）。这很大程度上就是为什么编程是当前智能体真正生效的领域。

每一个软件时代都会有一项技术，其演示效果远超实际部署，而智能体就是这个时代这种差距的冠军。这种差距的弥合方式始终如一——不是靠技术变成魔法，而是靠工程师构建那些枯燥的外骨骼，让强大但不可靠的内核得以工作：循环中的预算、选择的结构、工具的权限层级、整个系统下持久化的状态，以及人类被部署在他们的判断无可替代、且仅此而已的地方。

约束，原来就是让自主性得以交付的东西。当前在智能体上取得成果的团队，不是那些对模型最信任的团队——而是那些给它筑起最好围栏、最诚实衡量、且只有数据说话时才扩大围栏的团队。像这样构建，演示的承诺就不再是一种类型惯例，而开始成为真实的完成率。