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

过去常见的误区

过去很多人会下意识觉得，模型回答不好，大概率是提示词没写到位。但放到真实的 Agent 系统里一跑就会发现，问题往往不是一句 prompt 能解决的。

关键变量其实是每次调用模型前，我们到底让它看到了什么数据。

上下文到底包含什么？

对于一个 Agent 来说，上下文远远不只是用户当前这条问题。它可能包括：

• 系统规则
• 历史对话
• 知识库召回的内容
• 工具调用的结果
• 当前任务状态
• 用户偏好
• 甚至一些临时笔记

如果这些素材不加筛选、不做组织，一股脑全塞给模型，反而容易让模型抓不住重点，甚至输出错误判断。

核心理解转变

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

企业客服案例

在企业客服 Agent 的场景中，上下文里需要包含：

• 用户当前问题
• 最近几轮有效对话
• 知识库召回的关键片段
• 当前业务信息
• 工具调用结果
• 是否已经转人工
• 系统回答规则和边界

这些东西的优先级其实天差地别。

• 用户已经转人工了，这个状态就应该优先于自动回复逻辑。
• 知识库召回的内容太多时，需要做排序、裁剪和压缩。
• 历史对话如果太长而不加筛选，反而会污染当前回答的判断。

关键点

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

一句话总结

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

后续方向

后续如果继续深入做 Agent 或 RAG 方向的项目，重点关注的一定是上下文构建这块——比如：

• 历史对话怎么保留
• RAG 结果怎么组织
• 工具返回结果怎么结构化
• 状态信息如何参与模型决策

这部分才是 Agent 从 demo 走向真实工程系统时真正关键的环节。

《夸克》非常好用的免费AI浏览器

下载APP查看