Effective context engineering for AI agents

Overview

  1. Context engineering vs. Prompt engineering 上下文工程与提示工程
  2. Why context engineering is important to building capable agents ? 为什么上下文工程对构建高性能智能体至关重要?
  3. The anatomy of effective context 高效的上下文构成要素
  4. Context retrieval and agentic search 上下文检索与智能体搜索
  5. Context engineering 结论

Context engineering vs. Prompt engineering 上下文工程与提示工程

什么是上下文工程?

LLMs often requires thinking in context — considering the holistic state available to the LLM at any given time and what potential behaviors that state might yield.

What configuration of context is most likely to generate our model’s desired behavior?

Context engineering as the natural progression of prompt engineering. Prompt engineering refers to methods for writing and organizing LLM instructions for optimal outcomes

Context engineering refers to the set of strategies for curating and maintaining the optimal set of tokens (information) during LLM inference, including all the other information that may land there outside of the prompts

Context engineering is the art and science of curating what will go into the limited context window from that constantly evolving universe of possible information.

In contrast to the discrete task of writing a prompt, context engineering is iterative and the curation phase happens each time we decide what to pass to the model.

intuitively,

  1. LLM 总是需要 <考虑上下文>, 现在构建 ai 应用的一个焦点问题是: 什么样的上下文设置,能够让我们的模型输出是最符合我们期望的?
  2. 上下文工程考虑大语言模型在任何特定时间所能获取 token 整体状态,以及该状态可能产生的潜在行为
  3. 上下文工程其实是从 PE 演进出来的概念
  4. 上下文工程定义: 在大语言模型推理过程中筛选和维护最优信息集的一系列策略,包括可能出现在提示词之外的所有其他信息
  5. 上下文工程是从不断演变的海量潜在信息中筛选出适合放入有限语境窗口的内容的艺术与科学
  6. 与编写提示词这一离散任务不同,上下文工程是一个迭代的过程,而且每次我们决定向模型传递什么内容时,就在筛选合适的上下文

Why context engineering is important to building capable agents ? 为什么上下文工程对构建高性能智能体至关重要?

  1. LLM 存在 “上下文衰退现象” 导致 context 是一种有限的资源: 随着上下文窗口中 token 数量的增加,模型从该上下文中准确回忆信息的能力会下降; contex 必须被视为一种边际收益递减的有限资源; 每引入一个新 token 都会在一定程度上消耗这一预算,这就使得我们更有必要仔细筛选可供大语言模型使用的 token
  2. 简单说明为什么 LLM 存在 “上下文衰退现象”?
    1. Transformer 架构决定了注意力的形成机制: 每个 token 能够关注整个上下文中的其他每个 token; 随着上下文长度的增加,模型捕捉这些成对关系的能力会被稀释,这就在上下文大小和注意力焦点之间产生了一种自然的张力 (这个比喻绝了).
    2. 模型的注意力模式是从训练数据分布中发展而来的,在这些数据中短序列数据总比长序列多, 这意味着模型在处理全上下文依赖关系方面经验更少,专门的参数也更少; 让模型从小上下文中学出来长序列理解能力, 目前没有完美的技术解决方法, 当前采用 position encoding interpolation 技术,让模型在小上下文样本学习过程中能够处理更长的序列,不过这会在一定程度上降低对标记位置的理解能力; 这些因素会导致性能呈梯度下降,而非急剧下滑:模型在更长的上下文中仍然保持较强的能力,但与在较短上下文中的表现相比,在信息检索和长距离推理方面的精度可能会有所降低

The anatomy of effective context 高效的上下文构成要素

高效的上下文构成要素: SP、Tool、Few-shot Prompt、Memory

Calibrating the system prompt 校准 SP

  1. 系统提示词应当极其清晰,使用简单、直接的语言,并以适合智能体的 “right altitude” 呈现观点. “right altitude” 是介于两种常见失效模式之间的 “Goldilocks 区”
    • 一种极端情况: 工程师在提示词中硬编码复杂、脆弱的逻辑,以引发精确的智能体行为. 这种方法会造成脆弱性,并随着时间的推移增加维护复杂性
    • 另一种极端情况: 工程师有时会提供模糊、高层次的指导,无法为大语言模型提供关于期望输出的具体信号,或者错误地假设存在共享语境
    • 最佳高度需要取得平衡:足够具体以有效指导行为,同时又足够灵活,为模型提供强大的启发式方法来指导行为
  2. PE 划分: 将提示词组织成不同的部分
<background_information>
<instructions>
## Tool guidance
## Output description
  1. PE 最佳实践: 先用可用的最佳模型测试一个最精简的提示词,看看它在你的任务上表现如何,然后根据初始测试中发现的失效模式,添加清晰的指令和示例来改进性能

