补漏四条：
- 2817 stars / 336 fork 四天，不是看上去那么夸张。release 历史回溯到 2026-05-29（v0.1.60）、COORDINATION 文档标 5/28 prompt 基线、agent-cli 已迭代到 v0.1.127。三个月内部打磨 + 四天爆发的反差，决定了它不是 weekend 项目，是有沉淀的成品。这条时间线比 stars 数字更说明工程纪律——yetone 这人做事是先做后喊。
- 「钉死每 agent 模型」(prod 上 claude-opus-4-7) 这条原帖讲得对但没说根因。本地 Claude CLI 曾在一次会话中途把默认从 opus-4-7 翻到 opus-4-8，多 agent 行为当场变样——这种"模型自己换自己"的事件只有 Anthropic 发模型时才会触发，频率不高但杀伤力大。钉版本号在多 agent 系统里是 production 表，不是 best practice。原帖没讲「钉版本号 = 多 agent production 第一铁律」。
- 大脑 6 / 小脑 8 的并发差异是血的教训。原文 0-1500ms 随机抖动曾导致四个 agent 同时醒全滚到低值，照样锁死；改成 500ms 定长间隔后，突发速率在数学上就是 1/间隔。这条经验对所有「基于速率限制的防爆机制」都有普适价值——随机抖动在尾部事件分布上比定长间隔差很多。原帖讲「215-359 秒排队」是结果，但没说清调参路径。
- chain / counting 是"形状对偶"基准——这条设计哲学很值。chain 考"队友缺席时团队会不会补位"（nova 曾补位连发三次）；counting 考"有明确上限时守不守得住"。任一方向回归，只会在其中一个暴露。判分走统计而非逐次（≥67% 试次精确完成 且 中位逐字碰撞 = 0）——这套设计比大多数项目"跑通 demo 就算赢"扎实得多。这是 cumora 把多 agent 协调从"工程问题"提到"研究级基准"的关键动作。
- BYOA 把密钥锁回用户本地是个亮点，但安全面写得薄。文档里关于 SOC2 / GDPR / 数据主权几乎没说。"谁能 npx cumora agent computer" 这种访问控制没明文——守护进程跑在用户机器上，被另一台机器用同账号 SSH 进来就能调 Agent。这是 BYOA 模式的隐藏攻击面。文档没覆盖，企业落地会卡这一步。