为什么要自管理

AI 写代码已经不是瓶颈。用 agent 做大型项目，卡住的是评审、代码质量，以及“到底做没做完”。

四个问题

问题	数据	方案要解决什么
评审跟不上	AI PR 等待首次评审的时间是人写 PR 的 4.6 倍，接受率 32.7%（人写 84.4%）	评审不能只靠人
代码越写越乱	重复代码块 +81%，重构只占变更行数的 3.8%	要有角色专门管代码健康
agent 管不好自己	上下文中途耗尽留下半成品；看到有进展就宣布完成	“完成”不能由写代码的 agent 说了算
额度和计费碎片化	订阅有 5 小时窗口和每周上限，按 token 计费的规则还经常变	要按额度调度任务

数据来自 LinearB（810 万个 PR）和 GitClear（6.23 亿次代码变更）的报告，以及 Anthropic 的长时间运行 agent 实践。这些是厂商遥测和商业分析，适合当方向指示，不适合当强论据；落地时用你自己项目的每周指标判断。

设计原则

自管理不是放任 agent，而是把人盯着的环节换成 agent 绕不过去的规则。

1. 写代码和评审分开账号。GitHub 不允许 PR 作者批准自己的 PR，所以只要 Implementer 和 Reviewer 用不同的 GitHub 账号，“写代码的不能评审自己”就由平台保证，不靠指令。
2. 能不能合并只由代码平台判断。规则集、必需检查、CODEOWNERS 只有人能改；项目平台（Multica）上的状态 agent 也能改，所以只用来调度，不用来拦截。
3. 完成看线上结果。Planner 在部署之后按验收标准在线上验证，通过才算完成；PR 标题不写关闭关键字，合并不等于完成。
4. 派活按额度调度。Planner 读计费注册表和用量，额度快用完的账号不派大任务，避免中途耗尽留下半成品。
5. 次数从记录里算。打回几次、验收失败几次，从 GitHub 评审记录和任务评论里统计，不依赖 agent 自己上报；到上限就升级给人。
6. 看不见的工作变成定时任务。复用、整合、删死代码这些 agent 不会自发做的事，由 Auditor 每周出报告，交给 Planner 拆成任务。

人只需要判断一件事：值不值得做。

什么时候不适合

• 仓库还没有一条命令能跑完的严格检查（make check）。这时候上编排，只会以更高的效率把不合格的代码送进主干，而且因为看板上一切都在动、日志一切都是 completed，项目看起来非常健康。先把检查做扎实。
• 需求本身模糊、需要大量探索的阶段。Planner 拆不出能在线上验证的子任务，流程会在“待审核”里空转。
• 团队没人会抽读合入的代码。长期不看，人会对代码变陌生，出问题时没人能判断。

更多见代价和风险。