AI Agent可靠性：为什么最终答案并不足够

正确的输出并不能证明推理正确、执行安全或系统可信。

多年来，人工智能评估一直被一个看似简单的问题所主导：答案正确吗？对于聊天机器人来说，这有时可能就足够了。但对于一个能够搜索系统、读取数据、调用工具、修改状态、执行工作流、写入文件、与API交互或做出决策的智能体来说，这还不够。

一个智能体可能在产生正确的最终答案的同时，在过程中做了几件错误的事情。它可能使用了错误的来源，误解了指令并随后弥补了错误，访问了不必要的信息，执行了未经授权的中间操作，从本应触发升级的错误中悄然恢复，或者留下了没人注意到的副作用。

这造成了智能体AI的核心问题之一：正确的结果并不能证明正确的轨迹。

结果错觉

传统软件给了我们一个直观的正确性模型。输入进入一个确定性或基本确定性的系统，执行逻辑，产生输出，测试验证预期行为。基于LLM的系统削弱了这一假设。智能体系统则更进一步。

• 模型解释
• 检索到的上下文
• 工具选择
• 中间观察
• 外部状态
• 先前的动作
• 模型生成的计划
• 权限边界
• 重试和回退行为
• 人工交互

从几乎相同的输入开始的两个执行可能通过非常不同的路径达到相同的结果。如果评估只观察最终输出，那么系统的大部分内容仍然是不可见的。

想象一个AI智能体收到指令：更新客户的账单地址。地址最终被正确更新。传统的评估可能会将任务归类为成功。

1. 智能体搜索了几个不相关的客户记录。
2. 它检索了超出要求的更多个人信息。
3. 它最初修改了错误的账户。
4. 它注意到了错误。
5. 它撤销了更改。
6. 它更新了正确的账户。
7. 它报告成功。

最终状态：正确。系统行为：不可接受。仅基于结果的基准测试会给这次执行一个通过。生产保障系统不应该这样做。

轨迹是产品的一部分

这就是为什么AI智能体的轨迹必须成为一流的工程对象。轨迹是原始请求和最终结果之间的相关状态和动作的序列。

意图 → 上下文 → 决策 → 工具 → 动作 → 观察 → 决策 → 状态变化 → 结果

Zachary J. Stevens在《轨迹即系统》中发展了这一思想，认为智能体评估必须超越最终答案，检查在变化环境中行动的完整路径。

正确的结果并不能为不可接受的轨迹开脱。— Zachary J. Stevens，《轨迹即系统》

轨迹即系统

Zachary J. Stevens — DFEI.009 关于通过完整轨迹而非仅最终结果来评估智能体系统。

这种区别非常重要。因此，可靠性不仅仅是正确的输出。它更接近于可接受的结果 + 可接受的轨迹 + 可恢复性 + 证据。

正确答案可能掩盖系统缺陷

智能体	最终结果	执行过程
A	正确	路径安全
B	正确	路径不安全
C	错误	安全失败
D	错误	不安全失败

大多数基于基准的评估强烈倾向于A和B，而惩罚C和D。然而，在操作层面，B可能比C更危险。智能体C可能识别不确定性，停止执行并请求人工审查。智能体B可能自信地产生正确结果，同时违反无人监控的假设。

成功输出 → 信任增加 → 权限扩大 → 自动化程度提高 → 影响范围扩大

我们需要证据，而非信心

在采用人工智能时，最大的错误之一是将模型信心、用户满意度或历史成功率视为系统可靠性的证据。它们并不等同。

• 智能体接收了什么？
• 它检索了哪些上下文？
• 它调用了哪些工具？
• 为什么允许该操作？
• 操作前存在什么状态？
• 发生了什么变化？
• 发生了哪些中间失败？
• 是否有重试？
• 是否需要人工批准？
• 执行能否被停止？
• 操作能否被撤销？
• 涉及哪些模型、提示词和工具版本？

没有这些答案，就没有严肃的操作保证。只有输出。因此，可观测性和证据必须设计到智能体架构中，而不是在部署后添加。

日志记录不等于控制

组织通常回应：一切都已记录。很好。但仅记录并不能控制任何事情。日志告诉你发生了什么。控制决定某事是否可能发生。

智能体请求删除 /customer/123 ↓
操作已记录 ↓
删除已执行

这提供了可观测性。将其与以下内容进行比较：

智能体请求删除 /customer/123 ↓
策略评估 ↓
当前身份验证 ↓
当前操作参数检查 ↓
风险阈值评估 ↓
如果需要，人工批准 ↓
操作已执行 ↓
结果验证 ↓
证据存储

现在我们接近一个控制系统。差异是架构性的，而非表面性的。

权限是必要的——但它不是保证

假设一个智能体有发送电子邮件的权限。访问控制回答：这个智能体可以发送电子邮件吗？它不回答：这封特定的电子邮件是否应该发送给这个特定的人，并附带这个特定的附件，现在？

能力控制
智能体在技术上被允许做什么？ + 操作保证
在当前状态下，这个特定操作是否合适？

RBAC、OAuth范围、API权限和智能体身份定义了可能操作的空间。它们不能证明该空间内的操作是合适的。强大的智能体架构需要两个层次。

