AI Agent架构进化五阶段：从模型调用到生产运行时的真实路径

从模型调用到生产运行：Agent 架构的真实进化路径

很多人对 AI Agent 的理解还停留在"一个模型外面套一圈工具"的层面，但从工程实践来看，这种认知远远不足以支撑一个能够稳定运行的生产级系统。Agent 架构的演进实际上经历了五个清晰的阶段，每一层增加的不是"炫技"能力，而是一组新的责任与随之而来的新故障方式。

这里有一个关键的观念需要先厘清：这五层并不是等级排名，层数越多不代表系统越好。 任务需要哪一层，就把哪一层做扎实。盲目堆叠层级只会引入无谓的复杂度和风险。

AI Agent 的核心职责是什么

在拆解五层架构之前，先把 Agent 的本质说清楚。一个真正的 AI Agent 需要围绕目标保存进展，从允许的动作中选择一个，拿到真实的执行结果后再更新判断，同时还要清楚地知道：什么时候继续、什么时候结束、什么时候交给人类接管。

这里涉及三组核心要素：

• 目标与状态：目标说明任务要得到什么结果，状态记录已完成什么、拿到了哪些事实。注意，这里的状态指的是任务事实，而不是聊天记录。聊天记录可以参与构建模型上下文，但绝不能充当任务数据库，也不能成为恢复执行时的唯一依据。任务事实应当是结构化的、可序列化的数据——例如"已查询到3个候选方案"、"用户已确认预算上限为5000元"——而非一段冗长的对话历史。
• 动作与反馈：模型不能随意发挥，只能在系统允许的动作中选择，由运行时真正执行，再把结构化结果返回。每次执行结果都要回到任务状态里，成为下一步判断的依据。Prompt 写得再长，也替代不了这个反馈闭环。这个"感知-决策-行动-反馈"的循环，本质上借鉴了经典控制论和强化学习中的 Agent-Environment 交互范式，但在工程实现中增加了权限、格式约束和错误处理等现实层面的考量。
• 停止条件：任务完成、确定失败、超过预算、连续无进展、遇到需要审批的动作，都需要退出当前循环。这些条件必须在设计时写清楚，而不是等出了问题再补。

Agent 架构五个阶段逐层拆解

第一层：模型调用——一次性生成

最基础的形态，输入指令和上下文，模型返回一次结果。这个阶段主要处理的是指令是否清楚、输出结构是否稳定、模型如何选择、结果如何评测。常见问题是内容不准确、格式不稳定或上下文不完整。但本质上，它仍然是一次性生成，没有任务状态的概念。

从系统设计角度看，这一层对应的是经典的"请求-响应"模式。模型作为一个无状态的函数：给定输入，产出输出。所有的"智能"都被压缩在一次前向推理中。这意味着它天然不适合需要多步推理、中间验证或外部数据获取的任务，但对于文本改写、分类、摘要等单轮任务，这一层已经足够。

第二层：工具调用——扩展模型能力边界

模型开始连接数据库、外部服务或业务 API，能力边界被显著扩展。系统此时需要定义输入输出结构、身份权限、超时方式以及错误含义。

一个特别值得强调的工程细节是：只要工具可能写入数据或触发操作，就必须考虑幂等性。 否则一次网络重试就可能变成两次真实执行，造成难以挽回的副作用。这也是很多初级 Agent 系统埋下的隐患。

幂等性（Idempotency）是分布式系统设计中的核心概念，指同一操作执行一次和执行多次产生的效果完全相同。在 Agent 系统中，网络抖动、超时重试、进程重启等情况极为常见，如果一个工具调用（如扣款、发送通知、创建订单）不具备幂等性，重试就会导致重复执行。常见的幂等实现方式包括：为每次调用分配唯一的幂等键（idempotency key），服务端在执行前检查该键是否已处理过；或者将操作设计为"设置为某值"而非"增加某值"。在生产级 Agent 中，这不仅是工具层面的问题，还涉及运行时如何记录"哪些动作已成功完成"，以便在断点恢复时跳过已执行的步骤。

