导语：当 Agent 从演示走向生产，决定效果上限的往往不再是那句“精心打磨的提示词”，而是模型在每一步究竟看到了什么。上下文工程（Context Engineering）正在成为比提示词技巧更值得投入的工程能力。

从“写好提示词”到“管好输入”

过去两年，提示词工程（Prompt Engineering）是使用大模型的核心技能：如何措辞、如何给例子、如何设定角色。但随着 Agent 类应用的普及，这套方法的边际收益在下降。

原因很直接：Agent 不是一次性问答，而是多轮、多工具、多状态的循环。在每一轮里，模型接收到的输入包括系统指令、历史对话、工具返回结果、检索到的文档片段、中间推理记录等。这些内容共同构成“上下文”，而提示词只是其中很小的一部分。

于是问题从“这句话怎么写”变成了“这一步该让模型看到什么、不该看到什么”。这正是上下文工程要解决的问题。

上下文工程到底在管什么

可以把 Agent 的上下文管理拆成几个可操作的维度：

• 选择（Select）：从海量可用信息中，挑出与当前子任务真正相关的部分。检索增强、工具结果过滤、状态摘要都属于这一类。
• 组织（Structure）：把选中的信息按模型易理解的方式排列，例如把稳定指令放前面、把易变的工具输出放后面，减少相互干扰。
• 压缩（Compress）：长对话和多轮工具调用会迅速撑爆上下文窗口，需要通过摘要、裁剪、结构化提取来控制体积。
• 隔离（Isolate）：不同子任务使用不同的上下文，避免无关信息污染当前决策。
• 更新（Update）：随着任务推进，及时替换过期状态，防止模型基于陈旧信息行动。

这五个动作共同决定了 Agent 的“视野质量”。提示词写得再漂亮，如果上下文里塞满了无关的工具返回和过期的中间结论，模型依然会跑偏。

为什么它比提示词更难，也更值钱

提示词工程的反馈回路很短：改一句话，看输出变化。上下文工程的反馈回路则长得多，它涉及系统架构、数据流和状态管理。

具体难点体现在三方面：

1. 上下文是动态的。同一套提示词，在不同轮次面对不同工具输出时，效果可能完全不同。问题往往不在措辞，而在输入内容本身。
2. 窗口是有限资源。上下文越长，噪声越多，关键信息越容易被稀释。如何取舍是工程问题，不是文案问题。
3. 错误会累积。一次错误的工具结果如果被保留在上下文里，后续多轮都可能被反复引用，形成连锁偏差。

也正因如此，上下文工程的投入回报更持久：它沉淀为系统能力，而不是某条提示词的偶然有效。

落地时的几个实践方向

结合 Agent 的常见架构，可以从以下方向着手：

• 把上下文当作数据管道来设计：明确每个环节写入什么、读取什么、何时清理，而不是把所有东西一股脑拼进 prompt。
• 为工具输出做结构化与截断：工具返回往往是上下文膨胀的主要来源，先提取关键字段再注入，比原样塞入更可控。
• 维护显式的任务状态：用结构化状态记录“已完成什么、待办什么”，替代让模型从长对话里自行回忆。
• 区分稳定指令与易变信息：稳定部分可复用、可缓存，易变部分按需注入，降低相互干扰。
• 建立上下文质量的可观测性：记录每轮实际注入的内容与体积，才能定位“模型变笨”的真实原因。

结论

上下文工程的崛起，本质上是 Agent 工程化的必然结果。写提示词是表达意图，管好输入是保障决策质量。前者决定模型“听懂没有”，后者决定模型“看对没有”。在真实的生产系统里，后者往往才是效果的分水岭。

生成标记：本文由 ITPUB 文章生成平台基于已选素材整理生成。