参数幻觉是漂移信号，而非模型 Bug

工单上写着 “模型幻觉了一个用户 ID”。分拣标签是 model-quality。修复方案是在系统提示词中多加一句话。六周后，另一个工具开始幻觉日期格式，循环再次开启。一年后，提示词已经演变成一段针对整个后端的 4,000 token 的道歉信，而团队也坚信该模型在工具参数方面就是不可靠的。

模型并非不可靠。模型是一个合约一致性机器，它在阅读你提供给它的合约 —— 而你提供的合约一直在悄悄偏离线路另一端的合约。大多数生产环境中的 “参数幻觉” 并不是模型故障。它们是你的工具描述在默默失败的集成测试，之所以表现为模型输出，是因为这是技术栈中唯一能看到分歧的地方。

这种视角的转变至关重要，因为每一个下游决策都会随之改变。如果模型很差，你会修补提示词并调整温度。如果描述已过时，你会测量描述与 API 之间的差距，在 CI 中限制描述修改，并将每个 “幻觉” 参数视为合约漂移的前导指标。其中一个方案具备扩展性，而另一个则会累积每个季度都变得更难清除的技术债。

模型根据给定的描述进行生成

LLM 工具调用是从自然语言 Schema 到 JSON 负载的转换。工具描述 —— 包括工具上的 description 字段、参数文档字符串、枚举值、类型提示 —— 都是源文本。模型的工作是渲染该源文本的一个实例，以满足用户的意图。当渲染出错时，Bug 几乎总是出在以下三个地方之一：

• 源文本与目标 API 不一致。
• 源文本足够模糊，导致多种渲染方式同样有效。
• 目标 API 在运行时有比 Schema 宣传的更严格的要求。

这些都不是模型缺陷。来自一家金融科技团队的 2026 年 3 月事故报告使这种失败模式变得具体：周二发布了一个后端重命名，将 annual_income_verified 改为 verified_annual_income。工具描述在其散文中仍提到了旧字段名。模型开始为该字段返回 null，这被记录为幻觉。经过三天的 “模型退化” 调查后，实际的修复方案是对描述进行了单行修改。

将这种情况乘以 30 个函数的工具表面，每个函数有五个参数，且描述是六个月前编写的且从未复读过，这道算术题就变得令人沮丧。每一次后端重命名都是一个潜在的参数幻觉，等待着分拣寻呼机。模型正在做完全被要求做的事情。

基准率证实了这一点。当团队严格测量差距时，Schema 不匹配在根本原因排名列表中占据主导地位 —— 领先于上下文截断、深度嵌套、转义 Bug、温度随机性和损坏的消息历史。尖端模型在描述良好的工具上能达到 95–99% 的参数有效性；当描述变得陈旧或从自动生成的 OpenAPI 规范中继承了歧义时，这一比例会下降到 70–85%。模型不是变量，描述才是。

三种看起来像幻觉的具体漂移模式

参数幻觉往往聚集在少数几种可重复的模式中。每一种都是描述与运行时之间的不同差距，每一种都需要不同的修复。如果你的事后分析将它们全部归为 “模型错误”，你将永远看不到这些模式。

类型漂移 (Type drift)。 描述写着 customer_id: string，运行时现在期望 string 但以前接受 int，而模型仍然生成 12345，因为描述中的几个 few-shot 示例显示的是整数。模型是根据 few-shot 示例进行渲染的，而不是类型注解。修复方法：删减矛盾的示例，而不是更用力地提示模型。

字段名漂移 (Field-name drift)。 重命名的字段仍保留在描述中，因为重命名的 PR 没有触及 Agent 的工具文件。模型产生带有旧名称的调用；API 返回 422；模型重试；循环燃烧 token。修复方法：在工具的自然语言描述与 API 的单一事实来源 Schema 之间进行 CI diff，在出现分歧时使构建失败。

必填与可选漂移 (Required-vs-optional drift)。 Schema 说一个字段是可选的，运行时悄悄地将其改为必填，而模型（理所当然地）省略了它。运行时返回一个模糊的错误，模型读取错误，并试图通过虚构一个值来修复它，因为描述没有提供有效值长什么样的锚点。修复方法：将 Schema 的必填集与运行时实际情况对齐，并返回本身是结构化的错误（字段名加上有效值的单行描述），而不是晦涩的堆栈跟踪。

这三者的统一主张是：模型是根据陈旧或模糊的源文本进行生成的。“幻觉” 是将这种陈旧性渲染到 JSON 负载中。所有其他诊断 —— 置信度分数、重试预算、裁判模型 —— 都是在搞好源文本之后的下游环节。

参数有效性是针对每个工具的时序指标

大多数团队并没有参数有效性仪表盘。他们只有一个工具调用成功率指标，将“API 返回 200”和“API 在模型重试三次后返回 200”混为一谈。这两种结果的成本剖析截然不同，且只有后者才是幻觉信号。

真正起作用的监控方案更为细致且枯燥。针对每个工具，记录参数数据（payload）和一个二元判定：是否符合 Schema。按工具名称和参数字段对时序数据进行切片。结果就是一个仪表盘，其中每个工具都有自己的参数有效性曲线，而任何导致漂移的描述修改都会在几小时内以阶跃函数的形式显现出来。

