能够投入生产的AI智能体与未能投产的有何区别

企业 AI 对话已悄然发生转变。两年前，高管们询问他们的组织是否可以构建 AI 代理。今天，他们正在询问他们的组织是否可以信任 AI 代理。

信任问题体现在两个方面：他们已经构建并正在生产环境中运行的代理，以及开发人员日常依赖于构建软件的编码代理。在这两种情况下，大多数组织都无法信任其代理。

AI 代理的工作演示很常见，但客户日复一日依赖、随着时间的推移不断改进并能经受住现实世界边缘情况考验的代理却很少见。

缩小差距不是建模问题。这是一个验证问题。组织可以以代理的速度构建软件，但还不能以代理的速度验证软件。

传统的软件测试是一个已解决的问题：工程师编写单元测试，持续集成阻止回归，部署受到门禁限制。但 AI 代理打破了该方案背后的每一个假设。它们是非确定性的。相同的输入可能产生不同的输出。对系统提示词或工具描述的微小更改可能会级联成仅在多步工作流中出现的失败。旨在提高性能的模型升级可能会引入沉默的回归，直到客户报告时才会被注意到。

反馈循环的五个组成部分

许多工程团队仍然以最初测试代理的方式操作它们：手动、在电子表格中、迭代提示词，并希望某个修复不会悄悄破坏其他三个工作流。

商业后果迅速累积。达到工作演示阶段的项目会停滞数月，有时甚至是无限期，因为团队无法证明代理可以安全地大规模发布。工程时间消耗在“打地鼠式”的调试中。发布周期变慢。预期的投资回报率 (ROI) 没有实现，因为代理从未达到业务案例所需的面向客户的规模。

成本可见性本身也成了一个问题，因为成群的代理（包括开发人员整天在笔记本电脑上运行的编码代理）会悄悄推高财务团队无法归因的支出。将这种纪律制度化的组织与仍在即兴发挥的组织之间的差距每周都在扩大。

缩小差距的团队将 AI 代理视为软件产品，并建立在可观测性基础上的真实反馈循环。五个组成部分定义了这一基础：

1. 生产追踪利用开放标准持续流入观测层，因此每个代理决策、模型调用、工具调用、检索和响应都是可检查的。
2. 评估从脆弱的字符串匹配转向分层评估器，包括针对特定行为检查而精简范围的大型语言模型 (LLM) 评审员，以及在适用情况下的确定性代码测试。
3. 真实的生产追踪（包括失败）成为团队评估的黄金数据集，而不是合成的理想路径示例。
4. 在发布任何内容之前，针对这些数据集对比提示词、模型和配置的变化进行实验。
5. 持续集成流水线根据评估通过率来控制合并。

由于底层仪器遵循基于 OpenTelemetry 的开放标准，同样的纪律适用于云原生运行时，而不会将团队锁定在任何单一供应商的技术栈中。

新的变化以及行业的发展方向是，循环本身开始在没有人类驱动每一个步骤的情况下运行。长期运行的代理现在可以发现需要调查的问题，以拉取请求 (pull requests) 的形式提出修复方案，并在工程师监督和批准而非执行每项任务的情况下对自己的工作进行评分。

先进的测试框架

一个 AI 原生工程团队花了两年多时间构建和运行一个生产代理，帮助开发人员调试和改进其他代理。