Omnara开源可持久运行的Agent服务

把 AI 模型接进产品，只是 Agent 系统的起点。任务在哪里执行、工具调用谁来批准、进程崩了怎么恢复、历史记录存在哪里，才是把演示变成服务时绕不开的问题。Omnara 想把这些能力做成一个可自托管的开源平台。

它的主张很明确：模型和执行机器由你选择，Agent 的运行、权限和状态交给平台管理。对前端和全栈开发者，值得看的是这套分层思路；至于它能否替代成熟托管服务，原文提供的证据还不够。

它替你管理的，到底是哪一层

Omnara 将自己定位为 Claude Managed Agents 和 OpenAI's Agents API 的开源替代方案，采用 Apache 2.0 许可证，同时提供 Omnara Cloud。

它接管的是 Agent 的运行过程：接收任务、构造模型上下文、调用工具、等待审批，以及持续返回事件。你的应用通过 REST API 或 TypeScript SDK 发出请求，平台再按配置选择模型、工具和机器。

模型支持范围也有明确边界：原文列出 OpenAI Responses、OpenAI Chat Completions、Anthropic Messages 兼容端点，以及 OpenAI、Anthropic、OpenRouter、Amazon Bedrock、LiteLLM、Ollama 等接入方式。因此，「任意模型」应理解为满足这些接口兼容要求的模型，不能直接推导为所有模型都能无成本接入。

机器则被当作 Agent 可以使用的工具。macOS 或 Linux 上的笔记本、VM、容器安装 omnarad 后，会主动连接平台，不需要为连接开放入站端口或配置 SSH keys。

原文还列出 11 家沙箱供应商：Arker、Blaxel、boxd、CreateOS、Daytona、E2B、Freestyle、Modal、Superserve、Tenki、Unikraft。一个 Agent 可以使用多台机器；作者称笔记本离线后，任务可以转到沙箱继续，再通过 git 同步工作。

这里要分清网络连接和执行权限。无需入站端口，解决的是机器如何接入；Agent 能读哪些文件、执行哪些命令，仍需要另外配置。

为什么任务恢复能力要落到数据库里

Omnara 的架构中心是 API、Postgres 和 Workers。

API 负责启动 Agent、接收消息、处理审批和输出事件流。应用、CLI、控制台共用这套接口，业务系统也就不必依赖控制台操作。

Postgres 保存每个 Agent 的每一步记录，而且这些记录就是它的状态。Workers 是无状态进程，负责构造上下文、请求模型和执行工具。某个 Worker 崩溃或重启后，另一个 Worker 可以依据记录继续处理。

长期运行的 Agent，需要把任务状态放在执行进程之外。

Worker 只在 Agent 处理一轮任务时被占用，因此一个 Worker 可以服务多个 Agent；增加 Workers，则可以提高同时处理任务的能力。平台还使用 Redis、存放附件和工具输出的 blob storage，以及 memory filesystem。自托管需要维护的服务，比一个模型代理接口更多。

但「恢复任务」还有一条边界：恢复运行记录，不等于外部操作恰好执行一次。工具已经提交了修改，记录却没来得及写入怎么办？原文没有解释幂等、去重和重试语义，接入有副作用的工具时仍需核查。

权限设计也值得借鉴。每个工具可以配置为立即执行、先请求人工批准，或者禁止执行，规则由平台强制执行。Agent 会等待批准或拒绝结果，而不是只靠提示词提醒它谨慎操作。

此外，Memory 可以跨对话保留文件，并按 Agent 设置只读或读写权限；Subagents 使用新的上下文，每个都是可独立检查的完整 Agent。两者分别解决信息复用和任务拆分，不应混成一种能力。

从 Node 接入，顺畅体验有哪些前提

Omnara Cloud 的首个项目预置了模型提供方 omnara-openrouter 和沙箱池 default-pool，所以原文这份 agent.yaml 可以直接用于云端示例：

version: v1
instruction: |
  You are an engineering assistant. Use your machine to run commands.
model:
  provider_config: omnara-openrouter
  name: anthropic/claude-fable-5.1
machine_sources:
  - machine_pool_name: default-pool

要留意 provider_config 和 machine_pool_name：它们引用的是实例里已有的资源。模型名 anthropic/claude-fable-5.1 是原文配置值，原文没有给出该模型的能力测试。

