AI Agents 102

你构建了一个在演示中勉强能用的 AI 代理，现在想将其部署给真实用户处理真实用例。演示和生产的要求截然不同；大多数代理项目正是在这个过渡阶段夭折的。

本文是爆款前作《AI Agents 101》的续篇——那篇火到甚至有人为此发了币。我们将讨论在可控条件下构建出可运行的东西之后，接下来该做什么。让我们开始吧。

为什么演示无法转化为生产环境

一旦真实用户开始与你的系统交互，演示代理所依赖的条件将不复存在。

当你演示代理时，你会选择能展示其能力的输入，这意味着你知道哪些例子效果好、哪些不好。生产环境不会给你这种奢侈——用户可能发送任何内容，从模棱两可的表述到不完整的信息。大量请求超出了代理的设计范围，最终会破坏你的解析逻辑。

当你演示代理时，你会全程盯着它工作，一旦出错能立刻发现并干预。这让你有机会解释发生了什么，或重新输入不同内容。生产环境中的代理需要自主运行，无人监控每一次交互。这导致故障在日志中不断累积，直到客户开始投诉——比如收到错误的工单，或造成架构性破坏。代理本身可能做出数百个糟糕决策，随后需要人工清理。

人们本能地回避边缘情况，因为它们会让讲述复杂化、拖长演示时间，但这恰恰是生产代理证明其价值或制造最大麻烦的地方。常见的、简单的情况通常容易处理，用更简单的自动化就能解决。而那些古怪的情况，才真正体现代理是展现真正的智能，还是暴露其脆弱性。

生产环境中的代理往往运行长时间的会话，上下文会在多次交互中不断累积，因此状态管理变得至关重要。上下文窗口限制成为真正约束，因为大会话会填满可用 token，迫使你决定保留什么——这通常是构建生产级代理时最重要的决策之一。

弥合这一差距需要在三个领域下功夫：强化代理以应对真实世界条件、构建评估系统、以及创建能持续改进的知识基础设施。

生产环境代理的六大支柱（注意，很多其实就是软件工程）

输入验证与标准化 —— 应在代理核心逻辑看到数据之前完成。明确定义你接受的输入格式，构建预处理层对传入数据进行格式验证。格式不匹配时，直接拒绝并返回错误信息。例如：如果你的代理需要产品名称，构建一个标准化层来处理常见拼写错误、缩写、大小写变体等。

优雅降级 —— 为代理无法完成预期任务的情况定义明确行为。你需要决定：代理是应返回一个部分结果并清晰指出缺失内容，还是应先向用户询问澄清再继续？最糟糕的结果是代理在出错时无声无息地产生垃圾输出。

超时与重试逻辑 —— 承认外部依赖不可靠。API 可能因维护宕机，数据库可能因意外负载变慢。当这些调用失败时，你的重试逻辑应能区分临时故障（如临时速率限制）和永久故障（如无效凭据）。临时故障应采用指数退避重试：等待短时间后重试，失败则等待更长时间，最多尝试 n 次。

状态检查点 —— 在工作流的自然边界处定义检查点，此时代理已完成有意义的阶段性工作。将当前状态保存到持久化存储中，包括代理恢复所需的一切：接收到的输入、已做出的决策、剩余待办事项。如果代理在执行过程中崩溃或超时，它可以从最近的检查点加载并恢复，而无需从头开始。

速率限制与资源管理 —— 保护你免受失控成本的影响。一个在循环中调用 API 而不设限的代理，可能产生数千美元的费用。因此，你需要为代理消耗的每项资源设置明确限制：每分钟最大 API 调用次数、每任务最大数据库写入次数、每会话最大生成 token 数、每工作流最大执行时间。监控消耗是否接近这些阈值，并在接近时发出警报。

审计日志 —— 帮助你捕获代理的决策，并提供足够的上下文来理解其决策原因。对于每个操作，记录：代理响应的输入状态、代理检索到的任何外部数据、推理过程、代理选择的动作、该动作的参数、执行后的结果、以及遇到的任何错误条件。结构化存储这些日志，以便可以以编程方式查询和分析。如果出现问题，请检查日志。

简化代理评估

大多数团队要么完全跳过系统化评估（依赖手动测试和感觉），要么构建过于复杂的评估基础设施。这两种方法都会失败，因为前者让你对代理行为毫无信心，后者则创建了与现实脱节的评估系统。

