AI 代理的高效上下文工程

摘要

本文由Anthropic应用AI团队撰写，系统阐述了"上下文工程"在AI代理开发中的核心地位。随着LLM能力增强，工程重心已从单次提示优化转向整体上下文配置管理。文章指出LLM存在"注意力预算"限制，过长上下文会导致"上下文腐蚀"。针对此，作者提出最小高信号上下文原则、动态检索策略，以及信息压缩、结构化笔记、子代理架构三大长任务管理技术。

内容框架与概述

文章开篇区分了提示工程与上下文工程的本质差异：前者聚焦于单次指令优化，后者则关注LLM推理时整体上下文状态的动态管理，包括系统提示、工具参数、历史记录和外部数据等多元素的协调配置。这一转变反映了AI代理从单轮交互向多回合长期任务演进的现实需求。

中间部分深入剖析了LLM的架构限制。Transformer的全连接注意力机制在长序列下产生n²级关系复杂度，加之训练数据偏向短序列，导致模型在长上下文中检索和推理能力衰减。基于此，作者提出有效上下文需在清晰与简洁间取得平衡，各组件（系统提示、工具、示例）需明确分工、信号强烈，并倡导从预加载转向"即时检索"的动态策略。

文章后半部分聚焦长任务场景的三大核心技术：信息压缩通过高质量摘要延续跨窗口任务；结构化笔记让代理在外部文件中维护长期记忆；子代理架构则通过分治协作应对复杂任务。作者总结认为，上下文工程是LLM应用范式的根本性转变，将持续塑造未来AI代理的设计理念。

核心概念及解读

上下文工程（Context Engineering）：区别于传统提示工程仅优化指令文本，上下文工程是对LLM推理时所有可用信息的系统性策划与管理，是一个随每次推理动态迭代的过程。

注意力预算（Attention Budget）：将LLM类比为拥有有限工作记忆的系统，每增加一个token都会消耗模型的"注意力资源"，超载将导致信息提取能力下降，需谨慎分配。

上下文腐蚀（Context Rot）：随着上下文token数量增加，模型准确召回信息的能力递减的现象，源于Transformer架构在长序列上的固有局限。

即时检索策略（Just-In-Time Retrieval）：代理不再预加载全部数据，而是仅维护轻量索引（如文件名、链接），通过工具按需动态加载所需信息，提升效率与灵活性。

子代理架构（Sub-agent Architecture）：复杂任务由多个独立子代理分工处理，各自维护独立上下文窗口完成深度工作，主代理负责协调与整合，实现高效的分布式任务处理。

原文信息

此摘要卡片由 AI 自动生成