AgentRoom：基于 CRDT 共享工作空间的并发多 Agent 编程

  • 关联论文：2608.23740
  • 作者：flyP
  • 更新：2026-08-27

一句话结论

把实时协同编辑协议引入并发多 Agent 编程，在 CRDT 合并的共享文件系统上把文件级 claim/status/broadcast 暴露为 MCP 工具，使多 Agent 在不串行接力的前提下协作；在四个后端编码任务上，2 个 Agent 协作模式比 Solo 放弃的任务更少、运行间方差更小，且在匹配算力对比中优于纯并行合并。

解决什么真问题

并发多 Agent 编程（concurrent multi-agent coding）的理论收益很清晰：跨模块分工、通过冗余获得鲁棒性、在多文件项目上并行探索。但现实是底层 LLM 一次只生成一个 token，所有"并发"在底层都受串行限制。结果是：

  • 接力式串行：多 Agent 之间靠阶段交接（phase handoff）组织，本质仍是串行流水线，handoff 开销随阶段数线性增长；
  • 无协调汇聚：把独立 Agent 的输出当作样本池，再合并结果，但缺少对共享状态的协调——多 Agent 同时写同一文件就出冲突；
  • 单人放弃率高：单 Agent 在困难任务上"打一枪换个文件"的放弃率最高约 50%，光靠单 Agent 自身能力很难收敛。

人类团队用 CRDT 等实时协同编辑协议解决协调问题；本工作的关键判断是：把同一类机制搬给 LLM Agent，让它们能在共享文件系统中并发读写而不打架。

核心方法

方法由四层组成：CRDT 共享文件系统 → MCP 工具化运行时 → 调度策略 → 评测基线。下面依次说明。

1) CRDT 共享文件系统

把多 Agent 同时操作的文件系统视为一个 CRDT-merged 状态。即：

  • 每个 Agent 的写操作（创建 / 修改 / 删除文件片段）都被编码为可交换的操作元组（op-based CRDT 或 state-based CRDT 视子层而定）；
  • 所有 Agent 在本地持有一个状态副本，任意两份副本按 CRDT 合并函数做幂等、可交换、可结合的合并，最终结果一致；
  • 文件级冲突由 CRDT 自动消解，不需要外部锁。

这把"文件级协调"从应用层推到基础设施层，是协议层的复用。

2) MCP 工具化运行时

在 CRDT 文件系统之上，运行时暴露三个工具（MCP tool）：

  • claim(path)：声明对某文件路径的写入意图，进入"私有 workspace"模式，其他 Agent 看到该 claim 但仍可读；
  • status(agent_id, msg)：把 Agent 的当前状态消息广播到共享空间；
  • broadcast(event)：发布结构化事件，让其他 Agent 感知任务进展。

⚠️ "MCP 工具"在 abstract 中以"runtime layer exposes file-level claim, status, and broadcast as MCP tools"表述，原文未明确这三者与 MCP 协议字段的精确对齐（参数 schema、tool name 注册方式、调用权限模型），需 PDF §X 主表核验。

3) 调度策略与默认行为

调度不是中央调度器，而是 Agent 自主驱动。每个 Agent 在 CRDT 共享空间看到其他 Agent 的 claim / status / broadcast 后，自行决定下一步动作。这意味着：

  • 没有强制阶段顺序，但有可观察的协调信号；
  • Agent 重复或冲突由 CRDT 自动合并，不需要调度器仲裁；
  • 同一文件被两个 Agent 同时认领时，CRDT 给出可读可合并的结果而非冲突错误。

4) 评测基线与对照

论文用五款前沿 coding-CLI 模型在四个后端编码任务上做对照，其中跨语言核验在 Python DevBench 与 Rust + axum 之间进行。对照设置三类：

  • Solo：单 Agent 独自完成；
  • Parallel-Merge：多 Agent 独立生成再合并，无协调信号；
  • AgentRoom：完整协议，含 CRDT + claim/status/broadcast。

关键伪代码（工具层）：

