传输层与多协议支持 ​

概述 ​

UCP 的核心设计原则之一是传输无关性。协议设计独立于传输层，支持多种传输协议，使得平台和商家可以根据自己的基础设施选择最适合的传输方式。

设计原则 ​

传输无关性 ​

UCP 的操作语义与传输层无关：

• 操作定义（如 create_checkout）独立于传输协议
• 传输绑定只定义如何通过特定协议调用操作
• 统一的错误处理和签名机制

统一的操作语义 ​

无论使用哪种传输协议，操作的行为和语义保持一致：

# REST
POST /checkout-sessions
Body: { "line_items": [...] }

# MCP
{
  "method": "tools/call",
  "params": {
    "name": "create_checkout",
    "arguments": { "checkout": { "line_items": [...] } }
  }
}

# A2A
# Agent Card 格式

支持的传输协议 ​

1. REST Transport（核心） ​

UCP 支持 HTTP/1.1（或更高版本）使用 RESTful 模式。

特点 ​

• Content-Type：请求和响应必须使用 application/json
• 方法：实现必须使用标准 HTTP 动词（如 POST 用于创建，GET 用于检索）
• 状态码：实现必须使用标准 HTTP 状态码（如 200、201、400、401、500）

端点解析 ​

服务的 endpoint 字段提供 API 调用的基础 URL。OpenAPI 路径附加到此端点以形成完整 URL。

示例：

{
  "rest": {
    "endpoint": "https://business.example.com/api/v2",
    "schema": "https://ucp.dev/.../rest.openapi.json"
}

OpenAPI 路径：/checkout-sessions

解析后的 URL：POST https://business.example.com/api/v2/checkout-sessions

规则 ​

• endpoint 必须是有效的 URL，使用 https 方案
• endpoint 不应有尾随斜杠
• OpenAPI 路径是相对的，直接附加到端点
• 相同的解析适用于 MCP 端点的 JSON-RPC 调用

请求示例 ​

POST /checkout-sessions HTTP/1.1
Host: business.example.com
Content-Type: application/json
UCP-Agent: profile="https://platform.example/profile.json"
Signature-Input: sig1=...
Signature: sig1=...

{
  "line_items": [
    {
      "item": {
        "id": "item_123",
        "title": "Widget",
        "price": 2500
      },
      "quantity": 2
    }
  ]
}

响应示例 ​

HTTP/1.1 201 Created
Content-Type: application/json

{
  "ucp": {
    "version": "2026-01-23",
    "capabilities": {
      "dev.ucp.shopping.checkout": [{"version": "2026-01-23"}]
    }
  },
  "id": "checkout_abc123",
  "status": "incomplete",
  "line_items": [...],
  "totals": [...]
}

2. Model Context Protocol (MCP) ​

UCP 支持 MCP 协议，它基于 JSON-RPC 运行。

特点 ​

• 基于 JSON-RPC 2.0
• 支持流式传输（Streamable HTTP）
• 工具调用模式
• 结构化内容支持

请求格式 ​

MCP 请求使用 tools/call 方法，操作名称在 params.name 中，UCP payload 在 params.arguments 中：

{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "create_checkout",
    "arguments": {
      "meta": {
        "ucp-agent": {
          "profile": "https://agent.example/profiles/shopping-agent.json"
        }
      },
      "checkout": {
        "line_items": [
          {
            "item": {
              "id": "item_123",
              "title": "Widget",
              "price": 2500
            },
            "quantity": 2
          }
        ]
      }
    }
  },
  "id": 1
}

响应格式 ​

MCP 工具响应使用双输出模式以实现向后兼容。UCP MCP 服务器：

• 必须在 structuredContent 中返回 UCP 响应 payload
• 应该在工具定义中声明 outputSchema，引用适当的 UCP JSON Schema
• 应该在 content[] 中也返回序列化的 JSON 以实现向后兼容

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "structuredContent": {
      "checkout": {
        "ucp": {
          "version": "2026-01-23",
          "capabilities": {
            "dev.ucp.shopping.checkout": [{"version": "2026-01-23"}]
          }
        },
        "id": "checkout_abc123",
        "status": "incomplete",
        "line_items": [...],
        "totals": [...]
      }
    },
    "content": [
      {
        "type": "text",
        "text": "{\"checkout\":{\"ucp\":{...},\"id\":\"checkout_abc123\",...}}"
      }
    ]
  }
}

错误处理 ​

MCP 错误使用 JSON-RPC 错误格式：

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32001,
    "message": "UCP discovery failed",
    "data": {
      "code": "profile_unreachable",
      "content": "Unable to fetch agent profile: connection timeout",
      "continue_url": "https://merchant.com/cart"
    }
  }
}

错误代码映射：

• -32000：一般错误（认证、权限等）
• -32001：UCP 特定错误（发现、协商失败）
• -32600：无效请求
• -32603：内部错误

流式传输 ​

MCP 支持流式 HTTP 传输，允许：

• 服务器推送更新
• 实时状态更新
• 长轮询支持

3. Agent-to-Agent Protocol (A2A) ​

商家可以暴露支持 UCP 作为 A2A 扩展的 A2A 代理，允许平台通过结构化 UCP 数据类型集成。

特点 ​

• 基于 Agent Card 规范
• 支持代理间通信
• 结构化数据交换
• 安全的消息传递

