MetaGPT 把协作约定写进了交付物

从需求文档到接口和测试结果,分析 MetaGPT 的共享消息池、订阅与前置依赖,讨论 SOP 在 Nexus 中的适用范围。

MetaGPT 将软件开发拆成岗位以后,又给每个岗位规定了产物。产品经理交付需求文档,架构师交付系统设计,项目经理分配任务,工程师实现代码,测试成员检查结果。岗位之间的依赖由这些产物连接。MetaGPT v7,第 3.1 节

这使 SOP 有了技术含义。它既规定由谁工作,也规定下一步依赖什么输入。分析 MetaGPT,应沿着产物流转寻找约束,而不能停在职位名称上。

成员在工作台之间交接蓝图和模型的手绘概念插画

概念插画,由 imagegen 生成。

交接规范为什么会影响生成结果

论文中的需求文档包含用户故事和需求池。架构师把它展开为文件列表、数据结构与接口定义,再由后续成员实现。每一份产物都在缩小下一步需要猜测的范围。

接口定义尤其重要。若调用方与实现方分别生成同一个函数的名称、参数和返回值,二者都有可能各自成立,却无法连接。共享接口约定能把这个问题提前暴露在设计阶段。这里的收益来自减少独立生成之间的不一致,单纯增加角色数量无法提供同样的约束。

MetaGPT 原论文图 1 对照人类软件团队和 Agent 的标准作业流程

Sirui Hong 等,MetaGPT 原论文图 1,版本 2308.00352v7。按 CC BY 4.0 引用,原文及图注。图片未修改,网页按宽度缩放。

图中同时画出了人类团队的流程与 Agent 岗位。需要关注的是需求文档、系统设计、任务和代码之间的箭头。它们说明依赖关系,不保证上游内容一定正确。错误需求也能被完整地传给下一位成员。

因此,结构化输出解决的是信息组织问题。字段齐全、格式可解析,有助于检查缺项;需求是否合理、接口是否满足业务,仍需语义层面的验证。将“符合模板”作为交接成功的全部条件,会使错误沿着流程传播。

共享消息池与订阅分别解决什么

若每个成员都向原作者索取材料,需求文档需要被反复转发,通信关系会随成员增加而变复杂。MetaGPT 将消息放进共享池,让成员按角色关注的信息获取材料。共享池解决可访问性,订阅减少无关信息进入当前任务。第 3.2 节

论文还指出,动作应在前置依赖到齐后启动。这个条件比“收到一条新消息”严格。架构师关注需求文档;工程师需要设计和任务安排。可见消息集合与执行所需输入集合,并不相同。

从工程角度看,这种安排接近按产物依赖推进工作。要把它用于持续维护的项目,还需要补充版本判断。上游改了需求,哪些设计和代码受影响,旧测试结论还能否继续使用,都取决于产物之间是否保留来源关系。这是从论文机制推导出的产品问题,不能仅凭消息池的存在就认为已经解决。

MetaGPT 从需求文档、设计到代码和测试反馈的结构化交接流程

简图合并了部分岗位。实线表示向后交付,虚线表示执行反馈返回实现。两类路径要分别检查,前者关注材料是否充分,后者关注修改是否针对已观察到的错误。

可执行反馈提供了另一类证据

MetaGPT 的工程师可以编写并运行单元测试,再依据执行结果修改代码。论文所述流程在测试通过或达到最多三次重试后停止。测试输出为模型提供了外部观察,模型不再只依靠对自己生成内容的文字评价。第 3.3 节

但测试也可能遗漏需求。如果代码与测试都来自同一份错误理解,通过测试只能说明两者相容。对于业务验收,仍应保留独立于实现过程的要求或样例。这一点决定了如何理解 Pass@1。

论文的函数级评测与项目级评测使用不同对象。HumanEval 和 MBPP 检查函数解答,SoftwareDev 则收集软件开发需求。v7 描述的 SoftwareDev 有 70 个任务,比较时选取其中 7 个代表任务。角色消融又只比较两个任务。样本范围应随结果一起阅读,不能把数据集总量当成每张表的实测数量。第 4 节

可执行反馈消融报告 HumanEval 和 MBPP 的 Pass@1 分别增加 4.2、5.4 个百分点。这个结果支持在对应设置中引入执行反馈,不能单独解释岗位拆分的收益。若要判断 SOP 是否有效,需要保持模型与反馈工具一致,再改变交接约定。

把 SOP 放进 Nexus,需要区分约定和校验

Nexus 的 Room Skill 可以规定分工、交付和停止规则,适合描述一个团队应怎样工作。工作图则用于记录任务、依赖、负责人和验收。两者可分别承载协作约定与需要跟踪的工作状态。

借鉴 MetaGPT 时,最先值得明确的是交付对象。一次设计交接应给出对应的需求版本、产物位置和未解决问题;接收者据此决定能否继续。若要求缺少接口定义就禁止实现,应把条件交给宿主或校验工具处理。Skill 中的一句话不会自动成为强制条件。

采用这种方法也有成本。中间产物需要生成、阅读和更新。对于边界明确的一次修改,重复创建需求和设计文档可能增加维护负担;对于多人接力且接口存在歧义的任务,保存共享约定才有收益。流程粒度应由返工来源决定。

评估时,可以把“找不到材料”“材料之间矛盾”“实现没有遵守材料”分别记录。三者分别对应传递、上游一致性和执行问题,处理方式不同。只有先辨认错误发生在哪一层,才知道应该补模板、改依赖规则,还是加强测试。

本文依据 MetaGPT v7 及 Nexus 公开文档作设计分析,未报告 Nexus 的复现实验。阶段之间保留多少上下文,见 ChatDev 解读