保留稳定的上下文，也要能放下失效的假设

2026-10-26 · 当时的记录

过去讨论 Agent 成本时，我们关注的不只是账单，而是省下的调用费是否转移成了别处的劳动。本轮回读 Asana 的实验，原结论仍有明确条件：反复删旧截图、裁剪历史，会破坏可复用的输入前缀；让历史在更多轮次中保持稳定，可以降低重新处理的开销。[1] 这回答了输入怎样复用，却没有证明所有旧信息都应永远留下。

Skyvern 给出一个有用的新角度：先减少每轮必须塞入的材料，让模型在需要时读取页面，整体重构后，即使调用次数和总 token 增加，生产运行的时间与费用仍下降。[2] 这说明优化对象应当是完成任务的总成本，而不是请求数。它与 Asana 的结果在缓存机制上相容，但负载、模型和改动都不同，不能把倍率拼成一个通用收益。

另一方面，Breunig 的长期对话经验提醒我们，保留信息也可能保留旧的判断路径。多次修补形成的假设互相牵扯，模型不容易从新条件重新考虑；他选择留下有用产物，再开新对话。[3] 这还不是受控实验，却提出了缓存统计无法单独回答的问题：低成本延续的那段上下文，是否仍然适合当前任务？

两种成本可以在同一流程里同时出现。例如，排查错误时反复移动历史记录，会增加输入重算；但发现最初的需求理解错了以后，继续保留未经标记的推断，又可能增加返工。一个可尝试的办法是：日常执行保持稳定前缀，新增信息按需获取；当目标或关键约束变化时，单独保存已经确认的产物、证据和未决问题，再决定是否重开。保存成果时还应区分事实与暂时猜测，否则压缩只会把旧假设写得更像定论。

这不是主张固定轮数后清空，也不是已有材料共同验证的最优策略。它把一个可迁移的判断留给读者：一次上下文修改，究竟在减少计算，还是在更新任务依据？后续可用同一批任务记录缓存费用、成功状态、返工和人工重新说明的时间，观察两类收益何时同向、何时相冲突。本期没有进行这种配对测试，旧观察得到的是更具体的检查方向，而非确定的总成本答案。

回到当期正文 ↗

2026-10-24 · 当时的记录

这周最有启发的变化，是一些“值得不值得自己做”的边界正在移动。过去为少数业务人员开发一页定制报表，很容易被排进没有尽头的需求队列；现在生成界面的成本下降，需求本身可以成为开发的起点。David Lequin 团队的经历为这种变化提供了实例：他们保留数据仓库、约两千个 dbt 数据模型和身份认证，把更自由的布局放到这些设施上。用户增长表明定制页面有吸引力，至于数字是否更可靠、总费用是否更低，还需要另外的记录。

10 月 18 日至 21 日的成本观察强调：省下调用费以后，仍要按最终完成的任务比较。24 日的 BI 案例已经把已有基础设施纳入判断。本周把 TorchTPU 的优化过程一起读，进一步看到复用具有不同层次：既可以复用权限和数据定义，也可以复用模型接口，再重写执行方式。这里应该修正的是评价起点。不能只在产物出现后追问“有没有隐形成本”，还应在开始前判断哪些已有工作使这次定制成为可能。

BI 案例中，页面通过查看者身份查询数据，沿用原有权限；但团队仍要隔离生成页面的脚本、约束通信与令牌，并由人确认发布。权限回答谁能读取数据，沙箱约束代码能做什么，指标定义则回答收入或活跃用户究竟怎样计算。三者分属不同问题。评论者 alexkbuilds 曾做过类似系统，他最难解决的是让每个人都看见正确数字，同时也认可用户能自由描述自己要的页面。保留这两个判断，才能说明定制能力的价值和它实际需要的基础。

TorchTPU 的例子让“复用”更不容易被误读成零改动。熟悉的 PyTorch 定义保留下来，计算与通信却需要重新组织。把通信放进可编译的图，才能安排重叠；融合损失计算先节省显存，扩批后才转为吞吐。这条因果链说明，性能有时来自重新划分共同执行的工作，而不是某一个算子突然更快。已有接口降低了尝试门槛，专门的执行设计决定能取得多少收益。

Flint-interactive 提供了第三个可以借用的边界：让作者描述选中了哪些数据、哪些图需要更新，再把事件到状态变化的重复逻辑交给共享算子。布局仍可各不相同，同一国家在多张图中的对应关系却不必每页重新实现。它尚未证明总体维护成本降低，但提出了一个有用的问题：用户需要改变的部分，和团队反复调试的部分，能否分开？这比要求所有页面统一，或让每页完全从头生成，更贴近实际工作。

