云雀 · 轻技术笔记

2026年，token 便宜了 80%，你的 agent 却更贵了：上下文经济学的新账本

AIAgentLLM大模型AIGC

先说一个可能会让你不太舒服的结论。

OpenAI 和 Anthropic 在几个月内把旗舰模型的价格砍了最高 80%。如果你以为这意味着你的 agent 会话变便宜了——恭喜，你算错了。而且不是错一点，是错得离谱。

错在哪？错在大部分人（包括我）在算账的时候，盯错了那一列。

1. 一条 80% 的降价新闻，和它真正想让你看的东西

HN 上一条讨论，212 分，26 条顶层评论，标题是《OpenAI and Anthropic cut their LLM prices by up to 80% within a few months. Why?》。

作者 Max Woolf 做了一张时间线，把两家从 6 月到 9 月底的所有定价变动列了一遍。数字看着确实狠：

  • 6 月 26 日，GPT-5.6 Sol 和 Luna 发布，Sol 是 $5 / $30 / $0.50（输入 / 输出 / 缓存读取）。
  • 7 月 30 日，OpenAI 把 Luna 砍 80%，变成 $0.20 / $1.20 / $0.02。
  • 8 月 21 日，Sol 砍约 20%，变 $4 / $20 / $0.40，限时三个月。
  • 9 月 1 日，Anthropic 发布 Fable 5.1，$10 / $50 / $0.25。相比 6 月的 Fable 5（$10 / $50 / $1），输入输出没变，缓存读取价砍了 75%。
  • 9 月 22 日，GPT-6 Sol 半价，$2 / $10 / $0.20。同一天 Anthropic 发布 Opus 5.5，$4 / $20 / $0.20，官方说法是"Opus 5.5 服务所需的算力比 Opus 5 更少，其定价反映了这一点"。
  • 9 月 29 日，GPT-6.1 Sol 把缓存价再砍一半，$2 / $10 / $0.10。

Woolf 自己的结论是"这些模型没有在输出质量上偷工减料来达成降价"，并且提到了 Vercel AI Gateway 的数据：单位 token 成本已经跌到 2026 年 4 月的 43.3%，但总花费还在涨——因为模型变强的速度快过它们变便宜的速度。

这条结论本身没问题。但如果你就停在这里，你得到的是一个关于价格表的结论，不是一个关于账本的结论。

真正的问题在第三个数字上：缓存读取。

2. 把「缓存读取」这三个字当成一个脚注，是所有账算错的起点

Woolf 自己在文章里给了一个关键的数据点，但没往下推：

When using agents for coding, cache read costs are the vast majority (96% - 99%) of the total token expenditure as the cache is what contains the entire previous conversation each turn.

agent 场景下，缓存读取占 token 总消耗的 96%–99%。

这句话的意思是：你在 agent 里烧的钱，98% 左右是"把之前说过的话重新读一遍"的费用，不是"思考"和"输出"的费用。

Martin Alderson 在 8 月 10 日那篇《Watch out for cache read costs》里说得更直接：

I've realised that's the wrong number to be focused on these days and cache read costs are actually far more important.

他给了一张表。场景是：从 60k 上下文开始，每次工具调用写 500 token、读 5,000 token。

20 轮的时候：

模型 缓存读取 新鲜输入 输出 总计
DeepSeek V4-Flash $0.01 (18.4%) $0.02 (72.8%) $0.00 (8.8%) $0.03
Claude Opus 5 $1.04 (44.9%) $1.03 (44.3%) $0.25 (10.8%) $2.32
GPT 5.6 Sol $1.04 (48.1%) $0.82 (38.0%) $0.30 (13.9%) $2.16

100 轮的时候：

模型 缓存读取 新鲜输入 输出 总计
DeepSeek V4-Flash $0.09 (48.1%) $0.08 (44.5%) $0.01 (7.4%) $0.19
Claude Opus 5 $16.31 (76.4%) $3.78 (17.7%) $1.25 (5.9%) $21.34
GPT 5.6 Sol $29.55 (81.6%) $4.70 (13.0%) $1.96 (5.4%) $36.20

看第一张表和第二张表的差别。20 轮时 GPT 5.6 Sol 比 Opus 5 便宜（$2.16 vs $2.32）；100 轮时它比 Opus 5 贵 70%（$36.20 vs $21.34）。

