从提示词工程到上下文工程

Anthropic公司上个月29日发布了一篇长文，关于智能体上下文工程，针对这篇文章去阅读学习了下，顺带做个总结。

原文链接：https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

01

—

Prompt Engineering vs Context Engineering

上下文指从大型语言模型（LLM）采样时包含的token集合。

如下图所示提示词工程和上下文工程的对比，提示词是引导大模型去如何思考得到我们想要的信息，而上下文工程将智能体中的大模型输出的信息进行整合提炼或持久化管理，这二者不是相互替代的关系，而是相辅相成的关系。

Prompt Engineering 解决“单次问答”最优解；

Context Engineering 解决“多轮自主任务”最优解。

02

—

上下文工程对智能体的重要性

文中提到了上下文会“腐烂”的观点。

Anthropic 用“大海捞针”实验给出一组冷酷数据：

• 上下文长度 <8k 时，模型召回率 95%+；
• 长度 32k 时，召回掉到 78%；
• 长度 100k 时，关键信息“视而不见”概率升至 30%。

可以看到，随着上下文窗口中token数量的增加，模型从该上下文中准确回忆信息的能力下降。

这种现象是源于LLM的架构约束。LLM基于transformer架构，该架构使每个token都能关注整个上下文中的每个其他token。这为n个token产生了n²的成对关系。随着上下文长度的增加，模型捕捉这些成对关系的能力会变得薄弱，这在上下文大小和注意力焦点之间产生了一种天然的张力。

这些现实意味着，深思熟虑的上下文工程对于构建有能力的智能体至关重要。

03

—

好上下文的4个配方

1、提示词：高信号、低噪音

不要在提示词中写“if A 且 B 且 C 则执行 D”的脆弱逻辑；也不要只说“请尽量做好”。正确姿势是——给出边界、目标、输出格式，让模型自己推理路径。

我们建议将提示词组织成不同的部分（如<背景信息>、<指令>、## 工具指导、## 输出描述等），并使用XML标记或Markdown标题等技术来划分这些部分。

2、智能体工具调用：高效token和高效智能体行为

工具允许智能体与其环境进行操作，并在工作时引入新的、额外的上下文。

我们看到的最常见的失效模式之一是工具集过于臃肿，涵盖太多功能或在决定使用哪个工具时导致模棱两可的决策点。

如果人类工程师无法明确说出在给定情况下应使用哪个工具，就不能期望AI智能体做得更好。

为智能体策划一个最小可行工具集也可以导致在长时间交互中更可靠的维护和精简上下文。

通过工具返回token高效的信息，和高效的智能体行为，对提升token效率是极其重要的。

3、示例（few-shot）：典型优于边缘

用 3 个覆盖 80% 主流场景的示例，比 20 条“罕见 corner case”更能让模型举一反三。

4、动态检索

在Anthropic的另一篇文章（Building effective agents： https://www.anthropic.com/engineering/building-effective-agents ）中介绍了基于LLM的工作流和智能体之间的差异，对智能体重新做了定义：LLM在循环中自主使用工具。

可以看到现在工程师在设计智能体的上下文的方式发生了一些转变。许多AI原生应用采用某种形式的基于嵌入的推理前检索，以呈现重要上下文供智能体推理。

该方式无需预先处理所有相关数据，采用"即时"方法构建的智能体维护轻量级标识符（文件路径、存储查询、网页链接等），并使用这些引用通过工具在运行时动态加载数据到上下文中。

这种方法反映了人类认知：我们通常不会记住整个信息库，而是引入外部组织和索引系统，如文件系统、收件箱和书签，以便按需检索相关信息。

04

—

长程任务如何解决上下文问题

当任务从“分钟级”拉长到“小时级”，上下文窗口必然爆掉。

Anthropic 内部总结出三把“瑞士军刀”：

1、压缩（Compaction）

例如在Claude Code中，通过将消息历史传递给模型来总结和压缩。

该模型在丢弃冗余工具输出或消息的同时，保留了架构决策、未解决的错误和实现细节。

可以优先对智能体中的工具调用及结果进行压缩清除，原因是一旦工具在消息历史深处被调用，智能体就不需要再次看到原始结果。

2、结构化笔记（Structured note-taking）

结构化记笔记，或智能体记忆，是智能体定期将笔记写入持久化到上下文窗口外内存的技术。这些笔记会在以后的时间点被拉回上下文窗口。

3、子智能体架构（Sub-agent architectures）

子智能体架构提供了绕过上下文限制的另一种方法。不是一个智能体试图在整个项目中维护状态，专门的子智能体可以用干净的上下文窗口处理集中的任务。主智能体与高级计划协调，而子智能体执行深度技术工作或使用工具查找相关信息。每个子智能体可能会进行大量探索，使用数万个token或更多，但仅返回其工作的浓缩、提炼总结（通常1,000-2,000token）。

这种方法实现了关注点清晰分离——详细的搜索上下文仍隔离在子智能体内，而主智能体专注于综合和分析结果。Anthropic在《How we built our multi-agent research system》（https://www.anthropic.com/engineering/multi-agent-research-system）文中所述，在复杂研究任务上比单智能体系统显示出显著改进，在 100 页 PDF 分析任务上，子智能体方案准确率提升 27%，token 消耗降 40%。

05

—

结语

提示词时代，我们像搭讪高手，用一句话吸引模型；

上下文时代，我们像电影导演，用整场戏讲好故事。

当你的智能体开始自己查资料、写笔记、派小弟，请记住：“限制它的从来不是智商，而是你给它的注意力预算。”