Home
Blog
让人工智能 Agents 脚踏实地：使用 Milvus 防止语境腐化的语境工程策略

让人工智能 Agents 脚踏实地：使用 Milvus 防止语境腐化的语境工程策略

Engineering

December 23, 2025

Min Yin

如果你参与过长时间的 LLM 对话，你可能会遇到这种令人沮丧的情况：长长的对话进行到一半时，模型开始漂移。答案变得含糊不清，推理能力减弱，关键细节神秘消失。但如果你把完全相同的提示放到新的聊天中，模型就会突然表现得专注、准确、脚踏实地。

这不是模型 "累了"，而是语境发生了变化。随着对话的增加，模型必须处理更多的信息，其优先排序能力也会慢慢下降。反熵研究表明，当上下文窗口从大约 8K 标记扩展到 128K 时，检索准确率会下降 15-30%。该模型仍有空间，但它会失去对重要内容的追踪。更大的上下文窗口有助于延缓问题的解决，但并不能消除问题。

这就是上下文工程的用武之地。我们不会一次性将所有信息都交给模型，而是塑造它所看到的内容：只检索重要的部分，压缩不再需要的内容，并保持提示和工具足够简洁，以便模型进行推理。我们的目标很简单：在适当的时候提供重要信息，而忽略其他信息。

检索在这里扮演着核心角色，尤其是对于长期运行的 Agents 来说。Milvus等向量数据库为有效地将相关知识拉回到上下文中奠定了基础，即使任务的深度和复杂性不断增加，系统也能保持稳定。

在这篇博客中，我们将探讨上下文轮转是如何发生的、团队管理上下文轮转的策略，以及从检索到提示设计的架构模式，这些模式能让人工智能 Agents 在长时间、多步骤的工作流程中保持敏锐。

为什么会发生上下文腐烂

人们通常认为，给人工智能模型提供更多的上下文自然会带来更好的答案。但事实上并非如此。认知科学表明，我们的工作记忆大约能容纳7±2 块信息。如果超出这个范围，我们就会开始遗忘、模糊或曲解细节。

LLMs 也有类似的表现--只是规模更大，失效模式更多。

问题的根源来自Transformer 架构本身。每个标记都必须与其他标记进行比较，在整个序列中形成成对关注。这意味着计算量会随着上下文长度的增加而增长O(n²)。将提示符从 1K 扩展到 100K 并不会让模型 "更努力地工作"，而是会让标记交互的数量增加10,000 倍。

然后是训练数据的问题。模型看到的短序列远远多于长序列。因此，当你要求 LLM 在极其庞大的上下文中操作时，你就会把它推向一个没有经过严格训练的环境。在实践中，对于大多数模型来说，超长上下文推理往往是不适用的。

尽管存在这些限制，长语境现在已不可避免。早期的 LLM 应用大多是单轮任务--分类、总结或简单的生成。如今，超过 70% 的企业人工智能系统都依赖于 Agents，这些 Agents 在多轮交互中保持活跃，往往长达数小时，管理着分支、多步骤的工作流程。长期会话已经从例外变成了默认。

那么，下一个问题就是：我们该如何保持模型的注意力，而又不至于让它不堪重负？

解决上下文旋转的上下文检索方法

在实践中，它往往以互补的模式出现，从不同角度解决上下文腐烂问题。

1.及时检索：减少不必要的上下文

上下文腐烂的一个主要原因是模型过载了它还不需要的信息。Claude Code-Anthropic的编码助手通过即时检索（JIT）解决了这一问题。

克劳德代码不会将整个代码库或数据集塞入其上下文（这会大大增加漂移和遗忘的几率），而是维护一个微小的索引：文件路径、命令和文档链接。当模型需要某项信息时，它会检索该特定项目，并在关键时刻--而不是之前--将其插入上下文。

例如，如果你要求克劳德代码分析一个 10GB 的数据库，它绝不会尝试加载整个数据库。它的工作方式更像工程师：

运行 SQL 查询，获取数据集的高级摘要。
使用head 和tail 等命令查看样本数据并了解其结构。
只在上下文中保留最重要的信息，如关键统计数据或样本行。

通过尽量减少保留在上下文中的内容，JIT 检索可以防止无关标记的积累，从而避免出现错误。由于模型只查看当前推理步骤所需的信息，因此能保持专注。

2.预检索（向量搜索）：防止语境漂移于未然

