标准定位

目的#

标准拟合解释了 UAI-1 与相邻代理、工具、API、身份、跟踪、模式和传输系统相关的位置。这是一个启动阶段的边界页面：对于需要配合的实施者、审阅者和公众读者很有用，而不会将当前的桥梁证据示例变成过于宽泛的支持声明。

核心对比#

A2A 协调代理，MCP 连接工具和资源，UAI-1 记录便携式交换。OpenAPI 描述 HTTP API，JSON 模式 验证消息结构，DID/VC 风格的系统可以支持信任证据，Trace Context 承载分布式跟踪链接，CBOR 或 MessagePack 仅当证据路径存在时才能成为未来的紧凑传输绑定。

快速选择器#

当问题不是 UAI-1、MCP 或 A2A 在抽象上更好，而是哪一层拥有您面前的工作时，请使用此部分。

UAI-1 与 MCP#

• MCP 询问：该模型客户端可以在此主机会话中使用哪些工具、资源、提示和上下文？
• UAI-1 询问：另一个系统可以验证、引用、重播、审查或附加哪些便携式交换记录以发布证据？
• 桥接规则：MCP 工具调用可以映射到 uai.intent.request.v1，而 MCP 资源或工具结果可以映射到 uai.intent.response.v1。该映射不会将 UAI-1 转换为 MCP 会话生命周期。
• 在以下情况下一起使用：本地工具结果成为跨团队证据、发布工件、公共测试样例或实施支持声明。

UAI-1 与 A2A#

• A2A 询问：哪个代理可以完成这项工作，任务如何委派，以及工作运行时任务状态如何变化？
• UAI-1 询问：在运行时对话结束后，哪些请求、功能声明、任务状态记录、响应、错误或一致性结果需要保持可移植性？
• 桥接规则：A2A 代理卡可以映射到 uai.capability.statement.v1，A2A 任务更新可以映射到 uai.task.status.v1。该映射不会使 UAI-1 成为 A2A 发现、委派或流协议。
• 在以下情况下一起使用：委托代理工作需要验证器支持的移交记录、审计跟踪、公开启动数据包或实施证据。

决策问题#

1. 主要问题是主机会话内的本地工具/资源访问吗？以 MCP 开头。
2. 主要问题是对等代理发现、委派还是任务协调？以 A2A 开头。
3. 记录是否需要跨团队、供应商、发布、审计或公共实施声明进行传输？添加 UAI-1。
4. 该作品是否需要公开证明包？解决UAI-1、模式、注册表、示例和扩展支持语言之前的验证器输出。

相邻标准图#

• A2A:可以拥有对等代理发现、委派、任务流和协作任务状态。 UAI-1 可以记录可移植请求、结果、任务状态或能力证据，这些证据应在运行时会话之外保持可审查。
• MCP:可以拥有主机-客户端-服务器工具调用、资源读取、提示和应用程序本地能力协商。当工具结果或请求需要离开该本地边界时，UAI-1 可以记录公共交换。
• OpenAPI:描述 HTTP 运营和航线合同。 UAIX 为其 REST 表面发布 OpenAPI，而 UAI-1 则描述可以穿过这些路由或在这些路由旁边传输的消息记录。
• JSON 架构：检查当前 UAI-1 配置文件的结构。它是书面规范的验证伴侣，而不是语义指导或发布规则的替代品。
• DID/VC、mTLS 和签名信封：可以支持通过 trust、credential_ref、signature_ref 和配套传输层声明的信任断言，而无需成为一个强制身份堆栈。
• 跟踪上下文：当分布式跟踪已经存在时，可以遍历 conversation.traceparent 和相关的来源字段。
• 问题详情：通知类型化公共失败的样式，而 UAI-1 将特定于配置文件的错误记录和验证器问题代码附加到其自己的注册表中。

代理系统架构路径#

当读者询问 UAIX 如何适合生产代理线束时，请使用此路径。安全带运行工作； UAIX 保留运行过程中必须保留的便携式证据和移交记录。

实际规则是：让运行时执行，让 MCP 连接工具，让 A2A 协调代理，让可观测性系统跟踪行为，并让 UAIX 发布另一方可以检查的验证器就绪记录、一致性数据包和项目内存切换。

桥剖面边界#

