拆解 Anthropic 的 7*24 在线 Agent 架构设计

一件事，多轮运行

假设我们让 Agent 跟进一次代码修复：调查问题、修改代码、提交测试；测试失败了，继续排查；准备推送到约定的分支时，再找人确认。中间可能等几分钟，也可能隔一夜。

测试还没结束，人还没回复，Agent 就可以结束本轮执行。指南明确说，它大部分时间都在休眠。这里的“在线”，说的是事情能够持续跟进。

run 是一轮执行；session 保存消息和工具调用记录，可以跨越多轮 run。 下一条事件到来，系统再恢复已有 session，或开启新的 session。

图里，每轮执行内部仍是熟悉的模型与工具循环：判断下一步、调用工具、查看结果，继续工作。Anthropic 重点设计的是循环之外的五类职责：inbox 收事件，timer 安排后续运行，memory 保存跨轮信息，permissions 管理行动权限，outbox 处理消息输出。

这些围绕模型准备上下文、提供工具、管理执行与权限的程序，属于我们常说的 Harness。顺着那次代码修复，就能看清它们为什么需要配合。

先入队，再执行

测试结果来了，用户又补充一句要求。如果两个入口都直接调用 Agent，就可能同时启动两轮执行，互相覆盖进度；进程中途退出，刚收到的消息也可能丢掉。

Anthropic 给出的起点很朴素：一张持久化的 inbox 表、一个接收事件的 HTTP 接口、一个后台 worker。

接口先把事件写入表中，尽快确认收到，再通知 worker。worker 以表内记录为准，读取待处理事件：延续已有工作的事件，如用户对先前问题的回复，恢复对应 session；其他事件则开启新 session。本轮处理结束后，再把对应事件标记为完成。

这样，即使 worker 中途退出，后续 worker 仍能找到未完成的记录。来源重复投递的事件，可以按唯一 ID 去重；用户连续发来的几句补充，也可以合并成一轮处理。

原文建议从“一个用户一个 inbox，同一 inbox 同时只有一个活跃 worker”开始，让状态更新有明确顺序。运行中又来了新消息，是留到下一轮、并入当前轮，还是中断重来，则取决于具体交互。

回到测试。如果 CI 支持异步提交，Agent 可以保存测试任务 ID，结束本轮；测试完成后，结果再作为事件进入 inbox。触发本轮的事件处理完了，整项修复任务仍在继续。 worker 也不必一直等测试，可以处理其他事件。

这种做法还有个容易漏掉的细节：用户可能在等待期间换了修复目标。旧测试结果回来时，需要核对任务和代码版本；结束一轮 Agent 执行，并不会自动取消已经提交的测试。

到时间，再触发

测试结果可以回调，但“两小时后再看看有没有回复”怎么办？模型写下这个打算，还需要有人负责到时启动下一轮。

指南把 timer 单独持久化，由调度器定期检查。到了时间，调度器更新 timer，并向 inbox 写入事件。一次性 timer 标记为已触发，周期 timer 更新到下一次执行时间。后续仍由 worker 取出事件，按统一流程处理。

未来的安排留在 timer 中，inbox 只存已经可以处理的事件。到期只是入队，实际执行还要等 worker。

模型决定是否跟进、何时再看；调度器负责到时产生事件。 不必让 worker 挂在那里等两小时，也不必为定时任务另写一套执行流程。能收到完成回调的任务，通常也用不着频繁调用模型去查。

实现时还需要补上可靠性处理：如果 timer 已标记完成，事件却没写进 inbox，这次跟进就可能消失。两张表在同一数据库时，可以用事务完成这两个动作；分属不同存储时，则需要可重试的投递和去重。

下一轮记住什么

事件到了，新的 run 开始。接下来的问题是：这次跟进哪件事，上次做到哪里？

沿用原 session，能带回之前的消息和工具调用，但上下文总有上限。压缩旧消息或新建 session 都会丢失细节，所以重要信息需要在工作过程中及时保存。

我们之前在《Coding Agent 为什么正在从 Session 走向 Project？》里，讨论过把目标、约定和进度保存在单次会话之外。常驻 Agent 又向前走了一步：无论下一轮由测试回调还是定时器触发，都得找到与这件事有关的记录。

William 将记忆分为四类，区别主要在于下一轮如何使用：

保存什么	下一轮如何读取
行为要求，如“推送前找我确认”	每轮加载，延续原有约定
用户偏好与背景	少时直接读，多时按索引查
任务进度与后续安排	按任务读取具体记录
已经告诉过用户的内容	发送前查看，避免重复通知

测试日志、工单状态这些外部系统已有的信息，尽量只保存引用，需要时再查询最新状态。对代码修复来说，一句“测试通过”不够，还得知道哪个提交、哪次测试通过了。

这也关系到进度是否可信。Anthropic 在 2025 年的长期运行 Agent 实验中，就遇到过模型改完代码、跑过单元测试便认定功能完成，实际用户流程仍有问题的情况。那套 Harness 用功能清单、进度文件、Git 记录和端到端验证支持后续开发。记忆中的“已完成”，需要有产物和验证结果作为依据。

这些信息存在哪里，同样重要。Claude Code 自动记忆和 Messages API 的 Memory tool 采用文件目录形式；指南建议，常驻 Agent 将目录映射到数据库或对象存储等持久存储。记忆和工作产物的寿命，都要长于本轮 worker。 否则，进度写着“修复已准备好”，代码却随临时环境消失，下次仍然无法继续。

