AgentRoom: 基于 CRDT 的共享工作空间中的并发多智能体编码

TL;DR AgentRoom 通过 CRDT 支持的共享文件系统和 MCP 工具实现多编码智能体实时并发协作，相比 solo 或并行合并，显著降低任务放弃率，证明协调而非并行或合并是关键。

问题

问题背景

多智能体编程（multi-agent coding）旨在将多文件项目分解给多个 LLM 并行开发，以提升效率与鲁棒性。业界持续探索并发分工、冗余采样与实时协作协议，但受限于 LLM 的逐 token 生成机制，真正的并发协作尚未成熟。

现有方法局限

现有框架普遍存在两类问题：

• 相位交接型（如按角色顺序执行 agent）会产生等待时间与上下文信息丢失；
• 无协调并行型仅合并独立样本，缺乏文件级冲突检测，易导致重复劳动与集成失败。 单个 agent 在困难任务上的放弃率高达约 50%，常以单文件桩代码退出，无法完成多文件集成。尽管 CRDT 已解决人类团队的实时协同编辑，但直接套用到 LLM 存在 token 粒度与工具接口不匹配。

为什么这个问题难/重要

多智能体编码的核心难点在于：需要在 共享文件系统 上实现文件级声明、状态广播与冲突消解，同时兼容 MCP 工具调用。协调层的开销与一致性保障直接决定任务完成率与方差：缺乏协调的并行策略往往带来伪并行，实际收益有限；过度串行又牺牲吞吐。该问题直接影响企业级 multi-agent 系统的工程可行性。

行业类比

如同分布式数据库采用 CRDT 实现多副本最终一致，将实时协作编辑能力赋予编码智能体，可类比为“为 LLM 搭建一个支持并发提交的共享仓库”。

核心洞察

• AgentRoom 的核心是把文件级 claim、status、broadcast 封装为 MCP 工具，运行在 CRDT 合并的共享文件系统上，使多个编码 agent 在生成 token 的过程中实时协调。与 Aider/CodeStory 等顺序流水线或独立采样后合并的 baseline 不同，AgentRoom 让 agent 显式感知文件占用和冲突，从而避免生成半途放弃（stub-and-exit）。工程启示：协作协议应嵌入生成循环，通过工具调用实现同步，而不是依赖最终合并策略。
• 消融实验表明，协调层（ordering）而非 CRDT 合并或并行度，是性能提升的主要来源。作者将完整 AgentRoom 与 CRDT+prompt 无 MCP、仅并行合并等部分配置对比，完整版本在所有条件下占优。这挑战了“先并行采样再合并即可”的直觉，证明多 agent 编码需要显式的 claim 冲突避免与状态广播。工程设计 MCP 工具时，claim 和 status 的时序语义比底层复制机制更重要。

方法

输入是多个编码代理同时处理多文件项目；每个代理通过 MCP 工具 与共享工作区交互。

核心由三部分组成：

1. CRDT 共享文件系统：所有代理的编辑操作通过 CRDT 合并，保证最终一致且无中央锁。
2. 协调运行时：在 CRDT 之上暴露 claim / status / broadcast 三个文件级 MCP 工具，代理用 claim 声明正在修改的文件，status 更新进度，broadcast 向其他代理广播信息，从而降低并发写冲突。
3. 协作协议与评估：代理遵循特定工作流（如先声明再编辑），系统用 Quality Score 和 Emergence Score 评估产出；实验覆盖 Python DevBench 与 Rust+axum，对比 Solo、parallel-merge、串行角色流水线等基线。

输出是多个代理共同完成的代码库，关键指标显示 2 代理比 Solo 放弃任务更少、运行间方差更低；在 matched-compute 下，协调带来的收益超过单纯并行合并。

与仅做 CRDT 合并或并行采样不同，AgentRoom 把文件级声明与广播变成显式 MCP 工具，将协调行为内化为代理可调用的接口，而非依赖事后合并。

实验

实验设计

AgentRoom 在 CRDT 支持的工作区上实现并发多智能体编码，通过 MCP 工具提供文件级 claim / status / broadcast 原语。实验使用五个前沿 coding CLI 模型，在四个后端任务（T1–T4）上运行，并加入跨语言验证：DevBench 多文件 Python 任务与 Rust+axum 任务。基线包括 Solo（单代理）、parallel-merge（无协调并行合并）及顺序角色流水线。评估采用 LLM-judge（主）与 regex scorer（辅），指标涵盖任务放弃率、运行间变异及匹配计算量对比。

