摘要

  • Agentproto 公开会议纪要把八组举手结果称为不具约束力的现场意见，并明确说还要在邮件列表确认共识；它没有记录工作组已经成立，也没有记录章程已经获批。
  • “初始范围是否正确”得到 38 票赞成、124 票反对、40 票无意见；初始交付物为 92–58–49；“是否按这份章程成立工作组”却得到 154–51–5。
  • 这些问题的谓词不同，回答总数也不同。公开表格没有逐人交叉数据，不能断言反对范围的 124 人就是支持成立工作组的 154 人中的某一固定群体。
  • 会议所用章程可以固定到不可变提交 a9405f3d5d0a4e8c67342d7945137c8230b9cd05。会后邮件与尚未合并的缩减范围 pull request 表明，会议讨论的核心边界并未结束。
  • 研究截止时，Datatracker 仍把 Agentproto 标为 BOF，章程为 (None)。现场意见、列表确认、领域主管判断、IAB 意见与 IESG 批准是不同制度行为。
  • 一张“谓词协调矩阵”可以在不公布实名选票的前提下，保存问题原文、章程版本、回答分母、异议、修改、列表处置与最终授权状态。

先看那两行，而不是先讲结论

IETF 126 Agentproto BoF 纪要中，第四问与第六问相隔不远。第四问问初始范围是否正确，答案为 38、124、40。第六问问是否“按这份章程”成立工作组，答案为 154、51、5。若把 yes、no、no opinion 的列名拿掉，这只是两串数字；若把问题拿掉，它们就可以被任何一方重新包装。

纪要本身比这种包装谨慎。文件标着“供主席审阅的草案”，说明它由人类记录员的笔记、Zulip 对话与现场幻灯片汇编而成，汇编过程使用了 AI agent harness；发言人姓名和机构仍待核对，出席人数尚无最终数据，最终修订责任在主席。这个披露不会让纪要失去价值，反而告诉读者应当把它当成什么：一份重要、具体、但尚未定稿的制度记录。

纪要还给所有举手结果加了同一个边界：这是通过 Meetecho 收集的现场意见，不具约束力，共识需要在邮件列表确认。任何文章若删掉这句话，哪怕数字一个不错，也会把证据等级写高一层。

第 01 版议程显示，会议先讨论动机、与其他工作的关系、会话、跨模态通信和框架，再开放麦克风，最后才进入共识询问。IETF 126 会前 BoF 介绍也把工作组形成型 BoF 描述为同时检验共识、投入意愿与范围是否足够收敛。由此产生多维而不是单一答案，本来就是这种会议的功能。

八个问题并不共享一个含义

第一问检验问题是否被理解、可解决且值得解决，结果是 124–72–14。第二问检验互操作需求是否清楚，为 155–30–8。第三问检验 IETF 是否是合适场所，为 158–30–14。第四问转向初始范围，为 38–124–40。第五问问初始交付物是否正确，为 92–58–49。第六问问是否按这份章程成立工作组，为 154–51–5。第七问问是否愿意撰写或审阅草案，为 137–17–40。第八问问是否愿意实现协议，为 42–28–40。

纪要的归纳没有抹平差异：现场强烈支持问题值得解决、互操作需求明确、IETF 是合适场所，也支持成立工作组；但“按现有文字写出的初始范围”没有获得支持，交付物意见分裂。收尾时 Laurent Ciavaglia 特别指出，“是否正确”不应与“是否完整”混为一谈，范围与章程讨论要转入邮件列表。

每问回答总数依次为 210、193、202、202、199、210、194 与 110。它们显然不是一个固定投票团体完成的八轮法定表决。有人可能跳过某问，有人可能离场，也可能有人只愿意表达实现意愿。现有材料没有给出原因。

更关键的是，表格只有每一问的边际总数，没有逐人联合分布。我们不知道第四问投 no 的 124 人中，有多少人在第六问投 yes；也不知道每个人如何理解“正确”“完整”或“按这份章程”。因此，“同一批 124 人先否定范围又支持成立”不是事实；“两组人完全不同”同样不是事实。

