Agent工程中上下文工程为什么比Prompt更重要？

今天读到 Hello-Agents 第9章「上下文工程」，一个很直观的感受是：这一章比单纯讲 prompt 要更贴近真实的 Agent 工程。

上下文工程与Prompt工程的区别

过去很多人会下意识觉得，模型回答不好，大概率是提示词没写到位。但放到真实的 Agent 系统里一跑就会发现，问题往往不是一句 prompt 能解决的——关键变量其实是每次调用模型前，我们到底让它看到了什么数据。

对于一个 Agent 来说，上下文远远不只是用户当前这条问题。它可能包括系统规则、历史对话、知识库召回的内容、工具调用的结果、当前任务状态、用户偏好、甚至一些临时笔记。如果这些素材不加筛选、不做组织，一股脑全塞给模型，反而容易让模型抓不住重点，甚至输出错误判断。

在有限的token预算内构造高质量输入

所以现在对上下文工程的理解，核心已经不是“把信息尽量塞满”，而是“在有限的 token 预算里，构造出高质量的输入”。

企业客服Agent场景示例

举个例子，在企业客服 Agent 的场景中，上下文里需要包含：用户当前问题、最近几轮有效对话、知识库召回的关键片段、当前业务信息、工具调用结果、是否已经转人工、系统回答规则和边界。这些东西的优先级其实天差地别。比如用户已经转人工了，那这个状态就应该优先于自动回复逻辑；知识库召回的内容太多时，需要做排序、裁剪和压缩；历史对话如果太长而不加筛选，反而会污染当前回答的判断。

这一章让人意识到一个关键点：Agent 工程不只是一套“模型 + 工具 + RAG”的技术堆叠，更重要的是把模型每次做决策前所看到的信息管理好。

核心总结：上下文工程决定模型判断依据

一句话总结：Prompt 工程更像是“怎么说”，而上下文工程更像是“让模型基于什么信息来做判断”。

后续如果继续深入做 Agent 或 RAG 方向的项目，重点关注的一定是上下文构建这块——比如历史对话怎么保留、RAG 结果怎么组织、工具返回结果怎么结构化、状态信息如何参与模型决策。这部分才是 Agent 从 demo 走向真实工程系统时真正关键的环节。