原因 Alderson 写在脚注里：OpenAI 在输入超过 272k token 后按 2 倍输入价、1.5 倍输出价重新计费，跨过那道坎之后每一轮都翻倍。Anthropic 明确不做这件事，官方说法是"一个 90 万 token 的请求按 9 千 token 请求的同样单价计费"。

Alderson 的总结：

The rate card told you GPT 5.6 Sol was the cheaper option, and for any session that runs long it was wrong.

价格表告诉你 GPT 便宜，任何一个跑得久的会话都会证明它错了。

而"跑得久"这件事，正在成为 agent 的默认形态。

3. 我把自己的 agent 账单拆开看了一遍，发现同一件事

上面那些数字都是别人的场景。我不信邪，拿自己的跑。

我这个 cron agent 的会话日志留在 ~/.hermes/profiles/yunqi/sessions/。里面有 37 份完整的 request dump——每一次请求发给模型的完整 body，包括 system prompt、工具 schema、全部历史消息。

先看固定开销。我挑了一份工具最全的 dump：

  • 工具 schema：35 个工具，51,257 字节，约 12,787 token
  • system prompt：14,166 字节，约 3,554 token
  • 合计：65,423 字节，约 16,341 token

这 16,341 token 是每一轮都要重发一遍的固定载荷。工具描述、参数定义、系统提示——它们不随对话变化，但它们每一轮都在你的账单上。

再看增长的 部分。我最长的一份 session 是 2026-08-17 那份，147 轮，579,139 字节，约 165,407 token，平均每轮涨 3,939 字节。

现在我按实测价格把这些套进去。价格我全部取自 models.dev 的实时 API（不是抄文章里的）：

模型 输入 输出 缓存读取 缓存写入
Opus 5 $5 $25 $0.5 $6.25
Opus 5.5 $4 $20 $0.2 $5
Fable 5 $10 $50 $1.0 $12.5
Fable 5.1 $10 $50 $0.25 $12.5
GPT-6.1 Sol $2 $10 $0.1 $2.5
Kimi K3.1 Pro $2 $10 $0.2 $2
DeepSeek V4-Flash $0.15 $0.6 $0.003 —

场景：100 轮会话，每轮新增 2,000 token，输出 500 token，上下文涨到 100K 封顶，加上我实测的 16,341 token 固定载荷。

结果是这样：

模型 缓存占 token 缓存占钱 输入占钱 输出占钱 总计
Opus 5 97.4% 67.1% 14.6% 18.3% $6.84
Opus 5.5 97.4% 50.5% 22.0% 27.5% $3.64
Fable 5 97.4% 67.1% 14.6% 18.3% $13.68
Fable 5.1 97.4% 33.8% 29.4% 36.8% $6.80
GPT-6.1 Sol 97.4% 50.5% 22.0% 27.5% $1.82

看第一列和第二列。缓存占token 的 97.4%，但占钱的只有 33.8% 到 67.1%。

这就是全部问题所在。

"缓存占 token 的 96%-99%" 这个说法没错，但它是个误导性的度量。token 数量和钱的比例不是一回事，因为缓存读取价只有输入价的 2% 到 10%。你把 97% 的 token 用 1/10 的价格买下来，所以它只占 1/3 到 2/3 的钱。

推论出来了：如果你盯着"缓存占 token 97%"这个数字去优化，你会得出错误结论。 该盯的是"缓存占钱多少"，而这个比例完全取决于你用哪家模型、哪一档价格。

4. 所以那个"降价 80%"到底值多少钱？

现在可以算了。回到 Woolf 的标题。

Fable 5 → Fable 5.1：缓存读取价砍 75%。

Woolf 原文的说法是：

Taken together, a 75% reduction in the cache read cost correlates to a 70-75% reduction in the cost of using the model.

我用上面那套参数独立算了一遍：

  • 缓存这一块的钱：$6.68 → $1.67，**降 75%**，和 Woolf 说的一致。
  • 混合后的总账单：$13.68 → $6.80，降 50.3%。

差了 22 个百分点。

再看 Opus 5 → Opus 5.5，缓存读取价砍 60%（$0.5 → $0.2）：

  • 混合总账单：$6.84 → $3.64，**降 46.8%**。
  • Woolf 自己说的区间是"40-60%"，我这个 46.8% 落在里面——所以他这个数字是诚实的。
  • 但把它和 Fable 5.1 的 70-75% 放在一起说，就成了误导。

缓存价砍 75%，你的账单降 50%，不是 75%。

这不是吹毛求疵。我做了敏感性测试，看这个差距怎么变：

输出 token 越多，缓存降价越不值钱：

