一次高 Token 消耗任务的复盘

记录时间：2026-07-01 06:50:10

这是一轮 Codex 协作的成本复盘。核心任务并不是普通写作，而是从 284 篇巴菲特相关原文里，提取“他认为不该做的、错误的、需警惕的、Stop-doing 的事”，并进一步归纳出什么样的人、公司、财报指标和文化是在做错事。

结果文章做出来了，校验也跑完了；但 token 消耗明显偏高。真正值得记下来的，不是“这次花了多少”，而是下次如何在保持质量的前提下，把同类任务压到更合理的成本区间。

这轮到底做了什么

任务大致分成五段：

先让 3 个 Explore 子代理探查仓库结构、文章规范和既有内容；
写计划文件，并澄清产出形式和取材深度；
让 9 个子代理分批扫描 284 篇原文，其中 5 个中途失败，之后串行重跑补齐；
整理来源矩阵底稿，并把文章重构成五类主体结构；
跑 validate、build、test，再抽查 42 条引用，修正 2 处问题，最后删除工作草稿。

后面几个追问，比如“为什么消耗这么多 token”“为什么不用脚本读语料”“把经验存为记忆”“本轮完整复盘”，几乎不花 token。真正的大头集中在第一个核心任务，尤其是“读取并判断 284 篇原文”这一段。

成功取材子代理的 token 已经约 309 万，再加上前期探查、失败子代理的无效读取、主对话承接结果的滚动上下文，这一个任务占了全轮 90% 以上的消耗。

三个主要浪费点

1. 把整篇原文喂给 LLM

最大浪费来自“整篇读取”。有些股东大会原文单篇就超过 200KB，子代理会把整篇放进上下文，再让模型判断其中是否包含目标信息。

更合理的做法应该是两步：

先用脚本或 rg 通过关键词、否定词、风险词、管理层词、财报指标词定位命中片段；
再只把命中片段及其前后文交给 LLM 做语义判断。

脚本适合做“定位”，LLM 适合做“判断”。这轮把两件事都交给 LLM，等于让模型拿着整本书找页码，成本自然失控。

2. 子代理失败后重跑

本轮有 5 个子代理中途失败。失败前它们已经读取了大量文件，但没有形成可用产出；之后为了补齐覆盖范围，又重新跑了一遍。

这部分属于纯浪费，估计占 15% 到 20%。如果前面先用脚本切片，即使子代理失败，重跑的输入也会小很多。

3. “宁多勿漏”导致过度摘录

为了保证质量，我给取材代理的方向偏向“宁多勿漏、逐字抄录”。结果是材料池比最终文章实际需要多 5 到 10 倍。

这在全量研究阶段有价值，但如果目标是写一篇结构清晰的文章，其实不需要穷尽所有证据。每类主体保留 8 到 10 条最强引用，通常已经足够支撑论点。

下次怎么提问更省

这不是要求用户写复杂 prompt，而是在任务里加几个约束旋钮，让执行路径从一开始就更省。

1. 明确深度档位

最省的一句话是：

先用脚本 grep 定位，只读命中片段，再做提取。

如果目标不是学术级穷尽，可以再加：

重点文件优先，够用即可。

或者：

每类主体最多 8 到 10 条最强引用，不要穷尽。

这会直接改变执行策略：先用机器筛薄语料，再让 LLM 做高价值判断。

2. 给产出设上限

没有上限时，模型会倾向于把所有“可能有用”的内容都摘出来。更好的约束是：

每节挑 5 到 8 条最有代表性的材料。

这能避免前期摘出几百条，后期只用几十条的浪费。

3. 大任务先做小样本

对于 200 篇以上的语料任务，更稳的流程是：

先扫 20 篇，给我看产出质量和格式，我确认后再铺开全量。

小样本能暴露关键词设计、分类方式、引用格式和文章结构的问题。方向不对时，只损失 20 篇，而不是 284 篇。

4. 直接指定“脚本压薄”

这轮之后，同类任务应默认采用：

脚本 grep / rg 定位
-> 切出命中片段与前后文
-> LLM 做语义归类和取舍
-> 再进入文章写作

这条经验已经存进长期记忆。以后遇到大语料、长原文、全量抽取类任务，不应直接把整篇文章喂给子代理。

5. 把澄清前置

这轮中途澄清了两个问题：产出形式和取材深度。如果一开始就写清：

重构现有那篇；全量扫，但每类限 10 条最强证据。

就能少一轮往返，也能让后面的取材和写作更受控。

一句话结论

本轮 90% 以上 token 花在读取 284 篇原文上，其中 60% 到 70% 本可以通过“grep 定位 -> 切片 -> LLM 判断”省掉。

下次同类任务，最有效的提示不是写更长，而是加一句方法约束：

先脚本压薄语料，再让 LLM 提取；每类只保留最强证据。

这能在不明显牺牲质量的前提下，大幅降低 token 和时间成本。