Tool 工具

  1. 构建工具的原则: 构建 LLM 能充分理解且功能重叠最小的工具。与设计良好的代码库的功能类似,工具应当是独立封装的、能容错的,并且其预期用途要极其明确。输入参数同样应当具有描述性、明确性,并能发挥模型固有的优势
  2. Tool 调用最常见错误表现原因之一是工具集臃肿,工具集涵盖了过多功能,或者导致在选择使用哪种工具时出现模糊的决策点。如果人类工程师无法明确说出在特定情况下应该使用哪种工具,那么也不能期望AI智能体做得更好。为智能体精心挑选一套最小可行的工具集,还能在长期交互中实现更可靠的维护和上下文精简动作

Few-shot prompting 少样本提示

  1. Few-shot prompting 是必不可少的
  2. 选择最优的 few-shot: 干活团队往往会在提示词中堆砌一长串边缘案例,试图阐明大语言模型在特定任务中应遵循的每一条可能的规则。但 anthropic 不建议这样做: 应该要精心挑选一组多样化、具有代表性的示例,以有效地展示智能体的预期行为。对于大语言模型而言,示例就是那 “胜过千言万语的图画”

Context engineering for long-horizon tasks 长程任务的语境工程

long-horizon tasks, 长上下文任务需要在 token 中保持连贯性、一致性和目标导向,因此构建 agent 核心一个任务是解决上下文窜口大小的限制, 总共有三类方法: 压缩、结构化笔记、子 agent 架构, 下面介绍下这几个方法

  1. Compaction 压缩

    1. 压缩是指对话接近上下文窗口的限制的时候对内容总结,并使用该总结重新启动一个上下文窗口;压缩通常是提升上下文工程中提高长期的连贯性的重要手段;压缩的核心是高保真提炼上下文内容,使得智能体在 performance 损失最小的情况下继续运行
    2. 在 Claude Code 中, 将消息历史传递给模型总结压缩最关键的细节, 压缩总结的内容是: 架构决策、未解决的漏洞、实现细节,同时丢掉冗余的工具输出和信息, 然后利用压缩总结和最近访问的五个文件工作
    3. 压缩的艺术在于 [选择保留什么] 和 [选择舍弃什么], 过度激进的压缩可能会导致一些细微但是关键的上下文丢失;
    4. 对于搞压缩的模型,需要非常精细调整压缩 PE;评估指标上看,要遵循先召回率后准确率的原则,首先要最大化召回率,保证压缩提示词能捕捉到每一个相关的信息; 然后再慢慢迭代看能不能消除多余的内容, 提高准确率
  2. Structured note-taking 结构化笔记法

    Structured note-taking, or agentic memory, is a technique where the agent regularly writes notes persisted to memory outside of the context window. These notes get pulled back into the context window at later times.

    1. 结构化笔记或者叫代理化记忆/结构化记忆, 结构化笔记和压缩的关键区别是在窗口外持久化的技术, 结构化记忆会在存储之后拉回到上下文中;
    2. Claude玩《精灵宝可梦》展示了在非编码领域中例如玩游戏,记忆如何改变智能体的能力. 该智能体在数千个游戏步骤中保持精确的记录—追踪各种目标,例如记下来 “在过去的1234步中,我一直在1号道路训练我的宝可梦,皮卡丘已朝着10级的目标提升了8级”. 在没有任何关于记忆结构的提示的情况下,它绘制已探索区域的地图,记住已解锁的关键成就,并保存关于战斗策略的战略性笔记,这些笔记帮助它了解哪些攻击对不同的对手最有效
  3. Sub-agent architectures 子智能体架构

    1. 不用单一的 agent,而是用多个 agent 维护上下文状态,有个 main-agent 进行协调记忆工作,sub-agent 还要它使用工具或者其他进行广泛探索, 用到的 token 可能用几万个,但最终返回的结果大概 1000-2000 个 token
  4. 以上三种方法的选择:

    1. 压缩: 能在需要大量来来回回交流的任务中保持对话流畅性
    2. 结构化笔记: 在有明确里程碑感、迭代式发展的场景中表现最好
    3. 多智能体架构: 在非常复杂的研究和分析工作中,能带来显著收益

Context engineering 结论

  1. 上下文工程代表了 LLM 落地的一种根本性的关键转变;精心设计提示词不是最重要的,而是要审慎筛选每一步给到模型的信息
  2. 不管是采用压缩、调用工具或者让其他 agent 持续调用,核心目标都是:找到最小规模的有效信号 token 集合以最大程度提高实现预期结果的可能性
  3. 虽然模型能力不断变强, 但是仍然将 context 视为一种宝贵的、有限的资源;上下文工程师构建可靠的高效的 agent 的核心原则

Reference

[1]. Effective context engineering for AI agents.


转载请注明来源 goldandrabbit.github.io