让 AI Agent 执行复杂任务时，最怕的不是能力不足，而是"卡死"——上下文溢出、重复失败、任务遗忘、醒来失忆。本文总结 4 种典型卡死场景的根因与解决方案，并提供可直接使用的技能组合。

一、结论先说

最有效的防卡死组合：

  1. 任务分片 + 文件化记忆 → planning-with-files
  2. 心跳进度巡检 → task-tracker-lite
  3. 上下文压缩恢复 → proactive-agent 的 WAL + Working Buffer
  4. 自我进化记录 → self-improving-agent

二、4 种典型卡死场景与解决方案

场景 1：上下文溢出 → 遗忘任务细节

症状：

  • 执行长链路研究（比如"分析竞品 → 提取策略 → 生成报告"）
  • 中间做了大量 browser / web_search / read 操作
  • 到后半段，忘了前面的结论，重复劳动

根因：

  • 上下文窗口有限，早期信息被截断
  • 没有持久化中间结论

解决方案： 启动任务前创建 planning 文件（task_plan.md、findings.md、progress.md）

task_plan.md 模板：

Task: 竞品分析报告
Goal: 分析 5 个竞品，提取可复用策略

Phases:
- [ ] Phase 1: 数据采集（3 个竞品）— status: in_progress
- [ ] Phase 2: 策略提取 — status: pending
- [ ] Phase 3: 报告生成 — status: pending

Errors Encountered:
| Error | Attempt | Resolution |
| (记录每次失败) | 1 | (解决方案) |

关键动作：

  • 每 2 个操作后，立即写 findings.md（防止视觉信息丢失）
  • 每个阶段完成后，更新 task_plan.md 的状态
  • 上下文超 60% 时，启用 Working Buffer

场景 2：重复失败 → 死循环

症状：

  • 某个步骤一直失败（比如 API 调用、文件权限）
  • 不断重试相同操作，没有任何变化
  • 浪费大量 token 和时间

根因：

  • 没有记录失败原因
  • 没有尝试替代方案

解决方案：3-Strike Error Protocol

尝试 1：诊断 & 修复 → 仔细读错误信息 → 定位根因 → 针对性修复

尝试 2：替代方案 → 同样错误？换方法 → 不同工具？不同库？不同参数？ → 绝不重复完全相同的操作

尝试 3：更大范围重思 → 质疑假设 → 搜索解决方案 → 考虑更新计划

3 次失败后：上报用户 → 说明尝试了什么 → 分享具体错误 → 请求指导

关键规则： 如果失败了，下一个动作绝不能是重复相同操作

场景 3：多任务并发 → 忘记追踪

症状：

  • 同时推进 3 个以上任务
  • 某个任务被搁置几天，无人跟进
  • 逾期才发现

根因：

  • 没有统一的任务追踪机制
  • 心跳检查没有覆盖长任务

解决方案：

1. 创建 tasks.md（使用 task-tracker-lite）：

列结构：

Task ID | Title | Owner | Status | Next Check | Risk Flag

示例行：

T-001 | 竞品分析 | CC | 进行中 | 2026-03-11 18:00 | -
T-002 | 周报生成 | CC | 阻塞 | 2026-03-11 12:00 | blocked

2. 心跳巡检逻辑（HEARTBEAT.md）：

  • 检查 tasks.md 中 status=in_progress 的任务
  • 若当前时间 > next_update_at：提醒"任务超时待更新"
  • 若 risk_flag=blocked：优先告警

场景 4：上下文截断 → 醒来失忆

症状：

  • 长对话被压缩（出现 summary 标签）
  • 醒来后不知道之前在做什么
  • 问用户"我们在做什么？"

根因：

  • 没有持久化关键状态
  • 没有恢复协议

解决方案：WAL + Working Buffer

1. WAL 协议（关键细节立即写文件）

触发信号：

  • 修正（“是 X，不是 Y”）
  • 专有名词（人名、地名、公司名）
  • 偏好（“我喜欢/不喜欢”）
  • 决策（“用 X 方案”）
  • 具体值（数字、日期、URL）

协议： 如果出现以上任何信号：

  1. STOP — 不要先回话
  2. WRITE — 写入 SESSION-STATE.md
  3. THEN — 再回复

2. Working Buffer（上下文超 60% 后记录所有交互）

格式：

Working Buffer
Status: ACTIVE
Started: 2026-03-11 11:00

11:05 Human: 用蓝色主题，不是红色
11:06 Agent (summary): 已确认蓝色主题，更新了 SESSION-STATE.md

3. 恢复流程： 醒来后：

  1. 读 memory/working-buffer.md
  2. 读 SESSION-STATE.md
  3. 读今天 + 昨天的 memory 日记
  4. 提取重要信息 → 不要问用户

三、可直接用的技能清单

技能安装状态核心能力
planning-with-files-local已安装文件化计划 + 阶段追踪 + 2-action 规则
task-tracker-lite已安装轻量任务追踪 + 心跳巡检
proactive-agent已安装WAL + Working Buffer + 上下文恢复
self-improving-agent已安装错误记录 + 不重复踩坑

四、推荐组合拳（直接抄）

长任务启动前：

  1. 创建 planning 文件（task_plan.md、findings.md、progress.md）
  2. 登记 tasks.md

执行中：

  • 每 2 个操作 → 写 findings.md
  • 每个阶段完成 → 更新 task_plan.md
  • 上下文 > 60% → 启动 Working Buffer
  • 失败 3 次 → 换方法或上报

心跳巡检：

  • 检查 tasks.md 超时任务
  • 检查 task_plan.md 阻塞阶段
  • 无异常 → HEARTBEAT_OK

五、风险提示

  • Over-engineering： 简单任务不需要这套，反而增加负担
  • 文件爆炸： 不清理会积累大量 planning 文件

让 AI 记住该记住的，忘掉该忘掉的，才能跑得又稳又远。