多智能体去中心化听着优雅，执行起来常撞上同一个尴尬：活可以派出去，责任派不出去。一层的智能体把子任务委托给下一层，再下一层再委托——链条一长，中间某个依赖出了故障，该谁恢复、该谁认账，就成了糊涂账。10 月 15 日提交 arXiv 的 RCM（编号 2610.21243，14 页含附录）就是冲这个问题来的：用「承诺」把委托和责任焊在一起。
论文五位作者 Thi-Nhung Nguyen、Viet-Thanh Pham、Linhao Luo、Thuy-Trang Vu 与 Dinh Phung，跨多智能体系统与人工智能两个分区，未经同行评审。它的诊断很直白：中心编排有吞吐与适应性瓶颈；去中心编排把这些瓶颈摊掉了，却让「被委托依赖与故障恢复的责任」悬空。RCM 的答案是承诺——每次任务委托都附带一份写清各方责任的承诺，递归下派时上游责任不撒手，于是问责链在整条委托链上保留，形成一张「局部编排的网络」。
机制落在两个部件上
一个是责任约束的决策：智能体建立、管理、终止承诺都有自己的规矩，不能随口答应也溜不脱。一个是面向责任的通信协议 RCP：智能体用它在运行中自主协商这些承诺。随着智能体并行行动，各自的局部动作持续演进一张承诺图，全局协调从中涌现——没有中央控制器，但责任始终有位置可查。论文报告，在推理、编码与可执行智能体环境上，RCM 相较强的中心式与去中心式基线，任务性能至多领先 18.7 个百分点，责任指标领先 10.2 个百分点，失败与伤害检测也更好，且不需要针对任务专门训练。
放进台谱里看
这条协调路线上，站点近两周刚攒下两个坐标：1970 的 ScaleMAS 把协调搬进共享消息库，治的是「智能体一多就读不动」；1939 的 GitSwarm 让中间成果以原子提交落进 Git 仓库，治的是复合推理的复利。RCM 治的是第三种病——问责。三篇摆在一起，能看到多智能体协调机制正在分工专业化：介质治规模、资产治复利、承诺治责任，而不是某篇论文包打天下。
它还与 1968 的问责周构成一组跨层对位。那篇记的是人类侧的问责：METR 驻场、听证会、FTC 民事要求；RCM 问的是机器之间的事——智能体互相委托出了事，账怎么算。两者合起来才是完整的问责图景：组织层的制度与协议层的机制，缺了哪层都转不动。
把镜头再推远一点，问责正在从「论文里的指标」变成「生意里的条款」。1930 记过蚂蚁国际万里汇经 A2A 接入生态伙伴智能体，广告、物流、税务服务商开始替商家跑腿；1959 的 Accio 把询盘与核价托付给智能体；1976 那一周的按层收费里，审批层产品已经开始替人类拦工具调用。这些场景有个共同结构：任务在人与智能体、智能体与智能体之间层层转手，而每一跳的责任归属几乎都靠私下约定。RCM 的价值在于把「私下约定」上升为协议原语——承诺图既是协调结构，也是出事之后的追责地图。对任何要做智能体转手交易的平台，这张地图迟早要从可选项变成必选项。
几盆该浇的冷水
「至多 18.7 个百分点」是上限读数，均值、方差与失败模式的分布要等全文；摘要层面没点名具体基准，也没披露承诺图规模上去之后的协商开销——承诺谈得越密，通信成本越高，这个曲线在多大规模上抬头，是它能否实用的关键。承诺由智能体自主建立、管理与终止，遇到恶意或故障成员故意许下无法兑现的承诺时怎么处理，论文摘要没有涉及。五名作者、预印本，复现要等代码。
给正在设计多智能体委托的团队一个低技术含量的自查：把你们系统里「A 派给 B、B 派给 C」的链路画出来，在每一跳旁边写下「这一跳失败了，谁会发现、谁去恢复、谁向最终用户解释」。三个问号都填不出来的跳数，就是你们欠下的问责债——RCM 的思路可以原样搬进你们的工作流设计，哪怕暂时不碰论文本身。