问题的提出当前主流的 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 → Reportverify-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 设为只读安全措施 认知分工将高频工作流沉淀为可复用技能逐步迭代——不需要一次性搭建完整体系