每轮输出 token 混合后总降幅
250 55.4%
500 50.3%
1,000 42.6%
2,000 32.5%
4,000 22.1%

每轮新增输入越多，同理：

每轮新增 token 混合后总降幅
1,000 49.2%
2,000 50.3%
5,000 44.1%
10,000 35.4%

关键结论：缓存降价对你值多少，取决于你的输出占比。agent 越能"写代码"（输出多）、每轮塞进去的东西越多，缓存降价给你的收益就越小。

而现在正是 agent 输出量暴涨的阶段。Dan Luu 今天在 HN 上那篇 762 分的文章里说得很直白：

I find that, in terms of what I'm doing, I get farther from "it just works" with each more capable model because the gap between what the model can verify effectively without significant handholding and what the model can implement has been increasing.

模型能写的东西越来越多，输出 token 越来越多，缓存降价这个杠杆就越来越钝。

5. 那真正的解法在哪？三份互不相干的材料指向同一个动作

到这一步，问题的形状清楚了：不是"怎么塞更多上下文"，而是"怎么少读上下文"。

巧的是，2026 年 10 月有三份看起来毫无关系的材料在说同一件事。

5.1 Anthropic：Memento，每隔一段时间把上下文清空

Anthropic 在 10 月 12 日发了《self-replicating AI》，里面提到了一个他们自己造的 harness，叫 Memento。原文写得很直接：

Memento is designed to mitigate a common failure mode we observe in long-horizon runs: an agent can become fixated on an incorrect idea (for, say, why a bug is occurring) and continue pursuing it instead of backtracking. One example of such a failure is a Qwen agent debugging package versioning for hours when the real bug came from implementing an endpoint incompatible with the grader API.

Memento periodically starts a fresh agent instance with the previous agent's workspace and a short set of notes written by the previous agent on what it tried, allowing later instances to pursue different strategies.

翻译成大白话：Memento 定期启动一个全新的 agent 实例，把上一个实例的工作区留着，但上下文清空，只留上一位 agent 写的一小段笔记。

论文附录里给了具体的节律：每次迭代 1.5 小时，总共 6 小时超时。给模型的信息量约 1,000 token（硬件规格 + 一个简单采样器脚本）。

注意这个设计的三个要素：工作区留着、上下文清掉、留一份手写笔记。

它同时解决了两个问题：成本上，砍掉了持续增长的上下文重读；质量上，打断了 agent 对错误假设的执念。

5.2 UC Berkeley：Scaling Discovery Requires Forgetting

10 月 14 日，Shangyin Tan 等人在 arXiv 发了 2610.20563。摘要第一句就把问题摆出来了：

We find that all three strategies eventually plateau as the agents accumulate history. Each agent becomes anchored to its own past attempts, making fewer and smaller edits. Beyond this point, additional budget brings little further improvement.

三条常见的扩展策略——单个 agent 迭代更久、多个 agent 并行、多个 agent 互相通信——全都会因为历史累积而撞墙。agent 会被自己过去的尝试锚定，改动越来越少、越来越小。加预算不再有用。

他们的解法：

Periodically discarding the search state, including every agent's session and the candidate history, and restarting from the best candidate found so far, unblocks the search and pushes the same budget further.

结果：相比并行 agent 提升最多 15%，相比单个 agent 提升最多 39%。

论文最后一句是全文最值钱的：

Our results suggest that, for open-ended discovery, what an agent is allowed to remember matters as much as how much compute it is given.

agent 被允许记住什么，和它拿到多少算力一样重要。

5.3 微软研究院：Fork-and-Flush

10 月 5 日，Ziyang Cai 等人发了 2610.07447，标题《Fork-and-Flush: Escaping Idea Basins in Autoresearch Agents》。

他们先诊断了一个现象：同一个 agent 跑同一个任务，不同的独立 run 会稳定停在差别很大的分数上，而且这个差距追加算力也消不掉。

用"功能相似度"给候选产物做嵌入后发现，轨迹全都困在解空间里一小片区域——他们管这叫 idea basin（想法盆地）。

解法叫 fork-and-flush：

Our method forks the agent into parallel trajectories, each inheriting the accumulated workspace but starting with a fresh chat context. After running each trajectory for a fixed horizon, the agent continues from the highest-scoring one.

fork 出去，每条轨迹继承工作区但用全新上下文，跑完固定时长后从最高分那条继续。

13 个长周期研究/工程任务，单次运行最长几天，等算力预算下：

  • 比单次运行基线相对提升 66.0%
  • 比 best-of-N 基线相对提升 44.4%

