今天看了 Hello-Agents 第9章「上下文工程」，感觉这一章比单纯讲 prompt 更贴近真实 Agent 工程。
以前我会觉得，模型回答不好，可能是提示词没写好。但放到真实 Agent 系统里看，问题往往不是一句 prompt 能解决的，而是每次调用模型前，我们到底给它看了什么。
对一个 Agent 来说，上下文不只是用户当前问题，还可能包括系统规则、历史对话、知识库召回内容、工具调用结果、任务状态、用户偏好、临时笔记等。如果这些内容没有经过筛选和组织，全部塞给模型，反而可能让模型抓不到重点，甚至产生错误判断。
所以我现在理解的上下文工程，核心不是“把信息尽量塞满”，而是“在有限 token 预算里，构造高质量输入”。
比如在企业客服 Agent 场景里，上下文里可能需要包含：用户当前问题、最近几轮有效对话、知识库召回的关键片段、当前业务信息、工具调用结果、是否已经转人工、系统回答规则和边界。
这些信息的优先级其实不一样。比如用户已经转人工了，那这个状态就应该优先于自动回复；知识库召回内容太多时，也需要排序、裁剪和压缩；历史对话太长时，也不能无脑保留，否则会污染当前回答。
这章让我意识到，Agent 工程不只是“模型 + 工具 + RAG”，更重要的是把模型每次决策前看到的信息管理好。
一句话总结：Prompt 工程更像是“怎么说”，上下文工程更像是“让模型基于什么信息来判断”。
后续如果继续做 Agent/RAG 项目，我会更关注上下文构建这块，比如历史对话怎么保留、RAG 结果怎么组织、工具结果怎么结构化、状态信息怎么参与模型决策。感觉这部分才是 Agent 从 demo 走向真实工程系统时很关键的一环。
（顺便吐槽一下今天在公司上班好无聊捏）