采用套件和一致性包现在包含验证器支持的桥接证据示例。正式的桥配置文件仍应将证据映射到 UAI-1 记录中，而不接管相邻的运行时行为。

• A2A 代理卡可以映射到 uai.capability.statement.v1 记录，但 A2A 仍然拥有本机发现和任务执行。
• A2A 任务更新可以映射到 uai.task.status.v1，但 UAI-1 不会成为流任务协议。
• MCP 工具调用可以映射到 uai.intent.request.v1 并且结果可以映射到 uai.intent.response.v1，但 MCP 仍然拥有会话生命周期和工具调用。
• OpenAPI 操作引用可以出现在 UAI-1 出处或主体元数据中，但 OpenAPI 仍然描述 HTTP API。
• DID/VC 信任证据和跟踪上下文链接可以在信封中声明，但 UAI-1 不需要一个全局凭证或跟踪堆栈。

紧凑型转运梯#

1. 键控 JSON：用于审查、文档、验证器输出和支持声明的人类可读源记录。
2. 缩小键控 JSON：相同的键控记录，没有空格，用于简单传输，其中可读性不太重要；验证器将其视为相同的键控记录。
3. 无钥匙JSON：使用公共的紧凑数组形式现场注册表在验证之前重建密钥记录；验证器当前接受此模式。
4. 别名 JSON:计划的工作，直到存在公共别名地图、测试样例、标准化规则和验证器期望。
5. CBOR 或消息包：研究跟踪或未来的运输工作，直到发布编码/解码奇偶性、路线行为和一致性证据。

标准化规则#

当前验证器支持 keyed-json、minified-keyed-json 和 keyless-json。在模式验证、JCS 规范化、散列、签名、验证器证据、发行说明或公共支持声明之前，每个接受的紧凑形式都必须规范化回完整键控的 JSON。现场订单是一张运输图；重建的键控 JSON 记录是审查和完整性基线。

示例比较#

下面的例子故意做得很小。它们显示了可读、缩小和无密钥形式之间的关系，而不将别名或二进制支持呈现为当前的公共行为。

{
  "uai_version": "1.0",
  "profile": "uai.intent.request.v1",
  "message_id": "msg-demo-001",
  "body": {
    "intent": "resolve-profile",
    "subject": "uai.task.status.v1"
  }
}

[
    "1.0",
    "uai.intent.request.v1",
    "msg-demo-001",
    null,
    null,
    null,
    null,
    null,
    [
        "resolve-profile",
        "uai.task.status.v1"
    ]
]

{"uai_version":"1.0","profile":"uai.intent.request.v1","message_id":"msg-demo-001","body":{"intent":"resolve-profile","subject":"uai.task.status.v1"}}

[
    "1.0",
    "uai.intent.request.v1",
    "msg-demo-001",
    null,
    null,
    null,
    null,
    null,
    [
        "resolve-profile",
        "uai.task.status.v1"
    ]
]

["1.0","uai.intent.request.v1","msg-demo-001",null,null,null,null,null,["resolve-profile","uai.task.status.v1"],null,null,[]]

[
    "1.0",
    "uai.intent.request.v1",
    "msg-demo-001",
    null,
    null,
    null,
    null,
    null,
    [
        "resolve-profile",
        "uai.task.status.v1"
    ],
    null,
    null,
    []
]

当前公众支持边界#

• 当前支持包括键控 JSON、缩小键控 JSON、无键 JSON 规范化、模式、注册表记录、示例、字段注册表、验证器行为、规范哈希等效证据、桥接证据示例、一致性包和实现跟踪。
• 无密钥传输与公共现场注册表相关联，并且必须保持可逆到密钥 JSON。
• 别名映射、二进制信封媒体类型、正式桥配置文件、SDK、CLI 和正式认证仍处于计划或研究轨道中，直到公共证据推动它们向前发展。
• 任何符合标准的语言都不应暗示 UAI-1 取代 A2A、MCP、OpenAPI、JSON 架构、DID/VC 系统、跟踪、签名或传输协议。

在哪里验证当前记录#

使用UAI-1对于合同，模式, 注册表, 示例，以及验证器作为证据，API参考和一致性包用于面向机器的切换，以及路线图加变更日志为未来的边界和释放轨迹。