技术 · 熟练
你的上下文账单，在写原型那天就定了
省 token 的关键不是压得狠，是当初选对了什么进窗口
「上下文太长」这件事，最后一定以账单的形式出现在你面前 —— 但账单不是压出来的，是当初选出来的。Microsoft 在 2026 年 9 月 2 日那篇企业 agent 成本文章里指出一个很具体的反模式：很多系统在原型阶段就把「模型每一轮看到什么」定死了，之后再也没有回看过 —— 而这一层恰恰可能主导运行成本和答案质量。
这一页是站上《token预算》的下一步：那边讲的是「怎么在塞满前主动管理」，这里讲「怎么算钱、钱花在哪、以及哪些成本项你从来没数过」。核心结论只有一句：目标不是 token 最少，而是在能可靠完成任务的前提下，最小的那个高价值上下文。
方法 · 一图看懂
1
先把「模型每轮看到什么」列成一张清单 — 系统指令 · 工具描述 · 检索结果 · 记忆 · 历史 · 工具结果 —— 逐项标出它是常驻还是按需
2
算一遍结果成本，而不是单次价格 — 结果成本 = Σ(输入 + 缓存 + 输出 + 工具费) + 重试 + 失败运行 + 人工纠正
3
找出那三项从来没人数的成本 — 重试、失败、人工纠正；它们往往比模型费更贵，而且不写在账单上
4
把「常驻」改成「按需」 — 检索优于全读，工具描述按需加载；常驻的东西每轮都在付费
5
定一个复看时机 — 原型期定的上下文清单不算定稿，给它排一次复看（改需求时 / 账单异常时 / 换模型时）
原理 · 为什么有效
为什么说「账单是当初选出来的」？因为 agent 不是一次模型调用，而是一个循环：它规划、调工具、读结果、再推理。一次成功的输出可能包含很多次模型请求，而「模型每轮看到什么」这一份清单，会被乘上轮数反复计费。你当初为了省事把整份工具目录、整份项目说明塞进了系统提示，这份「省事」就会在之后每一轮里各收一次钱。
第二层原因：成本项和直觉不一致。真正贵的三项是重试、失败运行与人工纠正 —— 它们不体现在 token 单价上，只体现在「同一件事做了三遍」和「人要回来收拾」上。一次失败的重跑，可能比省下来的那点输入费贵得多。
第三层原因：省 token 和省质量不是同一个方向。把上下文压到最小可能让质量掉下来、失败率上升、重试变多 —— 总账反而更贵。所以正确的目标不是「最少」，而是「能可靠完成任务前提下的最小高价值上下文」：先保任务能成，再往下减。
适用场景
适合：已经在跑 agent 或自动化流水线、账单开始变得不好解释的人；把整份文档 / 工具目录常驻在系统提示里的人；发现「同一件事经常要重跑」但以为是模型不稳的人。
不适合：单次对话式的用法（没有循环，这一页的乘数效应不成立）；以及还不确定任务能不能跑通的阶段 —— 那时第一优先级是让它成，不是让它便宜。
自测 · 5 问
我说得出「模型每轮看到什么」里，哪些是常驻、哪些是按需吗？
我上一次复看这份清单是什么时候（还是从来没有）？
我算过「重试 + 失败 + 人工纠正」这三项的成本吗？
我的工具描述是全量加载，还是按当前任务检索？
我减上下文的时候，是一起减了质量、还是只减了冗余？
怎么上手 · 验证步骤
上手第一步：把常驻项列出来，然后逐项问一句「它每一轮都在付费，值吗？」多数人的系统提示里躺着三类东西 —— 不会再变的项目背景、全量工具目录、过期的历史记录。把第一类改成「需要时读」，第二类改成「按当前任务检索」，第三类直接删掉，通常能把每轮的固定开销砍掉一大截，而任务的完成质量不动。
第二步：做一次「重跑记账」。挑最近一周，数一数同一个任务被重跑了多少次、每次为什么。这三个数字（重跑次数 / 原因 / 人工收拾耗时）比 token 账单更能告诉你钱花在哪。
自检动作：同一个任务，把常驻上下文砍掉一半再跑一遍，两条线对比：① 完成质量有没有掉（同一套验收标准）② 总成本（含重试与人工）有没有降。只有两条都答得上来，这次减才算数 —— 只看 token 数下降不算，那可能只是把成本推给了重试。