话说回来，

过去两年。AI Agent 的能力曲线涨得非常快。它们能写代码、查资料、调用业务 API、操作浏览器，也能把一个模糊目标拆成几十个步骤连续执行。老实说，

这很容易制造一种错觉：只要下一代模型再聪明一点。Agent 就会自然跨过 Demo 与生产之间的鸿沟。

但真实情况恰好相反。模型能解决的任务越来越难，公司把关键业务交给 Agent 时仍然十分谨慎。问题不再只是“它会不会”，而是：同一个任务连续运行十次它能否十次都做对；发生异常时它能否发现、恢复，而且不越权、不失控。

如果必须给当前 AI Agent 的最大瓶颈取一个名字，我认为它不是上下文、幻觉、成本、安全或 ROI 中的某一项。而是这些问题的共同上游：

可靠性不是模型排行榜上的一个分数，而是一套程序在长链路、重复运行、异常环境和真实权限下持续产生正确结果的能力。

模型、上下文、工具、执行环境和治理中任一环节失效，都可能把任务带入另一条轨迹。

一、能力上限在提高，但“能完成”不等于“可托付”

• 公司关心的是重复性与可审计性而不是单次成功率。
• 从使用者痛点来看，一次性的高成功率无法满足日常运营需要； 难道不该持续稳定交付吗，

METR 指标说明

METR 提出的 task-completion time horizon，经常被用来描述 Agent 能处理多长的人类任务。这个指标的定义并不是 Agent 自己运行了多久。而是：对于需要人类专家花费某个时长的任务，Agent 达到指定成功概率时对应的任务时长。

现实与测试场景差距

• 实际工作更复杂：涉及人类判断边界不清晰，难以自动评分。
• User Pain Point: 现有指标无法反映实际工作中的“不干净”因素，如异常数据、不完整信息等。

二、长任务为什么天然不可靠：成功率会沿链路相乘

单步正确率与链路衰减关系

P = p₁ × p₂ × …× pₙ = ∏ pᵢ，即使单步 % 看起来已高，但 n 步后整体成功率急剧下降。例如 p=0.9 且 n=20 时总体仅约 12%。

pass^k 指标关键性

• User Pain Point: 单次通过不能保证每天几千次操作都使用较稳定；需关注多次连续通过率，
• 业务风险：低频错误若无检测，将演变为高频生产事故。

真正有效的方向不是“祈祷不犯错”。而是引入纠错

三、单步为什么也不稳定：上下文、工具和环境都在制造噪声

有限注意力预算 vs 长

• Context rot：
• 噪声累积：
• 常用方法：

工具调用导致现实副作用

• 工具选择错误：
• 工具使用错误：

User Pain Point: 公司担心因工具调用错误导致不可逆损失，需要严格校验与审批机制。

环境不可预测性

• 异常文本混入事实库：

User Pain Point: 实际程序经常遇到网络抖动或第三方服务故障。一旦未及时归类处理，将影响整个流程稳定性。

四、可靠性为什么难调试：Agent 不是确定性函数

• 输入相同却输出不同：