AI Agent 架构：生产环境中真正有效的方案

一家公司交付了 7,949 个 AI Agent。其中只有 15% 能够正常工作。其余的要么静默失败，要么陷入死循环，或者在执行任务中途前后矛盾。这并非个别现象——企业级分析一致发现，88% 的 AI Agent 项目从未进入生产阶段，95% 的生成式 AI 试点项目以失败告终或表现严重不及预期。引人入胜的演示 (Demo) 与可靠系统之间的差距并非模型问题，而是架构问题。

那些成功交付了实际可用 Agent 的工程师们，在架构决策上达成了一系列共识，而这些决策与框架教程中的玩具示例截然不同。本文将探讨这些决策：层级如何划分、故障集中在哪里，以及为什么最难的问题从来不是提示词 (Prompt)。

每个生产级 Agent 都需要的五个层级

无论使用何种框架或领域，任何经受住生产环境考验的 Agent 系统都可以分解为五个关注点：

感知 (Perception) 是模型接收到的信息。它包括文档解析、多模态预处理，以及至关重要的过滤。大多数生产系统在信息进入推理循环之前，会先进行相关性评分和去重。你排除掉的内容与你包含的内容同样重要。

推理 (Reasoning) 是 LLM 的核心。两种主流模式是 ReAct（一步一动地进行迭代推理和行动）和“计划-执行”（Plan-and-Execute，先进行前期分解，再执行）。ReAct 能更好地处理不确定性，但消耗的 Token 更多，且单次请求成本难以预测。“计划-执行”对于稳定且范围明确的任务来说更快、更便宜，但如果初始计划错误，就会失败。大多数生产团队两者兼用：对常规工作流使用“计划-执行”，对探索性或异常路径使用 ReAct。

记忆 (Memory) 是大多数生产环境故障的根源（下文将详细展开）。

工具执行 (Tool execution) 是集成层——调用 API、查询数据库、写入文件。这里是安全漏洞、成本超支和级联错误的源头。

编排 (Orchestration) 通过状态管理、检查点和控制流将所有环节串联起来。行业已明确转向基于显式图 (Graph) 的状态机，而非开放式的 Agent 循环。

记忆即系统

最常见的生产故障模式并非模型失败，而是记忆失败。Agent 会重复获取在同一会话中已完成的数据抓取。它们会推翻两个工具调用之前做出的决定。它们在第 1,000 次会话中的表现与第 1 次不同，因为运行之间没有任何持久化。这些 Bug 比模型错误更难重现，也更难修复，因为它们是架构层面的。

生产团队已经总结出四种不同的记忆层级，每种都有不同的实现要求：

工作记忆 (Working memory) 是当前上下文中的内容——当前任务、最近的工具执行结果、活跃的约束条件。硬性限制约为 8,000 个 Token；超过此限制会导致延迟增加 40–60%，并降低指令遵循能力。超出此限额的每个 Token 都会带来双重负担：推理成本和质量损失。保持精简的工作记忆不是一种优化，而是一个正确性要求。

情景记忆 (Episodic memory) 存储过去交互的结构化记录：Agent 可以查询带有时间戳的 JSON 事件。在实践中有效的检索模式结合了语义搜索和时间权重，因为五分钟前的工具调用几乎总是比三天前语义相似的调用更具相关性。纯向量嵌入 (Embedding) 搜索会忽略这一点。

语义记忆 (Semantic memory) 保存关系知识——即不属于单个会话但需要通过关系进行推理的事实。知识图谱在此处的表现优于扁平的向量嵌入存储，因为关系查询（谁批准了什么、哪家供应商处理哪种合同类型）具有向量相似性无法表达的结构。随着知识库的增长，语义记忆需要定期执行合并任务来解决矛盾。

程序记忆 (Procedural memory) 将成功的工作流轨迹存储为可复用的模板。实施该方案的团队报告称，常规任务的计划错误减少了 30–50%，因为 Agent 不需要重新推导已经解决过的工作流。

实践中的启示是：如果你的 Agent 没有明确的记忆架构，那么你只拥有工作记忆。这意味着每个会话都从零开始，每个重复任务都会消耗全部推理成本，且每次失败都不会为未来的运行留下可规避的痕迹。

