Context Engineering解读：Agent可靠性不只靠提示词，而靠上下文治理

摘要

Anthropic Engineering 在《Effective context engineering for AI agents》中给出一个明确判断：Agent 工程正在从 prompt engineering 走向 context engineering。提示词仍然重要，但真正决定长期 Agent 表现的，已经不只是系统提示词怎么写，而是每一轮推理时，模型看到哪些信息、丢弃哪些信息、用什么工具补充信息，以及如何跨长任务保持状态。

对研发团队来说，这个视角很关键。很多 Agent 系统失败，不是因为模型不会推理，而是因为上下文里塞了太多低信号信息：重复工具结果、无关历史、含糊工具说明、过长日志、失效记忆和未整理的文件内容。本文基于 Anthropic 文章，拆解上下文工程对 Agent 平台研发的实际意义。

背景：Prompt 只是上下文的一部分

早期 LLM 应用更多是一次性分类、总结、改写或生成，因此 prompt engineering 是主要工作。工程师关注系统提示词怎么写、示例怎么排、输出格式怎么约束。但 Agent 不一样。Agent 会在循环中调用工具、读取文件、写代码、处理日志、接收用户反馈，并把这些中间结果不断带入后续推理。

Anthropic 对 context engineering 的定义，是管理和维护 LLM 推理时可用 token 集合的策略。这包括系统提示词、工具定义、MCP 返回内容、外部数据、消息历史、文件路径、笔记、压缩摘要和子任务结果。也就是说，prompt 只是上下文的一层，不是全部。

随着 Agent 任务时间变长，问题会迅速放大。一次工具调用返回几百行日志，一次 grep 返回几十个文件片段，一次错误尝试留下多轮无效对话。模型的上下文窗口看起来很大，但注意力并不是无限的。上下文越大，低信号 token 越多，模型越容易失焦。

技术要点一：上下文是有限注意力预算

Anthropic 强调，LLM 会在长上下文中出现类似“context rot”的现象：token 数量增加后，对关键信息的准确召回和长程推理会下降。即便模型支持很长上下文，也不意味着应该把所有东西都塞进去。

工程上应该把上下文看成有限注意力预算，而不是廉价存储。每个 token 都要回答一个问题：它是否提高下一步正确行为的概率？如果只是为了“可能有用”而保留，就会稀释更关键的信息。

这对编码 Agent 尤其明显。一个失败测试的完整日志可能有 5000 行，但真正有用的是错误类型、失败文件、复现命令、最近相关改动和少量栈信息。把完整日志塞给模型，不一定比给一份结构化摘要更好。

技术要点二：系统提示词要在正确抽象层级

Anthropic 提到系统提示词有两个常见失败模式：一端是把复杂逻辑硬编码成脆弱的 if-else 提示词，另一端是给过于抽象的高层原则，假设模型已经理解隐含背景。好的提示词应该处在中间层级：足够具体，能指导行为；又足够灵活，允许模型用启发式解决新问题。

对研发团队来说，系统提示词更像平台宪法，而不是业务代码。它应明确角色、边界、工具使用原则、输出要求和风险处理方式，但不应该把每个业务分支都塞进去。细节应通过工具说明、Skills、项目文档、示例和运行时检索加载。

实践上，可以把提示词拆成 background_information、instructions、tool guidance、output description 等清晰段落。格式本身不是关键，关键是让模型能快速定位不同类型信息。

技术要点三：工具是上下文入口，也是污染源

工具让 Agent 与环境交互，但工具也是上下文污染的主要来源。Anthropic 指出，工具应该推动高效行为：返回 token-efficient 的信息，并鼓励 Agent 用更少步骤完成任务。

一个常见失败模式是工具集合膨胀。多个工具能力重叠，名称相近，参数含糊，模型就会在选择时摇摆。如果人类工程师都不能明确判断某场景该用哪个工具，Agent 通常也不会做得更好。

另一个失败模式是工具返回过大。搜索、日志、数据库、文件读取工具如果默认返回全量内容，会让 Agent 在后续推理里背着大量无关信息前进。更好的工具应提供摘要、分页、过滤、采样、top-k、错误聚合等接口，让模型按需深入。

技术要点四：按需检索比 upfront 全量加载更稳

Anthropic 将 just-in-time context 作为 Agent 设计趋势：不要在任务开始前预处理所有相关数据，而是保留轻量引用，例如文件路径、查询名、链接、目录结构，让 Agent 在运行时用工具逐步加载需要的内容。

Claude Code 就是典型混合模式。CLAUDE.md 这类项目说明会 upfront 放入上下文，而 glob、grep、文件读取、head、tail 等工具让 Agent 能按需探索代码库。文件名、目录结构、时间戳等元数据本身也会提供语义信号，帮助 Agent 判断哪些信息值得打开。

这对企业 Agent 很实用。相比把知识库检索结果一次性塞满上下文，不如给 Agent 一个可导航的信息地形图：目录、索引、实体 ID、查询模板、文档链接。模型先看地图，再决定走哪条路。

长任务治理：压缩、笔记和子 Agent

长任务会超过单个上下文窗口，Anthropic 给出三类技术：compaction、结构化笔记、多 Agent 架构。

Compaction 是在上下文接近限制时压缩历史，再用摘要开启新的上下文窗口。关键不是简单总结，而是保留架构决策、未解决 bug、实现细节和最近相关文件，同时清理重复工具结果。Anthropic 建议 compaction 先追求召回，确保重要信息不丢，再逐步提高精度。

结构化笔记是把状态写到上下文窗口之外，例如 TODO、NOTES.md、任务进度、决策记录。Agent 后续可以重新读取这些笔记，而不必保留全部对话历史。对研发任务来说，这比单纯依赖聊天上下文更可靠。

子 Agent 架构则把复杂探索隔离到干净上下文里。主 Agent 负责计划和综合，子 Agent 负责深度检索、局部分析或实验验证。子 Agent 可以消耗大量 token，但只把 1000 到 2000 token 的高密度结论返回主 Agent，避免主上下文被细节淹没。

实践建议：给研发团队的上下文治理清单

第一，给每类上下文设置预算。系统提示词、工具定义、项目文档、历史消息、工具结果、长期记忆都应有上限。不要等上下文窗口满了再处理。

第二，工具默认返回摘要。完整结果应写入文件或支持按需读取，模型上下文中只保留关键错误、路径、ID、计数和下一步建议。

第三，让 Agent 学会记笔记。长任务中要求它维护 TODO、progress、known_issues、decisions 等结构化文件。每轮工作结束时更新状态，而不是把状态留在对话里。

第四，建立 context review 指标。记录单次任务的 prompt tokens、工具结果 tokens、重复内容比例、被压缩次数、读取文件数量、无效检索次数。没有指标，就很难知道 Agent 是模型不行，还是上下文太乱。

第五，为不同任务选择不同策略。短任务适合少量 upfront context；代码库任务适合项目说明加按需 grep；研究任务适合子 Agent 并行探索；长迁移任务适合 compaction 加结构化笔记。

风险与限制

上下文工程不是越复杂越好。过度检索会让 Agent 浪费时间，过度压缩会丢失微妙信息，过多子 Agent 会增加协调成本。Anthropic 的建议仍然是先做能工作的最简单方案，再根据失败模式增加机制。

另一个风险是把上下文治理误解成“少给信息”。真正目标不是短，而是高信号。某些任务需要长背景或多个示例，盲目压缩反而会降低准确率。判断标准应是任务成功率、可复现性和错误类型，而不是 token 数字本身。

参考来源

• Anthropic Engineering - Effective context engineering for AI agents: https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents