Rag

上下文管理 [!summary] 这一章真正想回答的问题是：每次调用大模型前，怎样把最有用的信息组织好再交给模型？ 所谓上下文工程，不是单纯研究提示词，而是研究如何把任务目标、规则、状态、记忆、检索结果和工具输出组织成一次高质量输入。 1. 这一章到底在讲什么 上下文工程（Context Engineering）的核心不是“给模型更多信息”，而是“给模型更合适的信息”。它关注的是： 哪些信息应该进入这次调用的上下文 这些信息应该按什么顺序和结构摆放 信息太长时该如何压缩与取舍 这件事之所以重要，是因为在真实 Agent 场景里，仅有 [[智能体基础#大语言模型基础（智能体的大脑）|模型能力]]、记忆系统或 RAG 还不够。系统仍然需要持续、系统地构造恰当上下文，否则模型容易答偏、忘重点，或者浪费大量 token。 [1] 2. 一句最容易记住的话 [!note] 上下文工程不是“喂更多信息”，而是“喂更合适的信息”。 这几个概念最好分开记： Prompt Engineering：关注提示词怎么写 RAG：关注去哪里找外部知识 Context Engineering：关注怎样把目标、规则、历史状态、检索结果、记忆和工具返回整体装配成一次高质量输入 [1] 3. 为什么上下文工程重要 3.1 真实任务不是一次性问答 Agent 往往需要持续交互、调用工具、读文件、做判断。此时模型看到的不只是“用户当前一句话”，还包括： 历史动作 中间结论 系统规则 当前任务状态 外部工具的返回结果 [1] 3.2 上下文窗口不是越大越好 上下文变长，并不意味着模型会自动抓重点。信息过多时，反而可能出现： 重点被埋没 注意力分散 无关噪声干扰推理 所以关键不是“全塞进去”，而是“筛选后再组织”。 [1] 3.3 长程任务必须做状态管理 做代码维护、研究任务、长对话助手时，如果没有中间笔记、结构化状态和压缩机制，模型很容易在长流程中忘掉前面的关键事实。这也是本章引入 NoteTool 和 TerminalTool 的直接原因。 [1] 4. 这章最重要的框架：GSSC Hello-Agents 把上下文构建总结成一个四步流水线： GSSC = Gather -> Select -> Structure -> Compress [2] ...