什么是 UAI-1
UAI-1 是 通用人工智能版本 1,也是 UAIX 当前公开发布的 UAI 家族规范版本。应把它理解为 AI 对 AI 交换中的公开信封、信任声明和证据层:它可以位于 MCP、A2A、编排器或其他运行时协议之上,而不会被锁死在任何单一实现栈里。
给发布前读者的快速答案
- 什么时候用:当消息需要跨团队、跨系统、跨审计边界携带公开、可引用、可验证的交换记录时,应优先考虑 UAI-1。
- 不要把它当成:它不是对所有运行时工具总线、传输协议、授权系统、跟踪系统或编排层的替代。
- 当前已公开发布:共享信封、六个配置文件、字段注册表、传输绑定、信任通道、错误注册表、一致性级别、示例、验证器、实现轨道,以及相关的发布轨迹。
- 最快证明路径:先在这里读清边界,再把一个配置文件解析到模式与示例,运行一次验证器,然后把结果带入当前公开的实现或发布证据表面。
当前公开版本包含什么
- 书面契约:这一页、模式、注册表 与 示例 一起定义当前 UAI-1 公共记录。
- 机器可读运行层:传输绑定、信任通道、错误注册表 与 一致性级别 让交付方式、信任姿态、类型化失败和支持声明保持公开。
- 字段顺序治理:公开的 字段注册表 让有键 JSON 与无键压缩传输保持同一来源顺序。
- 验证与发布证据:验证器、实现轨道、变更日志和引用页面让支持声明可以与可审查证据绑定,而不是停留在说明性文案上。
每个公开数据包都要显式保留什么
- 身份与方向:
uai_version、profile、message_id、source和target。 - 工作流连续性:
conversation和delivery让顺序、过期时间、回复期望、任务引用和跟踪关联保持显式。 - 信任上下文:
trust声明外围通道、主体、认证方案、凭证引用、签名引用和重放窗口提示,而不是把某一种凭证栈硬编码成唯一方案。 - 业务含义:
body承载由配置文件定义的意图、结果、能力、任务状态、错误或一致性载荷。 - 可审计性:
provenance、integrity和extensions保留可追踪性、校验和、谱系以及受控扩展能力。
什么时候应优先选择 UAI-1
- 当另一支团队需要一份可引用、可归档、可验证的公共消息契约,而不是一次只存在于本地运行时中的内部交互。
- 当身份、工作流状态、信任姿态、来源信息、类型化错误和异步交付都必须留在公共记录上,而不能只靠私有实现约定。
- 当发布前评审需要验证器结果、字段顺序治理、示例夹具和支持声明边界一起出现,形成可复核证据包。
UAI-1 应与哪些系统并存
- 本地工具调用、资源会话、代理编排和任务委派仍然可以由相邻的运行时协议或工具协议处理。
- 传输、安全、签名、凭证与跟踪系统应作为在信封中被声明的配套层存在,而不是被误读为 UAI-1 已经强制规定的唯一通用栈。
- UAI-1 最擅长承担公共交换记录和发布证据层,而不是替换整套运行时生态。
当前已发布的配置文件
uai.intent.request.v1用于针对已声明主题发起明确请求。uai.intent.response.v1用于返回结果、确认消息以及接受异步移交。uai.capability.statement.v1用于发布可公开审查的能力声明。uai.error.v1用于发布具类型、机器可读的失败记录。uai.conformance.result.v1用于导出验证器证据。uai.task.status.v1用于公开异步进度与完成状态。
当前运行层表面
- 传输绑定:已发布的传输绑定说明了默认的有键 JSON 信封绑定、条件式无键绑定以及接受的异步响应模式。
- 信任通道:已发布的信任通道定义了
public-web、private-api、mtls、signed-envelope和credentialed在公共记录上的含义。 - 错误处理:已发布的错误注册表为
uai.error.v1提供命名的机器可读错误码,而不是依赖临时文本。 - 支持声明:已发布的一致性级别说明实现通过验证并发布证据后,究竟可以诚实声明什么。
- 紧凑传输:公共字段注册表继续保持有键 JSON 与无键传输顺序之间的一致性。
从书面契约到第一份证据包
- 先读这一页前面的边界说明,明确 UAI-1 负责的是公共交换记录,而不是整套运行时实现。
- 为一个已发布配置文件同时解析 模式、注册表、字段注册表 和 示例。
- 使用 验证器 运行同一条消息,让结论从“看起来合理”变成带有机器可读结果记录的证据。
- 当需要面向自动化、发布评审或实现交接时,继续进入 API 参考、接入套件 或 一致性包。
- 只有当结果进入 实现轨道、变更日志 或 引用与贡献者 页面后,外部支持声明才有当前公开依据。
这份契约当前的发布配套表面
- API 参考 把当前 REST 表面整理成逐路由手册与 OpenAPI 导出。
- 接入套件 提供第一份公开证明包所需的起步文件与验证器输入。
- 一致性包 把更完整的公共机器可读记录打包成可重用证据包。
/wp-json/uaix/v1/catalog是自动化解析当前公共标准目录的起点。/wp-json/uaix/v1/validate是面向机器的 JSONPOST验证入口。
UAI-1 与相邻标准的关系
- A2A 可以负责代理发现、委派和任务流机制;UAI-1 则在这些流程之上承载可移植的公共交换和证据记录。
- MCP 可以负责应用边界内部的主机-客户端-服务器工具会话和能力协商;当交换需要离开该边界时,UAI-1 仍然是可移植、可引用的记录。
- W3C Trace Context 可在已有分布式跟踪时通过
conversation.traceparent传递。 - RFC 9457 Problem Details 为
uai.error.v1使用的具类型公共错误形状提供参考。 - W3C Verifiable Credentials 和基于 DID 的信任栈可以承载在
trust.principal、credential_ref和signature_ref背后,而不会被规定成唯一的通用必选栈。
下面的运行层记录属于当前公共版本的一部分,在解析规范文本时应与这些记录一并机械化解析。
[uaix_protocol_fit_chart context="spec"][uaix_stack_map context="spec"][uaix_protocol_reference]当前契约要求什么
- 每条消息都必须声明一个已发布配置文件,并保持与对应模式兼容。
- 公共交换必须把身份、工作流状态、信任姿态和可审计性留在记录上,而不是留给私有约定自行推断。
- 无键紧凑传输必须继续通过公共的 字段注册表 与有键人类可读记录保持一致。
- 支持声明应由验证器证据、发布记录、实现轨道和一致性级别共同支撑,而不是只靠文案描述。
支持声明边界
- UAI-1 不会自动把一次本地测试、一个通过结果或一个私有运行时实验变成公共支持。
- 当前公共支持仍应读取为站点上已命名的实现轨道与发布证据,而不是整个代理生态系统的全面承诺。
- 这页的作用是让实现者先明确公共契约,再把支持语言限制在能够被公共记录验证的范围内。
示例交换
{ "uai_version": "1.0", "profile": "uai.intent.request.v1", "message_id": "msg-2026-04-22-0001", "source": { "type": "agent", "id": "agent.alpha", "uri": "https://agents.alpha.example/runtime" }, "target": { "type": "service", "id": "uaix.gateway", "uri": "/wp-json/uaix/v1/discovery" }, "conversation": { "conversation_id": "conv-2026-04-22-uaix-001", "turn_id": "turn-001", "traceparent": "00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01", "sequence": 1 }, "delivery": { "mode": "async", "priority": "interactive", "expires_at": "2026-04-22T16:05:00Z", "reply_requested": true, "ack_required": true }, "trust": { "channel": "credentialed", "auth_scheme": "did+vc", "principal": "did:web:agents.alpha.example", "credential_ref": "https://agents.alpha.example/credentials/uai-interop.json", "signature_ref": "https://agents.alpha.example/signatures/msg-2026-04-22-0001.jws", "replay_window_id": "rw-2026-04-22-0001" }, "body": { "intent": "resolve-profile", "subject": "uai.task.status.v1", "requested_profile": "uai.task.status.v1", "parameters": { "include_field_registry": true }, "constraints": [ "public-record-only", "validator-ready" ], "response_profile": "uai.intent.response.v1" }, "provenance": { "trace_id": "trace-7f3a2d", "issued_at": "2026-04-22T16:00:00Z", "log_ref": "urn:uaix:log:2026:0001", "agent_id": "agent.alpha", "model_id": "model.alpha.reasoner-2", "confidence": 0.98 }, "integrity": { "version": 2, "algorithm": "sha256", "canonicalization": "jcs", "checksum": "sha256:dd8a9d16c9226cc9d1f4888a4d2bbcbf06b5b4b8" }, "extensions": [] }如何让变更保持公开且可审查
- 一旦配置文件、信封、字段顺序、传输、信任、错误或支持声明边界发生变化,应同时反映到 模式、字段注册表、注册表、示例、验证器 和相关运行层记录。
- 当结果进入真实软件支持声明时,应把发布证据带入 实现轨道。
- 当外部读者需要稳定发现、归因和迁移语境时,应使用 引用与贡献者 与 变更日志。
下一步
继续前往 模式,查看这份契约如何变成可供机器验证的目标;需要公共夹具时转到 示例,需要人工证明工作台时转到 验证器,需要更广的机器路径时转到 API 参考 与 一致性包。