内容管家
评论319字数 817阅读2分43秒阅读模式
一、为什么选择 Oh My OpenCode 做多 Agent 编排？
如果说 OpenCode 原生的 plan / build / subagent 是“角色切换”，那么 Oh My OpenCode 更像一个“任务调度器”。它可以自动拆解复杂任务、并行调用多个 Agent、分阶段执行并汇总结果，形成结构化输出链路。
- 自动拆解复杂任务
- 并行调用多个 Agent
- 分阶段执行并汇总结果
- 形成结构化交付流程
当项目规模扩大时，多 Agent 编排的价值会指数级提升。
二、从“多 Agent”到“AI 研发团队模型”
真正有价值的编排，不只是多个技术 Agent，而是模拟一个完整的产品研发组织结构：
- PM（产品经理）：需求拆解与验收标准
- Research：代码扫描与依赖分析
- Architect：技术方案与接口契约
- Backend：后端实现
- Frontend：前端实现
- QA：测试与回归验证
- User Persona：目标用户体验评估
- Docs / Release：文档整理与版本发布
- Report：最终汇总
三、目录结构示例
.opencode/
├── agents/
│ ├── pm.yaml
│ ├── research.yaml
│ ├── architect.yaml
│ ├── backend.yaml
│ ├── frontend.yaml
│ ├── test.yaml
│ ├── user_persona.yaml
│ ├── docs_release.yaml
│ └── report.yaml
└── workflows/
└── feature-workflow.yaml
四、关键 Agent 配置示例
1️⃣ pm.yaml
name: pm
mode: read
system_prompt: |
你是产品经理。
输出：目标、非目标、用户故事、验收标准、优先级、风险。
不写代码，不做技术实现。
2️⃣ backend.yaml
name: backend
mode: write
system_prompt: |
你是后端工程师。
严格遵循接口契约。
每步输出：改动文件、逻辑说明、验证方法。
必须考虑安全与日志。
3️⃣ frontend.yaml
name: frontend
mode: write
system_prompt: |
你是前端工程师。
负责 UI、交互、状态管理与错误提示。
输出改动文件与本地验证方式。
4️⃣ user_persona.yaml
name: user_persona
mode: read
system_prompt: |
你是目标用户代表。
从真实用户视角评估功能：
1) 第一感受
2) 使用是否顺畅
3) 是否增加认知负担
4) 潜在困惑点
5) 优化建议（按优先级排序）
不写代码。
5️⃣ docs_release.yaml
name: docs_release
mode: write
system_prompt: |
你是文档与发布工程师。
输出：CHANGELOG、发布步骤、回滚步骤、版本号建议。
五、完整 Workflow 示例
name: feature-workflow
steps:
- agent: pm
- agent: research
- agent: architect
- parallel:
- agent: backend
- agent: frontend
- agent: test
- agent: user_persona
- agent: docs_release
- agent: report
流程说明：
- 先明确需求与验收标准
- 再做技术设计
- 前后端并行实现
- 测试验证
- 目标用户体验评估
- 生成文档与发布信息
- 最终汇总报告
六、为什么必须加入 User Persona？
大多数多 Agent 系统只关注“能否运行”，却忽略“是否好用”。加入目标用户 Agent，可以避免：
- 功能可用但难理解
- 增加用户认知负担
- 破坏原有使用习惯
- 产生误导性交互
这一步会让系统从“技术协作”升级为“产品级协作”。
七、总结
通过 Oh My OpenCode，你可以把 OpenCode 从单体工具升级为一个完整的 AI 研发组织模型。
关键不在于 Agent 数量，而在于：清晰的职责边界、结构化交接协议、可回滚设计与用户体验闭环。
当流程标准化后，多 Agent 协作将成为可复用的自动化研发流水线。
评论