编排与路由：一个关键区别

大多数团队从路由 (Routing) 开始——基于规则的分发，将计费问题发送给计费 Agent，将支持请求发送给支持 Agent。路由是有效的，也是正确的起点。但当任务需要跨多个步骤持久化的状态、当故障需要恢复而非重启、或者当需要人工审批中断正在运行的工作流时，路由就会失效。

编排 (Orchestration) 是有状态的版本：基于图的工作流管理，节点代表工具调用和 LLM 调用，边代表允许的转换，检查点则允许暂停、恢复和重放。业界已将此术语定为“流程工程” (flow engineering)——将 Agent 行为视为图遍历问题，而非提示词问题。

权衡是现实存在的：基于图的编排需要分布式系统知识、状态持久化策略以及显式的调试基础设施，而简单的路由器则不需要。缺乏这些背景的团队往往低估了实现成本。但另一种选择——没有显式状态机的开放式 Agent 循环——所产生的系统在生产中无法调试，且几乎不可能达到可靠性。

对于多 Agent 系统，三层层级结构在任何工作节点启动前至少会增加 6 秒的协调开销（每层大约需要 2 秒的 LLM 调用时间）。只有当分解带来的收益——并行化、领域专业化、故障隔离——超过这些协调成本时，多 Agent 架构才值得构建。

工具调用的实践

模型上下文协议 (MCP) 已成为工具集成的行业事实标准，将集成复杂度从 N×M 次实现降低到了 N+M。但一项针对生产环境 MCP 工具描述的研究分析发现，89.8% 的描述存在未说明的限制，89.3% 缺失使用指南，84.3% 的参数含义模糊。标准本身是完善的，但生态系统的文档说明却并非如此。

这意味着在实践中：不要盲目信任工具描述。已经交付可靠工具调用智能体的团队通常会强制执行显式的最大工具调用次数，在执行前严格验证可用工具，并将工具错误视为预期事件（配合重试逻辑），而非异常失败。

另一个关键模式是：将工具调用结果保持在主对话上下文之外。在长运行工作流中，将工具结果堆积在对话线程中是突破上下文限制最快的方式。相反，应该总结结果并将其存储在情节记忆 (episodic memory) 中。

一个值得明确指出的失败模式：轮询反模式。使用请求-响应 API 持续轮询更新的智能体，其 95% 的 API 调用都是浪费的，因为基础设施模型与智能体的事件驱动需求不匹配。如果你的智能体需要等待某事发生，请设计一条事件通知路径，而不要使用轮询。

上下文工程取代了提示词工程

主导 2023 年和 2024 年的框架是提示词工程 (prompt engineering)：即你如何与模型交流。而主导 2025 年生产环境的框架是上下文工程 (context engineering)：即模型在每一步拥有哪些信息。

一个生产级上下文流水线在推理时包含五个动态组装的层级：

1. 系统指令
2. 检索到的知识 (RAG 输出，经过相关性过滤)
3. 持久记忆 (相关的清洁和语义记录)
4. 对话历史 (经过压缩)
5. 工具定义

这种顺序并非随意。模型会过度关注上下文窗口的开头和结尾。系统指令和与任务最相关的上下文应放置在边界位置。中间的填充内容（冗长的工具 schema、无关的历史记录）会降低模型遵循实际指令的能力。

那些构建了运行时动态组装显式上下文流水线的组织报告称，与静态提示词模板相比，响应延迟改善了 50%，输出质量提高了 40%。这种差异并非源于模型能力的提升，而是源于信息架构。

七大失败模式

对失败的企业智能体部署进行的分析发现，七种模式占了生产环境失败案例的 94%：

范围蔓延 (34%) 是最常见的。一个“有限自动化”项目——旨在自动化特定工作流——在构建过程中扩展成了边界不明的开放式推理系统。解决方法是在架构开始前签署书面的范围合同，并明确排除项。

数据质量 (27%) 排在第二。智能体不像人类那样能容忍不完整或过时的数据——它们会将错误在工具调用链中放大。一个查询含有 15% 过时记录数据库的智能体，产生的不仅仅是 15% 的错误答案；它会以高置信度在整个过程中产生微妙的错误答案。