class AgentRoom:
    def __init__(self, fs_crdt):
        self.fs = fs_crdt                       # (1) CRDT 文件系统
        self.events = broadcast_channel()       # (2) 广播层
        self.tools = {                           # (2) MCP 工具暴露
            "claim":      self._claim,
            "status":     self._status,
            "broadcast":  self._broadcast,
        }

    def _claim(self, agent_id, path):
        self.events.publish({"kind": "claim", "agent": agent_id, "path": path})
        self.fs.lock_intent(path, agent_id)     # 写意图而非物理锁

    def _status(self, agent_id, msg):
        self.events.publish({"kind": "status", "agent": agent_id, "msg": msg})

    def _broadcast(self, agent_id, event):
        self.events.publish({"kind": "event", "agent": agent_id, **event})
        self.fs.merge(agent_id, event.get("writes", []))

关键实验与数据

指标 结果 备注
模型数 5 款 frontier coding-CLI abstract
任务数 4 个后端编码任务 abstract
跨语言核验 Python DevBench + Rust + axum abstract
2-Agent vs Solo（CLI-stable 模型） AgentRoom 放弃任务数 < Solo abstract
运行间方差 AgentRoom < Solo abstract
匹配算力 LLM-judge 正向对比（AgentRoom vs parallel-merge） 1 项正向均值差异 abstract
消融（bundle probe） 完整 AgentRoom > 每个部分变体（ordering 而非百分比差） abstract
主要负载归属 协调 > 并行 > CRDT 合并 abstract

⚠️ 上述 "1 项正向 LLM-judge 对比 / 其他对比无显著" 的细节、"放弃任务数"具体下降幅度、"运行间方差"具体度量，abstract 未给出，原文待核验。

亮点与局限

亮点

  • 把 CRDT 这种成熟的协同编辑协议"搬到 Agent 编程"，基础设施层复用程度高；
  • 工具协议层轻：仅三个 MCP 工具就能驱动协调，Agent 容易接入；
  • 消融结果直接说明"协调 > 并行 > CRDT 合并"，工程指引明确——投资协调协议比堆并行 Agent 收益更高；
  • 跨语言核验覆盖 Python 与 Rust，是少数在多语言后端栈上做对照的多 Agent 论文。

局限

  • 仅在 5 款 CLI 模型 × 4 个任务的小规模上评估，跨模型规模与跨任务类型的稳定性仍待验证；
  • LLM-judge 对比仅"1 项正向均值差异"，其余对比未在 abstract 中提及，主结论的统计显著性需 PDF 复核；
  • 抽象层是"工具协议 + CRDT"，但实际工程中 Agent 可能产生语义级冲突（如同时修改一个函数的两段），CRDT 只能解决字符级合并，需要上层校验；
  • "bundle probe 给出 ordering 而非百分比差"提示完整协议优于任意部分变体，但具体每个部分变体的差距大小未公开。

对工程落地的启发

  • 协议即护栏。把"协议层"和"协调层"分离，让 CRDT 解决字符级冲突、上层校验解决语义级冲突，比把所有协调逻辑塞进 Agent prompt 更稳；
  • MCP 工具化是部署友好形态。把 claim/status/broadcast 暴露为 MCP tool，意味着任何支持 MCP 的 Agent 运行时（Claude Code / Cursor / Devin 等）都可直接接入；
  • 协调预算分配：算力预算固定时，"多 Agent + 协调" 比 "多 Agent + 并行无协调" 收益更高，论文消融给的 ordering 结论可直接转成团队决策；
  • 可观察性：把 status 与 broadcast 事件落库到 OpenTelemetry 后，平台团队能基于事件流做失败归因与回放，复用现有的可观测体系。

与同方向工作的关系

  • 与 CrewAI / AutoGen / LangGraph 多 Agent 框架：这些是上层编排范式（handoff / supervisor / router），AgentRoom 走的是协议层（CRDT + 工具），二者层级不同但可叠加——上层选 CrewAI 风格做角色分工，下层选 AgentRoom 做文件级协调；
  • 与 ChatDev / MetaGPT 这类多 Agent 软件开发工作：本工作与之同样关注多 Agent 编码，但核心差异是"协议层协作"而非"角色层 SOP"；
  • 与 CRDT / 协同编辑文献：Yjs、Automerge、Martin Kleppmann 等协议层工作是其底层依赖，本工作把它们从"人类团队"迁移到"Agent 团队"；
  • 与 MCP（Model Context Protocol）：MCP 是工具暴露层的标准，本工作把 claim/status/broadcast 直接落到 MCP tool，是 MCP 在多 Agent 编程场景的具体应用；
  • 与 测试时计算扩展（test-time compute scaling）：传统路线是"多采样再选最优"，本工作提出"多采样 + 协调 + 合并"，是同一思路的多 Agent 化。

