今天的一个画面：我的 AI Agent 在终端里干活，我在它旁边并行开发了一个新功能——一个 token 额度的调度台。
现在打开工作台，手里几家 coding 资源的状况一目了然：Kimi 的额度用了百分之几、什么时候重置，Codex 的窗口余量，DeepSeek 还剩多少余额。以前是凭感觉用，超了才知道；现在是先看见，再决定怎么用。
顺带说一句，这个调度台本身也是人机协作的产物：我提需求，AI 给技术选型，我点头，加上验收。《这个博客，我只参与了三次》里说的那种分工，今天继续生效。
第一笔账：为用不上的能力付费，是最隐蔽的浪费 #
今天我把默认模型从 K3 切到了 K3-256k。区别在一个数字：单次对话能吃下的上下文上限，从一百万 token 降到二十五万。
为什么敢降？因为我估计了一下自己的真实场景：95% 的任务，二十五万上下文以内足够解决。写代码、改配置、整理知识库，没几个真的需要把一百万 token 塞满。
但这里有个顺序要说清楚，不然容易误读成「一开始就该用低配」。我的策略恰恰相反：一开始，在能选的范围内选最好的，不去纠结上下文会不会超，先用——保留必要的冗余，不为「万一不够」提前焦虑。等到额度真的紧张了，再按当时的情况降配。
降配不是赌博。因为我手里有那个 95% 的估计——知道降完之后绝大多数场景照样跑得动。这个判断不来自教程，来自天天用。
第二笔账：不折腾，也是一种决策 #
接着说 DeepSeek harness，圈子里讨论得挺热，这事我不是没看——我看了它的设计理念，还派 Agent 去调研、简单测了一下。
先说好的部分。它那个「轨迹」的设计确实好，有点 agent runtime 的味道。而 runtime 这个东西，是当下很热、也很值得去了解的方向。它的仓库应该算是有史以来最快突破 10 万 star 的，围绕它的生态明显有未来——这个很重要。
但我测完的结论很明确：迁移成本确实高，用起来也不是很流畅。我的工作流长在 Kimi CLI 上，技能、hooks、工作台、派单流程全围着它搭，迁移不是换个命令，是把整套结构搬一遍。
还有一笔更直接的账：DeepSeek 的模型 API 调用成本整体上升了。算下来，当下性价比最高的可能还是 Codex；国内这边，用 Kimi 做备用主力。这就是调度台存在的意义——哪家划算、额度怎么排，是算出来的，不是追出来的。
所以它很「未来」，但正因为这个未来还在快速变化，对个人而言，它是可以等的。何况 Kimi 3.1 已经在内测，等的成本很低。追新的反面不是守旧，是先测一下，再算账。
第三笔账：写东西这件事，读者不只是人 #
这个博客存在了几天了，今天说清楚它存在的一个硬理由。
以前有句话：授人以鱼不如授人以渔。现在好像有点反过来了——我不要渔，你直接给我鱼。很多东西我们只需要知道它的大致重点和推理过程，执行直接交给 AI，我们只负责判断。
所以现在最理想的内容形式是：这是一篇文档，这是它的链接，照着复刻。人读完给 Agent 一丢，事就干起来了。
但微信自带反爬机制。文章发在公众号，人读完，Agent 想照着复现里面的内容，中间得自己搭一层爬虫——这得懂点技术。不是完全读不了，是使用体感上产品体验不好：我自己用都不顺畅，别人想用，还得我一步步写清楚「先怎么做，再怎么做」，这就很累了。
所以博客用 Markdown 呈现：人打开是好读的页面，Agent 打开是能直接吃的文本。一份内容，两类读者。
最后 #
今天三件事：装调度台，是看见资源；定降配策略，是管理资源；用 Markdown 写博客，是让产出可复用。
看起来不相干，其实是同一个动作：给 AI 协作搭结构。AI 越强、越便宜、选择越多，「算账能力」就越值钱——而算账的第一步，永远是先看清自己手里有什么。
调度台还有个后招：等它能算出每天烧掉的 token 折合成多少钱，那种「白嫖感」会很强——越用越想用。能让人愿意持续算账的调度台，才算真的装好了。
账，接着算。