过去两年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在没有校验和恢复机制时所有步骤都正确的概率近似为P(任务成功) p₁ × p₂ × ... × pₙ ∏ pᵢ如果为了便于理解假设每一步的正确率相同都是 p那么P(任务成功) pⁿ单步 95% 看起来已经很高但连续执行 20 个关键步骤整体成功率只有0.95²⁰ ≈ 35.8%即使单步成功率提高到 99%运行 50 步后的理论整体成功率也只剩约 60.5%。这不是某个框架的 Bug而是串联系统的基本规律。关于多步预测中误差被放大的问题在模型式强化学习研究中已有系统讨论。[2]单步正确率越接近 100%链路衰减越慢但不会消失。更现实的系统还存在相关错误因此简单独立假设往往偏乐观。2.1 平均成功率会掩盖重复运行的不稳定tau-bench 提出了 pass^k用于衡量同一类任务连续运行 k 次、每次都成功的概率。论文报告称当时的先进函数调用 Agent 在零售任务上的 pass^8 仍低于 25%。[3]如果一次任务的成功率是 s在各次运行近似独立时pass^k sᵏ对演示来说运行一次成功就足以录屏对客服、财务、合同审查和运维来说每天运行几千次低频错误必然会变成稳定发生的生产事件。这也是为什么 Agent 的验收不能只看 pass1 或一组平均分。至少还要观察多次重复执行的一致性长尾输入和边缘场景错误能否被检测而不是带着错误继续运行错误发生后的恢复成本有副作用操作的越权率和回滚率。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 的可观测性不能只保存最终答案。至少应记录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] 这些看起来是三个问题实际上可以放进同一个公式净价值 自动化收益 - 模型与工具成本 - 人工复核成本 - 错误修复成本 - 安全与合规成本如果 Agent 每次运行都需要人工从头检查它提供的不是自动化只是生成速度。如果为了把失败率压低而增加大量模型投票、重试和人工审批成本又会吞噬收益。一项针对成熟开源项目的随机对照研究也提醒我们不要用主观“感觉更快”代替测量16 名熟悉项目的开发者完成 246 个任务时事前预计 AI 会节省 24% 的时间实验结果却显示在该研究条件下完成时间增加了 19%。这项结果不能外推到所有开发工作但它很好地说明了基线测量的重要性。[12]Agent 项目立项时首先应该问的不是“能不能接入最强模型”而是当前人工流程的时间、成本和错误率是多少哪些错误可以容忍哪些必须零容忍哪些步骤有客观验证器哪些动作可回滚哪些必须人工批准Agent 带来的增量价值能否覆盖评测、治理和异常处理成本九、怎样把可靠性从口号变成架构仅靠一条更长的系统提示词无法解决可靠性。更有效的方式是把开放式推理放进一个确定性的控制框架。生产级 Agent 应当在每轮行动前后执行策略、验证和状态更新。模型负责提出行动运行时负责决定行动是否允许以及结果是否可信。9.1 缩短开放式决策链能用规则、SQL、状态机和传统代码解决的步骤不要交给模型重新推理。模型最适合处理语义理解、非结构化信息和难以穷举的选择确定性程序适合计算、校验、权限和状态变更。9.2 为每个高风险步骤设计验证器验证器可以是 Schema、规则、测试、双重查询、交叉来源或人工审批。假设某一步首次成功率为 p失败后被检测到的概率为 d检测后恢复成功的概率为 r则这一环节的有效成功率可以近似写成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必须把两者之间的巨大空白用状态、验证、权限、评测和反馈闭环一点点填满。