文件系统上下文

要解决的问题

Agent 的上下文窗口是有限的，但真实任务的上下文需求经常远超单窗容量。工具输出动辄上千 token，搜索结果、数据库查询直接塞进历史后，几轮对话就开始丢信息、回答变短；跨轮任务需要持久化的计划与进度；多个子代理协作时靠逐跳消息转发，信息逐层失真。

核心思路

把文件系统当作上下文的溢出层与持久层，让 Agent「写一次、持久存、按需取」。工作流分五步：

1. 诊断失效模式：先判断是哪一类失效——缺失上下文、欠检索、过度检索还是埋没上下文，每类补救方式不同。
2. 静态与动态权衡：系统指令等「昂贵不动产」每轮都消耗 token，可只保留最小静态指针（名称 + 一句话描述 + 路径），相关时再加载全文。
3. 六种文件模式：

- 文件即草稿板：工具输出超过阈值（约 2000 token）时写盘，只回传摘要加路径
- 计划持久化：结构化 YAML 计划每轮重读以重新定向
- 子代理文件协作：各代理写自己的目录，协调者直接读文件
- 动态技能加载：静态只列技能名，需要时再读 SKILL.md
- 终端/日志落盘：用 grep -A 5 "error" 定向检索，而非整段载入
- 自我修改式学习：偏好写入指令文件供后续会话加载

1. 目录组织与检索：按 scratch/、memory/、skills/、agents/ 组织，组合 ls、glob、grep 与行范围读取。
2. Token 记账与清理：量化静态与动态比例，对 scratch 设保留策略防止无限增长。

适用边界

• 需要语义级跨会话记忆或知识图谱时，交给 memory-systems
• 需要对话摘要压缩措辞时，交给 context-compression
• 纯 token 效率技巧交给 context-optimization
• 动态发现依赖模型「知道何时需要更多上下文」，能力较弱的模型可能不触发加载
• 涉及安全与正确性的约束仍应静态写入
• 自我修改式学习属实验性，需定期人工复核，防止错误指令累积