22 篇博文 含有标签「context-engineering」

在扩展 AI Agent 时，大多数团队都会遇到一个违背直觉的失败模式：Agent 的工具集越强大，它的表现就越差。你为了处理更多场景而增加工具，准确率却下降了。你增加了更优秀的工具，它却变得更慢，并开始选错工具。你加入了编排逻辑来管理工具选择，结果你在原始的复杂性之上又重建了一层复杂性，而整个系统几乎无法运行。

增加工具的本能是错误的。生产环境中 Agent 的性能提升往往源于“删减”。

生产环境中的智能体存在一种失效模式，大多数工程师都是通过惨痛的教训才发现的：你的智能体在最初的几步表现良好，但在任务执行到一半时开始出现幻觉，遗漏了开头明确给出的细节，或者发出了一个与二十步前的指令相矛盾的工具调用。模型没有变。任务没有变难。上下文变了。

长时间运行的智能体积累历史记录的方式就像浏览器标签页消耗内存一样——无声无息、永不停歇，直到崩溃。每一个工具响应、观察结果和中间推理轨迹都会被追加到窗口中。模型会看到这一切，这意味着它在后续的每一步都必须对所有内容进行推理。随着上下文的增长，精度会下降，推理能力会减弱，模型会遗漏本应捕获的信息。这就是“上下文腐烂”（context rot），也是生产级智能体最常见的失效模式之一。

大多数生产环境中的 AI agent 失败并不是因为模型耗尽了上下文。它们发生的原因是模型在达到限制之前很久就已经发生了 漂移 (drift)。Forrester 将 “agent 漂移” 称为 AI 加速开发的隐形杀手 —— Forrester 2025 年的研究显示，近 65% 的企业级 AI 失败都可以追溯到多步推理过程中的上下文漂移或记忆丧失，而不是单纯的 token 耗尽。

这种区别至关重要。硬性的上下文限制是很清晰的：API 拒绝请求，agent 停止，你会收到一个可以处理的错误。上下文腐烂 (Context rot) 则是隐蔽的：模型继续运行，继续生成输出，但性能却在悄然下降。仅根据信息在上下文窗口中所处的位置，GPT-4 的准确率就会从 98.1% 下降到 64.1%。你不会收到错误信号 —— 你只会得到微妙的错误答案。

本文涵盖了在生产级 agent 中管理上下文的三种主要工具 —— 压缩 (compaction)、工具结果清理 (tool-result clearing) 和外部记忆 (external memory) —— 以及在你的 agent 发生漂移之前应用它们的实际策略。

你的 AI 编程助手不记得昨天发生了什么。每个会话都是冷启动的 —— 它不知道你使用的是 yarn 而不是 npm，不知道你禁用 any 类型，也不知道 src/generated/ 目录是神圣不可侵犯的，永远不应该手动编辑。因此，它会使用错误的包管理器生成代码，在你禁止的地方引入 any，偶尔还会覆盖掉那些需要你花一小时才能恢复的生成文件。你纠正了它。明天它又犯同样的错误。你再次纠正它。

这不是模型质量问题。这是一个配置问题 —— 解决方案就是一个纯 Markdown 文件。

CLAUDE.md、AGENTS.md 及其针对特定工具的同类文件，是 AI 编程助手在每个会话开始前阅读的简报。它们编码了助手原本需要重新发现或被纠正的内容：运行哪些命令、避免哪些模式、团队的工作流如何构建，以及哪些目录是禁区。它们相当于一份详尽的工程入职文档，被压缩成了一种优化过的、适合机器阅读的形式。

2025 年，近 65% 的企业级 AI 失败归因于多步推理过程中的上下文偏移（context drift）或记忆丢失 —— 而非模型能力问题。如果你的智能体（agent）在执行长任务时决策失误或失去连贯性，最可能的原因不是模型，而是上下文窗口（context window）中的内容。