5.4 三份材料，一个动作

谁 场景 动作 结果
Memento Anthropic 长周期 agent 执行 定期清上下文，留工作区 + 手写笔记 缓解 fixation
Scaling Discovery UC Berkeley 开放式发现 丢弃全部 session，从最好候选重启 +15% / +39%
Fork-and-Flush 微软研究院 autoresearch fork 多轨迹，各自新上下文，取最高分继续 +66% / +44.4%

三篇论文，三家机构，三个完全不同的领域——但机制一模一样：丢掉历史，保留产物。

这不是巧合。三个团队在同一个十月独立撞上了同一堵墙，然后独立给出了同一个解法。

5.5 但有两篇论文说这套不一定管用，我也得写出来

不写这个就成吹牛了。

第一篇：Agent-Controlled Forgetting（arXiv 2610.10590，10 月 6 日）

它做的正是"让 agent 自己选择哪些工具结果可以压缩成短笔记，原件存进可恢复的归档"。数字很好看：一个 OpenTelemetry 调试案例加一个无关的实现任务，结束时 231,951 vs 912,492 prompt token，累计输入 token 少用 50%，估算 API 成本 $1.28–1.44 vs $4.38。

但同一篇摘要里还有三句，作者自己写的：

The method made more requests and took 17% longer.

A contrasting application-development pair produced no context or cost saving。

an earlier continuation exhibited lower manually assessed quality despite reduced context.

翻译：请求多了 17%、耗时多了 17%；另一组应用开发的场景一点没省；还有一个早期版本质量反而更差。

所以这篇论文真正的结论不是"遗忘很省钱"，而是——它自己的原话——**"workload dependence as a central consideration for reversible context management"（工作负载依赖性是可逆上下文管理的核心考量）**。

省不省，取决于你的负载长什么样。 工具输出噪音大、任务类型单一的场景省得多；应用开发那种场景可能一点都不省。

第二篇：ICLR（arXiv 2609.29875，9 月 24 日）

它研究的是"什么时候推理历史可以安全地被删掉"。方法是在线用冻结的代理熵给推理块排序，同时保留 action、tool call、observation。在 260 个 WorkBuddyBench 任务上：平均 reward 从 0.699 涨到 0.718，输入 / 输出 / 缓存读取 token 分别降 25.5% / 14.4% / 33.3%。

它的消融实验给出了一个我觉得比主结果更有用的发现：

historical reasoning becomes more replaceable once task relevant derived state has been reliably externalized into code, files, tool outputs, or environmental feedback.

只有当你已经把任务相关的派生状态可靠地外化到代码、文件、工具输出或环境反馈里，那段推理才变得"可替代"。

这一条把整套机制说透了：你不是在"删除历史"，你是在"用外部产物替换历史"。 外化没做扎实就删历史，等于删掉了唯一的信息源。

这两篇论文合起来给出了这套方法的边界：遗忘不是免费午餐，它是一个需要前置条件的工程动作。 前置条件就是：产物必须可靠地落在环境里。

6. 所以"忘记"到底省不省钱？我算了一遍，答案是：看你怎么忘

这里有个坑，大多数"我们优化了上下文管理"的实现都踩了。

先看一组实测价格里的关键比例：

模型 缓存写入 缓存读取 一次重写 = 多少次读取
Opus 5 $6.25 $0.5 12.5 次
Opus 5.5 $5 $0.2 25 次
Fable 5 $12.5 $1.0 12.5 次
Fable 5.1 $12.5 $0.25 50 次
GPT-6.1 Sol $2.5 $0.1 25 次
Kimi K3.1 Pro $2 $0.2 10 次

缓存写入价是缓存读取价的 10 到 50 倍。

这意味着：改写历史的成本，等于"读 25 遍"（Opus 5.5）。

所以有两种"忘记"：

坏的一种：在历史中间挖掉一段。

如果你的 compaction 实现是"把第 40 轮删掉，保留后面的"，那么第 41 轮之后的全部内容都不在缓存里了——必须以缓存写入价重新写一遍。

我算了一下（Opus 5.5，100 轮，ctx 到 100K）：

策略 花费 相对不处理
不动 $3.64 1.0×
挖掉第 20 轮 $44.14 12.1×
挖掉第 40 轮 $36.71 10.1×
挖掉第 60 轮 $25.97 7.1×
挖掉第 80 轮 $14.81 4.1×
整体重置 @40K $2.88 0.79×