这里的 Memory tool 是客户端工具：Claude 发出文件操作请求，由应用执行，并提供 /memories 背后的实际存储。跨会话能否读到同一份记忆，取决于应用如何保存它。

持久保存之后，还要控制每轮读入的量。行为要求每轮加载，具体任务记录按需读取；系统提示、工具定义和初始记忆尽量精简，并使用提示缓存降低成本。原文还提出可选的 dreaming：回看历史会话，更新过时记忆、发现跨轮规律。它负责后续整理，日常进度仍要在工作时及时记录。

等人时，保存进度

测试通过，Agent 准备推送代码，用户却不在线。前面保存的“推送前找我确认”，这时就要真正约束工具调用。

Anthropic 采用 deferred tool call，也就是暂缓执行工具调用：保存 session 和尚未完成的调用，展示问题，结束本轮，等回复再恢复。

第二天用户回复，答案作为事件进入 inbox，触发新的 run，恢复对应 session。保存下来的信息必须能说明：这个问题属于哪个任务、对应哪个工具调用。这样，一句“同意”才能找到要继续的动作。

基于 Claude Code 实现时，官方 hooks 文档提供了 defer 机制：PreToolUse 可在非交互模式 claude -p 下暂缓调用，由外层应用收集回复后恢复 session。目前要求该回合只有一个工具调用；交互模式或多工具并行调用不适用。

等待用户只是权限设计的一部分。无人值守时，Agent 还要能在授权范围内自行工作。指南引用 Claude Code 的 auto mode，用分类器审查高风险动作，拦截识别出的危险行为，让 Claude 尝试更安全的做法；最重要的决定仍需用户审查。

凭证则放在 Agent 环境之外：Agent 发出不带凭证的请求，由代理注入真实令牌后转发。这样可以使用服务，又不必把真实令牌交给执行环境。分类器有判断局限，工具本身仍需限定权限。

从架构上看，确认因此成为任务中可以保存、可以恢复的一步。但恢复不代表原样重做昨天的动作：分支可能已更新，用户要求可能已改变，需要先核对最新状态。

故障重试还会遇到另一个问题：外部操作已经成功，本地却没来得及记下结果。事件去重，不能保证外部操作只发生一次。 推送等外部动作还需要幂等处理，或先查询执行结果。这是实际落地时需要补充的恢复条件。

有结果，再通知

修复推送成功，最后还差一步：让用户知道。

Anthropic 将一轮运行的结束分成三种：发送消息、静默结束、暂缓调用并询问用户。 修复完成，就发结果；查了一次没有新进展，可以保持安静；不确定目标分支，就提出问题。每次运行都发“我又检查了一遍”，持续跟进很容易变成持续打扰。

发送机制可以先简单些。原文认为，多数场景用一个 send 工具直接发送就够了。需要控制发送节奏、从发送错误中恢复时，再引入正式的 outbox：Agent 将待发消息写入独立表，由消息发送程序 dispatcher 读取并投递。

修复已经完成、通知却没发出去时，就可以只重试通知，而不必重新做一遍修复。确认请求也可以经过 outbox，或直接显示在界面中；用户回复仍回到 inbox。

除了能否送达，还要看这条消息值不值得发。指南建议评测通知频率，初期安静一些。记住已经通知过什么，也是为了避免每次定时检查都重复汇报同一份结果。

Harness 留下什么

沿着一次代码修复看下来，这套设计的重点逐渐清楚了：任务可能在等测试、等时间、等人，但每次等待都有记录，也有下一次运行的入口。五类职责可以由一个应用和现有数据库承担，并不要求拆成五套微服务。

这也让我们今年一直讨论的“Harness 做减法”更具体了：哪些流程可以随模型进步而简化，哪些仍然需要系统负责？

Claude Code 团队的 Thariq Shihipar 在 9 月访谈中提到，为旧模型积累的纠错指令，可能反过来限制新模型；与此同时，模型能做的工作更多，沙盒、权限和数据访问等设施也会更复杂。

Anthropic 今年 3 月的应用开发实验就调整过前一类流程：换用 Opus 4.6 后，研究者撤掉分阶段开发的安排，把评估移到构建结束后。这说明一些步骤值得随模型变化重新评估，不能由此推成所有任务都不再需要验证。

而在常驻 Agent 中，两小时后由谁触发运行，换了 worker 到哪里读进度，用户隔天回复后继续哪个调用，仍然需要明确的程序和存储来完成。

回到开头的问题：今天没做完，明天能不能自己继续？这套架构给出的办法，是让每一轮都留下足够的信息，也为后续工作安排好触发条件。一次执行可以结束，一件事仍然有人持续跟进。

JOTO 企业落地观察

• 企业部署常驻 Agent 时，需优先保障 inbox 与 timer 的跨节点一致性，否则将导致事件丢失或重复触发，直接影响任务连续性。
• 这类系统的取舍在于：是否将 memory 存储与业务数据库解耦。耦合便于事务控制但增加运维负担；解耦利于扩展却需额外实现最终一致性保障。
• RAG 知识工程在此类系统中需转向“按需加载+显式缓存”模式——行为要求类记忆必须全量加载，而用户背景类记忆应支持语义检索与增量更新。
• AI 安全治理的关键落点从单次调用审查，延伸至跨轮行为链审计：例如“用户确认→代码推送→分支更新”需形成不可篡改的操作证据链。