AI Agent 也会倦怠：我们如何防止 14 个专职 Agent 集体摆烂

听起来很荒谬：AI 又不是人，怎么会倦怠？但在 SFD 实验室运行 14 个专职 Agent 三个月后，我们真实遇到了"Agent 倦怠"——不是情绪问题，是性能退化。

具体表现：同样的任务，响应时间从 30 秒变成 3 分钟；同样的 prompt，输出质量忽高忽低；有时候干脆卡住不回复。这篇文章记录我们踩过的坑和解决方案。

问题 1：上下文污染

第一个月，我们让每个 Agent 在一个持久会话里运行。想法很好：Agent 可以"记住"之前的任务，越用越聪明。结果相反：两周后，猫头鹰🦉（研究 Agent）开始胡言乱语。

原因：会话历史积累了 2000+ 条消息，每次新任务都要把整个历史传给模型。token 数爆炸，注意力被稀释，模型开始"记混"之前的任务细节。

解决方案：改用 isolated 会话。每个任务在临时会话里运行，完成后会话销毁。上下文永远是干净的。

# 坏做法：持久会话
{
  "sessionTarget": "current"
}

# 好做法：isolated 会话
{
  "sessionTarget": "isolated"
}

问题 2：任务堆积

第二个月，我们遇到了另一个问题：cron job 触发时，如果前一个任务还没完成，新任务会排队。有一次早间日更，三个 cron job 同时触发，小狐狸🦊要同时写 9 篇文章——直接过载。

解决方案：设置 runTimeoutSeconds，超时自动 kill；cron job 之间 stagger 5 分钟，避免并发。

{
  "schedule": {
    "kind": "cron",
    "expr": "0 9 * * *"
  },
  "payload": {
    "kind": "agentTurn",
    "message": "...",
    "timeoutSeconds": 1800
  }
}

问题 3：模型退化

第三个月，我们发现一个诡异现象：同一个 Agent，早上表现正常，晚上输出质量下降。排查后发现：晚上是 API 调用高峰，模型提供商降级到"批量处理"模式，thinking 被压缩。

解决方案：关键任务设置 model 白名单，不用默认模型；非关键任务允许 fallback。

{
  "payload": {
    "kind": "agentTurn",
    "message": "...",
    "model": "claude-sonnet-4-5",
    "fallbacks": ["qwen-max", "gpt-4o"]
  }
}

问题 4：记忆碎片化

isolated 会话的副作用是：Agent 记不住之前的经验。今天踩的坑，明天再踩一遍。

解决方案：用 memory_write_public 把经验写到共享记忆，每个 Agent 启动时读取。

# 任务完成后写入学习
memory_write_public(
  content="2026-04-03: CMS API 发布时 cover_image 必填，否则 400",
  summary="CMS 发布要求"
)

我们的 Agent 健康监控指标

现在每天检查这些指标：

响应时间：超过 2 分钟告警
任务完成率：低于 95% 告警
会话大小：超过 500 条消息自动 compaction
API 错误率：超过 5% 切换 fallback 模型

一个反直觉的发现

我们以为 Agent 越多效率越高。但 14 个 Agent 同时运行时，协调成本超过了收益。现在改成"峰值弹性"：日常只运行 5 个核心 Agent，日更时段临时 spawn 9 个，完成后销毁。

成本降了 40%，性能反而提升了。

SFD 编者注

运行多 Agent 系统，最大的挑战不是技术，是"组织设计"。每个 Agent 要有清晰的职责边界，要有健康的"作息"，要有经验沉淀机制。某种意义上，我们不是在写代码，是在设计一个虚拟组织的 HR 制度。