## 为什么给 AI 更多上下文，不一定更好？ 现在的大模型上下文越来越长。 几十万 token、上百万 token，直觉上当然是一件好事：能放进去更多代码、文档、聊天记录和日志，模型能参考的信息也更多。 但如果你真的让 AI 持续参与一个几小时、几天甚至更久的软件项目，可能会遇到一种有点反直觉的情况： **材料明明都还在，它却越来越容易抓错重点。** 一个要求它看过。 一个 Bug 它调查过。 某个反例甚至曾经明确指出过。 可经过几轮搜索、修改、测试和新的任务以后，它仍然可能在最后做出一个与这些信息不一致的判断。 这时候问题就不只是： > 上下文够不够长？ 而是另一个问题： > **模型能看到的信息越来越多以后，哪些信息还在真正影响当前判断？** --- 假设你让一个 AI 帮你持续维护一个软件项目。 过程中它可能看过： - 最初的用户需求 - 几十个源码文件 - 搜索结果 - 几万行日志 - 测试输出 - 三个失败方案 - 两次架构讨论 - 一堆临时假设 - 已经修掉的 Bug - 后来证明错误的判断 - 当前正在解决的问题 最直接的处理方式当然是： **只要装得下，就尽量都保留。** 但这里其实混在了一起的，是两个不同的问题： **Context capacity：能放进去多少。** 和 **Context utilization：放进去以后，模型能多可靠地利用它。** 一次推理中的 context，更像是： > **这一刻摊在模型面前的工作材料。** 它和人类“已经理解并长期内化了一项知识”的状态并不完全一样。 现代 Agent 系统当然可以使用 session、memory、RAG、数据库等方式保存长期状态，但某项信息最终想影响一次模型判断，仍然需要以某种形式成为这次推理可以使用的信息。 --- ## 信息在上下文里，不代表它一定会被同样好地利用 这不是一个新的观察。 2024 年发表于 TACL 的 **《Lost in the Middle》** 做了一个很直观的实验： 把回答问题所需要的信息放在长上下文中的不同位置。 结果发现，即使模型支持很长的 context window，重要信息所处的位置仍然会显著影响模型表现；在很多设置下，位于中间的信息利用效果明显更差。[1] 也就是说： > **“模型看得到”与“模型能稳定利用”之间还有距离。** 另一个 ICML 2023 的研究则向问题中加入与任务无关的信息，发现 irrelevant context（无关上下文）可以明显干扰大模型的推理表现。[2] 这意味着，当上下文越来越大时，我们真正需要考虑的已经不只是： > 能不能把资料塞进去？ 还包括： > **真正重要的东西，会不会被其他同时存在的信息稀释？** Anthropic 在关于 Agent context engineering 的公开文章中也把 context 描述为一种需要管理的有限资源，并提出一个很实际的目标： 尽可能找到**足以产生目标行为的最小高信号信息集合**。[3] --- ## 那么，把以前的内容总结一下呢？ 这是现在非常常见，也非常有效的方法。 但 summarization 解决容量问题时，也会产生另一个问题： **摘要本身就是一次新的语义判断。** 比如原始材料里有一句： > SDK 3.9.1 在某条路径下不会转发 idempotency header。 经过一次总结，它可能变成： > 存在 SDK compatibility issue。 再经过后续工作： > Compatibility handled. 最后留下： > Tests PASS. 这些表述并不一定哪一句是错的。 但它们显然已经不再携带完全相同的信息。 OpenAI 关于长 Session 的公开资料也提到 summarization 的几个典型代价，包括细节丢失、重要性权重发生变化、错误进入摘要，以及反复摘要带来的累计漂移。[4] 所以更稳妥的问题可能不是： > “哪些东西应该永远留在上下文里？” 而是把两个问题分开： > **现在需要模型看到什么？** 以及： > **以后需要时，什么还能重新找到？** --- ## 再进一步，就会碰到 Fresh Context 假设现在需要调查一个 Bug。 负责调查的 Agent 可能需要： - grep 几百个调用点； - 看三万行日志； - 试五个猜想； - 写临时脚本； - 排除四条错误路线； - 最后发现真正关键的两个事实。 这时候，负责整个任务最终判断的模型，是否真的需要继承： **三万行日志、五个猜想和四条死路？** 也许它真正需要的是： - 最终发现了什么； - 为什么可信； - 原始来源在哪里； - 还有什么没有确定。 这也是 multi-agent 除了“并行做事”以外，一个很重要的作用： > **不同的推理过程可以拥有不同的 working set。** 负责调查的人可以暂时沉入大量搜索结果。 负责实现的人只接收真正与实现有关的内容。 独立 Reviewer 可以从一个相对干净的上下文重新检查原始要求与候选实现，而不必完整继承实现过程中的全部假设。 负责全局判断的 Controller，则继续关注： > 用户最初到底需要什么？ > 当前证据到底支持什么？ --- ## 到这里，问题已经慢慢变了 一开始我们关注的是： > **怎样让 AI 拥有更多上下文？** 但在长期任务里，很快还会出现另一组问题： > 当前这次判断，究竟应该看到什么？ > 哪些局部搜索过程完成以后可以退出当前工作集？ > 哪些事实现在不用反复显示，但未来必须还能追溯？ > 一个重要反例出现以后，怎样避免它被后来的局部 PASS 无意中盖过去？ > 谁适合搜索，谁适合实现，什么时候值得重新用一个独立上下文挑战已有结论？ > 一个项目持续很久、目标已经变化过多次以后，怎样保持项目级连续性，而不是每次重新认识整个仓库？ 这些问题已经不完全是 **context length** 的问题。 它们更接近 **context engineering**，再继续往前，就是我现在很感兴趣的一个方向： **cognitive orchestration（认知编排）。** --- ## 这也是我做 Thaliris 的出发点 Thaliris 并不是单纯想把 context 压得更短。 它尝试把几类原本容易混在一起的东西拆开： 长期 Controller 保留项目目标、关键约束和最终判断责任。 调查、实现、审查可以拥有各自短期、聚焦的工作上下文。 一次调查可以读取大量材料，但后续不一定需要继承整个调查过程。 摘要可以很短，同时原始 evidence 和 provenance 仍然能够重新打开。 一次测试 `PASS`、一次 Agent `Completed`，都只代表有限范围内发生了什么，并不自动等于： > 用户最初的目标已经满足。 大量检索和机械工作也不一定需要最昂贵的模型亲自承担；高能力模型的注意力可以集中在更需要判断的地方。 而随着项目从一个目标进入另一个目标，局部工作上下文可以不断变化，控制层仍然可以维持一定的项目级连续性。 --- 我最近做了一支 Thaliris 的短片《案头 · ON THE DESK》。 回过头看，我发现影片里的很多设计——独立调查桌、被筛选后交回的卡片、重新打开原始材料、PASS 后重新审查——都建立在上面这些前提之上。 所以与其先解释某个具体项目，我更想先把这个问题本身讲清楚： > **长期 AI Agent 的难点，也许不只是让它看到更多信息。** > **还包括让正确的信息，在正确的时候，进入正确的判断。** --- ### 参考资料 **[1]** Liu, N. F. et al. (2024). *Lost in the Middle: How Language Models Use Long Contexts*. Transactions of the Association for Computational Linguistics, 12, 157–173. DOI: `10.1162/tacl_a_00638` **[2]** Shi, F. et al. (2023). *Large Language Models Can Be Easily Distracted by Irrelevant Context*. ICML 2023, PMLR 202:31210–31227. **[3]** Anthropic. *Effective context engineering for AI agents.* **[4]** OpenAI Cookbook. *Context Engineering — Short-Term Memory Management with Sessions.* 项目：**https://github.com/Iris0fTheValley/Thaliris** 支持dsh，codex，cloude