quorum — MCP agent collaboration spine

quorum — MCP agent collaboration spine

为什么值得入库

quorum 的价值不在“Slack for agents”的比喻，而在它把多 coding-agent 协作最容易失控的部分做成 MCP coordination spine：身份识别、房间消息、事件 feed、文件 claim、断线恢复和人类参与。它补充了 子代理驱动开发 与 Harness-Engineering 中一个常见空白：多个 agent 同时工作时，冲突不是只发生在最终 git merge，而是发生在任务意图、文件 ownership、消息丢失和未读状态上。

机制 / 一阶原理

quorum 当前可运行部分是 localhost MCP server。agent 通过 identify 注册身份，通过 claim_scope 声明将要修改的文件范围，通过 post_message 交流，通过 wait_for_events 阻塞等待事件而不是轮询。状态持久化在本地数据库中，身份由 (name, harness) 决定，重连后可以恢复 claim 和 feed cursor。

这个设计的一阶原理是：多 agent 协作需要共享“谁是谁、谁将碰哪些资源、我读到了哪里、我是否错过消息”的最小事实层。没有事实层时，subagent orchestration 很容易退化成主 agent 的一次性 prompt 分发，无法处理并发冲突、重试、异步反馈和人类插入。

和既有 wiki 概念的关系

• 对 子代理驱动开发：补充文件 claim 和事件 cursor 这两个低层 coordination primitive。
• 对 Harness-Engineering：说明 harness 可以不仅控制单个 agent 的流程，也可以控制 agent fleet 的协作协议。
• 对 Loop-Engineering：长期 loop 若有多个 worker，需要持久身份、消息 replay 和 resource claim，否则跨轮状态不可恢复。

对 Hermes / llm-wiki 的可执行启发

1. 大规模 deep ingest 或 delegate_task 时，应引入 page/file claim，避免多个 worker 同时创建近似页面或覆盖同一概念页。
2. 对长期 cron，log 之外可增加轻量 event cursor：上次 radar 读到哪些 source/feed/query，哪些候选已拒绝。
3. Human-in-the-loop 不应只是最终审批按钮，也可以作为 room participant 进入事件流，留下问题、阻塞和决策。

失败模式 / 边界

• README 说明 deliberation protocol、DM 和 human web UI 仍是 spec，当前主要运行 coordination spine；不能把未来计划当成已实现能力。
• v0 信任机器边界、无认证，因此只适合 loopback / 本机协作，不适合直接暴露公网。
• 文件 claim 只能防止“知情 agent”碰撞，不能阻止未接入 quorum 的进程写同一文件。

写入记录

• 2026-07-30 09:00 CST：基于 GitHub README 新增 quorum 页面，提炼多 agent 身份、文件 claim、事件 cursor 与 llm-wiki deep ingest 并发控制启发。