关键发现

对于 CLI 稳定的模型，2 个 AgentRoom 代理的任务放弃率低于 Solo，且运行间变异更小。在匹配计算量下，一项 LLM-judge 对比显示 AgentRoom 优于 parallel-merge；另一项 bundle probe 表明完整 AgentRoom 优于所有部分条件（如仅 CRDT 合并或仅 prompt）。这指向 协调 而非并行度或 CRDT 合并承担主要贡献。文件级 claim/status/broadcast 降低了冲突率，避免单代理“stub-and-exit”式放弃。

基线对比解读

与顺序流水线相比，AgentRoom 在相同计算预算内实现了更稳定、更少中途放弃的多文件开发，表明实时协调原语能有效利用并发代理的冗余优势。与 parallel-merge 的对比进一步说明，仅靠并行采样后合并无法解决冲突，必须通过显式 claim 协议约束写入。这对工程实践的启示是：多代理编码系统应优先设计轻量级协调层（类似 CRDT 之上的 MCP 工具），而非盲目增加代理数量或依赖事后合并。

行业影响

落地场景

AgentRoom 适合需要多智能体并发开发多文件项目的场景：

• AI coding agent 平台：如 GitHub Copilot Workspace、Cursor 等 IDE 插件，可支持多个 agent 同时编辑不同文件，提升复杂任务吞吐。
• 企业级软件交付：金融、电商等行业的微服务架构开发，多个 agent 可并行实现认证、订单、支付等模块，减少串行交接。
• 自动化测试/重构：让多个 agent 并行探索不同实现路径，并通过 CRDT 合并不冲突的变更。

商业价值

• 降本：减少任务放弃率（实验显示 CLI-stable 模型下 2 agent 放弃任务少于 Solo），降低无效 token 消耗；减少 run-to-run 波动，预测成本更稳定。
• 增收/交付效率：通过并行开发提升单位时间产出，尤其适合计费型 agent 服务，提高客户满意度与复购。
• 体验提升：CRDT 实时同步提供一致的工作区状态，避免合并冲突导致的人工介入，使多 agent 协作更可靠。

与现有产品/工作流接口

AgentRoom 的运行时层通过 MCP tools（file-level claim、status、broadcast）暴露能力，可无缝集成至：

• 现有 agent 框架：LangChain、AutoGen、CrewAI 等，将 AgentRoom 作为共享文件系统后端。
• IDE/编辑器：VS Code、JetBrains 等可通过 MCP 客户端接入，让人类开发者与 AI agent 实时协作。
• CI/CD 流水线：在代码生成阶段使用 AgentRoom，生成的代码可直接进入测试与部署，减少合并成本。

具体落地 use case：

• 电商平台开发：多个 agent 同时开发商品服务、订单服务、库存服务，通过 CRDT 合并各自文件，避免一个 agent 完成全部导致超时放弃。
• 金融风控系统：并发生成数据管道、模型训练脚本、API 层，AgentRoom 的 claim 机制防止文件竞争，broadcast 让 agent 感知彼此进展。

局限

• AgentRoom 依赖模型稳定调用 MCP 工具，对于不支持或对话式不稳定调用工具的模型，协作效果可能下降。实验也指出 Concurrent-MCP CLI Compatibility 存在部署注意事项，部分模型在特定环境下工具调用不稳定，限制了实际适用范围。此外，多智能体系统通常需要较强的基础模型能力，而论文仅测试了五个前沿 CLI 模型，模型规模与类型覆盖有限，对不同能力层次模型的泛化性存疑。
• 评估有效性方面，论文使用 LLM-judge 作为主要评分器，存在与待评估模型同源或偏好偏差，摘要中同样提到 Same-family judge concern。虽然进行了交叉验证，但 LLM-judge 的可靠性仍受质疑。任务规模较小（四个后端任务），实验重复次数有限，统计功效可能不足，尤其对于部分正向结果仅有一个正向平均 LLM-judge 对比，结论的普适性需要更多任务与更大规模实验验证。
• 与现有框架对比不足：论文比较了 Solo、parallel-merge 以及 sequential role pipeline，但未与更多成熟的 multi-agent 编码框架（如 MetaGPT、AutoGen、ChatDev 等）系统对比。这些框架虽非 CRDT 并发模式，但作为基线能体现 AgentRoom 的增量价值。此外，CRDT 合并在更复杂的代码场景（如细粒度同文件并发编辑）下的语义正确性与冲突解决能力尚未充分验证，可能限制了其在大型项目中的应用。