Oh My OpenAgent 多 Agent 协作实战：一个需求，7 个 Agent 并行完成

前情提要：第八篇讲了 IDEA + ACP + OpenCode 环境搭建。
这一篇讲多 Agent 协作：如何让 7 个专用 Agent 并行工作，完成复杂开发任务？
我的答案：Oh My OpenAgent（原 Oh My OpenCode）+ 46 个生命周期 Hook + /opsx-apply 工作流。
效果：复杂功能开发从 3 天 降到 4 小时，提升 83%。
注：Oh My OpenCode 于 2026 年 3 月正式改名为 Oh My OpenAgent，功能不变。

一、为什么需要多 Agent 协作？

1.1 单 Agent 的局限性

场景： 开发一个完整的”员工请假审批”功能模块

单 Agent 工作流：

1. AI 分析需求
2. AI 设计数据库表
3. AI 编写后端代码
4. AI 编写前端代码
5. AI 编写测试
6. AI 调试问题

问题：
- 每个步骤都要重新加载上下文
- AI 容易忘记之前的决策
- 代码风格不一致
- 调试时丢失全局视角

核心问题：

一个 Agent 试图做所有事情，就像一个人同时扮演产品经理、架构师、开发工程师、测试工程师。

1.2 多 Agent 协作的优势

OH MY OPENAGENT只是AI编程工具，能自动规划任务、并行处理复杂项目。7大专业Agent各司其职，工作中断后可精确恢复进度

Oh My OpenAgent 的 7 个专用 Agent：

Agent	角色	职责
Sisyphus	主协调器	理解需求、编排其他 Agent
Prometheus	规划师	生成实施计划、任务分解
Metis	计划顾问	审查计划、提出改进建议
Artistry	创意专家	非传统问题、创新方案
Oracle	架构专家	复杂逻辑、架构决策
Librarian	文档专家	查找文档、API 参考
Explorer	代码探索	探索代码库、查找模式

多 Agent 工作流：

用户提出需求
     ↓
Sisyphus（主协调器）分析需求
     ↓
┌────────────────────────────────────┐
│ 并行执行：                          │
│ - Prometheus 生成计划               │
│ - Explorer 探索代码库               │
│ - Librarian 查找文档                │
└────────────────────────────────────┘
     ↓
Metis 审查计划
     ↓
Oracle 解决架构难题
     ↓
Sisyphus 整合结果 → 生成代码
     ↓
自动测试验证

优势：

✅ 专业化 – 每个 Agent 专注擅长的领域
✅ 并行化 – 独立任务同时执行
✅ 一致性 – 共享上下文，决策连贯
✅ 可追溯 – 每个步骤有明确的责任 Agent

1.3 效率提升对比

任务	单 Agent	多 Agent	提升
需求分析 + 计划	60 分钟	15 分钟（并行）	75%
代码探索 + 文档查找	45 分钟	10 分钟（并行）	78%
架构设计	90 分钟	30 分钟（Oracle 专精）	67%
代码生成	120 分钟	60 分钟（上下文清晰）	50%
调试问题	180 分钟	45 分钟（多视角分析）	75%
总计	495 分钟	160 分钟	68%

二、Oh My OpenAgent 核心概念

2.1 46 个生命周期 Hook

Hook 是什么？

Hook 是 OpenCode 执行过程中的拦截点，可以在关键时刻介入、修改行为、记录日志。

Hook 分类：

类别	Hook 数量	用途
任务生命周期	12 个	任务创建、执行、完成
消息生命周期	15 个	消息发送、接收、处理
工具生命周期	10 个	工具调用、结果处理
Agent 生命周期	9 个	Agent 激活、切换、退出

常用 Hook 示例：

{
  "hooks": {
    // 任务开始前
    "before_task_create": "记录任务信息到日志",
    
    // 工具调用前
    "before_tool_call": "校验工具参数",
    
    // 消息发送前
    "before_message_send": "添加水印或标记",
    
    // 任务完成后
    "after_task_complete": "自动提交 Git"
  }
}

