MCP 接入多个测评工具时，如果不同工具对同一问题返回格式不统一，应该如何设计统一输出协议或适配层？｜阿里巴巴后端开发面经解析

60 秒回答模板

我会在 MCP 工具和 Agent Runtime 中间设计 Tool Output Adapter，把不同工具的原始返回统一成标准 ToolResult。标准协议至少包含 toolName、callId、status、contentBlocks、structuredData、error、metadata、traceId 和 version。contentBlocks 面向模型阅读，可以承载文本、表格、文件、引用、图片或日志；structuredData 面向程序稳定消费，例如 rows、columns、score、entityId；error 要有 code、retryable、userAction、missingPermission 等机器可判断字段；metadata 记录耗时、分页、缓存命中、权限范围、数据新鲜度和来源。这样 Agent 面对的是一致工具语义，可以处理成功、部分成功、失败、流式增量和版本演进，避免把格式适配散落在 prompt 或业务代码里。

考点 协议统一

难度 真实面经题

回答目标 体现你能从后端协议、Agent 可用性、错误恢复和长期演进角度设计 MCP 多工具输出适配。

深入解析

统一 envelope

多工具系统最怕返回格式各不相同：有的返回纯文本，有的返回 JSON，有的返回文件链接，有的把错误混在正文里。统一 envelope 可以把调用状态、展示内容、结构化结果、错误和调试信息分开，让 Agent 不必从自然语言里猜工具是否成功。

适配工具私有格式

Adapter 把每个 MCP 工具的原始输出映射成标准协议。搜索工具映射成 resultList 和 citation blocks，数据库工具映射成 rows、columns 和 queryStats，文件工具映射成 file block，错误统一成 error.code、retryable 和 userAction。适配层还可以裁剪、分页和摘要超长结果。

表达语义约束

工具输出不只是数据，还包含是否权威、是否可展示、是否需要鉴权、是否来自缓存、是否过期等语义。协议里应显式表达 source、confidence、freshness、visibility、sensitivity 和 citation 信息，帮助 Agent 区分内部推理材料和可放进最终答案的内容。

处理部分成功和可恢复失败

多工具调用经常不是全成全败。批量查询可能成功 8 个失败 2 个，文件上传成功但解析失败，某个工具超时但另一个工具成功。协议要支持 partial success，并给出 retryable、fallbackSuggestion、missingPermission、rateLimited 等字段，让 Agent 能重试、请求授权、换工具或继续回答。

版本治理和契约测试

工具会升级字段和能力，输出协议要有 version、schemaName 和 capabilities。Adapter 应支持向后兼容，旧 Agent 读取稳定字段，新 Agent 使用增强字段。治理上需要 schema registry、契约测试和黄金样例，保证工具升级不会静默破坏 Agent Runtime。

易错点

把工具原始返回直接塞给模型，导致 prompt 里充满私有格式和不可控噪声。
错误只返回自然语言，Agent 无法判断是否可重试、是否需要授权、是否可以降级。
没有区分展示内容和结构化数据，后续业务逻辑只能解析文本。
忽略版本兼容，工具字段变更后 Agent 行为静默退化。

面试官追问

contentBlocks 和 structuredData 为什么要分开？

contentBlocks 面向模型阅读和展示，可能是摘要、引用、文件或表格；structuredData 面向程序稳定消费，要求字段可预测。混在一起会导致业务逻辑脆弱地解析自然语言。

工具输出很大时 Adapter 应该怎么做？

应支持分页、摘要、字段裁剪和按需加载。给模型的上下文只放关键内容，完整结果保留在可追踪存储或引用链接里，避免污染上下文和超出 token 预算。

多个工具返回冲突结果怎么办？

协议要带来源、时间、新鲜度、置信度和权限范围。Agent 或上层仲裁器可以按权威源、更新时间、任务场景和冲突策略决定采用、提示不确定或要求人工确认。

如何为输出协议做契约测试？

为每个工具维护典型成功、部分成功、权限失败、超时、空结果等黄金样例，校验 Adapter 输出字段、错误码和版本兼容，CI 中阻止破坏性 schema 变更。