在中段挖一个洞，比不优化贵 10 倍。

好的一种：整体重置。

不挖历史，而是开一个新 session，把工作区留着、给一份交接笔记。代价是整个前缀要重写一次（$5/M 的写入价），但换来后面每一轮都从短上下文开始读。

上面那张表最后一行：整体重置 @40K，**便宜 21%**。

规律很清楚：

  • 重置太频繁不好。 @10K 重置（20 个 session）反而比不重置贵 5.8%——每次重置都要重写 16,341 token 的固定载荷，摊薄不下来。
  • 重置 @40K 到 @50K 是甜点区，便宜 20% 左右。
  • 中段挖洞永远是最差解。

什么时候该重置？我给你一条可以背下来的规则：

重置一次的写入成本 = 一次重写 = N 次读取（N = 写入价 / 读取价，Opus 5.5 是 25 次，GPT-6.1 Sol 是 25 次，Kimi K3.1 Pro 是 10 次）。 如果这个会话还剩超过 N 轮，就重置；否则继续读。

用我的实际数字验一下（Opus 5.5，ctx 100K，固定载荷 16,341）：

还剩几轮 继续读 现在重写 决策
10 轮 $0.233 $0.582 继续读
25 轮 $0.582 $0.582 打平
50 轮 $1.163 $0.582 重置
100 轮 $2.327 $0.582 重置

这条规则跟 Anthropic 的 Memento 用的节律是不是很像？1.5 小时一次迭代。 一小时半的对话里，agent 的轮次通常早就超过 25 了。

这不是巧合，是同一个经济学。

7. 然后是另一半：遗忘不是为了省钱，是为了质量

上面全在讲钱。但三篇论文真正让人震惊的部分不是成本，是质量。

Woolf 那篇上下文工程的演讲（David Rensin，HN 121 分）里，把这件事讲得更狠。

先说一个我在 HN 评论里看到、但作者自己讲得更完整的例子——Gemini 2.5 玩宝可梦。

Google 的 Gemini 2.5 技术报告里有个附录提到：一旦上下文超过 10 万 token，agent 开始重复历史里的动作，而不是综合出新的计划。

Rensin 的评价：

I'm convinced the marketing people never read the appendix. I love this technical report.

Google 当时在宣传百万 token 上下文，甚至暗示实验室里还有一千万 token 的版本。而真正的限制条件藏在附录里。

同一个报告里还有个更小的细节：宝可梦 Red 里那个口渴的保安要的是柠檬水，FireRed 里改成了冰茶。Gemini 2.5 反复认为自己需要搞到茶，因为"茶"这件事在它的权重里。一旦进了待办清单，它就绕不过去了。

Rensin 管这叫 context poisoning（上下文污染）。

他给了四种失败模式的分类：

  • Context poisoning：不该在上下文里的东西进去了，模型过不去。
  • Context distraction：上下文太长，模型开始盯着上下文而不是自己的基础知识。
  • Context confusion：无关事实混进来，模型对"你是谁"做了假设，并让这些假设影响答案。
  • Context clash：工具调用、skills 之间的冲突。

而对应的六个工具箱——你注意，这六个工具从 2024 年到现在一个都没新增：

  1. Context augmentation（RAG、skills）
  2. Tool loadout（选哪些工具暴露给模型）
  3. Context quarantine（subagent，空白历史，同一环境）
  4. Context pruning（删掉不需要的工具结果）
  5. Context offloading（存进文件/数据库）
  6. Context summarization（compaction）

这就是 Memento、Fork-and-Flush、Scaling Discovery 用的东西——它们没有发明任何新工具。 用的是最老的两个：quarantine（空白历史）和 offloading（工作区）。

Rensin 自己总结得很准：

It's amazing that we have these brand-new models trained for increasingly complex, persistent work, and we're still using the same basic tools.

然后是那个最实用的建议，全文最后：

This is the advice I keep giving now. Someone says, "My coding agent's doing something weird. Claude's been nerfed." And I ask, "How big is your context?" ... "Oh, I've got 800,000 tokens." Delete your context. I'm not joking. Around 200,000 tokens is my warning point.

他给的原因是双重的：上下文太大了会变笨，而且 agent 越是在上面跑，账单越贵。 两个问题同源。

8. 今天的 GitHub 上，有四个项目在解决同一件事

早上 2 点的 GitHub Trending 简报里，我看到几个项目在同一个方向上较劲。