CLI 要求 Node.js 22 或更新版本，通过 npx omnara agents launch --file agent.yaml 启动，示例还传入 --name "Machine assistant" 和 --message "Report this machine's operating system and free disk space."。随后可以用 npx omnara agents chat <agent-id> 在终端继续对话。

对 Node 服务，更有参考价值的是 SDK 流程。先创建 API key，导出为 OMNARA_TOKEN，执行 npm install @omnara/sdk，再用 npx omnara config 查看组织和项目 ID：

import { readFile } from 'node:fs/promises'
import { bearerToken, createOmnaraClient, openAgentEventStream, sdk } from '@omnara/sdk'

const client = createOmnaraClient({ auth: bearerToken(process.env.OMNARA_TOKEN!) })
const path = { orgID: 'org_...', projectID: 'proj_...' }

const config = await sdk.createAgentConfig({
  client,
  path,
  body: { source: await readFile('agent.yaml', 'utf8'), source_format: 'yaml' },
})
const launched = await sdk.createAgent({
  client,
  path,
  body: { config: config.data.id, message: "Report this machine's free disk space." },
})

const agentID = launched.data.agent.id
for await (const event of openAgentEventStream({ client, path: { ...path, agentID } })) {
  console.log(event)
}

重点看最后的 openAgentEventStream：消费的是 Agent 运行事件，不只是最终文本。前端可以据此展示工具调用、任务进度和审批等待；但事件结构、断线重连和历史补取，原文没有展开。

自托管则要求 Docker with Compose，启动命令是 docker compose -f compose.yaml --profile app up -d，本地入口为 http://localhost:8000。验证链接会出现在 docker compose logs api，无需先配置邮件服务；源码构建使用 docker compose --profile app up -d --build。

新实例没有现成模型和机器。需要添加模型提供方与模型、连接机器，再把资源显式共享给项目；配置中的 machine_pool_name 也要替换为 machine_name: <your machine>。沙箱接入还要求实例拥有公共 URL。

CLI 通过 npx omnara config --api-url http://localhost:8000/api/v1 --issuer-url http://localhost:8000 切换实例，再执行 npx omnara login。原文明确提示：本地默认配置刻意采用不安全设置，不能直接当作生产配置。

如果参与源码开发，要求又有所不同：Go 版本以 go.mod 为准，Node.js 24 或更新版本，并需要 Corepack、ripgrep 和 Docker with Compose；快速仓库检查命令是 make verify。

我的判断

我认可它把状态、执行机器和工具权限拆开管理的方向。这些问题不会因为换一个更强的模型就自动消失，平台统一处理也有利于业务系统保持清晰边界。

但这份原文主要是产品说明和接入指南。它没有提供并发量、恢复耗时、长期运行成功率，也没有给出与两家托管方案的成本和可靠性对照。示例覆盖 PR review、5xx 排查、浏览器任务等场景，只能说明项目提供了对应配置，不能当作效果验证。

「免费自托管」同样只描述软件收费。数据库、Worker、存储、模型调用和维护仍有成本。Omnara Cloud 声称没有平台费，自带模型 keys 和机器可以免费使用平台；平台提供的模型按供应商 token 费率计费，沙箱按活跃时间和保留存储收费。原文没有给出具体价格。

只做一个短流程工具时，直接接模型 API、配一个任务队列，可能更容易掌控。等到确实需要多机器执行、人工审批、跨会话状态或多租户管理，Omnara 这类平台的价值才更明显。它是否适合团队，应通过真实任务验证，不能仅凭功能列表决定。

能拿来做什么

• 如果你正在给 Node 产品加入后台 Agent，可以先接入一个读取机器信息的低风险任务，验证配置创建、任务启动、事件消费和人工继续输入，再扩展工具权限。
• 如果团队希望自动 review PR，可以用原文的 PR review agent 示例做小范围试点，检查它如何结合仓库 checkout 提交行内发现，并保留人工复核。
• 如果你准备自托管，先验证资源共享和权限边界，再测试 Worker 重启、机器离线后的恢复行为；涉及写操作时，单独检查重复执行问题。
• 如果只是想从现有编程助手调用远程 Agent，可以先评估 MCP 接入。原文支持 Claude Code、Codex、Cursor 等具备 OAuth 能力的客户端，不必立刻开发完整业务界面。