Hotdry.
归档
ai-systems

AI URI Scheme：为人工智能系统设计的统一资源标识符标准化

深入解析IETF草案中的AI URI方案设计，探讨其语法结构、HTTPS网关集成机制，以及为AI系统互操作性带来的标准化路径。

随着人工智能系统的快速发展，AI 代理、模型和工具之间的互操作性需求日益迫切。2025 年 10 月，IETF（互联网工程任务组）收到了一份名为《AI URI Scheme》的实验性草案，提出为人工智能资源定义专用的统一资源标识符（URI）方案。这一提案旨在为自主系统和机器人提供原生连接点，同时通过 HTTPS 网关保持与现有 Web 栈的兼容性。

AI URI Scheme 的设计动机与核心价值

当前 AI 系统间的通信大多依赖于专有 API 或基于 HTTP 的自定义协议，这种碎片化的现状带来了显著的互操作性问题。AI URI Scheme 的核心目标是为 AI 可寻址资源（包括代理、模型、工具和任务）提供标准化的标识和访问机制。

草案作者 Aram Sogomonian 在文档中明确指出："ai URI scheme identifies AI-addressable resources such as agents, models, tools, and tasks." 这一设计允许部署方选择性地通过原生 AI 系统解析ai:标识符，或通过 HTTPS 网关实现与现有 Web 基础设施的兼容。

从技术演进的角度看，AI URI Scheme 的提出反映了 AI 系统从孤立应用向网络化服务转型的趋势。随着自动驾驶汽车、工业机器人和智能家居设备的普及，这些系统需要更标准化的通信协议来确保安全、可靠的互操作。

语法结构与设计原则

AI URI Scheme 严格遵循 RFC 3986 中定义的 URI 通用语法规范。草案中给出的非规范性语法定义为：

ai-uri = "ai:" hier-part [ "?" query ] [ "#" fragment ]

这一简洁的语法设计体现了几个关键原则：

1. 向后兼容性

方案保持了与现有 URI 解析器的兼容性，任何符合 RFC 3986 的解析器都能正确处理ai:前缀的 URI。这种设计降低了采用门槛，使得现有系统可以逐步集成对新方案的支持。

2. 分层结构

hier-part部分支持分层路径结构，这为组织复杂的 AI 资源命名空间提供了灵活性。例如：

  • ai:/agent/forklift-42?task=load&zone=A3
  • ai://factory.example/pay?amount=10&currency=USD

第一个示例展示了相对路径的使用，适用于本地或私有网络中的 AI 资源；第二个示例则包含了权威部分（authority），适用于跨域访问的场景。

3. 查询参数标准化

查询字符串部分允许传递操作参数，这与 HTTP URL 的设计理念一致。草案建议但不强制规定特定的参数格式，为不同 AI 服务的特定需求留出了扩展空间。

AIIP：底层协议架构

草案中引入了一个重要概念 ——AIIP（Artificial Intelligence Internet Protocol）。作者明确指出："While ai:// is the URI scheme, AIIP defines resolution and interaction semantics."

AIIP 作为操作协议，定义了ai://资源的寻址、解析和调用语义。这种分离设计具有显著优势：URI 方案负责标识，而底层协议负责交互。这种分层架构允许不同的传输协议（如基于 TCP 的自定义协议、QUIC 或 WebSocket）实现相同的 AIIP 语义。

从工程实现角度看，AIIP 需要解决几个关键问题：

  1. 资源发现：如何找到特定 AI 服务的端点
  2. 身份验证：如何验证 AI 代理的身份
  3. 授权机制：如何控制访问权限
  4. 会话管理：如何维护长时间运行的交互会话

HTTPS 网关：渐进式部署的关键

考虑到大多数用户代理不会原生实现ai方案或 AIIP 协议，草案提出了 HTTPS 网关作为过渡方案。这种设计允许立即实现互操作性，同时为最终的原生支持铺平道路。