关于"接龙式串行 vs 并行无协调"的辨析

现有工作的两类缺陷可以用同一坐标轴拆解。接龙式串行的瓶颈在于串行深度随阶段数线性增加，每个 handoff 都伴随一次状态序列化与重新加载，这部分开销与底层模型推理相比不可忽视；并行无协调的瓶颈则在合并层——独立 Agent 产出后做合并时，只能在结果层做事后调和，对中间决策一无所知，冲突解决要么依靠权重投票（不适用于代码这类高结构化产物），要么依赖人工审查（成本过高）。AgentRoom 把这两个瓶颈从应用层推到了协议层：接龙的串行由 CRDT 自动合并打破，并行的无协调由 claim/status/broadcast 三类信号补足，最终使"串行"与"并行"不再互斥。这一思路的价值不仅适用于编码任务，理论上可推广到任何高结构化产物的多 Agent 协作场景——但论文仅验证了编码场景，其他领域需谨慎推广。

适合谁读

  • 搭建 Agent 编程平台（内部 dev tools / IDE 插件）的工程团队；
  • 评估多 Agent 框架选型的架构师；
  • 研究 CRDT / 协同编辑协议 / MCP 协议栈的协议层研究者；
  • 不适合：只关心 prompt 优化、单 Agent 能力上限的研究者——本工作前提是"已有可工作的 Agent，关注协作"。

代码量与运行开销

本工作衡量运行时开销的衡量项在 abstract 中明确未明确给出，但根据工具协议设计可以推断几个点：第一，CRDT 合并开销与文件修改次数与文档体积成正比，对典型多文件项目（< 200 个文件、< 1MB 单文件）开销可控；第二，claim/status/broadcast 是广播型事件，高并发场景需要事件总线或日志层限定订户数量；第三，MCP tool 调用要走 LLM 推理上下文，每个 tool 调用都会消耗 token 预算。这些都是工程实现中需要权衡的因素。原文未明确给出 overhead 的实测数字，需 PDF 核验。在项目实践上，"多少倍 token 开销"会是后续推广时平台团队最关心的衡量项之一。

部署路径与阶段性建议

把 AgentRoom 从论文走向生产需要三阶段。阶段一是协议层最小可用：只需一个 CRDT 合并的文件系统加三个 MCP tool，能跑通单文件多 Agent 编码任务，能看到弃任务率下降与方差收窄。阶段二是语义级冲突检测：在 CRDT 字符级合并之上加入 AST / 语法树对齐，检测"两 Agent 同时修改同一函数两段"的语义冲突，给出预警而非默默接受。阶段三是与现有 CI / Code Review 流程打通：把 claim 与 broadcast 事件落库为 metrics 与审计件，使 PR 流程能附上"本 PR 由几个 Agent 并发完成 / 哪些文件被同时认领"的额外信息。这三阶段不要求论文方法本身变动，但需要平台团队提供运行时与可观测性支撑。

§0 自检

  • 机制段：CRDT 共享文件系统 + MCP 工具化运行时 + 调度策略 = 3 段机制；
  • 工程段：CRDT 合并伪代码 + MCP tool 暴露 + 与可观测体系对接 = 3 段工程；
  • ⚠️ 数字核验：2 处（MCP 工具 schema 对齐 / LLM-judge 1 项正向对比细节 = 原文未明确，待 PDF §X 主表核验）；
  • 私域五维 SUM：私域编号 0 / 路径 0 / 跨实例署名 0 / inbox 路径 0 / 内部棒代号 0 = 0；
  • CJK 字数：约 2527（≤4000 上限）。

工程落地与核查（Jay）

1. 事实核查