此外，工具调用引入了一个新的信任边界：模型生成的调用参数是否合法？是否可能构成注入攻击？系统需要在模型输出和实际执行之间增加参数校验层，这是纯 Prompt 工程无法覆盖的安全需求。

第三层：工作流（Workflow）——管理多步骤任务

当任务有了明确的多个步骤，系统就要开始管理状态、分支、重试、补偿、取消或审批。这里有一个判断 Workflow 与 Agent 的黄金标准：

一个流程里可以有多个模型节点，但只要下一步仍然由代码或规则决定，它就是一个 Workflow，而不是 Agent。

这种确定性带来的最大好处是：流程更容易测试、回放和审计。

Workflow 引擎（如 Temporal、Apache Airflow、Prefect、AWS Step Functions）本质上是对有限状态机或有向无环图（DAG）的工程化实现。它们将任务拆解为离散的步骤，每个步骤有明确的输入输出契约、重试策略和补偿逻辑。关键能力包括：持久化执行状态（即使进程崩溃也能从上一个检查点恢复）、支持人工审批节点、提供可视化的执行历史用于审计。与传统的 cron 脚本或队列消费者相比，Workflow 引擎的核心优势在于"执行即记录"——系统天然知道当前走到了哪一步、为什么停在这里、下一步该做什么。这种确定性正是它与 Agent 循环的根本区别。

在实践中，大量被标榜为"AI Agent"的系统，本质上是包含模型节点的 Workflow。这并不是贬义——恰恰相反，对于绝大多数业务场景，确定性流程加上局部模型能力才是最稳健的组合。

第四层：Agent 循环——动态决策的引入

只有当路径难以提前枚举、每一步结果都可以继续验证时，才适合引入 Agent 循环。模型根据当前状态和最新反馈决定下一个动作。

但 Agent 循环也带来了新的风险：无效循环、目标漂移、成本失控、错误连续放大。因此动作范围、预算和停止条件必须一起设计，缺一不可。

目标漂移（Goal Drift）是 Agent 循环中最隐蔽的风险之一。由于大语言模型基于上下文窗口进行推理，随着循环轮次增加，早期的目标描述在注意力机制中的权重逐渐被后续信息稀释，模型可能开始追求与原始目标无关的子任务。成本失控则更为直观：每次循环都消耗 token，如果没有预算限制，一个陷入无效循环的 Agent 可以在几分钟内消耗数十美元的 API 费用。业界常见的防护措施包括：设置最大循环次数、每轮检查是否有"新信息增益"、为整个任务设定 token 或金额上限、以及引入"进展检测器"——如果连续 N 轮状态没有实质性变化，强制退出并转人工。

从架构模式来看，Agent 循环本质上是一个带有模型决策器的 while 循环。它的伪代码结构通常是：while not done: observe → think → act → update_state → check_stop_conditions。简洁的结构背后隐藏着巨大的工程复杂度，因为"think"这一步的输出是不确定的，这使得整个系统的行为空间从有限变为近似无限。

第五层：生产运行时（Production Runtime）——保障稳定交付

这一层负责持久化状态、检查点、超时恢复、取消、审计和观测等一系列能力。运行时既可以承载 Workflow，也可以承载 Agent。

需要特别澄清的是：支持断点恢复只能说明任务能在故障或等待之后继续，并不代表模型变得更聪明了。 可恢复执行是 Workflow 和 Agent 共同需要的运行时能力，而非某种 Agent 的专属特征。

