Token 效率优先：DeepSeek 双模型在 AI 编码工具中的分工实践

用最小的上下文成本达到最好的开发效果------这不是口号，是可以用配置精确量化的工程问题。

一、问题的起点：为什么 Token 效率是硬指标

AI 编码工具的核心成本是 Token 。每一次模型调用、每一段上下文传入、每一轮对话------都在消耗 Token。大多数工具的默认行为是"塞满上下文"：把所有文件内容贴进去、把历史对话全量带入、让最贵的模型做最简单的搜索。结果就是：一个 typo 修复和一次架构重构花差不多的钱。

这个问题有两个解法，恰好可以叠加：

模型选择：推理型任务用贵模型（Pro），检索/编辑/简单问答用便宜模型（Flash）。
上下文策略：引用而非粘贴、按需加载而非全量常驻、并行非串行、用完了就压缩。

下面展开讲。

二、双模型架构：Pro 与 Flash 的分工逻辑

DeepSeek 当前提供两档模型：

模型	能力定位	适用场景	相对成本
`deepseek-reasoner`（V4 Pro）	深度推理、复杂决策	架构设计、根因分析、代码审查、重型重构	~2x
`deepseek-chat`（V4 Flash）	快速响应、高吞吐	代码搜索、文档查询、单文件编辑、配置修改	~1x

两档模型不是"好"和"差"的关系，而是不同任务的最佳匹配。关键认知：

一个 typo 修复不需要 Pro 的推理能力。一次根因分析不该信任 Flash 的浅层扫描。

这是分工的出发点。但问题在于：谁来做出这个路由决策？ 如果每做一个操作都要人工判断该用哪个模型，这套设计就没人会用。所以需要一个自动化的编排层。

三、编排层设计：意图识别与成本感知路由

编排器（Orchestrator）的工作不是执行，是路由。它分析每一个用户请求，归类到 6 种任务类型，然后选择最合适的子代理。

3.1 意图门控

用户说的话和真正想做的事，经常不是一回事。编排器的第一层就是意图识别表：

用户表达	真实意图	路由目标
"解释一下 X"	研究/理解	explore → 综合 → 回答
"实现 X 功能"	明确实现	planner → deep-worker
"看看 Y 怎么回事"	调查	explore → 报告
"我遇到这个报错"	需要修复	oracle → 诊断 → deep-worker
"重构一下 Z"	开放式变更	oracle 评估 → planner 提案
"帮我分析 W"	深度调查	oracle → 分析报告
"X 还是 Y 好"	决策支持	consultant → 评估选项

17 种模式覆盖了日常开发中绝大部分场景。编排器在执行之前先对意图做一次归类------这一步看似慢，实际上避免了"用重武器打蚊子"的浪费。

3.2 三条路由铁律

编排器内部有明确的路由纪律，不是简单的 if-else：

铁律一：Flash 优先，Pro 升级。

"Flash-first for defined work. If the task is well-defined and a flash agent can handle it, route there first. Only escalate to pro when flash is out of its depth."

命名的搜索/查找/小编辑工作一律先走 Flash。Flash 搞不定了，再将完整上下文移交 Pro 继续。Pro 是升级路径，不是默认选项。

铁律二：Pro 用于推理，绝不用于查找。

"Pro for reasoning, never for lookup. Never waste pro on 'find where X is' or 'look up Y docs'."

在代码库里找东西、查文档、翻 API 参考------这些是 explore 和 librarian 的活（都是 Flash 代理）。让 Pro 做这些，相当于雇架构师去翻文件夹。

铁律三：未规划不构建。

"Plan before building. For any task touching 2+ files or involving architectural decisions, always delegate to planner first."

涉及架构层级的变更，一定先让 planner 出 Handoff Plan，再由 deep-worker 执行。跳过规划直接开工的代价远大于规划本身。

四、Agent 角色体系：执行与探索的严格分离

这是整套设计中最核心的结构性决策：把"读"和"写"彻底分开。

4.1 十一 Agent 全景

复制代码

Sisyphus (编排器) ── Pro ── 路由，不动手
    │
    ├── Prometheus (规划师)  ── Pro ── 出方案，不写代码
    ├── Hephaestus (实现者)  ── Pro ── 只管写，不许查
    ├── Oracle (分析师)      ── Pro ── 只读，根因诊断
    ├── Momus (审查者)       ── Pro ── 只读，找问题
    ├── Metis (顾问)         ── Pro ── 权衡，不给代码
    ├── Multimodal (前端)    ── Pro ── UI/UX，不看后端
    │
    ├── Sisyphus Jr. (轻量)  ── Flash ── 单文件小改
    ├── Explore (搜索)       ── Flash ── 只读，代码库扫描
    ├── Librarian (检索)     ── Flash ── 只读，外部文档
    └── Atlas (通用)         ── Flash ── 兜底杂活

