https://www.knightli.com/tags/%E5%B0%8F%E6%A8%A1%E5%9E%8B/ Recent content in 小模型 on KnightLi的博客 Hugo -- gohugo.io zh-cn Fri, 15 May 2026 08:59:33 +0800 https://www.knightli.com/2026/05/15/token-efficiency-agent-orchestration/ Fri, 15 May 2026 08:59:33 +0800 https://www.knightli.com/2026/05/15/token-efficiency-agent-orchestration/ <p>AI 编程接下来真正重要的指标，可能不是“谁的模型最强”，而是谁能用更少的 token、更低的成本、更稳定的流程，完成更多可验收的工作。</p> <p>这就是 Token Efficiency 的价值。</p> <p>很多人理解 Token Efficiency，只会想到模型便宜、上下文变长、缓存命中更低价。但这些只是底层条件。真正能把它变成生产力的，是模型分工、任务编排、上下文预算和评估体系。</p> <p>换句话说，Token Efficiency 不是省钱技巧，而是一套把 token 转换成产出的工程方法。</p> <h2 id="deepseek-v4-的定位把大小模型分工产品化">DeepSeek V4 的定位：把大小模型分工产品化 </h2><p>这篇文章最应该先补上的背景，是 DeepSeek V4 的定位。</p> <p>DeepSeek V4 不是单纯发布一个更强模型，而是把 Token Efficiency 需要的两层能力直接拆成了 <code>V4 Pro</code> 和 <code>V4 Flash</code>：<code>Pro</code> 更适合做规划、推理、架构判断和关键审查，<code>Flash</code> 更适合做高频执行、批量改写、代码补全、资料整理和 agent 循环里的普通节点。</p> <p>这正好对应 AI 编程里的两个角色：</p> <ul> <li><code>V4 Pro</code>：当作 planner / consultant，用在需求拆解、技术方案、复杂 bug 根因、架构审查和最终验收。</li> <li><code>V4 Flash</code>：当作 executor，用在文件扫描、简单实现、测试补齐、文档整理、候选方案生成和重复性任务。</li> </ul> <p>DeepSeek 官方 API 文档显示，<code>V4 Flash</code> 和 <code>V4 Pro</code> 都支持 <code>1M</code> 上下文、JSON Output、Tool Calls、Chat Prefix Completion 和 FIM Completion；价格页也把缓存命中输入单独计价，并说明全模型 input cache hit 价格已降到发布价的十分之一。这几个点组合起来，才是它和 Token Efficiency 关系最密的地方。</p> <p><code>1M</code> 上下文解决的是复杂 agent 任务容易被压缩的问题；低缓存命中价格解决的是长系统 prompt、项目文档、代码片段和历史状态反复进入上下文的成本问题；<code>Flash / Pro</code> 双模型形态解决的是“每一步都用旗舰模型太贵、每一步都用小模型又不稳”的分工问题。</p> <p>所以 DeepSeek V4 的优势不应该只写成“便宜”或“上下文长”，而应该理解成三件事：</p> <ol> <li><strong>执行层便宜</strong>：大量 agent 节点可以交给 <code>V4 Flash</code>，让 token 消耗落在低成本模型上。</li> <li><strong>判断层可用</strong>：关键步骤仍然可以调用 <code>V4 Pro</code>，避免为了省钱牺牲复杂推理质量。</li> <li><strong>长链路友好</strong>：<code>1M</code> 上下文和缓存价格让代码库、文档、工具调用历史更容易留在可用窗口里。</li> </ol> <p>这就是为什么 DeepSeek V4 对 AI 编程的意义，不只是又多了一个模型选项，而是给“顾问模型 + 执行模型 + harness 编排”的模式提供了更现实的成本结构。</p> <h2 id="不要让最强模型干所有活">不要让最强模型干所有活 </h2><p>过去使用 AI，常见做法是找一个最聪明的模型，让它从需求分析、代码实现、测试、总结一路干到底。</p> <p>这个方式简单，但不一定高效。因为很多任务并不需要最高级别的推理能力。真正贵的模型，应该更像顾问、架构师或规划员：只在关键决策点介入。</p> <p>更合理的结构是：</p> <ul> <li>大模型负责拆问题、定方向、做关键判断。</li> <li>小模型负责执行、批量处理、重复修改。</li> <li>工具和 harness 负责流程、状态、上下文和验证。</li> <li>人负责定义产品、验收结果和决定取舍。</li> </ul> <p>这样做的好处是，前沿推理能力不会被浪费在机械执行上。大部分 token 消耗可以落到便宜模型和缓存输入里，贵模型只处理真正需要“脑力”的部分。</p> <h2 id="上下文不是越大越好">上下文不是越大越好 </h2><p>长上下文很重要，尤其是 coding agent。代码、文档、历史对话、测试输出、错误日志都会吃掉上下文。上下文一旦接近上限，模型就容易触发压缩、遗忘或误判。</p> <p>但长上下文不等于可以无限塞资料。</p> <p>Token Efficiency 的关键，是让每个任务都能在一个清晰、可控的上下文窗口内完成。最理想的状态不是“把整个仓库塞进去”，而是：</p> <ul> <li>当前任务只带必要文件。</li> <li>背景文档只带决策相关部分。</li> <li>历史信息只保留当前阶段需要的状态。</li> <li>每个节点有明确输入和输出。</li> <li>完成后把结果压缩成结构化摘要，交给下一个节点。</li> </ul> <p>上下文越便宜，越要警惕浪费。便宜 token 会诱导人把无关信息全塞进去，最后模型不是更聪明，而是更容易被噪声拖慢。</p> <h2 id="harness-比单个模型更重要">Harness 比单个模型更重要 </h2><p>如果只是把 Claude Code、Codex 或其他 coding agent 接到便宜模型上，效果未必好。小模型容易在长链路任务里跑偏，需要更强的流程控制。</p> <p>真正让小模型发挥价值的，是 harness。</p> <p>这里的 harness 可以理解为一套调度系统：它知道任务怎么拆、节点怎么跑、模型怎么选、结果怎么验收、失败怎么重试、上下文怎么传递。</p> <p>一个可用的编排系统，至少要回答几个问题：</p> <ul> <li>哪些任务需要规划？</li> <li>哪些任务可以直接执行？</li> <li>哪些节点可以并行？</li> <li>哪些节点必须串行？</li> <li>哪个节点用大模型，哪个节点用小模型？</li> <li>每个节点最多允许多少上下文？</li> <li>每个节点完成后输出什么结构？</li> <li>谁来 review，谁来决定是否继续？</li> </ul> <p>没有这层软件，小模型只是便宜；有了这层软件，小模型才可能变成杠杆。</p> <h2 id="用-dag-拆任务">用 DAG 拆任务 </h2><p>一个有效的思路，是把复杂任务拆成有向无环图，也就是 DAG。</p> <p>比如一个功能开发任务，可以拆成：</p> <ol> <li>需求澄清</li> <li>方案设计</li> <li>任务拆分</li> <li>编码实现</li> <li>测试补齐</li> <li>Code Review</li> <li>修复问题</li> <li>提交 PR</li> </ol> <p>每个节点都可以是一个独立 agent。它们运行在独立环境里，有自己的角色、prompt、工具权限和输出格式。节点之间不靠长篇聊天传递信息，而是靠预先定义好的结构化结果。</p> <p>这会带来两个直接收益。</p> <p>第一，单个节点更短。任务越小，越容易被小模型完成，也越不容易撑爆上下文。</p> <p>第二，流程更可测。你可以单独观察“编码节点失败率高”还是“review 节点漏问题多”，然后针对性优化。</p> <h2 id="任务可以跑多个副本">任务可以跑多个副本 </h2><p>当 token 足够便宜时，一个有趣的变化会出现：同一个任务不一定只跑一次。</p> <p>你可以让同一个任务用不同模型、不同 prompt、不同编排跑多个副本，再从结果里选最好的，或者把多个结果合并。这个思路有点像“抽卡式任务解决”，但前提是必须有评估和验收。</p> <p>适合多副本的任务包括：</p> <ul> <li>方案设计</li> <li>文案生成</li> <li>测试用例补全</li> <li>Bug 根因假设</li> <li>重构方案比较</li> <li>Code Review</li> </ul> <p>不适合盲目多副本的任务，是那些会直接修改共享状态、会产生外部副作用、或者验收标准不清楚的任务。</p> <p>多跑几次不是为了碰运气，而是为了获得可比较样本。样本越多，越能反过来优化编排、模型选择和节点技能。</p> <h2 id="必须建立评估体系">必须建立评估体系 </h2><p>Token Efficiency 不能只看价格。便宜但失败率高，最后会吞掉人的时间，反而更贵。</p> <p>所以每个团队都应该逐步建立自己的评估体系。它不需要一开始就很复杂，但要能量化。</p> <p>可以先记录这些指标：</p> <ul> <li>任务完成率</li> <li>人工介入次数</li> <li>工具调用失败率</li> <li>测试通过率</li> <li>Review 发现的问题数量</li> <li>单任务 token 成本</li> <li>单任务耗时</li> <li>返工次数</li> <li>不同模型组合的差异</li> </ul> <p>有了这些数据，才能知道哪些任务适合小模型，哪些任务必须上大模型，哪些任务应该交给人判断。</p> <p>真正的优化不是“所有地方都换便宜模型”，而是把每类任务放到最合适的模型和流程里。</p> <h2 id="业务流程要原子化">业务流程要原子化 </h2><p>普通用户不一定要自己写完整 harness。未来这类工具会越来越多，也会越来越成熟。</p> <p>但现在就可以做一件事：把自己的业务流程拆成原子节点。</p> <p>比如内容生产可以拆成：</p> <ul> <li>选题</li> <li>资料收集</li> <li>提纲</li> <li>初稿</li> <li>事实核查</li> <li>风格改写</li> <li>SEO 标题</li> <li>多语言翻译</li> <li>发布检查</li> </ul> <p>软件开发可以拆成：</p> <ul> <li>需求确认</li> <li>技术方案</li> <li>数据结构</li> <li>接口变更</li> <li>单元测试</li> <li>实现</li> <li>迁移脚本</li> <li>文档</li> <li>Review</li> </ul> <p>每个节点都要尽量做到输入明确、输出明确、验收明确、上下文可控。这样等 harness 工具成熟时，你的业务流程可以直接接进去。</p> <h2 id="硬件不是第一优先级">硬件不是第一优先级 </h2><p>很多人聊 Token Efficiency，很快就会聊到本地部署和显卡。但对大多数人来说，第一选择仍然应该是 API。</p> <p>原因很简单：在没有跑通经济模型之前，本地硬件只是成本前置。你还不知道 token 怎么转化成收入或生产力，就先买昂贵设备，很容易变成玩具。</p> <p>更稳的顺序是：</p> <ol> <li>先用 API 跑通业务流程。</li> <li>建立任务评估和成本统计。</li> <li>找到稳定高频的执行节点。</li> <li>再考虑哪些节点值得本地化。</li> <li>最后再计算硬件、电费、维护和折旧。</li> </ol> <p>如果只是个人提效，API 往往已经够用。如果是创业团队，要验证模型边界和推理框架，本地 CUDA 平台才更有学习价值。如果已经有明确生产场景和经济模型，多卡部署才有讨论空间。</p> <h2 id="小结">小结 </h2><p>Token Efficiency 的本质，不是“用便宜模型替代贵模型”，而是重新设计 AI 工作流。</p> <p>大模型负责关键判断，小模型负责批量执行，harness 负责调度和验证，人负责定义目标和验收结果。只有这四层配合起来，token 才能稳定变成生产力。</p> <p>接下来真正有价值的能力，不只是会用最新模型，而是能把任务拆小、把上下文控住、把结果量化、把流程编排起来。</p> <p>模型会继续降价，上下文会继续变长，小模型会继续变强。越是这样，越应该早点理解 Token Efficiency。因为未来的差距，很可能不在谁调用了最强模型，而在谁能用同样的 token 撬动更多真实产出。</p>