AI Agent 目前最大的瓶颈是什么？

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

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

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

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

可验证的系统可靠性。

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

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

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

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

例如，50% time horizon 表示 Agent 对这一难度的任务预计有一半概率成功。METR 同时提醒，这些任务主要来自软件工程、机器学习和网络安全，往往边界清晰、可以自动评分；它们比现实工作"干净"得多。一个八小时的时间跨度，并不等于 Agent 可以替代任何岗位八小时的工作。 $1$

这个区别非常重要：

能力指标关心的是能否完成一部分高难度任务。
生产系统关心的是能否重复、稳定、可审计地完成指定任务。

如果一个 Agent 有 50% 概率完成两小时任务，它是很有能力的研究对象，却还不是可以无人值守运行的生产组件。企业系统通常还要求权限边界、异常恢复、结果可验证、操作可回滚，并对错误成本承担责任。

所以，Agent 真正需要跨越的不是从"不会"到"会"，而是从"偶尔能做对"到"错误被约束在可接受范围内"。

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

一个 Agent 任务通常包含多次观察、判断和行动。把第 i 个关键步骤的正确率记作 p_i，在没有校验和恢复机制时，所有步骤都正确的概率近似为：

text 复制代码

P(任务成功) = p₁ × p₂ × ... × pₙ = ∏ pᵢ

如果为了便于理解，假设每一步的正确率相同，都是 p，那么：

text 复制代码

P(任务成功) = pⁿ

单步 95% 看起来已经很高，但连续执行 20 个关键步骤，整体成功率只有：

text 复制代码

0.95²⁰ ≈ 35.8%

即使单步成功率提高到 99%，运行 50 步后的理论整体成功率也只剩约 60.5%。这不是某个框架的 Bug，而是串联系统的基本规律。关于多步预测中误差被放大的问题，在模型式强化学习研究中已有系统讨论。 $2$

单步正确率越接近 100%，链路衰减越慢，但不会消失。 更现实的系统还存在相关错误，因此简单独立假设往往偏乐观。

2.1 平均成功率会掩盖重复运行的不稳定

tau-bench 提出了 pass^k，用于衡量同一类任务连续运行 k 次、每次都成功的概率。论文报告称，当时的先进函数调用 Agent 在零售任务上的 pass^8 仍低于 25%。 $3$

如果一次任务的成功率是 s，在各次运行近似独立时：

text 复制代码

pass^k = sᵏ

对演示来说，运行一次成功就足以录屏；对客服、财务、合同审查和运维来说，每天运行几千次，低频错误必然会变成稳定发生的生产事件。

这也是为什么 Agent 的验收不能只看 pass@1 或一组平均分。至少还要观察：

多次重复执行的一致性；
长尾输入和边缘场景；
错误能否被检测，而不是带着错误继续运行；
错误发生后的恢复成本；
有副作用操作的越权率和回滚率。

2.2 真正有效的方向不是"祈祷不犯错"，而是引入纠错

MAKER 研究展示了一个很有启发性的极端案例：通过把汉诺塔任务最大化拆分为微小步骤，并在每一步使用独立采样、投票和风险标记，系统完成了超过一百万个 LLM 步骤且没有错误。 $4$

它不意味着所有业务都应该启动百万个 Agent，而是说明了一条工程原则：

大规模可靠性来自分解、检测和纠错，而不是让一个单体 Agent 从头坚持到尾。

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

长链路失败不只是因为步骤多。每个步骤本身也不是固定概率的硬币，它会随上下文、工具定义、输入数据和运行环境变化。

3.1 上下文不是越大越好，而是有限的注意力预算

长上下文窗口解决了"装不下"的问题，却没有自动解决"看得准"的问题。Anthropic 将 context rot 描述为：随着上下文 token 增加，模型从上下文中准确回忆和使用信息的能力会下降；上下文应被视为边际收益递减的有限资源。 $5$

Agent 运行时间越长，上下文中越容易积累：

已经过期的计划；
冗长的工具原始返回；
失败重试产生的重复信息；
与当前子任务无关的历史；
互相矛盾的中间结论。

于是模型并不是简单地"忘记第一句话"，而是当前决策的信噪比持续下降。比较有效的做法包括：

Compaction：把历史压缩为决策、事实、未解决问题和约束，而不是机械保留全部对话。
结构化笔记：把计划、检查点和关键状态写到上下文之外，在需要时重新加载。
子智能体隔离：让子任务在干净上下文中执行，只向主 Agent 返回浓缩结果。
按需检索：不要把整个知识库和全部工具一次性塞给模型。

上下文工程的目标不是尽可能多地提供信息，而是为当前决策选择尽可能少的高信号信息。

3.2 工具调用把"语言错误"变成"现实副作用"

Agent 与聊天机器人最大的区别，是它能把模型输出转化为操作。工具调用一旦接入数据库、邮件、支付、工单或代码执行环境，错误就不再只是回答不好，而可能产生真实副作用。

工具幻觉至少有两类： $6$

工具选择错误：选错工具、在不该调用时调用，或遗漏必要调用。
工具使用错误：参数格式错误、参数内容捏造、权限范围不正确。

