上下文工程概念与落地实践本文整理Context Engineering上下文工程的核心观念与可执行做法主要依据 Anthropic 工程博客 Effective context engineering for AI agents2025-09并结合本仓库已有模式做对照说明。目标读者在构建多轮 Agent、工具链或长任务自动化时需要系统管理「模型每一轮能看到什么」的工程师。1. 上下文工程在讲什么1.1 定义上下文Context某次推理时实际进入大语言模型、参与采样的全部 token 集合系统提示、工具定义、MCP、外部检索结果、消息历史、中间产物等。上下文工程在约束与目标之下持续遴选、裁剪、更新这些 token使模型在多轮、长时域任务上稳定产出期望行为。它不是一次性「写好 prompt」而是每次调用前都要做的策展curation。1.2 与 Prompt 工程的关系维度Prompt 工程上下文工程焦点指令怎么写、怎么分段、示例怎么放整盘状态本轮该放进哪些信息、历史怎么处理、工具返回怎么截断典型场景单次分类、单轮生成Agent 循环、多工具、长对话、跨会话任务迭代单位改 system prompt / few-shot改「进窗策略」检索、摘要、外部笔记、子 Agent 边界可以把它理解为Prompt 工程是上下文工程的一个子集Agent 时代的主战场在「整窗管理」。1.3 为什么必须认真对待Context rot上下文衰减窗口变长后模型对其中细节的准确回忆与利用会下降并非无限堆字就能变强。注意力预算上下文在工程上应视为有限资源新 token 会稀释对其它部分的有效「注意力」。Agent 循环产数据每轮工具输出、中间推理都会膨胀「可能相关」的信息若不治理噪声会淹没信号。原则原文精神在可接受的行为目标下追求尽可能小、但信号足够强的 token 集合。2. 上下文的组成部分与做法要点2.1 系统提示System prompt高度altitude避免两端——一端是把复杂 if-else 业务规则全写进提示脆弱、难维护另一端是过于空泛、默认模型「已经懂你的业务」。结构用 Markdown 标题或 XML 风格分段如背景、指令、工具说明、输出格式帮助模型解析格式本身不如「信息是否必要且清晰」重要。起步方式用当前最强模型先试最小可用提示再针对失败模式增量补规则与示例而不是一上来堆砌边角案例。2.2 工具Tools工具是 Agent 与环境的契约设计目标包括返回尽量省 token、语义不重叠、失败可恢复。反模式工具过多或边界模糊——若人类工程师无法明确说清「此情此景用哪个工具」不能指望模型更稳。实践维护MVP 工具集随任务演化再扩展工具描述与参数名应对模型友好自解释、歧义少。2.3 示例Few-shot继续推荐少量、多样、能代表期望行为的范例。不推荐把无数 edge case 规则塞进 prompt应提炼成典型范式其余交给运行时检索或工具。2.4 消息历史与其它动态信息默认假设历史越长策展越重要。对工具结果深历史里的原始大段输出往往可以清除或替换为摘要轻量 compaction 的一种只要不影响当前决策所需事实。3. 运行时检索从「预灌全文」到 Just-in-time3.1 思路Embedding 预检索仍常见更 Agent 化的做法是保留轻量引用路径、URL、查询 ID、片段定位需要时再用工具拉取。类比人类不背整本书而是用目录、书签、索引按需加载。渐进披露progressive disclosure通过探索列表、预览、head/tail逐步缩小相关子集避免一次性把大对象塞进上下文。3.2 混合策略一部分关键材料 upfront如项目里的AGENTS.md/CLAUDE.md类说明一部分靠 grep/glob/读文件即时拉取。边界取决于任务静态域可多读一点高动态或大体量数据域更依赖 JIT 强工具习惯。4. 长时域任务的三类技术当 token 规模持续超过「舒适区」时原文归纳三类手段可组合手段作用适用直觉Compaction压缩将临近上限的对话/轨迹摘要后开启新窗口丢掉冗余工具输出等需要保持对话连贯、长链工具调用结构化笔记 / 外部记忆把进度、决策、依赖写入上下文外持久存储需要再读回里程碑清晰、跨多会话子 Agent 架构子任务在干净子窗口深挖主 Agent 只收浓缩摘要如 1k–2k tokens复杂检索/研究、可并行探索Compaction 注意过度激进会丢掉「当时看起来次要、后来才关键」的细节实现上可先偏召回再迭代精度删冗余。5. 落地实践清单可直接当评审表5.1 设计阶段是否明确列出「必须始终在窗内」与「仅按需加载」的信息类系统提示是否达到合适高度不过度硬编码、不过度模糊工具集是否为最小可用且无职责重叠few-shot 是否为canonical集合而非规则大全5.2 运行阶段工具返回是否有默认截断/结构化摘要尤其列表、大 JSON、长网页多轮后是否有清除旧工具原始输出或滚动摘要的策略是否用引用 工具代替「把整库贴进 prompt」长任务是否具备Compaction / 笔记 / 子 Agent中至少一种预案5.3 观测与迭代能否从日志中看到「每轮进窗 token 量级」与主要来源历史 / 工具 / RAG失败案例是否先区分指令问题vs上下文噪声/缺失vs工具契约问题6. 延伸阅读AnthropicEffective context engineering for AI agents同系列Building effective AI agents工作流 vs Agent 等定义平台能力Claude Developer Platform 上的Memory / context management与tool result clearing等特性原文有提及具体以官方文档为准。7. 一句话备忘上下文工程 把上下文当作有限注意力预算在每一轮推理前做高信号、小体积的策展与 Prompt 工程并行是构建可靠 Agent 的基础能力。
AI Agent 开发 --- 上下文工程：概念与落地实践（四）
上下文工程概念与落地实践本文整理Context Engineering上下文工程的核心观念与可执行做法主要依据 Anthropic 工程博客 Effective context engineering for AI agents2025-09并结合本仓库已有模式做对照说明。目标读者在构建多轮 Agent、工具链或长任务自动化时需要系统管理「模型每一轮能看到什么」的工程师。1. 上下文工程在讲什么1.1 定义上下文Context某次推理时实际进入大语言模型、参与采样的全部 token 集合系统提示、工具定义、MCP、外部检索结果、消息历史、中间产物等。上下文工程在约束与目标之下持续遴选、裁剪、更新这些 token使模型在多轮、长时域任务上稳定产出期望行为。它不是一次性「写好 prompt」而是每次调用前都要做的策展curation。1.2 与 Prompt 工程的关系维度Prompt 工程上下文工程焦点指令怎么写、怎么分段、示例怎么放整盘状态本轮该放进哪些信息、历史怎么处理、工具返回怎么截断典型场景单次分类、单轮生成Agent 循环、多工具、长对话、跨会话任务迭代单位改 system prompt / few-shot改「进窗策略」检索、摘要、外部笔记、子 Agent 边界可以把它理解为Prompt 工程是上下文工程的一个子集Agent 时代的主战场在「整窗管理」。1.3 为什么必须认真对待Context rot上下文衰减窗口变长后模型对其中细节的准确回忆与利用会下降并非无限堆字就能变强。注意力预算上下文在工程上应视为有限资源新 token 会稀释对其它部分的有效「注意力」。Agent 循环产数据每轮工具输出、中间推理都会膨胀「可能相关」的信息若不治理噪声会淹没信号。原则原文精神在可接受的行为目标下追求尽可能小、但信号足够强的 token 集合。2. 上下文的组成部分与做法要点2.1 系统提示System prompt高度altitude避免两端——一端是把复杂 if-else 业务规则全写进提示脆弱、难维护另一端是过于空泛、默认模型「已经懂你的业务」。结构用 Markdown 标题或 XML 风格分段如背景、指令、工具说明、输出格式帮助模型解析格式本身不如「信息是否必要且清晰」重要。起步方式用当前最强模型先试最小可用提示再针对失败模式增量补规则与示例而不是一上来堆砌边角案例。2.2 工具Tools工具是 Agent 与环境的契约设计目标包括返回尽量省 token、语义不重叠、失败可恢复。反模式工具过多或边界模糊——若人类工程师无法明确说清「此情此景用哪个工具」不能指望模型更稳。实践维护MVP 工具集随任务演化再扩展工具描述与参数名应对模型友好自解释、歧义少。2.3 示例Few-shot继续推荐少量、多样、能代表期望行为的范例。不推荐把无数 edge case 规则塞进 prompt应提炼成典型范式其余交给运行时检索或工具。2.4 消息历史与其它动态信息默认假设历史越长策展越重要。对工具结果深历史里的原始大段输出往往可以清除或替换为摘要轻量 compaction 的一种只要不影响当前决策所需事实。3. 运行时检索从「预灌全文」到 Just-in-time3.1 思路Embedding 预检索仍常见更 Agent 化的做法是保留轻量引用路径、URL、查询 ID、片段定位需要时再用工具拉取。类比人类不背整本书而是用目录、书签、索引按需加载。渐进披露progressive disclosure通过探索列表、预览、head/tail逐步缩小相关子集避免一次性把大对象塞进上下文。3.2 混合策略一部分关键材料 upfront如项目里的AGENTS.md/CLAUDE.md类说明一部分靠 grep/glob/读文件即时拉取。边界取决于任务静态域可多读一点高动态或大体量数据域更依赖 JIT 强工具习惯。4. 长时域任务的三类技术当 token 规模持续超过「舒适区」时原文归纳三类手段可组合手段作用适用直觉Compaction压缩将临近上限的对话/轨迹摘要后开启新窗口丢掉冗余工具输出等需要保持对话连贯、长链工具调用结构化笔记 / 外部记忆把进度、决策、依赖写入上下文外持久存储需要再读回里程碑清晰、跨多会话子 Agent 架构子任务在干净子窗口深挖主 Agent 只收浓缩摘要如 1k–2k tokens复杂检索/研究、可并行探索Compaction 注意过度激进会丢掉「当时看起来次要、后来才关键」的细节实现上可先偏召回再迭代精度删冗余。5. 落地实践清单可直接当评审表5.1 设计阶段是否明确列出「必须始终在窗内」与「仅按需加载」的信息类系统提示是否达到合适高度不过度硬编码、不过度模糊工具集是否为最小可用且无职责重叠few-shot 是否为canonical集合而非规则大全5.2 运行阶段工具返回是否有默认截断/结构化摘要尤其列表、大 JSON、长网页多轮后是否有清除旧工具原始输出或滚动摘要的策略是否用引用 工具代替「把整库贴进 prompt」长任务是否具备Compaction / 笔记 / 子 Agent中至少一种预案5.3 观测与迭代能否从日志中看到「每轮进窗 token 量级」与主要来源历史 / 工具 / RAG失败案例是否先区分指令问题vs上下文噪声/缺失vs工具契约问题6. 延伸阅读AnthropicEffective context engineering for AI agents同系列Building effective AI agents工作流 vs Agent 等定义平台能力Claude Developer Platform 上的Memory / context management与tool result clearing等特性原文有提及具体以官方文档为准。7. 一句话备忘上下文工程 把上下文当作有限注意力预算在每一轮推理前做高信号、小体积的策展与 Prompt 工程并行是构建可靠 Agent 的基础能力。
