上下文工程
梳理 Prompt、记忆和 RAG 的分工，以及收集、筛选、组织和压缩上下文的流程。
上下文工程
上下文工程是在每次模型调用前，收集、筛选、组织和压缩任务所需的信息。它处理的不只是用户输入，还包括规则、历史状态、记忆、检索结果和工具返回。
模型能力决定了系统能处理什么；这一轮实际提供的上下文，则影响模型能依据哪些信息作判断。输入越长，不代表关键事实越容易被利用。
Prompt、Memory、RAG 的分工
| 概念 | 主要负责什么 |
|---|---|
| Prompt Engineering | 描述任务、约束和预期输出 |
| Memory | 保存和更新跨步骤或跨会话的信息 |
| RAG | 检索外部知识，为生成提供材料 |
| Context Engineering | 把指令、记忆、检索和当前状态组织成这一轮输入 |
GSSC 流程
Hello-Agents 用 GSSC 描述上下文构建：Gather → Select → Structure → Compress。
| 阶段 | 做什么 | 要点 |
|---|---|---|
| Gather：收集 | 汇集用户问题、历史、规则、检索和工具结果 | 先形成候选材料集合 |
| Select：筛选 | 按任务相关性、时效性和重要性选择材料 | 保留关键约束，排除无关信息 |
| Structure：组织 | 区分规则、任务、状态、证据和输出要求 | 明确每段信息的作用 |
| Compress：压缩 | 对超出预算的内容摘要、去重、提取关键事实 | 预留指令和输出预算，检查信息是否失真 |
为什么需要结构
同一组要求，明确分工后更容易执行。例如：
任务：分析作者观点
证据：第二段和结尾部分
要求：重点解释观点，不复述原文
长度：300 字
这里没有增加信息，只是分清了任务、证据和约束。在长任务中，还要区分 State（做到哪里） 和 Evidence（判断依据是什么），避免把推测当成已确认状态。
课程中的实现组件
Hello-Agents 第九章用三个组件配合处理长任务：
ContextBuilder：按 GSSC 组织当前输入。NoteTool：持久化任务状态和关键中间结论。TerminalTool：读取文件、操作环境，按需查找材料。
持久化内容不必全部放回上下文。调用前先看任务需要，再取出相关状态和证据。
例子：总结论文的方法创新
用户要求“总结这篇论文的方法创新点”时，可以这样组织：
- 收集摘要、方法、关键实验及已有阅读笔记。
- 筛出方法创新和与 baseline 的差异，去掉无关历史及参考材料。
- 分开列出任务、证据和输出要求，例如“三点、通俗解释”。
- 材料过长时压缩方法描述，保留支撑结论的关键细节和出处。
怎么评估
用同一批任务比较答案正确性、结果稳定性、token 与延迟，以及任务中断后能否依据状态继续。排查时先检查模型这一轮实际看到了什么，是否缺少事实、混入噪声或丢失了已确认约束。