评估需要回答关于代理的三个核心问题：1）在应该行动的情况下，它是否做了该做的事？2）在不应行动或信息不足的情况下，它是否避免了行动？3）在用户和业务最关心的案例上，它的表现是否可接受？

黄金数据集是系统化评估的基础。你可以从领域中的真实示例收集，如果有实际用户交互数据就更理想。对于黄金数据集中的每个示例，记录：代理接收到的确切输入、期望的输出或动作、该输出正确的原因、以及任何相关元数据（如案例类型或难度级别）。对于范围狭窄的任务（你的第一个代理应该如此），大约 100 个示例就足够了；重点关注后果真正重要的那些情况。

指标应反映实际重要的东西，而不是将所有内容简化为一个隐藏重要差异的准确率数字。如果 90% 的案例是简单的，10% 是复杂的，一个能完美处理简单案例但无法处理困难案例的代理，会显示 90% 的准确率，却在那些真正需要代理智能的案例上提供糟糕的价值。

评估应集成到你的开发工作流中。可以配置 CI/CD 流水线，在每个涉及代理逻辑的拉取请求上执行评估套件。如果评估分数低于可接受阈值，则阻止合并更改，直到有人调查回归是否真实以及如何解决。

注意：本节（坦白说，其他节也一样）本身就可以写成整本书。我故意简要说明，给你一个深入研究的起点。我强烈建议你这样做。

能自我改进的知识基础设施

代理依赖知识来完成工作——这可以是产品信息、公司政策、历史上下文、领域专业知识等。你如何管理这些知识，决定了你的代理是随着时间的推移变得更智能、更准确，还是逐渐退化。

常见知识存储模式包括：用于非结构化文档语义搜索的向量数据库、用于具有清晰模式的机构化事实数据的关系或文档数据库、以及用于显式策略的配置文件。正确选择取决于知识将如何被查询以及变更频率。大多数生产系统会组合使用，将不同类型知识放在适合其访问模式的不同存储中。

对所有知识变更进行版本控制，可以让你了解何时发生了什么变化、诊断行为偏移，并且如果更新导致问题还可以回滚——当你的代理开始表现异常时，这一点尤其有用。如果知识变更未被追踪，你无法回答这个问题，调试将变得更加困难。所以，请使用版本控制。

生产环境下的多代理编排

某些工作流超出了任何单个代理的有效处理能力，这主要是因为上下文窗口限制。该限制通常阻止单个代理在复杂的多步骤过程中维护所有相关信息，这就是为什么你需要多个代理并行运行，各自拥有独立的上下文窗口。

但代理越多，评估也越多，意味着需要照顾的故障节点也越多。这就是管道架构重要的原因。管道架构将代理按顺序排列，每个代理完成其工作后将结果传递给下一个。例如：代理 A 接收原始输入并执行分类，确定请求类型及应走哪条下游路径；代理 B 接收分类后的输入并执行核心处理，应用业务逻辑，生成初始输出；代理 C 接收这些输出，处理最终格式化响应。

并行架构同样重要。它们同时运行多个代理处理同一输入的不同方面，在所有代理完成后合并结果。一个交易审批工作流可能并行运行法律审查代理、财务分析代理和技术评估代理，每个代理从各自专业角度审查交易。

生产就绪检查清单

在部署代理处理实际工作之前，需要确保以下内容就绪：

输入处理：代理是否验证输入是否符合预期格式？标准化是否能处理用户实际发送的常见变体？

故障模式：是否为每个外部依赖故障定义了降级行为？代理是否能在缺乏足够信息继续时识别？

资源管理：是否为所有外部调用配置了超时？重试逻辑是否能区分临时故障和永久故障？

可观测性：审计日志是否捕获了每个决策的完整上下文？事后能否从日志重建代理推理过程？

评估：你的黄金数据集是否覆盖常见情况、边缘情况和高风险情况？代码变更时，评估是否自动运行？

知识：知识是否从代理代码中外部化？知识变更是否经过版本控制和追踪？

人工监督：是否定义了升级标准？升级请求是否包含足够的上下文供人类快速解决？

这份检查清单将为你提供正确的基础设施，开始考虑如何将代理部署到生产环境。希望你能从中找到有用的东西。

如果你是企业，需要为内部流程构建 AI 代理，请访问 varickagents.com 预约免费 AI 审计。

如需每周获取关于构建能适应真实世界环境的代理的见解，请订阅 varickagents.com/newsletter。