上一篇写多 Agent 协作时，我还只是把 plan、task 和 review 放进一个比较安静的文件状态机里。那时问题还集中在“计划写完以后谁来审”“task 完成以后放到哪里”这些事情上。
后来项目继续往前走，测试、联调、回归、缺陷修复都慢慢加入进来。流程也不再只是 plan -> task 这么短的一段路，而变成了一条会绕回来、会留下证据、也会提醒人不要太快把事情说成完成的路。
这篇就整理一下现在这套生命周期。它仍然很朴素：目录表示阶段，文件标记表示状态，review 标记表示结论。只是这一次，它不只服务于开发，也服务于测试和修复闭环。
先说整体形状
现在文档体系大概分成五块：
development-plans # 要做什么，为什么做
development
ready
complete
development-tasks # 怎么做，做了什么
development
complete
test-cases # 怎么验证
development
ready
complete
tests # 验证结果、缺陷、回归和总结
execution-results
defects
summaries
final-reviews # 阶段性质量门禁我越来越觉得，Agent 协作里最重要的不是让每个 Agent 都变聪明，而是让它们少猜一点。
文件在哪里，就代表它现在处于哪个阶段。文件末尾有什么标记，就代表它能不能被下一个 Agent 处理。review 文件有没有写完、结论是什么，也都用统一标记表达。这样一来，人和 Agent 都不用在一堆文档里凭感觉判断。
Plan：先把要做的事说清楚
Plan 是开发前的设计文档。它负责回答：为什么要做、做什么、不做什么、风险在哪里、完成后怎么验证。
development-plans/development
- 正在规划
- 等待 plan review
- 等待修复 plan review
development-plans/ready
- plan review 已通过
- 等待开发
development-plans/complete
- 对应 task 已完成
- task review 已通过plan 文件的状态标记也很直接：
<!-- PLAN_STATUS: READY_FOR_REVIEW -->
<!-- PLAN_STATUS: READY_FOR_DEVELOPMENT -->
<!-- PLAN_STATUS: DEVELOPMENT_COMPLETED -->对开发 Agent 来说，它不需要翻所有计划，只需要看 development-plans/ready。那里就是“已经被审过，可以开始做”的入口。
Task：把实现过程留下来
Task 是真正开发时的执行记录。它不是单独漂在外面的 todo，而是从 ready plan 出发，记录实现做了什么、改了哪些文件、怎么验证。
development-tasks/development
- 正在开发
- 等待 task review
- 等待修复 task review
development-tasks/complete
- task review 已通过
- 开发完成归档task 的状态比 plan 更短：
<!-- TASK_STATUS: READY_FOR_REVIEW -->
<!-- TASK_STATUS: REVIEW_APPROVED -->当 task review 通过后，task 进入 complete，对应的 plan 也会从 ready 移到 complete。这样一件开发工作才算真正从计划走到实现。
Review：不要把“写完了”和“通过了”混在一起
review 文件现在都使用双标记：
<!-- REVIEW_STATUS: READY_FOR_RESOLUTION -->
<!-- REVIEW_RESULT: APPROVED | APPROVED_WITH_NOTES | CHANGES_REQUESTED -->REVIEW_STATUS 只表示 reviewer 写完了，resolution agent 可以读取。REVIEW_RESULT 才是结论。
这两个标记拆开以后，很多误会会自然消失。review 文件存在，不代表 review 已经完成；review 完成，也不代表它通过了。只有两件事都清楚，后续的 resolution 才能继续。
Test Case：先审测试设计，再执行
测试用例也有自己的生命周期：
test-cases/development
- 测试用例编写中
- 等待测试用例 review
- 等待修复测试用例 review
test-cases/ready
- 测试用例 review 通过
- 等待执行
test-cases/complete
- 该用例所需的 API / Browser / Regression 验证都完成这里有一个很容易误解的点：单个 API 执行结果通过，并不一定代表测试用例可以归档。
如果一个测试用例要求 API 和 Browser 都验证，那么 API 通过以后，它仍然应该留在 test-cases/ready。只有它需要的范围都完成，并且没有相关 defect、没有待处理 plan，才进入 test-cases/complete。
Test Result：从 run 级归档改成文件级 resolution
这是最近最大的变化。
一开始我把测试执行结果按 run 管理。每次执行创建一个 runs/<run-id>，等整个 run 全部通过以后再移动到 complete。这个规则看起来整齐，但实践里很快变得笨重。
一个 run 里可能有几十上百个结果：有的已经 PASS 并且三方 review 通过，有的还缺 Claude review，有的结果本身是 BLOCKED，有的虽然 PASS 但 review 要求补证据。它们全混在一个目录里时，run 就像一张越堆越满的桌面。
所以现在改成文件级 resolution：
tests/execution-results/api/runs/<run-id>/...
tests/execution-results/api/planned/<run-id>/...
tests/execution-results/api/complete/<run-id>/...
tests/execution-results/browser/runs/<run-id>/...
tests/execution-results/browser/planned/<run-id>/...
tests/execution-results/browser/complete/<run-id>/...
tests/execution-results/regression/runs/<run-id>/...
tests/execution-results/regression/planned/<run-id>/...
tests/execution-results/regression/complete/<run-id>/...单个 execution result 文件在三方 review 完成后，就可以立刻分流：
- PASS + 三方 review 通过：result 文件和三份 review 一起进入
complete。 - FAIL / BLOCKED / PARTIAL_PASS：进入
planned，作为后续 plan/task 的证据。 - PASS 但任一 review 是 CHANGES_REQUESTED：也不能算通过，进入
planned。 - 缺少任一 review：继续留在
runs。
这样 run 不再是“全部完成才能动”的大箱子，而只是一次执行批次。真正流转的单元，是每一个测试结果文件。
为什么失败结果 review 通过，也不等于测试通过
这里还有一个细小但很重要的判断。
如果某个结果是 FAIL、BLOCKED 或 PARTIAL_PASS，三方 review 都通过了，这只说明一件事：这个失败、阻塞或部分通过的记录是可信的。
它不代表测试通过。
所以这种文件不会进入 complete，而是进入 planned。后续会生成新的 test result fix plan，再经过 plan review、task 修复、task review，最后重新执行测试或回归测试。
Defect：问题不要长期停在 test 里
测试发现的问题会进入 defect 流程：
tests/defects/open
- 问题已确认或需要处理
- 尚未进入 plan
tests/defects/planned
- 已经转成 development plan
- 等待或正在修复
tests/defects/closed
- 对应 plan/task 完成
- regression 通过defect 不负责实现修复。它更像一张证据卡片：问题是什么、来自哪个测试、影响是什么、建议怎么验证。
真正的修复仍然回到 plan/task。等 task 完成并通过 review，再通过 regression 把 defect 关掉。测试流程就这样绕回来了。
Regression：让修复回到证据里
当 test-fix task 完成以后，不能只说“代码已经改了”。还要重新验证它真的解决了原来的问题。
test result review
-> test-fix plan
-> plan review
-> task development
-> task review
-> regression execution
-> regression result review
-> defect closed这就是我说的“会回头的路”。流程不是一直向前冲，而是在修复之后回到测试证据里，确认原来的洞真的被补上了。
每次 resolution 都新建 plan
最近我还加了一条看似啰嗦、实际很必要的规则：test result review resolution 每次都必须新建 plan。
因为同一天、同一个 run，可能会经历很多次 resolution。如果一直写进同一个 2026-06-04-browser-initial-run-test-result-fix-plan.md，上下文会越堆越乱，也很难知道某一轮 resolution 到底处理了什么。
现在命名会带上时间和问题组：
2026-06-05-1430-api-auth-evidence-test-result-fix-plan.md
2026-06-05-1430-browser-initial-run-route-evidence-test-result-fix-plan.md旧 plan 可以被引用，但默认不再被直接改写。这样每一轮 resolution 都像一张新的照片，记录当时看到的问题，而不是把很多时刻揉成一团。
为什么后来回到 Windows 客户端
中间我也尝试过用命令行脚本批量启动 Claude Code、Cline 和 Cursor。它能跑，但慢慢变得不太适合这个阶段。
因为现在流程依赖的已经不只是“执行一个命令”：它需要权限确认、插件能力、浏览器证据、文件移动、review 读取、计划生成，还需要在不确定时停下来让人确认。Windows 客户端在这些地方更自然。
所以现在标准方式又回到了客户端：打开对应 workflow prompt，复制给目标 Agent，让它在自己的上下文里执行。脚本被归档，只保留为历史参考。
监控面板：让状态从文件里浮出来
这套流程虽然靠文件系统运转，但人不应该每天只靠手翻目录生活。
所以项目里还有一个本地的 License Refactor Workflow Dashboard。它会扫描当前文档状态，把 plan、task、test case 和 test result 分成几类展示出来：
- 已完成
- 等待解决
- 等待评审
- 待处理评审结论
它的作用不是替代生命周期，也不是替代 Agent。它更像一盏台灯，把文件状态机里散落的状态照出来。
比如某个 plan 缺 Claude、Cline、Cursor review，面板会直接显示。某些 test result 已经进入 complete，某些还等 resolution，也可以通过面板看到。这样人不用一直问“现在到底卡在哪里”，而是可以先看一眼整体，再决定把哪段 prompt 交给哪个 Agent。
现在这条路长什么样
plan development
-> plan review
-> plan ready
-> task development
-> task review
-> task complete
-> plan complete
complete plan/task
-> test case generation
-> test case review
-> test case ready
-> api / browser execution
-> result review
-> file-level resolution
clean PASS
-> execution-results/.../complete
needs fix / needs decision / non-pass
-> execution-results/.../planned
-> new test-fix plan
-> task fix
-> regression
-> defect closed它看起来比最初复杂了很多，但复杂的部分并不是为了炫技。它只是把真实开发里本来就存在的事情显式写出来：计划、开发、测试、失败、修复、回归、关闭。
结尾
我现在越来越相信，和 Agent 一起开发时，文档不是附属品，而是协作本身。
如果文档没有生命周期，Agent 会迷路，人也会迷路。已经完成的东西会被重新处理；失败的结果会被误认为通过；review 写完和 review 通过会混在一起；测试发现的问题会停在原地，没人知道它什么时候应该进入开发。
把这些都放进目录和标记里以后，事情会慢下来一点，但也会稳下来一点。
每个文件都知道自己在哪里。每个 Agent 都知道自己该看什么。每次失败都能回到 plan/task，再回到 regression。面板负责把这些状态照出来，而人只需要在关键地方做判断。
这条路不短，但它终于是能回头、能检查、也能继续走下去的路。
No comments yet.