可恢复执行（Resumable Execution）依赖于检查点（Checkpoint）机制，其核心思想是将任务执行的中间状态序列化并持久化到外部存储（如数据库或对象存储），使得进程崩溃、机器重启甚至跨机器迁移后，任务能从最近的检查点继续而非从头开始。这一概念源自操作系统和数据库领域的事务日志（WAL，Write-Ahead Logging），在 Workflow 引擎中被广泛采用。对 Agent 系统而言，检查点需要记录的不仅是"执行到了第几步"，还包括任务事实（已收集的数据、已完成的动作列表）、当前目标状态和剩余预算。值得注意的是，模型的上下文窗口内容通常不作为检查点的一部分——它可以在恢复时根据任务事实重新构建，这也是为什么文章强调"任务事实"与"聊天记录"必须分离。

此外，生产运行时还需要提供完善的可观测性（Observability）支持：每一步执行的耗时、token 消耗、工具调用结果、模型决策理由都应被结构化记录，便于事后分析和持续优化。

Prompt、Workflow、Agent 的职责边界

三者管理的是完全不同的范围，不能相互替代：

• Prompt 负责的是单个模型节点如何工作；
• Workflow 负责整个任务如何从开始走到结束；
• Agent 只是处理工作流中少量无法提前写死的动态决策。

换句话说，即使模型判断能力越来越强，任务状态、权限边界、失败恢复和结果验收也不会自动消失，仍然需要系统明确负责。

判断某个环节是否真的需要 Agent，可以问两个问题：第一，路径能不能提前写清楚？ 能写清楚就用代码。第二，路径难以枚举但结果能否客观验证？ 只有当路径难以枚举且结果可验证时，才考虑让模型参与判断。

这里的"可验证"是一个经常被忽视的条件。如果模型做出了一个决策但系统无法判断这个决策是否正确（例如"给用户写一封安慰邮件"），那么即使引入了 Agent 循环，系统也无法自动判断何时该停止或是否需要重试。可验证性是 Agent 自主性的前提条件。

生产级 Agent 的职责分离设计

真正的生产级 Agent 绝不是模型外面接一圈工具那么简单。它需要把任务编排、状态保存、模型决策、权限检查、工具执行、结果验证和运行治理清晰地分开，让每一部分都有明确的责任边界。

首先是运行时，负责推进步骤、控制超时和取消，并把任务事实写入持久化状态与检查点。模型上下文可以在每次调用前重新构建，但任务事实不能随一次调用结束而消失。

关键分工在于：模型负责提出动作策略，系统负责决定动作能不能执行。 模型建议回滚、发消息或修改配置，并不代表它已获得这些权限。身份、工具、参数范围、预算和人工审批都应在模型之外判断。

只有策略检查通过后，工具网关才执行真实意图，并按统一结构返回结果。

这种职责分离的设计思想，与微服务架构中的"关注点分离"（Separation of Concerns）和安全领域的"最小权限原则"（Principle of Least Privilege）一脉相承。模型本质上是一个"建议者"，而非"执行者"。这种设计使得即使模型产生了幻觉或被提示注入攻击，系统层面的策略检查仍然能够阻止危险操作的实际执行。

这里也需要澄清一个常见误区：MCP（Model Context Protocol）解决的是模型或 Agent 如何连接工具、如何交换调用信息，但它不赋予权限，也不会自动处理超时或错误。 MCP 是 Anthropic 于 2024 年底提出的开放协议，旨在标准化大语言模型与外部工具、数据源之间的连接方式，定义了工具描述、调用请求、结果返回的统一格式，类似于 API 领域的 OpenAPI 规范。它解决的核心问题是"互操作性"——让不同的模型、不同的工具提供方能够通过统一协议对接，降低集成成本。但任务是否成功，还要通过测试、数据库状态、监控指标等外部证据来验证，不能只信模型自己的说法。

审视 Agent 架构成熟度的四个关键问题

看一套 Agent 架构是否成熟，可以直接问四个问题：

1. 事实状态在哪里？
2. 动作由谁审批？
3. 成功有什么证据确认？
4. 执行失败后怎么恢复？

任何一个问题回答不清楚，这套系统就很难完整上线。以一个真实案例说明：某线上服务的 checkout API P99 延迟从 220 毫秒升到 1.8 秒，且近期有一次发布，目标是找出原因并给出可核实的证据。