IETF 无须因此公布实名答卷。主席可以发布不识别个人的异议分类，例如：范围过宽、范围缺项、术语含混、会话生命周期不应纳入、交付物状态不当；也可以说明第六问的支持是否以某些修改为条件。这样保留判断内容，不把工程协商改造成阵营统计。

两个结果可以共存，但条件必须公开

希望有一个工作组，同时反对当前范围，在逻辑上完全成立。参与者可能相信 Agentproto 的互操作问题值得长期场所，却认为会话生命周期应放在范围外；也可能认为需要框架，但不赞成拟议交付物；还可能把“正确”理解成“完整无缺”，因而对一个可修复的草案投 no。

困难来自第六问的完整措辞。它不是“这个话题是否值得讨论”，而是“是否按这份章程成立 WG”。

RFC 5434建议把问题拆开，以便找出同意点和分歧点；这为上述共存提供了正当解释。但它给出的综合问题范例也是“是否支持按以下章程成立 WG”，并把这理解为对具体章程是否已准备好的检验。因此，分项问题否定了范围，而综合问题获得支持之后，制度记录必须补上中间的解释。

若 154 个 yes 的真实含义是“修改范围后成立”，就应列出哪些修改构成条件。若第四问主要受“正确”与“完整”的歧义影响，就应记录哪些缺项。若最终章程显著改变，就不能说会议已经对后来文字投过 154 票；后来文字的权威应来自邮件列表、领域主管与 IESG 的后来行为。

这种做法同时保护两边：154 不会成为空白授权，124 也不会变成对整个 Agentproto 议题的永久否决。

“这份章程”必须指向不可变对象

纪要链接了一份章程，并说现场持续展示当前文本。官方 ART area 仓库留下了清楚的时间锚：提交 a9405f3… 中的 Agentproto 章程。该文件在 7 月 21 日创建，距离 BoF 两天；截至研究时，文件历史仍只返回这一提交。

冻结文本的范围并不空泛。它包括 agent-to-agent 与 agent-to-tool 通信，也把特定的人机通信协议机制纳入；关键考虑涉及独立身份、授权、机密性、完整性和可审计性；交付物包括 standards-track 会话协议与 informational 框架。会话协议预期处理长短会话、上下文、故障恢复、多种时效的数据并发交换以及点对多点拓扑。

不可变提交不能证明每个人逐字读过，也不能证明所有人对术语理解一致。它解决的是另一件事：后来再说“这份章程”时，指针不会随 main 分支移动。新版本可以更好，但它是新对象，应当有自己的审查轨迹。

会后记录证实范围仍在移动

8 月 12 日，Suresh Krishnan 在邮件列表发表“Sussing out points of disagreement on the charter”，说会议内外的意见已经促成两个从头改写的方案，并列出六个待决点：产出是底层 substrate 还是一组语义、是否纳入会话生命周期、只做关联还是还要证明绑定、支持点对多点还是仅双边、交付物数量/状态/顺序，以及章程需要定义多少术语。

这些不是遣词修订，而是在决定工作组将生产什么。

官方仓库的 pull request 77在 BoF 后以会议版提交为 base，提出“minimum viable primitive”范围缩减：把会话生命周期移出范围，把会话协议交付物改为 interaction reference 与 binding envelope。研究截止时它仍开放且未合并。说明文字还披露其思路使用 AI 辅助分析聊天记录；这使来源更透明，却不会把贡献者方案变成主席决定或 IETF 结论。

8 月 26 日一封关于证据要求的章程文字提议展示了更细的依赖关系。Nancy Sahu 建议说明运行证据能证明什么、不能证明什么；如果交付物中的证据条款被删除，关键考虑中的 auditability 也应同时处理。这个建议是否正确不是本文结论。它说明高层属性不能与负责实现它的交付物失去连接。

9 月 1 日发布的 IETF 126 回顾说 Agentproto 的 BoF 旨在检验成立工作组的共识，并说讨论仍在邮件列表继续。当前 Datatracker 页面则给出最简洁的权威状态：BOF、Charter (None)、尚未成立。空值不是负面评价，而是截至该时刻准确的制度事实。

现场提供证据，授权还要继续走

