常驻 Agent 的五个基础件，和它睡着之后要处理的事

Anthropic 11 月 13 日发了一篇 Building always-on agents，作者 William Hu。九原客在推文里说，这其实是 Personal Agent 最基本的设计模式，之前在 raft build 上见过类似设计。

常驻 Agent 并没有真的常驻。它大部分时间在睡觉，事件到了才醒。每次醒来叫一个 run，run 在 session 里执行，结束后把状态写回去，再继续睡。

Anthropic 把这套架构拆成五个基础件：事件收件箱、定时器、记忆、权限、发件箱。

事件收件箱解决触发问题。webhook、定时任务、后台任务都不直接调用 Agent，先把事件写进收件箱。收件箱通常是一张数据库表，handler 负责写入，worker 负责读取并启动 run。实现时有几个细节：handler 要快速确认，收件箱是 source of truth，一个收件箱同一时间只放一个 active worker，pending 事件可以合并，避免同一件事被重复执行。

定时器让 Agent 能主动做事。它分两类：Agent 给自己设的 follow-up，和用户设的 schedule。定时器不直接启动 run，scheduler 轮询到期项，把事件写进收件箱，再唤醒 worker。

记忆负责跨 run 续上上下文。Anthropic 的做法是把记忆做成文件目录，映射到数据库或对象存储。instructions 每次 run 都加载，用户笔记和任务进度可以只加载索引，需要时再读具体文件。已经存在别的系统里的东西，存指针就够。上下文开头的系统提示、工具定义、记忆文件是固定开销，要控制体积，用 prompt caching 降成本。session 太长可以压缩旧消息或新开，但细节会丢，需要持久化的内容要提前写进记忆。

权限是风险最大的部分。常驻 Agent 拿用户权限，按设计又没人盯着。凭证推荐放在 Agent 环境外的代理里，Agent 发请求时不带密钥，代理转发时注入。高风险动作交给 auto mode 的分类器拦，最重要的决定仍然要用户确认。需要澄清或审批时，用 deferred tool call 把请求展示给用户，run 结束并保存 session，用户答复作为新事件回到收件箱，下一个 run 再恢复。

发件箱处理输出。run 可以发消息，可以什么都不发，也可以用 deferred tool call 请求输入。outbox 是一张待发送消息表，dispatcher 负责投递。消息频率要调，发太多会吵，发太少会漏。Anthropic 建议用 evals 找平衡，先让 Agent 安静，再逐步争取用户注意力。

五个件串成一个循环：定时器或收件箱触发 run，run 读记忆、在权限内行动、写回记忆，结果进发件箱，用户回复又变成收件箱里的新事件。

评论区里几个判断比标题更实在。有网友说，永远在线听着比打工人还累。有人说，让它一直开着不算最难，难的是它知道什么时候该叫你。有人把手机当成最个人的 event inbox。也有人提醒，断了之后从哪续、重复执行怎么去重、空转烧 token 的账单，才是常驻之后每天要面对的问题。

Anthropic 给的是基础件，落地还要自己补状态恢复、去重和成本控制。常驻 Agent 的体验差距，很可能就藏在这些不显眼的地方。