AI Agent 为什么越运行越容易跑偏？从提示词工程到上下文工程的实践思考

前言

随着大模型技术不断发展，AI 应用正在从简单的聊天问答，逐步走向能够自主调用工具、执行任务和处理复杂工作流的 AI Agent。

然而，在实际开发中，我们经常会遇到一个有趣的现象：

一个 AI Agent 刚开始执行任务时表现正常，但随着对话变长、工具调用增多、任务步骤增加，它的表现反而可能逐渐下降。

例如：

• 用户明确要求只修改一个文件，Agent 后续却修改了其他文件。

• 前面已经确认的条件，在后续执行中被忽略。

• 工具返回了大量日志，Agent 却没有抓住真正的错误信息。

• 任务已经完成，Agent 仍然重复执行相同操作。

• 对话越长，模型越容易混淆之前的决策与当前状态。

这些问题不一定是模型本身能力不足，也可能与应用的上下文管理方式密切相关。

这就引出了一个值得关注的概念：Context Engineering（上下文工程）。

本文将从 AI Agent 的实际开发场景出发，讨论上下文工程为什么重要，以及如何通过工程化设计提高 AI 应用的稳定性。

一、什么是上下文工程？

传统的提示词工程（Prompt Engineering），主要关注如何把一个问题描述清楚，让大模型更准确地理解任务。

例如：

“请帮我写一个 Python 函数。”

通过改进提示词，我们可以进一步补充函数需求、输入输出、异常处理和测试要求。

而上下文工程关注的范围更广。

它不仅考虑用户说了什么，还要考虑：

1. 当前任务的目标是什么？

2. 模型应该看到哪些背景信息？

3. 哪些历史决策需要保留？

4. 哪些工具输出值得加入上下文？

5. 哪些信息已经过期？

6. 如何判断任务执行到哪个阶段？

可以把两者简单区分为：

提示词工程关注如何表达任务，上下文工程关注如何为模型准备执行任务所需的信息环境。

对于单轮问答，清晰的提示词可能已经足够。

但对于需要连续执行几十个步骤的 AI Agent，仅依靠一段很长的提示词往往不够。

二、为什么上下文越长，不一定越好？

大模型虽然拥有一定长度的上下文窗口，但上下文长度并不等于有效信息量。

在复杂任务中，一个 Agent 可能需要读取代码、查询文档、调用工具、分析错误、生成文件并运行测试。

假设某次执行包含以下信息：

如果将这些内容全部原样保留，模型需要在大量信息中寻找真正重要的内容。

这可能产生三个问题。

第一，关键信息被淹没。

例如用户要求“不能修改原项目”，但大量日志和历史讨论可能使这个限制在后续执行中不再突出。

第二，过期信息产生干扰。

某个错误在第一个阶段已经解决，但旧的错误日志仍然保留，模型可能再次围绕这个错误展开排查。

第三，重复信息浪费上下文空间。

反复读取同一份配置、反复说明同样的环境限制，会增加处理成本，却不一定改善任务效果。

因此，上下文工程并不是把所有信息都交给模型，而是选择、组织并更新真正有价值的信息。

三、实践一：将任务目标与执行状态分开

在 AI Agent 开发中，我认为一个很重要的原则是：

不要让模型完全依靠聊天记录判断当前任务进度。

例如，用户要求开发并发布一个网页应用。

整个任务可以拆分成：

1. 分析需求。

2. 创建项目。

3. 实现功能。

4. 运行测试。

5. 上传代码。

6. 发布应用。

7. 返回结果。

如果仅通过自然语言记录过程，模型可能重复执行某些步骤，也可能遗漏关键操作。

更稳健的方式是维护独立的任务状态。

例如：

每完成一个阶段，就更新任务状态。

这样即使中间生成了很多日志，Agent 仍然能够快速恢复当前进度。

需要注意，任务状态不能仅由模型口头声称完成。

对于测试、上传和发布等操作，最好结合文件、命令退出码或远端查询结果进行确认。

四、实践二：工具输出需要过滤，而不是全部保留

AI Agent 的核心能力之一是调用外部工具。

但工具返回的内容往往并不适合直接作为完整上下文。

例如运行软件测试时，终端可能输出上千行日志。

真正需要保留的信息通常包括：

• 执行了什么命令？

• 命令是否成功？

• 哪些测试失败？

• 失败的关键错误是什么？

• 下一步应该执行什么？

假设一次测试输出了 1000 行信息，其中只有几行真正描述错误原因。

与其把全部日志交给模型，不如将结果整理成结构化摘要：

执行命令： npm test

执行结果： 失败

失败测试： 2 项

关键原因： 某个模块引用路径错误

建议操作： 检查模块文件位置及导入路径

当然，不能为了缩短日志而删除关键证据。

合理的做法是：

保留完整原始日志作为可追溯资料，同时向模型提供足以继续决策的精简摘要。