4.2 只读 Agent 的硬约束

Oracle、Reviewer、Explore、Librarian 这四个 Agent 在配置中直接锁死了写权限：

json 复制代码

"permission": {
  "edit": "deny",
  "write": "deny",
  "task": "deny"
}

它们只能返回文本报告。这不仅仅是安全措施------它强制了单向数据流：信息从只读 Agent 流向编排器，编排器决策后再派给写 Agent。不存在"边读边改"的中间态，每一步的责任清晰。

4.3 写 Agent 的"三不"纪律

Deep Worker 和 Light Orchestrator 有明确的执行纪律：

"No research, no delegation. Do not delegate to explore, librarian, or other subagents."

写代码的 Agent 禁止自己去做研究。它需要的所有上下文由编排器在派发时一次性提供。这个设计的逻辑是：

写 Agent 的上下文很贵（Pro 模型），不应该被搜索操作填满
搜索和决策在派发前已经由编排器和 Flash Agent 完成
写 Agent 拿到的是结论而非原始数据，能专注在实现上

五、Token 效率的七种武器

以上是架构设计。下面是具体的 Token 节省策略------每一招都对应一类常见的浪费。

武器一：引用路径，不粘贴文件

这是最贵的一个习惯 。编排器派发任务给子代理时，传的是 src/app.ts:42，而不是把整个文件内容贴进 prompt。子代理自己需要什么读什么------它的上下文是自己的成本，不污染编排器。

"Pasting files is the single most expensive routing mistake --- the subagent can read what it needs."

武器二：右尺寸路由

每种 Agent 都标注了相对成本。编排器做路由决策时，这是一个显式的权衡因素：

Agent	模型	相对成本
explore, librarian, light-orchestrator, generalist	Flash	~1x
planner, deep-worker, oracle, reviewer, consultant, ui-builder	Pro	~2x

典型场景：一个"找到 XX 函数的定义"的请求，走 explore（Flash），成本大约是走 Oracle（Pro）的一半。如果每天有 50 次这种请求，差距就很显著了。

武器三：先查文档，再写代码

训练数据有截止日期，第三方库天天在变。凭记忆写 API 签名------写的时候便宜，调试的时候贵得多。verify-with-docs 技能强制执行检索优先：

"Your training data has a cutoff and libraries move fast. Guessing an API from memory is cheap to write and expensive to debug. Retrieve before you write."

一次幻觉签名的调试成本远超一次文档查询。这不是理论------每天都在发生。

武器四：技能按需加载

15 个技能（code-review、spec-workflow、simplify、security-review 等）全部存放在磁盘上，只在触发条件命中时才加载到上下文。没有哪个 Agent 在启动时携带所有技能。

这跟传统做法的差别很大：许多工具的做法是把所有系统指令全量塞进 system prompt，不管当前任务用不用得到。按需加载意味着上下文里只有当前任务需要的东西。

武器五：复用子代理会话

编排器维护一个 task_id 表。当一个任务需要多次回到同一个子代理时，不创建新会话，而是 resume 已有会话。子代理已经加载了相关上下文，续用比重启便宜得多。

"Prefer reusing an existing subagent session over spawning a fresh one --- carried context saves tokens."

武器六：Codemap 替代盲目探索

进入一个不熟悉的仓库时，传统的做法是 glob + grep 满世界撒网。codemap 技能生成一个结构化的带注释目录树------一次调用替代十几次探索性搜索。

"One codemap can replace a dozen exploratory searches."

武器七：自动上下文压缩

通过 OpenCode 的 compaction 机制：

json 复制代码

"compaction": {
  "auto": true,
  "preserve_recent_tokens": 16000,
  "reserved": 10240,
  "tail_turns": 10
}

当一个探索线索得出清晰结论后，原始数据被压缩成摘要，释放上下文窗口。实现工作从一个干净的上下文开始------只带着规划和结论，不带着探索过程的原始对话。

六、两层配置：从单框架到多工具

