上下文管理

问题：长会话填满 Context

LLM 的上下文窗口是有限的。一个典型的科研 session 可能涉及：

• 读取多篇论文的摘要
• 生成和审查实验代码
• 分析训练日志和指标
• 写论文的某个章节

这些操作会迅速填满 context。更糟糕的是，如果关键状态只存在于 context 里，session 结束或 context 被截断时，这些信息就永远丢失了。

方案：不依赖 Context 存状态

AutoResearch 的核心策略是把 context 当工作记忆，把磁盘当长期记忆。

graph LR
    A[状态变化] --> B{重要吗？}
    B -->|是| C[写入磁盘]
    B -->|否| D[留在 context]
    C --> E[status.yaml / findings.md / ...]
    D --> F[session 结束后自然消失]

什么写磁盘

• Pipeline Status 变化（阶段切换、训练状态更新）
• 实验结果（指标、配置、结论）
• 过程中的关键发现
• Research Contract
• 任何需要跨 session 使用的信息

什么留在 context

• Agent 之间的即时通信
• 编排器的中间推理过程
• 临时的调试信息
• 一次性的命令输出

预防：Agent 返回一行摘要

这是控制 context 膨胀最有效的手段。

规则

每个 Agent 完成任务后，返回给编排器的是一行摘要，不是完整的工作日志。详细结果写到磁盘对应的文件里。

反面示例 — Agent 返回完整输出：

Coder 完成代码实现。以下是修改的文件列表：
1. models/backbone.py - 添加了 ContrastiveHead 类（120 行）
   - __init__ 方法初始化投影层...
   - forward 方法计算对比损失...
2. train.py - 修改了训练循环（50 行改动）
   - 添加了对比损失计算...
   - 修改了 loss 聚合逻辑...
[...此处省略 200 行...]

正面示例 — Agent 返回一行摘要：

Coder: 已实现 ContrastiveHead 并集成到训练循环。改动 3 个文件，详见 git diff。

第一种方式会消耗大量 context 空间，而这些信息在后续操作中很少被引用。第二种方式只占一行，需要详情时随时可以从磁盘读取。

恢复：新 Session 从磁盘重建

当 context 满了或开始新 session 时，恢复流程是确定性的：

sequenceDiagram
    participant N as 新 Session
    participant D as 磁盘
    participant R as 远程服务器
    
    N->>D: 1. 读 status.yaml
    N->>D: 2. 读 contract.md
    N->>D: 3. 读 HANDOFF.md（如果存在）
    N->>R: 4. 检查远程训练状态（如果 training_status 非空）
    N->>N: 5. 重建完毕，继续工作

恢复时读什么

文件	何时读	包含什么
status.yaml	总是	当前阶段、进度、训练状态
contract.md	总是	研究目标、evidence 要求
HANDOFF.md	如果存在	上个 session 的交接信息
findings.md	按需	过程发现（通常不需要全部读入）
experiments/	按需	已完成实验（需要对比时读入）

不要全部读入

恢复时不要把所有文件都读进 context。只读 status.yaml、contract.md 和 HANDOFF.md。其他文件按需读取。这是保护 context 空间的关键。

HANDOFF.md 的生命周期

用户说 "收工" → 写 HANDOFF.md → session 结束
                                    ↓
新 session 启动 → 读 HANDOFF.md → 恢复完毕 → 删除 HANDOFF.md

HANDOFF.md 是一次性文件。新 session 读取并恢复后，它的使命就完成了。

Writer 的干净上下文

Writer（论文写作 Agent）有一个特殊需求：它需要干净的上下文来写出高质量的论文段落。

问题是，如果 Writer 在一个已经塞满了调试日志、代码 diff 和训练指标的 context 中工作，写出来的文字质量会明显下降 — LLM 的注意力被无关信息分散了。

解决方案：

1. Writer 在独立的 session 中运行，不继承编排器的 context
2. 编排器只传递 Writer 需要的信息：
   • Research Contract（研究目标和 claim）
   • 论文大纲
   • 相关实验结果（精简版）
   • 要写的具体章节的指令
3. Writer 完成后返回一行摘要，论文内容写到 paper/sections/

graph TB
    O[编排器<br/>context 很满] -->|精简信息| W[Writer<br/>干净 context]
    W -->|一行摘要| O
    W -->|论文内容| D[(paper/sections/)]

为什么不所有 Agent 都这样？

因为大多数 Agent 的任务不需要"创意空间"。Coder 写代码、Judge 做评审，这些任务对 context 污染不敏感。但学术写作需要 LLM 有足够的注意力集中在文字表达上。

实践建议

1. 定期检查 context 使用量 — 如果感觉响应变慢或质量下降，可能是 context 快满了
2. 大操作前考虑新 session — 如果接下来要做大量文献阅读或代码审查，先保存状态开新 session
3. 不要手动复制粘贴大量文本 — 让 Agent 读磁盘文件，不要把内容粘到对话里
4. 信任恢复机制 — 新 session 的恢复是可靠的，不用担心丢失进度

下一步

• 监控系统 — 训练监控不需要长 context
• 工作空间隔离 — 多项目如何管理