幻影技能：当你的智能体展示出你从未测试过的能力

一位客户在你的支持频道里发布了一张截图。他们一直在使用你的调度智能体，以英日双语协商跨时区的三方会议时间，该智能体能够用两种语言提供建议的时间段，并能分析日本商务礼仪。它确实起作用了。领导层在 Slack 上分享了这张截图，并配上了一个火的表情符号。产品经理（PM）随后更新了营销文案。

团队中没有人编写过这项能力。没有 eval（评估集）覆盖它。没有任何提示词指令提到过日语、礼仪或三方协调。这种行为是真实存在的，但它从未经过工程设计，从未被衡量，而现在它已经成为了你产品功能面的一部分。

这就是一种幻影技能（phantom skill）：你的智能体展示出了没有任何测试验证过的能力。它不是一个 bug，但也不完全是一项功能。它是没有任何契约保障的承重行为，而且这种失效模式悄无声息地定义了你的“AI 产品”到底是什么。

发现的时刻即是陷阱

幻影技能的发现方式每次都如出一辙。用户发现了某种行为，团队为此感到高兴，领导层将其贴上“涌现（emergent）”的标签，而这种工作流在几周内就会被固化为客户的期望。陷阱并不在于发现本身，而在于发现之后的那一刻——当团队将用户展示出的能力视为团队工程化的能力时。

“涌现”这个词中嵌入了一个分类错误。当研究人员使用它时，他们指的是随着模型规模跨越某个阈值而出现的能力——这是模型本身的属性。当产品团队将这个词用于自己的智能体时，他们几乎总是指在用户手中产生的能力，而不是在实验室中产生的。智能体并没有突然变得更聪明；而是用户找到了团队未曾设想过的用例。

这种区分之所以重要，是因为两者的可靠性状况完全不同。团队设计的能力已经过各种输入变量、对抗案例、边界条件的测试，并且可能还有回归评估（regression evals）在保护它。而幻影技能则完全没有这些。它只有一个数据点：那张被发现的截图。

当用户在该数据点的基础上构建他们的工作流时，你现在就承诺了要维护一个你从未刻画过其支撑面的行为。下一次底层模型更新、提示词进行例行修改或工具库存发生变化时，你可能会破坏这项幻影技能——而你甚至不会知道，因为没有任何测试告诉你它的存在。

为什么幻影技能在智能体产品中积累迅速

幻影技能在软件中的分布并不均衡。它们专门堆积在语言模型周围，因为语言模型具有三个不适用于确定性系统的属性。

首先是开放式输入。传统的软件具有受限的输入语法——表单有字段，API 有参数，按钮只做一件事。而智能体接受自由形式的自然语言，任何自然语言的表达都是对能力的潜在探测。输入空间没有边界。你无法罗列出用户提问的所有方式，因此你也无法罗列出他们会发现的所有能力。

其次是组合性。即使你的智能体工具库中的每一个工具都经过了充分测试，工具序列的组合空间也没有。一个用户将“日历查询 → 翻译工具 → 电子邮件草拟工具”按照你的 eval 从未覆盖过的顺序连接起来，这就行使了一项你的团队从未设计过的能力。模型决定序列，用户决定目标，而没有人决定联合行为。

第三是模型自身的意愿。LLM 是积极的。它们会尝试几乎任何在上下文范围内看似合理的任务，其自信程度与任何特定标准都无关。这种积极性是它们发挥作用的原因，也是幻影技能积累如此之快的原因：智能体总会去尝试，而且大多数时候它会产生看起来正确的输出。用户误将“看起来正确”视为“受支持”，而团队稍后才会发现这一点。

综上所述，幻影技能的积累是智能体产品的结构性属性，而不是工程粗糙的标志。任何交付足够通用的智能体的团队都会积累这些技能。问题在于该团队是否有一套发现它们的准则。

模型升级是幻影技能消亡之时

幻影技能通常不会因为你的更改而失效。它们会因为供应商的更改而失效。当基础模型升级时——无论是新的次要版本、底层权重的悄悄更新，还是安全过滤器在系统提示词侧的更改——你在 eval 中衡量的行为往往能存续下来，因为这就是你的 eval 的作用。而你没有衡量的行为则没有这种保护。

具体案例：一个团队从一个模型版本迁移到同系列的更新版本时，发现他们在同一套评估套件上的提示词注入（prompt-injection）抵御能力从 94% 下降到了 71%。由于他们有 eval，这种回归是可见的。同样的升级可能还改变了其他数十种没有任何 eval 覆盖的行为。其中的一些转变改善了情况，而另一些则破坏了团队甚至不知道其存在的幻影技能。

事故报告中的模式是一致的。用户报告一个他们已经使用了几个月的工作流“突然不能用了”。团队进行调查。提示词没变。工具定义没变。应用程序代码没变。唯一改变的是模型。没有人能肯定地说明这项能力是什么时候开始起作用的，又是何时失效的，因为没有人监控它。

这就是本文所指出的组织失能模式：幻影技能以客户期望的形式进入你的产品表面，并在产生它们的模型更新时悄无声息地退出你的产品。用户会注意到。支持工单随之而来。而团队无法做出工程上的响应，因为这项能力从来就不属于他们维护的范畴。

发现一：生产环境追踪挖掘

第一种方法是结构化的：定期挖掘生产环境的追踪（traces），寻找你的评估测试套件尚未覆盖的能力主张。这与标准的观测性（observability）不同。标准观测性的目的是标记故障——错误率、延迟峰值、工具调用超时。幻影技能发现（Phantom skill discovery）则需要观察 成功 的案例，并询问哪些成功是无法解释的。

