Agent 架构新范式：持久化运行而非常驻进程

Published on julin.ai

构建 AI Agent 的常见方式，是将其视为一个长时间运行的进程。Worker 收到请求后进入 Agent 循环，调用模型和工具、等待结果，最终返回答案。

直到 Agent 开始执行实际工作时，这种方式才会暴露问题。

Agent 可能在研究问题上花费 20 分钟，等待构建 10 分钟，请求用户审批，或在外 部任务完成后数小时才返回。整个运行期间保持 worker 存活会浪费资源，且失败代价高昂。部署、崩溃或机器重启都可能摧毁已经完成的工作。

一个更好的模型是将 Agent 运行与执行它的进程分离。

Agent 运行是持久的。它的状态、消息、工具结果、预算和当前位置都存储在 worker 外部。Worker 是临时的。它租用一个可运行的 Agent，执行短期有用工作，检查点新状态，然后消失。

运行在持久会话中加载，循环执行思考和工具步骤，检查点，然后 worker 退出。

后续的 worker 可以从检查点继续执行。

这不意味着每个模型或工具调用都需要自己的进程，那样会造成不必要的调度和状态重建开销。Worker 可以获得 30 秒或 60 秒的租约，在取得进展时执行多个 Agent 步骤。

重要的界限在于等待。

如果 Agent 需要等待 CI 运行 5 分钟，它不应该睡眠 5 分钟。它记录等待状态然后退出。当 CI 完成或定时器触发时，运行会再次变得可执行。

同样的模式适用于速率限制、人工审批、计划操作、外部回调和 Agent 间的通信。

这改变了我们对 Agent 的思考方式：

one agent = one process

one agent = durable state
          + a sequence of short compute leases

这个模型有一个有趣的扩展特性。系统可以包含一百万个活跃的 Agent 运行，而不需要一百万个运行中的进程。大多数 Agent 通常处于等待状态，只有那些有有用工作要做的 Agent 才需要计算资源。

这有成本。状态必须能够廉价地重建。副作用必须能够承受重试而不会被执行两次。浏览器、Shell 和沙箱可能需要自己的更长寿命的服务。流式输出也需要独立于当前拥有运行的 worker。

但这些都是我们已经知道如何解决的基础设施问题。

大型 Web 系统很久以前就停止为每个用户分配永久的服务器进程。Agent 系统最终可能也会做出同样的转变。

因此，有用的抽象不是短命的 Agent。

而是一个具有租约执行器的持久 Agent。