放弃提示词，Anthropic是如何做 Context Engineering 的？

不知道各位赛博老板们奴役AI员工时，有没有发现一个神奇的现象：

相同的提示词，在原有对话窗口喂给大模型，和新开窗口喂给大模型，效果天差地别。

恭喜你，发现了一个非常有价值的结论：context腐化。

Anthropic数据显示，技术上，大模型支持的上下文长度虽然一直在增加，但当我们的与AI对话的上下文从8K增至128K tokens时，模型信息检索准确率就会下降15%-30%。出现的问题包括但不限于失焦、忘记关键信息或产生错误回答。

那么怎么解决这个问题？

你一定想到了：针对复杂任务，可以把任务分拆给不同模型；针对客服、代码等连续场景，可以压缩上下文。总而言之，通过动态管理，想尽一切办法，精简喂给大模型的上下文长度

恭喜你，已经掌握了最近一年来最时髦的AI落地范式：context engineering 上下文工程。

那么，context engineering的行业进展究竟如何，不同场景下我们又该如何合理使用，如何把向量数据库与context engineering更好结合，本文将一一解答。

01 

为什么上下文不是越多越好?

心理学研究表明，人类的工作记忆容量大约是7±2个信息块，超过这个限度，我们就会开始遗忘或混淆。

AI其实也一样，甚至这种遗忘与混淆比人类还严重。

这源于Transformer架构的数学本质:每个token需要与其他所有token建立关联，这导致计算复杂度是O(n²)。当上下文从1K增加到100K时，模型需要处理的token关系数量增长了10,000倍。

更重要的是，模型的训练数据中，短序列出现的频率远高于长序列。这意味着模型在处理超长上下文时，本质上是在做它不太擅长的事情。

但一个问题是，在早期的LLM应用，超过80%的用例是单次分类或文本生成任务。但到了2025年，超过70%的企业级AI应用需要Agent在多轮交互中持续工作，有的甚至需要运行数小时完成复杂任务，上下文长度边长已经无可避免。

这也正是我们需要上下文工程的原因。

具体怎么做，我们可以先看一下Anthropic自家的AI编程助手Claude Code的解决思路。

做AI coding时，它只维护一个轻量级的索引系统(文件路径、查询语句、网页链接等)，然后在需要时动态加载数据。

举个例子:你让它分析一个10GB的数据库时，它不会把所有数据都读进来，而是:

先用SQL查询获取数据摘要

用head和tail命令查看数据样本

只把关键统计结果保留在上下文中

这种即时检索(Just-in-Time)的策略，让它能处理远超上下文窗口限制的任务。

但只有即时检索就能解决所有问题吗？

答案是否定的。

02 

混合策略预检索+实时探索登上舞台

说到即时检索，就得提到一个关键技术:向量数据库。

在传统的RAG(检索增强生成)架构中，我们会提前把知识库转换成向量embeddings，存储在专门的向量数据库中，然后在推理前通过语义相似度检索相关内容。

这种方法的优势很明显:速度快、成本低。 比如用Milvus这样的向量数据库，可以在毫秒级完成百万级文档的语义检索，这对于需要快速响应的应用(如客服机器人、智能问答)是刚需。

但Anthropic指出了一个容易被忽视的问题:预检索有时效性和精准度的双重困境。

时效性问题:如果知识库更新了，但向量索引还没重建，AI就会基于过时信息回答

精准度问题:在任务开始前，你很难预判AI在执行过程中会需要哪些信息

那是不是说向量检索没用了?

恰恰相反。最佳实践是混合策略:用向量检索处理静态知识，用Agent工具处理动态探索。

用一个实际场景说明:假设你在开发一个技术文档助手，架构应该是这样的：

第一层:Milvus向量检索(预加载)

把公司的技术文档、API文档、历史issue都向量化存入Milvus

用户提问时，先通过语义检索召回Top-K最相关的文档片段

这一步解决了80%的常见问题，响应时间<500ms

第二层:Agent实时探索(按需加载)

如果预检索的内容不够，Agent可以调用工具:

用search_code工具在代码仓库中精确查找

用run_query工具从数据库获取实时数据

用fetch_api工具获取最新的系统状态

这一步处理复杂问题，可能需要3-5秒

