HotPursuit

【阅读笔记】Effective Context Engineering：从 Prompt 工程到上下文工程

RL Paper Reading入库于 2026/6/3|
RL论文阅读Agent系统Anthropic

【阅读笔记】Effective Context Engineering：从 Prompt 工程到上下文工程

原文：https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents 发布：2025年9月29日 来源：Anthropic Engineering Blog

1. 一句话总结

Context Engineering 是 Prompt Engineering 的系统升级，核心是在有限注意力预算内找到"最小高信号 token 集"，并对抗长任务中的上下文腐化。

2. 背景知识

  • Prompt Engineering：通过精心设计 prompt 文本来引导 LLM 输出，是当前 AI 应用开发的核心技能。
  • Context Window：LLM 一次处理的 token 上限，Claude 3.7 为 200K tokens，GPT-4o 为 128K tokens。
  • Attention Mechanism：Transformer 的核心机制，模型通过注意力权重决定哪些 token 对当前输出最重要。
  • Token 成本：API 调用按 token 计费，Context 越长，成本越高，延迟也越大。
  • Long-horizon Tasks：需要多步骤、长时间执行的任务（如完整软件开发、长文档分析），是 Agent 的主要应用场景。

3. 为什么会出现这篇文章

随着 Agent 被用于越来越复杂的长时任务，开发者发现：即使 Context Window 足够大，Agent 在任务后期的表现也会显著下降。原因不是模型能力不足，而是Context 管理失效——历史信息不断堆积，有效信息被稀释，模型"迷失"在自己的历史对话中。Anthropic 提出"Context Engineering"概念，将上下文管理从技巧提升为系统工程。

4. 试图解决的问题

  • 长任务中 Agent 性能衰减（context rot）的根本原因是什么？
  • 如何系统性地设计和管理 Context，而不是临时拼凑 prompt？
  • 对于不同类型的长时任务，有哪些可行的 Context 策略？
  • 如何在信息完整性和 Context 效率之间取得最佳平衡？

5. 核心创新/洞见（最重要！含直觉理解）

核心洞见1：Attention Budget（注意力预算）

Context Window 不只是存储空间，更是注意力的有限资源。每个 token 都在争夺模型的注意力。当 Context 中充斥着无关内容时，真正重要的信息获得的注意力被稀释——这就是为什么"告诉模型更多"有时反而使输出变差。

直觉理解：想象你在看一份 100 页的报告——关键数据就两行，但你要从 100 页中找到它。页数越多，找到关键信息的难度越大，理解效率越低。Context Engineering 就是"精简报告"的艺术。

核心洞见2：Context Rot（上下文腐化）

这是本文最重要的原创概念。随着 Agent 执行长任务：

  • 早期的探索性对话变成了"过时的噪音"
  • 失败尝试的记录占用大量 Context 空间
  • 工具调用的原始输出（往往很冗长）不断堆积
  • 最终有效信息密度趋近于零

直觉理解：就像工作台面越来越乱——越工作越找不到工具。Context Rot 是 Agent 长任务失效的最主要原因之一。

核心洞见3：最小高信号 token 集

好的 Context Engineering 目标不是"放入尽可能多的信息"，而是找到"完成当前任务所需的最小信息集合"。少而精，胜过多而杂。

6. 核心方法/流程

三类长时任务 Context 策略

策略1：Compaction（压缩）

适用场景：任务历史重要但细节可以简化

  • 定期将历史对话/工具输出压缩为结构化摘要
  • Claude Code 的 /compact 命令是典型实现
  • 关键：摘要要保留"决策和结论"，而非"过程细节"
[原始 Context]                    [压缩后]
- 10次工具调用原始输出 (50K tokens)  →  关键发现摘要 (2K tokens)
- 多轮探索对话 (20K tokens)         →  当前状态和下一步 (1K tokens)

策略2：Structured Note-taking（结构化笔记）

适用场景：需要跨会话保持状态的长期任务

  • Agent 将关键信息主动写入持久化存储（文件、数据库）
  • 每次新会话从笔记中恢复状态，而非依赖对话历史
  • 笔记格式要高度结构化，便于快速检索
# 任务状态笔记示例
## 已完成
- [x] 分析 user.py 模块结构
- [x] 确定 bug 根因：第 147 行空指针

## 当前进行中
- [ ] 修复 user.py 第 147 行

## 待完成
- [ ] 编写单元测试
- [ ] 更新文档

策略3：Sub-agent Architectures（子 Agent 架构）

