Appearance
MCP 如何接入现有 Harness：Gateway、Conformance 与 Adapter
前置：15-01～08 的协议能力；内部 Tool/Runtime abstraction 已稳定
核心问题：接入多个 MCP Server 时，Gateway 怎样统一差异并证明 adapter 符合协议，而不让远端实现细节泄漏进 Runtime？
组织内部不应让每个 Agent 直接理解所有外部 MCP Server。更稳定的做法是让 Gateway 统一路由、授权和审计；Adapter 把 MCP protocol 映射成内部 Tool/Resource contract；Conformance tests 则保证协议升级不会悄悄破坏这层映射。
MCP Gateway
Gateway 可集中做 server registry、routing、auth、policy、cache、rate limit、audit 与 protocol translation。它减少客户端复杂度，但也形成高价值信任和故障集中点。
Protocol Conformance / Compatibility Testing
协议 contract test 应固定 request/headers/schema/error/MRTR/tasks 行为，并对目标 SDK/spec version 建兼容矩阵。
Conformance 测试验证 JSON-RPC/protocol 行为，Compatibility 测试验证不同 SDK/version/server 组合能否互操作。不能仅靠单个 happy-path demo 宣称兼容。
Internal Tool Abstraction → MCP Adapter
先有内部 Tool/Resource contract，再做 MCP Adapter，能避免协议升级把 Runtime 核心类型和状态机一起拖动。
这样 local tool、hosted tool、MCP tool 可共享上层 policy。
🔍 源码对照：MCP Bridge 不拥有业务执行，只做协议适配
完整源码与通用分析见 06-04 Tool Search / Execution Pipeline。这里不重复代码；这里关注 Adapter boundary：MCP bridge 只把协议 call 映射到内部 Executor，业务执行的 ownership 仍然属于 Runtime。
源码说明
inference-router.ts 会根据 provider 选择直接 tool path 或创建 MCP bridge；bridge 再把内部 list/call 适配成 MCP surface。这正好验证本文“Core Runtime 不直接与 MCP SDK/transport 强耦合”的原则：同一内部能力可以有不同边界 adapter，而 provider compatibility 在外围解决。
工程边界
这是为了让特定 provider 使用 Grok Bot tools 的实验扩展，不是 MCP Gateway 的唯一架构。尤其 bridge 中写死的旧 protocol revision 只属于该 reconstruction snapshot。
Shadow Harness 对照
- Domain
ToolRegistry/ToolExecutor保持协议无关；MCPAdapter 实现 discover/call/result/error translation。 - Conformance test 针对 Adapter contract，不需要启动完整 Agent loop。
验证
为 Fake Internal Tool 同时跑 direct contract test 与 MCP conformance test；任何协议转换不得改变 domain success/error/structured result。
为什么 Gateway 不能直接成为 Runtime
一个组织可能接入几十个 MCP Server。Gateway 可以负责 server discovery、连接、认证、限流、协议兼容，但 Runtime 仍应只依赖内部 Tool 抽象：
text
Model
↓ ToolCall(name,args)
ToolRegistry
↓
ToolExecutor
↓
MCP Adapter
↓
Gateway / MCP ServerAdapter 要把远程错误收敛成本地 taxonomy。例如网络不可达、MCP protocol error、远端 tool business failure 不应该全部变成字符串 error；Runtime 需要知道哪些可以 retry，哪些应该反馈模型，哪些属于 authorization/security failure。
Conformance test 则针对 Adapter/Gateway 的协议行为；Runtime contract test 针对内部 ToolCall → ToolResult。把两层测试分开后，升级 MCP SDK 时可以验证协议兼容，而不用重新证明整个 Scheduler 的状态机。
Failure Modes
Runtime 直接依赖 MCP SDK / Session 类型
症状： Planner、Scheduler 或 StateStore 保存 SDK request/session object。
处理： MCP 类型只存在 Adapter；Runtime 只依赖内部 Tool/Resource/Error contract，协议升级通过 conformance suite 验证。
如何验证
| Case | 断言 |
|---|---|
| 替换 MCP SDK / Server 实现 | Runtime 代码不变；fixtures 覆盖 discovery、call、error、auth、unknown extension。 |
关联源码
自测
- 现有 Harness 已有统一 Tool contract，接入 MCP 时为什么应写 Adapter，而不是让 MCP SDK 类型穿透 Runtime？
- Conformance test 应验证协议“能通”之外的哪些行为，才能确认 gateway 没破坏 capability/security boundary？