我是怎么用 Paseo + Beads 搭了一个会烧 token 的软件开发 Agent Team（三）
上一篇里，我讲了第二版 Agent Team 的问题。
第二版里，我一度试图把 Agent Team 拆成一个很像真实软件公司的组织：产品经理、项目经理、架构师、前端、后端、数据库、测试、Reviewer、Release Manager，甚至还要考虑 worktree 合并和版本管理。
这个设计一开始看起来很完整。因为真实的软件团队就是这样协作的。需求有人澄清，任务有人拆分，架构有人把关，开发有人实现，测试有人验证，Reviewer 检查代码，Release Manager 管版本和发布。
但真正跑起来之后，我发现一个问题：Agent Team 不能简单照搬人类公司的组织结构。人类团队里的角色，不只是一个职位名称。它背后还有经验、默契、边界感和组织习惯。一个人知道什么时候该提建议，什么时候该拍板，什么时候该停下，什么时候不应该越界。Agent 没有这些默认共识。它不一定真正理解这个角色在团队中的边界。结果就是，角色越多，系统看起来越专业，但协作成本也越高。
所以第三版，我开始做减法。
从完整组织，回到最小闭环
第二版给我最大的启发是：Agent Team 的目标不是模拟一个真实公司，而是稳定完成一次软件交付。这两个目标是不一样的。
模拟真实公司是根据角色定义，但如果目标是完成一次软件交付，那问题就变成了以交付环节定义。那么就可以将交付环节简单分为三个：需求要被澄清、拆分和分配；代码要被实现；结果要被测试和反馈。也就是说，真正需要稳定下来的，不是一个完整的组织架构，而是一个交付闭环。
所以第三版里，我把 Agent Team 收敛成了三个核心角色：
一个 Manager Agent，负责澄清需求、拆分任务、分配 Issue，并把对应的 context 发给对应 Agent。
一个 Developer Agent，负责根据明确的 Issue 和 context 实现代码。
一个 Tester Agent，负责测试、验证、发现 Bug，并把新的问题写回 Beads。
Manager Agent：把入口收敛起来
第一版最大的问题，是入口在我身上。需求澄清、任务拆分、Issue 描述、优先级判断、context 补充，都需要我来做。Agent 虽然可以干活，但整个流程的上游还是手工的。
第二版里，我把这些事情拆给了多个角色，但角色太多之后，又出现了协调混乱。
所以第三版里，我做了一个反向选择：不再把澄清、拆分、分配拆成多个 Agent，而是把它们合并到一个 Manager Agent 里。这个 Manager Agent 的职责非常明确：它不是一个”什么都管”的老板，而是整个任务流的入口和调度器。
它要做的第一件事，是把模糊需求变成可以执行的任务。很多时候，我给出的需求并不是一个天然可执行的 Issue。它可能只是一个想法，一个方向，甚至只是一句”这里好像不太对”。如果直接把这种内容交给 Developer Agent，结果通常不会太稳定。所以 Manager Agent 需要先澄清需求，判断这个需求到底是什么类型：是新功能，是 Bug，是重构，还是测试反馈。
然后，它要把需求拆成合适的 Issue，写进 Beads 里。这里的关键不是把任务拆得越碎越好，而是拆到 Agent 可以明确执行。一个 Issue 最好有清楚的目标、边界、相关上下文和验收方式。否则 Developer Agent 拿到以后，就很容易自己脑补，最后做出一个看起来很努力、但方向不对的结果。
Manager Agent 的第三个职责，是分配任务。它需要判断这个 Issue 当前是否可以做，是否依赖其他 Issue，是否应该先测试，是否应该等另一个功能完成之后再处理。然后，它再把任务和对应 context 一起发给 Developer Agent。
这样一来，Developer Agent 不再只是从 Beads 里看到一个孤立的 Issue，而是拿到一个经过整理的工作包。这个工作包里应该包含：为什么要做这个任务，相关背景是什么，涉及哪些文件或模块，和其他 Issue 有什么关系，以及做到什么程度算完成。
Developer Agent：只负责把任务做完
第二版里，开发相关角色被拆得很细：前端、后端、数据库、架构师，有时候还会有 Reviewer 来介入。这样做的问题是，一个真实功能往往天然跨多个层次。前端改动可能牵涉接口，后端改动可能牵涉数据库，数据库变化又可能影响测试和版本。如果角色拆得太细，每个 Agent 都会盯着自己那一块，但功能本身不一定能顺畅地完成。
所以第三版里，我没有继续强调前端 Agent、后端 Agent、数据库 Agent 的细分，而是先把它们收敛成 Developer Agent。Developer Agent 的核心职责只有一个：在给定 context 和 Issue 边界的情况下，把任务实现出来。
它不负责重新定义需求，不负责重新规划整个版本，不负责决定哪些任务优先级更高，也不应该随意扩大自己的修改范围。
第三版里，我更希望 Developer Agent 像一个拿到清晰任务的执行者。它可以探索代码，可以提出疑问，可以在必要时反馈任务不清楚，但它不应该自己把一个 Issue 重新定义成另一个 Issue。
如果它在开发过程中发现了新问题，最好的方式不是直接扩大范围，而是把问题反馈给 Manager Agent，或者写回 Beads，进入下一轮任务流。这让开发行为变得更可控。
Tester Agent：让反馈重新进入系统
第三个核心角色是 Tester Agent。
第一版里，测试已经存在，但更多像是开发之后的一个动作。Agent 做完以后跑一跑测试，如果发现 Bug，就写回 Beads。到了第三版，我开始更明确地把测试当成整个闭环的一部分。
因为对 Agent Team 来说，测试不只是为了确认代码有没有问题，它还是整个系统继续迭代的反馈入口。
Developer Agent 完成任务之后，Tester Agent 要负责验证结果。它需要看这个 Issue 是否真的完成，是否满足验收标准，是否引入新的 Bug，是否有明显的边界情况没有覆盖。
如果测试通过，任务就可以进入下一步验收。如果测试失败，Tester Agent 要把问题重新写回 Beads，形成新的 Bug Issue。然后 Manager Agent 再判断这些 Bug 的优先级，把它们重新分配给 Developer Agent。
这样，一个循环就形成了：Manager Agent 澄清和分配任务，Developer Agent 实现任务，Tester Agent 验证结果，测试发现的问题写回 Beads，Manager Agent 再次整理、判断和分配。
这时候，Beads 不只是一个 Issue 列表，而是整个 Agent Team 的状态中心。任务从这里进入，结果在这里更新，Bug 在这里反馈，下一轮迭代也从这里开始。这个 loop 比第一版更完整，也比第二版更简单。
Release 被放到了最后
第三版里还有一个很重要的变化：我不再一开始就让 Release 绑定所有任务。
第一版的入口是 Release。先定义版本，再拆 Issue，再让 Agent 去做。这个思路非常符合传统软件开发习惯，但在 Agent Team 里，它有时候会显得太硬。因为 Agent 的任务推进速度很快，中间发现的问题也很多。如果一开始就把所有任务都绑死到某个 Release 里，临时 Bug、优先级变化、依赖调整都会变得很别扭。
第二版里，我试图通过 Release Manager Agent 来管理这个复杂度，但后来发现，这又引入了新的角色和新的协调成本。
所以第三版里，我更倾向于把 Release 放到后面。也就是说，前面的核心是让任务闭环稳定跑起来，循环几轮之后，再根据当前已经稳定下来的任务集合，判断哪些内容可以组成一个 Release。
这样一来，Release 不再是所有任务的起点，而更像是一个阶段性的快照。它不是用来提前锁死所有任务，而是用来在任务流稳定之后，做一次整理、合并和发布判断。
为什么三个角色反而更稳定
对 Agent Team 来说，最重要的不是角色覆盖面，而是责任边界清不清楚。三个角色虽然少，但边界非常明确。这三个角色刚好对应一次交付里最核心的三个动作：理解、实现、验证。这三个角色是围绕交付闭环收敛出来的。
至于架构、Review、Release 这些事情，并不是不重要，而是不一定要先变成独立 Agent。架构可以先作为 Manager Agent 在拆分任务时需要考虑的约束。前端、后端、数据库也可以先作为 Developer Agent 处理任务时的不同工作区域，而不是一开始就拆成多个角色。Review 可以先作为 Tester Agent 或人工验收的一部分。Release 可以先放到最后，由人和系统一起判断当前任务集合是否足够稳定。而且每一个 agent 都可以定义多个 skill，来让它完成复合型的任务。
这套结构也可以迁移到其他任务
虽然这三篇讲的是软件开发，但是这套思路不只适用于写代码。很多复杂任务其实都有类似的结构。
比如写文章，也可以有类似的流程：一个 Agent 负责澄清主题和拆大纲，一个 Agent 负责写初稿，一个 Agent 负责审稿和提出修改意见。
做市场调研也可以这样：一个 Agent 负责定义调研问题和拆分方向，一个 Agent 负责收集和整理信息，一个 Agent 负责检查证据质量和输出结论。
甚至企业内部很多流程，本质上也都是这样的闭环：需求进入、任务拆分、执行推进、结果验证、问题反馈、再次迭代。
所以我现在越来越觉得，多 Agent 协作的关键并不是”多”，而是”协作结构”。多个 Agent 同时工作不一定就是 Agent Team。只有当它们围绕同一个任务系统，有稳定的职责边界，有清晰的反馈循环，才算是真正形成了 Team。
回头看这三版
回头看这三版，其实是一个不断收敛的过程。
第一版，我关注的是任务系统。
我用 Release、Issue、Dispatcher 和 Agent，把多个 Agent 串进一个可以运转的开发循环里。它证明了多 Agent 协作不是空想，但也暴露出任务澄清和上下文组织的问题。
第二版，我关注的是角色分工。
我试图把真实软件团队里的角色映射到 Agent Team 里，让产品、项目、架构、开发、测试、Review、Release 都有对应的 Agent。它解决了一部分 context 传递问题，但也带来了角色过多、边界不清和协调复杂度上升的问题。
第三版，我关注的是最小闭环。
我不再追求完整组织，而是把 Agent Team 收敛成 Manager、Developer、Tester 三个角色，让需求澄清、代码实现、测试反馈形成一个稳定循环。
这也是我现在对 Agent Team 的一个基本判断：Agent Team 不是把一堆 Agent 放在一起，也不是复制一个人类公司。它更像是在设计一个可以不断吸收任务、执行任务、验证结果、反馈问题的工作流系统。
毕竟，Agent Team 的目标不是看起来像一个团队，而是真的能把事情做完。