不监控MCP服务器的隐藏成本

你的MCP服务器对每个请求都返回200 OK。你的监控仪表盘一片绿色。你的用户却很沮丧。

这种断裂比任何人愿意承认的都要普遍。HTTP状态码不衡量真正重要的东西。工具返回了数据——但它是正确的工具吗？响应有用吗？LLM实际使用它了吗？

我见过MCP部署中40%的工具调用完全是错误的工具。按所有传统指标来看，服务器都是健康的。延迟低于200ms。零5xx错误。99.99%正常运行时间。但将近一半的时间，LLM在调用一个根本无法回答用户问题的工具。

服务器不知道。团队不知道。用户只是觉得AI不好用。

这就是静默故障问题。你的MCP服务器可以同时"完美运行"和"完全崩溃"——取决于你选择衡量什么。而现在，大多数团队在衡量错误的东西。

对于REST API，"正常工作"意味着"接受有效请求并返回正确响应"。简单。几十年的工具都在验证这一点。

对于MCP服务器，"正常工作"是至少四件事正确发生的链条：LLM选择正确的工具、发送正确的参数、接收有用的响应、并正确地将其纳入回答。每个步骤都可以独立失败。而这些失败中没有一个会出现在传统监控中。

LLM选了错误的工具？你的服务器仍然返回200。参数技术上有效但语义错误？仍然返回200。响应准确但LLM忽略了它？仍然返回200。

你可以在仪表盘上显示100%的成功率，而生产环境中实际成功率只有40%。这个差距就是用户沮丧所在之处。这就是人们说"AI不好用"的原因，而他们真正的意思是"工具没有被检测来捕获真正重要的故障。"

一旦你接受传统指标是不够的，问题就变成：应该衡量什么？

工具选择准确率。当用户提问时，LLM是否选择了你预期的工具？如果你有search_invoices工具和list_documents工具，用户要求"上个月的发票"，哪个被调用了？追踪这个。预期选择和实际选择之间的差距是MCP可观测性中最具揭示性的指标。

参数有效率。不是"参数是否通过了schema验证"——那是基本要求。参数在语义上合理吗？日期范围是否与用户的要求匹配？

响应利用率。这是没人追踪的，但可以说是最重要的。LLM实际使用了响应吗？如果你返回50行数据而LLM全部忽略了，说明有问题。

错误恢复率。当工具调用失败时，LLM会用修正后的参数重试、尝试另一个工具，还是直接放弃？

每次成功调用的成本。不是每次调用的成本——是每次成功调用的成本。当你把浪费的调用算进去，实际成本通常是API原始成本的3-5倍。

这五个指标告诉你的关于MCP服务器健康状况的信息，比所有传统指标加起来都多。

我知道你在想什么。"我已经有Datadog了。我已经有可观测性了。"大概是的。而且对这个用途来说大概没什么用。

Datadog、New Relic、Grafana——它们做的事情很出色。追踪延迟分布、错误率、吞吐量、资源利用率。对于调用方是发送确定性请求的Web浏览器的API来说很完美。

但调用你工具的LLM不是Web浏览器。它是一个做决策的推理引擎。故障模式不是"请求超时"——而是"模型决定这是正确的工具，但实际上不是。"这不是延迟问题。这是决策质量问题。没有任何传统APM工具是为衡量决策质量而设计的。

这就像用速度表来诊断为什么一辆车总是开到错误的目的地。速度表工作正常。它只是没有衡量真正出了问题的东西。

你需要在LLM和工具之间建立一个新的可观测性层。一个理解用户意图、工具选择、参数和响应之间语义关系的层。传统APM是基础。但对于MCP服务器来说，连全貌的一半都算不上。

那具体该怎么做？不需要一步到位。从三件事开始。

第一，记录每次工具调用及其完整的prompt上下文。不只是工具名称和参数——记录导致调用的整个对话。没有这个上下文，你无法评估选择是否正确。

第二，追踪被选择的工具与预期工具的对比。这需要一些基准真值——手动标注、用户反馈信号或启发式规则。即使是粗糙的启发式也比什么都没有强。如果用户问关于发票的问题而LLM调用了联系人工具，这就是一个可以自动检测到的工具选择错误。

第三，衡量响应利用率。将工具返回的内容与LLM回复中实际出现的内容进行比较。如果差距很大——返回了大量数据，使用的很少——你就发现了一个信号。

这三个信号——调用上下文、选择准确率和响应利用率——比所有传统指标加起来更能告诉你MCP服务器的真实表现。它们是知道你的服务器在运行和知道你的服务器真正在帮助用户之间的区别。

现在构建这个可观测性层的团队将拥有巨大优势。不是因为技术很难——并不难。而是因为它提供的洞察比其他人看到的丰富得多。当你的竞争对手看着延迟仪表盘为五个九的正常运行时间自我庆祝时，你将真正知道你的工具是否有效。