把 Agent 当成服务运行：Omnara 的自托管平台、机器与持久状态
许多 AI Agent 原型能在开发者自己的终端里跑通，却很难变成团队可依赖的服务：进程重启后状态如何恢复？模型、工具和机器凭据由谁管理？用户从 Slack 或应用发来任务后，如何观察执行并审批高风险操作？Omnara 想解决的不是某个 Agent 的提示词，而是这些运行时与运营问题。
它是一个 Apache-2.0 许可的开源 managed-agent 平台，可以使用 Omnara Cloud，也可以自行部署。它把 REST API、工作进程、持久事件记录和可连接的执行机器组合起来，让应用通过 API 启动 Agent；模型、工具和机器则按项目配置。这里的“托管”指生命周期、状态和连接能力，不代表自托管后无需运维。
它与 Agent 框架有什么不同
LangChain、Mastra 等框架主要帮助开发者在应用代码中组织 Agent 逻辑；终端 harness 通常围绕单个开发者和本机工作流。Omnara 的重点则是把 Agent 作为可启动、可观察、可恢复的服务运行：API 与 CLI 可创建 Agent、发送消息，事件可以流式传回；每一步写入 Postgres，使工作进程重启后有机会从已保存状态继续。
机器是 Agent 可调用的执行环境。官方 README 描述了安装 omnarad 的 macOS/Linux 机器，也支持连接外部沙箱；机器端主动连回平台，因此其架构不要求为 Agent 命令执行开放入站端口。权限规则可以让工具调用直接执行、等待人工批准或被阻止。务必把“可审批”理解为控制面能力，而不是默认所有操作安全：生产部署仍须按实际威胁模型限制权限、密钥和网络访问。
先用 Compose 看清自托管边界
官方快速开始给出的本地启动方式如下：
git clone https://github.com/omnara-ai/omnara.git cd omnara docker compose -f compose.yaml --profile app up -d
随后访问 http://localhost:8000 完成注册。新实例不会自动拥有模型或机器，需要在控制台添加模型提供方与模型、连接机器，并把它们授权给项目。CLI 指向本地实例并登录：
npx omnara config --api-url http://localhost:8000/api/v1 --issuer-url http://localhost:8000 npx omnara login
这些是开发/试用起点，不是生产部署清单。项目 README 明确提醒本地默认配置有意不安全；上线前应依照自托管部署与配置文档处理外部访问、认证、密钥及基础设施设置。文档还指出，开发环境的验证链接可以从 API 容器日志查看；不要把这一便利设置当成生产邮件配置。
用 YAML 描述 Agent，再由 CLI 启动
云端 Quickstart 展示了一个简化的 Agent 配置。示例中的 provider 和机器池名称是云端示例值，不应原样假设在自托管实例中存在：
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
保存为 agent.yaml 后，可用 Node.js 22 或更新版本的环境运行 README 中的启动命令：
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 在终端继续交互，也能在仪表盘观察工具调用并回复。若改用自托管实例，应按实例实际配置替换模型和机器名称；项目说明要求将云端的 machine_pool_name 改为已连接机器对应的 machine_name。
值得采用的工程边界
第一，把状态持久化与执行环境分开考虑。Postgres 保存 Agent 的事件与状态，机器负责命令和文件操作；机器断线不等于状态记录消失，但任务是否能顺利继续，仍取决于配置、工具副作用和外部服务。
第二，采用最小权限。只给项目共享所需的模型、机器、MCP 服务器和密钥；对写入、部署、删除等工具配置人工审批或阻断规则。持久化记录便于审计，也意味着敏感输入、工具输出和附件可能进入自有存储，须制定保留与访问策略。
第三，先验证恢复路径再谈规模化。做一次工作进程重启、机器断连和审批等待测试，观察事件是否可读、任务能否恢复以及重复执行是否会造成副作用。README 描述了状态持久化与可恢复设计，但这不替代对你自己的任务幂等性测试。
适合谁
如果你要把长任务 Agent 接入内部产品、Slack、GitHub 或定时流程，并希望自己选择模型、机器和数据存储，Omnara 提供了一个可检查的控制面起点。若需求只是单机脚本，单独使用 SDK 或现有框架可能更轻；若不愿运维数据库、队列与存储，则云服务更省事。自托管换来的是部署控制权，同时也把升级、备份、监控和安全责任交还给团队。