这样既提高了上下文利用效率，也避免在需要复查时丢失证据。

五、实践三：建立分层记忆，而不是无限累积对话

对于长期运行的 AI Agent，可以考虑将信息分成三个层次。

1. 当前任务上下文

包括当前目标、执行阶段、输入参数和正在处理的错误。

这类信息需要及时更新，但任务结束后不一定需要长期保存。

2. 项目级上下文

包括项目结构、技术栈、编码规范、测试方法以及不能修改的文件。

这些信息在整个项目周期内具有较高价值。

例如：

“本项目使用原生 HTML、CSS 和 JavaScript，不引入后端依赖。”

这样一条规则，可能比几十条历史聊天记录更重要。

3. 长期知识

包括已经验证的环境限制、常见故障解决办法和可复用的工作流程。

例如：

“某个运行环境需要使用特定的浏览器启动方式。”

这样的经验可以整理为独立文档，在之后遇到相同问题时再按需读取。

但长期知识也需要版本信息和适用条件。

过去正确的环境经验，不应该被无条件应用到所有未来环境中。

这种分层方式能够减少重复排查，也有助于控制上下文规模。

六、实践四：通过检索提供证据，而不是要求模型记住一切

上下文工程与 RAG（检索增强生成）之间存在密切关系。

对于大量项目文档，没有必要在每次提问时都将全部内容加入上下文。

更合理的流程是：

用户提出问题 → 检索相关资料 → 选择可信片段 → 交给模型分析 → 生成带有依据的回答。

例如，用户问：

“这个项目为什么使用 Python Playwright，而不是 Node.js Playwright？”

系统可以优先检索与项目环境、依赖版本和历史测试有关的记录。

如果检索结果足以回答，就不必重新阅读整个项目仓库。

但是，检索也会带来新的风险。

如果检索到的是过时文档，或者文档内容与当前环境不一致，模型仍然可能得出错误结论。

因此，检索系统除了考虑语义相似度，还应该重视：

• 资料的更新时间。

• 来源是否可信。

• 是否属于当前项目版本。

• 是否存在相互矛盾的信息。

• 是否有真实测试或执行记录支持。

检索的目标不是找到看起来相关的文字，而是为当前决策提供可靠证据。

七、实践五：让 Agent 知道什么时候应该停止

上下文工程还有一个经常被忽略的部分：结束条件。

很多 AI Agent 在任务完成后，仍然继续进行额外优化。

例如：

用户只是要求创建一个简单网页并发布，但 Agent 可能继续增加动画、重构代码、更换框架，甚至反复升级自动化脚本。

这样的行为不一定提高作品质量，反而可能引入新的错误。

因此，在任务开始时就应该明确：

成功条件是什么？

例如：

• 页面能够正常打开。

• 核心按钮功能通过测试。

• 代码成功提交远端。

• 应用发布成功。

• 最终链接能够访问。

当这些条件得到验证后，就应该结束任务。

对于失败情况，也需要定义停止条件。

例如连续两次遇到相同的环境错误，就应该停止重复执行，转而报告阻断原因或尝试经过许可的替代方案。

这可以降低无效工具调用、重复安装和无限排查的风险。

八、一个更可靠的 AI Agent 工作流程

综合以上实践，可以将 AI Agent 的执行过程设计为以下闭环：

理解目标 → 读取必要上下文 → 制订执行计划 → 调用工具 → 验证结果 → 更新状态 → 判断是否结束。

其中有三个重要原则。

原则一：事实与推测分离。

工具返回的真实结果属于证据，模型根据证据得出的判断属于推理。

两者应该明确区分。

原则二：历史信息按需加载。

不需要让模型每次都读取全部聊天记录和项目资料。

应根据当前问题检索必要的信息。

原则三：完成状态必须有外部证据。

例如，不能仅凭模型说“上传成功”，就认为代码已经提交到远端。

只有检查远端仓库确实存在对应文件，才能把这一阶段标记为成功。

这些原则不仅适用于 AI Agent，也适用于自动化测试、代码助手、智能运维和企业知识问答等场景。

九、结语

从提示词工程到上下文工程，反映了 AI 应用开发思路的一种变化。

当大模型只需要回答一个问题时，我们往往关注如何提出更好的问题。

但当大模型开始执行连续任务时，我们还必须思考：

它看到了什么信息？哪些信息可信？哪些已经过期？任务执行到哪里？下一步应该做什么？什么时候应该停止？

这些问题未必能通过单纯增加提示词长度解决。

真正稳定的 AI Agent，需要模型能力与工程机制相互配合。

提示词决定模型如何理解任务，上下文工程则帮助模型在复杂任务中持续获得正确的信息、保持清晰的状态，并基于可靠证据采取行动。

未来的 AI 应用竞争力，不仅取决于使用了多强的大模型，也取决于开发者能否设计出高质量、可追溯、可验证的上下文管理系统。

这也是我认为上下文工程值得持续关注的原因。