> For the complete documentation index, see [llms.txt](https://yeasy.gitbook.io/context_engineering_guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://yeasy.gitbook.io/context_engineering_guide/di-san-bu-fen-jin-jie-ji-shu-yu-jia-gou/10_advanced/10.8_long_horizon_tasks.md).

# 10.8 长时间任务的上下文策略

## 10.8.1 长时间任务的核心挑战

长时间任务（Long-Horizon Tasks）指那些需要数十分钟乃至数小时才能完成的复杂工作，如大规模代码库迁移、综合研究项目分析、全书内容处理等。这类任务面临的核心挑战是：**如何在有限的上下文窗口内保持任务的连贯性、上下文的完整性和行为的目标一致性**。

即使模型具备超大上下文窗口（如 1M Token），长时间任务仍然需要专门的上下文管理技术，因为：

1. **信息污染不可避免**：随着任务推进，中间结果、失败尝试、工具输出等都会在上下文中积累，逐渐淹没关键信息
2. **成本约束**：超大上下文的单次调用成本很高，不能无限扩展
3. **延迟约束**：上下文越大，首 Token 延迟越高，影响用户体验

## 10.8.2 先定义六字段控制契约

长时间任务不应只携带一条目标描述。开始执行前，把意图写成可检查的控制契约（Control Contract）；每次恢复、压缩或委派后，都从契约重建边界。

| 字段             | 必须回答的问题              | 示例                             |
| -------------- | -------------------- | ------------------------------ |
| `Trigger`      | 什么事件允许任务启动或恢复？       | 收到已批准的迁移工单，且目标分支存在             |
| `Goal`         | 可交付结果是什么？            | 迁移三个指定模块，行为保持不变                |
| `Verification` | 哪些证据证明目标达成？          | 单元测试、集成测试和产物校验全部通过             |
| `Stop`         | 哪些完成或失败条件要求停止？       | 验证通过即结束；连续两次出现同一阻塞则暂停          |
| `Memory`       | 哪些状态需要持久保存，下一轮从哪里恢复？ | 保存已完成模块、决策、失败尝试和下一步；不保存 secret |
| `Human Gate`   | 哪些动作必须等待人类确认？        | 推送、发布、删除、生产写入和权限扩大             |

契约要使用机器和人都能核对的值，避免“尽量完善”这类无终点目标。执行循环只能缩小未完成范围，不能静默放宽 `Goal`、绕过 `Verification` 或把 `Human Gate` 变成事后通知。外部状态改变导致契约失效时，记录证据并停止，由人重新批准边界。

## 10.8.3 策略一：压缩（Compaction）

**定义**：在上下文接近限制时，将对话历史压缩为高保真摘要，然后在新的上下文窗口中继续执行。

**核心流程**：

```mermaid
graph LR
    A["执行中的任务"] --> B{"上下文 > 80%?"}
    B --> |"否"| A
    B --> |"是"| C["触发压缩"]
    C --> D["传递完整消息历史给模型"]
    D --> E["模型生成压缩摘要"]
    E --> F["新窗口 = 摘要 + 最近5个文件"]
    F --> G["继续执行"]
```

**压缩策略的设计原则**：

关键是**选择性保留**（Selective Retention）——某些信息必须完整保留，某些可以丢弃：

| 信息类型      | 处理方式    | 理由            |
| --------- | ------- | ------------- |
| **保留**    |         |               |
| 架构决策      | 完整保留    | 影响后续所有实现      |
| 未解决的 Bug  | 完整保留    | 防止重复踩坑        |
| 当前计划      | 摘要保留    | 指导后续步骤        |
| **丢弃**    |         |               |
| 工具执行成功的输出 | 仅保留摘要   | 已完成的步骤不需要全部细节 |
| 冗余的中间结果   | 完全丢弃    | 清理重复和过期信息     |
| 调试日志      | 仅保留关键错误 | 保留教训，丢弃噪声     |

**实现示例**（Claude Code 的做法）：

```
原始消息历史（100K tokens）：
- 消息 1-50：代码编写、测试、迭代细节（冗长）
- 消息 51-100：最终的成功执行

压缩提示词：
"""
请总结以下编程任务的进度。保留：
1. 整体的架构设计决策
2. 任何未解决的 Bug 或技术债
3. 已完成功能的简要清单
4. 当前的下一步计划

请忽略：
1. 详细的日志输出
2. 成功的测试结果（只说"测试通过"）
3. 逐行代码diff（保留最终版本即可）
"""

压缩后的摘要（5K tokens）：
✓ 核心架构：使用异步事件循环 + 消息队列
✗ 待解决：性能优化（当前吞吐量 1000 req/s，目标 5000）
✓ 已完成：数据模型、API 端点、基础认证
→ 下一步：性能测试、负载均衡实现
```

**压缩的艺术**：

最具挑战性的是“**回忆优化**”（Recall Optimization）——在压缩时不遗漏关键信息。建议的方法：

1. **先最大化回忆**：初期的压缩提示词应该尽可能包含细节
2. **后迭代精简**：在多次压缩的测试中，逐步移除冗余内容
3. **针对性微调**：针对你的特定任务，找到最佳的信息保留平衡

## 10.8.4 策略二：结构化笔记（Structured Note-Taking）

**定义**：智能体在执行过程中定期将重要信息写入持久化的外部记忆，然后在上下文重置时重新读取。

**与压缩的区别**：

* **压缩**：被动的、自动的，由系统在上下文满时触发
* **笔记**：主动的、有意识的，由智能体主动记录关键信息

**笔记结构设计**：

一个良好的笔记体系包含多个文件，各自承载不同的信息层级：

```
project/
├── NOTES.md          # 日记式的工作日志
├── PROGRESS.md       # 最新的进度跟踪
├── ARCHITECTURE.md   # 架构和关键决策
├── KNOWN_ISSUES.md   # 已知问题和解决方案
└── NEXT_STEPS.md     # 下一步计划
```

**NOTES.md 示例**（类似开发日志）：

```markdown
# 项目日志


### 上午（推理步骤 1-50）
- 实现了用户认证模块
- 发现数据库连接池有内存泄漏
  * 症状：连续 100 个请求后内存占用翻倍
  * 临时方案：每 50 个请求重启一次连接池
  * 待根本解决

### 下午（推理步骤 51-100）
- 完成 API 路由设计
- 添加了日志记录中间件
- 性能测试：单机 500 RPS（待优化至 5000）

### 关键发现
- 选择 FastAPI 而非 Django 的决定是正确的（更轻量）
- 需要在架构中加入缓存层

### 当前状态
- 代码行数：8500+
- 测试覆盖率：65%（目标 85%）
- 预计完成日期：2026-04-05
```

**Pokemon 游戏案例**（公开长时程任务示例）：

这是一个展示笔记在长时间任务中价值的示例。智能体通过自动化方式玩 Pokemon 游戏数小时，可以用笔记追踪：

```markdown
# Pokemon 训练日志

## 当前目标
将皮卡丘从等级 5 训练至等级 15（目标突破）

## 进度跟踪
- 当前位置：一号路线（第 1234 步）
- 皮卡丘等级：5 → 7（+2）
- 经验值进度：1234/1500（达到目标还需 266 点经验值）
- 上次升级时间：23:45

## 战斗记录（最近 5 场）
- 野生小鸟 (等级 3)：赢，获得 150 XP
- 野生小鸟 (等级 4)：赢，获得 180 XP
- 野生毛毛虫 (等级 3)：赢，获得 140 XP
- 训练师对战（5 只 Pokémon）：赢，获得 500 XP
- 野生小拉达 (等级 5)：赢，获得 200 XP

## 已学技能
- 电击：威力 40，成功率高
- 绷紧：辅助技能，提高防御
- 充电：蓄力技能

## 待办事项
- 学习新技能（闪电）需要 Lv. 13
- 收集 TM28（地震）增加多样性
- 探索新路线寻找更强对手

## 战略决策
避免强敌（等级 8+），专注经验值积累
```

**笔记的自动化管理**：

智能体在每个重要的里程碑（如完成一个大任务、遇到错误、上下文即将满）时自动更新笔记：

```python
def on_major_milestone(state, action_result):
    # 更新笔记文件
    if is_success(action_result):
        append_to_progress_md({
            "timestamp": now(),
            "milestone": action_result.description,
            "state": summarize_current_state(state)
        })
    elif is_error(action_result):
        append_to_known_issues_md({
            "error": action_result.error,
            "attempted_solution": action_result.solution,
            "workaround": generate_workaround(action_result)
        })

    # 当上下文接近满时，也触发更新
    if context_usage() > 0.75:
        update_summary_in_notes(state)
```

## 10.8.5 策略三：多智能体架构（Sub-Agent Architecture）

**定义**：不让单个智能体承载整个长时间任务，而是分解为多个专用的子智能体，每个子智能体有独立的上下文窗口，最后由主智能体综合结果。

**架构对比**：

```mermaid
graph TB
    subgraph "单智能体方案"
        A["单个智能体"] -->|"处理全部细节"| B["上下文爆炸"]
        B --> C["效率下降"]
    end

    subgraph "多智能体方案"
        M["主智能体<br/>高层规划"] --> S1["搜索子智能体<br/>发现相关资源"]
        M --> S2["分析子智能体<br/>深度理解内容"]
        M --> S3["综合子智能体<br/>生成报告"]
        S1 -->|"摘要结果"| M
        S2 -->|"关键发现"| M
        S3 -->|"最终输出"| M
    end
```

**关键优势**：

1. **上下文隔离**：每个子智能体的处理细节不污染主智能体的上下文
2. **并行执行**：多个子智能体可以同时工作，加快总体进度
3. **专业化**：子智能体可以针对特定任务优化提示词和工具

**多智能体研究系统案例**（Anthropic 的例子）：

在一个需要深度调研的任务中，使用以下架构：

```
Lead Agent（主智能体）
├── 角色：研究主导、规划、综合
├── 工作流：
│   1. 分析用户问题
│   2. 分解为子任务，委派给各子智能体
│   3. 接收结果摘要
│   4. 综合生成最终报告
└── 上下文占用：低（只处理摘要）

├─ Search Sub-Agent（搜索子智能体）
│  ├── 角色：网络搜索、信息发现
│  ├── 工作：搜索 20+ 个网站，返回 5 个最相关的
│  ├── 输出：一份 2KB 的摘要
│  └── 上下文占用：自内部消化大量搜索结果
│
├─ Reading Sub-Agent（阅读子智能体）
│  ├── 角色：深度阅读、信息提取
│  ├── 工作：读取长文档，提取相关段落
│  ├── 输出：3 段精选文本 + 要点
│  └── 上下文占用：自处理长文档分析
│
└─ Synthesis Sub-Agent（综合子智能体）
   ├── 角色：整合信息、撰写报告
   ├── 工作：基于主智能体提供的摘要生成结构化报告
   ├── 输出：最终报告（1-2K 字）
   └── 上下文占用：相对较小
```

**效果对比**（示意性数据）：

| 维度         | 单智能体     | 多智能体                 |
| ---------- | -------- | -------------------- |
| 处理 10 个数据源 | 上下文 150K | 上下文 30K（主） + 各子智能体隔离 |
| 处理时间       | 串行，较长    | 并行，显著缩短              |
| 结果质量       | 可能遗漏细节   | 更全面，专业化处理            |
| 系统复杂度      | 低        | 中等                   |

## 10.8.6 策略选择指南

选择合适的策略取决于任务特性：

```mermaid
graph TB
    A["长时间任务"] --> B{"任务特性分析"}
    B --> |"需要完整对话流<br/>频繁反馈"| C["采用压缩<br/>+ 笔记"]
    B --> |"需要独立子任务<br/>并行处理"| D["采用多智能体<br/>架构"]
    B --> |"混合特性"| E["综合使用<br/>所有策略"]

    F["大规模代码迁移"] --> |"适合"| C
    G["综合研究项目"] --> |"适合"| D
    H["AI 编程助手"] --> |"适合"| E
```

**具体建议**：

1. **代码开发任务**（如 Claude Code）：
   * 优先使用：压缩 + 笔记（保留架构决策和 Bug 记录）
   * 辅助使用：多智能体（代码审查、测试子智能体）
2. **研究和分析任务**：
   * 优先使用：多智能体（搜索、分析、综合的分工）
   * 辅助使用：压缩（处理超长子任务）
3. **复杂交互任务**（如客服、个人助手）：
   * 优先使用：笔记（用户历史、偏好、当前状态）
   * 辅助使用：压缩（超长对话历史）
4. **混合场景**（现实大多数生产任务）：
   * 综合使用所有三个策略
   * 根据实际运行情况微调配置

## 10.8.7 最佳实践

1. **早期规划**：在任务开始前预设压缩、笔记和多智能体的策略
2. **监控指标**：跟踪上下文使用率、压缩频率、任务完成时间
3. **迭代改进**：根据实际运行数据调整策略参数
4. **测试验证**：在 pre-production 环境测试长时间任务的稳定性
5. **用户反馈**：收集真实任务中的反馈，优化笔记结构和压缩策略

## 10.8.8 策略四：跨会话持久记忆

前面三种策略（压缩、笔记、多智能体）解决的是 **单次长任务内** 的上下文管理。但在真实产品场景中，还有一种更长时间尺度的挑战：**跨会话的状态延续**。

用户今天的对话结束后，明天再回来时，系统需要“记住”之前的上下文——不只是对话记录，而是用户的偏好、项目状态、已做的决策和待解决的问题。

### 跨会话记忆的独特挑战

跨会话记忆比单次任务内的上下文管理更难，因为：

1. **时间跨度不确定**：两次会话之间可能间隔几分钟，也可能间隔几周。间隔期间，用户的状态可能已经变化
2. **外部状态漂移**：用户可能在其他工具中做了变更（更新了代码、修改了文档、回复了邮件），这些变更不在对话历史中
3. **事实冲突积累**：随着会话次数增加，历史记录中的矛盾信息会逐渐增多

### 从对话存储到状态维护

新一代记忆框架（如 Supermemory）的核心思路是：不把整段对话塞进存储，而是将记忆重新定义为 **持续状态维护**。具体做法包括：

* **事实抽取**：从每次对话中自动提取结构化事实，而非存储原始文本
* **画像分层**：将用户状态拆分为“静态画像”（长期稳定的偏好和背景）和“动态画像”（近期上下文和临时状态），分别管理
* **冲突消解**：当新事实与旧事实矛盾时，自动执行覆盖，而非让两者共存
* **多源同步**：通过连接器实时同步外部系统（文档、代码仓库、邮件），补充对话之外的状态变化

### 与压缩和笔记的关系

跨会话记忆与前述策略是 **不同时间尺度上的互补**：

| 策略           | 时间尺度       | 核心问题      |
| ------------ | ---------- | --------- |
| 压缩（10.8.3）   | 单次对话内（分钟级） | 上下文窗口溢出   |
| 笔记（10.8.4）   | 单次任务内（小时级） | 任务进度延续    |
| 多智能体（10.8.5） | 单次任务内（并行）  | 信息量超载     |
| **跨会话记忆**    | 跨任务（天/周级）  | 用户状态延续与演化 |

在实践中，这四种策略往往需要组合使用：单次会话内用压缩和笔记保持连贯，会话间用持久记忆维护状态，复杂任务用多智能体分解负载。

## 来源标注

本节内容融合了 Anthropic 在 Claude Code 和多智能体研究系统中的实践经验，参考资料：

* "Effective context engineering for AI agents" (Anthropic, 2025-09-29)
* Claude Code 中的压缩和笔记机制
* "How we built our multi-agent research system" (Anthropic)