Hook 的价值：

✅ 可观测性 – 记录每个步骤的执行日志
✅ 自定义行为 – 在关键时刻插入自定义逻辑
✅ 质量控制 – 校验输入输出，防止错误传播
✅ 自动化 – 自动执行重复任务（如 Git 提交）

2.2 配置文件详解

配置文件位置：

类型	路径	说明
用户级配置	~/.config/opencode/oh-my-openagent.jsonc	全局配置，所有项目共用
项目级配置	<项目根目录>/.opencode/oh-my-openagent.jsonc	仅当前项目生效

完整配置示例：

{
  "$schema": "https://opencode.ai/config.json",
  
  // Provider 配置
  "provider": {
    "bailian-coding-plan": {
      "name": "Model Studio Coding Plan",
      "api": "openai",
      "options": {
        "baseURL": "https://coding.dashscope.aliyuncs.com/apps/anthropic/v1",
        "apiKey": "sk-sp-xxxxxxxxxxxxxxxx"
      },
      "models": {
        "qwen3.5-plus": { "name": "Qwen3.5 Plus" },
        "glm-5": { "name": "GLM-5" },
        "kimi-k2.5": { "name": "Kimi K2.5" },
        "minimax-m2.5": { "name": "MiniMax M2.5" }
      }
    }
  },
  
  // 默认模型
  "defaultModel": "bailian-coding-plan/qwen3.5-plus",
  
  // Agent 配置
  "agents": {
    "sisyphus": {
      "model": "bailian-coding-plan/qwen3.5-plus",
      "temperature": 0.7,
      "maxTokens": 4096
    },
    "prometheus": {
      "model": "bailian-coding-plan/glm-5",
      "temperature": 0.5
    },
    "metis": {
      "model": "bailian-coding-plan/kimi-k2.5",
      "temperature": 0.6
    },
    "oracle": {
      "model": "bailian-coding-plan/qwen3.5-plus",
      "temperature": 0.3
    },
    "artistry": {
      "model": "bailian-coding-plan/minimax-m2.5",
      "temperature": 0.8
    }
  },
  
  // 内置技能配置
  "skills": {
    "playwright": {
      "enabled": true  // 浏览器自动化
    },
    "git-master": {
      "enabled": true  // 原子化提交
    },
    "test-runner": {
      "enabled": true  // 自动运行测试
    }
  },
  
  // Hook 配置
  "hooks": {
    "before_task_create": {
      "log": {
        "enabled": true,
        "level": "info"
      }
    },
    "after_task_complete": {
      "git-commit": {
        "enabled": true,
        "autoMessage": true
      }
    }
  },
  
  // 后台任务并发限制
  "backgroundTasks": {
    "concurrencyLimit": {
      "bailian-coding-plan/qwen3.5-plus": 5,
      "bailian-coding-plan/glm-5": 3,
      "bailian-coding-plan/kimi-k2.5": 4
    }
  }
}

2.3 验证安装

Oh My OpenAgent 是 OpenCode 的增强插件，安装后会自动集成到 OpenCode 中，无需额外启动命令。

第一步：启动 OpenCode

# 在项目目录启动
cd ~/your-project
opencode

第二步：检查 Oh My OpenAgent 是否加载

启动后应该看到 Sisyphus 被加载：

第三步：查看可用 Agent

在 OpenCode 交互界面中输入：

/agents

第四步：测试多 Agent 协作

尝试一个简单的任务，观察是否自动调用多个 Agent：

帮我分析这个项目的目录结构，并生成一个 README 草稿

预期行为：

Sisyphus 接收任务
自动调用 Explorer 探索代码库
自动调用 Librarian 查找类似项目的 README 模板
整合结果并生成 README

如果看到类似输出，说明 Oh My OpenAgent 已正确加载！ ✅

常见问题排查：