因此，一个工具是否"能被模型调用"只是起点。生产工具还需要：

严格的参数 Schema 与业务校验；
用户身份和数据权限校验；
幂等键、超时、重试和熔断；
对写入、发信、付款、删除等动作设置审批；
对返回内容做大小限制、脱敏和可信度标记；
保存 request、tool_call、result 和状态变更的关联链路。

3.3 环境不是测试集：网页会改版，API 会超时，数据会漂移

真实环境中的 API 限流、网络抖动、验证码、字段变化、空数据和第三方故障会持续发生。传统程序通常把这些情况写成显式分支；Agent 可能把异常文本当作新的事实，再基于错误观察继续规划。

因此，环境错误必须先被确定性代码归类，再交给模型决定策略。不要把一段不可控的异常堆栈直接扔回上下文，并期待模型每次都能理解。

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

传统函数常被理解为：相同输入、相同版本、相同依赖，应该得到相同输出。Agent 的输出则受到模型采样、推理服务、工具返回、检索结果、并发顺序和历史状态共同影响。

这会带来两个后果：

一个失败未必能原样复现。
修改一处提示词，可能让后续工具选择和执行轨迹整体改变。

Anthropic 在多智能体研究系统的工程总结中指出，Agent 是有状态的，错误会沿工具调用累积；他们采用检查点、确定性重试、完整追踪和渐进部署来支撑恢复与调试。 $7$

Agent 的可观测性不能只保存最终答案。至少应记录：

text 复制代码

trace_id
├── 输入、身份与策略版本
├── 上下文快照与检索来源
├── 每轮模型请求及结构化决策
├── 工具参数、权限判定与返回摘要
├── 状态变更、检查点和工件地址
├── 重试、降级、人工审批与异常
└── 最终结果、评测分和成本

这里的目标不是无限保存用户敏感内容，而是在隐私边界内保留足够的因果线索，使开发者能回答："它为什么在这一步选择了这个动作？"

五、评测也是瓶颈：没有可靠尺子，就无法提高可靠性

Agent 的输出往往不是一个字符串，而是一条动态轨迹。两个 Agent 最终都完成了任务，其中一个可能调用了三次工具，另一个可能修改了不该修改的数据。只看最终文本，会遗漏过程风险。

公开 Benchmark 也不是永远可靠。OpenAI 在审计 SWE-bench Verified 的一部分难题后发现，受审计问题中至少 59.4% 存在测试设计或问题描述缺陷；同时，公开仓库带来了训练数据污染风险。因此 OpenAI 建议用更新的基准替代它。 $8$

这并不意味着 Benchmark 没用，而是说明企业需要自己的分层评测：

评测层	主要问题	示例指标
模型与节点	单次判断是否正确	分类准确率、参数合法率、引用正确率
轨迹	过程是否合理	工具选择、步骤数、无效重试、规则遵循率
任务	是否完成业务目标	task success、pass^k、人工接管率
安全	是否产生不可接受动作	越权率、敏感数据外发率、危险调用拦截率
运营	是否值得持续运行	p95 延迟、单任务成本、恢复率、业务收益

业务任务往往没有唯一标准答案，因此评测不必追求虚假的"绝对正确"。更可行的办法是建立人工基线、黄金案例、风险案例和回归集，再持续观察相对改进与分布漂移。

六、多智能体能提高效果，但可靠性不是免费午餐

当任务可以并行探索时，多智能体能够把上下文隔离开，让不同子 Agent 独立查找和验证。Anthropic 报告其多智能体研究系统在内部研究评测中相对单 Agent 提升 90.2%。但同一篇工程文章也指出，普通 Agent 的 token 用量约为聊天的 4 倍，多智能体系统约为聊天的 15 倍。 $7$

多 Agent 并不是把一个不可靠系统复制几份就会自动可靠。它还会增加：

协调和结果合并错误；
状态一致性问题；
子 Agent 之间的相关错误；
更长延迟和更高成本；
更复杂的权限与审计关系。

适合多 Agent 的任务通常具有高价值、可并行、信息量大、子问题边界清晰等特征。强依赖、顺序敏感、共享状态频繁变化的业务，往往更适合确定性工作流加少量模型节点。

七、安全是可靠性的负面定义：系统必须可靠地"不做什么"

很多团队把安全当作上线前增加的一层过滤器，但 Agent 的安全边界必须进入执行架构。

当系统同时具备以下条件时，风险会显著上升：

能读取私有数据；
会处理网页、邮件、文档等不可信内容；
能通过工具向外部发送信息或执行写操作。

攻击者不需要攻破模型，只要让不可信内容被模型解释成高优先级指令，就可能诱导 Agent 泄露数据或执行操作。缓解手段包括最小权限、工具白名单、数据与指令分离、敏感操作审批、隔离执行环境和输出侧防泄漏控制。

2025 年披露的 Replit Agent 生产数据删除事件，以及 Cursor 支持机器人编造不存在的多设备使用政策，说明了两类不同风险：前者是自主执行范围过大，后者是未经验证的生成内容直接成为对外业务口径。 $9$ $10$

