核心 GUIDE
PRACTICEINTERMEDIATE7 分钟阅读
Context Management
Context Management 会随着任务变化不断决定哪些内容需要加载、刷新、压缩或移除。
核心心智模型
好的 Context 是根据当前决策从 State 与 Evidence 中 Just-in-time 组装出来的，而不是一份永远增长的 Conversation Transcript。
为什么重要
长期任务一直在变化：事实会过期、目标会被重新定义、Tool 会产生新状态，而中间推理的价值会下降。没有明确 Context Lifecycle，Prompt 最终就会变成当前证据与历史残留物的混合物。
01
建立 Context Lifecycle
在每一个有意义的步骤之前，应用先明确下一步要做的 Decision，再加载最小必要 State 与 Evidence，保留 Durable Constraint，并压缩或删除 Transient Material。Retrieval 与 Memory 是这个 Lifecycle 的输入机制，而不是两个互相独立的魔法功能。
02
例子：Repository Editing Agent
与其每次重新发送整个 Repository 与全部 Chat History，Editing Agent 只加载当前 Task Spec、准备修改的文件、相关 Test 与最新 Tool Result。修改完成并验证后，它持久化关键 Decision，再丢弃原始 Command Output。
常见失败模式
- 把 Conversation History 等同于 Application State。
- 即使静态前缀与下一步无关，也反复加载。
- 底层 Source 已经变化，却没有让旧 Context 失效。
工程启发
- 围绕下一次 Decision 构造 Context，而不是围绕整个 Project。
- 明确分离 Durable State、Retrievable Knowledge 与 Transient Observation。
- 记录每个项目为什么被保留，让 Compression Policy 可审计。
关键结论
- 01Context Management 是持续 Lifecycle，而不是一次 Prompt Optimization。
- 02重要 State 需要在 Prompt 之外存活。
- 03Retrieval、Memory 与 Summarization 都是更大 Selection Policy 里的机制。
来自 Knowledge Graph 的相关知识点
这些关系直接来自 canonical graph，不维护第二套 Guide 分类体系。
Retrieval PipelinePREREQUISITEGuide →有限 Context 预算PREREQUISITEGuide →
Context 结构与 Cache 友好稳定性PREREQUISITE
压缩与关键信息保留的权衡PREREQUISITE