Anthropic 拆解常驻 Agent：五类组件串起后台运行与审批 · 2026-11-14
本期为历史补录：取材日期 2026-11-14，补录于 2026-11-14；不代表今日新消息。
（dated November 13）五类组件支撑常驻体验，审批等待可跨运行恢复
Anthropic 于2026年11月13日发布《Building always-on agents》，将常驻 Agent 的外围架构拆为五类组件：事件收件箱、定时器、记忆、权限和消息发件箱。这是一篇 Claude Platform 工程实践文章，内容围绕架构设计展开。文中解释，常驻体验由反复唤醒、执行和休眠形成；每次执行称为一次 run，所在的 session 保存消息与工具调用记录，核心代理循环与其他 Agent 相同。
这套设计面向希望让现有代理主动工作、或从头构建后台代理的产品团队。相较于收到用户消息才运行的代理，触发来源扩展到 webhook、定时任务和后台作业。文章指出，各事件源直接调用代理可能导致并发执行相互竞争，或在崩溃时丢失事件；它建议通过持久化收件箱接收事件，每个收件箱同时只保留一个活跃 worker，并合并待处理事件。定时器到期后也向收件箱投递事件，记忆则使用独立的持久化存储，使状态能够跨 worker 生命周期保留。
无人值守执行把权限边界带到每次工具调用：自主继续、阻止，或等待批准。文章沿用 Claude Code 的相关模式，描述了由代理环境外的代理服务注入凭据，以及延后工具调用的机制。需要用户确认时，当前 run 结束，session 保存到调用中途；用户答复作为新事件返回收件箱，随后恢复执行。在等待期间，worker 仍可处理其他事件。文中同时强调，最重要的决定仍需用户审核，因此主动运行并不意味着取消人工审批。
消息交付也有明确的适用范围：文章认为多数常驻代理使用直接发送消息的工具即可，只有需要控制发送节奏或从错误中恢复时，才需要正式的发件箱及 dispatcher。对于这些开发团队，文章的工程价值在于把事件接收、状态延续、权限等待和消息交付分别说明，而不是只描述模型如何完成任务。它还指出，压缩旧消息或开启新 session 都会丢失细节，需要长期保留的信息应在运行过程中写入记忆；消息频率则应通过评估来调整。
证据与适用范围
本期仅依据 Anthropic 一篇官方工程实践文章，未独立验证其实现，也未进行部署、故障恢复或权限安全测试。该来源不足以确认上述架构已作为完整托管产品提供，或证明其在具体负载下的可靠性与成本；本期亦无可支持市场及监管报道的材料。
本文使用 AI 辅助起草，并经过独立模型审稿；属于来源分析，未进行独立性能测试。