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，负责网络级的路由、状态和资源分发。

每一层解决不同粒度的问题，互不重叠。

这个分层与互联网的经典协议栈高度相似。

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 决定请求发给哪个 Agent，MCP 决定 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 = f"wm:{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_ascii=False), } self.r.xadd(self.stream_key, entry) def read(self, tag_filter: str = None, count: int = 100): entries = self.r.xrevrange(self.stream_key, count=count) 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_filter="deps")

这段代码展示了工作记忆的核心语义：追加写、标签过滤、任务级生命周期。

第三，推理产物的缓存意识。

如果你的多 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 的介入，标志着这个讨论从"要不要标准化"进入了"怎么标准化"的阶段。

对于开发者而言，现在是理解这些草案方向、调整架构预期的最佳时机。

不需要等标准出来才行动，先把路由和状态管理从应用代码中剥离出来。

当标准化的那一天到来时，你的架构已经准备好了。

这正是草案最大的价值：不是告诉你怎么实现，而是告诉你方向在哪。

附录：关键术语速查