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

大多数 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 智能体中构建持久化、个性化的记忆——涵盖其四阶段生命周期、分层优先级规则以及如果你跳过工程设计将遇到的具体故障模式。