Skip to main content

​
电梯演讲

将 params._meta 记录为从客户端向代理传播元数据的约定，例如追踪标识符或关联 ID。这与 MCP 保持一致，由于两个协议都使用 stdio JSON-RPC 传输，从而实现共享检测。

​
现状

ACP 客户端已经通过 _meta 向代理传播上下文。例如，requestId 用于 AionUi 中的请求关联。 然而，extensibility 文档没有指定 _meta 类型或记录其用于传播的内容。没有文档记录，各方必须临时协调，这可能导致可移植性事故（例如，一方使用 _meta.traceparent 而另一方使用 _meta.otel.traceparent）。记录传播的字段是 _meta 中的根键可以防止这种情况。

​
我们提议对此做什么

用两个更改更新 extensibility 文档：
  1. 将类型 { [key: string]: unknown } 添加到现有的摘要句子中。此类型与 MCP SDK 兼容。
  2. 在 JSON 示例之后添加一个关于传播约定的新段落。

​
美好的未来

  • 相同的检测（OpenInference 等）适用于 ACP 和 MCP。
  • 可观测性工具可以跨协议关联追踪。

​
实施细节

更改 1：更新 extensibility 中现有的摘要句子： 
-All types in the protocol include a `_meta` field that implementations can use to attach custom information.
+All types in the protocol include a `_meta` field with type `{ [key: string]: unknown }` that implementations can use to attach custom information.
更改 2：在 JSON 示例之后，在”实现不得”之前，添加：
客户端可以向代理传播字段以进行关联，例如 requestId。以下 _meta 中的根键应该为 W3C 追踪上下文 保留，以保证与现有 MCP 实现和 OpenTelemetry 工具的互操作性：
  • traceparent
  • tracestate
  • baggage

​
常见问题

​
为什么现在记录这个？

客户端已经通过 _meta 传播上下文。文档记录可以防止不兼容的漂移，并启用与 MCP 的共享工具。

​
为什么引用 MCP？

ACP 和 MCP 是两个核心代理协议，都使用 stdio JSON-RPC。在 _meta 类型兼容的地方，检测代码可以被抽象并为两者重用。 以下是传播 W3C 追踪上下文的 MCP SDK：

​
修订历史

  • 2025-12-04：在可扩展性文档中实施
  • 2025-11-28：初始草稿