大模型上下文工程实践- 上下文管理策略
二、上下文管理的策略
在上一节中，我们介绍了上下文带来的问题，接下来我们来探讨使用哪些管理策略可以减少这些问题在大模型应用中产生
2.1、RAG
检索增强生成（RAG）是指选择性的添加相关信息，以帮助 LLM 生成更好的回复
关于 RAG 后续上下文工程里面会仔细讲解，在这里就不深入讨论了
每当上下文窗口上限增加的时候，就会诞生一场新的“RAG 已死”的争论，其实 RAG 也会改变，无论上下文的窗口上限如何增加，在大模型应用开发的过程中RAG 或许都会有”一席之地“
正如一句话：“如果你把你的上下文当作一个杂货抽屉，垃圾就会影响你的回复”
2.2、工具配置和定义
在上下文的工具定义部分，应只加入与当前输入相关的工具定义，提供给 LLM 使用
选择相关工具最简单的方法是将 RAG 应用在你的工具描述中，通过将工具描述存储到向量数据库中，RAG 能够根据输入来检索选择最相关的工具
在对 DeepSeek-v3 进行提示时，团队发现：当可用工具数量超过 30 个时，选择合适的工具就变得至关重要。超过 30 个之后，工具的描述开始互相重叠，导致混淆。而当工具数量超过 100 个时，模型几乎必然无法通过测试。利用 RAG 技术将工具数量筛选到 30 个以内，可以显著缩短提示长度，并将工具选择的准确率提升多达 3 倍
但是如果你的工具定义不多，并且边界清晰，那其实没有必要使用 RAG 来检索工具，完整的将你的工具定义提供给 LLM 效果会更好
2.3、上下文隔离
上下文隔离（Context Quarantine）指的是将上下文隔离到各自专用的线程中，每个线程由一个或多个 LLM 独立使用
当我们的上下文太长并且都是有效的时候，无法进行压缩裁剪，这个时候我们可以使用将任务分解成为更小、更隔离的工作给 LLM，每一个 LLM 都有自己的上下文
在 Anthropic 的博客文章中有详细的介绍
搜索的本质是压缩：从庞大的语料库中提炼见解。子代理通过并行操作自己的上下文窗口来促进压缩，在将最重要的标记压缩给主要研究代理之前，同时探索问题的不同方面。每个子代理还提供了关注点的分离——不同的工具、提示和探索轨迹，这减少了路径依赖性，并能够进行彻底的独立调查。
研究适合这种设计模式。当给定一个问题时，可以识别出几个子问题或探索领域，并使用多个代理分别提示。这不仅可以加快信息收集和提炼的速度（如果有计算资源的话），而且可以防止每个上下文积累过多信息或不相关的信息，从而提供更高质量的结果：
我们的内部评估显示，多智能体研究系统在涉及同时追求多个独立方向的前序查询中表现尤为出色。我们发现，以 Claude Opus 4 为主智能体、Claude Sonnet 4 为子智能体的多智能体系统，在我们的内部研究评估中比单智能体 Claude Opus 4 表现高出 90.2%。例如，在要求识别信息技术 S&P 500 公司所有董事会成员的任务中，多智能体系统通过将任务分解给子智能体来找到正确答案，而单智能体系统则因缓慢的顺序搜索而未能找到答案。
这种方法也有助于工具配置，当使用多智能体的架构设计时，可以为每一个智能体配置专属的工具定义
2.3、上下文修剪
上下文修剪是从上下文中移除无关或不需要的信息的行为
代理在触发工具和组装积累上下文的时候，在正式将上下文输入给 LLM 之前，进行上下文的内容评估并且移除冗余部分时值得的，因为这样会让上下文更加精简的同时发挥模型更大的推理能力
有一些实际开发策略时有效的：Token 压缩策略，根据不同的模型来决定压缩上下文不同的部分，并且会有一个压缩的策略，先压缩中间，如果还是不够，在压缩上或者下，主要目的还是根据不同场景保留最相关的上下文信息给 LLM，详细的 Token 压缩策略会在下文解释
2.3、上下文总结
上下文总结是将累积的上下文浓缩成简要摘要的行为
当上下文尤其是会话的历史记录超过最大的上下文长度时，这个时候可以针对历史记录生成一个简短的摘要，最好在这个简单的摘要中能够保留核心的信息
最后
本文节选自我正在整理的 「上下文工程实践」 项目，该项目已完整发布在 GitHub 上。
如果你希望相关的章节与案例，可以前往项目仓库查看：
👉 https://github.com/WakeUp-Jin/Practical-Guide-to-Context-Engineering