多角色智能体：PM、开发、测试分工协作的软件开发模式
一、单 Agent 的角色混乱
让一个 Agent 既当 PM 又当开发又当测试。
它会在需求、实现、验证之间反复横跳。
上下文被三类职责稀释，每项都做不深。
就像一个人开站会、写代码、测功能。
精力分散，质量靠运气。
越复杂的任务，越容易顾此失彼。
多角色智能体把职责显式分开。
PM 管需求与验收，开发管实现，测试管验证。
各角色专注一段，靠标准接口交接。
本文探讨 PM/Dev/QA 三角色的协作模式。
二、角色协作的机制
三角色通过"工件"衔接，而非共享大脑。
PM 产出需求规格与验收清单。
开发产出代码，对齐验收清单。
测试依据清单写用例，独立验证。
测试角色必须独立，不读开发上下文。
否则会"顺着代码找通过"，失去客观性。
这是质量不被自我麻痹的关键。
下面是协作的工件流：
flowchart TD A[PM: 需求规格] --> B[Dev: 实现代码] B --> C[QA: 依据规格写用例] C --> D{用例通过?} D -->|否| E[缺陷回 PM/Dev] D -->|是| F[验收完成] E --> A E --> B style A fill:#e1f5fe style F fill:#e8f5e9关键在"规格是唯一标尺"。
三方看同一份验收清单，争议有依据。
避免"我觉得好了"的主观扯皮。
三、生产级实现
下面用代码描述角色间的工件契约。
from dataclasses import dataclass, field from typing import Optional from enum import Enum class Role(Enum): PM = "pm" DEV = "dev" QA = "qa" @dataclass class Spec: """PM 交付的工件，作为下游唯一依据""" feature: str acceptance: list[str] dev_code: Optional[str] = None qa_result: Optional[bool] = None def dev_implement(spec: Spec) -> Spec: if not spec.acceptance: raise ValueError("PM 未给验收标准，开发无法开工") # 真实场景调用开发 Agent 生成代码 spec.dev_code = f"impl:{spec.feature}" return spec def qa_verify(spec: Spec) -> Spec: """QA 独立验证，只看规格与代码，不读开发思路""" if spec.dev_code is None: spec.qa_result = False return spec # 逐条核对验收，独立判断 spec.qa_result = all( crit.lower() in (spec.dev_code or "").lower() for crit in spec.acceptance ) return spec if __name__ == "__main__": s = Spec("登录", ["含超时", "含错误日志"]) s = dev_implement(s) s = qa_verify(s) print("验收通过" if s.qa_result else "需返工")真实系统里三个角色跑独立上下文或进程。
规格对象通过消息或存储传递，互不共享记忆。
这样任一角色崩溃不影响整体。
四、多角色智能体的代价与边界
三角色提升质量，但成本显性。
协调开销。多一轮交接就多一轮延迟与 token。
简单任务用单 Agent 更快更省。
应按任务复杂度决定角色数，不为用而用。
规格的质量天花板。开发再强，规格错就全错。
PM 角色必须能澄清歧义，而非照单转写。
低质量规格是三角色模式的致命短板。
测试独立的代价。QA 不读开发思路，可能漏掉隐含意图。
缓解：把"为什么"写进规格，而非依赖默契。
并允许 QA 在不确定时回问 PM。
失败归因复杂。三方协作，问题出在哪段难定位。
应有每阶段的产出留痕与状态标记。
便于复盘时快速定责。
多角色协作的"沟通成本"要算进账。三角色带来质量，也带来三倍的上下文传递与对齐开销。建议用结构化工件（规格、任务清单、测试结果）替代自然语言沟通，减少误读，也让任一角色缺席时他人能接手。另一个实践是"角色可裁剪"：简单任务退化成单 Agent，复杂任务才上三角色，不为用而用。最后，协作过程要可审计，每个角色的产物与决策留痕，出现质量事故时能快速定位是规格错、实现错还是验证错，而非互相推诿。
五、总结
PM/Dev/QA 多角色协作，本质是用职责分离换质量。
机制上以规格为唯一标尺，三方独立上下文防自我麻痹。
工程上按复杂度决定角色数，留痕便于归因。
落地路线：先让 PM 产出带验收的规格；开发对齐规格实现；QA 独立逐条验证；不合格回抛。复杂任务交给分工，简单任务留给单人。