一、问题的起点为什么 Token 效率是硬指标AI 编码工具的核心成本是 Token。每一次模型调用、每一段上下文传入、每一轮对话——都在消耗 Token。大多数工具的默认行为是塞满上下文把所有文件内容贴进去、把历史对话全量带入、让最贵的模型做最简单的搜索。结果就是一个 typo 修复和一次架构重构花差不多的钱。这个问题有两个解法恰好可以叠加模型选择推理型任务用贵模型Pro检索/编辑/简单问答用便宜模型Flash。上下文策略引用而非粘贴、按需加载而非全量常驻、并行非串行、用完了就压缩。下面展开讲。二、双模型架构Pro 与 Flash 的分工逻辑DeepSeek 当前提供两档模型模型 能力定位 适用场景 相对成本deepseek-reasonerV4 Pro 深度推理、复杂决策 架构设计、根因分析、代码审查、重型重构 ~2xdeepseek-chatV4 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 ~1xplanner, deep-worker, oracle, reviewer, consultant, ui-builder Pro ~2x典型场景一个找到 XX 函数的定义的请求走 exploreFlash成本大约是走 OraclePro的一半。如果每天有 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-configGitHub。它的核心竞争力来自于 OpenCode 原生的多 Agent 框架能力——代理调度、权限隔离、会话管理、技能系统这些是这套设计能跑起来的平台基础。但双模型分工的理念不限于 OpenCode。第二个配置仓库my-deepseek-configGitHub把同样的理念横向扩展到了 7 个常用的终端 AI 编码工具工具 接入方式 双模型支持Claude Code Anthropic 兼容端点 deepseek-reasoner deepseek-chatCodex CLI 自定义 Provider / Profile --profile pro / --profile flashQwen Code OpenAI 兼容端点 /model 切换Gemini CLI OpenAI 兼容端点 /model 切换iFlow CLI OpenAI 兼容端点 /model 切换Kimi CLI OpenAI 兼容端点 Pro 默认开启 always_thinkingGitHub 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-orchestratorFlash直接改。约 3000 tokensFlash 模型。成本降约 70%。场景二新功能开发传统做法主模型边搜索边理解边写代码。上下文里全是原始数据容易丢失重点。优化做法exploreFlash搜索 → plannerPro出方案 → deep-workerPro实现。每一步的上下文都经过压缩和精炼。质量提升上下文更干净。场景三Bug 诊断传统做法主模型表面扫描 → 猜原因 → 改代码。优化做法OraclePro温度 0.1深度分析 → 输出结论 置信度 → 编排器决策 → deep-worker 修复。根因准确率远高于首轮猜测。场景四日常问答传统做法所有问题都走主模型。优化做法“find where X is” 走 exploreFlash“how to use Y API” 走 librarianFlash。只有why does Z happen 走 Pro。Flash 接管了大部分低成本请求。八、局限与取舍任何设计都有代价这套方案也不例外编排开销每次请求多一层意图识别和路由决策。简单请求的端到端延迟略高。但如果请求本身足够简单Flash Agent 的处理速度可以抵消这部分开销。配置复杂度11 个 Agent 15 个技能 全局规则出问题时排查成本不低。好处是改一个 Agent 的 prompt 不影响其他但要理解全局交互需要时间。框架绑定第一层深度依赖 OpenCode 的 Agent 框架能力。如果换框架需要重新适配。这也是为什么第二层多工具配置保持轻量——降低迁移成本。模型依赖双模型策略假设 Pro 和 Flash 的能力差距足够大使得分工有意义。如果未来两档模型趋同这套设计的边际收益会降低。但从目前趋势看模型分层只会更细。九、结语Token 效率不是一个省点钱的次要问题——它是 AI 辅助编码从能用到好用的关键变量。上下文塞满垃圾时模型再强也会给出次优输出合适的模型做合适的活不仅能省钱更能提升输出质量。这套设计的核心逻辑可以归结为三句话把任务分类把模型分层用最匹配的组合。把读和写分开把决策和执行分开每一步的上下文都精炼过。引用不粘贴按需不常驻复用不重建——Token 是靠习惯省出来的。