OpenAN / A2A-T 到底是什么：一份基于源码的拆解

智能体网关这个方向，文稿很多、能跑的东西很少。OpenAN 是目前唯一能读到实代码的电信级多智能体协议实现：IETF 那批草案（RTGWG / DMSC / OPSAWG）都还停留在文本，而 OpenAN 已经把「注册中心」和「编排中心」写出来了——核心代码约 11800 行 Python、762 次提交、Apache-2.0。

对做标准的人来说，代码比文稿更诚实：它暴露了哪些设计真被实现了、哪些还只是口号。本文基于 2026-08-31 克隆的 registry-center（AtomGit）与 a2a-t-sdk-python（GitHub project-openan 组织，v1.0.0）源码，未部署运行。

一、最关键的结论：A2A-T 不是新协议

注册中心的 AgentCard 校验直接 import 标准 A2A 的类型：

from a2a.types import AgentCard, AgentProvider, AgentSkill, AgentCapabilities, AgentInterface

整个数据模型没有重新定义，就是标准 A2A 的 AgentCard。A2A-T 的增强全部挂在 capabilities.extensions 字段上，注册中心只做数量与长度校验（单个 Agent ≤10 个扩展、单个扩展 JSON ≤512 字符），不解析内容。

这个「容器 + 不解析」的设计值得琢磨：好处是协议演进不用改注册中心；代价是注册中心无法校验扩展是否合规。对照 IETF 侧 draft-zhang-dmsc-gateway-directory-sync 主张的「能力目录应维护经过校验的能力信息」，这是一个真实存在的差距——也是两套体系可以互补的地方。

二、Task-T 的真实报文：YAML 头 + 提示词正文

SDK 里 task_prompt_format.py 全文不到 60 行，Task-T 的报文格式是：

---
scenario_code: <场景码>
language: <语言>
description: <描述>
---

<自由正文>

三字段必填，解析器手写、逐行 key:value。所谓「确定性任务模式」的落点是提示词工程，不是新报文协议——这是读代码前想不到的。

三、标准化主场在 TM Forum

SDK 源码里所有扩展 URI 都挂在 TM Forum 命名空间下：

https://projects.tmforum.org/a2aproject/telecommunication/extensions/Task-T/v1
https://projects.tmforum.org/a2aproject/telecommunication/extensions/Negotiation-T/v1

统一带 v1 版本号。这说明 A2A-T 的标准化主场在 TM Forum；IETF 侧草案做的是网络层视角，两者不是竞争关系——投标准前先想清楚去哪个组织投什么。

四、官方四个扩展，实现进度参差

官网架构页明确 4 个扩展（此前公众号流传的 6 个里，Memory-T / Governance-T 不在官方列表）：

扩展	SDK v1.0.0 实现情况
Task-T	✅ 提示词生成 + JSON Schema 槽位校验
Negotiation-T	✅ 三种协商类型，但具体语义基本是回声式透传
Notification-T	⚠️ 仅文档示例，源码零实现
Authorization-T	❌ 全库零命中，停留在纸面

交叉印证一个事实：注册中心「黑名单兜底、不解析扩展」+ SDK「不做鉴权」= 官方四个扩展里最关键的安全扩展，目前没有任何一份开源代码实现。这既是差距也是机会——运营商侧的授权管控标准正好补这一层。

五、成熟度：原型级，不是生产级

README 的「设计约束」一节是全篇最诚实的部分：单实例部署、Agent 注册上限默认 100 个、请求体 1 MB、默认文件存储，并明确写着「本模块用于内部系统集成，不可直接开放到公网」。官方路线图（2026.06 种子代码 → 2026.12 场景包 → 2027 商用验证）与这些数字是对得上的。

另外两处工程细节很「电信」：所有者隔离用 TLS 客户端证书 CN 而非账号体系（信任来自网络层）；JWK 密钥分发端点单独限流到 10 次/秒（比其他接口低一个数量级，防放大攻击）。

六、对标准工作的三点启示

1. 「扩展走容器、不解析内容」需要被标准回答——工程灵活与能力可校验之间的张力，IETF 目录同步草案正好是另一半答案。
2. 语义检索已是标配，但检索的确定性与可解释性没有保障机制——电信网管场景里这是真问题。
3. 审核流程被实现成二值状态机（registered → published），对照运营商清册的「在网/退网/待退网/冻结」多态模型，差距明显——定义智能体能力目录状态模型时，这里是现成的对照案例。

边界说明

所有结论来自两个仓库的 main 分支（2026-08-31 克隆）与 openan.dev 官网，未实际部署运行；Java 版 SDK 未读；对成熟度的判断基于设计约束的推断，不代表官方立场。代码均可自行验证：git clone --depth 1 https://atomgit.com/OpenAN/registry-center.git。