P99 延迟指的是在所有请求中，99% 的请求响应时间都低于这个值，即只有 1% 的请求比它慢。相比平均值或中位数，P99 更能反映长尾请求的体验，是线上服务健康度的关键指标。当 P99 从 220ms 飙升到 1.8s，意味着有大量用户正在经历明显的卡顿。在可观测性（Observability）体系中，通常依靠三大支柱来定位此类问题：指标（Metrics，如延迟分布、错误率）、日志（Logs，记录具体事件）和链路追踪（Traces，还原一次请求经过的所有服务和耗时）。

如果只是把日志贴给模型，让它列可能原因——这只是辅助分析，界面是聊天框并不代表后端采用了 Agent 架构。而真正的做法是：系统依次取基线、检查近期发布、采集日志和链路、生成报告，每一步由代码根据状态推进，失败时能知道从哪里重试。当故障分支多到手册无法覆盖时，才把局部诊断选择交给模型——模型在指标、链路、发布、依赖这几个已注册工具中选下一项检查，结果再回到任务状态。同时系统必须加上明确边界：只开放只读工具、限制最大调用次数、连续两轮无新证据就转人工。

这个案例清晰地展示了 Workflow 和 Agent 的混合运用：大部分诊断流程是确定性的（取基线→对比发布→查日志），只有在故障分支难以穷举时才引入模型判断。这正是"确定性外层 + 动态内核"的典型模式。

Agent 架构的四个演进方向

综合来看，未来 Agent 架构有四个明确趋势，核心都是模型负责局部判断，系统负责执行、验证和恢复：

• 混合控制会越来越常见：确定性外层流程由代码推进，模型只处理难以枚举的局部判断。这种模式有时被称为"人机协同的半自主系统"，它承认了当前模型能力的边界，同时最大化利用了模型在模式识别和自然语言理解上的优势。
• 状态从对话上下文中外置：长任务需要检查点、事件驱动的暂停恢复和取消，不能依赖一个进程一直在线。这一趋势与云原生架构中"无状态计算 + 外部状态存储"的设计哲学高度一致，也使得 Agent 系统能够更好地水平扩展和容错。
• 评测从最终答案扩展到执行过程：除了结果对不对，还要检查工具选择是否合适、是否遵守限制、有没有重复无效动作、成本是否失控。这意味着 Agent 的评测框架需要从传统的"输入-输出对"扩展为"轨迹评估"（Trajectory Evaluation），关注决策路径的合理性而非仅仅关注最终输出。
• 多 Agent 不应成为默认选择：只有当角色权限确实需要隔离、任务能有效并行或不同上下文会互相干扰时，拆分才有收益，否则只是增加延迟、成本和新的故障点。多 Agent 系统面临的额外挑战包括：Agent 间通信协议设计、全局状态一致性维护、死锁检测与避免、以及整体行为的可预测性急剧下降。

Agent 架构选型的决策顺序

最后的选型顺序也很清晰：路径明确优先用 Workflow；路径难枚举但结果可验证再考虑 Agent；动作不可逆或高风险保留人工审批；任务需要跨故障继续则引入可恢复运行时。确定的流程交给代码，难以枚举且可验证的局部判断交给模型，而执行授权、验收和恢复始终交给系统负责。

这个决策顺序本质上遵循了工程设计中的"简单性原则"：在满足需求的前提下，选择复杂度最低的方案。每增加一层能力，都同时增加了新的故障模式和维护成本。一个只需要 Workflow 就能解决的问题，如果被实现为 Agent 循环，不仅增加了不确定性，还使得调试和监控变得困难。反过来，一个真正需要动态决策的场景如果被硬编码为 Workflow，则会因为分支爆炸而变得不可维护。选择正确的抽象层级，是 Agent 系统架构设计中最核心的判断。

核心要点