Databricks开源Omni：统一管理所有AI Agent的元框架

为什么我们需要一个「元框架」？

如果你是一个活跃的AI开发者，你很可能同时在使用多个AI Agent——Codex、Claude Code、Pi等等。每个Agent都有自己的能力边界，但它们之间彼此隔离：不同的记忆、不同的UI、不同的会话历史。你就是那个在它们之间不断复制粘贴的「人肉中间件」。

这个问题的本质在于，每个Agent都是「模型+框架（Harness）」的组合。模型负责预测文本，而框架负责真正完成工作——包括Agent循环、工具调用、记忆管理和用户界面。在大语言模型（LLM）的原始形态中，模型本身只能根据输入文本预测下一个token，并不具备执行实际操作的能力。Harness（有时也称为Agent Runtime或Agent Framework）是包裹在模型外层的执行环境，它实现了Agent循环（即"思考-行动-观察"的ReAct循环）、工具调用协议（如Function Calling）、上下文窗口管理、文件系统访问和沙箱隔离等功能。目前主流的Agent框架包括LangChain、AutoGen、CrewAI等开源方案，以及Codex CLI、Claude Code等商业产品内置的专有框架。每个框架在工具注册方式、记忆持久化策略、并发模型等方面都有不同的设计选择，这正是导致Agent之间互不兼容的根本原因。

Codex、Claude Code、Pi，每一个都是不同实现的框架，但它们有一个关键的共同点：对外接口完全一致——输入是消息和文件，输出是文本和工具调用。

既然接口一致，为什么不在所有框架之上再建一层？这就是「元框架（Meta-Harness）」的核心思想。Databricks刚刚以Apache 2.0协议开源的Omni项目，正是这一理念的落地实现。

Omni的核心架构：一个屋檐下的所有Agent

统一会话：一个Session，多个入口

Omni最直观的价值在于统一会话管理。会话存在于元框架层而非具体工具层，因此只有一个Session对象——包含你的Agent文件和完整历史。无论你通过终端、Web浏览器、桌面应用、移动端还是REST API访问，看到的都是同一个会话状态。

你可以在终端启动一个任务，切换到浏览器继续操作，甚至在手机上查看进度。同一个Agent、同一套文件，只是不同的窗口——而且它们实时同步。对于需要在不同设备间切换工作的开发者来说，这带来了显著的效率提升。

三大核心能力概览

Omni在底层由三个关键模块组成：左侧是你带入的各种Agent，右侧是你要使用的应用和工具，中间是统一的编排层。它解锁了三大核心能力：组合、控制和协作。

组合能力：Agent即配置，一行YAML切换框架

在Omni中，一个Agent就是一个简短的YAML文件，包含提示词、工具列表和框架选择。这种做法借鉴了DevOps领域「基础设施即代码（Infrastructure as Code）」的理念。YAML（YAML Ain't Markup Language）是一种人类可读的数据序列化格式，广泛用于Kubernetes、Docker Compose、GitHub Actions等工具的配置文件中。将Agent定义为声明式配置文件意味着Agent的行为完全由版本可控的文本文件描述，而非硬编码在程序中——配置可以纳入Git版本管理、支持代码审查流程、便于团队共享和复现，以及实现Agent的动态组合与热切换。

从Claude切换到Codex，只需改一行配置。你甚至可以同时运行多个Agent作为一个团队，Agent还能编写Agent——你只需描述需求，它就能自动生成配置文件。

Omni预置了两个非常实用的Agent：

Polly（技术负责人）：Polly本身不写代码，它负责规划和任务分解。它会将目标拆分为子任务，分配给不同的编码Agent并行执行（使用独立的Git工作树），然后将每个Agent的代码交给另一个供应商的Agent来审查。

这里值得展开说明两个关键设计。首先是Git工作树（Worktree）的运用：Git Worktree是Git 2.5引入的功能，允许从同一个仓库同时检出多个工作目录，每个工作目录对应不同的分支。多个工作目录共享同一个.git对象数据库，但各自拥有独立的工作区和索引。在多Agent编排场景中，这意味着每个编码Agent可以在自己的工作树中独立修改代码，互不干扰，最终通过Git的合并机制将成果整合，避免了Agent之间的文件冲突，是实现真正并行编码的基础设施保障。

其次是跨供应商交叉审查的工程意义。比如Claude Code写的代码由Codex审查，Codex写的代码由Claude审查。这种跨供应商交叉审查只有在元框架层才能实现——你不希望写代码的Agent审查自己的代码，因为它存在内在偏见。研究表明，当同一个模型被要求评估自己生成的内容时，它倾向于给出更高的评分，因为生成和评估共享相同的内部表征和偏好模式。通过让不同供应商的模型（如Anthropic的Claude和OpenAI的Codex）互相审查，可以引入真正的认知多样性：不同的训练数据、不同的对齐策略、不同的架构偏好，使得审查过程更可能发现盲点和潜在问题。这种模式在传统软件工程中类似于引入外部安全审计团队，其价值在元框架层得到了自动化实现。

