MCP 框架传输后语义漂移如何被定位与检测

最近读到一篇 arXiv 预印本，它专门研究了 Model Context Protocol（MCP）在不同 Python 代理框架之间传输后，语义信息会出现哪些偏差。作者没有直接拿真实产品跑压力测试，而是设计了 18 个固定的工具返回值（fixture），让它们分别经过四个已锁定版本的 Python 集成路径，然后在每个框架的公开接口上逐项检查下游软件真正需要的字段、错误声明以及丰富内容。这种做法相当于在同一条输入上做差分测试，只要任意一步出现结构值、错误状态或富媒体字段的不一致，就会被记录为一次 fixture‑task divergence。
在这套实验里，共发现了 13 处唯一的偏差点。这些偏差不是随机噪声，而是可以归结为三类：结构化数值的丢失或类型变换、声明错误被误报或漏报，以及富含マークダウン或多媒体的字段在不同框架里要么被当作空值处理，要么被强制转成了字符串。其中，Google 的 ADK 集成在它观察到的完整路径上，满足了所有主要合同约定——也就是说，只要走它的官方 API，下游看到的就是上游送来的原始信息。而其余三个集成则表现出更为复杂的行为：有的仅在某些接口上出现字段缺失或类型强制转换，有的则直接导致执行失败，因而无法完成后续的验证步骤。
有趣的是，这些偏差究竟是不是“问题”，很大程度上取决于下游消费者是怎样读取数据的。比如 OpenAI 的严格富内容校验里，很多失败其实源于一种假设：当某个可选字段在传输过程中根本不存在时，框架会把它当作 null 来处理。如果下游代码本来就把缺失字段和 null 视为等价，那么这些所谓的失败实际上并不会影响功能；反过来，如果下游要求该字段必须显式出现且不能为 null，同样的缺失就会变成硬错误。换句话说，同样的线表现，在不同的消费期待下可能被判定为“无害”或“不可接受”。
作者还做了一次探索性回放实验：把原本应该是结构化对象的返回值先序列化成 JSON 文本，再让各框架去解析。结果表明，这种做法确实能够多恢复一些结构化值——因为文本形式保留了键值对的完整描述。然而，同时也带来了两个副作用：一是有时会返回根本不存在于源数据里的字段值（显然是框架在解析时默认填充了某些默认值）；二是对于本来就缺失的字段，解析后仍然会得到一个看似合法的值，这会误导下游以为该字段真的有内容。换言之，纯文本回放在提升可恢复信息的同时，也把正确性的门槛拉高了。
在压力测试环节，研究者故意制造了输出冲突的情况——同一工具在不同并发下返回了结构值与错误声明互相矛盾的结果。这时候，只要查看框架文档中关于“默认处理策略”或“后备字段”的说明，往往就能够在不额外申请独立结构槽的情况下，让下游选择一个可接受的解释路径。也就是说，好的文档不只是说明怎么调用，还能在出现歧义时提供一个可依赖的回退机制。
最后，作者引入了故障挑战（fault challenge）的概念：他们人工注入一些已知的解析错误或类型不匹配，然后观察测试套件是否能够捕获这些异常，并且在随后的全新 przypadków 中验证修复是否真的生效。结果显示，最初的测试 oracle（也就是判定对错的依据）本身就有一个盲点——它把某些结构性偏差当成了可以接受的噪声，导致真正的问题被漏掉。在补足这个盲点之后，同样的故障在新案例里被稳定地捕获出来，说明测试方法本身是可以迭代改进的。
总结来说，这篇工作的核心贡献不是给出一个生产环境的故障率，而是提供了一套可以在受控固定 fixture 上复用的、接口特定的差分检测手段。它的实际意义在于：如果团队想要在 MCP 代理框架之间做回归测试，光检查“线路上有没有错”是不够的，还必须同时明确两件事——首先，到底哪些信息是下游必须保留的；其次，下游代码在遇到缺失、null 或默认值时，具体会怎么解释。只有把这两个维度都写进测试用例，才能真正抓住那些在传输后悄悄改变语义的问题，而不会被看似“正常”的通过所欺骗。

https://arxiv.org/abs/2610.00182