网关发现机制

草案详细定义了从 HTTPS 到 AI 资源的发现机制，提供了多种可选方案：

服务器可以在 HTTP 响应中包含 Link 头部，指示相关的 AI 端点：

Link: <ai://bank/service/payments>; rel="aiip"

HTML 链接关系

对于渐进式增强的 Web 应用，可以在 HTML 中使用 link 元素：

<link rel="aiip" href="ai://bank/service/payments">

Well-known 资源

在/.well-known/aiip路径下提供 JSON 格式的端点描述：

{
  "endpoint": "ai://bank/service/payments",
  "jwks": "https://www.bank.example/.well-known/aiip.jwks.json",
  "scopes": ["initiate-payment", "check-balance"],
  "policy": {
    "auth": "oauth2",
    "mtls": true,
    "requireSignedResults": true
  }
}

DNS 引导（可选）

通过 SRV 或 TXT 记录提供发现信息：

_aiip._tcp.bank.example.  300 IN SRV 0 0 443 aiip.bank.example.
_aiip.bank.example.       300 IN TXT "endpoint=ai://bank/service/payments"

网关行为规范

HTTPS 到 AIIP 网关必须遵循严格的行为规范：

  1. URI 映射：将嵌入的ai:// URI 映射到网关控制的 HTTPS URL
  2. 输入验证：解析并规范化ai:// URI，拒绝格式错误或模糊的输入
  3. 身份验证：向 AI 端点进行身份验证，并验证响应的来源
  4. 授权执行：根据用户的 Web 会话强制执行授权策略
  5. 安全保护：保持至少等同于 TLS 1.3 的机密性和完整性
  6. 防降级：防止身份验证或授权的降级攻击

例如，网关可以将原始 URI：

ai://bank/service/payments?amount=10&currency=USD

映射为：

https://ai.example/gateway/bank/service/payments?amount=10&currency=USD

安全与隐私考量

AI URI Scheme 草案对安全和隐私问题给予了充分重视，这在涉及金融操作或物理设备控制的场景中尤为重要。

安全要求

实现必须对端点进行身份验证，并应用授权和安全策略。网关在转换ai:到 HTTPS 时，必须保持来源证明并提供符合 RFC 8446（TLS 1.3）和 RFC 9110（HTTP 语义）的传输安全。

草案特别强调："Gateways MUST prevent downgrades; do not weaken authentication or authorization versus native AIIP." 这一要求确保了网关不会成为安全薄弱环节。

隐私保护

通过 HTTPS 网关访问ai://资源可能会向中间方暴露元数据，如目标标识符、来源站点和时间信息。草案建议网关应最小化日志记录，应用严格的数据保留限制，并避免将标识符保留超过操作必要的时间。

来源证明和结果签名可能包含可链接的标识符，部署方应在适当的情况下应用最小权限范围和匿名化技术。

命名空间管理与治理

为了支持全球唯一性和自主系统的安全操作，ai:标识符的命名空间管理预计将由人工智能互联网基金会（AIIF）协调。AIIF 标识符注册机构（AIID）将运营 AI 根注册表，并管理ai://命名空间的标识符分配和操作策略。

这种治理模式与互联网域名系统（DNS）的管理有相似之处，但专门针对 AI 资源的特点进行了优化。关键考虑因素包括：

  1. 标识符持久性：确保 AI 资源的长期可寻址性
  2. 委托管理：支持分层命名空间委托
  3. 争议解决：建立标识符争议的解决机制
  4. 政策执行：确保符合安全、隐私和互操作性政策

实现挑战与标准化路径

尽管 AI URI Scheme 提出了有前景的设计，但其标准化之路仍面临多个挑战。

技术挑战

  1. 协议语义定义：AIIP 的具体协议语义需要进一步详细定义，包括消息格式、错误处理、流控制等
  2. 性能优化：AI 交互往往涉及大量数据传输和实时处理，协议需要针对这些场景进行优化
  3. 向后兼容：确保新协议与现有 AI 系统和工具的平滑集成

