Agent工程中上下文工程为何比Prompt更重要

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

以往很多人会下意识觉得，模型回答效果不理想，多半是提示词编写得不够到位。然而在真实的 Agent 系统里一跑就会发现，问题往往不是一条 prompt 能解决的——关键变量其实是每次调用模型前，我们究竟让它看到了哪些数据。

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

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

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

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

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

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