Omnara 文档里那张对照表，我看了两遍。
三列：Claude Managed Agents、OpenAI Agents API、它自己。能力那几行写得很克制，重点在最下面——Claude Managed Agents 目前不在 Zero Data Retention 覆盖范围里，也没有 HIPAA BAA；OpenAI Agents API 不支持 ZDR，数据只落在美国。
一个开源项目把对手的合规缺口印进自己的文档。这个动作比后面几百行功能描述都说明问题。它没打算在“谁的智能体更聪明”上赢，那仗它打不赢。它打算在“这东西能不能签进采购合同”上赢。
这套打法我见过不止一次。2011 年 GitLab 从一份自托管的 Git 托管程序起步，那会儿 GitHub 已经是闭源 SaaS 了，它当年的卖点不是功能更多，是代码不出你的机房。Sentry 把错误追踪的服务端开源出去，靠的同一句话。Supabase 2020 年挂着“开源 Firebase 替代品”的牌子出来，头两年没几个人当真，直到 Google 那边动了几次 Firebase 的定价和配额，人才开始搬家。
三个例子，三种结局。这差别恰好能拿来量 Omnara 这一把能走多远。
GitLab 活下来了，活得不算差，但它从来没真正威胁过 GitHub。原因不复杂：代码托管这行的网络效应长在“人”这一侧，你同事都在 GitHub 上，自托管省的那点钱换不回同事。Sentry 的自托管版到今天还有人跑，可官方这些年一直在文档里劝人别自建，理由写得很好听——运维成本高、跨版本升级麻烦。这话不假，翻译过来是“自托管对我们不是好生意”。只有 Supabase 那一次，替代品是真真切切吃到了上位者的失误。
所以规律不是“自托管一定赢”，那是天命归式偷懒，我不买。规律是：自托管版能不能活，取决于上面那家公司有没有动力把自己这一层做死。GitHub 当年有，它要做社交编程，要把人锁进关系网里。Firebase 当年也有，它要绑住 GCP 的账单一头。
那 Anthropic 和 OpenAI 有没有？
这是我觉得 Omnara 在 2026 年值得看一眼的唯一理由，也是它跟前面那三个例子最大的不同。Claude Managed Agents 的计价是 token 费率加每活跃会话小时 0.08 美元。把 0.08 放在 token 账单旁边看，就是个零头。托管沙箱、会话时长这些收入，对一家卖 token 的公司来说，意义从来不在营收，在于把使用门槛压下去。它没有强烈动机为这一层楼跟自托管派打一场消耗战——打赢了多收不了几个钱，打输了还挡了自己卖 token 的道。
Omnara 自己的价目表反过来印证这个判断：平台费不收，自带模型 key、自带机器就免费，用平台的模型按 provider 的 token 价走，用平台的沙箱按活跃时间和保留的存储算。这不是一个要跟模型厂商抢饭吃的站位。这是在你楼下开小店，卖你不屑于卖的那几样。
但共存不等于赢。要看清它把注押在哪，得往结构里翻。
每一步都落库
第一个押点，是它把每个智能体的每一步事件都写进 Postgres。
这事儿听着像运维细节，其实是一整套东西的地基。因为每一步都落了库，进程崩了、机器断了、worker 重启了，任何一个 worker 捡起来都能接着往下跑——状态不在内存里，在表里。
这个思路一点都不新。六十年代的批处理系统就得会这一手，那叫 checkpoint/restart，机器要关机了先把中间状态存下来，开机接着算。八十年代 Condor 那类高吞吐计算系统把它做成了常规操作。上一轮把它产品化的是 AWS 的 Simple Workflow，然后是 Uber 的 Cadence，再然后是 Temporal 那一拨。所以“可恢复执行”本身不是 Omnara 的发明，它是把一个四十年前的老手艺搬到了智能体上。
搬过来的位置很讲究。它没有把历史存在自己的云上——自托管部署的时候，那些事件表就在你自己的 Postgres 里。于是同一份数据同时是三样东西：崩溃恢复的依据、审计日志、以及能拿来做评估和后续训练的数据集。前两样是可靠性设计，第三样是资产设计。这才是我认为它真正在卖的东西：智能体的 trace 是你的，不是平台方的。
这里有个陷阱我得承认。训练数据这个说法容易被说滑——智能体的 trace 到底有多少训练价值，取决于任务密度和质量，一大半跑出来的东西是噪声。但从“数据在哪”到“数据能不能用”这一步，起码得先有“数据在你手里”。
守护进程往外连
第二个押点更有意思：它把“机器”做成了一个工具，而不是一个运行环境。
具体做法是装一个叫 omnarad 的守护进程，你的 Mac、内网 VM、容器都行，然后它主动往平台那边连。注意方向——是它往外连，平台不需要连回来。没有入站端口，没有 SSH key，不用在防火墙上开洞。
这是 pull 模式。这套东西的正经谱系我印象里得追到九十年代 cfengine 那一路的配置管理，后来被 CI 发扬光大：GitLab Runner、GitHub Actions 的自托管 runner，都是 runner 主动去拉活儿，不是服务器推过来。原因很朴素——企业内网不许进，个人笔记本没有公网 IP。我推测 Omnara 在这上面还多占了一点便宜：既然连接方向永远是往外，那对平台侧来说“机器离线”和“机器不存在”就是同一件事，都是没心跳，迁移逻辑才能做得这么轻松。
不过这个老架子上它加了一手新的：机器是可替换的执行位置，不是身份的绑定。智能体能同时挂好几台机器，也能在机器之间迁移；笔记本合盖、掉线了，任务转到沙箱接着跑，结果用 git 同步回来。
这条因果链得说清楚，因为它是整篇里我认为最容易被看漏的一环：能迁移的前提是能恢复。 如果每一步没有落进 Postgres，“智能体换台机器接着干”就是句空话——上一台机器的上下文、工具调用的中间结果、半截的文件状态全丢了，你只能从头再来。所以 durable log 不是可靠性模块，它是移动性的前置条件。这两个设计本来就是一件事的两面，文档里分开写，读的时候得合起来看。
三种接口，够用就行
第三个押点小，但取舍很硬：它说“模型无关”，落地方式是只认三种接口格式——OpenAI 的 Responses、OpenAI 的 Chat Completions、Anthropic 的 Messages。你想接 Ollama、LiteLLM、Bedrock、还是自己机房里跑的推理服务，行，但你的端点得会说这三种话里的一种。
这是省事的做法，也是让步。省的是：不用为每一家 provider 写适配器，翻译层收敛成三种，新 provider 只要能伪装成这三种之一就自动被支持。让掉的是：provider 独有的那部分能力会被抹平——某些模型特有的缓存语义、思考预算、结构化输出的怪癖，穿过这层翻译之后剩不下多少。
这条我感情比较复杂。它肯定是对的，这会儿模型半年一换代，押注任何一家的私有接口都是给自己上枷锁。但“最小公约数”这个词在历史上从来不讨喜，它保住了可移植性，也注定了你够不到最好的那档能力。
这属于我个人的偏见，先撂下。
其余的部分，说实话，是清单，不是创见。shell、文件读写、网页抓取、向人提问的内置工具，接 MCP server，Skills 打包复用，跨会话的 memory store，能开子智能体并查看进度，工具调用分“直接执行 / 需人工批准 / 禁止”三态并强制执行，组织与项目两级 RBAC，Slack、Discord、GitHub 事件触发，webhook 和流式事件回传。这些零件没有一样是它发明的，它只是把一个 harness 该有的零件按清单摆齐了，摆得挺整齐。整齐这件事有独立价值——自托管平台的死法里，死于“少一个功能所以过不了评审”的，比死于 bug 的多得多。
那如果我前面那套“模型厂没动机做死这一层”的判断错了呢？
假设明年 Anthropic 把 Managed Agents 补上 ZDR 和 BAA，价格再往下压。Omnara 这套东西还剩什么？
反事实历史是廉价的，我一般不爱在这上面耗。但这一次推一下不亏，因为它能标出这条路的真实下沿——剩下的那部分是“你私网里的机器”“你自己 Postgres 里的 trace”“不装在公网上的凭据”。这三样东西，托管服务再怎么降价也给不了，因为它们的定义就是“不外包”。哪怕最坏的情况发生，它守的也不是一个会被价格战打穿的阵地。
但我得把话说回来：守住一个打不穿的阵地，和在市场上赢，是两码事。GitLab 的教训就在那儿摆着，十四年了。
所以回到今天。Omnara 这个项目最重要的问题不是“它能不能取代 Claude Managed Agents”——这问题问错了对象，它本来就不打算取代。值得记住的是它切的那条缝在哪：数据驻留、私有网络、以及“跑出来的东西归谁”。
这条缝在每一次托管层出现的时候都在同一个位置。2008 年 Google App Engine 出来，缝在“我的代码跑在哪”；2013 年前后 PaaS 混战，缝在“能不能自托管”；到了智能体这一层，缝挪到了“模型可以租，但执行轨迹不能租”。
缝的位置一次比一次靠上，一次比一次更接近数据本身。这是我觉得这回有点不一样的地方——以前自托管的筹码是合规，是那种你不得不做、做了也不涨分的成本项；现在多了一条，智能体的 trace 自己开始有价值了，它是评估集、是蒸馏材料、是下一轮的口粮。合规是守，资产是攻。
一个开源项目能不能靠这个攻出去，我不知道。但“这层楼早晚有人从底下凿一遍”这件事，过去十四年里没有一次落空。