为什么Milvus特别适合这个场景? 因为它支持混合检索(向量+标量过滤)和动态索引更新。举个例子:

# 在Milvus中可以这样组合查询

collection.search(

    data=[query_embedding],  # 语义相似度

    anns_field="embedding",

    param={"metric_type": "COSINE", "params": {"nprobe": 10}},

    expr="doc_type == 'API' and update_time > '2025-01-01'",  # 结构化过滤

    limit=5

)

这样既能利用语义理解，又能精确控制检索范围，让Agent的注意力预算花在刀刃上。

那么问题来了，混合检索、预检索、实时检索，我们什么时候该用哪种策略?

Anthropic给出了一个判断框架:

一句话概括：金融、法律等领域，知识更新频率低但准确性要求高，适合以Milvus为核心构建知识库;而软件开发、数据分析等领域，环境变化快且需要深度探索，更适合Agent主导的即时检索。

03 

上下文窗口不够用时怎么办？

通过向量数据库，可以避免所有信息一股脑的塞给大模型，但对于一些需要持续工作数小时的复杂任务(比如大型代码库迁移、深度研究报告)，即使有向量数据库，200K的上下文窗口也会被填满。

Anthropic总结了三种应对策略:

1.压缩

若上下文空间快用完时，让AI把之前的对话总结成简短版本，替换掉原来的详细内容。

其中，需要重点保留的内容是设计决定、未修复的问题、关键细节，可以删除的是不必要的工具输出内容。

在这个过程中，压缩太多会丢失重要细节，我们需要在记住全面信息和保持精确度之间找平衡

2.结构化笔记(Structured Note-taking)

让AI把重要信息记录到外部数据库，需要的时候再读取这些内容

例如，Claude玩宝可梦游戏时，会记录简单信息如在1号路训练了1234步，皮卡丘升到8级，目标是10级，更多细节则记录在外部。它的好处是信息可以长期保存，可以在不同对话间保持连续性，且几乎不占用资源

3. 多Agent架构(Sub-agent Architecture)

对于复杂任务，我们可以设计一个主agent管理整体工作，多个专门的agent负责深入分析相关子任务的大量信息，但只返回精简的重要结果。这个思路一般用于研究报告或数据分析场景比较多。

实践中，我们应该首先尝试单Agent加压缩方法来解决问题;只有当需要跨会话保持记忆时，才引入外部存储;而多Agent架构则应该保留给那些确实需要并行处理的复杂任务。

04 

实践指南

另外，Anthropic还给了一个理论框架图。

这张理论框架图可从三个层次理解：

首先，设计系统提示词时要寻找恰到好处的指令深度，避免过于详细或过于模糊；

其次，将具体规则通过工具API和少量高质量示例来实现，而不是塞满条件判断；

最后，动态信息应当从系统提示中剥离，改为按需获取，以维持上下文清晰度。

1.系统提示词:找到合适的Goldilocks区间

系统提示词设计中存在两种常见错误。第一种是过于具体，即编写大量条件逻辑，这不仅容易导致错误，还使后续更新变得困难。第二种是过于笼统，仅提供一般性指导而缺乏明确的执行方向。

正确的做法是找到Goldilocks区间:既要具体到能引导行为，又要灵活到给模型留出推理空间。

推荐结构:

你是一个技术文档助手,服务对象是开发者...
1. 优先从Milvus知识库检索相关文档
2. 如果检索结果不足,使用search_code工具深入查找
3. 回答时引用具体的文档章节或代码行号
## Tool guidance
- search_docs: 用于语义检索,适合概念性问题
- search_code: 用于精确查找,适合实现细节问题
...

2.工具设计:少即是多

工具太多往往是导致失败的常见原因。当人类工程师无法清晰判断应该使用哪个工具时，AI同样难以做出更好的选择。

设计原则:

每个工具功能单一、边界清晰

参数描述明确，避免歧义

工具之间尽量不重叠

Anthropic在文章最后提到了一个重要观点:随着模型能力提升，工程的复杂度会下降。

但这不意味着上下文工程会消失。

恰恰相反，它会从技巧性工作演变为架构性工作，就像从写汇编代码进化到设计系统架构。

作者介绍

Zilliz黄金写手：尹珉