有时，模型无法动态地 "询问 "信息--客户支持、问答系统和 Agents 工作流程往往需要在生成开始之前就获得正确的知识。这时，预先检索就变得至关重要。

上下文腐坏的发生往往是因为模型收到了一大堆原始文本，并期望从中找出重要的内容。而预检索则相反：向量数据库（如Milvus和Zilliz Cloud）会在推理之前识别出最相关的片段，确保只有高价值的上下文才能到达模型。

在典型的 RAG 设置中：

文档被嵌入并存储在一个向量数据库（如 Milvus）中。
在查询时，系统会通过相似性搜索检索出一小部分高度相关的语块。
只有这些数据块才会进入模型的上下文。

这可以从两个方面防止垃圾信息：

减少噪音：无关或相关性较弱的文本永远不会进入上下文。
提高效率：模型处理的标记数量大大减少，从而降低了丢失重要细节的几率。

Milvus 可以在几毫秒内搜索数百万个文档，因此这种方法非常适合延迟很重要的实时系统。

3.混合 JIT 和向量检索

基于向量搜索的预检索通过确保模型从高信号信息而不是原始的超大文本开始，解决了上下文腐烂的一个重要部分。但 Anthropic 强调了团队经常忽略的两个真正挑战：

及时性：如果知识库的更新速度快于向量索引的重建速度，那么模型可能会依赖于陈旧的信息。
准确性：在任务开始之前，很难准确预测模型将需要什么--尤其是多步骤或探索性工作流。

因此，在实际工作负载中，混合应用是最佳解决方案。

向量搜索，获取稳定、高可信度的知识
Agents 驱动的 JIT 探索，用于探索不断变化或仅在任务中期才变得相关的信息

将这两种方法混合使用，既能获得向量检索的速度和效率，以获取已知信息，又能让模型灵活地发现和加载新的相关数据。

让我们看看这在实际系统中是如何工作的。以生产文档助理为例。大多数团队最终会采用两阶段管道：Milvus 驱动的向量搜索 + 基于 Agents 的 JIT 检索。

1.Milvus 驱动的向量搜索（预检索）

将文档、API 引用、更新日志和已知问题转换为 Embeddings。
将它们与产品区域、版本和更新时间等元数据一起存储在 Milvus 向量数据库中。
当用户提问时，运行语义搜索，抓取前 K 个相关片段。

这样就能在 500 毫秒内解决大约 80% 的常规查询，从而为模型提供了一个强大的、抗上下文干扰的起点。

2.基于 Agents 的探索

当初始检索不够充分时，例如，当用户询问的内容非常具体或具有时间敏感性时，Agent 可以调用工具来获取新信息：

使用search_code 查找代码库中的特定函数或文件
使用run_query 从数据库中提取实时数据
使用fetch_api 获取最新系统状态

这些调用通常需要3-5 秒钟，但它们能确保模型始终使用新鲜、准确和相关的数据运行--即使是系统事先无法预料的问题。

这种混合结构确保了上下文的及时性、正确性和特定任务，大大降低了长期运行的 Agents 工作流中上下文腐烂的风险。

Milvus 在这些混合场景中特别有效，因为它支持

向量搜索 + 标量过滤，将语义相关性与结构化约束相结合
增量更新，允许在不停机的情况下刷新Embeddings

这使得 Milvus 成为既需要语义理解又需要精确控制检索内容的系统的理想支柱。

例如，您可以运行以下查询

# You can combine queries like this in Milvus
collection.search(
    data=[query_embedding],  # Semantic similarity
    anns_field="embedding",
    param={"metric_type": "COSINE", "params": {"nprobe": 10}},
    expr="doc_type == 'API' and update_time > '2025-01-01'",  # Structured filtering
    limit=5
)

如何选择处理上下文旋转的正确方法

有了向量搜索预检索、即时检索和混合检索，问题自然就来了：你应该使用哪一种？

这里有一个简单而实用的选择方法，它基于你的知识的稳定性和模型信息需求的可预测性。

1.向量搜索 → 最适合稳定的领域

如果领域变化缓慢，但要求精确--金融、法律工作、合规性、医疗文件--那么由 Milvus 驱动的、具有预检索功能的知识库通常是最合适的。

信息定义明确，更新频率低，大多数问题都可以通过预先检索语义相关的文档得到解答。

可预测的任务 + 稳定的知识 → 预检索。

2.及时检索 → 最适合动态、探索性工作流