第一步走错至关重要

当代理失败时，最终的错误操作往往不是失败开始的地方。真正的失败可能发生得更早。

错误的检索 ↓
错误的假设 ↓
看似合理的推理 ↓
有效的工具调用 ↓
错误的操作

如果我们只调查最终操作，我们修复的是症状。如果我们检查轨迹，我们可以识别第一步错误。这将无法归因的失败转化为具体的工程问题。

代理测试必须超越提示测试

提示很重要，但生产环境中的代理行为源于整个系统。

模型
+
系统提示
+
上下文
+
记忆
+
检索
+
工具
+
权限
+
工作流
+
外部状态
+
控制逻辑

改变其中任何一个都可能改变轨迹。因此，仅对提示进行版本控制是不够的。

模型版本
提示版本
工具版本
策略版本
检索版本
工作流版本
环境状态
执行ID

代理的验收标准必须包含行为

传统的验收标准通常如下：给定X，系统产生Y。对于代理系统，这是不完整的。验收标准还应定义轨迹上的约束。

结果

客户的地址已正确更新。

授权

代理仅修改明确选择的客户。

数据访问

不访问无关的客户记录。

工具

仅使用经批准的CRM操作。

验证

新地址被读回并与请求的值进行比较。

失败

模糊的身份解析会停止执行。

人类权威

当风险阈值需要批准时，人类可以在执行前拒绝修改。

证据

执行留下足够的痕迹，以重建决策和状态转换。

恢复

先前的值仍然可以恢复。

人在环中还不够

添加一个人工审批框并不能自动解决问题。只有当人具备可见性、权威、时间、上下文和恢复能力时，才能控制代理。

• 可见性：足够的信息以了解正在发生的事情。
• 权威：实际停止或修改操作的能力。
• 时间：在后果发生之前进行干预。
• 上下文：足够的证据以做出决策。
• 恢复能力：撤销或修复操作的能力。

用户点击批准，但他们无法有意义地检查的内容，并不是强有力的治理。这是批准剧场。

回滚必须成为AI的原生能力

传统软件部署教会了我们一些有价值的东西：永远不要部署无法回滚的内容。我们应该将同样的原则应用于代理操作。

可逆
可以自动撤销。可补偿
不能直接撤销，但可以执行补偿操作。不可逆
无法可靠地恢复先前的状态。

不可逆性越高，控制要求就应该越强。

读取公开文档 → 低后果
创建草稿 → 可逆
修改CRM记录 → 可逆但有后果
发送外部邮件 → 实际上不可逆
转账 → 高后果
删除生产数据 → 可能造成灾难性后果

智能体需要控制平面

用户/系统意图 │ ▼ AI智能体 │ 提议的行动 │ ▼ ┌───────────────────┐ │ 控制平面 │ ├───────────────────┤ │ 身份 │ │ 授权 │ │ 策略 │ │ 风险 │ │ 状态 │ │ 证据 │ │ 人类权威 │ │ 回滚 │ └───────────────────┘ │ 批准？ / \ 否 是 │ │ 停止 ▼ 工具 │ ▼ 状态变更 │ ▼ 验证

LLM应该提出建议。控制平面应该进行治理。这种分离至关重要。模型不应成为决定其自身提议的高影响行动是否安全的最终权威。

从基准测试到运营信任

基准测试仍然有用。它们告诉我们能力、比较模型、检测回归，并帮助估计预期性能。但能力评估和运营信任回答的是不同的问题。

基准测试问：系统能做到吗？运营保障问：我们能否允许系统在此处、在这些条件下、以这些权限和后果执行此操作？

可靠性应作为系统属性来衡量

1. 结果正确性：系统是否产生了预期结果？
2. 轨迹正确性：它是否遵循了可接受的路径？
3. 控制完整性：授权、策略和干预边界是否得到尊重？
4. 可恢复性：故障能否被遏制、逆转或修复？
5. 证据完整性：执行过程能否被重建和审计？

运营可靠性
=
结果 × 轨迹 × 控制 × 可恢复性 × 证据

乘法是有意为之。如果某个关键维度趋近于零，其他方面的高分不应掩盖它。一个完全正确的输出，如果授权完整性为零，并不是一个80%可靠的系统。那是一次不可接受的执行，碰巧产生了正确的答案。

成功有时是最危险的失败

失败会引起注意。成功往往不会。这使得成功但不受控的智能体轨迹特别危险。明显的失败会引发事件。隐藏的轨迹缺陷会创造信心。而信心会扩大自主权。

因此，组织不仅应该调查为什么智能体失败了？他们还应该定期问：为什么智能体成功了？是因为架构可靠地约束和验证了执行，还是因为这次没有出错？

结论

行业正迅速从能够回答的AI转向能够行动的AI。这种转变改变了可靠性的含义。对于回答系统，评估答案往往就足够了。对于行动系统，我们必须评估路径。

提示 ↓
响应变为意图 ↓
轨迹 ↓
行动 ↓
状态变更 ↓
证据 ↓
结果

最终答案仍然重要，但它只是一个更大系统中可见的末端。一旦人工智能被允许影响现实世界，通往答案的路径就成为答案的一部分。