24小时在线的AI助理，大部分时间在睡觉

Anthropic 在 2026 年 11 月 13 日发了《Building always-on agents》，作者 William Hu。文章拆的是常驻 Agent 的底层结构：事件收件箱、定时器、记忆、权限、发件箱。读下来最反常识的一点，常驻 Agent 并不一直醒着。它大部分时间在睡觉，只有事件进来才跑一次，不调用模型，也不烧 token。

宝玉的推文配了两段演示视频：

原文给了一张时间线：长时间沉睡，中间插入短暂 run。一个 run 收到事件，执行任务，把发生了什么写回状态，然后继续睡。run 跑在 session 里，session 是消息和工具调用的记录。

为什么现在能跑起来

文章提到两个变化。模型判断力更好，能理解用户意图，知道什么时候该来确认。智能更便宜，长程任务降幅更大。一个长程编码基准上，Opus 5.5 每解出一道题的成本比 Opus 5 低 78%，普通任务低 40%。常驻 Agent 正好吃长任务成本下降。

五件套

事件收件箱

大多数 Agent 只在用户发消息时运行。常驻 Agent 可以被 webhook、定时任务、后台作业触发。一种直接做法是每个事件源直接调用 Agent，问题也明显：两个事件同时到，可能起两段互相打架的 run；进程崩了，事件可能丢。

收件箱把这件事拆开。事件源不直接调 Agent，先把事件写进收件箱。收件箱通常是一张数据库表，handler 一般是 HTTP endpoint，worker 是后台服务。收件箱记录状态，按来源唯一标识去重。原文建议一开始一个用户一个收件箱。

几个关键约束：handler 要快速确认事件，深度检查放到 run 里做；收件箱是事实来源，worker 被叫醒后先拉最新事件；一个收件箱同一时间只留一个 active worker，避免两段 run 重复干活或互相覆盖。跑到一半来了新事件，原文给了三种处理：留到下一轮，并进当前这轮，打断重跑。用户连发几条消息，worker 可以合并成一次 run，只回一次。

定时器

定时器让常驻 Agent 有主动能力。它分两类：follow-up 和 schedule。follow-up 是 Agent 给自己设的截止时间，比如过一会检查回复。schedule 是固定节奏的重复任务，比如每日简报。定时器放在独立持久存储里，和收件箱分开。收件箱只放已经准备好处理的事件。

定时器自己不拉起任务。调度器按固定间隔扫描到期项，更新 follow-up 或 schedule 的状态，然后把事件写进收件箱，再叫醒 worker。

记忆

常驻 Agent 跨很多次 run 工作，靠记忆保持连续。记忆也放在独立存储里。Claude Code 的 auto memory 和 Messages API 的 memory tool 用目录文件实现。对常驻 Agent 来说，目录要映射到持久存储，通常是数据库或对象存储，这样记忆能活过 worker。

原则是只存 Agent 之后查不到的东西。能查到的留指针。要存的东西包括：用户指令，单独文件，每次 run 开始加载；用户笔记，记角色、偏好、纠正；过去说过的话，避免重复；任务进度，每次新 run 读进度文件接着做。

每次 run 开始都要加载 system prompt、工具定义、记忆文件。这部分是固定开销，要精简，用 prompt caching 降成本。session 太长可以压缩旧消息或开新 session，两种都会丢细节，需要留下的信息要在过程中写进记忆。原文还提到 dreaming，用历史 session 整理记忆，替换过期条目，找跨 run 才出现的模式。

权限

权限是常驻 Agent 风险最高的地方。run 拿着用户访问权，还无人值守。每个工具调用都要决定：自己继续，拦住，还是等批准。

凭证存储用代理模式。Agent 环境外放一个代理，请求出去时由代理注入真实凭证。Auto mode 用分类器审查高风险动作，拦危险操作，让 Agent 找更安全的路径。最重要的决策仍要用户 review。Deferred tool call 可以让 run 停下来，保存 session，把请求展示给用户，用户答复作为新事件进收件箱，再启动新 run 恢复 session。等待期间 worker 可以处理别的事件。

发件箱

大多数 Agent 边生成边推流，用户能看完整过程。常驻 Agent 在后台干活，用户拿结果和少量细节。run 结束有三种情况：发消息到发件箱，什么都不发，或者用 deferred 请求权限和补充信息。

发件箱是出站消息表，和收件箱对应。dispatcher 是后台服务，读待发消息，决定投递。原文建议调消息量，太多变吵，太少漏事。先安静，再慢慢赚用户注意力。评论区有人提到，五件套里最容易被低估的是发件箱。做对十件事攒的信任，一次半夜乱开口就能败光。

拼起来

一个 run 由收件箱事件启动，可能是用户消息、webhook、定时器。worker 拉起 run，新建 session 或恢复旧 session。Agent 读记忆，在权限内行动，更新记忆，结束把消息推进发件箱。dispatcher 投递。用户回复又变成收件箱事件。run 可以设定时器，之后叫醒自己。每个 run 很短，循环可以一直转。

几个落地判断

常驻 Agent 的工程难点从模型能不能做，转到什么时候做、做多少、什么时候开口。成本取决于醒来频次和每次携带的上下文。权限和发件箱要一起看：权限决定能做什么，发件箱决定何时打扰。两边口径不一致，会出现该干没干，或者不该说时说了。

评论区还有一条实操建议：加静默时段，同一事件去重只通知一次，把每次唤醒的决策理由写进 memory，事后能查为什么打扰了用户。如果做邮件助理，用户连发三条消息合并成一轮只回一次，适合当默认策略。原文给的处理方式没有标准答案，取决于事件是否继续旧任务、能否合并、用户是否等着。

最后，原文那句话值得记住：一开始最好让 Agent 安静一点。

来源：Anthropic《Building always-on agents》，作者 William Hu，2026.11.13。原文：https://claude.com/resources/articles/building-always-on-agents 。宝玉推文：https://x.com/dotey/status/2121406975279792268