我是怎么用 Paseo + Beads 搭建了一个软件开发 Agent Team（二）

上一篇里，我讲了第一版 Agent Team 是怎么跑起来的。 最开始的流程其实很朴素：我先定义一个 Release，再把它拆成 Feature 和 Bug，写进 Beads 里。然后通过 Dispatcher，把这些 Issue 分配给不同的 Agent 去开发、测试、修复。 这套流程跑起来之后，Agent 写代码这件事，不再只是”我和一个 AI 对话”，而是有点像在调度一个小型开发队列。 但第一版也很快暴露了一些问题：首先，整个系统的入口还是我，需求要我来澄清，任务要我来拆，Issue 要我来写，优先级要我判断，背景信息也要我补充。Agent 的确可以领取任务，也可以修 Bug，但它们能不能正确行动，仍然取决于我有没有把前置工作做得足够细致，边界足够清楚。 第一版看起来已经有了自动循环，但它的上游还是高度依赖我的效率。 所以我开始着手做第二版，既然开发任务可以交给 Agent，那需求澄清、任务拆分、上下文整理、版本管理这些工作，是不是也可以交给 Agent？

第二版：把 Agent Team 拆成一个软件团队

既然人类软件开发不是一个人完成的，而是由产品、项目经理、架构师、前端、后端、测试、Reviewer、Release Manager 等角色一起协作，那 Agent Team 是不是也可以这样设计？

于是，我开始把第一版里压在自己身上的工作拆出去：

• 产品经理 Agent 负责把模糊需求澄清成更明确的需求。
• 项目经理或者 Manager Agent 负责拆分任务、管理 Issue、判断优先级，并把任务分配给对应的 Agent。
• 架构师 Agent 负责看整体技术方案、模块边界和实现路径。
• 前端 Agent 负责页面、交互和接口对接。
• 后端 Agent 负责接口、业务逻辑和服务层。
• 数据库 Agent 负责 schema、迁移和数据结构。
• 测试 Agent 负责验证功能、发现 Bug，并把 Bug 写回 Beads。
• Reviewer Agent 负责代码审查。
• Release Manager Agent 负责版本节奏、worktree 合并和发布相关的事情。

这样一来，它就不再像几个 Agent 在 Beads 里抢 Issue，而更像一个被拆出来的软件开发组织。它看起来终于从”任务分发”变成了”团队协作”。

第二版里，我希望 Manager Agent 能成为新的调度中心。它不仅负责把 Beads 里的 Issue 分给不同 Agent，还负责把相关 context 一起整理出来，发给对应的 Agent。这一步其实很重要，因为第一版里有一个很大的问题：Agent 有时候只看到一个孤立的 Issue，却看不到这个 Issue 背后的背景。

到了第二版，这个问题在一定程度上被缓解了。因为 Manager Agent 可以把需求背景、相关 Issue、依赖关系、当前版本目标，一起打包给具体执行的 Agent。也就是说，Agent 不再只是拿到一句”去修这个 Bug”，而是能拿到更完整的上下文：这个 Bug 是怎么来的，它和哪个 Feature 有关，当前版本里哪些东西不能动，做完以后应该满足什么标准。并把所有的内容都落实成文档。

但新的问题又出现了。

角色越多，系统越像一个组织，也越像一个组织问题

第二版跑起来之后，我很快发现一个问题：角色拆得越细，系统看起来越专业，但协作本身也变得越来越复杂。

一开始我以为，只要给 Agent 定义好角色，它就能像人类团队里的对应角色一样工作。但是人类团队里的”角色”，除了任务的领取和执行，还有一个非常重要点就是知道什么是合适的”时机”。一个产品经理知道什么时候应该澄清需求，技术人员也知道什么问题是需要再去跟产品经理去沟通需求合理性的；一个架构师知道什么时候应该给方案，而不应该亲自下场乱改代码；一个 Reviewer 知道自己的重点是审查，并且也应该知道这个问题应该转给那个环节的负责人去调整。

这些东西不是写在职位名称里的，而是来自长期的软件工程经验、团队协作习惯和组织默契，但 Agent 没有这些默认共识。你告诉它”你是架构师 Agent”，它确实会开始用架构师的口吻思考问题。 你告诉它”你是 Reviewer Agent”，它也会开始检查代码质量。你告诉它”你是 Release Manager”，它会去关注版本和合并。

但问题是，它不一定真的理解这个角色在整个团队里的边界和真正的职责流程。它知道自己叫什么，不等于它知道自己什么时候该介入，什么时候该停下。于是第二版里开始出现一些混乱。

典型混乱：大家都在帮忙，但边界不清

第二版里最典型的一种混乱，是多个角色都想插手同一个问题。

比如一个 Feature 需要改前端页面，也需要改后端接口，还涉及一点数据库结构调整。按照理想流程，产品经理 Agent 应该先澄清需求，Manager Agent 拆分任务，架构师 Agent 判断整体方案，然后前端、后端、数据库 Agent 分别实现，测试 Agent 验证，Reviewer Agent 审查，最后 Release Manager Agent 处理合并和版本。但真实跑起来之后，事情往往不是这样。

产品经理 Agent 可能在澄清需求时，顺便给出了实现方案。架构师 Agent 看了以后，可能认为这个方案不够好，于是重新拆了一遍技术路径。Manager Agent 又需要决定到底按照产品经理的拆法，还是按照架构师的拆法。前端 Agent 拿到任务后，发现接口不够用，开始建议后端怎么改。后端 Agent 觉得这个需求其实应该调整数据库。数据库 Agent 又认为这次变更会影响后续版本。Reviewer Agent 审查时，可能提出一组新的修改意见。Release Manager Agent 最后合并 worktree 时，又发现几个 Agent 改到了相同的地方。

每个 Agent 都在努力完成自己的任务，但因为角色边界不够稳定，整个系统反而开始产生额外的协调成本。人类团队里也会有这种问题。一个角色太强势，另一个角色越界，或者项目经理没有把决策权说清楚，都会导致协作变慢。但在人类团队里，大家至少会慢慢形成默契。而在 Agent Team 里，如果这些边界没有被显式设计出来，它们不会自动形成。

角色不是越多越好，Agent team的颗粒度不该太细

一开始，我之所以把角色拆得那么细，是因为想着复制一个更”专业”的人类开发团队。但实际跑起来以后我发现，人类团队里的角色之所以能成立，不只是因为这些角色本身的定位，而是因为它们背后有大量隐含的组织经验。这些边界对人类来说也许是常识，但对 Agent 来说不是。如果没有把这些边界写进系统里，只是告诉它”你是某某角色”，它会用语言理解这个角色，却不一定用组织方式理解这个角色。

角色不是越多越好。角色越多，对协作协议的要求越高。如果没有足够清晰的协议，更多角色不会带来更强的团队能力，反而会带来更多协调成本。

第二版依旧不够理想

软件开发真正重要的，不是有多少角色，而是能不能稳定完成一次交付。完成一次软件交付，到底最少需要几个 Agent？这就是第三版的起点。

在第三版里，我开始做减法：把澄清、拆分和分配收敛到一个 Agent，把开发收敛到一个 Agent，把测试和反馈收敛到一个 Agent。不是因为其他角色不重要，而是因为对 Agent Team 来说，最先需要稳定下来的，不是组织结构有多完整，而是交付闭环能不能跑通。所以第三版，我开始从”像不像一个团队”，转向”能不能形成一个最小可运行的交付系统”。