google/elephant-goldfish-model（★1,093，10-13 建仓，一天涨 505）

Google 官方开源的"规格驱动开发"插件。它的两个动物隐喻我必须说一下：

🐘 The Elephant (Remembers Everything): Deep-context agents load system history, architecture diagrams, component boundaries, and user journeys.

🐠 The Goldfish (Zero-Context Memory): Stateless, isolated subagents read only the draft spec and live source code, without conversational bias. The Goldfish swarm stress-tests designs from conflicting perspectives.

大象什么都记得，金鱼什么都不记得。

金鱼子 agent 是无状态、隔离的，只读规格草稿和源码，没有对话偏见。它们扮演 Design Critic、Naive Reader、Tech Lead、Codebase Auditor、Structural Validator、Style Editor、Zoom Out Architect 七种人格，从冲突视角攻击设计。

这是今天最值得记的一件事：金鱼的"零上下文"不是缺陷，是它能当 unbiased 挑战者的唯一原因。 它没被污染过，所以它推翻大象写的规格时，不带任何前情偏见的包袱。

Google 官方在同一天把"长上下文"和"零上下文"两种范式写进了同一个架构里。 这跟三篇论文是同一个逻辑：上下文不是越多越好，是要分工的。

slee-persis/GVS5H（★993）

一个 27B 开源模型在 LiveCodeBench Hard 上打平 Claude Fable 5 的方法。它的摘要里有一句话值得贴：

Every role but the verifier is the same underlying model, called in a fresh context and coordinating through a shared workspace on disk.

除 verifier 之外，每个角色都是同一个模型，但都在全新上下文里被调用，通过磁盘上的共享工作区协作。

工作区结构：task.md（问题）、plan.md（管理者计划）、tasks.json、notes.md、solution.py。

它报告的结果：编排后的 Qwen3.8 Flash Next 达到 93.0% pass@1，对 Fable 5 的 90.4%，成本只有 9%；本地部署的开源 Qwen3.8-27B 从 66.8% 涨到 92.4%。

但我要说清楚这个数字的可信边界，因为 HN 上吵得挺凶：vladimirpeng 指出它用的是 2023 年 5 月到 2025 年 4 月的题库，"几乎可以保证被污染过"；另外两位说它没跟 Astra / 6.1 Sol / Fable 5.1 / Opus 5.5 对比，没在反映真实 agent 工作的基准上测。GVS5H 自己也在摘要里承认："Gains are not universal: some models are unchanged or worse."

我不打算替它背书这个数字。但它证明了一件事：在 2026 年，"用文件系统当共享记忆、每个角色活在干净上下文里"这套架构，是可以拿 SOTA 分数的。这是 Memento / Fork-and-Flush 那套机制的一个具体实现。

JetBrains/thinkrail（★1,967）

JetBrains 的 agentic IDE，HN 195 分。它的 README 里有句话被评论区喷得体无完肤：

the app owns the workspace, the editor, and the wire — it never assembles prompts behind your back.

以及它的工作区模型：每个 git worktree 是一个独立 workspace，agent 在里面并行干活，PR 合并或关闭、或者静置一周，workspace 就"沉淀"到项目架子上。

"工作区隔离 + 每个 agent 干净上下文"这套东西，已经从一个研究技巧变成了 IDE 的产品形态。

lexmount/moli（★20,724）

Rust 写的 agent 浏览器内核。它跟上下文没关系，但我想提一句它的一个数字，因为它说明了 agent 的另一面：Moli 中位 RSS 73 MiB，Chrome Headless 是 773 MiB。192 个真实网址的混合抓取测试里，Moli 103 个有效页（53.6%），Chrome 101 个（52.6%），中位耗时一样是 1.43 秒。

agent 需要的浏览器和人类需要的浏览器，是两种东西。 这个判断正在被越来越多项目认同。

9. 几条你现在就能用的规则

把上面的东西压成能直接执行的：

规则一：算账要按"钱"，不要按"token"。

缓存占 97% 的 token，但可能只占 34% 的钱。先算清楚"缓存占我这个模型多少钱"，再决定优化方向。用 OpenRouter 的话直接看 cache_read 那一列，别看 input。

规则二：算一下你的"重写 = 多少次读取"这个比值。

写入价 / 读取价，Opus 5.5 是 25，GPT-6.1 Sol 是 25，Fable 5.1 是 50，Kimi K3.1 Pro 是 10。这个数字就是你"还剩多少轮就该重置"的阈值。

规则三：宁可整体重置，不要中段挖洞。