因此，对一个准备采用生成式工具的团队，我会先看已有的可靠资产：数据口径是否稳定，权限能否沿用，性能基线是否可重跑，交互关系是否可描述。再挑展示需求变化多、底层承诺变化少的一小类任务，比较首次交付和后续修改各花了多少人力。如果时间主要耗在澄清指标，继续加快写页面未必解决瓶颈；若重复工作集中在布局与联动，共享执行层就可能释放新的需求。

这个方法是从几种不同工程实践中归纳的待验证建议，本期没有运行比较实验。它也不意味着要先建一个大平台：原始案例本来就利用了已存在的设施，重新建设是否合算需要单独算账。下次应优先找新增页面的边际工时、底座持续维护、错误数字与后续修改的共同记录。只有把这些分开，才既看得见生成能力带来的自由，也不会把已经付过的建设成本误写成消失。

回到当期正文 ↗

2026-10-24 · 当时的记录

10 月 21 日的成本观察提醒我们，节省调用费后，还要看最终保留下来的正确任务。今天的 BI 实践把这个问题推到产品层：一页报表变便宜，可能因为模型减少了编写工作，也可能因为数据建模、身份认证和运维已经由旧平台承担。把后者识别出来，既能避免夸大节省，也能看见真正值得继续复用的资产。[1]

David Lequin 团队没有用 HTML 重新发明数据仓库。他们让页面沿用查看者权限与已有数据模型，把新的自由放在布局和交互上。由此出现的价值并不只是少付一笔许可费：业务人员能够提出更贴近自身问题的页面，迭代也不必总等统一产品排期。用户增长支持这种需求存在，尚不足以证明数字更正确或总投入更低。这两类判断应分别保留。

Flint 提供了另一个层次的复用。它让 Agent 描述选中了哪些数据、需要更新什么，把鼠标事件到图形状态的重复转换交给编译器。不同页面可以继续长得不同，框选后同一国家的对应关系却不必每次临场写一遍。两项工作由此指向同一设计问题：哪些变化是用户真正需要的，哪些重复工作可以收进稳定接口？[2]

这也解释了为什么“全面标准化”或“全部自由生成”都太粗。BI 评论者担心的是错误指标，Flint 处理的是交互一致性，二者不在同一个层次。即使页面安全、交互正确，收入的计算口径仍可能错；但这个缺口并不否定定制页面的价值。更有用的做法，是写清各层承担的承诺，再观察哪一层反复需要人返工。

ThinkingCap 则提醒我们，不同节省方式不能只用一张价格表比较。减少模型内部推理可能改变个别任务能力；复用数据平台把成本分摊到更多使用者；复用交互算子减少重复实现。这三种方法改变的对象不同，评价也应分别落在任务完成、平台持续维护和修改后的行为一致性上。平均 token 降幅只是其中一个局部指标。[3]

一个可迁移的起点，是挑选已有可靠数据定义、展示需求又多变的任务，记录首次交付与后续修改分别花在哪里。若多数时间仍花在澄清指标，继续压缩页面生成并不会解决主要困难；若重复调试跨图联动占了很多时间，共享交互层就可能有价值。这是本文提出的验证方向，尚未执行。下一次应找实际维护工时、错误数字与复用次数，检验便宜的生成是否真正带来更多可用成果。

回到当期正文 ↗

2026-10-21 · 当时的记录

此前我们沿着“省下的调用费，会不会花在别处？”追问缓存、检查和人工介入的代价。今天的新增边界，是成本控制可能直接改变哪些任务有机会完成。StopLoss 给出一个清楚的决策：观察最近几步，认为继续成功的希望太低时就停下。节省发生在没有执行的尾部；损失也发生在那里，因为部分尾部本来会走到成功。[1]

因此，比较方法至少要同时保留两本账：实际支出与成功结果。举一个仅用于解释的例子：原来花100元完成10件任务，停止策略花了80元却只完成8件，每件成功仍是10元。支出下降了，单位成功并没有改善；如果被放弃的两件恰好最重要，均值还可能掩盖更大的损失。StopLoss 的每个保留成功任务成本处理了其中一部分问题，但没有替业务决定各任务价值，也没有证明停止后换一种办法重试不值得。[1]

SlopCodeBench 进一步说明，这个分母也需要审查。阶段的新功能通过，与整套新旧测试全部通过，是不同的交付结果。若一次改动解决新要求却破坏旧行为，把它计为成功会让单位成功成本看起来更好。连续问题让过去的决定留在代码里，严格测试把这些承诺带到下一轮；它补充了停止策略没有回答的问题：我们到底在保护哪一种成功。[2]

由此可以迁移出一套评估顺序。先规定最终需要保留的行为和允许放弃的任务，再选择停止、升级或继续的规则；随后记录监控、执行、返工和被放弃结果，比较在相同交付要求下的总费用。对新任务类型，应重新检查阈值，因为原执行器失败不意味着任务本身无解。这里提出的是可实行的验证安排，本期没有运行在线实验，也不能把两项独立研究拼成已验证的组合系统。

