AgentRoom：CRDT shared workspace for concurrent coding agents
AgentRoom：CRDT shared workspace for concurrent coding agents
一句话结论
AgentRoom 把多 agent coding 从“多个独立样本最后 merge”推进到“多个 agent 在 CRDT 合并的 shared workspace 中实时协作”。它的关键机制不是简单并行，而是把 file-level claim、status、broadcast 作为 MCP tools 暴露给 coding agents，让并发探索具备协调协议。这为 Loop-Engineering 和 Harness-Engineering 提供了一个多执行者 runtime 设计样本。
为什么对用户重要
用户关注 agent workflows、harness、长程任务和企业内部 coding-agent benchmark。真实复杂任务常常跨文件、跨模块，单 agent 容易陷入一文件 stub 或长程放弃；但简单开多个 agent 又会产生冲突、重复、互相覆盖和不可归因。AgentRoom 关注的正是这个中间层：如何让并发 agent 知道谁声明了哪个文件、当前状态是什么、何时广播信息，以及如何把文件系统合并成可继续工作的共享状态。
对 Hermes 来说，这提示多子代理开发不能只靠自然语言“你负责 A、你负责 B”。需要 workspace-level contract：claim/lock/status、broadcast、merge policy、conflict resolution、run-to-run variation 记录和最终 verifier。
机制 / 一阶原理
CRDT 解决的是协作编辑里的并发合并问题；AgentRoom 在此之上给 agent 暴露 MCP 工具：file-level claim 避免重复占用，status 让其他 agent 看到进度，broadcast 支持跨 agent 信息同步，CRDT-merged filesystem 承载并发修改。abstract 的核心结论是 full AgentRoom 优于部分组件，说明贡献主要来自协调协议，而不只是并行数或自动 merge。
这和 Harness-Engineering 的关系在于：harness 不只定义单个 agent 的工具面，也定义多个 agent 之间的共享状态、通信边界和冲突规则。和 Agent-Benchmarks 的关系在于：评测并发 coding agent 时必须区分 solo、parallel-merge、coordinated shared workspace，并在 matched compute 下比较 abandon rate、variation、quality/cost。
对 Hermes / llm-wiki 的可执行启发
- 复杂 coding 任务若使用子代理，应先声明文件/模块 ownership、状态更新协议和冲突解决规则。
- 多代理不是默认增益；必须用 matched-compute benchmark 比较 solo、parallel、coordinated 三种模式。
- MCP 可以不只是外部 API gateway，也可以成为 agent 间共享状态和协作原语的接口层。
- llm-wiki 批量入库可借鉴 claim/status：不同子任务写哪些页面、哪些概念待合并、哪些 raw 已读取，应外部化成状态表，避免重复薄页。
失败模式 / 边界
- 本轮只读取 abstract，未审查任务设置、CRDT 实现、LLM judge 和具体数据；定量结论保持 medium confidence。
- CRDT 能合并文本，不等于能合并设计意图；语义冲突仍需要 verifier/reviewer。
- 多 agent 协调会增加 token、状态和协议成本；小任务可能不值得。
深度判断
晋升为正式 source 页，因为它不是泛泛的“多 agent 更强”，而是给出可迁移机制：CRDT shared filesystem、MCP coordination tools、claim/status/broadcast、matched-compute comparison。这对未来 Hermes 子代理/批量 wiki ingest 的 runtime 设计有直接参考价值。
写入记录
- 2026-08-30 09:00 CST：根据 arXiv abstract 新增 AgentRoom 分析，提炼 CRDT shared workspace、MCP 协调原语和多代理 coding benchmark 启发。