IETF Agent-GW 草案拆解语义路由 工作记忆 KDN多 Agent 基础设施为什么开始向网络层下沉2026 年 7 月IETF 同时发布了两份互联网草案直接瞄准多 Agent 系统的网络基础设施。draft-agent-gw-02 提出了三个核心原语语义路由、工作记忆和知识交付网络。这不是又一个应用层协议而是试图把 Agent 通信从 HTTP 往下推到网络层。当 MCP 和 A2A 刚刚完成标准化分工IETF 就开始定义它们之下的那一层。本文拆解这份草案的技术细节、工程含义和对开发者的实际影响。一、从应用层到网络层为什么 Agent 基础设施需要下沉过去两年Agent 协议标准化走了一条清晰的路径。MCP 定义了 Agent 与工具之间的垂直通信A2A 定义了 Agent 之间的水平通信。两者都在应用层工作用 JSON-RPC 2.0 作为消息格式。MCP 的 SDK 月下载量达到 1.1 亿次公共注册 Server 超过 2 万个。A2A v1.0 已有 150 多个组织在生产环境中使用GitHub Star 超过 2.2 万。但当 Agent 系统规模超过几十个节点时应用层协议开始暴露瓶颈。第一个瓶颈是路由效率。每个请求都要解析 JSON body 才能知道该发给哪个 Agent。在高并发场景下JSON 解析的 CPU 开销成为网关的性能瓶颈。MCP 2026-07-28 重构后新增了 Mcp-Method 和 Mcp-Name 两个必填 Header。这让网关可以不解析 body 就做基本路由但粒度只到工具调用级别。第二个瓶颈是状态管理。MCP 无状态化后跨 Agent 的共享上下文没有标准方式表达。每个团队都在自己搭共享存储Redis、数据库、对象存储各搞一套。第三个瓶颈是推理资源浪费。每个 Agent 独立跑推理大量 KV Cache 被重复计算。在典型的多 Agent 文档分析场景中不同 Agent 处理同一文档的不同部分。它们的 KV Cache 有大量重叠但用完即弃没有任何复用机制。IETF 的 Agent-GW 草案正是为了解决这三个问题而生。二、语义路由按意图分发不按端点分发传统路由基于 URL 或 RPC 方法名请求发给哪个服务是预先配置的。语义路由的核心改变是路由决策基于请求的意图和目标 Agent 的能力声明。草案定义了一个 Agent 能力描述格式类似 A2A 的 Agent Card 但更轻量。每个 Agent 在注册时声明自己能处理哪类任务用结构化标签而非自由文本。标签体系分为三层领域标签、技能标签和约束标签。领域标签标识 Agent 擅长的业务领域比如代码审查、数据分析、文档生成。技能标签标识 Agent 具备的具体能力比如调用 GitHub API、操作 PostgreSQL。约束标签标识 Agent 的运行限制比如只处理英文、需要人工确认、有 SLA 要求。网关收到请求后先用轻量分类器提取意图特征。分类器不依赖大模型而是用基于规则的关键词匹配加简单统计模型。意图特征与已注册 Agent 的能力标签做交集匹配计算兼容性得分。匹配算法不用向量相似度而是用确定性的标签交集和权重评分。这样做的好处是路由延迟可以控制在亚毫秒级不需要调用嵌入模型。当多个 Agent 都能处理同一类请求时网关根据负载和优先级做二次调度。负载信息通过 Agent 定期上报的心跳获取包括当前队列深度和 GPU 利用率。优先级由请求的业务属性决定比如VIP 用户的请求优先路由到高性能 Agent。这比 MCP 的 tools/list 动态发现更进一步。MCP 的发现在应用层工作客户端需要先连接 Server 再获取工具列表。语义路由在网络层工作请求到达网关时就已经完成了路由决策。开发者不再需要在应用代码里硬编码这个工具调哪个 Server。语义路由的另一个优势是支持灰度发布。当新版 Agent 上线时网关可以把特定类型的请求路由到新版本做灰度验证。这比基于权重的灰度更精准不是随机分配10%流量而是按业务语义筛选。比如把低风险的查询类请求发给新版本高风险的写入类请求留在旧版本。三、工作记忆跨步骤的共享结构化上下文MCP 2026-07-28 重构后协议层彻底无状态状态管理被踢回应用层。requestState 是单个 Server 维护的不透明句柄用于多轮交互的状态续接。但多 Agent 协作场景中多个步骤之间需要共享上下文是刚需。比如一个代码审查任务Agent A 分析代码结构Agent B 检查安全漏洞。Agent B 需要知道 Agent A 发现的模块依赖关系才能判断漏洞的影响范围。在没有标准化机制之前这种信息传递要么靠消息队列要么靠共享数据库。消息队列的问题是消息丢失后无法恢复且消费顺序不保证。共享数据库的问题是需要定义 schema每个任务流的 schema 都不同。草案提出的工作记忆原语是一个在网络层维护的轻量共享状态空间。它不是数据库也不是缓存而是一个结构化的上下文容器。工作记忆的生命周期绑定到一个任务流而不是某个特定 Agent。任务流启动时创建工作记忆任务流结束时归档或销毁。任何参与该任务流的 Agent 都可以读取和追加工作记忆的内容。写入是追加式的不允许覆盖已有条目保证审计可追溯。每条记忆条目包含时间戳、写入者身份、标签和内容四个字段。内容是任意 JSON 对象标签用于后续检索时的过滤。读取支持按标签过滤Agent 只拉取与当前步骤相关的上下文片段。过滤是服务端执行的不需要把整个工作记忆下载到本地再筛选。这解决了一个实际痛点Agent A 处理完的结果Agent B 怎么拿到在没有工作记忆之前要么通过消息传递要么自己搭共享存储。消息传递的问题是丢失后无法恢复共享存储的问题是每个团队重复造轮子。工作记忆把这两种模式标准化了追加写、过滤读、任务级生命周期。工作记忆的实现不需要复杂的分布式一致性协议。因为写入是追加式的不存在并发写冲突。读取是过滤式的不需要全量同步。用一个简单的日志存储加标签索引就能满足大部分需求。这也是草案敢于在网络层提出这个原语的原因实现复杂度可控。四、知识交付网络复用推理产物降低重复计算KDN 是草案中最超前的部分也是争议最大的部分。核心想法是当多个 Agent 处理相似任务时前一个 Agent 的推理中间产物可以被后续 Agent 复用。这里的推理产物主要指 KV Cache——Transformer 模型在推理过程中产生的注意力状态。KV Cache 的作用是缓存已计算的 Key 和 Value 向量避免重复计算。在当前的 Agent 系统中每个 Agent 独立跑推理KV Cache 用完即弃。如果两个 Agent 处理的是同一文档的不同部分它们的 KV Cache 有大量重叠。重叠的部分主要是文档的共享上下文比如项目结构、依赖关系、配置信息。KDN 提议在网络层建立一个推理产物分发网络类似 CDN 但服务于推理过程。第一个 Agent 跑完推理后KV Cache 被上传到 KDN 节点。上传是异步的不阻塞 Agent 的正常返回。后续 Agent 在启动推理前先查询 KDN 是否有可复用的缓存。查询基于任务的上下文指纹比如文档哈希或项目标识符。如果有匹配的缓存直接加载到本地推理引擎跳过重复的前向计算。草案估算在典型的多 Agent 文档分析场景中KV Cache 复用可以减少 40% 到 60% 的推理计算量。但这个方案面临几个现实挑战。第一KV Cache 的格式与模型架构强绑定不同模型之间无法直接复用。GPT-4 的 KV Cache 和 Claude 的 KV Cache 格式完全不同。即使是同一模型的不同版本缓存格式也可能不兼容。第二KV Cache 的体积很大一个 70B 模型的单次推理缓存可达数十 GB。在网络上传输这么大的数据量延迟可能超过重新计算的时间。第三安全问题KV Cache 可能泄露推理过程中的敏感信息。缓存中包含了模型对输入的注意力分布可以反推出哪些输入片段被重点关注。草案承认这些挑战把 KDN 定位为长期研究方向而非短期可落地方案。但在特定场景下KDN 的收益是实实在在的。比如一个代码库有50个文件10个 Agent 各自审查5个文件。每个 Agent 都需要理解项目的整体结构和依赖关系。没有 KDN 时10个 Agent 各自跑一遍项目分析消耗10倍的推理资源。有 KDN 时第一个 Agent 跑完后把项目结构的 KV Cache 上传。后续9个 Agent 直接加载缓存只跑文件级别的增量推理。这种场景下推理成本可以降低一个数量级。五、三层协议栈的成型把 MCP、A2A 和 Agent-GW 放在一起看一个三层协议栈正在成型。最上层是 MCP负责 Agent 与工具之间的垂直连接。中间层是 A2A负责 Agent 与 Agent 之间的水平协作。最底层是 Agent-GW负责网络级的路由、状态和资源分发。每一层解决不同粒度的问题互不重叠。维度MCPA2AAgent-GW通信轴垂直Agent→工具水平Agent↔Agent网络网关→Agent核心抽象Tool / Resource / PromptAgent Card / Task / MessageRoute / Working Memory / KDN路由粒度工具调用级别Agent 能力级别任务意图级别状态管理无状态2026-07-28Task 生命周期工作记忆任务级传输格式JSON-RPC 2.0JSON-RPC 2.0 / gRPC待定草案阶段治理方Linux Foundation AAIFLinux Foundation LF AI DataIETF这个分层与互联网的经典协议栈高度相似。MCP 类似 HTTP定义应用层的请求和响应格式。A2A 类似 SMTP 或 SIP定义实体间的交互协议。Agent-GW 类似 IP 和 BGP定义网络层的寻址和转发。Google 之前用了一个精辟的比喻A2A 是两只手握手的姿势MCP 是每只手拿什么工具。现在可以补上第三句Agent-GW 是手与手之间的那条神经。2026 年 6 月Linux 基金会 Agentic AI Foundation 发布了 MCP 与 A2A 的融合草案。草案确认了两者的分工A2A 是 Agent 间的水平总线MCP 是 Agent 到工具的垂直总线。Agent-GW 草案在这个基础上进一步定义了总线之下的网络层。六、与现有标准的关系补充而非替代草案明确声明 Agent-GW 不替代 MCP 和 A2A。它补充的是 MCP 和 A2A 都没有覆盖的网络层能力。MCP 2026-07-28 重构后路由头 Mcp-Method 和 Mcp-Name 成为必填字段。这在应用层提供了基本的路由能力但粒度只到工具调用级别。Agent-GW 的语义路由在更粗的粒度工作按任务类型分发不是按单次调用分发。两者是互补的Agent-GW 决定请求发给哪个 AgentMCP 决定 Agent 内部调用哪个工具。工作记忆与 MCP 的 requestState 也是互补关系。requestState 处理的是单个 Server 内部的多轮交互状态续接。工作记忆处理的是跨多个 Agent 的共享结构化上下文协调。一个管纵向深度一个管横向广度两者解决不同维度的问题。类比来看requestState 像是单个进程的栈帧工作记忆像是共享内存段。A2A 的 Task 生命周期管理submitted、working、completed描述的是任务状态。工作记忆描述的是任务过程中产生的上下文数据。状态和数据是两个维度A2A 管状态流转Agent-GW 管数据共享。七、对开发者的实际影响短期来看Agent-GW 草案还是互联网草案阶段距离 RFC 还有很长的路。但草案提出的三个问题——路由效率、共享状态、推理复用——是真实存在的。当前的解决方案要么粗糙要么重复造轮子要么浪费资源。对于正在构建多 Agent 系统的团队有三个值得关注的工程实践。第一路由层与应用层分离。不要在业务代码里硬编码这个请求发给哪个 Agent。把路由决策抽到独立层用能力标签而非 IP 地址做分发。这样当 Agent 实例扩缩容时路由逻辑不需要改。可以用一个简单的标签匹配服务实现不需要复杂的语义理解。第二任务级共享上下文标准化。多 Agent 协作时用一个共享的结构化容器传递中间结果。容器的写入是追加式的读取是按标签过滤的。不要依赖消息传递的可靠性也不要依赖全局状态的强一致性。用 Redis 的 Stream 或 PostgreSQL 的 JSONB 就能实现基本功能。下面是一个基于 Redis Stream 的工作记忆最小实现import redis import json from datetime import datetime class WorkingMemory: def __init__(self, task_id: str, redis_client: redis.Redis): self.stream_key fwm:{task_id} self.r redis_client def append(self, agent_id: str, tags: list, content: dict): entry { agent: agent_id, tags: ,.join(tags), ts: datetime.utcnow().isoformat(), data: json.dumps(content, ensure_asciiFalse), } self.r.xadd(self.stream_key, entry) def read(self, tag_filter: str None, count: int 100): entries self.r.xrevrange(self.stream_key, countcount) results [] for _id, fields in entries: if tag_filter and tag_filter not in fields.get(tags, ): continue results.append({ agent: fields[agent], tags: fields[tags].split(,), ts: fields[ts], data: json.loads(fields[data]), }) return results # 用法示例 r redis.Redis() wm WorkingMemory(task-001, r) wm.append(agent-a, [structure, deps], {modules: [auth, db]}) wm.append(agent-b, [security, vuln], {cve: CVE-2026-1234}) deps wm.read(tag_filterdeps)这段代码展示了工作记忆的核心语义追加写、标签过滤、任务级生命周期。第三推理产物的缓存意识。如果你的多 Agent 系统处理的是相似文档或重复任务。考虑在 Agent 之间传递 KV Cache 或推理中间结果。即使不能直接复用至少可以避免重复加载相同的上下文。用 prompt caching 机制如果模型提供商支持可以在单次会话内实现缓存复用。八、中国厂商的标准化策略值得注意的是华为、阿里、腾讯在开放原子开源基金会下成立了专门的大模型与智能体工作组。他们采取的策略是先在国内协会内达成共识再由三家公司作为代表分别向 Linux 基金会或 ISO 组织提交中国提案。这种内外联动的标准化策略使中国在 AI 标准制定上的话语权在 2026 年提升了近三倍。国标 GB/Z 185《人工智能 智能体互联》的八项标准覆盖了身份码、身份管理、能力描述、发现、交互和工具调用。补的正是 MCP 和 A2A 最弱的身份治理环节。IETF Agent-GW 草案的语义路由部分与中国厂商强调的可信身份和能力描述有天然的对齐点。如果草案最终采纳了基于能力标签的路由机制中国的国标体系可以直接对接。中国电子技术标准化研究院牵头的七十余家企业参与了标准制定。美团、滴滴、智谱、用友、联想等公司已经接入了 AIP 协议的开源 V2.1 版本进行试点。九、风险与不确定性草案面临几个现实挑战。第一标准化周期。从互联网草案到 RFC 通常需要两到五年Agent 技术的迭代速度远快于标准化速度。等草案成为标准时Agent 架构可能已经发生了根本性变化。历史上有过先例HTTP/2 从草案到 RFC 花了将近三年。而 Agent 领域的变化速度比 Web 快得多三个月就是一个代际。第二产业共识。MCP 和 A2A 的成功在于有 Anthropic 和 Google 这样的头部公司推动。Agent-GW 草案的推动者相对分散缺乏一个明确的主导方。没有主导方意味着缺乏一个可以快速迭代参考实现的工程团队。MCP 的成功很大程度上归功于 Anthropic 的 TypeScript 和 Python SDK。A2A 的成功归功于 Google 的 ADK 和 AgentSpace 集成。Agent-GW 需要类似的工程投入才能从草案走向可用。第三技术可行性。KDN 的 KV Cache 复用面临格式兼容、传输带宽和安全泄露三重挑战。在模型架构快速演进的背景下缓存复用的工程复杂度可能超过收益。仅格式兼容一项就需要所有主流推理引擎达成共识。vLLM、TensorRT-LLM、SGLang 的缓存格式各不相同。第四与现有基础设施的集成。Kubernetes 的 Gateway API 已经定义了路由和服务发现的标准。Envoy 和 Higress 等网关已经支持 MCP 协议的解析和路由。Agent-GW 的语义路由需要与这些现有标准协调而不是另起炉灶。否则会出现两套路由体系并存的混乱局面。十、给工程团队的落点清单第一关注但不要等待。草案的方向是对的但落地时间不确定。先把路由层和应用层分离为未来的标准化路由做好架构准备。第二任务级共享上下文现在就可以做。不需要等标准出来用追加式日志加标签过滤就能实现基本功能。关键是把写入和读取的接口标准化底层实现可以随时替换。第三推理缓存是长期优化方向。当前优先级不高但如果你的系统有大量重复推理值得提前研究。先从 prompt caching 开始逐步探索跨 Agent 的缓存复用。第四跟踪 IETF 的 Agent 相关工作组。除了 draft-agent-gw-02还有 draft-agent-framework 和 draft-agent-security 等相关草案正在推进。这些草案共同构成了 Agent 网络基础设施的标准化蓝图。订阅 IETF 的 agent-wg 邮件列表可以获取最新进展。第五评估现有网关的扩展能力。如果你已经在用 Envoy、Higress 或 Lunar.dev MCPX 等网关。关注它们对语义路由的支持计划提前做好架构预留。这些网关很可能在草案成为 RFC 之前就提供实验性支持。结语MCP 和 A2A 解决了 Agent 怎么连接和怎么协作的问题。IETF Agent-GW 草案试图回答下一个问题当 Agent 数量达到百万级时网络层该怎么支撑。语义路由让请求按意图而非地址分发。工作记忆让多个 Agent 共享任务上下文而不需要集中式存储。KDN 让推理产物在网络层被复用而不是每个 Agent 从零开始。这三个原语单独看都不复杂但组合在一起构成了 Agent 基础设施的下一个抽象层。从2024年MCP诞生到2026年A2A稳定运行再到IETF开始定义网络层。Agent 基础设施的标准化只用了两年就走完了 Web 时代十年的路。正如 TCP/IP 之于 Web、Kubernetes 之于云原生Agent 时代也需要自己的网络层标准。IETF 的介入标志着这个讨论从要不要标准化进入了怎么标准化的阶段。对于开发者而言现在是理解这些草案方向、调整架构预期的最佳时机。不需要等标准出来才行动先把路由和状态管理从应用代码中剥离出来。当标准化的那一天到来时你的架构已经准备好了。这正是草案最大的价值不是告诉你怎么实现而是告诉你方向在哪。附录关键术语速查术语含义类比语义路由按请求意图和 Agent 能力标签分发流量类似 DNS 按域名解析 IP但粒度到任务类型工作记忆任务级的共享结构化上下文空间类似 POSIX 共享内存但生命周期绑定任务流KDN知识交付网络分发和复用推理产物类似 CDN 缓存静态资源但缓存的是 KV CacheKV CacheTransformer 推理过程中的注意力状态缓存类似 CPU 的 L2 缓存避免重复计算draft-agent-gw-02IETF 多 Agent 网关互联网草案第二版类似早期的 HTTP 草案定义网络层规范Agent CardA2A 协议中 Agent 的能力声明类似 DNS SRV 记录声明服务能力和端点
IETF Agent-GW 草案拆解：语义路由 + 工作记忆 + KDN，多 Agent 基础设施为什么开始向网络层下沉
IETF Agent-GW 草案拆解语义路由 工作记忆 KDN多 Agent 基础设施为什么开始向网络层下沉2026 年 7 月IETF 同时发布了两份互联网草案直接瞄准多 Agent 系统的网络基础设施。draft-agent-gw-02 提出了三个核心原语语义路由、工作记忆和知识交付网络。这不是又一个应用层协议而是试图把 Agent 通信从 HTTP 往下推到网络层。当 MCP 和 A2A 刚刚完成标准化分工IETF 就开始定义它们之下的那一层。本文拆解这份草案的技术细节、工程含义和对开发者的实际影响。一、从应用层到网络层为什么 Agent 基础设施需要下沉过去两年Agent 协议标准化走了一条清晰的路径。MCP 定义了 Agent 与工具之间的垂直通信A2A 定义了 Agent 之间的水平通信。两者都在应用层工作用 JSON-RPC 2.0 作为消息格式。MCP 的 SDK 月下载量达到 1.1 亿次公共注册 Server 超过 2 万个。A2A v1.0 已有 150 多个组织在生产环境中使用GitHub Star 超过 2.2 万。但当 Agent 系统规模超过几十个节点时应用层协议开始暴露瓶颈。第一个瓶颈是路由效率。每个请求都要解析 JSON body 才能知道该发给哪个 Agent。在高并发场景下JSON 解析的 CPU 开销成为网关的性能瓶颈。MCP 2026-07-28 重构后新增了 Mcp-Method 和 Mcp-Name 两个必填 Header。这让网关可以不解析 body 就做基本路由但粒度只到工具调用级别。第二个瓶颈是状态管理。MCP 无状态化后跨 Agent 的共享上下文没有标准方式表达。每个团队都在自己搭共享存储Redis、数据库、对象存储各搞一套。第三个瓶颈是推理资源浪费。每个 Agent 独立跑推理大量 KV Cache 被重复计算。在典型的多 Agent 文档分析场景中不同 Agent 处理同一文档的不同部分。它们的 KV Cache 有大量重叠但用完即弃没有任何复用机制。IETF 的 Agent-GW 草案正是为了解决这三个问题而生。二、语义路由按意图分发不按端点分发传统路由基于 URL 或 RPC 方法名请求发给哪个服务是预先配置的。语义路由的核心改变是路由决策基于请求的意图和目标 Agent 的能力声明。草案定义了一个 Agent 能力描述格式类似 A2A 的 Agent Card 但更轻量。每个 Agent 在注册时声明自己能处理哪类任务用结构化标签而非自由文本。标签体系分为三层领域标签、技能标签和约束标签。领域标签标识 Agent 擅长的业务领域比如代码审查、数据分析、文档生成。技能标签标识 Agent 具备的具体能力比如调用 GitHub API、操作 PostgreSQL。约束标签标识 Agent 的运行限制比如只处理英文、需要人工确认、有 SLA 要求。网关收到请求后先用轻量分类器提取意图特征。分类器不依赖大模型而是用基于规则的关键词匹配加简单统计模型。意图特征与已注册 Agent 的能力标签做交集匹配计算兼容性得分。匹配算法不用向量相似度而是用确定性的标签交集和权重评分。这样做的好处是路由延迟可以控制在亚毫秒级不需要调用嵌入模型。当多个 Agent 都能处理同一类请求时网关根据负载和优先级做二次调度。负载信息通过 Agent 定期上报的心跳获取包括当前队列深度和 GPU 利用率。优先级由请求的业务属性决定比如VIP 用户的请求优先路由到高性能 Agent。这比 MCP 的 tools/list 动态发现更进一步。MCP 的发现在应用层工作客户端需要先连接 Server 再获取工具列表。语义路由在网络层工作请求到达网关时就已经完成了路由决策。开发者不再需要在应用代码里硬编码这个工具调哪个 Server。语义路由的另一个优势是支持灰度发布。当新版 Agent 上线时网关可以把特定类型的请求路由到新版本做灰度验证。这比基于权重的灰度更精准不是随机分配10%流量而是按业务语义筛选。比如把低风险的查询类请求发给新版本高风险的写入类请求留在旧版本。三、工作记忆跨步骤的共享结构化上下文MCP 2026-07-28 重构后协议层彻底无状态状态管理被踢回应用层。requestState 是单个 Server 维护的不透明句柄用于多轮交互的状态续接。但多 Agent 协作场景中多个步骤之间需要共享上下文是刚需。比如一个代码审查任务Agent A 分析代码结构Agent B 检查安全漏洞。Agent B 需要知道 Agent A 发现的模块依赖关系才能判断漏洞的影响范围。在没有标准化机制之前这种信息传递要么靠消息队列要么靠共享数据库。消息队列的问题是消息丢失后无法恢复且消费顺序不保证。共享数据库的问题是需要定义 schema每个任务流的 schema 都不同。草案提出的工作记忆原语是一个在网络层维护的轻量共享状态空间。它不是数据库也不是缓存而是一个结构化的上下文容器。工作记忆的生命周期绑定到一个任务流而不是某个特定 Agent。任务流启动时创建工作记忆任务流结束时归档或销毁。任何参与该任务流的 Agent 都可以读取和追加工作记忆的内容。写入是追加式的不允许覆盖已有条目保证审计可追溯。每条记忆条目包含时间戳、写入者身份、标签和内容四个字段。内容是任意 JSON 对象标签用于后续检索时的过滤。读取支持按标签过滤Agent 只拉取与当前步骤相关的上下文片段。过滤是服务端执行的不需要把整个工作记忆下载到本地再筛选。这解决了一个实际痛点Agent A 处理完的结果Agent B 怎么拿到在没有工作记忆之前要么通过消息传递要么自己搭共享存储。消息传递的问题是丢失后无法恢复共享存储的问题是每个团队重复造轮子。工作记忆把这两种模式标准化了追加写、过滤读、任务级生命周期。工作记忆的实现不需要复杂的分布式一致性协议。因为写入是追加式的不存在并发写冲突。读取是过滤式的不需要全量同步。用一个简单的日志存储加标签索引就能满足大部分需求。这也是草案敢于在网络层提出这个原语的原因实现复杂度可控。四、知识交付网络复用推理产物降低重复计算KDN 是草案中最超前的部分也是争议最大的部分。核心想法是当多个 Agent 处理相似任务时前一个 Agent 的推理中间产物可以被后续 Agent 复用。这里的推理产物主要指 KV Cache——Transformer 模型在推理过程中产生的注意力状态。KV Cache 的作用是缓存已计算的 Key 和 Value 向量避免重复计算。在当前的 Agent 系统中每个 Agent 独立跑推理KV Cache 用完即弃。如果两个 Agent 处理的是同一文档的不同部分它们的 KV Cache 有大量重叠。重叠的部分主要是文档的共享上下文比如项目结构、依赖关系、配置信息。KDN 提议在网络层建立一个推理产物分发网络类似 CDN 但服务于推理过程。第一个 Agent 跑完推理后KV Cache 被上传到 KDN 节点。上传是异步的不阻塞 Agent 的正常返回。后续 Agent 在启动推理前先查询 KDN 是否有可复用的缓存。查询基于任务的上下文指纹比如文档哈希或项目标识符。如果有匹配的缓存直接加载到本地推理引擎跳过重复的前向计算。草案估算在典型的多 Agent 文档分析场景中KV Cache 复用可以减少 40% 到 60% 的推理计算量。但这个方案面临几个现实挑战。第一KV Cache 的格式与模型架构强绑定不同模型之间无法直接复用。GPT-4 的 KV Cache 和 Claude 的 KV Cache 格式完全不同。即使是同一模型的不同版本缓存格式也可能不兼容。第二KV Cache 的体积很大一个 70B 模型的单次推理缓存可达数十 GB。在网络上传输这么大的数据量延迟可能超过重新计算的时间。第三安全问题KV Cache 可能泄露推理过程中的敏感信息。缓存中包含了模型对输入的注意力分布可以反推出哪些输入片段被重点关注。草案承认这些挑战把 KDN 定位为长期研究方向而非短期可落地方案。但在特定场景下KDN 的收益是实实在在的。比如一个代码库有50个文件10个 Agent 各自审查5个文件。每个 Agent 都需要理解项目的整体结构和依赖关系。没有 KDN 时10个 Agent 各自跑一遍项目分析消耗10倍的推理资源。有 KDN 时第一个 Agent 跑完后把项目结构的 KV Cache 上传。后续9个 Agent 直接加载缓存只跑文件级别的增量推理。这种场景下推理成本可以降低一个数量级。五、三层协议栈的成型把 MCP、A2A 和 Agent-GW 放在一起看一个三层协议栈正在成型。最上层是 MCP负责 Agent 与工具之间的垂直连接。中间层是 A2A负责 Agent 与 Agent 之间的水平协作。最底层是 Agent-GW负责网络级的路由、状态和资源分发。每一层解决不同粒度的问题互不重叠。维度MCPA2AAgent-GW通信轴垂直Agent→工具水平Agent↔Agent网络网关→Agent核心抽象Tool / Resource / PromptAgent Card / Task / MessageRoute / Working Memory / KDN路由粒度工具调用级别Agent 能力级别任务意图级别状态管理无状态2026-07-28Task 生命周期工作记忆任务级传输格式JSON-RPC 2.0JSON-RPC 2.0 / gRPC待定草案阶段治理方Linux Foundation AAIFLinux Foundation LF AI DataIETF这个分层与互联网的经典协议栈高度相似。MCP 类似 HTTP定义应用层的请求和响应格式。A2A 类似 SMTP 或 SIP定义实体间的交互协议。Agent-GW 类似 IP 和 BGP定义网络层的寻址和转发。Google 之前用了一个精辟的比喻A2A 是两只手握手的姿势MCP 是每只手拿什么工具。现在可以补上第三句Agent-GW 是手与手之间的那条神经。2026 年 6 月Linux 基金会 Agentic AI Foundation 发布了 MCP 与 A2A 的融合草案。草案确认了两者的分工A2A 是 Agent 间的水平总线MCP 是 Agent 到工具的垂直总线。Agent-GW 草案在这个基础上进一步定义了总线之下的网络层。六、与现有标准的关系补充而非替代草案明确声明 Agent-GW 不替代 MCP 和 A2A。它补充的是 MCP 和 A2A 都没有覆盖的网络层能力。MCP 2026-07-28 重构后路由头 Mcp-Method 和 Mcp-Name 成为必填字段。这在应用层提供了基本的路由能力但粒度只到工具调用级别。Agent-GW 的语义路由在更粗的粒度工作按任务类型分发不是按单次调用分发。两者是互补的Agent-GW 决定请求发给哪个 AgentMCP 决定 Agent 内部调用哪个工具。工作记忆与 MCP 的 requestState 也是互补关系。requestState 处理的是单个 Server 内部的多轮交互状态续接。工作记忆处理的是跨多个 Agent 的共享结构化上下文协调。一个管纵向深度一个管横向广度两者解决不同维度的问题。类比来看requestState 像是单个进程的栈帧工作记忆像是共享内存段。A2A 的 Task 生命周期管理submitted、working、completed描述的是任务状态。工作记忆描述的是任务过程中产生的上下文数据。状态和数据是两个维度A2A 管状态流转Agent-GW 管数据共享。七、对开发者的实际影响短期来看Agent-GW 草案还是互联网草案阶段距离 RFC 还有很长的路。但草案提出的三个问题——路由效率、共享状态、推理复用——是真实存在的。当前的解决方案要么粗糙要么重复造轮子要么浪费资源。对于正在构建多 Agent 系统的团队有三个值得关注的工程实践。第一路由层与应用层分离。不要在业务代码里硬编码这个请求发给哪个 Agent。把路由决策抽到独立层用能力标签而非 IP 地址做分发。这样当 Agent 实例扩缩容时路由逻辑不需要改。可以用一个简单的标签匹配服务实现不需要复杂的语义理解。第二任务级共享上下文标准化。多 Agent 协作时用一个共享的结构化容器传递中间结果。容器的写入是追加式的读取是按标签过滤的。不要依赖消息传递的可靠性也不要依赖全局状态的强一致性。用 Redis 的 Stream 或 PostgreSQL 的 JSONB 就能实现基本功能。下面是一个基于 Redis Stream 的工作记忆最小实现import redis import json from datetime import datetime class WorkingMemory: def __init__(self, task_id: str, redis_client: redis.Redis): self.stream_key fwm:{task_id} self.r redis_client def append(self, agent_id: str, tags: list, content: dict): entry { agent: agent_id, tags: ,.join(tags), ts: datetime.utcnow().isoformat(), data: json.dumps(content, ensure_asciiFalse), } self.r.xadd(self.stream_key, entry) def read(self, tag_filter: str None, count: int 100): entries self.r.xrevrange(self.stream_key, countcount) results [] for _id, fields in entries: if tag_filter and tag_filter not in fields.get(tags, ): continue results.append({ agent: fields[agent], tags: fields[tags].split(,), ts: fields[ts], data: json.loads(fields[data]), }) return results # 用法示例 r redis.Redis() wm WorkingMemory(task-001, r) wm.append(agent-a, [structure, deps], {modules: [auth, db]}) wm.append(agent-b, [security, vuln], {cve: CVE-2026-1234}) deps wm.read(tag_filterdeps)这段代码展示了工作记忆的核心语义追加写、标签过滤、任务级生命周期。第三推理产物的缓存意识。如果你的多 Agent 系统处理的是相似文档或重复任务。考虑在 Agent 之间传递 KV Cache 或推理中间结果。即使不能直接复用至少可以避免重复加载相同的上下文。用 prompt caching 机制如果模型提供商支持可以在单次会话内实现缓存复用。八、中国厂商的标准化策略值得注意的是华为、阿里、腾讯在开放原子开源基金会下成立了专门的大模型与智能体工作组。他们采取的策略是先在国内协会内达成共识再由三家公司作为代表分别向 Linux 基金会或 ISO 组织提交中国提案。这种内外联动的标准化策略使中国在 AI 标准制定上的话语权在 2026 年提升了近三倍。国标 GB/Z 185《人工智能 智能体互联》的八项标准覆盖了身份码、身份管理、能力描述、发现、交互和工具调用。补的正是 MCP 和 A2A 最弱的身份治理环节。IETF Agent-GW 草案的语义路由部分与中国厂商强调的可信身份和能力描述有天然的对齐点。如果草案最终采纳了基于能力标签的路由机制中国的国标体系可以直接对接。中国电子技术标准化研究院牵头的七十余家企业参与了标准制定。美团、滴滴、智谱、用友、联想等公司已经接入了 AIP 协议的开源 V2.1 版本进行试点。九、风险与不确定性草案面临几个现实挑战。第一标准化周期。从互联网草案到 RFC 通常需要两到五年Agent 技术的迭代速度远快于标准化速度。等草案成为标准时Agent 架构可能已经发生了根本性变化。历史上有过先例HTTP/2 从草案到 RFC 花了将近三年。而 Agent 领域的变化速度比 Web 快得多三个月就是一个代际。第二产业共识。MCP 和 A2A 的成功在于有 Anthropic 和 Google 这样的头部公司推动。Agent-GW 草案的推动者相对分散缺乏一个明确的主导方。没有主导方意味着缺乏一个可以快速迭代参考实现的工程团队。MCP 的成功很大程度上归功于 Anthropic 的 TypeScript 和 Python SDK。A2A 的成功归功于 Google 的 ADK 和 AgentSpace 集成。Agent-GW 需要类似的工程投入才能从草案走向可用。第三技术可行性。KDN 的 KV Cache 复用面临格式兼容、传输带宽和安全泄露三重挑战。在模型架构快速演进的背景下缓存复用的工程复杂度可能超过收益。仅格式兼容一项就需要所有主流推理引擎达成共识。vLLM、TensorRT-LLM、SGLang 的缓存格式各不相同。第四与现有基础设施的集成。Kubernetes 的 Gateway API 已经定义了路由和服务发现的标准。Envoy 和 Higress 等网关已经支持 MCP 协议的解析和路由。Agent-GW 的语义路由需要与这些现有标准协调而不是另起炉灶。否则会出现两套路由体系并存的混乱局面。十、给工程团队的落点清单第一关注但不要等待。草案的方向是对的但落地时间不确定。先把路由层和应用层分离为未来的标准化路由做好架构准备。第二任务级共享上下文现在就可以做。不需要等标准出来用追加式日志加标签过滤就能实现基本功能。关键是把写入和读取的接口标准化底层实现可以随时替换。第三推理缓存是长期优化方向。当前优先级不高但如果你的系统有大量重复推理值得提前研究。先从 prompt caching 开始逐步探索跨 Agent 的缓存复用。第四跟踪 IETF 的 Agent 相关工作组。除了 draft-agent-gw-02还有 draft-agent-framework 和 draft-agent-security 等相关草案正在推进。这些草案共同构成了 Agent 网络基础设施的标准化蓝图。订阅 IETF 的 agent-wg 邮件列表可以获取最新进展。第五评估现有网关的扩展能力。如果你已经在用 Envoy、Higress 或 Lunar.dev MCPX 等网关。关注它们对语义路由的支持计划提前做好架构预留。这些网关很可能在草案成为 RFC 之前就提供实验性支持。结语MCP 和 A2A 解决了 Agent 怎么连接和怎么协作的问题。IETF Agent-GW 草案试图回答下一个问题当 Agent 数量达到百万级时网络层该怎么支撑。语义路由让请求按意图而非地址分发。工作记忆让多个 Agent 共享任务上下文而不需要集中式存储。KDN 让推理产物在网络层被复用而不是每个 Agent 从零开始。这三个原语单独看都不复杂但组合在一起构成了 Agent 基础设施的下一个抽象层。从2024年MCP诞生到2026年A2A稳定运行再到IETF开始定义网络层。Agent 基础设施的标准化只用了两年就走完了 Web 时代十年的路。正如 TCP/IP 之于 Web、Kubernetes 之于云原生Agent 时代也需要自己的网络层标准。IETF 的介入标志着这个讨论从要不要标准化进入了怎么标准化的阶段。对于开发者而言现在是理解这些草案方向、调整架构预期的最佳时机。不需要等标准出来才行动先把路由和状态管理从应用代码中剥离出来。当标准化的那一天到来时你的架构已经准备好了。这正是草案最大的价值不是告诉你怎么实现而是告诉你方向在哪。附录关键术语速查术语含义类比语义路由按请求意图和 Agent 能力标签分发流量类似 DNS 按域名解析 IP但粒度到任务类型工作记忆任务级的共享结构化上下文空间类似 POSIX 共享内存但生命周期绑定任务流KDN知识交付网络分发和复用推理产物类似 CDN 缓存静态资源但缓存的是 KV CacheKV CacheTransformer 推理过程中的注意力状态缓存类似 CPU 的 L2 缓存避免重复计算draft-agent-gw-02IETF 多 Agent 网关互联网草案第二版类似早期的 HTTP 草案定义网络层规范Agent CardA2A 协议中 Agent 的能力声明类似 DNS SRV 记录声明服务能力和端点