自管理 Agent 团队研究
自管理 Agent 团队，指的是让几个编码 agent 按角色分工，自己完成拆需求、写代码、评审、合并、上线和验收，人只负责提需求和批准任务。现在 AI 写代码已经不是瓶颈，卡住项目的是评审、代码质量和“到底做没做完”。这里从现状问题、方案设计、实施效果三部分整理这套方案，实施效果是把它做成工具 autoteam 后在示例项目上跑通的真实过程，希望对你有帮助。
现状问题
用 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 实践。
方案设计
这部分只讲角色和规则，不涉及具体工具。
整体流转
对于流程图里的编号：
- 人把需求告诉 Planner(规划者)。
- Planner 把需求拆成可单独验证的子任务，放进“待审核”。
- 人批准任务，也就是把它从“待审核”改成“待办”，这是人在日常流转里唯一的操作。
- Planner 按额度给任务选一个 Implementer(实现者)和一个 Reviewer(评审者)，两者必须不同。
- Implementer 实现并提交 PR，任务进入“审核中”，交给 Reviewer。
- Reviewer 批准后任务仍停在“审核中”，PR 在检查全部通过时自动合并、部署；有阻塞项就打回给 Implementer。
- 部署完成后，Planner 在线上按验收标准验证，通过才算完成。
另外，Auditor(审计者)定时把代码健康报告交给 Planner；来回处理超过次数上限的任务，由 Planner 升级给人。
可能有人会问：不需要“已批准”、“返工”、“待上线”这些状态吗？其实不需要，批准就是改成待办，打回和返工靠 @ 对方，评审通过后等线上验收，看板用项目平台自带的几列就够了。
人的参与方式
可能有人会问：合并和上线都不看，安全吗？我的回答是可以，前提是把原来人把关的环节换成 agent 绕不过去的规则：
| 原来靠人 | 现在靠什么 |
|---|---|
| 看代码 | 另一个身份的 Reviewer + 自动检查 |
| 点合并 | 代码平台的合并规则，所有 agent 都不能豁免 |
| 验收 | Planner 看线上真实结果 |
人只跟 Planner 对话：下发需求、批准任务、回复升级。修改约束 agent 的规则文件(合并规则、工作流、agent 指令、计费注册表)也必须由人批准。
压缩起来是四条不变量，实现可以换，这四条不能破：
- 写代码的不能评审自己。
- 能不能合并只由代码平台判断。
- 完成看线上真实结果。
- 约束 agent 的规则文件只能由人批准。
四个角色
| 角色 | 负责 | 不能做 | 实时触发 | 定时触发 |
|---|---|---|---|---|
| Planner | 拆需求、选人派发、线上验收、升级 | 写代码、批准任务 | 支持 | 支持 |
| Implementer | 实现单个子任务 | 评审、合并、标记完成 | 支持 | 不支持 |
| Reviewer | 评审 PR | 改代码、验收 | 支持 | 不支持 |
| Auditor | 周度健康报告、月度方向报告 | 改代码、直接建任务 | 不需要 | 支持 |
谁会叫醒谁：
说明：
- 角色之间的交接只靠两种动作：指派任务和评论里 @ 对方，改状态本身不叫醒任何人，状态只表示看板上的进度。
- Implementer 和 Reviewer 不设定时触发，因为它们的每次运行都要对应一个具体任务，由 Planner 统一调度。
Planner
实时触发：人下发需求、批准或回复；一批子任务全部完成；部署结束；Reviewer 或 Auditor @ 它。
定时触发：
| 任务 | 时间 | 内容 |
|---|---|---|
| 推进巡检 | 每2小时 | 先列出要处理的事(已合并没验收、运行失败、卡住的任务)，清单为空直接结束 |
| 每日摘要 | 每天 9:00 | 进展、待人处理的事项、放行核对、各账号额度用量 |
| 规则复盘 | 每周一 12:00 | 回看人介入的地方，提规则改进 |
指令(精简版)：
你是 Planner，负责拆需求、派任务、线上验收和升级问题，不写代码。人只和你对话。
开工先读 playbook(人批准过的项目经验)，再按事件读对应的 runbook，只读本次需要的：
- 收到需求、人回复、Auditor 报告要拆任务：intake
- 子任务被放行：dispatch
- 部署通知、推进巡检、一批子任务完成：progress
- Implementer 或 Reviewer 运行失败：reassign
- 打回或验收失败满上限、线上故障：escalate
原则：人只看“待审核”和“升级”两列，你不能把球留在其它状态等人。
每次运行结束前，把下次该换个做法的经验记进运营笔记。
你不能：写代码、批准或合并 PR、批准任务、修改规则文件。指令没有把所有步骤写在一起，而是按事件拆成 runbook，这样 Planner 每次运行只读用得上的那一份，读入的上下文更少，也不容易串步骤。
Implementer
可以配多个，分别用不同厂商、不同计费模式的 agent。
实时触发：被 Planner 指派；被 Reviewer 或 Planner @ 要求修改。定时触发：不支持。
指令(精简版)：
你负责实现一个子任务，一次只做一个。
开工：读任务和评论，起环境跑一遍端到端验证，确认项目当前正常；项目本身坏了就停下并 @Planner。
交付：
1. 跑全量检查，把结果贴进评论；没跑就明说
2. 用交付脚本开 PR 并打开自动合并，标题以任务编号开头，不写关闭关键字，因为要等线上验收才算完成
3. 对照任务的“要做什么、不做什么、验收标准”逐条核对改动文件
4. 任务改为审核中，@Planner 指定的 Reviewer
5. 范围外的问题写进评论的“范围外发现”，不要顺手做
不要：
- 新写已有的组件和函数，因为同一个 bug 会要修好几处
- 加 fallback、双写、兼容层，因为错误会被吞掉
- 大范围重构，因为改动会没法评审
你不能：批准或合并 PR、标记完成、没有任务要求时修改规则文件。禁止项都带上原因，模型遵守得会好很多。
Reviewer
可以配多个，但必须和本任务的 Implementer 是不同的 agent，最好是不同厂商的模型，避免模型评审自己的思路。
实时触发：被 Implementer @。定时触发：不支持。
指令(精简版)：
你负责评审一个 PR，不写代码。
1. 先看自动检查，没跑完就等；有失败直接打回
2. 只看三件事：正确性(边界、错误路径、并发)、有没有重复实现、跨边界数据有没有校验
3. 发现写进评审，分“阻塞”和“建议”，每条带文件和行号
结论：
- 无阻塞项：在 PR 上批准，任务停在审核中不改状态
- 有阻塞项：在 PR 上要求修改，@Implementer
- 已打回过两次：不再打回，@Planner 说明分歧
你不能：改代码、推送提交、修改指派人、标记完成。Auditor
只出报告，不改代码、不建任务，要做的事交给 Planner 统一拆分。
实时触发：不需要。
定时触发：
| 任务 | 时间 | 内容 |
|---|---|---|
| 周度健康报告 | 每周一 9:00 | 四节：整合审计(重复代码)、agent 成绩单、老代码巡检、规格对账 |
| 月度方向报告 | 每月1号 11:00 | 两节：前沿扫描(模型、平台、计费规则的变化)、路线图对账 |
指令(精简版)：
你负责代码健康审计，只出报告，不改代码，不建任务。
1. 跑健康指标脚本：重复代码占比、老文件改动占比、两周返工率、一次通过率、人自己提交和评审的次数
2. 和上一份报告对比，列出变差的指标；无变化的一节只写“无变化”
3. 列出新增的重复实现和该复用却重写的地方，带文件路径和行号
4. 报告写完 @Planner，请它把值得做的拆进待审核
每条建议都要能变成一个独立的小任务，不提“整体重构”。按计费和额度选 agent
| 计费模式 | 额度规则 | 用完后 | 用法 |
|---|---|---|---|
| 订阅窗口制 | 滚动时间窗口(比如5小时)加每周上限 | 等窗口重置 | 优先用，大任务避开快用完的账号 |
| 包月点数制 | 每月点数，按 token 扣 | 按预算停用或超额计费 | 适合评审等短任务 |
| 按量计费 | 按 token 付费 | 不停，但账单没有上限 | 订阅用完且任务紧急时用 |
| 免费额度 | 每分钟、每天的请求数 | 当天停用 | 不用于正式项目 |
我的建议是优先用订阅，按量计费只留作应急并在控制台设好消费上限。注意订阅额度按账号算，同一账号下的多个 agent 共用一份额度。
Planner 的选人流程：
判断额度时参考三类信息：人维护的计费注册表、项目平台记录的每次运行 token 消耗、因额度耗尽而失败的运行记录(报错里通常带恢复时间)。
防止来回打转
| 情况 | 上限 | 到上限后 |
|---|---|---|
| 同一个 PR 被打回 | 2次 | Planner 升级给人 |
| 同一个任务验收不通过 | 2次 | Planner 升级给人 |
| 因额度或权限运行失败 | 换1次 Implementer | 仍失败则升级给人 |
| 线上故障 | 不重试 | 先回滚，再升级给人 |
次数由脚本从代码平台的评审记录和任务评论里统计，Planner 每次巡检重新计算，不依赖 agent 自己上报。
代码平台和项目平台
| 代码平台 | 项目平台 | |
|---|---|---|
| 负责 | 合并规则、自动检查、部署 | 任务状态、角色配置、触发和定时 |
| 谁能改 | 只有人 | agent 和人 |
我的建议是：能不能合并只由代码平台判断，项目平台的状态只用来调度，因为 agent 能改的状态拦不住 agent。
实施效果
我把这套方案做成了工具 autoteam：GitHub 管合并闸门，Multica 管任务调度。下面是在官方示例项目 autoteam-example 上的真实过程，被测版本是 autoteam f1dc4b5，Multica 0.5.0。我还没有在长期运行的大型项目上验证过，这部分效果需要用最后的指标自己衡量。
示例项目
“团队书架”是一个零依赖的 Node 静态网站生成器，把 data/books.json 生成成网页和 JSON 接口，线上是 GitHub Pages。接入前它只有 npm test 和 npm run build，没有 CI、没有部署，也没有 agent。
| 项 | 配置 |
|---|---|
| 仓库 | 组织的公开仓库，规则集、自动合并、合并队列都可用 |
| Multica | 独立工作区，任务前缀 AUTO |
| agent | 6个，Claude Max 和 ChatGPT Plus 两个订阅，跑在同一台云端机器上 |
接入步骤
- 安装 skill 并生成文件，
init一次生成 24个文件：Makefile 桩、三个工作流、CODEOWNERS、.autoteam/下的配置和脚本。 - 适配
make check、make dev、make deploy三个目标，填团队清单。 - 创建三个 GitHub App 作为三种身份。
setup一次预览 GitHub 和 Multica 两边的改动，确认后执行，最后自动逐项验收。
npx skills add autoteam-ai/autoteam --skill autoteam
bash .claude/skills/autoteam/bin/autoteam init --workspace autoteam --human Song
bash ./autoteam github --create-apps --apply # 没有 App 时用 Manifest 流程创建
bash ./autoteam setup # 预览两边，确认后执行并运行 doctor其中有两个容易踩的点：
make deploy要等线上版本变成本次提交才返回成功。因为部署结束后会立刻通知 Planner 验收，如果只是“推上去了”，Planner 看到的可能还是旧版本。- 身份用 GitHub App 而不是机器账号。GitHub 不允许 PR 作者批准自己的 PR，Implementer 和 Reviewer 用两个不同的 App，就能在平台层面保证写代码的不能评审自己，而且不用注册邮箱、不占席位。可能有人会问 Reviewer App 能不能只给读权限？不行，GitHub 只把有写权限的身份提交的批准计入必需审批数，所以“评审者不能推代码”仍然只是指令约束，能当硬约束的只有“作者不能批准自己”。
团队清单同时是计费注册表，Planner 读它选人，工具按它创建 agent：
# .autoteam/registry.yaml：受 CODEOWNERS 保护，每月核对一次各家规则
accounts: # 同一账号下的 agent 共用额度
claude-max: { billing: subscription, windows: [5h, weekly] }
chatgpt-plus: { billing: subscription, windows: [5h, weekly] }
agents:
planner: { role: planner, account: claude-max, runtime: claude@devcontainer-cloud, max_tasks: 5 }
impl-claude: { role: implementer, account: claude-max, runtime: claude@devcontainer-cloud, max_tasks: 3 }
impl-codex: { role: implementer, account: chatgpt-plus, runtime: codex@devcontainer-cloud, max_tasks: 3 }
rev-claude: { role: reviewer, account: claude-max, runtime: claude@devcontainer-cloud, max_tasks: 3 }
rev-codex: { role: reviewer, account: chatgpt-plus, runtime: codex@devcontainer-cloud, max_tasks: 3 }
auditor: { role: auditor, account: chatgpt-plus, runtime: codex@devcontainer-cloud, max_tasks: 1 }GitHub 侧配好后的规则集如下：
对于截图里的配置：
- “Bypass list”是空的，所有 agent 包括管理员都绕不过。
- “Restrict deletions”和“Block force pushes”防止删主干和强推。
- “Require a pull request before merging”要求 1个批准、Code Owner 审批，新提交会作废旧批准。
- “Require status checks to pass”的必需检查是
check：PR 不超过 400行、重复代码不超标、make check通过。 - “Require merge queue”保证合并前在最新主干上重跑检查。
Multica 侧是注册表里的 6个 agent，写代码和评审各有 Claude 和 Codex 一个：
任务状态只用 Multica 内置的几个，不建自定义状态：
| 设计中的状态 | Multica 状态 | 谁设置 | 下一步怎么被叫醒 |
|---|---|---|---|
| 待审核 | backlog | Planner 建子任务时 | 不启动运行，等人批准 |
| 待办 | todo | 人批准；Planner 派发时改指派 | 指派给 Implementer 即启动它 |
| 实现中 | in_progress | Implementer 开工或返工时 | 运行失败由巡检兜底 |
| 审核中 | in_review | Implementer 提交 PR 后 | @Reviewer；合并部署后由部署通知叫醒 Planner |
| 完成 | done | Planner 验收通过后 | 不需要 |
| 升级 | blocked | Planner | @ 人 |
注意两点：
- Multica 0.5 起自定义状态不再继承“进入即唤醒”这类行为，所以交接全部靠显式指派和 @。
- PR 标题只写任务编号建立关联；写
Closes AUTO-9合并时会直接设为完成，跳过线上验收，所以不要写。
平台闸门能做到什么程度，取决于仓库的归属和套餐：
| 保护等级 | 仓库 | 规则集和自动合并 | 合并队列 |
|---|---|---|---|
| full | 组织的公开仓库 | 有 | 有 |
| standard | 个人公开仓库、Pro 或 Team 的私有仓库 | 有 | 没有 |
| none | GitHub Free 的私有仓库 | 没有 | 没有 |
我的建议是正式使用至少要到 standard，none 只适合试用，因为这时合并只靠 agent 指令约束。
跑通一个需求
需求是“书架加作者页，按作者浏览”：作者从 author 字段拆出来，每位作者一个页面，再加一个 api/authors.json 接口。我在 Multica 里建任务指派给 Planner，之后的时间线(2026 年 10 月 1 日)：
| 时间 | 发生了什么 | 谁 |
|---|---|---|
| 07:32:42 | 提需求 AUTO-8 | 人 |
| 07:33:19 | 拆成一个子任务 AUTO-9，放进待审核，请人批准 | Planner |
| 07:35:26 | autoteam approve AUTO-8 --apply 放行 | 人 |
| 07:36:10 | 派发：Claude 实现、Codex 评审，理由写在评论里 | Planner |
| 07:37:15 | 开 PR #23(+121 −9，5个文件)，打开自动合并，@Reviewer | Implementer |
| 07:39:44 | 批准，进合并队列 | Reviewer |
| 07:41:50 | 合并 | GitHub |
| 07:42:25 | 部署成功，通知 Planner 本次上线了 AUTO-9 | CI |
| 07:42:56 | 线上逐条验收 AUTO-9，通过，设为完成 | Planner |
| 07:43:19 | 父任务整体验收通过，@人告知 | Planner |
从提需求到上线 11分钟，我只做了两件事：提需求，运行一次 autoteam approve。
Planner 用 40秒完成拆分，子任务写清“为什么做、要做什么、不做什么、验收标准”，验收标准全部是能在线上检查的：
PR 由 Implementer App 开出并打开自动合并，Reviewer App 批准后进合并队列，全程是两个不同的身份：
部署工作流会算出“这次新上线了哪些任务”放进通知里，没有新任务的部署不会叫醒 Planner：
# .github/workflows/deploy.yml(节选)
- name: notify planner
if: always()
run: |
issues=$(bash .autoteam/scripts/deployed-issues.sh deploy "$SHA")
if [ "$issues" = '[]' ]; then
echo "没有相关任务，跳过通知 Planner"
exit 0
fi
jq -n --arg sha "$SHA" --arg result "$RESULT" --argjson issues "$issues" \
'{kind: "deploy", sha: $sha, result: $result, issues: $issues}' \
| curl -fsS -X POST "$HOOK" -H 'Content-Type: application/json' \
-H "Idempotency-Key: $KEY" --data-binary @-Planner 先核对线上 version.json 的 sha 就是合并提交，再逐条验收，只验收通知里的任务：
最后是线上的效果，首页每位作者都能点进作者页：
这个需求的用量：
| agent | 运行 | 输出 token | 读入上下文 | 用时 | 模型 |
|---|---|---|---|---|---|
| planner | 4次(拆分、派发、验收、整体验收) | 8.8k | 136万 | 2.5分钟 | claude-sonnet-5-5 |
| impl-claude | 1次 | 8.1k | 74万 | 1.5分钟 | claude-sonnet-5-5 |
| rev-codex | 1次 | 2.4k | 40万 | 2.7分钟 | gpt-6-sol |
持续运行的部分
默认启用 5个定时或事件任务(Multica 里叫 autopilot)：
| 名称 | 指派 | 什么时候跑 |
|---|---|---|
| 部署结果 | Planner | 部署后有新上线任务时 |
| 推进巡检 | Planner | 每2小时 |
| 每日摘要 | Planner | 每天 9:00 |
| 规则复盘 | Planner | 每周一 12:00 |
| 周度健康报告 | Auditor | 每周一 9:00 |
没事时的巡检很便宜：清单为空，23秒结束，输出 524 token，不发评论。
手动触发一次周度健康报告，Auditor 用 4分钟出完四节：
对于报告里的发现：
- 整合审计发现新的作者页和已有的标签页重写了同样的列表页结构，Planner 把它拆成一个低优先级任务放进待审核。
- 规格对账发现“同一本书不允许重复作者”代码里做了、验收标准里没写，Planner 直接补进了验收标准。
- agent 成绩单里 impl-claude 一次通过率 100%，返工 0轮。
人要改规则文件、或者想停掉整个团队时，也各有一条命令：
bash ./autoteam propose --apply # 把本地的规则文件改动用 Implementer App 身份开成 PR，人只批准
bash ./autoteam stop --apply # 暂停本项目全部定时任务，取消正在跑的运行
bash ./autoteam resume --apply # 恢复效果和代价
| 环节 | 之前 | 之后 |
|---|---|---|
| 提需求 | 写详细任务 | 跟 Planner 说一句 |
| 批准待办 | 人 | 人(低风险任务可以开启 Planner 自主放行) |
| 选人 | 凭感觉 | 按额度和成绩单 |
| 评审 | 人排队 | 另一个身份的 Reviewer + 自动检查 |
| 合并部署 | 人点按钮 | 自动 |
| 验收 | 人或没人 | Planner 线上验证 |
| 代码健康 | 没人管 | Auditor 每周报告 |
代价：
- 批准(待审核改成待办)agent 也能做，靠指令约束和每日摘要里的放行核对来发现；代码仍要过检查和独立评审才能合入。
- 先部署后验收，建议新功能放在功能开关(Feature Flag)后面，验收通过再全量打开。
- 平台闸门取决于 GitHub 套餐，Free 的私有仓库没有规则集和自动合并，硬约束会退化成指令约束。
- 额度规则和 Multica 的行为变化都很快，比如 Multica 0.5 改了状态模型，升级后要重新验收并演练一个小需求。
- 人参与少了会对代码变陌生，建议每周抽读一两个合入的 PR。
这一轮也发现了 10个可改进的地方，比如人改规则文件的 PR 没有任务编号，合并部署后不会通知 Planner，改过的指令要手工同步到 Multica。
建议每周关注的指标：Reviewer 一次通过率、验收一次通过率、升级到人的次数、单任务花费、重复代码占比趋势，以及人自己提交和评审的次数(它应该随时间下降)。
总结
这篇从现状问题、方案设计、实施效果三个方面讲了自管理 Agent 团队：
总结起来，自管理不是放任 agent，而是把人盯着的环节换成 agent 绕不过去的规则：写代码和评审分开身份，合并交给检查，完成看线上结果，派活按额度调度。人只需要判断一件事值不值得做。如果你也在搭类似的团队，可以直接试试 autoteam，欢迎一起讨论。
扩展阅读
- autoteam
- autoteam-example
- autoteam 文档
- Effective harnesses for long-running agents
- Issues and projects - Multica Docs
- Autopilots - Multica Docs
- Available rules for rulesets - GitHub Docs
- Automatically merging a pull request - GitHub Docs
- Registering a GitHub App from a manifest - GitHub Docs
- What is the Max plan? - Claude Help Center
- Using Codex with your ChatGPT plan - OpenAI Help Center