上下文管理

[!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]

4.1 Gather：收集

先把可能有用的信息都找出来，包括：

  • 用户当前问题
  • 历史对话
  • 系统指令
  • 检索结果
  • 自定义信息包
  • 工具执行返回
  • 任务状态

这一阶段强调的是多源汇集和容错性，先把候选材料备齐，不急着判断优先级。 [2]

4.2 Select：筛选

从候选材料里挑出真正重要的。Hello-Agents 采用比较务实的策略，主要看：

  • 相关性
  • 新近性

越贴近当前任务、越新的信息，优先级越高。重点不是“收得多”，而是“选得准”。 [2]

4.3 Structure：组织

把选中的信息按固定结构排好，明确语义边界，例如：

  • 角色
  • 当前任务
  • 状态
  • 证据
  • 输出要求

同样的内容，如果结构清楚，模型理解成本会更低，也更不容易混淆规则与材料。 [2]

结构化和不结构化的区别，不在于“有没有这些信息”，而在于“模型知不知道这些信息分别扮演什么角色”。

假设老师给你一段没有分段的话：

1

“阅读下面材料分析作者观点不要复述原文字数三百字重点分析第二段和结尾部分”

和下面这种：

1
2
3
4

**题目要求**：分析作者观点  
**不要做的事**：不要复述原文  
**重点材料**：第二段和结尾部分  
**字数**：300 字

是不是第二种更容易做对？

不是因为信息变多了，
而是因为信息的角色被标明了。

模型也是一样。

4.4 Compress：压缩

当总长度超出预算时，就要做摘要、去重、提炼和保留关键事实。系统通常还会预留一部分预算给系统指令等高优先级信息，避免它们被其他内容挤掉。 [2]

5. ContextBuilder 在工程上做了什么

这一章不只是讲概念，还把上下文工程落成了实际组件：

  • ContextBuilder：统一的上下文管理接口，负责按 GSSC 流水线构造输入
  • NoteTool：负责结构化笔记和关键中间结论的持久化
  • TerminalTool：负责文件系统操作和即时上下文检索

你可以把它们理解成一套分工明确的组合：

  • ContextBuilder 负责装配
  • NoteTool 负责记住
  • TerminalTool 负责补证据 [1]

6. 一个关键思想：在上下文中思考

这章最值得记住的一句话可以写成：

[!tip] 模型的输出，本质上是对当前可见上下文的反应。

做 LLM 系统时，不要只问“我要怎么提示模型”，而要问“模型现在到底看见了什么”。所谓“在上下文中思考”，就是在每次调用前，先审视模型可见的整体状态，并预判这会诱发什么行为。 [1]

7. 一个最容易理解的例子

假设用户问：

帮我总结这篇论文的方法创新点。

一个差的做法是：把整篇论文、全部历史聊天和无关参考文献一股脑塞进去。

一个好的上下文构建方式会是：

Gather

  • 用户问题
  • 论文摘要
  • 方法章节
  • 实验结果
  • 之前已经总结过的要点

Select

  • 保留“方法创新”
  • 保留“与 baseline 的差异”
  • 去掉作者信息、无关参考文献和无关历史对话

Structure

  • 任务：总结创新点
  • 证据：摘要 + 方法段 + 关键实验
  • 输出要求：分 3 点，用通俗语言

Compress

  • 先把方法章节压缩成若干关键创新
  • 再把压缩结果交给模型组织回答

这就是上下文工程。它不是替代检索，而是在检索之后，把材料变成“可直接驱动回答”的上下文。

8. 它和 Memory / RAG 是什么关系

这三个概念最容易混淆，可以这样记：

  • RAG 解决：去哪里找知识
  • Memory 解决：系统怎样记住重要信息
  • Context Engineering 解决：找到和记住的信息，怎样组织进当前这次模型调用 [1][3]

一句话概括就是：

检索负责找，记忆负责存，上下文工程负责装配。

9. 初学者最容易犯的 4 个错误

  1. 以为信息越多越好
    实际上无关信息越多，模型越容易跑偏。
  2. 把所有内容平铺直叙地拼接
    没有结构边界时，模型很难区分规则、背景、任务和证据。
  3. 忽略历史状态管理
    长任务里如果没有中间摘要和结构化笔记，后面很容易丢上下文。
  4. 只关注 prompt，不关注整体上下文
    很多问题不是提示词写差了，而是该给的信息没给，或者不该给的信息太多。

