Mixdog 开源编程代理主打低令牌开销

编码 Agent 的 token，不一定花在写代码上。读文件、重复发送上下文、给简单步骤调用高强度推理，都可能消耗额度。Mixdog 的作者据此做了一个开源 Agent，并声称：在同模型、同成功率的测试中，它比 Codex CLI 少用 63% 的 token。

值得看的不只是这个数字，还有背后的三种做法：按任务分配模型、自动调整推理强度、压缩上下文。不过，基准测试结果能否落到你的仓库里，还需要分开判断。

少用 63% 的 token，是怎么比出来的

作者称，测试覆盖全部 89 个 Terminal-Bench 2.1 任务，每个任务运行 5 次。Mixdog 和 Codex CLI 都使用 GPT-5.6 Sol，推理强度为 xhigh，由官方 Harbor verifier 判定结果。

报告给出的结论是：两者成功率相同，Mixdog 的 token 用量少 63%，且在 89 个任务中的 87 个上用量更低。这比只展示几次成功案例更有参考价值。

但原文没有列出具体成功率、token 总量和结果波动，也没有交代重试等配置是否完全一致。作者称，全部判定结果、日志和脚本都已放进仓库，可以检查或重跑；这里提供的材料不足以独立核验。

另一组测试使用 Claude Opus 5：Mixdog 比 Claude Code 多解决 2 个任务，成本低 19%。这里比较的是成本，不能直接当成 token 节省比例；原文也没展开这组测试的完整配置。

这些数字支持继续检查 Mixdog，但还不足以证明它在所有代码仓库里都更省。

它省的是哪些开销

第一种做法是让强模型带队，便宜模型执行搜索、编辑和审查，并行推进。用户可以从单模型切换到完整的多 Agent 协作，也能在对话中途调整。

这个思路容易理解：规划需要较强的判断力，定位文件等步骤未必需要同样昂贵的模型。但分工也会产生消息传递和协调开销。原文没有给出单模型与多模型的独立对照，无法判断那 63% 中有多少来自分工。

第二种做法是自动选择推理强度。一个 150 MB 的本地模型在 CPU 上运行，约用 0.1 s 评估每条消息和每个工具步骤，再选择所需强度，让简单操作少消耗 xhigh 推理。

这里有个需要核对的细节：作者同时说基准测试两边都使用 xhigh，却没有说明测试期间是否启用了自动降档。这个设置会影响我们怎样理解「同配置比较」。

第三种做法是精简上下文。Mixdog 会压缩工具结果和历史记录，并通过上下文视图展示 token 花在哪里。它瞄准的是反复读文件、反复发送旧信息的开销。

压缩也有代价：删掉无关日志有帮助，漏掉约束或错误细节则可能增加返工。原文没有说明压缩策略，也没有单独测量它的贡献。

我的判断

我更认可的是先检查 Agent 的执行过程，再决定是否需要更强的模型。上下文是否重复、工具输出是否冗长、简单步骤是否一直使用高推理强度，这些都值得量化。

不过，Mixdog 在文中展示的是一整套方案。模型分工、推理调度和上下文压缩各自有多大作用，目前没有拆开验证。对一般团队而言，先优化现有 Agent 的文件读取范围和上下文管理，改动可能更小；哪种方式更划算，原文没有对照数据。

Mixdog 还把产品范围扩到了完整桌面工作区：编辑器、终端、Git、GitHub、代码图谱和语言服务器，以及浏览器与桌面控制、Office 和 PDF 处理、图片与视频生成、目标持续执行、定时任务和 webhooks。作者也宣称支持通过端到端加密从手机继续工作。这些是能力声明，不能由前面的编码测试顺带证明成熟度。

它支持 Windows、macOS、Linux，免费并采用 Apache-2.0 许可证。接入方式包括 Claude、ChatGPT、Grok、Muse Code 订阅、API key，以及在自有 GPU 上运行本地模型。订阅额度和重置时间可以在面板查看，但原文没讲清各接入方式的具体限制。

能拿来做什么

• 如果你经常撞到 AI 编程额度上限，先观察一个完整任务里读了多少文件、重复发送了多少上下文，以及哪些简单步骤仍在高强度推理。把消耗位置找出来，才能判断换工具是否解决问题。

• 想试 Mixdog，可以挑现有前端或 Node 仓库里一个边界清楚的修复任务，与当前工具比较完成质量、token、耗时和返工次数。作者称无需配置文件，并提供五步教程；也可以通过终端安装：

  npm install -g mixdog
  

  注意命令中的 -g，它会进行全局安装。

• 评估自动推理和多模型分工时，记录实际使用的模型与推理强度。尤其要核对 xhigh 是否始终启用，避免把配置差异算成工具本身的收益。