这并不推出“计算越少越好”。若额外思考能保护关键旧功能，或把失败任务救回来，多花钱可能值得；若更多输出只增加冗长和检查负担，就应该改变过程。接下来最有区分力的证据，是跨执行器、跨任务的在线停止与升级实验，同时报告保留成功、误停类别及完整账单，而不仅是平均 token 数下降。

回到当期正文 ↗

2026-10-18 · 当时的记录

此前回访成本问题时，IBM 的芯片设计实验提供了推理账单，Minions 讨论了把任务移到用户设备后的响应，但都不足以覆盖质量、等待与人的收尾。今天 DeepSeek 的个人测试把问题缩小到十个可验收任务，记录重复成功、费用与时间。它没有解决通用生产率，却比直接比较 token 单价多了一项关键约束：先确认比较的是同一件完成的工作。

因此，本期对旧判断的推进是有限但具体的：作者报告，当任务与测试固定，低价组合可以在作者的小题集上达到相同完成结果；而原生框架与 Pi 的单次成功率、三次全对率、缓存和账单又显示，“便宜”必须连同统计口径一起说。李不凯帖下的分歧提醒我们，一旦换成别人的任务，失败后的 token 和返工就可能改变选择。那些体验不足以推翻实验，实验也不足以替每个人选择服务。

llmspeed 进一步展示了另一种尺度：输出快慢可以先被体验，但模拟速度不能代替任务验收。当前较稳妥的判断是把成本写成有条件的记录：在哪些任务、哪种框架与缓存条件下、多少次尝试完成，最后还剩多少人工处理。下一次真正能加强或推翻这条判断的，是更广任务集中的重复结果，以及把修补时间纳入后的成本变化。

回到当期正文 ↗

2026-10-14 · 当时的记录

IBM 的芯片设计案例给旧成本问题增加了一个具体对照：相同的假设数量，得到的设计并不相同。[1] 因而“搜索更便宜”不能直接读成“买到了相同质量的结果”。对团队而言，先确定设计的速度和资源门槛，再比较满足门槛的费用，往往比先看价格倍数更有用。

值得保留的正面证据是，开放模型和服务系统一起降低了这次探索的推理账单。它不是靠少生成 token 得来的：文中开放配置反而使用了更多 token。这个细节修正了把便宜一律归因于“少做事”的阅读倾向。与此同时，模型配置、服务价格与缓存共同变化，现有比较并没有单独识别每项机制贡献多少。

如果目标是一个能用的紧凑设计，较便宜的方案可能已经够用；如果必须追求更低延迟，另一配置的额外收益也可能值得花钱。这不是用结果质量否定低成本，而是让低成本落在实际的选择上。作者增加开放搜索预算后的收益递减，也提醒我们，省下的钱不一定按比例变成更好的设计。多次独立搜索比一次继续扩展更好，还是更差，仍需比较。

Minions 则把费用问题移到资源取得方式：闲置 Mac 可以减少新增设备需求，却仍需要领取任务、保存输出和处理机器离线。[2] HN 的 dekhn 从自述的闲置算力经历提出尾延迟、异构兼容与管理问题。[3] 这不是对 Minions 的独立测试，但提供了原报告没有量化的核算对象。若已有资源只能在某些时段用，“能开始运行”与“能按期交付”就可能不同。

BranchOPD 的生成 token 节省又是第三种口径，教师评分、反向传播和环境恢复仍在这个数字之外。[4] 它与闲置设备和缓存路由没有共享实验，收益不能相加；并排阅读的意义是提醒我们，优化最先测到的那一段，未必是用户最后支付的那一段。

回访后的判断保留旧问题，但把比较条件补得更严格：不是只要求总预算一致，还要写清可接受结果的门槛。先预定一组任务、最低质量和截止时间，再核算成功及失败的推理、验证、综合、重试和人工成本；硬件探索同时报告延迟与面积，批任务报告最慢部分何时完成。若更便宜的方案只在放宽要求后达标，应如实呈现这个取舍。当前仍缺重复搜索和完整工作流账单，不能把三个案例合成普遍省钱结论。

回到当期正文 ↗

2026-10-13 · 当时的记录

Context Mode 的仓库把一组工具输出压到很小，当前网站又给出成对任务费用估算。[1][2] 前一个数字测量进入上下文的字节，后一个把一段任务中的模型调用计入费用。两者都可能有用，却不能互相替代。过去关注“省下的调用费会不会花在别处”，今天首先要修正一个容易延续的怀疑：不能在已读到新测量后，仍说项目只测过压缩比例。

