摘要

  • IESG 于 2026 年 10 月 8 日批准 Agentproto 章程。工作组计划在十二月采纳用例草案，之后再推进架构和协议文档。
  • 10 月 15 日更新的用例提案仍属于个人提交。作者更新了文件，不等于工作组已决定以它为共同起点。

让几个 AI 服务分工做事，听起来可以从分配任务开始。但很快会遇到一个更朴素的问题：这条新消息，跟刚才那件事是什么关系？

一次对话可能经过多个服务，从语音切到文字，也可能在连接中断后继续。参与的系统需要知道哪些交互属于同一段对话，哪些还在进行，哪些已经结束。光有各自能回答问题的模型，并不会自动让这些信息对得上。

IETF 的 Agentproto 工作组准备为此制定通用的对话管理协议，并给出参考架构。已获批准的章程把“上下文”限定得很具体：这里说的是识别和维持对话所需的标识符及生命周期状态，不是把提示词、检索资料和模型的对话记忆一起打包传走。

这一限定缩小了工作范围，也让目标更清楚。Agentproto 不打算另造一种传输协议，也不替换应用层已有的智能体通信协议；相关上下文应由现有 IETF 协议承载。模型怎么实现、怎样推理和规划、用户界面长什么样、审计数据按什么结构保存，都不在它的职责之内。

把对话接上，并不等于替对话里的 AI 作决定。

网上有稿，为什么还要等十二月

工作组页面列出的第一项目标，是在 2026 年十二月采纳一份信息性用例草案。可相关文档列表里已经有了《Agentic AI Use Cases and Requirements》，版本号为 -04，更新日期是 10 月 15 日。只看文件名和日期，很容易把它读成一项已完成的成果。

关键在于谁作出了什么决定。这份文档自己的状态页仍将其标为活跃的个人 Internet-Draft，没有分配 RFC 流程类别。页面也明确说明，个人可以提交 Internet-Draft，提交本身不代表 IETF 背书。作者拿出一份建议，工作组选择以哪份建议展开共同工作，是两步。

还有一个容易造成误读的小细节。状态页的“预期 RFC 状态”没有填写，但草案正文首页明确写着拟作为信息性文档。不能因为页面空着，就说作者没有表明方向；同样，也不能因为作者写了方向，就说工作组已经采纳。

这份个人提案已经提供了一些可讨论的场景：多个智能体协作、执行时间较长的委托任务，以及通过中间环节访问工具和数据。它们帮助说明通信可能遇到什么问题，却不是已经获工作组接受的需求，更不是产品部署的证明。

例如，任务做得久，授权是否依然有效就会成为问题。章程提到，智能体可能需要独立于委托用户接受身份验证，其权限也可能需要单独撤销。但对话管理协议并不因此包办全部安全决策。协议要让相关交互维持连贯，应用如何运用这些信息仍有自己的责任。

批准了工作范围，还没有批准答案

章程历史记载了 IESG 在 10 月 8 日的批准。获批的是工作组的任务和范围，不是某份用例草案，更不是一套已完成的协议。

后续日程也说明两者相隔多远。计划先在 2027 年二月采纳信息性架构草案，再在三月采纳一份或多份拟走标准路线的协议草案；到 2028 年三月，才是将协议草案作为拟议标准提交 IESG 的目标时间。历史记录中，后面几个协议阶段的表述也改成了可以容纳多份草案的形式。

这些是目标日期，不是通关记录。十月有人修订文档，证明写作和讨论在推进；十二月的任务却需要工作组作出选择。只有决定与所涉文档、版本对应起来，才能知道第一步究竟走到了哪里。若目标日期调整，也应把调整与采纳分别看待。

接下来值得留意的，不只是列表又添了几份文件，而是哪一份成为工作组正式选择的起点。Agentproto 想让不同系统辨认同一段对话；判断它的进展，同样得先辨认眼前的是一个提案，还是一次决定。

**说明补充，2026 年 10 月 24 日：**本文区分了 Datatracker 未填写的状态字段与草案作者明确写出的信息性文档意向。上述日期均为工作目标；所核对的十月修订版仍是个人提交，并非已获工作组采纳的成果。