多 Agent 协作系统配置实践：从规划到落地

本文记录了如何构建一个多 Agent 协作系统，包括角色设计、权限管理、目录结构和协作流程。

持续更新中…

📌 文章状态

项目	内容
创建时间	2026-02-10
更新时间	2026-02-10 (新增实战问题分析与改进)
状态	实战验证完成，待发布
预计发布	确认后

一、背景与目标

1.1 为什么需要多 Agent？

在实际项目中，我们常常面临这样的困境：

需求分析师 负责 PRD 和用户故事，但不熟悉技术实现
技术架构师 负责系统设计，但不直接写代码
开发者 负责编码，但需要理解需求和架构
测试工程师 负责质量保障，但信息往往滞后
运维工程师 负责部署，但经常最后一个才知道变更

痛点：
– 信息孤岛：各角色之间缺乏有效的信息传递机制
– 职责模糊：任务分配和进度跟踪依赖人工协调
– 效率低下：沟通成本高，容易遗漏和误解

1.2 本次配置的目标

🎯 目标：构建一个清晰、高效、安全的多 Agent 协作系统

具体目标：
1. 角色清晰：每个 Agent 有明确的职责边界
2. 权限安全：最小权限原则，防止越权操作
3. 协作顺畅：通过共享目录和标准化流程实现信息流通
4. 灵活扩展：易于添加新的 Agent 或调整职责

二、Agent 角色设计

2.1 团队成员一览

Agent	名称	核心职责	协作定位
Sarah	Product Manager	需求分析、PRD 编写、用户故事、产品规划	需求源头
Alex	Tech Architect	系统架构、API 设计、技术选型、代码审查	技术把关
Mike	Project Manager	任务协调、进度跟踪、风险管理、团队协调	协调中心
Emma	Developer	代码开发、分支管理、功能实现、Bug 修复	主要执行者
Lisa	QA Engineer	测试用例、安全扫描、质量把关、验收测试	质量保障
Oscar	Operator / DevOps	代码部署、环境管理、运维监控、日志排查	最后交付

2.2 Agent 详细定位

Sarah（产品经理）

核心职责：
– 需求收集与分析
– PRD 文档编写
– 用户故事梳理
– 产品路线图规划

关键工作方式：
– 收到任务后，必须向用户询问关键需求细节
– PRD 完成后，必须获得用户确认才能继续
– 避免因理解错误导致的返工

产出：
– 存储位置：shared/prd/ – PRD 文档
– 存储位置：shared/user-stories/ – 用户故事

Alex（技术架构师）

核心职责：
– 系统架构设计
– 技术选型决策
– API 规格说明
– 代码审查

关键工作方式：
– 严格代码审查：语法检查、代码格式、逻辑正确性
– 构建验证：必须运行 npm run build 确保代码可编译
– 发现问题立即打回，不让有问题的代码进入 MR

产出：
– 存储位置：shared/architecture/ – 架构文档
– 存储位置：shared/api/ – API 规格
– 存储位置：shared/database/ – 数据库设计

Mike（项目经理）

核心职责：
– 任务分配与跟踪
– 进度管理
– 风险识别与应对
– 团队协调

关键工作方式：
– 协调中心：所有请求先到 Mike，再分发给其他 Agent
– 关键检查点：
– Sarah 是否确认 PRD？
– Alex 是否审查通过？
– Lisa 是否测试通过？
– MR 是否已合并？

产出：
– 存储位置：shared/status/ – Sprint 状态报告
– 存储位置：shared/status/risk-alerts.md – 风险警报

Emma（开发工程师）

核心职责：
– 功能代码实现
– Bug 修复
– 单元测试编写

