有个叫 consensus-rnd 的开源项目，2026 年 5 月 25 日建仓，到 6 月 12 日刚满 18 天。这 18 天里，它的 issue 编号涨到 402，PR 编号涨到 469，最新合并的那条挂着 #871。
把这些数字放在一起会有点不适：一个不到三周的项目，提交、评审、合并了将近 900 条 issue 和 PR，而这些工作的"作者"基本不是人，是这套系统自己。
它不雇程序员，也不靠一个人加班。它是一个跑在 GitHub 上的自治回路：自己发现要做的事，自己写代码，自己评审，自己合并，opt-in 之后甚至自己发版。全程没有人在每一步点"同意"。
这正是它值得看的地方。当 AI 已经能写出能跑的代码，剩下的问题不再是"它会不会写"，而是你敢不敢让它在没人盯着的时候，往你的主仓库里一直提交。consensus-rnd 给出的，是一套关于"怎么敢"的工程答案。
它到底是什么
先去掉光环。consensus-rnd 本身不是一个能运行的应用，它是一个跨平台的 Agent Skills 发布仓库。仓库里真正的产物只有 skills/ 目录下的两个 skill，外加一组让 Claude Code、Codex、Cursor、Gemini 都能指向同一份 skill 的平台清单。
两个 skill 分工很清楚：
- • ：重型自治回路。守护进程监督、Codex worker 派发、GitHub 编排、review 闸门、自动发版，全套都在里面。它处理的是能表达成 GitHub issue/PR 的"仓库自有工作"——feature、bug、文档、治理、重构都算。
- • ：轻量版。把同一套共识哲学压缩成纯 prompt 方法论，没有守护进程、没有 GitHub 编排，适合"这个高风险决策我想要几个隔离视角帮我判断，但不需要整套基建"的场景。
作者对"研发"的定义很激进，写在中文 README 里：任何持续向仓库提交状态的活动都是研发。代码、文档、营销、配置维护，只要需要 commit、需要评审、需要质量把关，就都能塞进这个回路。这句话决定了它的野心不是"AI 写代码工具"，而是"AI 自治交付的通用底座"。
它真正在回答的问题：信任
模型会写代码这件事，2025 年就不新鲜了。难的从来是下一步——让它在无人值守下持续改一个真实仓库，而你睡得着觉。
这里的障碍不是智力，是信任。单个 agent 再聪明，你也不敢把 commit、push、merge、发版的权限一次性交给它，因为它会犯错，而且会用很自信的语气犯错。人类组织几百年前就遇到过同构的难题：怎么让一群不完全可靠的个体，产出一个可靠的集体决策？人类的答案是分权、制衡、对抗性评审、用宪法约束授权。
consensus-rnd 做的事，可以理解成把这套制度搬给了 AI agent。它不去赌某个 agent 更聪明，而是设计一套流程，让一群各有偏见的 agent 互相牵制，最后收敛出一个可机械验证的结论。它信任的不是任何单个 agent，是制度本身。
三层制衡
拆开看，这套制度有三个互相咬合的层。
第一层，偏置独立的多角度。 一个设计决策不是丢给一个 agent 拍板，而是同时派三个 solver，每个带一种刻意安装的偏见：
- •
minimal：能解决问题的最小改动，明确拒绝过度设计； - •
structural：宁可多花成本（多一个抽象、多一跳），也要让架构评审半年后挑不出毛病； - •
delete：先质疑这功能到底要不要存在，能删就删，能并就并——而且禁止说"以后再说"，因为这个回路算力无限、不等人，要么现在删，要么承认必须留。
关键约束是：同一轮里，这三个 solver 看不到彼此的输出，各自封闭地下结论。 这是在故意制造分歧，而不是让它们抱团。评审侧同样有三个带不同先验的 reviewer——架构合规、代码质量、测试覆盖——也是彼此盲审。
为什么要刻意制造对立？因为一个会附和的评审等于没有评审。让 minimal 和 structural 天然吵架，让 delete 永远先问"凭什么加这段代码"，系统才有机会在合并前暴露出单一视角看不到的坑。
第二层，固定真值表收敛。 分歧总要有个了断，但这个了断不能靠某个 agent 临场发挥的"我觉得"。consensus-rnd 把它做成了规则：
设计阶段有个第四方 meta-judge，它不提方案，只读三份 solver 输出，然后只允许输出两种结果——达成共识，或者带着一个收窄的问题再来一轮。它没有权力直接拍一个第四种方案，因为那意味着它在解题而不是裁决。
合并阶段更硬，直接是一张真值表：reject=0 且 approve≥1 才放行 merge；只要有一个 reject，就回去修；评论只算建议，不计入批准。到底合不合并，不是讨论出来的，是算出来的。
这一层把"判断"从模糊的自然语言，压成了可以被机器复核的固定规则。系统里甚至有个叫 ConsensusGateProof 的纯校验器，专门检查一个共识证明是不是合法——它会拒绝单 worker 自我认证、拒绝角色重复、拒绝把命令和生命周期权限偷偷塞进证明里。规则之外，没有商量。
第三层，窄授权面。 谁能动 git，被卡得很死。controller 是纯编排者，它只负责路由、贴评论、打标签、派活、提交、合并、发版这些动作，而且只能走窄授权通道；它不思考、不写代码。真正写代码的 worker，只在隔离的 worktree 里产出 diff，它没有 commit 和 push 的权限。设计、实现、验证、修复全部外包给 worker 或确定性脚本，编排和执行被彻底切开。
把三层叠起来看，它其实给了一个可以借走的判断公式：
自治的可信度 ≈ 视角的对抗性 × 收敛规则的确定性 × 授权面的狭窄度。
三个乘数里任何一个塌成零，整个自治就不可信。视角全是附和的，对抗性归零；收敛靠某个 agent 心情，确定性归零；执行者手握全部权限，授权面归零。consensus-rnd 的全部复杂度，几乎都花在让这三个乘数同时不为零上。
最反直觉的一条：对"明显"的不信任
整套设计里最值得琢磨的，是它对"明显"的态度。
文档里写得很清楚：哪怕方向再明显，单个 agent 也不允许跳过共识直接去实现；闸门的作用，是把"明显的方向"证成"明确的方案"。
这很反工程师直觉。我们平时遇到显而易见的改动，第一反应是省掉流程直接干，走流程显得官僚。但 consensus-rnd 赌的是另一件事：在一个无人值守、会持续运转几百轮的系统里，"因为结论显然就跳过程序"这个口子一旦开了，就再也收不住。 今天能因为"明显"跳过共识，明天就能因为"差不多"跳过评审。
这恰好是人类制度里程序正义的内核——程序的价值不在每一次都改变结论，而在它不可被单方面跳过。一个能随时说"这次太明显了不用走流程"的系统，本质上等于没有流程。
它在用自己证明自己
consensus-rnd 还有一个气质上的细节：它是它自己最大的用户。
那将近 900 条 issue 和 PR，绝大多数是这套回路作用在自己身上的产物——它用自己的共识机制，来演化自己的共识机制。翻开代码，到处是这样的注释化石：
Refactor (iter3/skill-merge-policy):
Old pattern: 全票通过才合并 + 文案自相矛盾
New principle: 固定真值表 reject=0 && approve>=1 → MERGE；评论是建议
每一条都是一次"旧模式 → 新原则"的记录，层层叠叠，像地质剖面一样记下了这套制度自我修正的轨迹。一个声称能让 AI 自治改代码的系统，最有说服力的证据，就是它确实在让 AI 持续改写它自己，而且改了 18 天还没崩。
它没有藏着风险
值得给作者记一笔的，是 README 里那段风险提示写得异常坦诚，没有一点营销腔。它明明白白告诉你：
启用后回路可以无人值守运行，commit、push、merge、发版都没有逐动作人工确认；持续派 Codex worker 加六个轮询 GitHub 的守护进程，会一直烧 API 配额、token 和本机算力；自动发版打开后，坏版本直接弃掉用下一个版本盖过去，已发布的 tag 不回滚不移动；它现在是 dogfood 阶段的实验性基础设施，不是生产稳定性保证，下游不显式 opt-in，所有自治动作都该是 noop。
一个项目愿意把"它可能怎么伤到你"写在最显眼的地方，这种坦白本身就是一种成熟度信号。它清楚自己手里这把刀有多快，也清楚自己还在 dogfood 阶段——能力边界划得很死，只做能表达成 GitHub issue/PR 的仓库内工作，不碰任意的 GitHub 管理权限。
把视角拉远，consensus-rnd 真正有意思的地方，不在它今天能不能稳定干活，而在它选的那条路。当 AI 能力上限不断抬高，越来越多人把希望押在"等下一个更强的模型"上。它押的是另一个方向——与其等一个更值得信任的 agent，不如设计一套不需要信任任何单个 agent 的制度。
这套思路如果成立，影响会超出代码仓库。任何需要让一群 AI 在无人值守下持续产出、又不能失控的场景，缺的可能都不是更聪明的模型，而是这样一部能被机器执行的宪法。