安全阻碍 (14%) 往往发现得太晚。在人类工作流中看似合理的访问控制，当智能体需要跨系统自主行动时，就会变成架构问题。解决方法是在系统设计完成前（而不是在评审阶段）引入安全审查。

其余四种——集成复杂度 (9%)、成本超支 (7%)、治理缺口 (5%)、组织阻力 (4%)——虽然也都很重要，但通过标准的工程实践更容易解决。

值得特别关注的失败模式是从业者所说的“愚蠢的 RAG” (dumb RAG)：将整个数据仓库直接塞进向量数据库，并检索 top-k 结果而不进行相关性或矛盾过滤。结果是上下文窗口充斥着冲突信息，模型产生高置信度的幻觉——因为它拥有支持正确和错误答案的两种证据。解决方法是采用具有显式相关性阈值的分层检索，而不仅仅是嵌入相似度。

为可靠性指标而设计

在 20 步的智能体工作流中，5% 的单步故障率会导致端到端成功率仅为 64% 左右。如果不进行人工监督，这种智能体在每次运行中都是不可用的。自主智能体的生产目标是单步故障率低于 1%。这需要显式的错误处理、带退避机制的重试逻辑、工具失败时的优雅降级，以及设置检查点 (checkpointing) 以便失败后能继续运行而非重启。

不同类型智能体的延迟目标已趋于标准化：

• 简单查询智能体：P95 低于 1,000ms
• 复杂工作流智能体：P95 低于 4 秒
• 多智能体编排：P95 低于 6 秒
• 语音智能体：首个音频字节 P95 低于 800ms

语音智能体是最难的情况。语音智能体系统的典型 P99 延迟处于 8–15 秒之间——这 1% 的异常值在规模化运行时每天代表着数千次糟糕的体验。

智能体性能存在基准测试容易忽略的一致性问题：在单次运行评估中获得 60% 成功率的智能体，在针对同一任务进行 8 次运行测量时，成功率往往会降至 25%。规模化的一致性与测试集上的准确率并不是一回事。

将人机回环作为架构

对人类监督的正确定义并非“添加一个确认步骤”，而是在架构初期就内置的分级风险模型：

• 第 1 级（低风险，可逆）：自主执行
• 第 2 级（中等风险，可逆）：执行并通知
• 第 3 级（涉及财务、法律或不可逆）：执行前需审批

这些分级需要针对每个工具和工作流进行明确定义，而不是根据通用直觉进行推断。Agent 发送 Slack 消息属于第 1 级。Agent 发送面向客户的电子邮件属于第 2 级。Agent 修改生产数据库记录属于第 3 级。这些界限需要存在于状态机中，而不是提示词（prompt）里。

可观测性是另一个不可逾越的底线。生产环境中的 Agent 系统需要捕获 Agent span、工具调用序列、token 计数以及安全过滤结果，其格式必须支持调试——而不仅仅是日志记录。OpenTelemetry 生成式 AI 语义约定已成为标准。如果你无法在一个失败的会话中准确重建 Agent 做了什么以及为什么这么做，你就无法修复该故障。

这对你的构建方式意味着什么

AI Agent 市场是真实存在的且增长迅速——企业采用率已超过 57%，这些组织都在生产环境中部署了 Agent。失败率也是真实存在的。差距不在于模型能力；模型能力的差距正在迅速缩小。真正的差距在于周边系统：状态管理、数据基础设施、集成架构、安全设计和可观测性。

那些交付可靠 Agent 的工程师已经不再将 Agent 开发视为提示词问题，而是将其视为分布式系统问题。同样的原则也适用：组件之间明确的状态契约、类型化接口、预先设计的故障模式、从第一天开始的可观测性，以及具有清晰边界的增量范围。

难点不在于演示（demo）。自 2023 年以来，做 demo 一直很容易。难点在于“回环”——即当同一个任务在真实数据环境下运行 10,000 次，且面临工具失效和输入混乱时，如何确保其可靠性。这个问题需要通过架构来解决，而不是靠更好的提示词。