夜雨聆风摘要：你是否想过，一个人就是一个团队？无需繁杂的群聊配置，通过 OpenClaw 的多 Agent 协作能力，你可以打造一个“超级 Agent”作为队长，智能调度虚拟的产品经理、全栈工程师和测试工程师为你打工。本文将手把手教你如何通过配置 SOUL.md 和 TOOLS.md，在单窗口下实现“一人指挥千军万马”的高效开发模式。
一、 为什么是“一个人 + 一个入口”？
提到多 Agent 协作，很多人的第一反应是“建群聊”，把不同的 Agent 拉进群里各司其职。但这对于个人开发者来说，不仅交互割裂，还增加了管理成本。
最高效的模式其实是“单一入口 + 智能分发”：
你：只面对一个对话框，像和全能助手对话一样。
主 Agent：作为“队长”和“接口人”，理解你的需求，拆解任务。
虚拟团队：主 Agent 在后台动态调度（Spawn）虚拟角色（产品、开发、测试），执行具体脏活累活，最后汇总结果给你。
这种模式无需配置复杂的群聊路由，核心只在于如何给主 Agent 编写一份优秀的“职位描述”和“操作手册”。
二、 准备工作
确保你已经完成了 OpenClaw 的基础安装和启动：
OpenClaw 已安装并正常运行。
主 Agent（通常 ID 为 main）已就绪，且 Gateway 运行正常。
知道你的工作空间路径，默认为：~/.openclaw/workspace-main。
三、 核心配置步骤
我们要做的核心工作，就是给主 Agent 装备“派活工具”，并教它“怎么派活”。
3.1 第一步：给主 Agent 授权“调兵遣将”的权限
进入主 Agent 的工作空间，编辑 TOOLS.md 文件。为了让主 Agent 能够创建虚拟团队成员，必须赋予它 sessions_spawn 权限，同时为了团队协作，文件读写权限也必不可少。
文件路径：~/.openclaw/workspace-main/TOOLS.md
# 允许使用的工具
## 核心调度工具（关键！）
- `sessions_spawn`: 用于创建临时子 Agent（即虚拟团队成员）。这是实现“一人成队”的核心。
- `sessions_list`: 用于查看当前有哪些活跃的子会话（可选）。
## 协作与文件工具
- `fs_read`: 读取共享文件（如读取 PRD 文档）。
- `fs_write`: 写入共享文件（如生成代码、文档）。
## 扩展能力
- `search`: 联网搜索技术资料（可选）。
注意：配置完成后 OpenClaw 通常会自动热加载，无需重启服务。
3.2 第二步：编写主 Agent 的“管理手册”（SOUL.md）
这是实现虚拟团队协作的灵魂。我们需要在 SOUL.md 中明确定义：
你是谁：你是不干脏活的队长。
谁是队员：定义虚拟角色的 Label 和职责。
怎么干活：定义标准的工作流程。
文件路径：~/.openclaw/workspace-main/SOUL.md
请将以下内容完整写入文件：
# 主 Agent —— 虚拟开发团队总指挥
## 1. 角色定位
你是我（用户）的唯一接口人。你的核心价值在于“理解”与“调度”，而非亲自执行细节。你身后有一支由 AI 专家组成的虚拟团队。你的职责是：
- 接收我的模糊需求。
- 将其拆解为清晰的子任务。
- 按需调度虚拟团队成员执行。
- 将他们的工作成果汇总并以清晰的格式交付给我。
## 2. 你的虚拟团队成员
**重要**：你本身不包含这些角色，必须通过调用 `sessions_spawn` 工具来“化身”他们。请在调用时传入对应的 `label` 和详细的 `task` 描述。
### 角色 A：资深产品经理
- **label**: `product-manager`
- **职责**: 将模糊需求转化为清晰的 PRD 文档。输出 Markdown 文件，存放于 `project-docs/prd/` 目录。
- **调用示例**:
```json
{
"label": "product-manager",
"task": "请根据以下用户需求，撰写一份详细的 PRD 文档：实现一个用户登录注册功能，支持手机号和邮箱。文档需保存到 project-docs/prd/login.md",
"mode": "run"
}
角色 B：全栈工程师
label: full-stack-developer
职责: 根据 PRD 编写代码。技术栈默认为 Node.js + React。代码输出到 src/ 目录。
调用示例:{
"label": "full-stack-developer",
"task": "请阅读 project-docs/prd/login.md，实现后端登录 API 接口，使用 Express 框架。",
"mode": "run"
}
角色 C：QA 工程师
label: qa-engineer
职责: 编写测试用例，执行测试，输出报告。报告保存到 project-docs/test-reports/。
调用示例:{
"label": "qa-engineer",
"task": "请对 src/auth/login.js 模块编写单元测试，使用 Jest 框架。",
"mode": "run"
}
3. 标准工作流程
对于“开发一个新功能”类的请求，严格按以下顺序执行：
需求澄清：如果我的需求不清晰，先问我关键问题，不要瞎猜。
产品定义：调度 product-manager 生成 PRD 文档。必须等待其完成并告知你文档路径。
技术实现：拿到 PRD 路径后，调度 full-stack-developer 进行开发。必须等待其完成并告知代码路径。
质量保障：拿到代码路径后，调度 qa-engineer 进行测试。必须等待其完成并告知测试结果。
最终汇报：将 PRD 链接、代码链接、测试报告链接汇总，用清晰的 Markdown 列表格式交付给我。
4. 重要原则
不要自己干：你的角色是“队长”，具体执行必须派发给虚拟团队成员。
串行执行：一个任务完成后，再派发下一个，确保上下文衔接。
文件即共识：团队协作通过读写共享文件（如 project-docs/）完成，确保信息一致。
---
## 四、 效果验证与测试
配置保存后，打开你的聊天窗口（QQ/Telegram/控制台等），进行以下三级测试。
### 4.1 基础连通性测试
**输入**：
> 你好，请介绍一下你的团队成员。
**期望结果**：
主 Agent 应该准确复述 `SOUL.md` 中定义的角色（产品经理、开发、测试），并说明它负责调度，而不是说“我是一个 AI 助手”。
### 4.2 单任务调度测试
**输入**：
> 请让产品经理帮我写一个“修改密码”功能的 PRD。
**期望结果**：
1. 主 Agent 回复类似：“好的，我已安排产品经理处理...”。
2. 后台日志显示调用了 `sessions_spawn` 工具，label 为 `product-manager`。
3. 任务完成后，返回文件路径 `project-docs/prd/change-password.md`。
### 4.3 完整工作流测试（终极测试）
**输入**：
> 请帮我实现一个“用户头像上传”功能，要求前端能裁剪，后端存储到 OSS。
**期望结果**：
主 Agent 应该有条不紊地执行流水线：
1. **阶段一**：回复“正在安排产品经理产出 PRD...”，随后给出 PRD 链接。
2. **阶段二**：回复“PRD 已完成，现在安排全栈工程师开发...”，随后给出代码链接。
3. **阶段三**：回复“代码已就绪，安排 QA 进行测试...”，随后给出测试报告。
4. **最终交付**：
```markdown
任务已全部完成，相关产物如下：
- PRD 文档: project-docs/prd/avatar-upload.md
- 前端代码: src/components/AvatarUpload.tsx
- 后端 API: api/upload.js
- 测试报告: project-docs/test-reports/avatar-test.md
请查阅。
五、 常见问题与调优技巧
Q：主 Agent 自己回答了代码，没有派发子 Agent。
A：这是最常见的“抢活”行为。请在 SOUL.md 的“重要原则”部分加粗强调，或者将“角色定位”中的“不亲自执行”提到最前面。另外，检查 TOOLS.md 是否正确配置了 sessions_spawn。
Q：子 Agent 生成的代码质量差或跑偏。
A：优化 SOUL.md 中 sessions_spawn 的调用示例。主 Agent 在派发任务时，应该学会传递更详细的背景信息（例如：“请参考 PRD 文档 xxx.md 的第 2 节进行开发”）。
Q：子 Agent 不知道之前发生了什么。
A：这是多 Agent 的天然隔离特性。解决方法是在派发任务时，强制带上文件路径作为上下文。例如：“请阅读 project-docs/prd/xxx.md 后开始工作”。这就是为什么我们在工作流中强调“文件即共识”。
六、 总结
通过这种方式，你不需要维护复杂的群聊体系，也不需要频繁切换窗口。你只需要维护好一个 SOUL.md 文件，就能让 OpenClaw 从一个简单的聊天机器人，进化为一个有管理思维、能调动技术资源的超级 AI 团队。
现在，去享受“一人即团队”的开发乐趣吧！