这种闭环的一个可行版本分为三个步骤。首先，抽样成功的智能体（agent）追踪——即具有积极隐式信号的已完成用户会话（用户没有重试、没有中途放弃、第二天再次访问）。其次，刻画输入模式：语言、领域、工具序列、输出类型。第三，与你的评估库存（eval inventory）进行交叉比对。在生产环境中出现但在任何评估中都未出现的输入模式集合，就是你的幻影技能表面。

这里的本能反应是立即为你发现的一切添加评估。要抵制这种冲动。你发现的大部分内容都将是偶发性的探测——用户在测试极限，且不会重复。真正的信号是 重复出现 的未覆盖模式：在数十个会话中出现、被多个不同用户使用的能力。这些才是那些一旦中断就会让你深陷困境的工作流。

一个有用的框架：生产追踪是你的智能体所拥有的唯一完整的行为规范。你的提示词（prompt）只是暗示。你的评估只是对一小部分的检查。而追踪才是关于你的智能体在现实世界中实际表现的真实情况（ground truth）。挖掘它们并不是一个可有可无的观测性功能——它是发现你实际交付了什么的唯一途径。

发现二：反评估审计

第二种方法反转了通常的评估问题。标准评估审查会问：“我们的评估是否覆盖了我们想要的行为？”而反评估审计（anti-eval audit）则会问：“这个智能体在生产环境中做了哪些没有任何测试验证的事情？”

这种机制的设计初衷就是让人感到不适。列出营销网站宣称产品支持的功能列表。列出系统提示词要求智能体执行的能力列表。从销售通话和支持工单中列出客户用例。现在将这些列表与你的评估覆盖范围进行对比。出现在任何输入列表中但未出现在评估中的行为就是“反评估”——即没有经过验证的能力断言。

大多数团队会发现他们的反评估表面比评估表面还要大。这并非评估团队的失败，而是智能体产品的一种结构性特征。营销团队描述能力，客户反馈能力，系统提示词追求能力——而评估库存总是小于这些主张的并集。

审计的价值在于它让这种差距变得具体。反评估列表中的每一项都是一个决策：要么编写评估并将该能力纳入支持集，要么删除该主张并告诉用户这并非受支持的工作流。让它留在“我们宣称支持但我们不测试”的灰色地带，才是真正的失败模式。

一个实际的节奏：每季度运行一次审计，在每次重大提示词修订后，以及每次模型迁移后。输出是一个简单的双栏账本：声称的能力、评估覆盖状态。任何处于“声称但未覆盖”一栏的内容，要么获得评估，要么被弃用。

发现三：能力范围契约

第三种方法是预防性的：写下智能体应该做什么，并明确将其他所有事情标记为超出范围。这听起来显而易见，但在实践中却很罕见。

大多数智能体产品记录能力的方式就像功能列表一样——列出智能体可以做什么的要点。这种格式是不完整的。一份能力范围契约（capability-scope contract）包含两个方面：受支持列表和明确的不受支持列表，此外还维护一个“附带功能”（incidentally functional）的中间类别，用于描述那些目前有效但无法保证的行为。

这个中间类别是真正的创新。它捕获了幻影技能，但不对其做出承诺。当智能体在混合语言会话中进行日本商务礼仪推理时，契约会注明：“这在当前的生产环境中有效，但未经测试，不保证跨模型更新的稳定性，且不属于支持范围。”基于此进行构建的客户知道他们是在沙堆上盖房子。团队也清楚自己不欠缺什么。

这并不是法律上的避重就轻。这是明确承认智能体具有三个行为层面：已测试且受支持、已测试且已知失败、未测试但功能正常。将第三层视而不见，正是幻影技能失效导致意外停机的原因。命名它给了团队一个分类，并给了用户一个关于可以依赖什么的诚实信号。

在模型迁移期间，这份契约变得至关重要。在迁移之前，你在受支持集上运行评估——这是回归保护。你对附带功能集进行抽样测试——这是偏移检测。你不需要担心不受支持的集合。迁移方案变得清晰可见，因为范围契约告诉你哪些行为值得哪种级别的保护。

组织层面的转变

幻影技能（Phantom skills）从根本上说是一个诚实问题。团队不想承认 agent 的某些行为是无意的。领导层不想承认那些值得演示的能力是未经证实的。客户不想听他们正在构建的工作流是不受支持的。于是大家都心照不宣地将其称为“涌现（emergent）”，然后继续前进。

这种学科要求的转变虽然细微，却让人不适：将用户演示出的能力视为一个假设，而不是一个功能。只有当 eval（评估）覆盖了该能力时，假设才变成功能。在此之前，它只是一种碰巧有效的行为。这种措辞上的微调改变了对话方式。在 eval 覆盖之前，PM 不再将其加入营销文案。当模型更新破坏了某些工程师甚至都不知道已经存在的东西时，他们不再感到惊讶。当诚实的回答是“目前为止确实如此”时，客户也不会再被告知“是的，我们的 agent 支持那个功能”。

处理得好的团队并非拥有更少的幻影技能。他们拥有更快的从“幻影技能 → 已测量的能力 → 受支持的功能”的流水线，并且对卡在中间环节的行为有明确的策略。而处理不当的团队则会以惨痛的方式发现他们的幻影技能库存：一次悄无声息的模型升级、一波“你们的 agent 坏了”的工单，以及工程团队试图通过客户支持线程中的截图来重建 agent 以前的行为。

下次当你团队中有人针对自研产品使用“涌现”这个词时，请将其视为一个信号。用户到底做了什么？该工作流在你的 eval 覆盖范围中的哪个位置？如果答案是无处寻觅，那么你刚刚发现了一个幻影技能——而关于你是要衡量它还是失去它的倒计时已经开始了。