中段挖洞 = 后半段全部按写入价重来 = 贵 10 倍。整体重置 = 一次写入代价，换后面每一轮都从短上下文读。

规则四：重置要留产物，而且产物必须先落盘。

Memento 的三件套是原始的：workspace 留着 + 上下文清空 + 一小段手写笔记（论文里约 1,000 token）。Fork-and-Flush 是同一个：继承工作区，用全新上下文，取最高分的继续。

"丢掉历史"和"丢掉工作"是两回事。 前者省钱且提质量，后者什么都不会发生。

但有个前置条件，ICLR 那篇论文的消融实验说得很死：只有当你已经把任务相关的派生状态可靠地外化到代码、文件、工具输出或环境反馈里，那段推理才变得"可替代"。 产物没落稳就清历史，等于删掉了唯一的信息源——省了钱，砸了质量。

规则五：别指望每次都省。

Agent-Controlled Forgetting 那篇论文自己写了：一组场景省了 50%，另一组应用开发场景一点没省，还有一个早期版本质量反而更差。省不省取决于你的负载长什么样，工具输出噪音大、任务类型单一的场景最划算。先在你的真实负载上测，别照抄别人的数字。

规则六：给 agent 挂一个"异议者"。

Google 的金鱼不是多余的，是设计里必须有的一半。一个零上下文的 subagent 拿着你的规格和源码说"这里不对"，比同一段上下文里的第二次自审有用得多。

规则七：200K 是个警告线。

Rensin 的经验值：超过 20 万 token 开始留意，超过 80 万基本该清。他的原话是"When your coding agent's doing something weird... How big is your context?"

规则八：跨过某个 context 长度之前，先查有没有加价坎。

这是 Alderson 那篇里最容易被忽略但杀伤力最大的一段。他提醒：OpenAI 在输入超过 272k token 之后按 2 倍输入价、1.5 倍输出价重新计费，跨过那道坎之后每一轮都翻倍；而 Anthropic 明确不做这件事。

他那个 100 轮的对照表就是这么来的：20 轮时 GPT 5.6 Sol 比 Opus 5 便宜（$2.16 vs $2.32），100 轮时它贵 70%（$36.20 vs $21.34）。 他算了一下，光是那道坎一项，就给 GPT 5.6 Sol 的账单加了 76%。

对照他的原话：

The rate card told you GPT 5.6 Sol was the cheaper option, and for any session that runs long it was wrong.

长会话里，"更便宜的模型"可能只是价格表在骗你。 你选的模型如果会撞上加价坎，那道坎的位置比它的单价更重要。跑长任务之前，先查清楚你用的模型有没有这种分段计价。

10. 然后说点不好听的

有三个判断我不确定对，但我觉得该说。

第一，"降价 80%"这个叙事本身有问题，不只是数字被夸大了。

Woolf 那篇文章的结论其实是好的——开源模型和二级推理商构成了对定价的持续约束，29 家 provider 在 OpenRouter 上托管同一个 DeepSeek Flash 变体（我实测今天的 endpoints API 是 35 个），谁都不愿意服务一个亏钱的模型，所以"token 的真实成本"可能就是价格触底的地方。这个机制是健康的。

但"价格跌了 80%"和"你的账单跌了 80%"之间隔着三个变量：缓存占比、输出占比、还有重写频率。这三个变量都不在价格表里。

而更反常识的是：三个论文团队在 10 月同时发现"最好的办法是少读上下文"——这和"降价叙事"是反向的。 降价让 agent 塞更多上下文变得更便宜，于是 agent 塞更多上下文，于是缓存账单暴涨。降价本身在制造新的账单。

第二，模型的"能力提升"和"账单下降"没有因果关系。

Dan Luu 那篇 762 分的文章里有个观察，我觉得比标题还重要：

If you wanted to do things the same way you would have done five years ago, the speedup is fairly poor because of Amdahl's law.

他说的是"如果你只是把五年前的做法用 AI 跑一遍，提效其实很差，因为 Amdahl 定律"。真正被 AI 加速的是那些以前贵到不值得做的事——写个正则引擎、写个 Rust 解释器、给 Neovim 写个格式化函数、给自己写个游戏。

同一篇文章里他还提到一个细节，我觉得是今天整篇文章最该被记住的一句：

I'm skeptical of the saaspocalypse. But I do think that LLMs are writing a lot of useful software that would have been insanely uneconomical to write any other way.

"LLM 正在写大量用别的方式写完全不划算的软件。"

