一个 session 里同时跑了三种协作模式
三种协作模式并行运转
Mio v0.0.3 那天的待办挺长的：给 telegram bot 的 onboarding 流程加分级输入验证，部署，根据实际使用的反馈调限制，更新六个文档，写 changelog，打 v0.0.3 的 tag，跑一遍完整代码审计，把审计发现的问题全修掉，最后全部推到生产。这一堆活从头到尾大概用了 26 分钟，因为有三种完全不同的协作模式同时在跑。具体是怎么回事，我按模式一个一个讲。
模式一：我说哪里不对，看着它改
session 是从一个很具体的需求开始的：给 Mio 的 onboarding 流程加输入验证。bot 会问用户昵称、爱好、性格偏好，全是自由文本输入，之前共享一个 500 字的上限——也就是说昵称字段能输 500 个字，这个挺离谱的。
我把需求跟 cc 说了。它读了 onboarding 的代码，把所有输入字段找出来，做了一个双层方案：SHORT_INPUT_KEYS 里的字段（昵称、爱好）限 50 字，其他长文本字段保持 500。然后 build docker 镜像、push registry、部署到 cloud run，revision 44。从读代码到实现到部署，大概 14 分钟。
这就是直接模式：我和它在同一个问题上结对，机械性的活（docker build、gcloud run deploy）它干，设计决策我出。
500 → 50 → 10 → 6
部署完我去线上测了一下。50 字对昵称还是太多，而且空白输入没有被拦。我直接说：
"50 chars feels too much for name.. doing a one fit all max is bad, also validate blanks"
它马上调整，不用双层方案了，改成按字段配置：昵称 10 字，风格/性格选项 30 字，爱好 50 字，长文本 500。空输入会被弹回来，附一句「不能空着哦~」。build、push、deploy，revision 45。从我说出反馈到新版本上线，大概两分钟。
然后我又看了一眼昵称那个 10 字。中文名字一般就 2-4 个字，昵称也很少超过 6 个，10 还是多。
"max 10 char seems still a lot for chinese chars?"
改成 6，再部署一次。revision 46。
昵称上限就这样走了四个阶段，500 → 50 → 10 → 6，每一轮从「这不对」到「上线了」大概两分钟。不用提 ticket 等下个 sprint 再去 staging 环境验，我说哪里不对、看着它修、上线、我再测。三次生产部署都是在这段对话里顺手做完的。
模式二：踢个任务出去，自己继续干
昵称限制还在改（10 → 6 那一轮）的时候，文档的活也在等着：六个 docs 文件、一条 changelog、一个 v0.0.3 的 git tag。文档这种活最容易变成「回头再补」，然后一直没补。
我说了一句：
"spawn subagent to update all docs in docs/, todo, etc, and update changelog and tag v0.0.3 release"
cc 起了一个后台 agent，然后回来继续跟我讨论昵称限制。那个后台 agent 自己在读文档、更新六个文件、写 changelog、打 tag——同一时间我还在主 session 里迭代实现。
几分钟后它汇报：六个文档更新完、changelog 写好、v0.0.3 tag 打了。有个小偏差：它写进文档的还是旧的 10 字限制，因为它跟最后那轮改动是并发跑的，它先跑完了。这种记下来回头改一下就行，不算什么问题。
后台模式的判断标准很简单：不需要我盯着的活，就踢出去，我接着干主线。有点像你把一个 CI pipeline 踢出去跑，自己继续写代码，只不过这次跑 pipeline 的是个 agent。
模式三：给个目标，让它自己收敛
实现做完了，文档也在更了，接下来是完整的代码审计——不是随便扫一眼，是彻底审一遍并且把问题修掉。
"spawn agent team to do full review and audit of current codebase, then fix any issues. Do this iteration until review agent cannot find issues"
cc 建了一个小团队：一个审查 agent，一个修复 agent，用依赖链串起来，然后开始迭代。
- 第一轮：审查 agent 扫了整个 codebase，出了 22 条发现，安全、可靠性、正确性的问题都有。修复 agent 接手，解决 21 条，剩一条搁置——内存累加器的批处理效率优化，LOW 优先级，属于合理的技术债。
- 第二轮：审查 agent 在修复后的 codebase 上重新跑，找出 3 个新问题，都是第一轮修复引入或者暴露出来的。修复 agent 全修了。
- 第三轮：最终验证，没有新问题，结论 APPROVED。
三轮下来，25 个问题解决了 24 个。剩那条是性能优化，不是 bug 也不是安全风险，现在改它增加的复杂度不值。
团队模式里我给的只是一个目标——审到干净为止——agent 怎么建、依赖链怎么设、迭代几轮，全是它自己的事。整个过程我没看任何中间结果，只看了最后的总结。
这次跟第五篇那次审查的区别在迭代。那次是单次的：四个审查员找问题，三个修复员修完，结束。这次审查 agent 会回头检查修复 agent 的工作，发现漏的，修复 agent 再修，一直迭代到找不出新问题才停。
三种模式是怎么叠在一起的
实际的时间线是这样的：
0:00 开始实现输入验证
├── 直接模式：读代码，实现分级限制
14:00 部署 revision 44
├── 直接模式：用户测试，给反馈
├── "50 字太多了，要拦空白"
16:00 部署 revision 45（按字段限制 + 空白拦截）
├── 直接模式：继续反馈
├── "10 个字对中文名还是太多"
├── 后台模式：文档 agent 启动 ← 并发
17:00 部署 revision 46（昵称 → 6 字）
├── 后台 agent 还在跑文档/changelog
19:00 后台 agent 完成（6 个文档、changelog、v0.0.3 tag）
├── 团队模式：审查团队启动 ← 并发
├── 第一轮：22 条发现 → 修复 21 条
├── 第二轮：3 条新发现 → 全部修复
├── 第三轮：验证通过 → APPROVED
26:00 全部提交、推送、gh release 创建完毕
我跟主 session 结对的时候，文档 agent 在后台跑；审查团队自己迭代的时候，我在处理发布的事务。实现和文档是重叠着做的，边改代码边让后台 agent 更文档；审查那一段完全自治，团队自己转，我不用管。
传统串行流水线（1-4 天）被压缩成上下重叠的并行流（约 26 分钟）的机制。
发布
审查团队 approve 之后，提交、推送：
git push origin main --tags
gh release create v0.0.3 --title "v0.0.3: Multimodal Input, Enhanced Onboarding, Selfie Generation"
从第一行代码到 github release，一个 session。这次的产品视角我单独写了一篇，这篇就只讲工作流。
最后说一下什么活用什么模式。直接模式的反馈循环最紧，我说哪里不对马上就能看到变化，像昵称限制那种一轮两分钟的迭代也只有它做得到——代价是它一直吃我的注意力，整个过程我得看着。文档这种不用盯的活就走后台模式，起个任务就可以忘掉它，做完了它会来汇报，中途没法给反馈也无所谓。审查那种要反复迭代的适合团队模式，给个目标它自己收敛就行，不过快速小改用它就太重了。
三种协作模式的对比：直接结对反馈最紧但要盯着、后台委派可以忘掉它、团队循环给个目标自己收敛。
反正没有哪个模式能覆盖所有场景，真正好用的是在同一个 session 里随手切换，有时候两三种同时跑。第四篇讲 agent team 的时候展示过并行执行，这篇再往前一步：结对、后台委派、自治循环，全部同时进行。
跑下来我的感觉是，机械性的活全部让 agent 干了以后，我做的基本只剩决策，不碰执行：做什么、限制设多少合适、什么时候发布。现在慢的反而是我拿主意这一环，不是执行那一环。
