一个界面搞定三大 AI 编程工具:Bifrost CLI 实战-夜雨聆风

一个界面搞定三大 AI 编程工具:Bifrost CLI 实战

Claude Code 已经成为软件开发领域最受关注的工具之一，而 Codex 和 Gemini 也进入了许多开发者的日常工具箱。问题在于，一旦你开始同时使用多个工具，搭建成本会很快显现出来。

不同的认证流程、不同的 base URL、不同的模型假设以及不同的配置方式，会让整体体验比应有的更割裂。Bifrost 在其 CLI-agents 文档中将产品定位为解决这类碎片化问题：通过网关（gateway）为受支持的 agents 提供 universal model access（通用模型访问），并支持 MCP 集成与可观测性（observability）。

这正是【Bifrost CLI】(https://docs.getbifrost.ai/quickstart/cli/getting-started) 吸引我的地方。

与其把 Claude Code、Gemini 和 Codex 当作三个独立的终端工作流，[Bifrost CLI](https://docs.getbifrost.ai/quickstart/cli/getting-started) 让我从一个界面统一启动它们，并把一切流量路由到 Bifrost 网关。根据官方文档，Bifrost CLI 围绕交互式的初始化流程构建：你选择网关、harness（运行壳/适配层）、模型，然后无需手动拼接配置即可启动会话。

更广义的 Bifrost agent 文档也明确指出，这不仅仅是“在一个地方打开多个工具”，更是“通过同一个网关支撑的工作流，在受支持的 agents 上使用不同的 provider/model 组合”。

在这篇文章里，我将演示我如何用【Bifrost CLI](https://docs.getbifrost.ai/quickstart/cli/getting-started)】从一个界面同时使用 Claude Code、Gemini 和 Codex，以及为什么更有趣的不只是多 agent 访问，而是在同一工作流中更灵活地思考 agent choice（agent 选择）与 model choice（模型选择）。

1. 为什么我想要一个统一界面来使用 Claude Code、Gemini 和 Codex？

过去几个月里，AI 编码 agents 已经成为我开发工作流中的关键部分，也走进了许多开发者的工作方式。【Claude Code】备受关注，目前处于领先地位。【Codex】对于喜爱 OpenAI 生态的开发者仍然是熟悉的选择，【Gemini CLI】也逐渐成为希望在终端里拥有强力编码助手的人的选项之一。

问题在于，同时使用多个编码 agents 通常意味着要面对多种不同的安装与配置方式。

每个工具往往自带关于认证、base URL、模型选择和配置的各自假设。即便每一种设置都不算复杂，一旦你要在工具之间切换，或在真实工作中测试不同的“模型+agent”组合，这些摩擦就会迅速叠加。

这正是我觉得 Bifrost CLI 有意思的地方。

吸引我的并不仅仅是“用一个命令启动不同的编码 agents”。更有意思的是，【Bifrost】通过其网关站在这些 agents 之前，这意味着工作流不仅是“在 Claude Code、Gemini 和 Codex 间切换”，也包括“更灵活地从一个界面选择与路由模型”。Bifrost 官方称其为 universal model access（通用模型访问）：在 Bifrost 中配置的任何 provider 或模型，都可以与受支持的 agents 搭配使用。

对我来说，Bifrost CLI 的吸引力很简单：不再把 Claude Code、Gemini 和 Codex 当成彼此完全独立的终端环境，而是将它们视为同一工作流的一部分。

这将问题从：

“我该用哪个编码 CLI？”

变成更务实的：

“如何在不同编码 agents 与 models 之间切换，而不必每次都重新配置一切？”

这就是我想在这篇文章里探索的思路，并一步步展示如何做到。

2. 什么是 Bifrost，以及为什么网关很重要

在谈 [Bifrost CLI](https://docs.getbifrost.ai/quickstart/cli/getting-started) 本身之前，先弄清楚 Bifrost 到底是什么会更有帮助。

【Bifrost】是一个 AI 网关（AI gateway）。简单说，它位于你的应用或工具与底层模型提供商之间。与其把每个工具分别直连到每个 provider，Bifrost 在前面提供一层统一抽象。【官方文档】将其描述为面向多家提供商的、与 OpenAI 兼容的 AI 网关，并支持可观测性（observability）、治理（governance）、缓存（caching）、故障切换（failover）与负载均衡（load balancing）等能力。

这点很重要，因为 Bifrost CLI 并不是一个自带模型系统的“独立魔法外壳”。它的工作方式是将编码 agents 连接到你已经运行的 Bifrost 网关上。

Bifrost CLI 入门

在 CLI 快速入门中，流程从先启动 Bifrost 网关开始，通常是：

npx -y @maximhq/bifrost

这会在本地启动网关，默认监听 http://localhost:8080。然后在另一个终端里启动 CLI：

npx -y @maximhq/bifrost-cli

安装完成后，你就可以在新终端里直接运行：

bifrost

运行之后，你需要已经安装并能正常运行 Claude Code、Gemini CLI 和 Codex CLI，才能通过它们进行工作。

如果尚未安装，可以按以下步骤快速安装：

安装 Claude Code：

curl -fsSL https://claude.ai/install.sh | bash

安装完成后，启动命令：

claude

安装 Codex CLI：

npm install -g @openai/codex

安装完成后，启动命令：

codex

安装 Gemini CLI：

npm install -g @google/gemini-cli

安装完成后，启动命令：

gemini

需要注意的是：你需要为每个 LLM 提供商准备 Pro 订阅，或者为每个模型提供 API key，方可使用。现在回到 Bifrost CLI，在新终端中启动：

bifrost

启动后，你可以选择要使用的编码 agent。我先从 Claude Code 开始：

这里真正的价值并非只是能在一个界面里打开 Claude Code、Gemini 和 Codex，而是它们都能接入同一控制层。这为更灵活的工作流打开了大门，比如模型访问、可观测性以及 agent 配置。

你可以这样理解：

Bifrost 网关

= 路由与控制层
Bifrost CLI

= 通过该网关启动编码 agents 的交互式工作流层

有了这个划分，后文会更容易理解。

3. Bifrost CLI 的不同之处

通常我想试某个编码 agent，总会遇到一些配置摩擦。可能涉及环境变量、针对特定 provider 的 base URL、API key、模型配置，或按 agent 不同的安装步骤。

Bifrost CLI 用一个交互式流程替代了大量重复工作：我只需运行一个命令，选择我的设置，让 CLI 处理其余部分。文档把它描述为“一个交互式终端工具，将编码 agents 连接到 Bifrost 网关，无需手动配置”。

实际使用中，我会先启动 CLI：

bifrost

接着，Bifrost CLI 会引导我完成一套设置流程，包括网关 URL、可选的 Virtual Key（虚拟密钥）、要使用的 harness（运行壳/适配层）以及要启动的模型。根据官方入门文档，CLI 会为每个受支持的 agent 自动配置 base URL、API key、模型设置，从网关的 /v1/models 端点获取可用模型，并在需要时通过 npm 安装缺失的 agents。

我还喜欢的一点是：体验并不会在第一次启动后就结束。Bifrost CLI 提供的是一个持久化的标签式终端 UI。入门材料描述为“一标签对应一个运行中或最近的会话”，并带有活动徽标，显示会话是否在更新、空闲或有告警。这让它更像是真正的工作流层，而不是一次性启动器。

还有一个值得一提的实用安全细节：CLI 会将 Virtual Key 存储在操作系统的 keyring（密钥环）中，而不是明文配置文件；同时把 base URL、harness、model 等通用默认项写入 CLI 配置。这样的拆分很合理：把可复用的工作流状态保存在手边，但不要把机密明文存放。

所以我对 Bifrost CLI 的最简描述是：

给我一个进入 Claude Code、Gemini 和 Codex 的统一入口
让我在同一流程中选择模型
移除了大量重复的配置摩擦
通过持久化工作流，使切换会话更自然

这使它不再只是“启动一下工具就退出”的简单外壳，而是一个真正的工作流平台。

4. 通过 Bifrost CLI 使用 Claude Code

在 Bifrost CLI 中从 Claude Code 入手是很好的选择，尤其因为它是目前备受开发者关注的编码 agent。

我喜欢的是，我不再需要把 Claude Code 当作一个独立、需要手动配置的环境。相反，我启动 Bifrost CLI，选择 Claude Code 作为 harness，选好模型，并在交互式终端界面里更新其余会话设置即可。

此处流程是：

npx -y @maximhq/bifrost

然后在另一个终端里：

bifrost

当 [Bifrost CLI](https://docs.getbifrost.ai/quickstart/cli/getting-started) 打开后，我可以直接在终端界面里配置会话。正如启动页所示，我可以查看/修改 Base URL、Harness、Model、Virtual Key（从 Bifrost 获取） 与 Worktree，而无需编辑配置文件或手动导出环境变量。

这是体验中的关键：与其亲自把 Claude Code 的每一步都接好，Bifrost CLI 把设置变成引导式的启动流程。在这个界面中，我可以按：

u

：修改 base URL
v

：新增或更新 Virtual Key
h

：切换 harness
m

：选择不同模型
w

：为 Claude Code 启用 worktree
Enter

：启动

这也是为什么在本文中用 Claude Code 作为“锚点”很合适。它本就有很强的开发者关注度，而 Bifrost CLI 让围绕它的工作流更顺滑。我仍然在用 Claude Code 作为编码界面，但通过一个能在路由与模型选择上提供更大灵活性的中间层来使用。

这种灵活性才是更大的看点。Bifrost 文档把它称为 universal model access（通用模型访问），意味着 agent 界面与底层模型不必强绑定。因此，与其把 Claude Code 当作“固定配置”，我更把它当成“我想使用的界面”，而模型层的选择与路由交给 Bifrost。这比传统的“单 agent 启动”更有意思。

我还喜欢的另一个细节是：Claude Code 在 Bifrost CLI 里不只是“启动”那么浅。CLI 支持 Claude Code 的 worktree 模式（适合我隔离功能分支或并行任务时用）。文档也提到 Bifrost 可以自动为 Claude Code 附加其 MCP 服务器，使集成更进一步。

实际中，我通过 Bifrost CLI 使用 Claude Code 的流程如下：

启动 Bifrost 网关
运行 bifrost
确认选择 Claude Code 作为 harness
在 Bifrost CLI 界面中选择模型
在同一个终端 UI 中调整需要的设置
按 Enter 启动

按下回车启动后，Claude Code 会通过 Bifrost 启动（如上图所示），你就可以照常使用它了。接下来看看如何用 Codex 做同样的事。

5. 通过 Bifrost CLI 使用 Codex

当 Claude Code 已能通过 Bifrost CLI 正常工作后，下一步就是 Codex。这时，“一个界面”的故事更有说服力，因为我不仅是在复用相同的启动流程来运行另一个编码 agent。

我也在复用同一个“由网关支撑的模型工作流”。Bifrost 的 Codex 文档描述了 Codex CLI 如何通过 Bifrost 的 OpenAI-compatible（兼容 OpenAI 的）端点工作，同时仍然能通过 Bifrost 的翻译层访问其他 providers 的模型。

在手动配置中，Codex 通过将其 base URL 指向 Bifrost 的兼容端点，并通过 OPENAI_API_KEY 提供 Bifrost Virtual Key 来完成配置。文档给出的 base URL 是 http://localhost:8080/openai/v1，模型在 codex.toml 中配置。

但在本文中，我依然更喜欢走 Bifrost CLI 这条路径，原因与 Claude Code 相同：能保持工作流的一致性。

我无需直接编辑 Codex 的配置文件，而是打开同一个 Bifrost 终端 UI，把 harness 切到 Codex，选好模型，从同一个交互式界面启动。这更符合本文“从一个界面使用 Claude Code、Gemini 和 Codex”的主题，而不是维护三套独立配置。

Codex 在这个设置里尤其有用的一点是：Bifrost 并不把它限定在 OpenAI 托管的模型上。Codex 文档明确表示 Bifrost 会将请求翻译给其他 providers，并展示了用如下模型启动 Codex 的例子：

codex - model anthropic/claude-sonnet-4–5–20250929
codex - model gemini/gemini-2.5-pro

这清楚地说明：Bifrost 不只是个简单启动器。Codex 仍是 agent 界面，但底层模型可以来自其他 provider，并通过同一个由网关支撑的工作流运行。

小结一下，使用 Codex 的步骤很简单：

打开同一个 Bifrost CLI 界面
将 harness 切换为 Codex
选择如 anthropic/claude-sonnet-4–5–20250929 这样的模型
在就绪界面上直接启动

Choosing codex as the Harness while keeping the Claude Sonnet model.

接着，你就可以通过 Bifrost CLI 启动 Codex，同时使用 anthropic 的 Claude Sonnet 模型，十分妙！

Codex runs inside the same persistent Bifrost CLI workflow used for Claude Code, which keeps the experience consistent across agents.

一个小而实用的提醒：Codex 文档提到 Codex 更偏好 OAuth 而不是自定义 API keys，建议在为 Bifrost 网关配置 Codex 前先运行 /logout。此外，使用非 OpenAI 模型时，这些模型需要支持 Codex 期望的 tool-use（工具调用）能力。这是很有用的注意事项，能让文章更务实也更诚实。

6. 通过 Bifrost CLI 使用 Gemini

当我走到 Gemini 时，Bifrost CLI 的价值就更加直观了。

我不需要再学第三套设置，也不用管理一套单独的配置路径。我仍然使用同一个 Bifrost 界面、同一个启动流程、同一个模型选择工作流。唯一变化的是 harness。

这才让人感觉这真是“一个界面”，而不是“三个互不相干的工具”。

实际操作很简单：打开 Bifrost CLI，把 harness 切到 Gemini，选好模型，然后在与之前启动 Claude Code 和 Codex 完全相同的终端界面中启动。

# 终端 1
npx -y @maximhq/bifrost

# 终端 2
bifrost

然后按 h 将 harness 切换到 Gemini，按 m 选择模型，按回车启动。

Switching to Gemini happens inside the same Bifrost terminal workflow used for Claude Code and Codex.

这也让 Bifrost 的“大图景”更清晰。根据官方 Gemini CLI 文档，一旦把 Gemini CLI 通过 Bifrost 路由，所有 Gemini CLI 的流量都会经过 Bifrost 网关，因此可以访问该 Bifrost 设置中配置的任意 provider/model，并获得可观测性与治理能力。

这意味着 Gemini 并不限于谷歌托管的模型。Gemini CLI 文档明确展示了 Bifrost 的请求翻译能力，因此可以用 provider/model-name 的格式运行来自其他 providers 的模型，例如 openai/gpt-5 与 anthropic/claude-sonnet-4-5-20250929。

不过有个需要诚实说明的前提：Gemini CLI 文档指出，非 Google 的模型必须支持 tool use（工具调用），Gemini CLI 依赖该能力来进行文件操作、终端命令与代码编辑。因此虽然工作流很灵活，但兼容性仍然重要。

话虽如此，整体体验正是我想要的：我能保留同一个 Bifrost 界面，几次按键就切换到 Gemini，选好模型，然后顺畅继续工作，而无需从零重建工作流。

7. 面向 agents 与 models 的统一界面

在通过 Bifrost CLI 使用了 Claude Code、Codex 与 Gemini 之后，我最大的体会是：真正的价值不只是“把多个编码 agents 放在一起”。

更重要的收益在于：Bifrost 给了我一个同时跨越 agents 与 models 的统一界面。

这听起来像个小区别，但确实改变了工作流。

通常，编码 agents 与模型往往是强绑定的：Claude Code 往往对应某一类模型，Codex 对应另一类，Gemini 也有自己的默认预期。一旦走 Bifrost，这种绑定关系会更灵活：我交互的编码 agent 与真正服务请求的模型，不一定要像过去那样固定匹配。Bifrost 文档明确把这称为在受支持 agents 间的 universal model access（通用模型访问）。

这就是为什么我认为用“一个界面”来描述 Bifrost CLI 是恰当的。

它不只是“一条命令启动不同工具”，而是一个一致的流程，用于：

选择编码 agent
选择模型
在不重建设置的前提下改变这些选择
在同一个终端工作流中在不同会话间切换

实际中，这意味着我可以因为喜欢 Claude Code 的界面而使用它；当我想对比行为时切到 Codex；或在不从头开始的情况下转到 Gemini。同时，我可以将模型选择当作一个独立决策来思考。相比把每个 agent 都当作“孤岛”，这要实用得多。

这也让 Bifrost 比“简单启动器”更有意义。

启动器也许能省几个按键，但 Bifrost 做的是更有用的事情：把网关变成 agents 底下的控制层。这让在保持工作流一致性的同时，能更灵活地选择 provider 与 model。Bifrost 总览把网关描述为立于 providers 之前的统一层，具备可观测性与治理等特性；CLI-agent 文档展示了受支持的编码 agents 如何插到这一层里。

对我而言，这带来三点实际收益：

更容易在同类工作上比较不同 agents 的行为。无需分别搭建每个工具，我能在同一界面里在 Claude Code、Codex 与 Gemini 之间移动，把精力放在它们的表现上。
更容易试验不同模型的选择。想在某个编码 agent 里试别的模型？Bifrost 让这看起来就是工作流的常规一环，而不是另起一个集成任务。Codex 与 Gemini 文档都明确展示了通过 Bifrost 进行跨 provider 的模型示例，总览也对 Claude Code 表达了同样思路。
随着时间推移，降低配置摩擦。即使配置并不难，跨工具重复设置也会令人厌倦。Bifrost CLI 以单一交互式流程、可记忆的设置以及为重启/切换会话而设计的持久化终端 UI 来替代。

若要用一句话概括更大的价值，那就是：

Bifrost CLI 不只是在一个地方启动 Claude Code、Gemini 与 Codex——它给了我一个能更自由混搭 agent choice 与 model choice 的统一工作流。

这使得这套方案不只是“方便”，而是“真正有用”。

在通过 Bifrost CLI 使用了 Claude Code、Codex 与 Gemini 之后，我最大的收获是：它带来的价值远超“方便”。

Bifrost CLI 真正改变的是工作流——我不再为每个编码 agent 维护一条独立的配置路径，而是在一个界面里工作，并把底层的路由层交给 Bifrost 网关。这让跨 agent 切换更容易、试验不同模型组合更轻松、整体体验更一致。Bifrost 文档将其描述为 universal model access（通用模型访问），在我把它用于这三个 agents 后，这种表述非常贴切。

如果你已经对 Claude Code 感兴趣，同时也希望能在同一个终端工作流里灵活使用 Gemini 与 Codex，那么 Bifrost CLI 会让这套方案更可行。

目录

1. 为什么我想要一个统一界面来使用 Claude Code、Gemini 和 Codex？

2. 什么是 Bifrost，以及为什么网关很重要

Bifrost CLI 入门

3. Bifrost CLI 的不同之处

4. 通过 Bifrost CLI 使用 Claude Code

5. 通过 Bifrost CLI 使用 Codex

6. 通过 Bifrost CLI 使用 Gemini

7. 面向 agents 与 models 的统一界面