本文分享一套基于 OpenCode 框架和 DeepSeek V4 双模型的分层多智能体配置方案，探讨如何通过提示词工程（Prompt Engineering）实现低成本、高可靠的 AI 辅助开发工作流。纯配置实现，零额外依赖。
一、问题的提出
当前主流的 AI 编程助手大多采用"单体 Agent"模式------一个模型处理所有类型的任务。这种模式有几个明显的问题：
- 成本浪费：用推理能力最强（也最贵）的模型去搜索文件、查文档，就像用跑车送外卖。
- 注意力分散：单个上下文窗口同时容纳规划、搜索、实现、审查等多种活动，容易顾此失彼。
- 质量不稳定：同一个模型既要做深层推理又要做快速执行，很难在每个维度上都做到最优。
本方案的核心思路来自一个朴素的观察：开发工作中的任务天然存在不同的复杂度层级和成本敏感性。修一个拼写错误不需要 GPT-5 级别的推理能力，而定位一个隐蔽的并发 Bug 则绝不能交给轻量模型草草了事。
二、整体架构
2.1 两级模型分工
方案严格限定在 DeepSeek V4 的两个模型内完成所有工作：
| 模型 | 定位 | 典型场景 |
|---|---|---|
deepseek-v4-pro |
深度推理引擎 | 架构规划、根因分析、代码审查、复杂实现、主控调度 |
deepseek-v4-flash |
高速执行引擎 | 文件搜索、文档查询、轻量编辑、脚手架代码 |
关键设计原则：Flash 优先，Pro 兜底。能由 flash 完成的任务绝不浪费 pro------这个简单的路由策略在实践中能节省约 40-50% 的 Token 消耗。
2.2 十一个 Agent 的分层体系
系统由 1 个主编排器（Orchestrator）和 10 个专业子 Agent 组成，形成清晰的两层结构：
┌──────────────┐
│ Orchestrator │ ← 主入口，意图门控 + 任务分类 + 成本感知路由
└──────┬───────┘
┌───────────────┼───────────────────┐
┌──────┴──────┐ ┌──┴──────────┐
│ v4-pro 组 │ │ v4-flash 组 │
├─────────────┤ ├──────────────┤
│ planner │ 战略规划 │ explore │ 代码库搜索
│ deep-worker │ 重型实现 │ librarian │ 外部文档检索
│ oracle │ 深度分析（只读） │ light-orch. │ 轻量任务
│ reviewer │ 代码审查（只读） │ generalist │ 通用兜底
│ consultant │ 方案咨询 │ │
│ ui-builder │ 前端/UI │ │
└─────────────┘ └──────────────┘每个 Agent 都有明确定义的能力边界和"不做什么"，这是整个系统稳定性的基础。
2.3 意图门控：从"说什么"到"要什么"
Orchestrator 的核心能力是意图门控（Intent Gate）------识别用户的真实意图而非字面请求。这在实践中至关重要：
"帮我看看这段代码" → 是分析（oracle）还是审查（reviewer）？
"这个功能好难实现" → 是抱怨还是请求帮助规划（planner）？
方案定义了 17 种意图模式的识别表，每个模式有明确的语义标记和默认路由。例如：
"I'm seeing error X"→ 意图是修复问题 → 路由到 oracle 诊断 → deep-worker 修复"look into X"→ 意图是调查而非修改 → 路由到 explore 探索 → 报告结果"what do you think about X?"→ 意图是评估建议 → 路由到 consultant → 等待确认
这不是简单的关键词匹配，而是通过提示词引导 LLM 进行上下文推理。关键在于一个硬约束："Look into this" ≠ "Fix this"------在用户明确请求实现之前，绝不擅自修改代码。
三、成本感知路由：核心调度策略
3.1 委托决策表
Orchestrator 内置了一张委托决策快速参考表，解决"边界模糊时该找谁"这一高频难题：
| 任务形态 | 委托目标 | 反例（不应委托的情况） |
|---|---|---|
| 明确的搜索/查找 | explore 或 librarian | 一眼就能回答------直接处理 |
| 单文件小修改 | light-orchestrator | 涉及共享类型、数据库 schema 或公共 API |
| 多文件变更或新功能 | planner → deep-worker | 只是一行配置调整 |
| 无明确原因的 Bug | oracle | 错误信息已精确指出问题行 |
这背后是"最便宜可用原则"：能用 flash 不用 pro，能直接回答不启动子 Agent，能引用路径不粘贴文件。
3.2 降级与升级链
系统不是"一次性分配"后就放任不管。每个 Agent 都有预设的降级链：
deep-worker失败 → 重试一次 → 升级到planner重新规划 →deep-worker重新实现light-orchestrator不确定 → 升级到deep-worker（带走完整上下文）oracle找不到根因 → 转交deep-worker进行探索式调试librarian找不到文档 → 转交consultant提供经验主义建议
这种"优雅降级 + 上下文传递"的设计避免了 Agent 在能力边界死循环。
3.3 写作用域冲突检测
一个容易被忽视但致命的问题是：两个 Writer Agent 同时操作同一文件会导致不可逆的损坏。方案明确要求 Orchestrator 在每次分派 Writer 前检查是否有其他 Writer 正在同一文件集上工作，如有冲突则序列化执行。这个机制虽简单，却排除了多 Agent 系统中最高风险的故障模式。
四、执行与探索的严格分离
4.1 只读隔离
oracle、reviewer、explore、librarian 四个 Agent 被强制设置为只读模式 ------在配置层面直接禁用其 edit/write 权限。这不仅是安全措施，更是一种认知分工：
- 读 Agent 负责"搞明白"------它们分析、审查、搜索，输出的是洞察而非代码。
- 写 Agent 负责"做出来"------它们接收具体的执行指令，直接实施。
这种分离还有一个隐含好处：读 Agent 可以同时并发运行多个实例（例如同时搜索三个模块），而不用担心互相踩踏。
4.2 禁止研究与委托
deep-worker 和 light-orchestrator 被明确要求不研究、不委托。它们的职责是执行，所有必要上下文由 Orchestrator 在分派时提供。这避免了"Agent 找 Agent 找 Agent"的递归浪费。
如果 deep-worker 在执行中发现需要额外上下文（例如需要查外部 API 文档），它会向 Orchestrator 请求，由 Orchestrator 去调度 librarian 获取后再传回------上下文始终由调度层统一管理。
五、技能系统：按需加载的工作流模板
15 个技能（Skills）构成了方案的能力层。每个技能是一个可复用的工作流模板，Agent 只在需要时才通过 skill 工具加载，不常驻上下文。
5.1 代码审查技能：对抗性自检
code-review 技能值得单独一说。它借鉴了多 Agent 审查流水线的优点（维度覆盖、严重度校准、审查→修复循环），但将其浓缩进单个 reviewer pass 中，避免了多 Agent 流水线的 Token 开销。
它的核心创新是对抗性自检（Adversarial Self-Check）------在输出每个 finding 之前，审查者必须自行扮演"反驳者"角色：
- 我能反驳这个发现吗？ 构建一个反驳论证。如果反驳论证比原发现更强，丢弃。
- 严重度是否虚高？ 如果必须费力论证"这是 critical"，那它就不是 critical。降一级。
- 这是真实问题还是个人偏好？ 项目没有强制执行的风格偏好不是审查项。
同时附有显式拒绝准则：错误文件行号、未变更的旧代码、严重度虚高、纯风格偏好、重复项------一律驳回，不输出。
5.2 审查→修复的有界循环
/review-loop 命令实现了完整闭环：
Review → Fix (只修 critical/major + 明确的 minor) → Verify (format/lint/test) → Re-review停止条件：干净 / 最多 5 轮 / 停滞（同一问题连续两轮存在 → 暂停，交给人类）。这不是"永不停止"的理想化循环，而是工程化的有界收敛。
5.3 其他关键技能
| 技能 | 核心价值 |
|---|---|
spec-workflow |
explore → propose → apply → archive 四阶段规约驱动开发 |
deepwork |
审查门控分阶段执行：Plan → Review Gate → Implement → Verify → Report |
verify-with-docs |
编码前检索当前 API 文档，不用记忆编码------消除幻觉签名 |
reflect |
持续改进：回顾会话摩擦点，提出最小化配置修复 |
remove-deadcode |
LSP 验证的死代码安全删除 |
simplify |
行为保持的代码简化：减少嵌套、消除不必要抽象 |
六、AGENTS.md：全局共享的行为契约
AGENTS.md 是一个被所有 Agent 自动加载的共享规则文件。它不是"可选建议"，而是行为契约------定义了反模式清单、代码风格、注释纪律、自验证流程。
几个值得关注的设计：
"知道你的停止条件"原则：每个 Agent 在开始前必须自问------"什么可观测的条件意味着'完成'了？条件满足、变更验证通过 → 立即停止。不画蛇添足、不做无谓打磨、不做额外的验证循环。"
评论纪律：不写 AI 样板注释（"Initialize the service"），只写解释 WHY 而非 WHAT 的注释，不留被注释掉的代码------它们属于 Git 历史，不属于源文件。
Token 效率十七条：从"引用路径不粘贴文件"到"使用 codemap 替代盲目搜索"再到"复用 session 避免重建上下文"，形成了一套完整的 Token 节俭操作规范。
七、实践效果与关键权衡
经过 14 个版本的迭代打磨，这套方案在以下场景中表现突出：
- 复杂多文件变更：planner → deep-worker 链使得架构决策在动手前被充分论证，减少了返工。
- 代码审查：对抗性自检使得假阳性率显著低于简单的一遍过审查。
- Token 成本：flash 优先路由 + 技能按需加载 + 审查结果落盘回传（大 diff 时），累计可节省可观比例。
但同样存在明确的取舍：
- 延迟增加：plan → review gate → implement 增加了人工等待节点，适合质量敏感场景，不适合极速迭代。
- 提示词维护成本：11 个 Agent + 15 个技能 + 24 个命令的 Prompt 需要持续的版本演进和一致性维护。
- 上下文传递损耗：每次 Agent 间交接都涉及上下文压缩，信息密度高的细节可能丢失。
八、总结与启示
这套方案最核心的启示或许是：在多 Agent 系统中，"什么不交给谁做"比"谁做什么"更重要。 能力边界的清晰定义、执行与探索的严格分离、读写的权限隔离、写作用域的冲突检测------这些约束机制才是系统稳定性的基石，而非 Agent 数量或模型能力。
另一个关键认知是成本意识嵌入路由层。将模型成本作为一等公民纳入调度决策，而不是等账单来了才后悔------这是工程思维在 AI 时代的自然延伸。
对想要实践类似方案的读者，建议从以下几步开始：
- 先定义你的任务分类体系（哪些任务走轻量模型、哪些必须用强模型）
- 建立意图识别机制（哪怕是最简单的关键词映射 + 确认）
- 把读 Agent 设为只读（安全措施 + 认知分工）
- 将高频工作流沉淀为可复用技能
- 逐步迭代------不需要一次性搭建完整体系
这套方案是纯配置驱动的------所有能力由 opencode.json + agent/*.md + skills/*/SKILL.md + AGENTS.md 四个层次的提示词工程实现，无需任何外部工具或服务。如果你正在使用 OpenCode 或类似的 Agent 框架，欢迎参考和提出改进建议。
项目地址：https://github.com/znlgis/my-opencode-deepseek-config
作者注：本方案借鉴了 oh-my-openagent、oh-my-opencode-slim、anomalyco/opencode、Fission-AI/OpenSpec、deepreview、cli/cli 等多个社区项目的设计精华，在此致谢。