Debbie（头脑风暴伙伴）：Debbie同时调用Claude和GPT，每个问题都会得到两个并行的回答。输入/debate命令后，两个模型会互相批评对方的观点，经过几轮辩论后趋于收敛。这对于架构决策等需要多角度思考的场景非常有价值。

控制能力：安全策略的强制执行

每个操作都必须通过一个门控机制：允许、拒绝、或先询问用户。这不是提示词中的「礼貌请求」，而是在每次工具调用时强制执行的策略。

因为策略存在于元框架层，规则可以依赖于历史上下文。你可以设置：

• 成本上限：为每个会话或每个用户设置每日预算（比如10美元），并定义软警告阈值
• 风险控制：拒绝涉及PPI（个人隐私信息）的请求
• 文件和仓库范围：限制Agent只能访问特定目录
• 工具和连接器的访问权限

在底层，所有Agent都运行在OFlix沙箱中，只能接触你明确授权的文件和网络。这一设计体现了零信任安全架构（Zero Trust Architecture）在AI Agent领域的应用。在传统的Agent执行模式中，API密钥通常以环境变量或配置文件的形式直接暴露给Agent进程，这意味着一个被恶意提示注入（Prompt Injection）攻击的Agent可能泄露敏感凭证。

Omni的设计采用了类似于Kubernetes中Secret管理和Sidecar代理模式的思路：Agent本身运行在受限的沙箱环境中，无法直接访问密钥；当Agent需要调用外部API时，请求先经过元框架层的审批代理（类似于服务网格中的Envoy代理），由审批代理在请求的最后一刻注入必要的认证信息。更关键的是，Agent永远无法直接读取你的密钥——元框架层通过审批代理在请求发出时注入密钥。这种「最小权限原则」的实现确保了即使Agent被攻破，攻击面也被严格限制在沙箱边界内。即使你在YOLO模式下运行，安全性也远高于直接将密钥交给Agent。

协作能力：实时共享与会话分叉

当你的会话处于活跃状态时，你可以分享一个链接，队友可以实时观看工作进展，甚至直接在会话中交互。这本质上是AI Agent层面的「结对编程」。如果队友想走不同的方向，可以直接fork会话，独立探索而互不干扰。

会话分叉功能将Git的分支模型引入了AI交互领域。在传统的AI对话中，会话是线性的——你只能在当前对话的末尾继续。会话分叉允许从对话历史的任意节点创建一个独立副本，在不影响原始会话的情况下探索不同的方向。这个概念在学术界被称为「对话树」（Conversation Tree），在协作场景中尤为重要：团队成员可以从同一个决策点出发，分别探索不同的技术方案，最终比较各分支的结果来做出最优选择。这种模式本质上是将软件工程中成熟的版本控制和分支管理实践迁移到了AI辅助工作流中。

实战演示：从安装到多Agent编排

快速上手

安装只需一条命令。安装完成后，首先配置你的API密钥或订阅——可以使用Claude Code订阅、Codex订阅，Pi甚至可以使用本地的Ollama模型。

多Agent编排实战

在演示中，作者使用Polly Agent创建了一个使用Gemini Nano模型进行图像生成的Web应用。整个流程如下：

1. 任务分解：Polly接收需求后，自动将任务分解为子任务
2. 并行实现：Claude Code负责代码实现，在独立的Git工作树中工作
3. 独立审查：实现完成后，Codex对代码进行独立审查，只传递diff而非完整代码
4. 问题修复：Codex发现了具体问题，反馈给实现Agent修复
5. 再次测试：修复后自动重新测试

整个过程中，终端和Web UI显示完全相同的会话内容，你可以在任意界面查看每个Agent的实时工作状态。会话结束后，你还能看到详细的成本分析——每个模型消耗了多少Token，总花费多少。

说个细节，你可以在编排过程中随时直接与特定Agent交互。比如Codex正在审查代码时，你可以单独去问Claude Code一个问题，互不干扰。

为什么元框架层至关重要？

当前AI领域的一个核心痛点是供应商锁定。如果你在某个框架上构建了大量Agent逻辑，当更好的模型或更强的框架出现时，你需要重新搭建所有管道，迁移成本极高。

Omni的元框架思路将Agent变成了可互换的工作单元。每个框架都是一个插件，切换成本降到最低。这不仅解决了当下的多Agent协同问题，更为未来的技术演进提供了缓冲层。这种设计哲学与软件工程中的「依赖倒置原则」一脉相承——高层模块不应依赖低层模块，两者都应依赖抽象。在Omni的语境中，你的工作流和业务逻辑（高层）不再直接依赖于某个具体的Agent框架（低层），而是依赖于元框架提供的统一抽象接口。当底层的模型能力发生跃迁——比如新一代模型在代码生成上大幅超越现有方案——你只需在YAML配置中替换框架选择，而无需重构整个工作流。

项目目前仍处于早期阶段，可能需要一些调整和适配，但作为Apache 2.0开源项目，社区驱动的迭代速度值得期待。对于任何同时使用多个AI Agent的开发者和团队来说，Omni都是一个值得密切关注的项目。

核心要点