RFC 2418 / BCP 25规定了工作组形成的正式链条：拟议章程与相关 Area Director 协商，由 IAB 提供意见，最终由 IESG 批准；IESG 可以原样批准、要求修改或拒绝。批准后，秘书处才记录并公告工作组。

同一文件明确说 51% 不构成 rough consensus，也讨论了如何在邮件列表核验线下会议结论。这套设计不是反对数字，而是限制数字的职能。数字显示参与强度与分歧；主席判断反对理由的实质；列表让未到现场的人参与；Area Director 与 IESG 承担制度责任。

Heng Lu 在《The Multi-Stakeholder Mirage》中对“出席变成授权”的批评，在这里应当窄用。参与可以是证据、专业知识、警告与反对意见，却不会自动取代指定机关的决定。把 Agentproto 现场放回这个位置，并不是削弱它，而是让它的全部信号——包括反对初始范围——都不被一句“社区已经批准”覆盖。

谓词协调矩阵应记录什么

矩阵第一组字段记录稳定问题编号、完整原文以及它要服务的制度决定。第二组字段绑定现场展示的章程 commit 与 blob、收集时间和方法、yes/no/no opinion、回答总数及“不具约束力”的明确标签。

第三组记录解释：哪些词发生歧义，主要异议分成哪些不识别个人的类型，“正确”与“完整”如何区分，哪些条款需要修改，支持是否附带条件。没有安全的交叉数据时，就把该字段保留为未知，而不是猜测。

第四组记录授权传递：列表确认的开始与截止日期、相关讨论链接、主席的综合判断与异议处置、Area Director 动作、IAB 意见、IESG 决定以及获批最终章程的不可变提交。在决定发生前，字段必须明确为 null。更正要追加日期和原因，不能覆盖旧记录。

Agentproto 当前的矩阵不会显示一个简单红绿灯。它会显示：问题价值、互操作需求与 IETF 场所有强支持；初始范围没有支持；交付物分裂；撰写意愿较强；范围修订与列表确认尚在进行；最终章程和 IESG 批准为空。这正是 BoF 应当带回制度层的结果。

反对意见与证据边界

第一项反对是矩阵会把 rough consensus 变成多数表决。应对方式不是隐藏计数，而是让主席理由、未决异议与授权状态和数字同等醒目，绝不能用百分比作为最终状态。

第二项反对是版本锚会冻结讨论。事实相反：保留旧对象，才能让新文字自由变化而不冒充旧支持。第三项反对是隐私；这要求不公布个人回答组合，只保留汇总与理由。第四项是工作量；矩阵应从已有的纪要、提交、邮件与 Datatracker 事件生成，而不是另建一套庞大手续。

本文不判断 IETF 是否应成立 Agentproto，不选择 session protocol、interaction reference、framework 或其他技术方案，也不评价 MCP、A2A 等实现。它不证明计数错误、程序无效、任何人操纵会议或主席存在恶意。它不知道每个人怎样回答。纪要尚待审阅，邮件和 pull request 都只是有署名的提议，Datatracker 状态以后可能改变。

可以证实的结论更小：一个带有“按这份章程”的综合问题获得支持，而章程里的初始范围问题没有获得支持；随后范围继续被实质讨论。只要问题、文本与后来授权保持连接，这个过程就能诚实演进。若只留下最大的数字，它就会制造一份从未发生过的授权。

来源

  1. Heng Lu — The Multi-Stakeholder Mirage
  2. IETF 126 — Agentproto BoF 纪要
  3. IETF 126 — Agentproto 第 01 版议程
  4. IETF — IETF 126 Highlights
  5. IETF — Birds of a Feather at IETF 126
  6. 提交 a9405f3… 中的 Agentproto 拟议章程
  7. IETF Datatracker — Agentproto 当前页面
  8. RFC 5434 — Considerations for Having a Successful BOF Session
  9. RFC 2418 / BCP 25 — IETF Working Group Guidelines and Procedures
  10. Agentproto 邮件列表 — Sussing out points of disagreement on the charter
  11. Agentproto 邮件列表 — Proposed charter text: evidence requirements
  12. IETF ART area 章程仓库 — Pull request 77