这并不稀奇。这与任何团队在公共 API 上部署的监控手段相同：按端点计算 4xx 错误率，并按客户端切片。唯一的不同之处在于，这里的“客户端”是模型，而自然语言描述就是客户端正在阅读的 API 文档。当你这样定义它时，运维手册就是现成的，且告警阈值可以直接映射。某个工具的参数有效性下降 30%，与相应端点的 422 错误率激增 30% 是同类事故。它们需要相同的轮值响应。

聚合指标（整体 Agent 成功率）实际上掩盖了这一信号。单个工具可能已经失效数周，而整体成功率却保持平稳，因为 Agent 在默默地进行重试，而成本则隐藏在 Token 账单中。捕捉漂移的衡量单位是针对每个工具、每个字段的有效率。任何更宏观的聚合指标都过于粗糙，无法指导行动。

CI 门禁优于运维手册

如果描述是契约，API 是实现，那么两者之间的差距就是 CI 中缺失的契约测试。大多数团队都是被动地发现这一差距：修改了描述并上线，客户报告 Agent 不稳定，团队意识到描述与运行时行为不符，于是有人在运维手册中写下一条：“重命名字段时记得更新工具描述”。

运维手册的条目会随时间失效，而 CI 门禁不会。

门禁的形式很简单。工具的自然语言描述和参数 Schema 在源码控制中进行版本管理，并与 API 的事实来源 Schema（无论是 OpenAPI、protobuf 还是 GraphQL）存放在一起。合并前检查会解析两者，在字段名、类型和必填项级别标记偏差，并在作者未显式豁免的情况下拦截构建。豁免标志之所以存在，是因为某些偏差是刻意为之的：例如 API 暴露了 Agent 不应触及的字段，或者描述中故意使用了更面向用户的名称。强制显式确认使漂移在变更发生的时刻变得可见，而此时修复成本最低。

建立这种门禁的团队将彻底告别这类事故。漂移在 PR 评审阶段就被拦截，而不是在凌晨两点，当 Agent 的参数有效性崩溃，轮值人员不得不横跨三个仓库进行二分法定位以寻找原因。

针对有效调用集进行评估，而非“调用是否成功”

标准的工具正确性评估（eval）通常只针对一个二元指标打分：Agent 是否调用了正确的工具。这捕捉到了工具选择失败，但完全遗漏了参数有效性失败。工具可能被正确选择，但接收到的却是完全编造的参数——调用请求发送到 API，返回 422，并在仪表盘中归类为失败。

能捕捉到参数幻觉的评估方案是为每个工具建立一个“黄金调用集”，评分标准是针对预期数据进行逐字段匹配。每个工具的数据集规模很小（20 到 50 个示例即可覆盖大多数参数形态），并从生产环境日志中自然积累。逐字段评分能揭示是哪个参数发生了漂移，而不仅仅是“出错了”，这意味着评估失败能直接指向导致问题的描述修改。

一个不那么明显的收益是：这种评估可以兼作描述修改的回归测试。当提示词工程团队为了更简洁而重写工具描述时，评估会重新运行，要么通过，要么失败。一个“读起来更清爽”但导致参数有效性得分暴跌的描述，实际上是丢失了模型所需的信息。评估为这种损失提供了明确的名称和数值，而不是让它成为三周后才浮出水面的模糊疑虑，最终演变成客户投诉。

对于参数有效性而言，真正重要的基准测试是特定于项目的，而非通用的。BFCL 和类似的公共基准测试衡量的是数千个合成工具的综合函数调用能力。它们无法捕捉你特定代码库中特定工具描述的漂移，因为这种漂移是局部的。黄金集必须与它所评分的描述存放在一起。

参数幻觉是契约漂移的信号——开始这样对待它们

一旦你看透了这一点，模式就非常清晰。每一个“模型编造参数”的工单都是一个待验证的假设，有两个互斥的解释：模型失败了，或者描述漂移了。基础概率强烈倾向于第二个解释。将它们混为一谈的故障分类方式阻碍了团队对差异进行监控，这意味着描述漂移会隐蔽地累积，直到 Agent 的可靠性彻底崩塌。

本周可以检查几件事。调取最近 100 个与参数相关的 Agent 失败案例并重新分类。有多少可以用过期的字段名、过时的类型或与 Schema 矛盾的示例来解释？如果这个比例超过 30%，那么提升 Agent 可靠性最划算的工程投入不是更好的模型，而是在工具描述和 API Schema 之间建立 CI 门禁，加上针对每个工具的参数有效性仪表盘，以及针对流量前十工具的黄金调用评估集。

这种投入会产生复利。模型每个季度都在变得更便宜，而任由工具描述与 API 产生偏差的代价却不会。参数幻觉是系统在两个契约发生背离时发出的信号——学会将其视为漂移警报而非模型缺陷的团队，才是那些随着工具规模增长而 Agent 不会变得越来越不稳定的团队。