一、问题的起点：为什么 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 在配置中直接锁死了写权限：
“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 机制：
“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 是靠习惯省出来的。
