和"任务内 context"是两件事——它管的是跨 session、跨任务、跨用户 的偏好、事实、技能。混着用是混乱之源。
建议先读《Context Engineering / 元学科》；如果你是跳读，至少先看本章索引与本页 TL;DR。
课程中段的能力层，用来回答“一个 harness 为什么需要这些补丁”。
和"任务内 context"是 两件事 ——它管的是 跨 session、跨任务、跨用户 的偏好、事实、技能。混着用是混乱之源。
先看失败模式，再看能力补丁；能力不是越多越好，而是要能对症下药。
课程主线：稳定能力抽象 + 官方机制 + 跨框架共性。
三个最容易混的概念。一张表理清：
| Context（任务内） | VFS（任务内） | Long-term Memory（跨 session） | |
|---|---|---|---|
| 生命周期 | 一次任务结束即没 | 一次任务结束即没（除非显式持久化） | 跨多次任务、多次 session 持续存在 |
| 谁能看见 | 当前任务的 agent 全程可见 | 当前任务的 agent 按需 read | 未来任意 session 的 agent 按需召回 |
| 规模典型量级 | 几 k - 几十 k token | 几 KB - 几 MB | 几 MB - 几 GB（年级 scale） |
| 典型内容 | 对话、tool 历史、todos | 临时落盘的搜索结果、生成的草稿 | 用户偏好、永久事实、过往任务的教训 |
| 更新方式 | 每轮自动累积 | LLM 主动 write_file | 事件驱动（任务结束 / 用户给反馈 / 周期性整合） |
"用户偏好（喜欢简短回答）"应该在 long-term memory；"本任务 user 给我的 5 条 PDF 摘要"应该在 VFS；"当前正在分析第 3 条 PDF 的 cost"应该在 context。把这 3 个分清楚，agent 的状态机一下就稳了——这是看似简单但反复被新手混淆的边界。
