从“提示词奴隶“到“AI架构师“：Anthropic上下文工程大揭秘，小白也能驯服大模型！

关注

原创最新推荐文章于 2026-11-10 00:57:14 发布 856 阅读 AI 写同款· GEO 优化 ›

第4章-Context Engineering：上下文的工程化《从Harness Engineering 到 Loop Engineering：长程任务Agent原理与实战》 Context Engineering（上下文工程）：研究在 LLM 推理的每个时刻，输入上下文（系统提示、对话历史、检索片段、工具结果、文件内容、用户身份、环境状态等）的构造、筛选、排列、压缩与遗忘的工程学科。模型的输出质量，是上下文质量的函数。当模型给定后，工程师能做的唯一事情就是优化这个函数的输入。更形式化地，设模型为MMM，输入上下文为CCC，任务目标为GGGQualityMC→GQualityMC→G模型MMM不可改，目标GGG。阅读详情

放弃提示词，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在文章最后提到了一个重要观点:随着模型能力提升**，**工程的复杂度会下降。

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

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

作者介绍

如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

在这里插入图片描述