你的 MCP 服务器运行正常，但智能体却无法工作？原因在此

来源: Agentic AI Foundation (AAIF)
作者: Agentic AI Foundation
发布时间: 2026/5/9 01:14:50
原文链接: https://aaif.io/blog/your-mcp-server-works-your-agent-doesnt-heres-why/

深入解读 Calum Murray 与 Wesley Chun 在 MCP Dev Summit North America 2026 上的演讲

Red Hat 工程师 Wesley Chun 与 Calum Murray 开场便提出了许多 MCP 服务器构建者已经遇到的问题：你的代码通过了所有测试，但智能体（agent）依然失败，而你完全不知道哪里出了错。

他们的答案是 MCP Checker，一个专门针对传统软件测试与完整智能体评估（agent evals）之间空白地带而构建的开源评估框架。这是该框架的首次公开亮相。

智能体评估无法填补的测试空白

传统软件测试假设代码是确定性的。单元测试、集成测试、端到端测试——它们都是为每次行为一致的系统而构建的。而 LLMs（大型语言模型）每次运行的行为都不同。

智能体评估（agent evals）应运而生以应对这一问题，它们确实有用。但智能体评估关注的是特定智能体做了什么。它们需要在智能体内部植入检测代码（instrumentation），这意味着如果你不控制该智能体，它们就不是一个实用的选择。

一直以来缺失的是中间层：一种能够测试模型是否能正确使用你的 MCP 服务器语义（semantics）的工具，无论运行该模型的是哪个智能体。

MCP Checker 测试的是模型是否能正确使用你的 MCP 服务器的工具，无论运行该模型的是哪个智能体。

MCP Checker 的实际功能

MCP Checker 是一个开源评估框架，位于代理（agent）和你的 MCP 服务器之间。它通过代理记录每一次 MCP 交互，运行以 YAML 定义的评估场景，并为你提供可在 CI（持续集成）中使用的结构化结果。

设计该框架的三大驱动力：

• 在 MCP 层捕获所有信息（工具调用、输入、输出、错误），以便你能回溯并准确了解发生了什么
• 无需修改代码即可与任何代理配合使用。Calum 和 Wesley 在演示中通过代理-客户端协议（Agent-Client Protocol）使用了 Claude Code 作为代理
• 用 YAML 编写评估，使团队中的任何人都能读懂，而不仅仅是编写它们的工程师

YAML 格式定义了提示词（prompt）、设置步骤、预期调用的工具以及验证结果的断言。在简单字符串匹配无法满足需求时，LLM（大语言模型）评判器负责输出质量检查。

演示内容

演示使用了一个故意损坏的 MCP 服务器，包含四个文本处理工具（转换为大写、小写、标题大小写和首字母大写），分别命名为 process、transform、convert 和 format。名称模糊，没有类型提示，也没有有用的描述。

针对该服务器运行 MCP Checker 后，结果显示九个任务中有七个在任务层面通过。智能体得到了正确答案。但断言失败，因为智能体从未调用 MCP 工具，而是直接自行解决了文本问题，完全绕过了服务器。

例如，如果你的 Kubernetes MCP 服务器内置了安全逻辑，而智能体通过直接运行 kubectl 绕过了它，那么任务虽然完成，但你的防护措施并未触发。结果看起来正确，但行为并非如此。

在重命名工具并添加适当描述后，修复后的服务器通过了全部九个任务。令牌使用量有所增加——从约 300 个模式令牌增加到 1,600 个——但智能体正确使用了工具。

Kubernetes MCP 服务器的发现

Red Hat 已在其 Kubernetes MCP 服务器上运行 MCP Checker 数月。其中一些发现尤为突出。

在代码模式（即智能体直接编写代码而非调用工具）下，结果令他们惊讶。在 Opus 4.6 上，切换到代码模式后，任务通过率从 87.5% 降至 41.6%。添加一个帮助智能体搜索可用 API 的工具后，通过率回升至 91.6%，但 token 成本增加了四倍。当智能体同时拥有代码模式和标准工具时，它们仅在 6% 的情况下使用代码模式。

关于工具描述长度，模式（schema）中更详细的描述提高了工具调用成功率，但智能体在遇到问题时放弃得更快。使用更精简的模式时，智能体重试次数更多。团队不确定原因，但这一现象在不同模型中保持一致。

最严重的发现涉及 Kubernetes 中的更新请求。当更新被拒绝时，部分智能体会删除资源并创建新资源。对于 Kubernetes 集群而言，这意味着服务中断和数据丢失。最终状态看起来正确：资源拥有新配置，因此仅检查最终结果会完全遗漏问题。MCP Checker 之所以能发现它，是因为它断言的是工具调用，而不仅仅是结果。

这一发现促使服务器端修改代码，在内部处理更新冲突，而不是让智能体自行决定如何解决。

这对 MCP 服务器构建者的意义

如果你正在发布一个 MCP 服务器，你无法检测用户将带来的每一个智能体。MCP Checker 提供了一种无需接触智能体代码即可测试智能体与服务器接口的方法。

Kubernetes 的发现揭示了问题的严重性。静默失败（silent failures）、未预料的变通方案（unexpected workarounds）、危险的恢复行为（dangerous recovery behaviors）——这些都不会出现在单元测试中。它们只会在生产环境中出现，为时已晚。

MCP Checker 诞生仅几个月，正在积极寻找贡献者。如果你维护着一个 MCP 服务器，或者构建依赖它的代理（agent），那么它值得一看。

探索该项目并贡献代码：Red Hat GitHub 组织。AAIF 开源仓库 中提供了跨多个框架的工作示例。

加入 AAIF Discord 的讨论，并探索 MCP GitHub 仓库 开始构建。