Claude上下文再大，也绕不开agent开发的“分治”艺术
你是否经历过这样的场景？
为了让AI理解一份百页合同，你将PDF分割成十几段，逐段上传。第一段问签约方，第二段问金额，到了第八段想问违约责任与前面条款的关联时，AI已经忘了第三段提到的违约金比例。你不得不回头，把相关段落再贴一遍，重新提问。
你心想：要是上下文窗口再大一点，就好了。
最近Anthropic将Claude的上下文窗口扩展至100万token。人们在欢呼：分块处理的时代结束了，我们终于可以把整个文档、整个代码库、整个谈判历史一次性丢给AI。
但真的是这样吗？
Anthropic在博客中写下一句容易被忽略的话：“一百万token的上下文，只有在模型能够回忆正确的细节并在此基础上进行推理时才重要。Opus在MRCR v2上得分为78.3%，是该上下文长度下前沿模型中的最高分。”
这句话揭示了一个反事实的真相：大窗口本身不是终点，有效推理才是。而当我们冷静下来审视时会发现——由于上下文永远无法装下客观事实的全部，分治处理这一古老智慧非但不会消亡，反而需要在新的技术背景下被重新理解和精细化。
如果我们可以合理地分配、切割场景、定义压缩规则、设计跨源查询逻辑，那么在很多任务中，我们可能根本不需要100万token的上下文。
问题的本质：当分治不可避免，我们的得失是什么
在拥有百万上下文窗口之前，人们不得不把长内容切碎处理。这带来三重损失：
- 压缩损失——为了把内容塞进有限窗口，必须压缩，压缩意味着细节丢失。
- 交叉比对损失——当内容被切成M块和N块，问题就变成了一个M×N的配对问题。每一次跨块查询都需要额外的上下文切换，而切换意味着遗忘。
- Token的重复计费——一篇文章一次给AI，系统提示词消耗一次；分成M次给，消耗M次。冗余输入和冗余输出都是成本的大头。
百万token窗口的诱人之处，在于它让我们看到了一