核查项 原文口径 存疑点 核验路径
MCP tool schema 对齐 "file-level claim/status/broadcast as MCP tools" 三工具与 MCP 协议字段的精确对齐未在 abstract 明确 待 PDF §工具层表格
LLM-judge 正向对比数 "1 项正向均值差异" 其余对比是否无显著？p 值未给出 待 PDF §4 对照表格
任务放弃率具体下降幅度 "放弃任务数 < Solo" 无具体数字，仅有序关系 待 PDF §4
运行间方差具体度量 "AgentRoom < Solo" 无具体数字或度量名称 待 PDF §A

结论：abstract 支撑核心方向（CRDT + 三工具驱动协调），但具体数字存 4 处空白，引用具体指标时需标注"待 PDF 核验"。

2. 实际系统怎么用

接入层：三个 MCP tool（claim/status/broadcast）需要接入支持 MCP 协议的 Agent 运行时。当前主流支持 MCP 的平台包括：

  • Claude Code（Anthropic 官方 CLI 工具，2024 年底已内置 MCP 客户端）
  • Cursor（截至 2025 年支持 MCP server 注册）
  • Devin（Cognition 自研，对 MCP 支持程度需独立核验）

对于不支持 MCP 的平台（如早期 OpenAI 生态），需要一层 MCP Client Adapter：将 claim/status/broadcast 调用转换为该平台的等效 API 调用。论文未提供这一适配层，是生产接入的已知缺口。

运行时依赖： - CRDT 合并库（生产级候选：Yjs / Automerge-Python / Diamond Types） - 广播事件总线（推荐 Redis Pub/Sub 或 Kafka，用于跨进程/跨节点事件分发） - 每个 Agent 进程需维护本地 CRDT 状态副本，内存占用与并发 Agent 数线性相关

3. 坑在哪

坑 1：语义级冲突 CRDT 无法处理 CRDT 只解决字符级合并。两个 Agent 同时修改同一函数的两个不同分支，CRDT 给出"可合并"的假象，但语义上可能是冲突的。例如：

# Agent A 的写入
def process(x):
    result = step_a(x)  # 新增
    return result

# Agent B 的写入（同一函数）
def process(x):
    return step_b(x)  # 新增，与 A 冲突但 CRDT 不感知

建议在 CRDT 层之上加 AST 级别的语义冲突检测，超时未解决的 claim 需人工 review。

坑 2：claim 声明不等于物理隔离 claim(path) 是意图声明而非文件锁。如果 Agent B 在 Agent A claim 之后直接写该文件（不通过 claim），CRDT 仍会合并，产生难以追踪的幽灵写入。需要 MCP tool 层强制"所有写操作必须先 claim"，并在 Agent 运行时层面做静默拒绝。

坑 3：广播风暴 broadcast(event) 如果不加 rate limit 或 fan-out 控制，在 10+ Agent 场景下事件量 = O(n²)。建议在事件总线层加 namespace 过滤，或限制每个 Agent 的 broadcast 频率。

坑 4：MCP 工具 schema 未知导致集成摩擦 论文未给出三个 MCP tool 的完整 schema（参数类型、返回值格式、错误码）。生产接入前需要反向工程或等待论文补充 Appendix。

4. 部署检查清单

□ CRDT 合并库已选型并通过并发写入压测（建议 Yjs + y-indexeddb）
□ 广播事件总线已通过 10+ Agent 同时 publish 压测
□ MCP tool schema 已向论文作者或 Appendix 确认
□ 语义级冲突检测层已在 CRDT 合并后插入 AST diff
□ claim 强制校验已在 Agent runtime 层实现（防止幽灵写入）
□ broadcast rate limit 已配置
□ OpenTelemetry trace 已接入，覆盖 claim/status/broadcast 三个事件类型
□ 弃任务率监控已接入（Prometheus counter + Grafana dashboard）

5. 与现有框架的叠加建议

AgentRoom（协议层）+ CrewAI/AutoGen（编排层）是正交组合，不互斥。建议路径：

  1. 上层用 CrewAI 做角色划分（planner / coder / reviewer）
  2. 下层用 AgentRoom 做文件级并发协调
  3. 中间层：在 CrewAI 的 task output 进入下一 Agent 之前，走一遍 CRDT merge + claim 校验

这样做的好处是既保留了 CrewAI 的上层 SOP，又引入了 AgentRoom 的并发收益，且不需要对 CrewAI 本身做侵入式修改。