“上下文工程”（context engineering）一词正在迅速普及，但其背后的学科内容是具体明确的：即在智能体运行轨迹的每一个推理步骤中，主动、刻意地管理进入和离开 LLM 上下文窗口的内容。它不是一段提示词（prompt），而是一个由工程师设计、供智能体遍历的动态信息架构。上下文窗口的作用类似于 RAM —— 有限、昂贵，且如果你不进行刻意管理，就会出现抖动（thrashing）。

大多数运行 AI 编程智能体（AI coding agents）的团队都在优化错误的变量。他们过度痴迷于模型选择 —— Claude vs. GPT vs. Gemini —— 却将周围的脚手架视为次要的配套工作。但基准测试数据和生产环境的实战经验告诉我们一个不同的故事：一个在演示中令人惊叹的模型与一个能够可靠交付生产代码的模型之间的差距，几乎完全取决于其周围的控制环（harness），而不是模型本身。

这个公式看似简单：智能体 = 模型 + 控制环 (Harness)。控制环是除此之外的一切 —— 工具 schema、权限模型、上下文生命周期管理、反馈循环、沙箱环境、文档基础设施、架构不变性。如果控制环搞错了，即使是最前沿的模型也会生成虚构的文件路径，在会话进行到 20 轮时破坏自身的约定，甚至在没写任何测试之前就宣称功能已完成。

大多数构建 LLM 系统的人最初几周都会沉迷于优化提示词。他们进行 A/B 测试，争论该使用 XML 标签还是 JSON，并不断迭代系统提示词，直到模型输出看起来正确的内容。然而，一旦进入生产环境，加入真实数据、记忆和工具调用——模型就会开始出现各种提示词调优无法解决的异常行为。问题从来都不在提示词上。

生产级 LLM 系统的真实瓶颈在于上下文——即模型输入中包含什么信息、以何种顺序排列、信息量有多少，以及这些信息是否与模型即将做出的决策相关。上下文工程是将该输入空间作为系统首要关注点进行设计和管理的学科。它包含了提示工程，就像软件架构包含了变量命名一样：较小的技能依然重要，但它并不能大规模地决定最终成果。

大多数 AI Agent 的 Bug 并不是模型本身的 Bug。模型只是在执行它被告知的操作——出问题的是你放入上下文（context）的内容。在 Agent 执行到一定阶段后，问题不在于能力，而在于熵：噪声、冗余和注意力错位的缓慢积累，这会降低模型生成的每一项输出的质量。研究人员称之为“上下文腐烂”（context rot），而且所有主流模型——GPT-4.1、Claude Opus 4、Gemini 2.5——在任何输入长度增加的情况下，无一例外都会表现出这种现象。

上下文工程是专门管理这一问题的学科。它比提示词工程（prompt engineering）更广泛，后者主要关注静态的系统提示词。上下文工程涵盖了模型在推理时看到的一切：你包含什么、排除什么、压缩什么、将内容放在哪里，以及如何在长期运行的任务中保持缓存状态。

你将智能体连接到 50 个 MCP 工具。它可以查询数据库、调用 API、读取文件、发送电子邮件、浏览网页。理论上，它拥有所需的一切。但在实践中，一半的生产事故都源于工具使用——错误的参数、上下文预算超支、级联重试循环，导致成本是预期的十倍。

这是大多数教程都会跳过的部分：你加载的每个工具定义都是预先支付的 Token 税，甚至在智能体处理单条用户消息之前就开始计算了。连接了 50 多个工具后，仅定义一项就会在每次请求中消耗 70,000–130,000 个 Token。这并非极端情况——这是任何连接到多个 MCP 服务器的智能体的默认状态。

大多数智能体演示都是无状态的。用户提问，智能体回答，会话结束——下一次对话从头开始。这对于计算器来说没问题。但对于一个应该了解你的助手来说，这就不行了。

有用的智能体和令人沮丧的智能体之间的差距，往往归结为一点：系统是否记住了重要信息。本文将详细阐述如何在生产级 AI 智能体中构建持久化、个性化的记忆——涵盖其四阶段生命周期、分层优先级规则以及如果你跳过工程设计将遇到的具体故障模式。