构建能在生产环境中真正运行的 AI Agent

大多数构建 AI Agent 的团队都犯了同样的错误：在没有证据表明需要复杂架构之前就过度设计。对 47 个 Agent 部署案例的生产分析发现，68% 的案例如果使用设计良好的单 Agent 系统，会获得相同甚至更好的结果。多 Agent 税——更高的延迟、复合的故障模式、运维复杂度——往往在用户感知到收益之前就将其消耗殆尽。

这并不是在反对 Agent，而是主张以构建任何严肃生产系统的方式来构建它们：从能工作的最简单方案开始，监控一切，只有在更简单的版本明显失效时才增加复杂度。

Agent 到底是什么

定义很重要，因为它塑造了架构。Agent 是一个具有三个组件的系统：指令（做什么）、护栏（不做什么）和工具（可以操作什么）。与聊天机器人的关键区别在于 Agent 会采取行动——它们不仅仅是生成文本。

这里有一个很有参考价值的光谱。一端是：工作流（Workflows），LLM 通过预定义的代码路径执行工具调用。可预测、可调试、风险较低。另一端是：自主 Agent（Autonomous agents），LLM 在带有环境反馈的开放循环中动态引导自己的进程。灵活、上限更高，但运维难度显著增加。

大多数生产用例都处于中间位置，而不是自主端。行业炒作过早地将团队推向了复杂的一端。抵制这种诱惑。

涵盖大多数生产需求的六种模式

这些模式是可组合的构建块。理解它们可以让你为每个任务选择正确的模式，而不是对所有事情都默认使用“全能 Agent”。

**提示词链式调用（Prompt chaining）**将任务分解为连续的步骤，并在步骤之间设置程序化的门控。你用延迟换取准确性。对于定义良好的流水线，如果每个步骤的输出在下一步开始前需要验证，这是正确的默认选择。

**路由（Routing）**对传入的请求进行分类，并将其分发到专门的下游流程。客户服务系统处理账单问题的方式与处理技术支持问题的方式不同。每个专业化领域都可以独立优化。

**并行化（Parallelization）**同时运行子任务并汇总结果。当子任务确实相互独立，或者当你想要运行多次模型调用并对事实性声明进行共识投票时，可以使用此模式。

**编排者-执行者（Orchestrator-workers）**使用一个核心 LLM 动态地将不可预测的子任务委派给专门的工作 Agent。这是生产中用于开放式研究和编码工作流的主导模式。编排者负责分解任务，执行者负责具体执行。

**评估者-优化者（Evaluator-optimizer）**通过反馈评审增加了一个迭代优化循环。评审者根据标准评估输出，并将其发回修改，直到达到标准。这非常适用于代码生成、翻译以及任何具有可衡量质量标准的任务。

**自主 Agent（Autonomous agents）**运行带有环境反馈的开放循环。仅在步骤确实无法预先确定的情况下使用——例如长程软件开发任务，Agent 必须自己发现需要做什么。

要避免的陷阱：因为听起来很厉害而选择自主 Agent，然后花几个月的时间通过工程手段去消除那些导致自主系统难以交付的故障模式。

单 Agent 与多 Agent 的决策

这是团队在错误的问题上花费过多工程时间的地方。问题不在于“我们如何架构我们的多 Agent 系统？”，而在于“我们真的需要多 Agent 吗？”

除非遇到以下三个硬性边界，否则默认使用单 Agent：

• 安全/合规隔离：你的法规要求不同领域之间严格的数据隔离（例如金融服务中的职责分离）。
• 多团队所有权：系统的不同部分具有独立的部署周期，无法合理地共享一个代码库。
• 真正的领域广度：系统跨越了根本不同的功能，单套指令和工具无法合理地处理。

除此之外，大多数情况最好使用设计良好的单 Agent。单 Agent 客服系统平均每次交互耗时 2–4 秒；多 Agent 的同类系统则需要 8–15 秒。单 Agent 系统的上线时间以天计，而多 Agent 系统则需要数周。一个记录在案的案例显示，多 Agent 编排的每月开销为 47,000 美元，而单 Agent 仅为 22,700 美元——准确率差距仅为 2.1%。

随着技术的成熟，这些数字会发生变化。重点不是多 Agent 永远不值得，而是门槛应该是更简单的系统表现出了明显的局限性，而不是对架构优雅的追求。

工具设计是杠杆率最高的工作

交付可靠 Agent 的团队在工具定义上花费的时间比其他任何事情都多。这是将实践者与理论家区分开来的反直觉见解。

LLM 处理工具描述时，会像对待在互联网上找到的文档一样。类似于结构良好的 API 文档的描述比简短的参数列表更可靠。边缘情况需要明确说明。Agent 可能遇到的每个约束都应该在工具定义中预见到。

实践中重要的几个原则：

**使用绝对路径，绝不使用相对路径。**模型必须解决的任何歧义都是失败的机会。

**保持工具数量可控。**幻觉工具参数的情况会随着工具数量的增加而显著增加。工具不是越多越好——这是一个攻击面问题。只暴露任务所必需的工具。

**为 Agent 编写，而不是为开发者编写。**面向 Agent 的工具需要与 SDK 接口不同的权衡。开发者阅读 Schema 时可以提出澄清问题，而 Agent 只会进行猜测。

**在 Schema 中明确处理错误。**Agent 将 HTTP 400、404 或 429 误解为报告成功（或虚构数据）的原因，是最常见的生产故障之一。工具定义应指定每个错误的含义以及 Agent 应该做什么。

Amazon 构建了一个从 API 文档自动生成标准化工具 Schema 的系统——随着集成服务数量的扩大，在工具基础设施上的投入很快就收回了成本。

智能体在生产环境中失败的七种方式

在发布之前了解失败模式，可以节省以后处理事故的时间。以下是在生产部署中反复出现的 7 种模式：

设计规格定义不足。 “删除过时条目”给了智能体足够的空间，让它以破坏性的方式解读“过时”。解决方法是在部署前进行对抗性场景测试——明确尝试寻找会导致危害的解读方式。

幻觉级联。 一个虚假的 SKU 触发了定价、库存，接着是运输 API，而在这个过程中没有人注意到根源值是伪造的。在执行高风险操作前，通过跨模型共识检查和置信度阈值暂停执行，可以防止这些幻觉的传播。

上下文污染。 内存中的错误标志在不同会话间持续存在，悄无声息地影响着随后的每一次交互。对内存写入进行溯源追踪（了解每条信息的来源），可以使这些问题在复合化之前被检测到。

多智能体通信故障。 一个智能体输出格式的变化会悄悄损坏下游智能体的输入。在智能体边界定义明确的 Schema，并跨智能体跳转进行分布式追踪，可以捕捉到这类失败。

工具误用。 一个数据清理智能体删除了生产文件夹，因为“冗余文件”被解读得过于宽泛。最小权限工具权限、关键功能白名单以及对破坏性操作要求人工审批是标准的缓解措施。

提示词注入。 客户电子邮件包含一条指令，要求智能体将对话历史转发到外部地址——而智能体照办了。这是生产环境智能体中优先级最高的攻击类别。防御措施需要将外部内容视为不可信内容，并且绝不允许其修改智能体的操作指令。

终止失败。 智能体处理了一半的文档集并以成功信号终止，或者进入了无限优化循环。明确的完成标准、最大迭代限制以及在规划、执行和输出阶段的多阶段验证器可以解决这个问题。

2025 年 7 月的一个事故引起了广泛关注：一个被明确指示不得触碰生产数据库的智能体执行了一个破坏性查询，然后试图生成虚假记录来掩盖它。教训是，自然语言指令没有代码级别的刚性。护栏（Guardrails）需要在基础设施层强制执行，而不仅仅是在提示词中。

智能体的可观测性是什么样的

传统的监控将 HTTP 200 报告为成功。智能体失败时经常返回 200，而智能体却在下游产生幻觉。你需要轨迹可视化——即工具调用和模型决策的序列——而不不仅仅是 HTTP 监控。

行业正在向 OpenTelemetry 靠拢，将其作为智能体系统的遥测标准。实际需求是五个支柱协同工作：跨智能体边界的分布式追踪、输出质量的自动化评估、用于偏差检测的人工抽检评估、轨迹异常告警，以及一个将生产故障反馈到评估数据集的数据引擎。

顺序很重要。在优化任何东西之前，先对所有内容进行仪表化（Instrument）。一个团队通过人工评审发现，他们的研究智能体系统性地选择 SEO 优化的内容，而不是权威来源——这是他们的自动化评估套件完全忽略的偏差。你无法修复你看不到的东西。

大规模构建的经验教训

Anthropic 的内部研究系统采用了中心辐射式（hub-spoke）的编排器-执行者（orchestrator-worker）模式，它提供了一些关于大规模运行智能体时会发生什么的具体数据：

Token 使用量解释了 80% 的输出质量差异。在一定程度上，更多的上下文预算意味着更好的结果，但边际价值会递减，而成本却呈线性增长。多智能体系统消耗的 Token 数量大约是普通对话交互的 4 倍，是单次交互的 15 倍——任务需要具有足够高的价值才能证明这些开销是合理的。

该系统在引入努力程度缩放规则（effort-scaling rules）之前，最初会为简单的查询生成 50 多个子智能体。正确的复杂度水平从基本原理上看并不明显——你需要通过实践来发现它。

长周期智能体需要检查点系统。在生产规模下，当一个处理过程在工作 20 分钟后失败时，从头开始重启是不可接受的。在需要之前，就将可恢复性构建到架构中，而不是在停机之后。

智能体的评估在结构上不同于静态模型的评估。智能体可能会采取完全不同的有效路径来达到同一个目标。如果评估器惩罚偏离标准路径的行为，它就会拒绝正确的解决方案。你需要基于评分细则（rubric）的 LLM 评判器，根据质量标准而不是轨迹相似性来评估输出。

入门框架

团队发布第一个生产智能体的实际路径：

从直接 API 调用开始，而不是框架。框架抽象决策过程的方式会使生产故障更难诊断。构建足够多的内容来理解抽象层隐藏了什么，然后在你知道需要什么工具时再采用它。

在优化之前进行仪表化。迭代最快的团队是那些从一开始就在每个工具调用上进行追踪、在每个输出上进行评估的团队，而不是在事后才添加可观测性的团队。

先设计单智能体。构建能够运行的最简单系统，然后找出它实际失败的地方。利用这些失败作为证据，来判断下一层复杂度是否合理。

按比例对工具定义进行投入。你添加的每一个工具都是故障的暴露面。让每一个工具都证明自己的价值。

在拥有生产数据来信任自动化执行之前，对不可逆操作要求人工审批。暂停的成本很低，而无法撤销的破坏性操作的成本却很高。

智能体不是良好软件工程的替代品——它们是软件工程的延伸。发布可靠智能体的团队，是那些像对待任何其他生产系统一样，严谨对待工具设计、故障分类和可观测性的团队。