OpenCode多代理系统：6代理7阶段工作流的生产级实践

本文深入解析一个生产级多代理OpenCode系统，包含6个专业代理、6个可复用技能、严格的权限隔离和7阶段执行工作流，专为大规模代码库的AI辅助软件工程而设计。

• 原作者/维护者: Rozariozaro
• 来源平台: GitHub
• 原始标题: opencode-subagents
• 原始链接: https://github.com/Rozariozaro/opencode-subagents
• 发布时间: 2026年5月23日

---

这是一个为OpenCode设计的生产级多代理系统，将结构化、确定性、高质量的AI辅助软件工程引入大规模代码库。系统实现了6个代理、6个技能，具备严格的关注点分离、确定性委托和强质量门禁。

设计目标：

• 🍎 iOS/macOS开发
• 🔀 Kotlin Multiplatform (KMP)项目
• 🖥️ 后端服务
• 🐳 Docker/DevOps工作流
• 📦 长生命周期模块化代码库
• 🤖 规模化AI辅助开发

核心原则：先读后写，所有实现必须经过专用审查员，每个代理仅拥有其所需权限。

---

┌─────────────────────────────────────────────────────────┐
│                     ORCHESTRATOR                        │
│         (规划 · 委托 · 验证 · 报告)                        │
└────────┬──────────┬──────────┬──────────┬──────────────┘
         │          │          │          │
    ┌────▼───┐ ┌────▼────┐ ┌──▼──────┐ ┌▼──────────┐
    │EXPLORE │ │IMPLEMENT│ │REVIEWER │ │DOC-WRITER │
    │        │ │   -ER   │ │         │ │           │
    │只读    │ │写·编辑  │ │批准/    │ │仅文档     │
    │分析员  │ │构建·测试 │ │拒绝     │ │           │
    │        │ │         │ │         │ │           │
    └────────┘ └─────────┘ └─────────┘ └───────────┘
         │
    ┌────▼──────┐
    │WEBSEARCH  │
    │           │
    │仅网络获取 │
    │(无本地    │
    │文件读取)  │
    └───────────┘

执行流程: Orchestrator → Explore/Websearch → Plan → Implement → Review → (Doc-write) → Report

---

代理	模式	模型	温度	角色
orchestrator	主代理	claude-sonnet-4.6	0.1	中央协调器；分析意图、规划、委托、验证
explore	子代理	claude-haiku-4.5	0.0	只读分析员；发现架构、追踪依赖、识别约定
implementer	子代理	claude-sonnet-4.6	0.2	代码执行者；编写/编辑代码、运行构建/测试
reviewer	子代理	claude-opus-4.6	0.1	质量门禁；验证正确性、一致性、可维护性
doc-writer	子代理	claude-haiku-4.5	0.2	文档维护者；仅更新变更日志、README和文档
websearch	子代理	claude-sonnet-4.6	0.1	技术研究分析员；框架对比、OSS发现、API研究

🎯 Orchestrator

唯一的主代理。拥有完整的7阶段工作流。

关键约束: 无编辑权限 — 只能规划和委托，不能写代码。

这强制了工作流纪律：Orchestrator不能绕过委托流程，必须依赖专业代理执行具体任务。

🔍 Explore

只读代码库分析员。发现架构、追踪调用图、识别约定和模式。

温度0.0: 最大化确定性，确保代码库分析可复现。

🔨 Implementer

精确执行实现计划。拥有编辑+受保护的bash权限。

关键约束: 遵循Orchestrator计划，不做架构决策。

🔬 Reviewer

使用最强模型(Opus)的质量门禁。只读权限，不能直接修复问题，只能批准或拒绝并提供结构化反馈。

这防止了"边审边改"的混乱，确保问题被明确记录和追踪。

📝 Doc-Writer

仅限于文档文件。仅在Reviewer批准后激活，不能触碰源代码。

🌐 Websearch

仅网络获取，无本地文件访问。用于框架对比、API版本检查、OSS发现和弃用验证。

---

技能	触发词	用途
diagnose	"debug this", "diagnose"	5阶段循环: 复现→最小化→假设→插桩→修复
zoom-out	"zoom out", 不熟悉的代码段	架构映射；显示更广泛的上下文、调用者、依赖
graphify	知识图谱请求	生成HTML+JSON知识图谱，带社区检测
websearch	研究、对比、查找、调查	高级技术研究分析员技能
handoff	会话收尾、上下文交接	将对话压缩为结构化交接文档
grill-with-docs	压力测试计划	根据领域模型和现有文档挑战计划

---

Orchestrator遵循严格的7阶段执行模型：

阶段1: 分析      → 解析意图，识别歧义，估算复杂度
阶段2: 探索      → @explore (代码库) 和/或 @websearch (外部)
阶段3: 规划      → 将发现综合为显式实现计划
阶段4: 实现      → @implementer 带完整计划+上下文+验证命令
阶段5: 审查      → @reviewer 在标记完成前查看所有变更
阶段6: 文档      → @doc-writer 仅在Reviewer批准后
阶段7: 报告      → 总结变更、注意事项、后续事项