与 AI 协作分析 · 6/7
Context 还放得下，就应该一直往里面放吗？
假设一个 Agent 有 1M 的 context window，到了 800k 才触发自动压缩。这只是用来讨论的假设，不代表某个产品的规格或压缩门槛。我想问的是：眼前这个分析，真的需要一直带着这 800k 的内容吗？
我更想根据分析进展，决定哪些 context 应该继续带着走，以及哪些内容已经可以先保存备查。
Context 还放得下，就应该继续往里面放吗？
与 Agent 分析一段时间后，对话里通常已经有好几版 SQL、不同分母算出来的结果、初步猜测，以及一轮轮的修正。
比如分析活动参与率，我们可能先用全体活跃用户当分母，发现不合理，又试了符合活动资格的用户，最后确认采用已解锁活动入口的人。
这些讨论都有价值。但口径确认后，接下来做用户分群，还需要每一轮都带着前面所有的试算与讨论吗？
如果持续把这些内容放进模型输入，除了 token 消耗，我更在意的是：目前采用的定义，会不会跟那些已经放弃的方案混在一起？（前面才说这个分母不用了，后面它又拿回来算，原来我们刚刚只是礼貌性地交换意见）。
接近容量门槛时，把对话整理成摘要，是一种常见的处理方式。但 context 还剩多少空间，跟这一阶段的分析是不是已经可以收敛，是两件事，并且有时会有冲突。
有些选择在很早的时候就确认了，但当时没有压缩；对话快装不下时刚好在进行大型连贯分析，压缩完后好多数据要重拿。
我们其实一直在告诉 Agent，哪些内容可以收敛了
仔细想想，分析时我们常说的几句话，其实已经提供了很明确的讯号：
| 协作中的讯号 | 应留下的内容 | 仍须分清的状态 |
|---|---|---|
| 「这个分母确认了，接着往下做」 | 采用的口径、选择原因、适用范围 | 采用口径不等于所有结果都已验证 |
| 「这条路先停，样本量不够」 | 尝试的方法、停止原因、证据位置与重启条件 | 停止不等于成功完成 |
| 「这个结果先留着，等等跟另一组比较」 | 结果与位置，以及尚未完成的比较 | 部分结果不能先当成最终结论 |
我们原本就在做这些判断。如果能在当下把它们整理成后续可用的状态，就不必每次都从整段对话里重新辨认：哪些只是提过、哪些已经确认、哪些还欠一次验证。
我暂时把这种方式叫做「自然压缩」：随着分析推进，根据人的选择，让 context 一段段收敛。
通用压缩需要从已有记录里辨认重点；分析工作流则多了一个可以利用的条件——我们正在审阅、验证、调整方法，而这些选择本身就能成为整理的依据。
当然，这也包含「先不要收敛」。人说先保留、还没确认的东西，就应该继续维持待验证的状态，不能因为要写一份漂亮的摘要，就顺手把问题解决了。
这也让我想到，当 Agent 产出越来越快，验证这些产出的成本怎么办？至少在 context 收敛时，「我同意先这样做」跟「这个结果已经验证过」得分清楚。
采用的口径、通过的检查、还没排除的疑问，要连同对应证据一起留下来，不然压缩几轮后，很容易只剩一句看起来什么都确认过的结论。
当下可以少带，但需要时要找得回来
不过，压缩之后就真的不会再用到了吗？
主管在会议上追问：「你当时怎么判断这群人的样本不够？」如果只剩一句「样本不足，已停止」，我们还是得回头找当时的 SQL、样本分布，以及采用的判断标准。
只靠摘要，通常没办法还原被省略的细节。所以我认为这套方法要成立，得同时处理「目前带着什么」与「细节存在哪里」。
- 目前的 context：采用的计划、口径、必要理由、未解问题，以及对应证据的位置
- 工作区：保存计划版本、查询、结果与审阅纪录，用 lineage 串连，需要时取回
像是已停止的分析方向，后续不必一直带着整份旧 Plan 工作，但要知道它为什么停、证据在哪里。如果后来补到了数据，就能回头判断是否值得继续。
这也是我在 Lantide Data 里想做的事：把分析中原本就有的审阅、执行、验证与迭代，变成整理 context 的自然节点。Agent 根据已确认的选择保存分析状态，后续再依任务取得需要的内容。
这不会让摘要变成无损压缩，整理与取回也都有成本。但至少我们有机会根据工作的进展，决定什么需要持续参与分析、什么可以先保存备查。
对我来说，context 管理值得关心的，除了能装多少，还有能不能跟着分析进度收敛，以及在问题改变时，找回需要的细节。
延伸阅读
在 Lantide Data 中试用这套分析工作方式：下载 Lantide Data。
上一篇：团队做过的分析，怎么成为人与 Agent 都能接手的经验？ · 下一篇：文件版本之外：用 Change Context 留下分析判断的转折