MCP返回200，AI为何仍然失败？
你的 MCP 接口明明全是 200，AI Agent 为什么仍然完成不了任务？本轮热点扫描发现的 TrackMCP，把这个常被忽略的问题摆到了台前：网络请求成功，不等于工具真的帮 Agent 把事做成。

MCP 的失败至少有四层，值得直接收藏成排障清单：

1️⃣ 连接层：客户端、传输方式、协议版本和鉴权是否正确。连接成功只说明“门打开了”。

2️⃣ 发现层：Agent 看到了哪些工具和参数结构，又实际选择了哪个。工具没被发现、描述含糊或选错工具，都不会体现在普通接口可用率里。

3️⃣ 调用层：记录工具名、延迟、结果、重试和应用错误。MCP 的工具结果可能在 HTTP 200 里携带 isError:true；也可能返回空数组，Agent 却继续编出答案。只盯 5xx，会把这类失败统计成健康。

4️⃣ 结果层：把一串调用连成会话，判断任务最终是完成、失败还是中途停止。真正该优化的指标不是“调用成功率”，而是完成率、首次断点、无效重试和每个成功任务的成本。

TrackMCP 项目方称，它通过 TypeScript 或 Python SDK 在服务端边界包装现有 MCP，异步发送遥测，遥测故障时 fail-open，不阻塞主服务。更关键的安全原则是：默认只收集工具、客户端、耗时、状态和错误等结构化元数据；敏感参数应在进程内先脱敏，密钥不得写入工具参数。

我的判断：无论是否使用这个产品，MCP 团队都应建立四层观测，并为“200 但无用”单独设告警。先拿一条真实工作流验证，再决定是否扩大采集；同时明确字段白名单、保留期和访问权限。该项目目前展示的是产品方能力声明，还没有独立基准证明它能提升所有服务的完成率。

AIAgent 可观测性 AI工具