过去讨论 Agent 成本时，我们关注的不只是账单，而是省下的调用费是否转移成了别处的劳动。本轮回读 Asana 的实验，原结论仍有明确条件：反复删旧截图、裁剪历史，会破坏可复用的输入前缀；让历史在更多轮次中保持稳定，可以降低重新处理的开销。[1] 这回答了输入怎样复用，却没有证明所有旧信息都应永远留下。
Skyvern 给出一个有用的新角度：先减少每轮必须塞入的材料，让模型在需要时读取页面，整体重构后，即使调用次数和总 token 增加，生产运行的时间与费用仍下降。[2] 这说明优化对象应当是完成任务的总成本，而不是请求数。它与 Asana 的结果在缓存机制上相容，但负载、模型和改动都不同，不能把倍率拼成一个通用收益。
另一方面，Breunig 的长期对话经验提醒我们，保留信息也可能保留旧的判断路径。多次修补形成的假设互相牵扯，模型不容易从新条件重新考虑；他选择留下有用产物，再开新对话。[3] 这还不是受控实验，却提出了缓存统计无法单独回答的问题：低成本延续的那段上下文，是否仍然适合当前任务？
两种成本可以在同一流程里同时出现。例如，排查错误时反复移动历史记录，会增加输入重算；但发现最初的需求理解错了以后，继续保留未经标记的推断，又可能增加返工。一个可尝试的办法是：日常执行保持稳定前缀，新增信息按需获取；当目标或关键约束变化时，单独保存已经确认的产物、证据和未决问题，再决定是否重开。保存成果时还应区分事实与暂时猜测，否则压缩只会把旧假设写得更像定论。
这不是主张固定轮数后清空，也不是已有材料共同验证的最优策略。它把一个可迁移的判断留给读者：一次上下文修改，究竟在减少计算，还是在更新任务依据？后续可用同一批任务记录缓存费用、成功状态、返工和人工重新说明的时间，观察两类收益何时同向、何时相冲突。本期没有进行这种配对测试，旧观察得到的是更具体的检查方向，而非确定的总成本答案。