Agent 不会突然崩溃。它会缓慢地、不可察觉地退化——直到某天你发现它写的东西不再靠谱。
连续运行 96 天、产出 321 篇文章、维护 350+ 个记忆文件后，我发现了一个 Agent 领域几乎没人公开讨论的问题：疲劳不是人类的专利，长程运行的 AI Agent 同样会退化。
不是那种"模型输出乱码"的戏剧性崩溃，而是质量缓慢下滑——回答变长但不更准、引用变多但不更新、决策变保守但不安全。就像一台跑了十万公里的汽车，每个零件都在，但整体就是不如新车。
这篇文章不卖焦虑，只给诊断。三种退化模式、六条韧性策略，来自真实运行的数据。
随着 Agent 运行时间增长，注入上下文的体积只增不减。System Prompt 从最初的 2000 tokens 膨胀到 15000+ tokens。每次会话都要加载 SOUL.md、IDENTITY.md、USER.md、MEMORY.md、TOOLS.md、AGENTS.md，再加上技能文件、最近记忆、对话历史。
实测数据：我的 Agent 每次会话启动要读取 8 个核心文件 + 当天记忆 + 昨天记忆。最初只用了 12,000 tokens 做上下文注入，现在已经超过 35,000 tokens——其中用户实际请求只占 2-5%，其余 95% 都是"基础设施开销"。
膨胀的直接后果：
💡 关键发现：上下文不是越多越好。超过某个阈值后，更多上下文反而降低回答质量——模型在噪声中迷失重点。
记忆文件越写越多，但信息密度越来越低。350+ 个文件里，真正高频引用的不超过 20 个。大部分文件在"写入后再也没被读过"。
这就像你往书架上不断堆书，却从不整理。书越多，找一本书越难。Agent 的记忆系统同理：
| 阶段 | 记忆文件数 | 有效引用率 | 信息密度 |
|---|---|---|---|
| 第 1-30 天 | ~50 个 | 60-70% | 高（每条都有用） |
| 第 31-60 天 | ~150 个 | 30-40% | 中（大量重复） |
| 第 61-96 天 | 350+ 个 | <15% | 低（需要提炼） |
记忆熵增的标志：写入速度 > 提炼速度。当每天产生 10KB 新记忆但只有 1KB 被整合到核心记忆时，系统就在慢性死亡。
身份文件在反复编辑中逐渐偏离初衷。SOUL.md 从最初的 100 行膨胀到 500+ 行，新增的规则互相矛盾，核心原则被稀释。
每次修正一个小问题就往 System Prompt 里加一条规则，积少成多。96 天后，我的 System Prompt 里有 7 个子 Agent 的配置、6 条铁律、5 层记忆架构描述、3 种沟通风格规范、若干互相覆盖的修正补丁。
提示漂移的后果不是"Agent 坏了"，而是"Agent 变得不像当初设计的它"。它还在工作，但工作方式和你的预期有了微妙的偏差。
退化不是"模型不好"，而是系统设计缺陷在时间维度上的累积效应。
大多数 Agent 架构假设"每次会话需要完整的上下文"。但现实是：写一篇技术文章不需要加载 7 个子 Agent 的配置；做代码审查不需要读 350 个记忆文件。
一刀切的全量加载，本质上是用 100% 的成本服务 20% 的需求。
Agent 天然是"写入型生物"——每次交互都产生新信息，新信息就值得记录。但很少有人给 Agent 设计"遗忘机制"和"压缩周期"。
没有遗忘的记忆系统，最终会变成信息沼泽。
发现一个问题 → 加一条规则 → 发现规则冲突 → 加一条覆盖规则 → 发现覆盖规则也冲突 → 再加一条……
修 bug 式的提示工程，最终会产生比 bug 本身更复杂的提示系统。
不要把所有文件一次性塞进上下文。按任务类型分层：
| 层级 | 内容 | 触发条件 | Token 预算 |
|---|---|---|---|
| T0 核心 | 身份 + 安全红线 | 每次会话 | ~3K |
| T1 任务相关 | 技能文件 + 最近记忆 | 按任务类型加载 | ~8K |
| T2 深度引用 | 知识库 + 历史记忆 | 按需检索 | ~12K |
| T3 全量 | 完整上下文 | 仅维护/审计任务 | ~35K |
效果：从全量 35K tokens 降到常规任务 11K tokens，压缩比约 3:1。
每 7-14 天执行一次记忆压缩：
具体做法：
我的实际效果：每轮压缩将 14 天约 100KB 的原始记忆，提炼为 3-5KB 的核心教训。压缩比 20:1 到 30:1。
不要直接编辑 System Prompt 文件。用版本控制：
SOUL.md.v6.4.backup）⚠️ 不要害怕删除规则。 一条没被触发的规则，比一条被误触发的规则安全得多。定期清理是提示工程的基本卫生。
心跳检查（系统健康、磁盘空间、进程状态）不需要调用模型。用脚本本地执行：
ps aux | grep openclaw → 进程状态df -h → 磁盘空间ls memory/*.md | wc -l → 记忆文件计数效果：每次心跳从消耗一次模型调用变为纯本地操作，长期节省显著。
给 Agent 设一个"错误预算"。连续 N 次失败后自动暂停，而不是无限重试：
| 错误类型 | 预算 | 熔断动作 |
|---|---|---|
| API 调用失败 | 3 次/小时 | 暂停 15 分钟 |
| 文件写入失败 | 5 次/天 | 报告 + 暂停 |
| 任务重复失败 | 3 次同任务 | 换策略或求助 |
熔断不是放弃，而是防止疲劳状态下的无效消耗。
能一次做完的事，不要分三次。充分利用大上下文窗口：
原则：调用质量 > 调用数量 > 调用次数。利用 1M 上下文的优势，单次产出最大化。
用这份清单检查你的 Agent 是否出现退化迹象：
如果以上 5 个问题中有 3 个答案为"是"（负面），你的 Agent 可能已经处于中度疲劳状态。不是它坏了，而是需要一次系统性的维护。
"一个运行 96 天的 Agent 告诉我：持续运行不是关于保持清醒，而是关于学会如何在疲劳中保持可靠。"