新测量也留下具体条件。当前网关把输出处理、缓存和其他机制一起打开，并包含短回答风格；同一脚本任务反复运行，支持这个任务上的采样估计，不支持任意任务分布。文档又只展示区间完整落在省钱方向的结果。[2] 我因此把它当作值得继续检查的正面证据，而不会把节省区间写成所有用户都能达到的保证。仓库插件、商业网关和不同客户端仍要分开。

3月的外部分析追问检索往返成本，当前候选 PR 则给出一个更可操作的失败：某类非 ASCII 词边界让应有的记忆没有被召回。[3][4] 前者是方法批评，后者是作者报告的基准对照，两者都不是编辑独立复现。没有找到与找到错误信息会造成不同后果，评测不该只把它们记为一句“搜索失败”。

这使我更关注压缩的单位。对于问日志有多少错误，先写程序统计可能保留全部所需信息；对于判断一个约束是否违反，先给标题和计数可能省掉真正关键的条件。保存在外部不等于已进入模型的判断，也不等于它会想到正确检索词。应让任务预先指定需要找到的证据，记录回读次数、首次命中、误取旧约束以及最后是否完成。

SWE-TaskFlow 在同一组目标与最终测试下改变信息逐步出现的方式，费用就变了。[5] Meta 的新模型则强调跨会话记忆与持续执行。[6] 这些材料没有共同验证一种压缩方案，但让比较目标更清楚：既要看信息怎么存，也要看何时取出、任务改向后能否换掉旧判断。存储更省与使用更可靠应分别测量。

可以从几十个有明确证据位置的长任务开始，比较全文、摘要后按需检索、以及稳定前缀加按需检索三种方式。保持模型、最终测试和总预算一致，计入索引、追问与失败运行；另放一组有同名实体、旧版本约束和多语言术语的任务。若摘要方式只在简单统计题上省钱，就把适用范围收回到统计题。这样的负结果也能帮助我们决定哪些信息不应提前压掉。

回到当期正文 ↗

2026-10-11 · 当时的记录

Asana 的案例里，最有意思的地方不是标题中的倍数，而是一个违反直觉的结果：每轮删除旧截图、缩短历史，可能让调用更贵。原因是修改了前面的内容，后续请求不能继续复用原来的缓存前缀；改成分批清理，则能在多轮之间保留可复用的历史。[1][5] 在这套系统中，账单既与输入有多长有关，也与相邻两次输入有多少内容没变有关。

这使 Lynch 对自动模型分工的期待多了一层需要验证的条件。他不想为了简单子任务一直支付最强模型的价格，也不想自己负责拆解和切换。[2] 这个需求合理，但“把简单问题交给便宜模型”还不是完整的成本方案。接手的模型需要知道什么，前一个模型留下的结论能否检查，失败之后由谁接着做，都会改变最终账单。

2024 年的 RouteLLM 已经研究过按请求选择模型。除了省钱结果，值得留意的是它的分布变化：只用 Arena 偏好数据训练的路由器，在 MMLU 上表现接近随机路由；加入该领域的数据后才明显改善。[4] 这提示我们，判断任务难度也需要合适的经验。“这个请求看起来短”与“便宜模型能可靠完成它”之间，并没有现成的等号。

TokenRouter 讨论的是更细的 token 级路由，不能直接当作上述任务分工的实现。它把注意力放在切换后的异步执行与批处理，说明路由策略之外还有运行时调度问题。[3] 把这几份材料放在一起，我的推断是：选择模型时，除了下一步的能力和价格，还应考虑继续使用当前状态的价值。一个略贵但已有可复用上下文的选择，可能比便宜却需要重新铺垫的选择更合算；具体能否成立，要看服务的缓存规则和任务轨迹。

不过，“少切换”也不该变成新的口号。沿用当前模型可能延续一个已经错误的思路，过长历史可能干扰判断，重新整理上下文有时恰好能减少返工。真正要比较的是切换的增量收益与增量代价：它有没有提高最终完成率、减少后续尝试，代价又有多少来自重新输入、生成、排队和验证。只数调用次数，会把这些效果压成同一个数字。

我会把后续实验的核算单位定为一批原先就确定好的任务，而不是事后挑出的成功请求。分别比较固定模型、按子任务路由，以及把缓存与近期失败记录纳入决策的路由；保持验收要求和时限一致，报告整批总费用、完成率、等待时长，再给出每个合格结果分摊的费用。失败任务消耗的预算仍留在总费用里，否则最容易失败的方案反而可能显得便宜。

还需要看组合效果。可以把稳定前缀策略和模型路由分别打开、关闭，观察四种设置：两项优化是否互相促进，还是其中一项把另一项赖以成立的条件破坏了。今天的几份材料还没有回答这个组合问题。它比“多模型一定省钱”更值得追踪，也可能为路由器提供一个更实际的目标：不要只预测下一次回答的质量，要预测这一步会给后续任务留下什么成本。

回到当期正文 ↗