Serverless Agents

No Machine Owns the Loop。给 agent 一小时任务、合上笔记本五分钟——agent 不该死。把循环放进持久控制平面、把机器降级为工具，loop 即可 serverless。

作者: Ishaan Sehgal (Omnara, YC S25) 2026-07-23 原文 ↗

一句话论点

病根：local-first 把 agent 和设备绑成一体

Claude Code 2025 年初带起的 local-first 形状，被 Codex / Gemini / Cline / Grok / OpenCode / Cursor / Zed 全员复制。harness 和执行环境是同一个单元，跑在开发者笔记本上。"上云"也只是把笔记本搬进数据中心——架构没变。

诊断：agent 打破了同步假设

整个编程工具史（包括云端 CDE）都默认一个没人命名的假设：人停即编程停。agent 打破了它——它可以查故障、等 CI、响应外部事件、请求审批，在启动它的那次交互结束很久之后继续工作。

解法：拆成两个平面

既然 agent 不该继承设备生命周期，它的连续性得住在别处——一条 durable 事件 log（见姊妹篇 The Log Is the Agent）。由此得出一个干净边界：

"Serverless" 到底是什么

消息到达 → 一个临时 worker 认领 agent → 从 log 重建状态 → 问模型下一步 → 记录 → 消失。后续事件到达时，另一个 worker 接着干。agent 因此可以在零个 worker 运行时仍然活着——它只是在等。

# Runs on any worker, whenever an event lands
def advance(agent_id, event):
    with temporary_lease(agent_id):
        append_to_log(agent_id, event)
        state = reconstruct_from_log(agent_id)
        action = model.next(state)
        append_to_log(agent_id, action)
        dispatch(action)          # fire-and-forget
    # worker exits — the agent persists in the log

设备的新角色：从"容器"变成"客户端"

这套架构最打动人的一点：用户体验可以完全不变。仍在 repo 里开终端、输入请求、看命令跑、就地批准。笔记本仍是执行平面的一部分。改变的只是角色——harness 要读文件/跑命令时，把动作路由给笔记本，结果回写进 agent 历史。合上笔记本，依赖本地文件的工作暂停，但 agent 仍在控制平面；机器回来时同一个 agent 可继续用它。

分离后自然落地的四性质

性质	本地架构	持久控制平面
可用性	每次等待都是某台机器的 uptime 要求	等待只是 durable state；不必持续运行也能持续可用
韧性	一台机器/进程失败 = agent 失败	worker 允许失败，另一个从 log 重建接续
可扩展	每 agent 一个常驻进程	worker 容量 ∝ 并发推进数，machine 容量 ∝ 活跃 OS 工作量（两条独立曲线）
效率	持久 agent = 永久沙箱	1000 agent 仅 5% 需 shell → 执行平面只需 ~50 活跃负载；空闲 agent 消耗存储而非机器

谁拥有循环：可所有权

行业已在此方向移动——Anthropic Managed Agents 分离 harness 与 sandbox；Ramp / Stripe / Sentry / Coinbase 自建内部 background agent。但它们都不提供所有权：跑单 provider 模型在其基础设施上，不可 model-agnostic、不开源、不可自托管。

作者论证：agent 是你将运行的最亲密的软件（它需要你的个人数据、公司数据、工作流、决策）。The Log Is the Agent 已论证"记录层"——provider 持有 log 唯一副本即拥有你的 agent。本文把同一论证向上爬一层：控制平面是 log 居住、harness 运行之处，所以你也应该能拥有控制平面。这正是 Omnara 即将开源其控制平面的动机。

结论

这是 Omnara 正在构建的系统——他们即将开源 agent 的控制平面。