问题	可能原因	解决方案
看不到欢迎信息	Oh My OpenAgent 未安装	运行 npm install -g oh-my-openagent
只有 Sisyphus 可用	配置文件错误	检查 ~/.config/opencode/oh-my-openagent.jsonc
Agent 响应慢	并发限制过低	调整 backgroundTasks.concurrencyLimit
Hook 未生效	配置未保存	确认配置文件已保存并重启 OpenCode

调试技巧：

# 1. 检查配置文件是否存在
ls -la ~/.config/opencode/oh-my-openagent.jsonc

# 2. 查看配置文件内容
cat ~/.config/opencode/oh-my-openagent.jsonc

# 3. 验证 OpenCode 版本
opencode --version


# 4. 查看 OpenCode 日志
# macOS: ~/.opencode/logs/
# Linux: ~/.opencode/logs/
# Windows: %APPDATA%\opencode\logs\

三、实战案例：员工请假审批系统

3.1 需求描述

业务背景：

开发一个”员工请假审批”功能模块，包含：

请假申请 → 主管审批 → HR 备案三阶段流程
支持附件上传（病假证明、事假说明等）
多级审批（员工 → 部门主管 → HR）
流程状态跟踪和通知

技术要求：

后端：Spring Boot 3.3 + Java 21
前端：Vue3 + Element Plus
数据库：MySQL
文件存储：MinIO

3.2 多 Agent 协作流程

第一步：Sisyphus 分析需求

# 用户输入
帮我开发一个员工请假审批功能模块，包含请假申请、主管审批、HR 备案三阶段流程。

# Sisyphus 响应
好的，我来帮你实现这个功能。

让我先分析需求并调用专用 Agent：

1. 调用 Prometheus 生成实施计划
2. 调用 Explorer 探索现有代码库
3. 调用 Librarian 查找相关文档
4. 调用 Oracle 设计 BPMN 流程

预计耗时：15 分钟（并行执行）

第二步：并行执行（3 个 Agent 同时工作）

Prometheus（规划师）生成计划：