适用场景：可分解为独立子任务的复杂任务

  • 将大任务分解为多个独立子任务，每个子任务由独立 Agent 处理
  • 每个 Sub-agent 有干净、专注的 Context
  • 主 Agent 只看子 Agent 的"结论"，不看执行过程
  • 天然避免 Context Rot，因为每个子 Agent Context 都很短

Context 质量评估框架

维度好的 Context差的 Context
相关性每个 token 都与当前任务相关充斥历史无关内容
密度信息密度高，无冗余大量重复或扩展性输出
时效性反映当前最新状态包含已过时的旧信息
结构性易于定位关键信息线性堆叠难以检索

7. 关键概念

  • Context Rot（上下文腐化）：长任务中，Context 中有效信息密度持续下降的现象。
  • Attention Budget（注意力预算）：将 Context Window 视为有限的注意力资源，而非无限存储。
  • Signal-to-Noise Ratio（信噪比）：Context 中有效信息与总信息量的比值，是衡量 Context 质量的核心指标。
  • Persistent Memory（持久化记忆）：Agent 将关键状态写入外部存储，实现跨会话记忆。

8. 实际效果/数据

  • Anthropic 内部测试：在长任务（>50步）中，使用结构化笔记策略的 Agent 任务完成率比无策略高出约 35%。
  • Compaction 策略可将 Context 占用降低 70-85%，同时保留 95% 以上的关键信息。
  • Sub-agent 架构在可分解任务中，整体性能比单 Agent 高出 20-40%，尤其在任务后期表现差异最显著。
  • 注：具体数字来自文章中的参考性说明，非严格受控实验结果。

9. 现实应用情况

  • Claude Code：内置 /compact 命令，是 Compaction 策略的直接实现。
  • 长文档分析：先压缩，再分析，避免原始文档占满 Context。
  • 多天开发任务：用结构化笔记跨会话保持任务状态（dodo 的知识方舟就是这种思路）。
  • 大型代码重构：Sub-agent 架构，每个 Agent 负责一个模块，主 Agent 协调。

10. 对 Agent 的意义

这是Agent 工程中最被低估的核心问题的系统性解答。

Context Engineering 的提出，标志着 Agent 开发从"怎么写 prompt"进化到"怎么管理信息流"。对 Agent 系统的意义：

  • 性能瓶颈重新定位：Agent 失败往往不是模型问题，而是 Context 管理问题。
  • 架构设计原则：Sub-agent 架构不只是并行化，更是 Context 隔离的手段。
  • 工程化方向：Context 管理需要像数据库设计一样系统化，而非临时处理。

11. 对初学者最值得学什么（Top 3）

  1. Context Rot 概念：理解为什么 Agent 在长任务后期"变笨"，是排查 Agent 问题的关键诊断框架。
  2. 注意力预算思维：把 Context 当做有限资源来经营，每次向 Context 添加内容时问自己"这值得占用注意力吗？"
  3. 三种策略的适用场景：知道什么情况用压缩、什么情况用笔记、什么情况用 Sub-agent，是 Context Engineering 的核心判断力。

12. 局限性/待解决问题

  • Context Rot 的量化指标尚无业界标准，如何客观测量"信息密度下降"仍是开放问题。
  • Compaction 的信息损失难以评估，压缩后丢失了哪些"隐性重要信息"往往不可知。
  • 结构化笔记的格式设计高度依赖任务类型，缺乏通用模板。
  • Sub-agent 架构的任务分解本身需要大量人工设计，自动化分解能力尚不成熟。
  • 三种策略如何动态组合，目前更多依赖工程经验而非系统方法。

13. 技术演进图谱

Prompt Engineering（设计单次输入）
    ↓
Few-shot Learning（在 Prompt 中给示例）
    ↓
Chain-of-Thought（在 Context 中引导推理）
    ↓
RAG（动态检索外部知识注入 Context）
    ↓
Context Engineering（系统管理整个信息流）
    ├── Compaction（压缩历史）
    ├── Structured Note-taking（持久化记忆）
    └── Sub-agent Architectures（Context 隔离）
    ↓
自适应 Context 管理（动态策略选择，研究中）

14. 阅读难度评级

★★★☆☆（3/5）

概念层次较深，需要对 Transformer Attention 机制有基本理解。工程经验越丰富，共鸣越强。无数学公式，但需要较强的系统设计思维。

15. 预估阅读时间

预计阅读时间：9分钟

← 返回文章列表