工具调用（Tool Use / Function Calling）的稳定性，长期被框定在"模型能不能调对工具"这一帧里。本期把镜头移到另一个被严重低估的失败面：工具自身的定义会变。一个 MCP server 或 FunctionTool 在三个月内几乎必然经历参数改名、类型窄化、枚举删值、必填项新增乃至整工具弃用——而绝大多数 Agent 栈对这种演化既不感知、不校验、也不回退，模型于是拿着旧 schema 调用新工具，参数被静默丢弃、输出被解析塌方、调用看似成功实则已错。这就是 Schema 漂移税：一次上游的小重构，在 Agent 这端表现为大面积的"假成功"。本期实测六栈（LangChain/LangGraph、CrewAI、OpenAI Agents SDK、AutoGen、MCP 协议层、手写 jsonschema+pydantic），核心发现：协议层有版本协商（MCP 的 YYYY-MM-DD 版本字符串），但实现层普遍裸奔；唯一能在调用前拦截破坏性变更的，是 strict schema + 运行时 admission guard 的组合拳。
| 栈 / SDK | 破坏性变更感知 | 运行时校验 | 版本协商 | 漂移检测手段 | 静默失败风险 |
|---|---|---|---|---|---|
| LangChain / LangGraph | 无原生机制 | Pydantic v2（可选） | 无 | 需自建快照 diff | 高：额外参数默认丢弃 |
| CrewAI (BaseTool) | 无 | Pydantic args_schema | 无 | 需自建 | 高：改名即 None |
| OpenAI Agents SDK | strict 开关 |
strict 模式下服务端强制 | 无 | 无 | 中：strict 能拦类型，拦不住删值 |
| AutoGen | 无 | 类型注解 + Pydantic | 无 | 无 | 高：运行时崩溃而非拒绝 |
| MCP（协议层） | YYYY-MM-DD 版本字符串 | inputSchema（JSON Schema） | 有（initialize 握手） | 需外挂（LangSight/DriftAlert） | 协议感知，实现仍漏 |
| 手写 jsonschema + pydantic | 全自建 | 强 | 全自建 | 全自建（CI 快照） | 取决于工程投入 |
结论先行：没有一栈原生做到"变更即告警、调用即拒绝"。 MCP 是唯一在协议层内建版本协商的，但它只告诉你"版本号变了"，不告诉你"变了之后哪些工具会炸"。护栏必须自己补。
把 query 改成 search_query 是最典型的破坏性变更。模型根据 prompt 里缓存的旧描述，仍然产出 {"query": "..."}。下游会发生什么，取决于工具实现的语言语义：
# 新工具签名：def search(search_query: str, limit: int = 10)
# 模型传入：{"query": "6G 太赫兹", "limit": 5}
result = search(query="6G 太赫兹", limit=5)
# Python：search() 收到 search_query=None，limit=5
# ——不报错，返回空结果或全表扫描，"假成功"
六栈实测表现分化明显。LangChain 在 StructuredTool 里默认会把未声明的额外参数静默丢弃，连 warning 都不打——这是最危险的一档，因为日志里全绿。CrewAI 的 args_schema（Pydantic）在默认配置下同样接受额外字段，除非显式开 model_config = ConfigDict(extra="forbid")。OpenAI Agents SDK 若启用 strict=True，服务端会按 schema 严格校验，多余字段会被拒，但 strict 模式有自身的限制（如不支持 default、不允许 union 含 null），很多团队因此关闭它，护栏随之消失。AutoGen 在函数装饰器路径下依赖类型注解，重命名后会在运行时抛 TypeError，属于"响亮失败"，反而是六栈里最诚实的一种。变现提示：把"参数重命名检测"做成一个接入 MCP/LangChain 的 CI 闸门（快照对比 + 回归调用集），是面向 Agent 开发者的高复购训练营模块——因为它打中的是真实生产事故。
price: float 收紧成 price: int、tags: list[str] 改成 tags: str（逗号分隔）、可选变必填——这些是"窄化型"破坏。它的杀伤力在于模型仍按旧语义填充，而新校验在请求被接受后的某个深度才触发：
# 旧：def tag(items: list[str]) -> ...
# 新：def tag(items: str) -> ... # 期望 "a,b,c"
# 模型传入 ["a","b","c"]
# ——上游可能 join 成 "['a','b','c']"（repr），下游 split 出 "['a'" 之类的脏值
MCP 协议层对此有一个结构性缓解：inputSchema 是标准 JSON Schema，服务端理应用 ajv（JS）或 jsonschema（Py）在收到调用时校验。但实测大量第三方 server 跳过了校验步骤，直接把 payload 喂给业务函数——schema 沦为"给模型看的说明书"而非"给运行时用的合同"。手写栈（pydantic + 显式 extra="forbid" + 窄化版本号）是唯一能做到"窄化即拒绝"的，代价是工程量。一个关键工程红线：为每个工具维护 additionalProperties: false + 全字段 required 清单，这是把"说明书"升级为"合同"的最低门槛。
当上游给工具加了一个 region 必填参数，模型的旧 prompt 里没有 region，于是它要么不填（被新 schema 拒绝），要么幻觉一个默认值（如 region: "us-east-1"，业务上可能完全错误）。六栈表现：
raise，错误信息质量完全取决于开发者素养，方差极大。这一项的解药不是技术而是流程：必填项新增必须走"先做可选+带 default，跨一个版本周期后再转必填"的软迁移，与 API 后向兼容的经典实践同构。MCP 的工具弃用机制（deprecation notice）正是为此设计，可惜采纳率极低。
枚举漂移是最阴险的一类。模型被训练/prompt 在某个时间点见过 status: "archived"，而新版 schema 把 "archived" 从 enum 里移除了。模型仍产出 "archived"：
// inputSchema 新版 enum: ["active","inactive","deleted"]
// 模型调用：{"id": 123, "status": "archived"}
strict 校验会拒绝，但非 strict 栈会直接穿透到业务逻辑，DB 层因为外键约束抛错，错误信息与"archived 已弃用"毫无关联，排障成本极高。LangSight 的 schema-drift 检测正是把这类"枚举值减少"列为高优先级告警，因为它既难被单元测试覆盖（模型行为依赖枚举值存在），又难被运行时日志暴露（错误发生在远端 DB）。一个可落地的兜底：在工具入口维护一个"枚举值灰名单"，凡是被删的值在 30 天内做显式报错并附迁移说明，而非让约束炸在深处。
输入侧的破坏变更至少有调用层挡着；输出侧的变更几乎无栈保护。当 search_results 的结构从 {items: [...]} 变成 {data: {results: [...]}}，模型/Agent 拿到返回值后做的 result["items"] 直接 KeyError。更糟的是半结构化漂移：返回的 HTML、日志文本、错误堆栈改了模板，模型先前建立的提取正则/路径全部失效，而返回值本身看起来仍然成功（HTTP 200、JSON 合法）。
六栈在输出侧集体失声：没有任何一栈对工具返回值做结构契约校验。OpenAI Agents SDK 的 strict 模式只管输入，不管输出。MCP 的 outputSchema 字段在规范里是可选的，绝大多数 server 不声明，更不校验。这构成了假成功陷阱（已覆盖主题）的一个上游根因：返回值校验之所以难，是因为返回值的结构本身在漂移。解法是双向契约——输入 schema 和输出 schema 都纳入快照 diff，并在 Agent 解析返回值前加一层"结构断言"（assert path exists），断言失败即视为漂移信号。
当一个 MCP server 把 jira_create_ticket 下架，但某 Agent 的 system prompt 里仍写着"优先用 jira_create_ticket 创建任务"，模型会持续尝试调用一个不存在的工具。多数栈表现为：调用被协议层拒绝（method not found），模型收到错误后可能编造一个返回值（工具幻觉，推理越强越编造），也可能陷入无效 retry 循环。
这条线暴露了 prompt 与工具注册表之间的软绑定问题：工具列表是运行时动态拉的，但描述工具的 prompt 是离线写死的。MCP 的 deprecation 字段本可让客户端在拉取工具列表时感知下架，但实测中：客户端缓存了旧工具列表、或 prompt 里硬编码了工具名，导致 deprecation 信号传不到决策层。推荐工程：把"工具可用性"做成运行时的准入检查（admission control），调用前先校验工具仍在 list_tools() 的返回里，不在则直接短路 + 通知人类，而非交给模型 retry。
把破坏性变更挡在调用前，业界已沉淀出两条正交的检测链：
链 A——协议层版本协商（MCP 独有）。 MCP 用 YYYY-MM-DD 日期戳作版本字符串，客户端在 initialize 握手时声明自己支持的版本，server 据此协商。2026-07-28 的 MCP 规范修订是协议发布以来最大一次（stateless core、会话语义重写），属典型的"大版本破坏性变更"，所有客户端都被迫迁移。版本协商解决的是"双方说同一套话"，但不解决"这套话变了哪些工具"——它只告诉你"版本号从 2025-06-18 跳到 2026-07-28"，剩下的 diff 还得自己算。
链 B——Schema 快照 diff（全栈适用）。 周期性（CI / 启动时 / 定时巡检）拉取 server 的工具 schema 快照，与前一次快照做结构化 diff，按破坏性等级分类（改名/窄化/新增必填/删枚举/删工具为破坏级；新增可选字段/新增枚举为兼容级），破坏级变更触发告警或熔断。这一链已有成熟工具：LangSight 的 schema-drift detection、开源的 DriftAlert（OpenAI agents 实时监控）、商用 Schema Drift Gate（远程 MCP micro-controller）。它们共同把"漂移"从"线上事故"降级为"CI 红灯"。两条链必须叠加：版本协商给"变了"的信号，快照 diff 给"变了什么"的明细。
检测到漂移只是上半场，运行时如何不让漂移击穿调用才是交付底线。工程上分三道闸门：
版本钉死（pinned contract）。 Agent 部署时锁定一组经过回归的 (tool_name, schema_version)，运行时只接受这组契约。上游升级若不匹配，直接拒绝加载而非"试试看"。代价是失去热升级，换来可预测性——对生产 Agent 而言几乎总是划算的。
调用前 admission guard。 在工具真正执行前插一层：校验入参对齐钉死的 schema、校验工具仍在注册表、校验枚举值仍在白名单。任何一项不通过，不把错误丢回模型自由发挥，而是走"结构化纠错提示 + 最多 N 次"的受控重试，超限即熔断并升级人类。这把"假成功"和"幻觉重试"同时压住。
返回值结构断言。 如前述，对关键路径工具的返回值做路径存在性断言，断言失败即标记漂移、触发快照重新 diff。这是把输出侧纳入闭环的关键。
三道闸门叠加后，漂移税的形态从"大面积静默假成功"收敛为"小范围、有告警、可回退的受控失败"——这是生产 Agent 能不能上线的分水岭。
flowchart TD
A[上游 server 工具升级<br/>改名/窄化/删枚举/删工具] --> B{版本协商<br/>initialize 握手}
B -->|版本号变化| C[触发快照抓取]
C --> D[Schema 快照 diff<br/>结构化对比]
D --> E{分类}
E -->|兼容级<br/>新增可选/加枚举| F[静默通过<br/>记录]
E -->|破坏级<br/>改名/窄化/必填/删值/删工具| G[CI 红灯 + 告警]
G --> H[版本钉死 pinned contract]
H --> I[运行时 admission guard]
J[模型工具调用请求] --> I
I -->|入参/工具存在性/枚举白名单 校验| K{通过?}
K -->|是| L[执行工具]
K -->|否| M[受控重试<br/>结构化纠错提示, ≤N次]
M -->|超限| N[熔断 + 人类升级]
L --> O[返回值结构断言]
O -->|路径失效| C
O -->|正常| P[结果回灌模型]
图中关键闭环：版本协商 → 快照 diff → 分类 → 钉死 → admission guard → 返回值断言 → 再触发 diff。任一环节缺失，漂移就会以"假成功"的形态漏到线上。
场景一：纯生产、强一致（金融/医疗/合同）。 选 手写 jsonschema + pydantic + pinned contract + CI 快照 diff 这条重链。放弃热升级，换来可预测。MCP 仅作为传输层，契约由自己掌。漂移检测接 LangSight 或自建 DriftAlert 巡检，破坏级变更不通过不开闸。
场景二：快速迭代、内部工具（研发提效/数据分析）。 选 MCP 协议层 + OpenAI/Anthropic strict 模式 + admission guard。靠版本协商感知变更、靠 strict 拦输入侧、靠 guard 兜死工具存在性。可接受兼容级漂移热生效，破坏级走灰度。
场景三：多 Agent、多 server、工具规模大（≥58 工具/5 server ≈ 55K tokens）。 必须上分层准入：按调用频次和副作用把工具分三档（高副作用只读白名单 / 中副作用 admission guard / 低副作用自由），漂移检测只盯高副作用档，避免漂移税与工具过载税叠加把 token 和稳定性同时压垮。
通用底线（任何场景都要有）： ① 输入 schema 写 additionalProperties: false + 全字段 required；② 输出 schema 纳入快照 diff；③ 破坏级变更走"先可选带 default → 跨版本 → 转必填"的软迁移；④ 调用失败不把原始错误丢回模型，走受控纠错重试。这四条是把漂移从"必然事故"降级为"可控事件"的最低工程门槛。
[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。