10. 学完这章后至少要会回答的 3 个问题

  1. 什么是上下文工程？
    在每次模型调用前，以可复用、可度量、可演进的方式构造最合适的上下文。 [1]
  2. 为什么它重要？
    因为真实 Agent 任务依赖多源信息、长程状态和有限上下文预算，不能只靠检索或提示词。 [1]
  3. 核心方法是什么？
    GSSC：先收集，再筛选，再结构化，最后压缩。 [2]

11. 面试/考试可背的精简总结

上下文工程是指在每次调用大模型前，对任务目标、系统规则、历史状态、检索结果和记忆信息进行系统化的收集、筛选、组织和压缩，从而构造最有利于模型输出正确结果的上下文。 在 Hello-Agents 中，这一过程由 ContextBuilder 实现，其核心是 GSSC 流水线：Gather、Select、Structure、Compress。它和 RAG、Memory 不是替代关系，而是协同关系：RAG 负责找知识，Memory 负责保存关键状态，而上下文工程负责把这些信息高质量地装配给模型。 [2]

12. 这章最该记住的关键词

上下文工程、ContextBuilder、GSSC、相关性、新近性、结构化上下文、压缩、NoteTool、TerminalTool、长程任务管理

第九章最终复习版

一、10 句最重要的话

  1. 上下文工程研究的不是“提示词怎么写”，而是“每次模型调用前，怎样构造最合适的上下文”。
  2. 这里的“上下文”，指的是模型在一次采样时能看到的那组 tokens。
  3. 它的目标是让输入上下文变得可复用、可度量、可演进，从而提升正确性、鲁棒性和效率。
  4. 上下文工程之所以重要，是因为仅有记忆和检索还不够，真实 Agent 还需要持续、系统地构造“当前最合适”的上下文。
  5. 长上下文不是越长越好；上下文越长，token 成本越高，模型也越容易抓不住重点，这正是长任务和上下文管理的核心矛盾。
  6. Hello-Agents 用统一组件 ContextBuilder 来实现上下文构造，它的核心流程叫 GSSC：Gather、Select、Structure、Compress。
  7. Gather 是把候选信息收上来，Select 是挑当前最重要的，Structure 是把信息角色分清，Compress 是在放不下时做高保真压缩。
  8. 结构化之所以重要，不是因为“排版更好看”，而是因为它让模型知道：哪些是规则，哪些是任务，哪些是状态，哪些是证据。
  9. 在多轮 Agent 里，State 和 Evidence 必须分开：前者回答“现在进行到哪了”，后者回答“凭什么这样判断”。
  10. 第九章不只是讲概念，还在框架里加入了 ContextBuilder、NoteTool、TerminalTool，它们共同组成上下文工程方案，用来支撑长时程任务管理和智能体式搜索。

二、5 个最容易考/最容易问的点

1. 什么是上下文工程？

标准说法：

上下文工程是指在每次模型调用前，对任务目标、规则、状态、检索结果、工具结果等信息进行系统化收集、筛选、组织和压缩，从而构造最有利于模型完成当前任务的上下文。

2. 它和提示工程有什么区别？

  • 提示工程更关注“提示词怎么写”。
  • 上下文工程更关注“模型这一轮到底看见了什么，以及这些信息是怎么被组织起来的”。

3. GSSC 是什么？

  • Gather：收集候选信息
  • Select：筛选当前最相关的信息
  • Structure：把不同角色的信息分块摆好
  • Compress：太长时做摘要、去重、提炼

4. 为什么要结构化？

因为“同样的信息”在结构化和不结构化时，对模型来说不是一回事。结构化会显式告诉模型：

  • 这是规则
  • 这是任务
  • 这是状态
  • 这是证据
  • 这是输出要求

它减少的是角色歧义和优先级混乱，这个思想也和章节里的固定骨架设计保持一致。

5. 怎么判断一个上下文工程做得好不好？

看 4 件事：

  • 更准了吗
  • 更稳了吗
  • 更省了吗
  • 更能续了吗

这对应的正是章节里强调的正确性、鲁棒性、效率，以及长时程任务管理目标。

三、1 个可以直接背的答题模板

第九章讲的是上下文工程，也就是在每次调用大模型前，以可复用、可度量、可演进的方式构造最合适的上下文。它不是只研究提示词，而是研究任务目标、规则、历史状态、检索结果、工具输出等信息如何被收集、筛选、结构化和压缩。Hello-Agents 中通过 ContextBuilder 实现了 GSSC 流水线，并配合 NoteTool 和 TerminalTool 支持长时程任务管理和智能体式搜索。

四、再压成一句话

[!tip] 上下文工程不是给模型更多信息，而是给模型当前最该看到的信息。 这也是第九章最核心的主线。

参考