代价和风险

效果和代价

环节	之前	之后
提需求	写详细任务	跟 Planner 说一句
批准待办	人	Planner 按放行分级自主放行部分任务，其余由人批准
选人	凭感觉	按额度和成绩单
评审	人排队	另一个账号的 Reviewer + 自动检查
合并部署	人点按钮	自动
验收	人或没人	Planner 线上验证
代码健康	没人管	Auditor 每周报告

代价：

“批准”（backlog 改成 todo）agent 也能做。AUTOTEAM_AUTO_APPROVE=on 时，Planner 可按放行分级自主放行部分任务，每日有上限；受保护路径、新功能等不符合条件的任务仍由人放行。平台拦不住越界放行，其余约束靠指令执行，并由每日摘要里的放行核对发现违规；代码仍然要过检查和独立评审才能合入。
升级 autoteam 时，角色指令的变化不在 PR diff 里。指令随包发布、不落盘，升级 PR 只改版本号；要在升级 PR 描述里贴上两个版本之间的指令差异让人批准，见规则由包版本固定。
先部署后验收。新功能建议放在功能开关后面，验收通过再全量打开。
额度规则变化快。比如 Codex 的 5 小时限制在 2026 年 7 月取消、8 月底又恢复，registry.yaml 要每月核对。
人参与少了会对代码变陌生。建议每周抽读一两个合入的 PR，调试和架构决策刻意保留给人做。
平台闸门取决于 GitHub 套餐。Free 的私有仓库缺少平台强制闸门，约束会退化为指令约束（降级模式），见保护等级。
Multica 迭代很快。几乎每个工作日都发版，行为可能变化（0.5 就改了状态模型）。升级后跑一次 autoteam doctor，再演练一个小需求；旧 shipping 状态的归档仍需直接调用 Multica 的 HTTP 接口。

没在长期运行的大型项目上验证过整套配置，效果要用每周指标自己衡量。
跨文件调用数这类可维护性指标和语言强相关，health-metrics.sh 没有内置。
Multica agent 的调用权限：默认 private，autopilot 和 agent 由同一个人创建时链路能走通；多人协作时要改成 workspace。