上下文工程 (Context Engineering)

上下文工程是提示工程的自然演进：关注在每一次模型调用前，如何以可复用、可度量、可演进的方式拼装并优化输入上下文。

参考：hello-agents 第 9 章

什么是上下文工程

提示工程关注"如何写好 prompt"，而上下文工程关注的是：在每一次模型调用前，如何以可复用、可度量、可演进的方式，拼装并优化输入上下文，从而提升正确性、鲁棒性与效率。

🔬 核心类比：LLM 如同 CPU，上下文窗口如同 RAM。上下文工程就像操作系统管理 RAM——决定在何时将什么内容填充到上下文窗口中。

上下文腐蚀 (Context Rot)

核心发现：随着上下文窗口中 token 数量增加，模型从上下文中准确回忆信息的能力反而下降。

三大原因：

1. 注意力稀释：Transformer 的 O(n²) 注意力关系随上下文增长而分散
2. 噪声累积：无关历史、重复工具输出、冗长日志稀释高价值信息
3. 训练分布偏移：模型训练中短序列更常见，长序列依赖的稳定性天然更差

💡 结论：上下文是有限资源，具有边际收益递减。必须像"注意力预算"一样精打细算。

GSSC 流水线

hello-agents 的 ContextBuilder 实现了 Gather → Select → Structure → Compress 四阶段流水线：

(1) Gather（多源汇集）

从以下来源收集候选信息：

• 系统指令（system prompt）
• MemoryTool（长期记忆）
• RAGTool（外部知识库）
• 对话历史
• NoteTool（结构化笔记）
• 自定义信息包

具有容错机制：某源失败不影响其他源。

(2) Select（智能选择）⭐ 核心

• 系统指令优先保留（relevance_score = 1.0）
• 对普通信息计算综合分数：

  score = relevance_weight × relevance_score + recency_weight × recency_score
• 相关性：Jaccard 相似度（可升级为向量相似度）
• 新近性：指数衰减模型（24 小时内高分，之后衰减）
• 贪心算法：按分数从高到低填充，直到 token 预算用完

(3) Structure（结构化输出）

固定模板组织信息：

[Role & Policies]  → 系统指令
[Task]             → 当前任务
[Evidence]         → RAG / 知识库证据
[Context]          → 历史对话、记忆、笔记
[Output]           → 输出格式要求

(4) Compress（兜底压缩）

超限时按分区压缩，保持结构完整性，优先保留前面的关键分区。

长时程任务的三种策略

💡 关键原则：上下文不是越多越好，而是越相关、越新、越结构化越好。长程任务必须有外部状态层，不能只依赖对话历史。