5个AI代理无人值守30天：什么崩了，什么扛住了

当我对运营人员说"AI助手可以7×24小时自动运行"时，这是承诺。现实更狼狈——代理崩溃、会话死亡、上下文窗口塞满、模型提供商限流，你的"自动化"变成凌晨3点的告警。

上个月我给自己设了个限制：作为独立创始人，让5个小代理无人值守运行30天。不 babysit，不手动重启。一个处理收件箱分类。一个监控几个竞品定价页面。一个做夜间浏览器状态检查。一个跑代码重构批处理任务。一个做内容抓取。

以下是实际崩掉的部分、扛住的部分，以及我在让非技术运营人员接触代理之前会部署的可靠性模式。

我遇到的四种故障模式（按频率排序）

1. 上下文窗口膨胀 → 静默降级。这是最隐蔽的。代理没有崩溃——只是变得越来越蠢。第4天，收件箱代理开始把明显的垃圾邮件分错类，因为对话历史顶到了上限，最近的邮件把路由规则挤掉了。没有异常，没有告警。就是活儿变烂了。

2. 模型提供商限流。第11天。我不知道存在的速率限制在批处理中途触发。代理抛出429，没有重试路径，静默停止处理队列。6小时后我才发现，因为积压任务冒出来了。

3. 认证令牌过期。抓取代理第19天挂掉，因为会话cookie过期了。标准问题，完全可预测，完全没考虑到。

4. 长期运行浏览器会话的内存泄漏。Headless Chrome不喜欢30天不间断运行。第23天，OOM。监控代理把整个虚拟机一起带走。

本可以预防所有问题的五种可靠性模式

这些并不新鲜——它们和你用于任何无人值守工作负载的模式相同。新的是把它们应用到LLM驱动的工作流。

模式1：固定间隔的上下文轮换。别让对话历史无限增长。快照你在乎的状态（决策、规则、持久记忆），扔掉其余的，开启新上下文。对于收件箱代理，每200条消息=新上下文，顶部固定路由规则摘要。简单，永久解决静默降级问题。

模式2：带提供商故障转移的指数退避。主模型限流时，回落到备用。OpenRouter让这变得 trivial——你配置一个回退链然后忘掉它。对大多数任务，Claude → Haiku → GPT-4o-mini 够用。主模型429时用户根本注意不到。

模式3：运营人员真正能看懂的健康检查。不是Prometheus，不是Grafana。一个状态页写着"收件箱代理：上次动作8分钟前"或"定价监控：凌晨2:14失败，重试3次，2:20告警"。运营人员早上扫一眼就该知道要做什么。如果他们得解读图表，你已经输了。

模式4：把令牌刷新当作一等公民。认证令牌有过期时间。把它们烘焙进代理的生命周期。第19天的崩溃本可以是一条"检测到401，刷新令牌，继续"的日志，而不是6小时的静默故障。

模式5：进程隔离。浏览器代理应该在独立容器中，带重启策略。第23天的OOM本可以是30秒的中断，而不是手动VM恢复。把有状态代理和无状态工具分开。如果抓取器泄漏内存，别让监控器陪葬。

什么扛住了（以及为什么）

代码重构批处理任务。它最无聊，也最可靠。输入：代码库。输出：PR。无状态，幂等，可重试。第7天它因为临时GitHub限流失败，但指数退避在12分钟后解决了。没有人工干预。

定价监控在修复浏览器隔离后，第23天之后也稳定了。关键洞察：把"打开浏览器"和"解析价格"分开。前者泄漏，后者不泄漏。隔离它们。

我会先部署什么

如果重来，按这个顺序：

第0天：进程隔离。每个代理独立容器，带内存限制和自动重启。防止级联故障。

第1天：上下文轮换。200条消息或4小时，以先到为准。防止静默降级。

第2天：人类可读的健康检查。一个HTML页面，非技术联合创始人早上能看懂的。

第3天：提供商故障转移。OpenRouter配置，或者至少带退避的重试逻辑。

第7天：令牌刷新自动化。不是"修复"，是基础设施。

非技术运营人员就绪的检查清单

在让其他人碰这个之前，我需要看到：

• 过去7天零未解释停机（计划维护不算）

• 状态页被非技术人员验证过（他们能找到上次故障时间，无需解释）

• 文档写着"如果X发生，做Y"——不是代码注释，是运行手册

• 故障转移测试过：手动限流主模型，验证备用接管

• 恢复时间目标明确：代理崩溃后，多久能自动恢复？不是"很快"，是"4分钟内"

最后的想法

30天后，5个代理中有4个在生产中稳定运行。抓取代理被重写了——不是修复，是重新架构为无状态设计。原始版本需要30天会话，新版本每任务启动新浏览器。

最大的教训：LLM代理不是魔法。它们是带有非确定性步骤的软件系统。同样的纪律适用——监控、隔离、优雅降级。只是失败模式更安静，所以你需要更响亮的告警。

承诺"7×24小时运行"是可能的。但不是在第0天。是在你把分布式系统的经验教训应用到对话式工作流之后。