多角色智能体：PM、开发、测试分工协作的软件开发模式
一、单 Agent 的角色混乱
让一个 Agent 既当 PM 又当开发又当测试。
它会在需求、实现、验证之间反复横跳。
上下文被三类职责稀释，每项都做不深。
就像一个人开站会、写代码、测功能。
精力分散，质量靠运气。
越复杂的任务，越容易顾此失彼。
多角色智能体把职责显式分开。
PM 管需求与验收，开发管实现，测试管验证。
各角色专注一段，靠标准接口交接。
本文探讨 PM/Dev/QA 三角色的协作模式。
二、角色协作的机制
三角色通过"工件"衔接，而非共享大脑。
PM 产出需求规格与验收清单。
开发产出代码，对齐验收清单。
测试依据清单写用例，独立验证。
测试角色必须独立，不读开发上下文。
否则会"顺着代码找通过"，失去客观性。
这是质量不被自我麻痹的关键。
下面是协作的工件流：
关键在"规格是唯一标尺"。
三方看同一份验收清单，争议有依据。
避免"我觉得好了"的主观扯皮。
三、生产级实现
下面用代码描述角色间的工件契约。
python
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 独立逐条验证；不合格回抛。复杂任务交给分工，简单任务留给单人。