上述所有设计首先落地在 OpenCode 这一个框架中（my-opencode-deepseek-config，GitHub）。它的核心竞争力来自于 OpenCode 原生的多 Agent 框架能力------代理调度、权限隔离、会话管理、技能系统，这些是这套设计能跑起来的平台基础。

但双模型分工的理念不限于 OpenCode。第二个配置仓库（my-deepseek-config，GitHub）把同样的理念横向扩展到了 7 个常用的终端 AI 编码工具：

工具	接入方式	双模型支持
Claude Code	Anthropic 兼容端点	`deepseek-reasoner` + `deepseek-chat`
Codex CLI	自定义 Provider / Profile	`--profile pro` / `--profile flash`
Qwen Code	OpenAI 兼容端点	`/model` 切换
Gemini CLI	OpenAI 兼容端点	`/model` 切换
iFlow CLI	OpenAI 兼容端点	`/model` 切换
Kimi CLI	OpenAI 兼容端点	Pro 默认开启 `always_thinking`
GitHub Copilot CLI	指令注入 + MCP 桥接	模型由 GitHub 托管

每个工具的配置量都很小------一个指令文件（如 CLAUDE.md、AGENTS.md、QWEN.md）加上一个端点配置（settings.json）。没有 Agent 生态、没有技能系统、没有编排层，但双模型切换和 Token 效率思想 通过 shared/RULES.md 统一注入到了所有工具中。

两层配置的关系是：

第一层 （OpenCode）：发挥框架全部能力，构建完整的 Agent 分工、技能、审查体系------这是原生实现。
第二层 （多工具）：将核心思想（双模型分工 + Token 效率守则）以最小配置量注入其他工具------这是轻量适配。

七、可量化的效果

这些策略组合在一起，效果是可以估算的：

场景一：typo 修复

传统做法：主模型读文件 → 改一行 → 返回。约 5000 tokens，全是 Pro 模型。
优化做法：light-orchestrator（Flash）直接改。约 3000 tokens，Flash 模型。成本降约 70%。

场景二：新功能开发

传统做法：主模型边搜索边理解边写代码。上下文里全是原始数据，容易丢失重点。
优化做法：explore（Flash）搜索 → planner（Pro）出方案 → deep-worker（Pro）实现。每一步的上下文都经过压缩和精炼。质量提升，上下文更干净。

场景三：Bug 诊断

传统做法：主模型表面扫描 → 猜原因 → 改代码。
优化做法：Oracle（Pro，温度 0.1）深度分析 → 输出结论 + 置信度 → 编排器决策 → deep-worker 修复。根因准确率远高于首轮猜测。

场景四：日常问答

传统做法：所有问题都走主模型。
优化做法："find where X is" 走 explore（Flash），"how to use Y API" 走 librarian（Flash）。只有"why does Z happen" 走 Pro。Flash 接管了大部分低成本请求。

八、局限与取舍

任何设计都有代价，这套方案也不例外：

编排开销：每次请求多一层意图识别和路由决策。简单请求的端到端延迟略高。但如果请求本身足够简单，Flash Agent 的处理速度可以抵消这部分开销。
配置复杂度：11 个 Agent + 15 个技能 + 全局规则，出问题时排查成本不低。好处是改一个 Agent 的 prompt 不影响其他，但要理解全局交互需要时间。
框架绑定：第一层深度依赖 OpenCode 的 Agent 框架能力。如果换框架，需要重新适配。这也是为什么第二层多工具配置保持轻量------降低迁移成本。
模型依赖：双模型策略假设 Pro 和 Flash 的能力差距足够大，使得分工有意义。如果未来两档模型趋同，这套设计的边际收益会降低。但从目前趋势看，模型分层只会更细。

九、结语

Token 效率不是一个"省点钱"的次要问题------它是 AI 辅助编码从"能用"到"好用"的关键变量。上下文塞满垃圾时，模型再强也会给出次优输出；合适的模型做合适的活，不仅能省钱，更能提升输出质量。

这套设计的核心逻辑可以归结为三句话：

把任务分类，把模型分层，用最匹配的组合。
把读和写分开，把决策和执行分开，每一步的上下文都精炼过。
引用不粘贴，按需不常驻，复用不重建------Token 是靠习惯省出来的。

如果你在使用 AI 编码工具时感觉"模型很强但输出不稳定"或"小任务成本太高"，不妨试试从 模型分层 和 上下文纪律 两个维度做优化。不需要一次配齐十一 Agent------先从一个意图识别表开始，把搜索和编辑路由到 Flash 模型，效果立竿见影。