关键工作方式：
– 确认后才能开始：PRD 和架构设计确认后才能开始开发
– 本地构建验证：提交前必须运行 npm run build
– 遵循分支规范：功能开发用 feature/*，Bug 修复用 bugfix/*

产出：
– 存储位置：shared/code/ – 源代码
– 存储位置：shared/code/bug-fixes/ – Bug 修复

Lisa（测试工程师）

核心职责：
– 代码审查
– 安全扫描
– 构建验证
– 服务器测试

⚠️ 服务器环境限制：
– Linux 服务器环境无法打开图形浏览器
– 无法进行”打开浏览器测试交互”这样的操作
– 可以使用 curl 测试页面是否可访问
– 可以使用 npm audit 进行安全扫描
– 需要人类协助验证浏览器交互功能

工作方式：
– 代码审查 + 构建验证
– curl 测试页面加载
– 请用户在浏览器中验证交互功能
– 依赖人类反馈发现的问题

Oscar（运维工程师）

核心职责：
– 代码部署
– 环境管理
– 运维监控

关键工作方式：
– 确认后才能部署：MR 必须合并、QA 必须通过
– 构建验证：部署前运行 npm run build
– 部署验证：部署后检查应用是否正常运行

产出：
– 存储位置：shared/deployments/ – 部署报告

三、配置架构设计

3.1 OpenClaw 配置格式

OpenClaw 使用 JSON5 格式的配置文件 ~/.openclaw/openclaw.json，多 Agent 配置采用 agents.list 数组格式。

agents.list 配置

{
  agents: {
    list: [
      {
        id: "main",
        default: true,
        name: "Main Agent",
        workspace: "~/.openclaw/workspace",
        agentDir: "~/.openclaw/agents/main/agent"
      },
      {
        id: "product-manager",
        name: "Sarah",
        workspace: "~/.openclaw/workspace/team/product-manager",
        agentDir: "~/.openclaw/agents/product-manager/agent"
      },
      // ... 其他 Agent
    ],
    defaults: {
      model: {
        primary: "qwen-portal/coder-model",
        fallbacks: ["..."]
      }
    }
  }
}

支持的字段

字段	说明	支持状态
`id`	Agent 唯一标识	✅ 支持
`default`	是否为默认 Agent	✅ 支持
`name`	Agent 名称	✅ 支持
`workspace`	Agent 工作空间	✅ 支持
`agentDir`	Agent 状态目录	✅ 支持
`description`	Agent 描述	❌ 不支持
`toolPermissions`	工具权限	❌ 不支持

3.2 Agent 行为限制的实现

由于 OpenClaw 配置格式的限制，每个 Agent 的具体行为限制通过 AGENTS.md 文件定义。

AGENTS.md 文件位置

~/.openclaw/workspace/team/<agent>/
├── SOUL.md           ← Agent 人格设定
├── USER.md           ← 服务对象
├── AGENTS.md         ← ← Agent 行为限制（关键）
├── docs/             ← 私有文档目录
├── memory/           ← 记忆目录
└── skills/           ← 技能目录

3.3 Critical Rules 模板

每个 Agent 的 AGENTS.md 包含 ⚠️ Critical Rules 部分：

## ⚠️ Critical Rules

### DO
- ✅ 允许的操作
- ✅ 写入共享目录

### DON'T
- ❌ 禁止的操作
- ❌ 禁止访问的资源

3.4 技能配置

所有 Agent 共享相同的技能配置，在 openclaw.json 的 skills 部分定义：

{
  skills: {
    allowBundled: [
      "markdown-converter",
      "ddgs-search",
      "tavily-search",
      "summarize",
      "tencent-cos",
      "pinch-to-post",
      "pptx-creator",
      "healthcheck",
      "proactive-agent"
    ],
    entries: {
      "pinch-to-post": { ... },
      "tencent-cos": { ... }
    }
  }
}

3.5 认证配置共享

所有 Agent 的认证配置使用符号链接共享到 main Agent：

~/.openclaw/agents/
├── main/agent/
│   ├── auth-profiles.json    ← 原文件
│   └── models.json
├── product-manager/agent/
│   ├── auth-profiles.json    → main (符号链接)
│   └── models.json           → main (符号链接)
# ... 其他 Agent 同理

四、目录结构设计

4.1 完整目录结构

/root/.openclaw/
├── agents/                      ← 认证配置（符号链接）
│   ├── main/agent/
│   ├── product-manager/agent/
│   ├── tech-architect/agent/
│   ├── project-manager/agent/
│   ├── developer/agent/
│   ├── qa-tester/agent/
│   └── operator/agent/
│
├── workspace/
│   ├── projects/               ← Emma 开发目录
│   ├── shared/                 ← ⭐ Agent 协作共享目录
│   │   ├── prd/
│   │   ├── user-stories/
│   │   ├── prioritization/
│   │   ├── release/
│   │   ├── architecture/
│   │   ├── api/
│   │   ├── database/
│   │   ├── code-reviews/
│   │   ├── code/
│   │   ├── test-results/
│   │   │   ├── bugs/
│   │   │   ├── security/
│   │   │   └── coverage/
│   │   ├── deployments/
│   │   └── status/
│   │       ├── risk-alerts.md
│   │       └── capacity.md
│   │ 
│   └── team/                   ← Agent 私有目录
│       ├── product-manager/
│       ├── tech-architect/
│       ├── project-manager/
│       ├── developer/
│       ├── qa-tester/
│       └── operator/
│
└── config/                      ← 配置文件
    ├── openclaw.json
    └── tencent-cos-config.json

# 外部目录
/data/
├── git/                         ← 远端 Git 主干镜像（仅 Oscar 读写）
│   ├── project-a/
│   ├── project-b/
│   └── project-c/
│
├── wwwroot/                    ← 生产环境（Oscar 读写，其他人只读）
│   ├── project-a/
│   ├── project-b/
│   └── project-c/
│
└── logs/                      ← 应用日志（所有人只读，Oscar 可管理）

4.2 目录访问权限矩阵

目录	Sarah	Alex	Mike	Emma	Lisa	Oscar
`/data/git/*/`	❌	❌	❌	✅ 只读	❌	✅ 读写
`/data/wwwroot/`	❌	❌	❌	✅ 只读	❌	✅ 读写
`/data/logs/`	❌	❌	❌	✅ 只读	✅ 只读	✅ 读写
`/projects/*/`	❌	✅ 只读	❌	✅ 读写	✅ 读写	❌
`/shared/code/`	✅ 只读	✅ 只读	✅ 只读	✅ 读写	✅ 只读	✅ 只读
`/shared/prd/`	✅ 读写	✅ 只读	✅ 只读	❌	❌	❌
`/shared/architecture/`	✅ 只读	✅ 读写	✅ 只读	❌	❌	❌
`/shared/test-results/`	✅ 只读	✅ 只读	✅ 只读	❌	✅ 读写	❌
`/shared/deployments/`	✅ 只读	✅ 只读	✅ 只读	❌	❌	✅ 读写
`/shared/status/`	✅ 只读	✅ 只读	✅ 读写	❌	❌	❌

五、Git 工作流程设计

5.1 分支命名规范

main / master    ← 默认主分支（生产代码）
feature/*        ← 新功能分支
bugfix/*         ← Bug 修复分支
hotfix/*         ← 紧急修复分支

5.2 完整协作流程

┌─────────────────────────────────────────────────────────────┐
│                     远端 Git 服务器                          │
└─────────────────────────────────────────────────────────────┘
        ↑                              ↓
        |                              |
   (人类合并 MR)                   (Emma push 分支)
        |                              |
        ↓                              ↓
┌─────────────────────────────────────────────────────────────┐
│  /data/git/*/               /projects/*/                   │
│  ← Oscar 拉取主干            ← Emma 开发目录                 │
│  (部署用)                     (clone 自远端)                  │
│                              ├── feature/login              │
│                              │   └── Emma 开发               │
│                              └── Alex 审查                  │
└─────────────────────────────────────────────────────────────┘
        ↑
        |
   (Lisa 扫描/测试)
        |
        ↓
┌─────────────────────────────────────────────────────────────┐
│  /data/wwwroot/           /data/logs/                     │
│  ← Oscar 部署              ← 所有人查看日志                 │
└─────────────────────────────────────────────────────────────┘

5.3 Git 权限分配

操作	Emma	Alex	Lisa	Oscar
`git clone`	✅	✅	✅	❌
`git checkout -b`	✅	❌	❌	❌
`git commit`	✅	❌	❌	❌
`git push`	✅	❌	❌	❌
`git merge branch`	✅	❌	❌	❌
MR (feature → main)	❌	✅	❌	❌
Git 服务器合并	❌	❌	❌	❌ (人类)
`git pull` (到 /data/git/)	❌	❌	❌	✅

六、技能与权限配置

6.1 基础通用技能

所有 Agent 都具备以下基础技能：

技能	用途
`read`	读取文件
`write`	写入文件
`markdown-converter`	文档格式转换
`ddgs-search`	DuckDuckGo 搜索
`tavily-search`	AI 优化搜索
`summarize`	内容总结
`tencent-cos`	文件分享
`sessions_send`	Agent 间通信

6.2 Agent 特定技能

Agent	特定技能	说明
Sarah	`pinch-to-post`	发布博客到 WordPress
Alex	`healthcheck`	架构安全检查
Mike	`pptx-creator`	制作进度报告
Emma	`git`, `exec`	代码版本控制、开发命令
Lisa	`healthcheck`, `git`	安全扫描、只读访问
Oscar	`git`, `exec`	拉取主干、部署命令

6.3 Emma 开发命令白名单

Emma 被允许执行的命令：

{
  "node": ["npm run *", "npm test", "npm build"],
  "pnpm": ["pnpm *"],
  "npx": ["npx *"],
  "go": ["go run *", "go build *", "go test *"],
  "java": ["java *", "javac *"],
  "maven": ["mvn *"],
  "python": ["python *", "python3 *", "pip *"],
  "git": ["*"],
  "docker-compose": ["docker-compose *"],
  "testing": ["jest *", "eslint *", "pytest *"],
  "curl": ["curl http://localhost*"]
}

七、Agent 间协作协议

7.1 协调流程

用户请求
    ↓
Mike (Project Manager) ← 入口，统一协调
    ↓
根据需求类型分发：
    │
    ├─→ Sarah → PRD/用户故事 → shared/prd/, shared/user-stories/
    │       ↓
    │       向 Mike 汇报
    │
    ├─→ Alex → 架构/API设计 → shared/architecture/, shared/api/
    │       ↓
    │       审查 Emma 代码 → shared/code-reviews/
    │       ↓
    │       向 Mike 汇报
    │
    ├─→ Emma → 代码实现 → shared/code/
    │       ↓
    │       Alex 审查架构合规性
    │       ↓
    │       向 Mike 汇报
    │
    ├─→ Lisa → 测试 → shared/test-results/
    │       ↓
    │       向 Mike 汇报
    │
    └─→ Oscar → 部署 → shared/deployments/
            ↓
            向 Mike 汇报
    ↓
Mike 汇总 → shared/status/sprint-XX.md → 回复用户

7.2 共享目录协议

黄金法则：

每个 Agent 必须将最终产出写入共享目录，否则其他 Agent 无法访问。

写入流程：
1. 在私有目录起草 (docs/)
2. 审核定稿
3. 复制到共享目录对应子目录
4. 其他 Agent 可以读取

八、实战复盘：羊了个羊游戏开发

8.1 项目概述

项目：开发一个类似”羊了个羊”的三消益智游戏
技术栈：纯 Vue 前端，无服务端
Git 仓库：<内部 Git 服务器>（私有仓库，地址已脱敏）
部署地址：<内部部署路径>（私有部署环境，路径已脱敏）

8.2 执行流程

步骤	Agent	操作	产出
1	用户	提交需求	“开发羊了个羊游戏”
2	Mike	接收需求，分发	向 Sarah 发送任务
3	Sarah	未询问需求细节，直接写 PRD	PRD 过于简单
4	Alex	架构设计	shared/architecture/
5	Emma	开发	feature/init-project
6	Alex	代码审查	未发现语法错误
7	Lisa	QA 验证	未实际运行测试
8	人类	合并 MR	main 分支
9	Oscar	部署	生产环境

8.3 遇到的问题

问题	描述	根因
PRD 不完整	游戏规则未明确定义	Sarah 未向用户询问需求细节
代码无法编译	语法错误进入 MR	Alex 未运行 `npm run build`
部署后无法运行	UI 显示异常，交互无效	⚠️ Linux 服务器无法打开浏览器
游戏逻辑错误	点击卡牌无响应	Emma 实现有 bug
UI 问题	卡牌显示成一列，无堆叠效果	CSS 布局问题
点击匹配错误	点击第3张删除第2张	索引匹配错误

8.4 迭代修复次数

版本	修复内容	合并次数
v1.0.1	点击交互	MR #1
v1.0.2	游戏规则（6槽位）	MR #2
v1.0.3	正确游戏规则	MR #3
v1.0.4	UI改进（尺寸、悬停、堆叠）	MR #4
v1.0.5	语法错误修复	MR #5
v1.0.6	数组越界、连续消除	MR #6
v1.0.7	大卡片UI、删除逻辑	MR #7
v1.0.8	点击匹配修复	MR #8
v1.0.9	金字塔UI修复	MR #9

问题：一个小游戏开发迭代了 9 个版本才基本可用，严重影响效率。

九、问题分析与流程改进

9.1 问题根因分析

问题 1：Sarah 和 Mike 没有起作用

现象：
– 收到需求后直接开始写 PRD
– PRD 内容过于简单，缺少关键游戏规则
– 未确认PRD是否完整就开始开发

根因：
– Agent 配置中未明确要求”询问用户需求细节”
– Agent 配置中未要求”PRD 必须用户确认后才能继续”

后果：
– PRD 不完整导致理解偏差
– 后续多次返工

问题 2：Alex 没发现语法错误

现象：
– 提交的代码有语法错误
– 构建失败仍进入 MR

根因：
– Alex 只看了代码逻辑，未运行 npm run build
– Agent 配置中未明确要求”构建验证”

后果：
– 浪费多次合并和部署时间
– 降低团队效率

问题 3：Lisa 无法进行浏览器测试

现象：
– 代码审查通过，但部署后游戏无法交互
– 卡牌点击无响应

根因：
– ⚠️ Linux 服务器环境无法打开图形浏览器
– Agent 配置要求”必须打开浏览器测试”不切实际
– Lisa 只能使用 curl 测试页面是否可访问

后果：
– 交互问题直到用户访问才被发现
– 需要人类协助验证浏览器交互功能

解决方案：
– Lisa 使用 curl/npmm audit 进行服务器端测试
– 请用户在浏览器中验证交互功能
– 依赖人类反馈发现的问题

9.2 流程改进方案

改进 1：Sarah 的职责调整

新流程：

收到任务
    ↓
向用户询问关键问题：
  1. 核心游戏规则是什么？
  2. 胜利/失败条件？
  3. 道具功能？
  4. 交互方式（点击/拖拽）？
    ↓
等待用户回复
    ↓
生成完整 PRD
    ↓
向用户确认："PRD 是否完整正确？"
    ↓
用户确认后，才能通知 Alex 开始架构设计

关键规则：
– ❌ 不要直接写 PRD，必须先询问用户需求细节
– ❌ 不要跳过用户确认步骤

改进 2：Alex 的职责调整

新流程：

收到代码审查请求
    ↓
运行构建验证：
  cd /projects/project
  npm install
  npm run build
    ↓
构建失败：
  - 报告具体错误
  - 要求 Emma 修复
  - 不批准进入 MR
    ↓
构建成功：
  - 审查代码逻辑
  - 检查安全性
  - 写审查意见
    ↓
批准或打回

关键规则：
– ❌ 不要批准无法编译的代码进入 MR
– ❌ 不要跳过构建验证步骤

改进 3：Lisa 的职责调整（服务器环境限制）

新流程：

收到 QA 请求
    ↓
克隆代码：
  cd /projects/project
  git pull
  npm install
    ↓
构建验证：
  npm run build
    ↓
安全扫描：
  npm audit
  eslint --ext .vue,.js src/
    ↓
服务器测试：
  npm run preview
  curl -I http://localhost:4173
    ↓
**请人类验证交互**：
  - "请在浏览器中打开测试链接验证交互功能"
  - 请用户报告发现的问题
    ↓
人类反馈无问题后：
  - 写 QA 通过报告
  - 通知可以合并 MR

关键规则：
– ❌ 不要只审查代码就通过 QA
– ❌ 不要跳过实际运行测试

改进 4：Mike 的协调职责

新增检查清单：

Sarah：
├── 收到任务后，是否向用户询问需求细节？
├── PRD 生成后，是否用户确认？
└── 确认后才能继续

Alex：
├── PRD 确认后，才能开始架构设计？
├── 代码提交前，是否审查通过？
└── 构建失败不能进入 MR

Emma：
├── 必须在 bugfix 分支开发？
├── Alex 审查通过后才能提交 MR？
└── 本地构建是否成功？

Lisa：
├── 是否进行服务器端测试（构建 + curl）？
├── npm audit 安全扫描是否通过？
└── 是否请人类验证浏览器交互？

Oscar：
├── MR 合并后才能部署？
├── 构建是否成功？
└── 部署后是否验证？

9.3 更新后的 Agent 配置文件

Agent	更新文件	关键改进
Sarah	`team/product-manager/AGENTS.md`	询问用户需求细节、PRD 确认流程
Mike	`team/project-manager/AGENTS.md`	协调流程、关键检查点、风险报告
Alex	`team/tech-architect/AGENTS.md`	严格代码审查、`npm run build` 验证
Lisa	`team/qa-tester/AGENTS.md`	服务器端测试 + 请人类验证交互
Emma	`team/developer/AGENTS.md`	开发规范、本地构建验证
Oscar	`team/operator/AGENTS.md`	MR 合并后才能部署

9.4 新工作流程（已更新配置）

用户请求
    ↓
Mike 协调（确保每个步骤有检查点）
    ↓
Sarah 询问需求 → 生成 PRD → 用户确认 ✅
    ↓
Alex 架构设计
    ↓
Emma 开发 → 本地构建验证 → Alex 代码审查 ✅
    ↓
Lisa 服务器测试 + 请人类验证交互 → QA 通过 ✅
    ↓
人类合并 MR
    ↓
Oscar 部署验证 ✅

9.5 预期效果

改进项	改进前	改进后
PRD 完整性	PRD 简单，多次返工	完整 PRD，一次确认
代码质量	语法错误进入 MR	构建验证，不通过不打回
测试质量	未实际运行	必须打开浏览器测试
迭代次数	小游戏 9 次迭代	预期 2-3 次
部署成功率	多次失败	一次成功

十、经验总结

10.1 关键成功因素

职责边界清晰：每个 Agent 有明确的职责和权限
最小权限原则：只授予完成任务所需的最小权限
标准化流程：通过共享目录和命名规范实现标准化
安全第一：禁止危险操作，重要操作需要人工确认
持续改进：发现问题及时调整 Agent 配置

10.2 潜在风险

复杂度增加：多 Agent 协调比单 Agent 复杂
权限管理：需要仔细配置避免安全漏洞
学习成本：新成员需要理解协作流程
环境限制：Linux 服务器无法进行浏览器测试，需要人类协助验证交互功能

10.3 改进方向

浏览器测试能力：安装 Puppeteer/Playwright 实现自动化浏览器测试
自动化测试：增加集成测试覆盖率
监控告警：添加异常行为检测
文档完善：持续更新操作手册
配置检查：确保 Agent 配置正确

10.4 下次任务验证清单

开发前检查：
- [ ] Agent 配置已更新
- [ ] Sarah 知道要询问用户需求
- [ ] Alex 知道要运行构建验证
- [ ] Lisa 知道要服务器端测试 + 请人类验证

任务执行检查：
- [ ] Sarah 询问了用户需求
- [ ] PRD 获得用户确认
- [ ] Alex 运行了 npm run build
- [ ] Lisa 服务器端测试通过，请人类验证交互

附录

A.1 相关资源

OpenClaw 文档: https://docs.openclaw.ai
GitHub: https://github.com/openclaw/openclaw
Discord: https://discord.com/invite/clawd

A.2 文件清单

文件	说明
`team/product-manager/SOUL.md`	Sarah 人格设定
`team/product-manager/AGENTS.md`	Sarah 工作流程和限制
`team/tech-architect/SOUL.md`	Alex 人格设定
`team/tech-architect/AGENTS.md`	Alex 工作流程和限制
`team/project-manager/SOUL.md`	Mike 人格设定
`team/project-manager/AGENTS.md`	Mike 工作流程和限制
`team/developer/SOUL.md`	Emma 人格设定
`team/developer/AGENTS.md`	Emma 工作流程和限制
`team/qa-tester/SOUL.md`	Lisa 人格设定
`team/qa-tester/AGENTS.md`	Lisa 工作流程和限制
`team/operator/SOUL.md`	Oscar 人格设定
`team/operator/AGENTS.md`	Oscar 工作流程和限制
`config/openclaw-agents-config-final.json`	Agent 配置片段
`config/skills-entries-config.json`	技能配置片段
`config/git-repositories.json`	Git 和目录权限配置

更新日志

日期	更新内容	更新人
2026-02-10	初始版本，创建文档结构	Agent 系统
2026-02-10	补充 Agent 详细职责和工作流程	Agent 系统
2026-02-10	添加 Git 工作流程和权限分配	Agent 系统
2026-02-10	重大更新：配置架构变更、Agent 配置调整	Agent 系统
2026-02-10	新增实战复盘和问题分析	Agent 系统

本文将持续更新，记录从配置到测试的完整过程。

📌 文章状态

目录

一、背景与目标

1.1 为什么需要多 Agent？

1.2 本次配置的目标

二、Agent 角色设计

2.1 团队成员一览

2.2 Agent 详细定位

Sarah（产品经理）

Alex（技术架构师）

Mike（项目经理）

Emma（开发工程师）

Lisa（测试工程师）

Oscar（运维工程师）

三、配置架构设计

3.1 OpenClaw 配置格式

agents.list 配置

支持的字段

3.2 Agent 行为限制的实现

AGENTS.md 文件位置

3.3 Critical Rules 模板

3.4 技能配置

3.5 认证配置共享

四、目录结构设计

4.1 完整目录结构

4.2 目录访问权限矩阵

五、Git 工作流程设计

5.1 分支命名规范

5.2 完整协作流程

5.3 Git 权限分配

六、技能与权限配置

6.1 基础通用技能

6.2 Agent 特定技能

6.3 Emma 开发命令白名单

七、Agent 间协作协议

7.1 协调流程

7.2 共享目录协议

八、实战复盘：羊了个羊游戏开发

8.1 项目概述

8.2 执行流程

8.3 遇到的问题

8.4 迭代修复次数

九、问题分析与流程改进

9.1 问题根因分析

问题 1：Sarah 和 Mike 没有起作用

问题 2：Alex 没发现语法错误

问题 3：Lisa 无法进行浏览器测试

9.2 流程改进方案

改进 1：Sarah 的职责调整

改进 2：Alex 的职责调整

改进 3：Lisa 的职责调整（服务器环境限制）

改进 4：Mike 的协调职责

9.3 更新后的 Agent 配置文件

9.4 新工作流程（已更新配置）

9.5 预期效果

十、经验总结

10.1 关键成功因素

10.2 潜在风险

10.3 改进方向

10.4 下次任务验证清单

附录

A.1 相关资源

A.2 文件清单

更新日志

发送评论 编辑评论

发送评论编辑评论