Agent 说自己全天候在线，其实大部分时间在睡觉

Anthropic 11 月 13 日发了篇长文，讲怎么搭 always-on agent，作者 William Hu，阅读时长 14 分钟。原文地址：building-always-on-agents。

先纠正一个说法。always-on 描述的是用户体验，跟运行状态没关系。真实情况是它大部分时间在睡觉，被事件叫醒，跑一段，把状态存好，接着睡。这段醒着的时间叫 run，run 活在 session 里，session 是消息和工具调用的流水账。run 结束，Agent 回到睡眠，循环无限重复。

常驻 Agent 的时间线：长时间休眠，短促的 run 把它切开。每个 run 四步：事件到达、开启 session、跑 Agent 循环、把状态写回存储

为什么现在这事可行，文章给了两条：新模型判断力更好，知道什么时候该找用户确认；推理变便宜了，长周期任务省得最多。同一份长周期编码基准上，Opus 5.5 每解决一个任务的成本比 Opus 5 低 78%，普通任务只低 40%。

把架构拆下来，是五个原语。

事件收件箱

普通 Agent 只在你发消息时启动。常驻 Agent 得被 webhook、定时任务、后台作业叫醒。最省事的做法是让事件源直接调 Agent，问题是两个事件同时到达会打架，进程崩了事件就丢了。所以中间要垫一个收件箱：一张数据库表存事件，一个 HTTP handler 负责写入，一个后台 worker 负责读取。事件带状态，靠来源的唯一 ID 去重，建议先一个用户一个收件箱。

事件收件箱：handler 把事件写进数据库表，去重并记录状态，再唤醒 worker。worker 取出待处理事件，启动 run，等它跑完，把事件标成完成

四条实践：handler 要快速确认，webhook 提供商把慢响应当失败；收件箱是唯一真相源，worker 被唤醒后先从表里拉最新事件，这样 worker 挂了换一个还能重试；一个收件箱同时只能有一个活跃 worker，防止两个 run 重复干活或互相覆盖；worker 要把积压事件合批，用户连发几条消息，合并成一个 run 回一次就行。

定时器

定时器和收件箱配合，Agent 才有主动性。分两类：follow-up 是 Agent 给自己设的截止时间，比如过多久回来看看有没有回复；schedule 是周期任务，比如每天发简报。定时器单独存一张表，别塞进收件箱，收件箱只放已经能处理的事件。scheduler 按固定间隔轮询，到期的 follow-up 标成完成，schedule 把到期时间推到下一次，然后往收件箱写事件、叫醒 worker。scheduler 自己写或者用现成的持久化执行引擎都行。

定时器：run 往表里写一条 follow-up 或 schedule。scheduler 找出到期的，写进事件收件箱，启动下一次 run

记忆

run 和 run 之间是断开的，连续性全靠记忆。记忆也应该单独存，通常是数据库或对象存储，让记忆比 worker 活得久。原则一句话：只存 Agent 查不回来的东西，别的系统里已经有的，存个指针。

四类要存：用户指令，每次 run 启动时加载，用户不总在旁边盯着；用户笔记，角色、偏好、纠正过的地方，先一个文件，多了改成索引加分文件；过往消息，避免重复告诉用户同一件事；任务进度，每个进行中的任务一份进度文件，新 run 读完接着干。

一种记忆目录：instructions.md、index.md、reported.md 每次 run 开头加载，notes/ 和 progress/ 按需读取，run 过程中写入记忆

还可以加一层 dreaming，回看历史 session 整理记忆，替换过期条目，找出跨多次 run 才浮现的模式。

每次 run 开头都要装系统提示、工具定义、记忆文件，这份固定开销建议用 prompt caching 压成本。新 session 只有这份开销加上触发事件，老 session 会把之前的对话和工具调用带回来。

上下文随时间的占用：系统提示、工具、记忆占固定一段。已有 session 带回完整记录，越滚越大，直到压缩把旧记录变成摘要

权限

权限是风险最集中的地方。run 拿着用户的权限，还无人值守。每次工具调用，Agent 要判断是自己干、拦下来还是等人批。三样东西：凭证仓库，推荐放在 Agent 环境外面的代理里，Agent 发不带凭证的请求，代理注入真凭证再转发；auto mode，用分类器审高风险动作，判危险的拦掉，让 Claude 换条路，最重要的决定仍然要人看；deferred tool call，把调用挂起，run 结束，session 中途保存，请求以交互卡片的形式给用户，用户答复作为事件回到收件箱，起新 run 续上。挂起期间 worker 可以去处理别的事件，不阻塞。

发件箱

普通 Agent 边生成边流式输出，用户全程围观。常驻 Agent 在后台干活，用户要的是结果和少量细节，不是完整推理过程。run 有三种收尾：发消息、判断不用发、用 deferred tool call 要权限或补充信息。搞个 send 工具直接发也行，只有当你想控制节奏或从错误里恢复时，才需要正式的发件箱。它是另一张表，配一个 dispatcher，跟收件箱和 worker 的对应关系一样。发多少也是个问题，发太多吵，发太少漏。文章的建议是让 Agent 一开始安静点，慢慢赢得注意力。

发件箱：run 可能什么都不发，可能调 send，可能挂起等用户。消息进数据库表，dispatcher 投递给用户

五个原语拼起来是这样：

五个原语如何衔接：定时器和收件箱启动 run，run 在 session 里用记忆和权限干活，发件箱把消息送出去，用户的回复又变成事件

每个 run 都从收件箱里的一条事件开始，用户消息、webhook、定时器都算。worker 取事件，开 run，新建或恢复 session。Agent 读记忆拿基线，在权限范围内动手，把学到的东西写回记忆。run 结束，往发件箱推一行，dispatcher 送到用户手上。run 可以顺手设个定时器，下次再醒；用户回复，又变成收件箱里的事件。单个 run 很短，循环一直转，这就是“常时在线”的来源。

原推下面有人补了一条：收件箱旁边还该放一份已完成记录，被叫醒两次不能把同一封邮件发两遍。另一位说，事件驱动架构终于轮到 Agent 了。