Agent Card 格式 ​

{
  "agent_id": "business-agent-123",
  "name": "Business Shopping Agent",
  "version": "1.0.0",
  "capabilities": [
    {
      "type": "ucp",
      "version": "2026-01-23",
      "endpoint": "https://business.example/.well-known/agent-card.json"
    }
  ],
  "supported_transports": ["https"],
  "authentication": {
    "type": "http_signature",
    "keys": [...]
  }
}

使用场景 ​

• AI 代理之间的直接通信
• 自主商务场景
• 代理协作

4. Embedded Protocol (EP) ​

商家可以将接口嵌入到符合条件的宿主上，该接口会接收用户交互事件并委托关键用户操作。

特点 ​

• 基于 OpenRPC
• 嵌入式 UI 支持
• 事件驱动
• 委托用户操作

初始化 ​

通过商家返回的 continue_url 启动。

使用场景 ​

• 嵌入式结账
• 第三方平台集成
• 白标解决方案

传输协商 ​

服务声明 ​

平台和商家通过 services 在 Profile 中声明支持的传输：

{
  "ucp": {
    "services": {
      "dev.ucp.shopping": [
        {
          "transport": "rest",
          "endpoint": "https://business.example.com/api/v2",
          "schema": "https://ucp.dev/.../rest.openapi.json"
        },
        {
          "transport": "mcp",
          "endpoint": "https://business.example.com/ucp/mcp",
          "schema": "https://ucp.dev/.../mcp.openrpc.json"
        },
        {
          "transport": "a2a",
          "endpoint": "https://business.example.com/.well-known/agent-card.json"
        }
      ]
    }
  }
}

传输选择 ​

平台根据以下因素选择传输：

1. 支持情况：双方都支持的传输
2. 基础设施：平台和商家的基础设施
3. 用例：特定用例的需求（如 AI 代理偏好 MCP）
4. 性能：传输的性能特征

多传输支持 ​

商家可以同时支持多种传输：

{
  "services": {
    "dev.ucp.shopping": [
      { "transport": "rest", ... },
      { "transport": "mcp", ... },
      { "transport": "a2a", ... }
    ]
  }
}

这允许：

• 不同客户端使用不同传输
• 渐进式迁移
• 向后兼容

统一机制 ​

1. 签名机制 ​

所有 HTTP 传输使用相同的签名机制：

• RFC 9421：HTTP Message Signatures
• RFC 9530：Content-Digest
• 算法：ES256（必需）、ES384（可选）
• 密钥格式：JWK（RFC 7517）
• 密钥发现：signing_keys[] 在 /.well-known/ucp

2. 错误处理 ​

统一的错误代码和格式：

3. Profile 声明 ​

所有传输都使用相同的 Profile 机制：

• 商家：/.well-known/ucp
• 平台：通过传输特定机制声明（REST: UCP-Agent header，MCP: meta.ucp-agent）

4. 能力协商 ​

所有传输使用相同的能力协商算法：

• 能力交集计算
• 版本选择
• 扩展修剪

传输特定特性 ​

REST 特定 ​

• HTTP 缓存：支持标准 HTTP 缓存机制
• 幂等性：通过 Idempotency-Key header
• 分页：标准查询参数
• 内容协商：Accept header

MCP 特定 ​

• 工具发现：通过 tools/list 方法
• 流式响应：支持服务器推送
• 结构化内容：structuredContent 字段
• 工具模式：工具调用模式

A2A 特定 ​

• Agent Card：代理卡片格式
• 代理发现：通过 .well-known/agent-card.json
• 代理间通信：直接代理通信
• 安全消息：加密消息传递

Embedded 特定 ​

• 事件驱动：用户交互事件
• 委托操作：关键操作委托
• 嵌入式 UI：UI 组件嵌入
• 状态同步：实时状态更新

实现建议 ​

对于商家 ​

1. 优先支持 REST：最广泛的兼容性
2. 考虑 MCP：如果目标用例包括 AI 代理
3. 评估 A2A：如果需要代理间通信
4. 统一实现：共享业务逻辑，只改变传输层

对于平台 ​

1. 支持多种传输：根据用例选择
2. 传输抽象：抽象传输细节
3. 自动选择：根据商家支持自动选择最佳传输
4. 降级处理：如果首选传输失败，尝试其他传输

性能考虑 ​

REST ​

• 优势：广泛支持、缓存友好
• 劣势：请求/响应模式、无服务器推送

MCP ​

• 优势：工具模式、流式支持、结构化内容
• 劣势：需要 JSON-RPC 客户端

A2A ​

• 优势：代理间直接通信、低延迟
• 劣势：需要 A2A 基础设施

Embedded ​

• 优势：嵌入式体验、实时更新
• 劣势：需要宿主支持

总结 ​

UCP 的传输层设计实现了：

1. 传输无关性：操作语义独立于传输协议
2. 多协议支持：支持 REST、MCP、A2A、Embedded
3. 统一机制：签名、错误处理、能力协商统一
4. 灵活选择：根据用例选择最适合的传输
5. 向后兼容：支持渐进式迁移和多传输共存

这种设计使得 UCP 能够：

• 适应不同的基础设施
• 支持各种用例
• 保持操作语义一致性
• 实现灵活的集成方式