一个安全的 Agent 不只是更少说错话，而是即使模型判断错误，也无法轻易造成不可逆损失。

八、商业瓶颈表面是 ROI，本质仍是可靠性成本

Gartner 预测，超过 40% 的 Agentic AI 项目会在 2027 年底前被取消，原因包括成本上升、商业价值不清和风险控制不足。 $11$ 这些看起来是三个问题，实际上可以放进同一个公式：

text 复制代码

净价值
= 自动化收益
- 模型与工具成本
- 人工复核成本
- 错误修复成本
- 安全与合规成本

如果 Agent 每次运行都需要人工从头检查，它提供的不是自动化，只是生成速度。如果为了把失败率压低而增加大量模型投票、重试和人工审批，成本又会吞噬收益。

一项针对成熟开源项目的随机对照研究也提醒我们，不要用主观"感觉更快"代替测量：16 名熟悉项目的开发者完成 246 个任务时，事前预计 AI 会节省 24% 的时间，实验结果却显示在该研究条件下完成时间增加了 19%。这项结果不能外推到所有开发工作，但它很好地说明了基线测量的重要性。 $12$

Agent 项目立项时，首先应该问的不是"能不能接入最强模型"，而是：

当前人工流程的时间、成本和错误率是多少？
哪些错误可以容忍，哪些必须零容忍？
哪些步骤有客观验证器？
哪些动作可回滚，哪些必须人工批准？
Agent 带来的增量价值能否覆盖评测、治理和异常处理成本？

九、怎样把可靠性从口号变成架构

仅靠一条更长的系统提示词无法解决可靠性。更有效的方式，是把开放式推理放进一个确定性的控制框架。

生产级 Agent 应当在每轮行动前后执行策略、验证和状态更新。 模型负责提出行动，运行时负责决定行动是否允许以及结果是否可信。

9.1 缩短开放式决策链

能用规则、SQL、状态机和传统代码解决的步骤，不要交给模型重新推理。模型最适合处理语义理解、非结构化信息和难以穷举的选择；确定性程序适合计算、校验、权限和状态变更。

9.2 为每个高风险步骤设计验证器

验证器可以是 Schema、规则、测试、双重查询、交叉来源或人工审批。假设某一步首次成功率为 p，失败后被检测到的概率为 d，检测后恢复成功的概率为 r，则这一环节的有效成功率可以近似写成：

text 复制代码

q = p + (1-p) × d × r

这个公式说明，提升可靠性不只有"换更强模型"一条路。提高错误检测率和恢复率，同样能提升系统成功率，而且更容易度量。

9.3 检查点、幂等和补偿事务必须成为默认能力

长任务不应失败后从头重跑。系统需要保存已完成步骤、工具回执和工件地址；所有可能重复执行的写操作都应有幂等键；无法直接回滚的业务需要补偿事务或人工处理队列。

9.4 把风险与自主程度绑定

场景特征	推荐形态	默认控制
路径固定、规则明确	确定性工作流	单元测试、规则校验
路径可变、结果可验证	受控 Agent	自动验证、检查点、预算
路径可变、存在写操作	Agent + 人在回路	审批、最小权限、回滚
高风险且结果难验证	人主导、AI 辅助	只读建议、双人复核

9.5 用可靠性 SLO 管理 Agent

建议至少建立以下指标：

task success rate 与 pass^k；
首次成功率和恢复后成功率；
未检测错误率；
危险工具调用拦截率；
人工接管率和平均接管时点；
单任务 token、工具成本和 p95 延迟；
相同输入的轨迹差异与结果一致性；
不同模型、提示词、工具版本下的回归变化。

十、什么时候才应该让 Agent 自主运行

部署边界不应由"Agent 看起来很聪明"决定，而应由风险和可验证性共同决定。

图 4：风险越高、结果越难验证，越不应该给 Agent 完整自主权。 低风险且有验证器的任务，才适合逐步提高自动化程度。

一个稳妥的上线顺序通常是：

影子模式：Agent 运行但不影响真实业务，与人工结果比较。
只读建议：Agent 给建议和证据，由人决定是否执行。
低风险自动化：允许执行可回滚、可验证的动作。
受控写入：写操作进入审批、额度和权限边界。
有限自主：只有当回归数据和事故记录证明可靠性达标后，才减少人工干预。

结语：下一阶段的竞争，是谁能更可靠地使用不可靠模型

未来模型还会继续变强，上下文会更长，工具调用也会更准确。但只要系统依赖概率模型，错误就不会自动归零。

Agent 工程真正成熟的标志，不是模型可以连续思考多少轮，而是系统知道：

哪些决策可以交给模型；
哪些事实必须验证；
哪些动作必须审批；
出错后从哪里恢复；
如何证明一次升级没有破坏原有能力。

所以，AI Agent 目前最大的瓶颈不是"不会完成复杂任务"，而是不能以可测量、可复现、可恢复、可治理的方式持续完成复杂任务。

模型决定能力上限，工程决定可用下限。真正能够进入生产环境的 Agent，必须把两者之间的巨大空白，用状态、验证、权限、评测和反馈闭环一点点填满。