社区接受度

Hacker News 上的讨论反映了社区的一些关切。有评论指出："between this ai://proposal and the author's aiip://proposal, there is no indication why this is needed or why what we already have today does not suffice." 这种反馈表明，提案需要更清楚地阐述其独特价值和必要性。

标准化进程

草案目前的状态是 "实验性"，这意味着它还需要经过 IETF 的严格审查流程，包括：

  1. 工作组采纳：需要相关 IETF 工作组的正式采纳
  2. 社区评审：广泛的社区技术评审和反馈
  3. 迭代修订：基于反馈进行多次修订
  4. IESG 批准：互联网工程指导组的最终批准

工程实现建议

对于考虑采用 AI URI Scheme 的工程团队，以下是一些具体的实现建议：

渐进式实施策略

  1. 从网关开始：首先实现 HTTPS 网关，在不改变客户端的情况下提供 AI 服务
  2. 原型验证：在小规模场景中验证协议设计的合理性
  3. 性能基准测试：建立性能基准，指导协议优化
  4. 安全审计：进行彻底的安全审计，特别是网关实现

开发工具支持

  1. SDK 开发：为流行编程语言提供 AI URI 解析和 AIIP 客户端 SDK
  2. 测试工具：开发协议一致性测试套件
  3. 监控集成：与现有监控系统（如 Prometheus、Grafana）集成
  4. 调试工具：提供协议级别的调试和诊断工具

部署最佳实践

  1. 双重协议支持：同时支持 AIIP 原生协议和 HTTPS 网关
  2. 优雅降级：在网络条件不支持 AIIP 时自动降级到 HTTPS
  3. 缓存策略：为 AI 资源发现实现智能缓存
  4. 负载均衡：支持 AIIP 端点的负载均衡和故障转移

未来展望

AI URI Scheme 代表了 AI 系统互操作性标准化的重要一步。如果成功标准化，它可能带来以下深远影响：

生态系统效应

  1. 降低集成成本：标准化的协议将显著降低不同 AI 系统间的集成成本
  2. 促进创新：开发者可以更专注于 AI 算法本身，而不是通信协议
  3. 提高可靠性：经过严格标准化的协议通常具有更好的可靠性和安全性

新应用场景

  1. 跨域 AI 协作：不同组织间的 AI 系统可以安全、可靠地协作
  2. 边缘计算集成：边缘设备上的 AI 系统可以更轻松地接入云服务
  3. 实时控制系统：工业自动化和机器人控制系统的标准化通信

标准化演进

随着 AI 技术的不断发展，AI URI Scheme 可能需要扩展以支持：

  1. 流式交互：支持实时、流式的 AI 交互模式
  2. 联邦学习：为分布式机器学习提供标准化的通信协议
  3. 可解释性接口：标准化的 AI 决策解释和审计接口

结论

AI URI Scheme 草案为 AI 系统的互操作性提供了一个有前景的技术框架。其核心价值在于将 AI 资源标识与访问协议标准化，同时通过 HTTPS 网关机制确保了与现有 Web 基础设施的兼容性。

尽管草案仍处于早期阶段，且面临技术挑战和社区接受度的考验，但其提出的设计原则和架构思路为 AI 系统标准化提供了有价值的参考。工程团队可以关注这一标准的演进，并在适当的场景中探索相关技术的应用。

最终，AI 系统互操作性的标准化不仅是一个技术问题，更是推动 AI 技术广泛应用和创新的基础设施问题。AI URI Scheme 的提出，标志着这一重要议题开始进入主流技术社区的视野。

资料来源：

  1. IETF 草案文档：https://www.ietf.org/archive/id/draft-sogomonian-ai-uri-scheme-01.html
  2. Hacker News 讨论：https://news.ycombinator.com/item?id=46266238
查看归档