用上下文窗口省 Token 实战

　　先说结论：在 Agent Plan 这种没有上下文缓存的套餐里，1M 超大上下文窗口不是白送的福利，而是每轮对话都在烧钱的无底洞。我的博客写作从 1M 收到 128K 之后，单篇千字博文的 Token 消耗降了一个数量级，正文没丢过一个字。这篇把原理、配置和三种场景的完整参数一次讲清楚。

一、先看账：有缓存和无缓存差在哪

主流订阅制 AI 套餐的计费分两类，差别在"重复读同一段历史要不要钱"：

• 有缓存（上下文缓存）：上一轮算过的历史会被缓存，本轮只对新增部分计费。长会话历史动辄十几万 token，但真正花钱的只有增量，所以大窗口几乎零额外成本。
• 无缓存（如 ZCode Agent Plan）：不存在任何缓存，每轮都把全部历史上下文完整加载一遍重新计费。历史 10 万 token，聊 100 轮就是 100 个 10 万 token 的钱，重复地烧。

我核过 ZCode Agent Plan 的计费说明：按"每轮请求的完整上下文长度"计费，没有缓存层。这决定了后面所有策略——无缓存套餐里，上下文窗口大小直接决定单轮成本上限。

二、认知纠偏：窗口不是越大越好

很多人挑套餐时盯着"上下文越大越高级"，这是有缓存时代的惯性思维。在无缓存套餐下，窗口上限 = 单轮计费上限：

• 上下文 1M，意味着任意一轮对话都可能按接近 100 万 token 计费；
• 上下文 128K，单轮计费被硬性压到 12 万出头，成本差近一个数量级。

窗口大唯一的好处是"能塞进更多内容"，但对单篇 1500 字的短博文、写几段配置、调一个报错这种粒度的工作，1M 的容量 99% 是浪费——塞不满，却要为"塞不满的上限"承担计费风险。

还要说个更隐蔽的坑：无缓存下窗口过大，会把偏离主题的陈旧对话、无关工具输出全带进每一轮。上下文越长，模型在无关信息里翻找关键指令越难，Token 消耗变高，回答质量反而变差。窗口不是越大越好，是够用且尽量小最好。

三、ZCode /goal 长程任务为什么不怕小窗口

你可能会担心：窗口收小了，长任务做到后面，关键信息会不会被挤掉？

更要紧的是 ZCode 的 /goal 长程任务：它把大目标拆成多步，每步仍是"完整上下文 + 新指令"一轮。无缓存下这恰恰最怕大窗口——目标越大、步骤越多，重复计费的历史就越长。收小窗口从根上砍掉了这个乘法。

而且 /goal 里真正要模型"记住"的，不是海量过程，而是锚点信息，体量极小：

• MCP 凭证：一段环境变量或 token，几十个字符；
• Git 账号身份：user.name / user.email，两行；
• 写作规范：frontmatter 结构、每段两个全角空格、标签写法，几百字封顶。

这些锚点加起来也就一两千 token。128K 窗口装下它们绰绰有余，只要它们是"每轮都显式携带"的固定指令，就永远不会被截断。真正会被挤掉的是那些已经用完的中间产物——而那些本来就该被丢弃。把"窗口塞满过程垃圾"换成"窗口只装锚点 + 当轮增量"，是省 Token 的核心操作。

四、三套完整配置

下面三组配置覆盖我的三个真实场景。注意：ZCode 的上下文规格在各模型设置里选，下面的 JSON 展示的是对应 limit.context 配置与配套的 /goal 起始指令。

场景一：纯短文写作（默认推荐）

单篇 1500 字博文，写完即走，历史基本无用。128K 足够，也是我现在的默认值。

{
  "model": "GLM-5.3",
  "reasoning": "high",
  "contextLimit": 128000,
  "goalTemplate": "任务：写一篇 1500 字 Hugo 技术博文。\n写作规范（每轮必须遵守）：\n- frontmatter：title/date/description/tags/draft:false\n- 正文每段以两个全角空格开头\n- 标签用英文，如 [\"AI\",\"ZCode\"]\n- 完成后只输出 Markdown 正文，不啰嗦过程\n目标文件：content/posts/<slug>.md"
}

场景二：日常综合工作（平衡推荐）

兼顾 CNB MCP 调试（工具输出较长）+ Hugo 站点配置修改（hugo.toml、模板）+ 偶尔写短文。MCP 的工具返回可能一次几千 token，256K 留足余量，同时不会像 1M 那样失控。

{
  "model": "GLM-5.3",
  "reasoning": "high",
  "contextLimit": 262144,
  "goalTemplate": "任务：综合开发工作（CNB MCP 调试 + Hugo 站点维护）。\n锚点信息（每轮必须携带，勿截断）：\n- MCP 凭证：API_TOKEN 存于 ~/.zcode/cli/config.json 的 mcp.servers.cnb.env\n- Git 身份：user.name=cnb / user.email=cnb@cnb.cool\n- 站点根：c:\\Users\\Administrator\\Desktop\\hugo\n- 构建：.tools\\hugo.exe --minify --cleanDestinationDir\n调试完 CNB 工具后主动清理其长输出，再继续后续任务"
}

场景三：深度主题调试（长任务专用）

多步排查、跨文件改配置、一次做完一个完整闭环。此时才需要更大窗口，512K 是我实测不卡顿的平衡点——仍然不建议 1M。

{
  "model": "GLM-5.3",
  "reasoning": "max",
  "contextLimit": 524288,
  "goalTemplate": "任务：深度主题调试（多步、跨文件）。\n关键规则：\n- 每完成一个排查步骤，用一句话归档结论，删除该步骤的原始长输出，控制上下文增长\n- 只保留锚点：MCP 凭证、Git 身份、构建命令、目标文件路径\n- 遇到报错先贴单条错误，不要批量贴日志\n- 完成前在结尾列出：改动文件清单 + 验证命令 + 未决问题"
}

五、四档上下文规格横向对比

六、落到我的使用场景的最终建议

我的日常工作就三类：单篇 1500 字博文、CNB MCP 调试、Hugo 站点配置修改。

• 写博文：用场景一（128K）。内容体量决定了它永远是"短文场景"，1M 纯属为用不上的容量付费，这是我省 Token 的最大来源。
• CNB MCP 调试：用场景二（256K）。MCP 工具返回可能一次几千 token，128K 偶尔会紧，256K 留足余量又不会失控。关键是每轮让模型主动清理已用完的工具长输出。
• Hugo 配置修改：也是场景二（256K），或临时升到场景三（512K）做跨文件联动修改，改完降回来。
• 综合结论：默认 128K 打底，调试任务临时升 256K，深度长任务才上 512K，日常永远不要碰 1M。 配合"每轮只保留锚点 + 清理中间长输出"的纪律，单篇千字博文的 Token 消耗比用 1M 时降了一个数量级，而 MCP 凭证、Git 账号、写作规范这些关键信息一次都没丢过。

　　无缓存套餐省 Token 不是玄学：窗口收到"够用"，锚点显式携带，中间产物及时丢弃。三件事做到，钱省了，质量反而更高。