OpenClaw实现主子agent协作
构建高效的研发流程:主智能体与子智能体协作实战
今天咱们聊一个很实用的技术架构——如何通过主智能体协调多个子智能体的方式,搭建一个多智能体协作系统。简单来说,就是让一个“总指挥”智能体,能够自动调度产品、研发、测试三个“专家”智能体协同工作。具体怎么实现?咱们一步步拆解。
核心理念与角色分工
这套方案的核心,是围绕软件产品研发的核心环节,设计了三个专业角色:
产品智能体(Product):顾名思义,扮演产品经理的角色。它的任务是进行产品设计、澄清需求,并将抽象的需求转化为人人可理解、可验收的用户故事与标准。
研发智能体(Coding):这是技术担当。当需求明确后,它负责提供具体的技术方案、实现思路,并给出代码级别的详细建议,把想法落地为可行的技术路径。
质控智能体(QC):相当于测试专家。它的视角非常关键,专注于挖掘测试点、考虑各种边界条件、评估回归影响,并检查方案中是否有可改进之处,为最终交付的质量保驾护航。
最妙的地方在于,作为用户或项目管理者,你完全无需手动协调这三个角色。你只需要在一个指定的群聊(例如名为“多agent产品研发测试协作”的飞书群)中,向一个特定的机器人(比如 openclaw_bot)下达任务指令。剩下的工作,这个主智能体机器人会全自动接管:它会理解你的意图,将任务分派给对应的子智能体,收集并整合它们的专业意见,最终生成一份综合性的方案反馈给你。整个流程一气呵成。
下面的配置是实现这一协作模式的关键,主要通过一份名为 openclaw.json 的配置文件来完成。如果你对其他多智能体的实现方案也感兴趣,市面上也有不少可以参考的框架和文章。
一、产品研发质控的多Agent协同任务
首先,我们需要在系统中创建并定义那三位“专家”。具体操作是通过命令行工具添加智能体,并为它们指定专属的工作空间和身份。研发和测试智能体的创建方式也完全类似,或者,你也可以直接打开配置文件,修改智能体列表(agents list)的内容。这部分的具体操作,我们会在接下来的第一步详细说明。
# 产品agent
openclaw agents add product --workspace C:\\root\\.openclaw\\workspace-product
openclaw agents set-identity --agent product --name “product”
# 研发agent
openclaw agents add coding --workspace C:\\root\\.openclaw\\workspace-coding
openclaw agents set-identity --agent coding --name “coding”
# 测试检查agent
openclaw agents add qc --workspace C:\\root\\.openclaw\\workspace-qc
openclaw agents set-identity --agent qc --name “qc”
完成上述创建后,会生成一个配置文件,例如 openclaw-mutiagent-产品研发测试协作.json。这个文件有几处关键配置,理解了它们,就理解了整个协作机制的骨架。
1.在主agent中加上subagents配置
这是最核心的一步:让主智能体知道它手下有哪些“兵”。在配置中,我们为主智能体(id为“main”)增加了一个 subagents 字段,并在 allowAgents 列表中明确列出了它可以调度的三个子智能体:“product”、“coding”和“qc”。同时,每个子智能体自身的配置(如id、name、工作空间、身份和智能体目录)也需要独立定义。
{
“id”: “main”,
“default”: true,
“name”: “hello 张三”,
“workspace”: “C:\\root\\.openclaw\\workspace”,
“subagents”: { “allowAgents”: [“product”, “coding”, “qc”] }
},
{
“id”: “product”,
“name”: “product”,
“workspace”: “C:\\root\\.openclaw\\workspace-product”,
“agentDir”: “C:\\root\\.openclaw\\agents\\product\\agent”,
“identity”: {“name”: “product”}
}
// 其他两个类似
2.在bindings配置主agent和对应的channels
接下来,需要把主智能体“绑定”到一个具体的沟通渠道上。这里的意思是,告诉系统:当某个特定渠道(比如飞书)的特定账号(比如一个开发团队账号)收到消息时,就由主智能体(agentId: “main”)来负责响应和处理。
“bindings”: [{
“agentId”: “main”,
“match”: {
“channel”: “feishu”,
“accountId”: “dev-team”
}
}]
3.在channels中配置群组对应的账号
渠道配置是整个流程的“接入点”。这里以飞书为例,详细定义了连接方式、启用的账号,以及最关键的一点——这个账号关联了哪个群聊。注意看 groups 里的配置,它指向了飞书中那个名为“多agent产品研发测试协作”的群聊(通过群ID oc_xxxxxxf 识别),并且设置了 requireMention: false,意味着在这个群里对该机器人的发言,无需@它也能触发响应。
“channels”: {
“feishu”: {
“connectionMode”: “websocket”,
“enabled”: true,
“accounts”: {
“dev-team”: {
“appId”: “cli_axxxxx8”, // 对应飞书应用:openclaw_bot
“appSecret”: “mVHexxxxxCHZQneMp5j”,
“groups”: {
“oc_xxxxxxf”: {
“requireMention”: false // 飞书:“多agent产品研发测试协作”群聊
}
},
“default”: {
“dmPolicy”: “pairing”,
“groupPolicy”: “open”
}
}
}
}
4.应用测试效果
理论配置完毕,实际效果如何呢?我们来一次实战推演。在配置好的“多agent产品研发测试协作”群聊中,直接对 openclaw_bot 机器人发送这样一条指令:
我们做一个小项目推演:我有一个“基于Agent的空间计算分析的应用融合需求”。请你先派产品 Agent 整理成用户故事和验收标准,再派开发 Agent 给实现思路和关键代码,再派测试 Agent 给测试点和回归注意点;等三边都回复后,你再帮我综合成一份简要的项目清单。
发出指令后,你将观察到主智能体开始工作:它会依次召唤产品、研发、测试三个子智能体,并汇集它们的专业输出。最终,你会得到一份由主智能体整理的综合项目清单,其中包含了从需求到实现再到质量保障的完整视角。整个过程的协作反馈,类似下图所示的效果:
至此,一个基于主智能体与子智能体协作的自动化研发支持流程就搭建完成了。它不仅清晰划分了职责,更重要的是,通过自动化协调,将多个环节的专业分析无缝整合,极大地提升了方案构思与评审的效率和全面性。
