最近我把一套原本只服务于某个项目的多 Agent 工作流，慢慢整理成了一个更独立的小工具。
它一开始并不是为了做成什么正式的软件。更准确地说，它是从很多次混乱里长出来的。
一个 Agent 写完 plan，另一个 Agent 去 review；Codex 执行 task，Claude Code 或 Cline 再看一遍；测试结果出来以后，又要判断到底是代码有问题、测试条件不足，还是只是证据不够完整。
这些事情单独看都不复杂。可是当它们叠在一起，文档变多，对话变长，测试又反复回到同一个问题时，单靠一个对话窗口就很难稳稳地走下去。
所以这套系统真正想解决的，不是让某一个 Agent 突然变得无所不能。
它更像是在给多个 Agent 铺一张桌子：每个人都知道自己现在该看什么、该写什么、哪里已经通过、哪里还不能假装完成。
不是让 AI 更聪明，而是让过程更稳
我越来越觉得，复杂任务里最容易出问题的地方，不一定是 Agent 不会写代码。
更多时候，是上下文太长以后，它开始忘记前面的约束；或者一个方案看起来已经合理，就太快收敛；又或者某个边界条件其实还没有验证，却在对话里被轻轻带过去了。
单个 Agent 很容易给出一个“看起来可以继续”的答案。可复杂问题真正需要的，往往不是一个立刻继续的答案，而是一个能被反复检查、能被别人质疑、也能把分歧留下来的过程。
于是我把工作拆成几个阶段：plan、task、review、test case、execution result、blocker。
每个阶段都有自己的入口和状态。不是靠“我记得这个已经做完了”，而是让文件、SQLite 状态和 dashboard 一起告诉我：它现在到底在哪里。
Plan 和 Task：让想法先落到地上
Plan 负责把要做的事说清楚。
它不是一句“实现某某功能”，而是要写出为什么做、做什么、不做什么、有哪些风险、之后怎么验证。
Task 则记录真正执行时发生了什么。哪些文件被改过，哪些行为被验证过，哪些内容虽然提到了但没有在这次完成。
这样做的好处是，Agent 不会只在对话里完成工作。它必须把自己的判断留下来，交给后面的 review 和 resolution 继续接住。
Review：让不同视角彼此补上
这套系统里，review 不是一个装饰性的“LGTM”。
不同 Agent 会从不同角度看同一个文件。有的更容易注意架构和语义一致性，有的更容易盯住实现细节，有的会把接口契约和回归风险看得更重。
重点也不是简单投票。
我更在意的是：它们指出的问题有没有证据，哪些是阻塞项，哪些只是非阻塞建议，哪些风险可以接受，哪些必须回到 plan 里重新处理。
当多个 Agent 的看法不一样时，这些分歧不应该消失在聊天记录里。它们应该进入 review 文件，进入主文件的 notes，进入后续的 task 或 blocker。
Test 和 Blocker：不要让失败一直绕圈
测试流程是后来让我最明显感到需要整理的部分。
一开始，测试失败以后很容易进入一种循环：生成 plan，执行 task，重新测试，又失败，再生成新的 plan。
看起来每一步都在推进，但其实同一个问题可能被换了名字，绕了好几圈。
后来我把测试结果从单独的主线里拿出来，让它变成证据；真正驱动问题收敛的是 blocker。
一个 blocker 对应一个还没有满足通过条件的问题。它会记录相关测试用例、失败原因、根因分类、下一步动作、关联 plan、验证证据和最终关闭方式。
如果这次验证仍然失败，就更新同一个 blocker，而不是马上再创造一个新的问题。
只有当根因真的变了，才开新的 blocker。
这件事很重要。它让系统不再用文档数量制造“正在前进”的错觉，而是迫使问题在同一个位置慢慢变清楚。
Dashboard：让状态从文件里浮出来
文件和 SQLite 能保存状态，但人需要一个更容易看的入口。
所以后来有了 dashboard。
它不只是显示完成了多少、等待 review 多少，也会把真正需要交给 Agent 处理的入口放出来：哪个 plan 等待审查，哪个 task 等待 resolution，哪个 blocker 需要继续处理，哪个测试用例应该由 Agent 执行，哪个又应该交给我人工验收。
这让我少了很多“我现在到底该复制哪段提示词”的犹豫。
更重要的是，它把一堆分散在目录里的状态变成了一个可以扫一眼的工作台。
它真正带来的变化
这套系统并不会让开发变得完全自动。
我反而越来越觉得，好的 Agent 工作流不应该假装人不存在。
有些事情适合 Agent 做，比如读文档、生成计划、跑接口级测试、整理 review 结论。
有些事情必须由人判断，比如页面手感、业务口径、风险是否接受、外部服务是否可以真的触发。
系统需要做的是把这些边界说清楚，而不是让 Agent 在没有条件的时候假装已经完成。
所以它的核心作用，其实是把复杂问题变成一条可以停下来、回头看、再继续走的路。
当单个 Agent 处理得不够稳时，可以让另一个 Agent 看一遍。
当 review 意见不一致时，可以把分歧留下来。
当测试失败时，可以让 blocker 接住，而不是让问题散成更多文件。
当我自己需要介入时，也能知道现在介入的是哪一个环节，而不是从一整段聊天记录里重新找线头。
写在最后
这套工具现在还很小，也带着很多从实际项目里长出来的痕迹。
但我喜欢它的方向。
它不是一个宏大的自动开发平台，而是一套更安静的协作秩序：让 Agent 不必靠猜，让人不用一直记，让复杂问题不会在反复重测和反复 review 里散开。
如果说它解决了什么，我想不是“让 AI 更聪明”。
而是让 AI 的工作过程更可控、更可追踪，也更容易在困难的地方慢慢收束。
这对我来说，已经是很重要的一步了。
No comments yet.