常驻Agent的真相：大部分时间在睡觉，醒来先看收件箱

Anthropic最近发了一篇工程指南，讲怎么搭常驻Agent。它先纠正一个常见误解：所谓always-on，并不是24小时不停跑。真实情况是睡很久，短跑，保存状态，再睡。用户感觉它一直在，但token只在短暂run里烧。原文由William Hu写，2026年11月13日发布：Building always-on agents。Tekon Burns在推文里把核心压缩成五条，原帖在这里。

每个run四步：事件到达、开始session、agent loop跑任务、把状态写回去。run结束，agent继续睡。听起来像摸鱼，但这是成本可控的前提。

1. 事件收件箱

很多agent只由用户消息触发。常驻agent会被webhook、定时任务、后台job触发。别让每个事件源直接调agent。两个事件同时到会抢跑，崩溃会丢事件。

做法是在webhook和agent之间放一张数据库表。handler快速ack，worker从表里取待办，跑完标记。每个用户同一时间只留一个active worker，避免重复和覆盖。连续消息可以合并成一个run。指南建议按来源唯一标识去重，inbox是source of truth，worker挂了，新worker能重试。有网友问webhook重复投递怎么保证幂等，答案就在这层。

2. 定时器

定时器单独一张表，别混进inbox。分两类：agent给自己设的follow-up，用户设的周期性schedule。scheduler轮询到期项，把事件丢进inbox，再唤醒worker。

有网友分享自己的循环会每54分钟唤醒一次，避开55分钟自动压缩，保持缓存热。这是经验，不是指南强制项。

3. 记忆

只存查不到的东西：用户指令、用户笔记、过去消息、任务进度。醒来加载小索引，不是全部文件。需要细节再拉。定期做dreaming，清理过期事实。

上下文窗口的固定开销每次都在，所以系统提示、工具定义、记忆索引要瘦，开prompt caching。有日本开发者说，常驻的实体关键是上次工作能不能正确交给下次。网友Lozo更直接：agent如果忘记自己停在哪，就只是个有主见的cron job。

4. 权限

常驻agent风险最高，因为无人看守还拿着用户权限。API key别放agent sandbox，用外部proxy注入。Deferred Tool Calls把危险动作暂停等审批，run结束保存session，用户回答作为新事件回来，worker不用阻塞。

网友The SI Maximalist补了安全重试：run在“邮件已发”后崩溃，下次醒来不能重发。Tekon Burns回复用idempotency keys。这类细节不性感，但生产环境绕不过去。

5. 发件箱

后台工作多，用户不需要逐步过程。run结束三种：发消息、不发、deferred请求。outbox是出站消息表，dispatcher控制投递节奏，避免凌晨3点轰炸。

网友老王实验室提醒，outbox发送时还要做相关性检查。排队提醒可能已经过时，用户处理了，或者新消息改了计划。持久投递有用，持久投递过期建议没用。

质疑也值得放上来

Balázs Kerek的评论很尖锐：这不过是function call加cron，没有session continuity，只是用好的上下文处理和工具模拟连续性。

这套架构确实没发明新魔法。它把不可靠的长跑拆成可恢复的短跑。真正拉开生产差距的，是幂等、权限、通知相关性这些不性感的部分。听起来像给cron加了个日记本和钥匙柜，但日记本写不好，钥匙乱放，agent就会在凌晨三点给你发第二封邮件。