Anthropic 11 月 13 日发布工程文章《Building always-on agents》，作者 William Hu，把常驻智能体拆成事件收件箱、定时器、记忆、权限与发件箱五个架构原语。文章先纠正一个说法，常驻智能体并非一直运行，它大部分时间休眠，被 webhook、定时任务或后台作业唤醒后做一次 run，跑完接着睡。
文章把这轮回潮归因于模型判断力提升与智能成本下降，并给了一个可核对的数字，在某项长程编码基准上，Opus 5.5 每解决一个任务的成本比 Opus 5 低 78%，典型负载上的降幅是 40%。两个百分比均为厂商自测口径，基准名称、任务数量与绝对金额没有写出，公司也没有列出对照模型的运行时长。
事件收件箱由持久事件列表、HTTP 端点的 handler 与后台 worker 三部分组成。约束包括，handler 要尽快确认以免被判失败，收件箱作为真相源使 worker 中途死掉后能重试，一个收件箱同时只留一个活跃 worker，事件按来源标识去重，待处理事件还应合批，让用户连发几条消息只得到一次回复。定时器分跟进与周期两类，存在与收件箱分离的持久表里，到期由 scheduler 写成事件再唤醒 worker。
记忆要求独立持久存储，官方举的实现是文件目录映射到数据库或对象存储，只存智能体无法重新查到的信息，其余留指针；每次 run 按需加载记忆文件，另有整理过往 session 的 dreaming。权限被文章称为风险最大的一层，建议由环境外的代理注入真实凭证，auto mode 用分类器审查高风险动作，需要审批时把工具调用挂起，用户答复作为新事件回到收件箱再恢复。发件箱多数场景一个 send 工具就够。
把这五个部件摊开看，都是分布式系统里用了多年的形态，新的地方在于何时算同一段对话、什么值得记住、什么时候不打扰用户，这些判断从代码规则挪进了提示词与评测。文章没有给出常驻运行的生产案例与故障率，78% 与 40% 的测算方法未说明，官方组件是否全部可用、如何计费也没有写。成本降幅是厂商自测，跨模型能否复现暂无独立验证。