当“智能体能做 X 吗？”演变为交付承诺时

一个工程师花了一个下午钻研一个问题：智能体 (agent) 能否根据合同条款核对客户的发票？他们编写了一个简单的提示词，在五份真实发票上运行，结果三份是正确的。另外两份的错误方式他们还没完全搞清楚——于是他们关上电脑，继续做别的事。在第二天早上的站会上，他们说：“是的，发票核对基本上能用了。”房间里的 PM 记下了这一点。两周后，它成了 Q3 路线图上的一个项目。一个月后，一位销售代表在续约电话中向一家大客户承诺了这项功能。

没有人撒谎。没有人孤立地做出错误决定。但团队现在已经在合同上承诺了一种行为，而这种行为的评估集 (eval set) 并不存在，其失败模式从未被记录，其可靠性预算是由一位看了演示并将其解读为正式合同的总监设定的。这是 AI 功能获取范围 (scope) 最常见的方式：不是通过规划会议，而是通过一个从未被明确提升地位的能力探索 (capability probe)。

行业对这种下游症状有一个称呼——“POC 炼狱” (POC purgatory)，即 70% 到 80% 的 AI 项目在可运行的沙盒和可交付的产品之间停滞不前的状态。但“炼狱”是一个错误的比喻，因为它暗示项目被困住了。它们并没有被困住。它们在移动——在有人检查它们是否准备好之前，它们就被承诺了，现在团队正试图将可靠性强行填补到一个承诺中。

探索是如何演变成规范的

探索是健康的。工程师应该探索模型能力的边界，“让我们看看智能体是否能处理这个”正是正确的直觉。问题不在于探索。问题在于，从外部看，探索和承诺看起来是一样的，而且在大多数团队的工作流程中，没有一个时刻能将前者明确地转化为后者。

观察这种演变是如何发生的。它经过三次交接，每一次交接都会以一种可以预见的方向发生信息损耗。

工程师到站会。 运行了五次试验并看到三次成功的工程师有一个精确的思想模型：“在极小的、不具代表性的样本上达到 60% 的成功率，还有两种我尚未命名的失败模式。”而从他们口中说出来的是“基本上能用了”。这并不是不诚实——这是压缩。“基本上能用”是对“我很惊讶它能做得这么好”的一个合理总结。但这种不确定性、样本量和未被审视的失败在压缩过程中消失了。它们本是发现中最重要的部分，却也是最先被丢弃的部分。

站会到路线图。 PM 听到“基本上能用了”，然后履行职责，即将能力转化为计划。“能用”加上“客户想要这个”等于“在 Q3 交付”。PM 投并不是在鲁莽行事；他们是根据得到的信息进行操作。而他们得到的信息在两句话之前就被剥离了误差范围。

路线图到客户。 销售代表看到了路线图，或者看到了为支持路线图而构建的演示，然后履行你的职责，即将计划转化为收入。现在，外部各方有了一个合同层面的预期。探索已经从“我运行了五次”演变为“我们欠客户一个交代”，其间从未经过任何审核，也没人问过：实际的成功率是多少，在什么情况下成功的？

在任何阶段，都没有人逾矩。每一次交接都是一个人根据收到的输入正确地履行自己的职责。这种缺陷是结构性的——流水线中没有闸门，所以探索就像流水一样顺坡而下，直到撞上客户。

你测量到的东西并不是你承诺的东西

即便抛开交接过程中的损失，还有一个更深层次的不匹配。能力探索回答的是“这是否可能？”交付承诺回答的是“这是否可靠？”这是不同的问题，最近的可靠性研究对此直言不讳：能力和可靠性是两个独立的维度。一个能力极强的系统可能极其不可靠，而一个能力平庸的系统在狭窄的范围内可能是可靠的。测量其中一个维度几乎无法告诉你关于另一个维度的任何信息。

探索优化的是最佳情况 (best case)。工程师挑选有趣的输入，观察运行情况，在看起来不对劲时重试，并以宽容的态度阅读输出。他们回答的是“这能行吗？”——而经过论证，诚实的答案是肯定的。

生产环境问的是相反的问题：“在那些我没选的输入上、没人看守的情况下、第一次尝试时会发生什么？”那五份手动挑选的发票并不是生产流量的样本。它们是工程师觉得值得尝试的发票样本。智能体在损坏的 PDF、第二语言的合同或合同中不存在的项目上的表现——这些都没有被测量，因为测量这些并不是探索的目的。

目前处理结构化业务记录的智能体在现实的企业数据上，目标完成率通常低于 55%。一个在五个精选示例上达到 60% 的探索并不是反驳这一数字的证据，而是与之相符。探索和生产现实可以同时为真，因为它们测量的是不同的分布。

将能力测试转化为交付物，而非口头陈述

这种修正始于拒绝让“能力发现”仅作为站会中的口头陈述而存在。一次探索（probe）应当产生一个微小的、结构化的交付物——称之为能力测试（capability test）——它在表面上就明确声明自己不是一项功能承诺。

它不需要很繁琐。只需记录以下五个字段：

加载中…