软件工程、调试、分析和数据科学等领域涉及快速变化的环境：新文件、新数据、新部署状态。在任务开始前，模型无法预测会需要什么。

不可预测的任务 + 快速变化的知识 → 即时检索。

3.混合方法 → 当两个条件都成立时

许多实际系统并不是纯粹稳定或纯粹动态的。例如，开发人员的文档变化缓慢，而生产环境的状态却每分钟都在变化。混合方法可以让你

使用向量搜索加载已知的稳定知识（快速、低延迟）
使用 Agents 工具按需获取动态信息（准确、最新）

混合知识 + 混合任务结构 → 混合检索方法。

如果上下文窗口仍然不够用怎么办？

上下文工程有助于减少过载，但有时问题更为根本：任务根本无法容纳，即使经过精心裁剪也无济于事。

某些工作流，如迁移大型代码库、审查多存储库架构或生成深度研究报告，在模型到达任务终点之前，上下文窗口可能会超过 200K 以上。即使有向量搜索做重活，有些任务也需要更持久的结构化内存。

最近，Anthropic 提出了三种实用策略。

1.压缩：保留信号，减少噪音

当上下文窗口接近极限时，模型可以将先前的交互压缩成简洁的摘要。良好的压缩可以保持

关键决策
限制和要求
未决问题
相关样本或示例

并删除

繁琐的工具输出
无关日志
多余步骤

挑战在于平衡。压缩得过猛，模型就会丢失关键信息；压缩得过轻，空间就会变得很小。有效的压缩可以保留 "为什么 "和 "是什么"，而丢弃 "我们是如何到达这里的"。

2.结构化笔记：将稳定的信息移出语境

系统可以将重要的事实存储在外部存储器中，而不是将所有东西都保存在模型的窗口内--一个独立的数据库或一个结构化的存储空间，Agent 可以根据需要进行查询。

举例来说，克劳德的神奇宝贝代理原型就存储了像以下这样的持久性事实：...........：

Pikachu leveled up to 8
Trained 1234 steps on Route 1
Goal: reach level 10

与此同时，瞬时细节--战斗日志、长期工具输出--则保留在活动上下文之外。这与人类使用笔记本的方式如出一辙：我们不会将每个细节都保存在工作记忆中；我们会将参考点存储在外部，并在需要时进行查询。

有条理的笔记可以防止因重复、不必要的细节而造成的上下文腐烂，同时也为模型提供了可靠的真实来源。

3.子代理架构：分而治之的大型任务

对于复杂的任务，可以设计一个多 Agent 架构，由一个领导 Agent 监督整体工作，同时由几个专门的子 Agent 处理任务的特定方面。这些子代理深入研究与其子任务相关的大量数据，但只返回简明、重要的结果。这种方法通常用于研究报告或数据分析等场景。

在实际操作中，最好一开始就使用单个 Agents 结合压缩来处理任务。只有在需要跨会话保留内存时，才应引入外部存储。多 Agents 架构应保留给真正需要并行处理复杂、专业子任务的任务。

每种方法都能扩展系统的有效 "工作内存"，而不会破坏上下文窗口，也不会引发上下文旋转。

设计真正有效的上下文的最佳实践

在处理上下文溢出后，还有一个同样重要的环节：如何首先构建上下文。即使使用了压缩、外部注释和子 Agents，如果提示和工具本身不是为了支持冗长、复杂的推理而设计的，那么系统也将举步维艰。

Anthropic 提供了一种有用的方法来思考这个问题--与其说它是一个单一的提示书写练习，不如说它是在三个层次上构建上下文。

系统提示：寻找黄金地带

大多数系统提示在极端情况下都会失败。过多的细节--规则列表、嵌套条件、硬编码例外--会使提示变得脆弱且难以维护。结构太少则会让模型猜测该怎么做。

最好的提示处于中间位置：结构化程度足以指导行为，灵活性足以让模型进行推理。在实践中，这意味着给予模型明确的角色、一般的工作流程和少量的工具指导--仅此而已。

举个例子：

You are a technical documentation assistant serving developers.
1. Start by retrieving relevant documents from the Milvus knowledge base.  
2. If the retrieval results are insufficient, use the `search_code` tool to perform a deeper search in the codebase.  
3. When answering, cite specific documentation sections or code line numbers.
## Tool guidance

search_docs: Used for semantic retrieval, best for conceptual questions.
search_code: Used for precise lookup in the codebase, best for implementation-detail questions.

…