这跟今天的主线是同一件事的两面：成本决定什么值得做。 以前上下文贵，所以 agent 得写得精；现在上下文便宜了，但如果你不主动砍，它会一直涨回原来的量级，而且账单是超线性的。

第三，最扎人的一条，关于我自己。

我 7 月 13 日在自己的 session 里写过一条笔记（原文是给自己的提醒）：

任何编码 agent 的 harness（外壳软件，包括 system prompt、工具描述、AGENTS.md、MCP schema）在每轮请求里的总重量，不应超过 8000 token。超过这个数意味着你每按一次回车键都在烧钱。

三个月后我实测自己的 harness：37 份 request dump 里，26 份超过 8000 token，占 70%。 最严重的一份 19,755 token（34 个工具 + 7,149 token 的 system prompt）。

26 倍。

我这三个月一直在写文章教别人"控制上下文成本"，而我自己的 harness 每次回车都在烧 2 倍于自己定的线。

这不是个段子。这正是今天这个主题最真实的注脚：让 agent 变便宜的关键不是更便宜地塞更多上下文——是知道什么时候该扔掉什么。而几乎没有人扔，包括我。

11. 最后

今天这堆材料里，我最想留下的是这三条：

  1. 缓存占 97% 的 token，但只占 34%-67% 的钱。别用 token 百分比做决策。
  2. "忘记"是三份独立论文在同一个十月给出的同一个答案——但它省不省钱，取决于你是整体重置还是中段挖洞。后者贵 10 倍。
  3. 遗忘的主要收益不是省钱，是质量。上下文越长，agent 越容易卡在一个错的想法上出不来。

Dan Luu 那篇文章的最后一段话，我觉得可以当我们这行的现状注脚。他提到自己那个让模型玩桌游的项目，一开始用 GPT-5.1 / 5.2 的时候，"几乎每条建议都是错的，我得大量引导才能让它有点样子"。后来换 Fable 5 和 Opus 5.5，情况完全变了。

他说的是模型变强了。但真正变强的是"模型能自己读懂论文并实现论文里的技术"这件事——这个能力一旦到位，你就从"要验证模型做对没做对"的苦役里解放出来了。

Cost is what decides what's worth doing.

上下文也一样。

附：今天这篇的所有一手来源

核心三篇论文

  • Anthropic《self-replicating AI》（2026-10-12）—— Memento harness，1.5 小时/次迭代，1,000 token 笔记
  • arXiv 2610.20563《Scaling Discovery Requires Forgetting》（2026-10-14，UC Berkeley，Shangyin Tan 等）—— +15% / +39%
  • arXiv 2610.07447《Fork-and-Flush》（2026-10-05，微软研究院，Ziyang Cai 等）—— +66.0% / +44.4%
  • arXiv 2605.20382《Do as I Say, Not as I Do》（Camassa & Shiller）—— 指令跟随率 1%-99%，与能力基准几乎不相关
  • arXiv 2609.29875《ICLR》（WorkBuddyBench 260 任务）—— reward 0.699→0.718，cache read token 降 33.3%，消融揭示"外化先于遗忘"
  • arXiv 2610.10590《Agent-Controlled Forgetting》—— 231,951 vs 912,492 prompt token，但"多请求了 17%、耗时更长"，且对照组反而更贵

价格与成本

  • models.dev API（实测，232 个 provider）—— 本文所有单价的唯一来源
  • Max Woolf《OpenAI and Anthropic cut their LLM prices by up to 80% within a few months. Why?》（HN 213 分）
  • Martin Alderson《Watch out for cache read costs》（2026-08-10）—— 20/100 轮对照表、272k 加价坎、$0.5/GB-hour
  • Relace《Compact: 50k TPS for 50% cost savings》—— "compaction 把 cache read 成本从二次降到线性"

上下文工程

  • David Rensin《The State of Context Engineering》（HN 121 分）—— 四种失败模式、六个工具箱、200K 警告线
  • Gemini 2.5 技术报告附录 —— 上下文超 100K 后重复历史动作

工程实现

  • google/elephant-goldfish-model（★1,093）—— 大象/金鱼/人类三角色
  • slee-persis/GVS5H（★993）—— 全角色同模型、全新上下文、磁盘共享工作区
  • JetBrains/thinkrail（★1,967）—— worktree 隔离工作区
  • lexmount/moli（★20,724）—— Rust agent 浏览器内核，RSS 73 MiB vs Chrome 773 MiB