直接的答案是：一次成功的演示无法证明 AI 智能体的可靠性，因为正确的问题不是它是否完成过一次任务，而是它是否每一次都能正确完成。在微软于 2026 年 8 月 20 日发布的一项研究中，最强的模型在每个任务只运行一次时得分为 65.36%，但只有 25.25% 的任务能通过全部二十次尝试。这个差距，正是一个在会议上让你眼前一亮的智能体，与一个可以托付客户数据的智能体之间的距离。

微软究竟做了什么

这个工具名为 Thinkingbox，是一个以 MIT 许可证在 GitHub 上发布的开源测试环境。它的思路简单而巧妙：不把工具直接接入智能体，而是将它们定义为兼容 MCP 的服务器，在拥有独立后端数据库的隔离会话中运行智能体，并记录完整的执行轨迹。

关键在于它的评分方式。该框架不读取智能体声称自己做了什么，而是检查任务结束后数据库中实际发生了哪些变化。这一区别并非技术细节。智能体非常擅长为从未发生过的工作写出令人信服的总结，任何基于对话记录的评估衡量的都是文字的质量，而不是执行的质量。

在这个环境之上，团队构建了名为 Thinkingbox-bench 的基准测试，包含五个领域中 507 个受政策约束的工作流：零售与电商、旅游与酒店、汽车保险、一家新型数字银行的内部 IT 支持，以及一家咨询公司的 IT 与人力资源支持。每个任务都在十二个模型上运行了二十次，既有专有模型，也有开放权重模型。

为什么这个数字对企业主很重要

设想你把处理店铺退货申请的工作交给一个智能体。65% 的成功率在纸面上看似可以接受。但在实际运营中，这意味着三分之一的申请会以错误结果告终：退款发放了两次、订单关闭却没有把库存加回去，或者给了一位按你的政策不应享受例外的客户一个例外。

更糟糕的是，这项研究中的故障并不是明显的崩溃。论文明确指出，许多故障干净地结束，所采取的步骤看起来也都有效，但系统的最终状态依然是错误的。没有错误信息，没有中断，监控面板上也没有任何告警。只有一份读起来一切正常的日志，以及悄无声息地变错的数据。

让系统停下来的故障令人恼火，但看得见。完成了流程却让你的数据出错的故障，才是真正让你付出代价的那种，因为你要到一个月后对账时才会发现它。

这也解释了一个常见的失望来源。试点之所以通过，是因为试点只在干净的数据上把任务运行了一次。真实运营则是在杂乱的累积状态上把同一任务执行成千上万次，而 65% 与 25% 之间的差距恰恰就在这里显现。

采用任何智能体之前应该做什么

  • 要求重复运行，而不是一次演示。把用相同数据连续运行同一任务二十次作为你的验收标准。拒绝这样做的供应商，其实已经在告诉你一些东西。
  • 衡量数据状态，而不是回复文本。事先定义任务完成后数据库中的记录应该是什么样子，并将实际情况与之对比。不要满足于阅读智能体自己写的总结。
  • 测试政策，而不只是简单任务。你的大部分工作并非开放式的，而是受到规则约束：退货期限、信用额度、优先客户的例外。一个在无约束条件下成功的智能体，可能在遇到第一个真实条件时就崩溃。
  • 用你自己的案例构建测试集。从最近几个月中挑选二十个真实案例，包括那些曾让员工困惑的奇怪案例，把它们变成一套固定的测试，在采用任何模型之前以及每次更新之后都运行一遍。
  • 分阶段授予权限。先从只提建议、不执行的智能体开始，再让它执行低影响的操作，然后随着真实测量记录的积累逐步扩大其范围。权限应该用数据来赢得，而不是靠印象。

我们在 Origami 如何处理这个问题

当我们构建包含 AI 智能体的系统时，我们会像对待任何其他软件组件一样对待智能体：为它配备自动化测试套件、在每次操作后检查数据库状态的验证机制，以及在超过置信度阈值时转交给人工处理的明确节点。模型本身始终是一个可替换的配置，而不是焊死在代码里的东西，因为今天最好的模型，三个月后未必还是最好的。

这项研究值得我们记住的结论，并不是智能体不可用，而是我们过去评判它们的标尺错了。如今的智能体在定义清晰且持续测量的范围内是强大的工具，但如果仅凭一次令人信服的演示就把敏感流程交给它们，它们就会非常脆弱。差别不在模型，而在于围绕模型的工程纪律。

参考来源