# 任务：生成实施计划
task(subagent_type="prometheus", prompt="
根据员工请假审批功能需求，生成详细的实施计划。

要求：
1. 分解为可执行的任务
2. 标注任务依赖关系
3. 估算每个任务的工作量
4. 识别技术难点

输出格式：Markdown 任务清单
")

输出：

## 员工请假审批实施计划

### 阶段 1：数据库设计（2 小时）
- [ ] 设计 leave_request_process 表
- [ ] 设计 leave_request_task 表
- [ ] 设计 leave_request_attachment 表
- [ ] 创建数据库迁移脚本

### 阶段 2：BPMN 流程设计（3 小时）
- [ ] 设计三阶段流程图
- [ ] 定义节点类型和流转规则
- [ ] 配置审批权限

### 阶段 3：后端开发（8 小时）
- [ ] 创建 Entity 类
- [ ] 创建 Repository 接口
- [ ] 创建 Service 服务层
- [ ] 创建 Controller 控制器
- [ ] 实现文件上传接口

### 阶段 4：前端开发（8 小时）
- [ ] 创建列表页面
- [ ] 创建详情页面
- [ ] 创建审批弹窗组件
- [ ] 实现文件上传组件

### 阶段 5：测试（4 小时）
- [ ] 编写单元测试
- [ ] 编写集成测试
- [ ] 手动验证流程

### 阶段 6：文档（1 小时）
- [ ] 编写 API 文档
- [ ] 编写用户手册

Explorer（代码探索）探索代码库：

# 任务：探索现有代码库
task(subagent_type="explorer", prompt="
探索当前项目的代码结构，找出：

1. 现有的流程相关代码（参考现有审批模块）
2. 文件上传组件（查找已有实现）
3. 审批相关组件（查找 reviewDialog 等）
4. 代码规范和命名约定

返回：
- 相关文件路径
- 可复用的代码片段
- 需要避免的坑
")
输出：
## 代码库探索结果

### 可复用的模块

1. **现有审批流程**（参考实现）
   - 位置：`src/main/java/com/example/approval/ApprovalRouter.java`
   - BPMN 流程：`src/main/resources/approval.bpmn20.xml`
   - 前端组件：`components/approval/ApprovalDialog.vue`

2. **文件上传组件**
   - 位置：`components/upload/UploadDialog.vue`
   - 支持格式：pdf, doc, docx, jpg, png
   - 大小限制：10MB

3. **审批弹窗组件**
   - 位置：`components/approval/ReviewDialog.vue`
   - 功能：通过/驳回、意见输入、附件上传

### 代码规范

- Entity 命名：`LeaveRequestXxxModel`
- Controller 命名：`LeaveRequestXxxRouter`
- 前端组件：`leave-request-xXxx.vue`（kebab-case）

### 需要避免的坑

1. BPMN 流程 ID 不要与现有流程冲突
2. 文件上传需要校验文件类型和大小
3. 审批操作需要记录操作日志

Librarian（文档专家）查找文档：

# 任务：查找相关文档
task(subagent_type="librarian", prompt="
查找员工请假审批功能相关的文档：

1. Spring Boot 3.3 文件上传最佳实践
2. Element Plus Upload 组件文档
3. BPMN 2.0 规范（审批流程）
4. MinIO 文件存储配置

返回：
- 官方文档链接
- 关键配置示例
- 常见错误和解决方案
")
输出：
## 文档检索结果

### 1. Spring Boot 文件上传

**官方文档：** https://docs.spring.io/spring-boot/docs/3.3.x/reference/htmlsingle/

**关键配置：**
```properties
spring.servlet.multipart.max-file-size=10MB
spring.servlet.multipart.max-request-size=10MB

常见错误：

MaxUploadSizeExceededException – 需要在全局异常处理器中捕获

2. Element Plus Upload

官方文档： https://element-plus.org/zh-CN/component/upload.html

关键配置：

<el-upload
  :before-upload="beforeUpload"
  :on-success="handleSuccess"
  :on-error="handleError"
  :limit="5"
>

3. BPMN 2.0 规范

参考： https://www.bpmn.org/

审批流程模式：

排他网关（Exclusive Gateway）- 通过/驳回分支
用户任务（User Task）- 人工审批节点

4. MinIO 配置

官方文档： https://min.io/docs/minio/linux/index.html

Spring Boot 集成：

@Configuration
public class MinioConfig {
    @Bean
    public MinioClient minioClient() {
        return MinioClient.builder()
            .endpoint("http://minio.example.com")
            .credentials("accessKey", "secretKey")
            .build();
    }
}
---

**第三步：Metis 审查计划**

```bash
# 任务：审查 Prometheus 生成的计划
task(subagent_type="metis", prompt="
审查以下实施计划：

<粘贴 Prometheus 生成的计划>

请评估：
1. 任务分解是否合理？
2. 是否有遗漏的步骤？
3. 技术难点识别是否准确？
4. 工作量估算是否合理？
5. 改进建议
")
输出：
## 计划审查结果

### ✅ 优点
- 任务分解清晰，阶段划分合理
- 识别了文件上传、BPMN 流程等关键技术点
- 包含测试和文档阶段

### ⚠️ 需要改进

1. **遗漏的步骤：**
   - 缺少权限配置（不同角色的访问控制）
   - 缺少通知机制（流程状态变更通知）
   - 缺少请假类型配置（年假、病假、事假等）

2. **技术难点补充：**
   - BPMN 流程与现有 HR 系统的集成
   - 大文件上传的断点续传
   - 并发审批的数据一致性

3. **工作量调整：**
   - 后端开发：8 小时 → 10 小时（增加权限和通知）
   - 前端开发：8 小时 → 10 小时（增加通知和权限 UI）
   - 测试：4 小时 → 6 小时（增加集成测试）

### 📋 建议更新后的计划

（更新后的任务清单，包含上述补充内容）

第四步：Oracle 解决架构难题

# 任务：设计 BPMN 流程架构
task(subagent_type="oracle", prompt="
设计员工请假审批的 BPMN 流程架构。

要求：
1. 三阶段流程（请假申请 → 主管审批 → HR 备案）
2. 每个阶段包含审批、驳回、修改流程
3. 支持多级审批（员工 → 主管 → HR）
4. 支持多种请假类型（年假、病假、事假、调休）

输出：
- BPMN 流程图（文本描述）
- 节点 ID 命名规范
- 流转条件表达式
")
输出：
## BPMN 流程架构设计

### 流程图
```
┌─────────────────────────────────────────────────────────────┐
│                    员工请假审批流程                          │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ┌──────────┐                                               │
│  │   开始   │                                               │
│  └────┬─────┘                                               │
│       │                                                      │
│       ▼                                                      │
│  ┌─────────────────┐                                        │
│  │  请假申请提交   │ ◄───┐                                  │
│  │  (add1)         │     │                                  │
│  └────────┬────────┘     │                                  │
│           │              │                                  │
│           ▼              │                                  │
│  ┌─────────────────┐     │                                  │
│  │  主管审批       │     │                                  │
│  │  (view1)        │     │                                  │
│  └────────┬────────┘     │                                  │
│           │              │                                  │
│           ▼              │                                  │
│  ┌─────────────────┐     │                                  │
│  │  主管审批网关   │─────┘ (驳回)                           │
│  │  (gateway1)     │                                        │
│  └──────────┬──────┘                                        │
│             │                                                │
│       ┌─────┴─────┐                                          │
│       │           │                                          │
│       ▼           ▼                                          │
│  ┌─────────┐ ┌──────────┐                                   │
│  │  驳回   │ │  通过    │                                   │
│  │(update1)│ │          │                                   │
│  └────┬────┘ │          │                                   │
│       │      │          │                                   │
│       └──────┴──────────┘                                   │
│              │                                               │
│              ▼                                               │
│  ┌─────────────────┐                                        │
│  │  HR 备案         │                                        │
│  │  (add2)         │                                        │
│  └────────┬────────┘                                        │
│           │                                                  │
│           ▼                                                  │
│  ┌─────────────────┐                                        │
│  │  HR 确认         │                                        │
│  │  (view2)        │                                        │
│  └────────┬────────┘                                        │
│           │                                                  │
│           ▼                                                  │
│  ┌─────────────────┐                                        │
│  │  HR 确认网关     │                                        │
│  │  (gateway2)     │                                        │
│  └──────────┬──────┘                                        │
│             │                                                │
│             ▼                                                │
│  ┌─────────────────┐                                        │
│  │     结束        │                                        │
│  │  (endEvent)     │                                        │
│  └─────────────────┘                                        │
│                                                             │
└─────────────────────────────────────────────────────────────┘
```
### 节点 ID 命名规范

| 阶段 | 申请节点 | 审批节点 | 网关 | 驳回节点 |
|------|---------|---------|------|---------|
| 主管审批 | add1 | view1 | gateway1 | update1 |
| HR 备案 | add2 | view2 | gateway2 | update2 |

### 流转条件表达式

```xml
<!-- 通过分支 -->
<sequenceFlow name="通过" sourceRef="gateway1" targetRef="add2">
  <conditionExpression><!--MATH_PH_1-->{choice == '驳回'}</conditionExpression>
</sequenceFlow>

请假类型配置

public enum LeaveType {
    ANNUAL_LEAVE("年假"),
    SICK_LEAVE("病假"),
    PERSONAL_LEAVE("事假"),
    COMPENSATORY_LEAVE("调休"),
    MATERNITY_LEAVE("产假"),
    MARRIAGE_LEAVE("婚假");
    
    private final String label;
}
---

**第五步：Sisyphus 整合结果并生成代码**

```bash
# Sisyphus 汇总所有 Agent 的输出
# 开始生成代码

好的，我已经收集了足够的信息。现在开始实现：

## 实施进度

✅ 需求分析完成
✅ 实施计划生成（Prometheus）
✅ 代码库探索完成（Explorer）
✅ 文档检索完成（Librarian）
✅ 计划审查完成（Metis）
✅ 架构设计完成（Oracle）

## 开始生成代码

### 1. 数据库表结构

正在创建：db/leave_request.sql

```sql
-- 员工请假审批流程表
CREATE TABLE leave_request_process (
    id bigint PRIMARY KEY,
    process_instance_id varchar(255) NOT NULL,
    employee_id bigint NOT NULL,
    leave_type varchar(50),
    start_date timestamp,
    end_date timestamp,
    reason text,
    status varchar(50),
    current_stage int,
    create_time timestamp with time zone,
    update_time timestamp with time zone
);

-- 员工请假审批任务表
CREATE TABLE leave_request_task (
    id bigint PRIMARY KEY,
    task_id varchar(255) NOT NULL,
    process_instance_id varchar(255) NOT NULL,
    approver_id bigint,
    approval_opinion text,
    approval_result varchar(50),
    json_data jsonb,
    create_time timestamp with time zone
);

-- 员工请假附件表
CREATE TABLE leave_request_attachment (
    id bigint PRIMARY KEY,
    process_instance_id varchar(255) NOT NULL,
    file_name varchar(255),
    file_path varchar(500),
    file_size bigint,
    file_type varchar(50),
    create_user bigint,
    create_time timestamp with time zone
);
2. BPMN 流程定义
正在创建：src/main/resources/leave_request.bpmn20.xml
（BPMN XML 内容，基于 Oracle 的设计）
3. 后端 Router
正在创建：src/main/java/com/example/leave/LeaveRequestRouter.java
@Component
public class LeaveRequestRouter extends BaseRouter {
    
    private static final String PROCESS_KEY = "leave_request";
    
    @Autowired
    private MyFlowableEngine flowableService;
    
    // 提交请假申请
    public Mono<ServerResponse> submitLeaveRequest(ServerRequest request) {
        // ...
    }
    
    // 处理审批任务
    public Mono<ServerResponse> handleTask(ServerRequest request) {
        // ...
    }
    
    // 获取请假申请列表
    public Mono<ServerResponse> getLeaveRequestList(ServerRequest request) {
        // ...
    }
}
4. 前端组件
正在创建：src/main/webapp/components/leave-request/LeaveRequestList.vue
正在创建：src/main/webapp/components/leave-request/LeaveRequestReviewDialog.vue
正在创建：src/main/webapp/components/leave-request/LeaveRequestUpload.vue
5. 单元测试
正在创建：test/LeaveRequestRouterTest.java
正在创建：test/LeaveRequestServiceTest.java
完成
✅ 已创建 18 个文件 ✅ 已添加 35 个单元测试 ✅ 代码已通过编译检查 ✅ 已运行集成测试（全部通过）
[应用所有更改] [查看差异] [取消]
---

### 3.3 集成 `/opsx-apply` 自动实施

**多 Agent 生成计划后，用 `/opsx-apply` 自动实施：**

```bash
# 第一步：多 Agent 协作生成变更文档
/opsx-propose 开发员工请假审批功能模块

# 第二步：自动实施变更
/opsx-apply

# 执行日志
[INFO] 开始执行变更：leave-request-feature
[INFO] 读取任务清单：tasks.md（共 6 个大任务，28 个子任务）

[INFO] === 第 1 波：数据库设计 ===
[INFO] 创建数据库迁移脚本...
[OK] 第 1 波完成（4 个任务，耗时 12 秒）

[INFO] === 第 2 波：BPMN 流程设计 ===
[INFO] 创建 leave_request.bpmn20.xml...
[OK] 第 2 波完成（3 个任务，耗时 8 秒）

[INFO] === 第 3 波：后端开发 ===
[INFO] 创建 LeaveRequestRouter.java...
[INFO] 创建 LeaveRequestService.java...
[INFO] 创建 LeaveRequestModel.java...
[OK] 第 3 波完成（8 个任务，耗时 35 秒）

[INFO] === 第 4 波：前端开发 ===
[INFO] 创建 LeaveRequestList.vue...
[INFO] 创建 LeaveRequestReviewDialog.vue...
[INFO] 创建 LeaveRequestUpload.vue...
[OK] 第 4 波完成（10 个任务，耗时 45 秒）

[INFO] === 第 5 波：测试 ===
[INFO] 运行单元测试...
[INFO] 运行集成测试...
[OK] 测试全部通过（35 个测试用例）

[INFO] === 第 6 波：文档 ===
[INFO] 生成 API 文档...
[INFO] 生成用户手册...
[OK] 第 6 波完成（3 个任务，耗时 15 秒）

[SUCCESS] 变更实施完成！
- 创建文件：18 个
- 修改文件：5 个
- 运行测试：35 个（全部通过）
- 总耗时：3 分 50 秒

工作流整合：

Oh My OpenAgent 多 Agent 协作
     ↓
生成变更文档（proposal + design + tasks）
     ↓
/opsx-apply 自动实施
     ↓
自动测试验证
     ↓
Git 提交

四、效率提升数据

4.1 开发时间对比

任务	传统开发	多 Agent + /opsx-apply	提升
需求分析 + 计划	4 小时	15 分钟	94%
代码探索 + 文档查找	3 小时	10 分钟	94%
架构设计	2 小时	30 分钟	75%
后端开发	8 小时	35 分钟（AI 生成）	93%
前端开发	8 小时	45 分钟（AI 生成）	91%
测试编写	4 小时	自动运行	100%
文档编写	2 小时	15 分钟（AI 生成）	88%
总计	31 小时	2 小时 30 分钟	92%

4.2 质量对比

指标	传统开发	多 Agent + /opsx-apply	提升
代码审查问题数	15 个	4 个	73% ↓
单元测试覆盖率	60%	88%	47% ↑
Bug 数量（测试阶段）	10 个	2 个	80% ↓
文档完整度	50%	95%	90% ↑
返工次数	3 次	0.5 次	83% ↓

4.3 成本分析

传统开发（3 天）：

开发工程师：3 天 × 8 小时 × 500 元/小时 = 12,000 元
测试工程师：1 天 × 8 小时 × 400 元/小时 = 3,200 元
产品经理：0.5 天 × 8 小时 × 600 元/小时 = 2,400 元
总计：17,600 元

多 Agent + /opsx-apply（2.5 小时）：

AI 成本：约 5 元（百炼 Coding Plan 套餐）
人工审查：0.5 小时 × 500 元/小时 = 250 元
总计：255 元

成本降低：98.6%

五、避坑指南

5.1 多 Agent 协作的常见问题

坑 1：Agent 之间上下文不一致

问题：
- Prometheus 生成的计划基于过时的代码库信息
- Explorer 探索的结果没有被其他 Agent 使用

解决方案：
1. 使用 Sisyphus 作为主协调器，共享上下文
2. 在任务 prompt 中明确引用其他 Agent 的输出
3. 使用 Oh My OpenAgent 的会话管理功能

坑 2：并行任务冲突

问题：
- 两个 Agent 同时修改同一个文件
- 数据库连接数超限

解决方案：
1. 在配置文件中设置并发限制
2. 使用文件锁机制
3. 合理分配任务，避免资源竞争

配置文件示例：
{
  "backgroundTasks": {
    "concurrencyLimit": {
      "bailian-coding-plan/qwen3.5-plus": 5,
      "bailian-coding-plan/glm-5": 3
    }
  }
}

坑 3：Hook 配置错误

问题：
- Hook 执行失败导致任务中断
- Hook 日志过多影响性能

解决方案：
1. 逐步启用 Hook，先测试再上线
2. 设置 Hook 超时时间
3. 定期清理 Hook 日志

配置示例：
{
  "hooks": {
    "after_task_complete": {
      "git-commit": {
        "enabled": true,
        "timeout": 30000,  // 30 秒超时
        "logLevel": "warn"  // 只记录警告和错误
      }
    }
  }
}

5.2 `/opsx-apply` 的常见问题

坑 4：测试未通过继续执行

错误做法：
[FAIL] 测试失败
[INFO] 继续执行...  ← 错误！

正确做法：
[FAIL] 测试失败
[STOP] 停止执行
# 修复问题后
/opsx-apply  # 重新执行

坑 5：忽略人工审查

错误做法：
/opsx-apply  # 直接应用所有变更

正确做法：
/opsx-apply  # 等待 AI 生成代码
git diff     # 人工审查
git commit   # 确认无误后提交

六、总结

6.1 核心观点

多 Agent 协作 > 单 Agent – 专业化分工，并行执行
Hook 提供可观测性 – 记录每个步骤，便于调试和优化
/opsx-apply 自动化实施 – 从规划到上线的完整闭环
人工审查必不可少 – AI 是助手，不是替代

6.2 下一步计划

这个工作流还在持续优化中，后续我会：

沉淀 Agent 配置模板 – 针对不同场景的 Agent 配置
优化 Hook 链 – 更智能的自动化流程
团队推广 – 在团队内分享经验，提升整体效率

参考链接：

Oh My OpenAgent: https://github.com/code-yeongyu/oh-my-openagent
Oh My OpenAgent 官网：http://ohmyopencode.org/
OpenCode: https://github.com/OpenCodeAI/opencode
ACP 协议：https://agentclientprotocol.com/

Oh My OpenAgent 多 Agent 协作实战：一个需求，7 个 Agent 并行完成

一、为什么需要多 Agent 协作？

1.1 单 Agent 的局限性

1.2 多 Agent 协作的优势

1.3 效率提升对比

二、Oh My OpenAgent 核心概念

2.1 46 个生命周期 Hook

2.2 配置文件详解

2.3 验证安装

三、实战案例：员工请假审批系统

3.1 需求描述

3.2 多 Agent 协作流程

2. Element Plus Upload

3. BPMN 2.0 规范

4. MinIO 配置

请假类型配置

四、效率提升数据

4.1 开发时间对比

4.2 质量对比

4.3 成本分析

五、避坑指南

5.1 多 Agent 协作的常见问题

5.2 `/opsx-apply` 的常见问题

六、总结

6.1 核心观点

6.2 下一步计划

Recent Posts

Categories

一、为什么需要多 Agent 协作？

1.1 单 Agent 的局限性

1.2 多 Agent 协作的优势

1.3 效率提升对比

二、Oh My OpenAgent 核心概念

2.1 46 个生命周期 Hook

2.2 配置文件详解

2.3 验证安装

三、实战案例：员工请假审批系统

3.1 需求描述

3.2 多 Agent 协作流程

2. Element Plus Upload

3. BPMN 2.0 规范

4. MinIO 配置

请假类型配置

四、效率提升数据

4.1 开发时间对比

4.2 质量对比

4.3 成本分析

五、避坑指南

5.1 多 Agent 协作的常见问题

5.2 /opsx-apply 的常见问题

六、总结

6.1 核心观点

6.2 下一步计划

Related Posts

AI图谱工具实战：Graphify vs GitNexus 深度对比，让AI读懂你的代码仓库

开源 Claude Code 持久化记忆设计：planning-with-files 技能详解

再见Playwright！谷歌官方Chrome DevTools MCP正式发布，AI编程效率再翻倍

5.2 `/opsx-apply` 的常见问题