Appearance
MCP 进入生产环境后的边界：Tracing、Migration 与 Security
前置：MCP Core 之外怎样扩展长任务和 UI：Tasks Extension 与 Apps
核心问题：MCP 版本升级或远端返回不可信内容时，怎样同时保持 trace 连续、协议兼容和权限边界？
生产环境里，MCP 调用要能串进 distributed trace，同时还要面对协议演进和不可信远程 Server。Trace context 只是关联信息，不是模型 Context；deprecated capability 只应留在兼容层；远程 schema/result/prompt 始终按外部输入处理。
Trace Context Propagation
跨 MCP 调用应传递可兼容 trace context，但不能把业务 secret 混入 tracing metadata；server span 与 host/tool span 要能关联。
传播 correlation 不代表传播敏感 prompt/tool payload，采集内容仍要 redaction。
🔍 源码对照：Tool Call 使用稳定 ID 承接跨层诊断
完整源码与通用分析见 11-01 Timeout / Deadline / Retry。这里不重复代码；这里关注 tracing：稳定的 toolCallId 用于跨 Adapter / Runtime 关联 stall、error 与 latency，但 Trace payload 仍必须经过 redaction。
源码说明
MCP bridge 在内部执行时生成 toolCallId，而 Turn observation/telemetry 又维护 trace/span 相关信息。这个组合说明跨协议 Tool Call 最重要的不是“每层都记一条 log”，而是让同一逻辑 action 在 Model→MCP Adapter→Tool Runtime→Observation 之间保持可关联 identity。
工程边界
不要把案例的 trace 字段直接定义为 OpenTelemetry/MCP 标准字段。标准语义仍以规范为准，内部 identity 通过 mapper 适配。
Shadow Harness 对照
- 内部先定义 stable Run/Turn/ToolCall/Attempt ids；协议/OTel adapter 只做映射。
- MCP schema/protocol migration 与内部 Runtime schema version 解耦。
验证
同一 Tool 经 direct path 和 MCP path 执行，Trace 查询应能按同一个 logical tool_call 找到完整 span/event chain。
Deprecated Surfaces / Migration
截至 2026-07-28，Roots、Sampling、Logging 子系统按 SEP-2577 进入 deprecation window；现代协议同时改变了若干 legacy session / server→client request 交互方式。新实现应按 migration target 设计，而不是继续扩大这些旧表面的依赖。
initialize/session、MRTR、cancellation 等则属于 legacy/modern era 行为差异。兼容层可以服务旧 peer，但新 Harness 内部 contract 不应被任一时代的 wire shape 绑死。
MCP Security Boundary
远程 MCP Server 是外部依赖，应通过 gateway/policy 做 allowlist、identity、schema/version、rate limit 与审计；协议标准化不代表服务可信。
MCP 是协议互操作层，不是安全认证。远程 Server 的 schema/result/prompt 都是外部输入，Host 必须在本地执行 capability、approval、credential 和 data-flow policy。
MCP Trace 应该怎样接入整个 Run
当 Tool 经过远程 MCP Server 执行时，排障最怕出现两段互不相干的日志：Harness 只知道“tool 很慢”，MCP Server 只知道“某个请求很慢”。应尽量把调用关联到同一个 Run/ToolCall trace context：
text
Run span
└─ ToolCall span
└─ MCP client/protocol span
└─ remote server work即使不同实现暂时不能完整传播标准 trace context，本地也至少保存 run_id / tool_call_id / server_id / request_id 等 correlation fields。
迁移旧协议 surface 时也不要一次把 Runtime 绑死到新旧两套协议对象。更稳的做法是 Adapter 层兼容输入，内部只产生一种 canonical ToolCall/ToolResult；旧能力停止支持后，删除的是 Adapter compatibility code，而不是重写 Runtime。
Failure Modes
把 Distributed Trace Context 和模型 Context 混为一谈
Trace metadata 由 transport/instrumentation 传播；ContextManager 不负责保存 traceparent，compaction 也不应影响 trace linkage。
新实现继续依赖 Deprecated Surface
兼容旧端点可以有 adapter，但新 Runtime 的核心路径不应建立在 deprecated capability 上。
关联源码
自测
- MCP revision 升级后字段语义变化，为什么 Adapter 层比 Domain 层更适合吸收 migration？
- Trace 中同时包含 Tool 参数和凭证信息时，如何既保留可观测性又避免把 secret 直接落日志？