单个 AI 代理的能力有上限——上下文窗口有限、单线程处理慢、专业领域深度不足。WorkBuddy 的 Agent 多代理协作架构让多个子代理并行工作,各司其职又协同配合,像一支高效的团队一样完成复杂任务。本文将详解多代理架构的设计原理、配置方法、任务编排策略以及实战最佳实践。
WorkBuddy 的多代理架构采用主从模式(Orchestrator-Worker):
负责任务拆分、子代理调度、结果汇总、冲突解决,不直接执行具体任务
各自独立执行分配的子任务,拥有独立的上下文和工具集,并行运行
子代理间的数据交换通道,支持发布-订阅和请求-响应两种模式
每个子代理运行在独立沙箱中,文件系统、网络、进程互不干扰
通过 agents.json 定义代理团队:
{
"team": "fullstack-dev",
"orchestrator": {
"model": "hunyuan-pro",
"system_prompt": "你是一个全栈开发团队的技术负责人...",
"max_workers": 5
},
"workers": [
{
"id": "frontend",
"name": "前端工程师",
"model": "deepseek-v3",
"system_prompt": "你是前端开发专家,擅长 Vue3/React...",
"tools": ["filesystem", "browser", "npm"],
"skills": ["frontend-dev", "ui-design"],
"max_concurrent": 2
},
{
"id": "backend",
"name": "后端工程师",
"model": "deepseek-v3",
"system_prompt": "你是后端开发专家,擅长 Python/FastAPI...",
"tools": ["filesystem", "subprocess", "database"],
"skills": ["backend-dev", "api-design"],
"max_concurrent": 2
},
{
"id": "tester",
"name": "测试工程师",
"model": "hunyuan-pro",
"system_prompt": "你是QA专家,负责编写和执行测试...",
"tools": ["filesystem", "subprocess"],
"skills": ["test-gen", "test-runner"],
"max_concurrent": 1
},
{
"id": "reviewer",
"name": "代码审查员",
"model": "hunyuan-pro",
"system_prompt": "你是代码审查专家...",
"tools": ["filesystem", "git"],
"skills": ["code-review"],
"max_concurrent": 1
}
],
"shared_context": {
"mode": "pub_sub",
"topics": ["code_changes", "test_results", "review_feedback"]
}
}
最常见的拆分方式,将大任务按功能边界切分:
用户:开发一个用户管理模块,包含注册、登录、权限管理
Orchestrator 拆分:
├── backend: 实现 /api/users 注册/登录接口 + JWT 鉴权
├── backend: 实现 /api/roles 角色权限 CRUD 接口
├── frontend: 实现注册/登录页面组件
├── frontend: 实现用户管理后台页面(角色分配、权限配置)
└── tester: 为以上所有接口和页面编写测试用例
重构或修改类任务,按文件归属拆分:
用户:将项目从 JavaScript 迁移到 TypeScript
Orchestrator 拆分:
├── worker-1: 迁移 src/utils/*.js → *.ts
├── worker-2: 迁移 src/components/*.jsx → *.tsx
├── worker-3: 迁移 src/services/*.js → *.ts
└── worker-4: 更新 tsconfig.json 和类型声明文件
有依赖关系的任务,按阶段串行,阶段内并行:
用户:完成从需求到部署的全流程
阶段1(并行):
├── analyst: 需求分析与 PRD 编写
└── designer: UI/UX 设计稿
阶段2(并行,依赖阶段1):
├── frontend: 前端开发
└── backend: 后端开发
阶段3(依赖阶段2):
└── tester: 集成测试
阶段4(依赖阶段3):
└── devops: 部署上线
对于无冲突的结果(如不同文件的修改),Orchestrator 直接合并:
Orchestrator 汇总:
✅ backend: 创建了 5 个 API 文件
✅ frontend: 创建了 3 个页面组件
✅ tester: 编写了 12 个测试用例
📊 总计:8 个文件创建,12 个测试用例,耗时 3m20s
当多个 Worker 修改同一文件时,触发冲突解决:
汇总后,Orchestrator 执行质量检查:
质量门禁:
├── 代码风格:eslint 检查 → ✅ 通过
├── 类型检查:tsc --noEmit → ✅ 通过
├── 单元测试:npm test → ❌ 2 个失败
├── 代码审查:reviewer 评估 → ⚠️ 3 个建议
└── 决策:自动修复测试失败,采纳审查建议后重新验证
适用于异步通知场景:
# backend 发布代码变更
publish("code_changes", {
files: ["src/api/users.py", "src/models/user.py"],
summary: "新增用户注册接口"
})
# tester 订阅并自动触发测试
on("code_changes", (msg) => {
runTests(msg.files)
})
适用于需要即时结果的场景:
# frontend 请求后端接口定义
const apiSpec = request("backend", "get_api_spec", {
endpoint: "/api/users"
})
# backend 响应
response({
method: "POST",
params: { username: "string", password: "string" },
returns: { token: "string", user: "object" }
})
按模块拆分给不同 Worker 并行重构,Orchestrator 负责跨模块接口一致性
每个 Worker 负责一个模块的文档,并行编写后统一格式和术语
Worker 按模块并行生成测试,最后统一运行确保无遗漏
同一份数据,不同 Worker 从性能/安全/可维护性角度并行分析