将 Claude Code、Codex、Gemini 集成到同一浏览器工作台：Hive 开源了

作者：袖梨 2026-07-08

最近我一直在想一个问题：当 Claude Code、Codex CLI、Gemini CLI、OpenCode 这些工具都越来越能写代码之后，真正影响体验的可能已经不是“哪个模型更聪明”，而是外面那层工作台。

也就是：任务怎么拆？谁在写？谁在 review？终端输出去哪看？diff 怎么收敛？中途断了怎么接着跑？

于是我做了一个开源项目：Hive。

Hive 的定位很简单：浏览器里的本地多 Agent 协作工作台。它不替代 Claude Code / Codex / Gemini / OpenCode，而是把它们当成真实的 CLI 进程组织起来，让它们像一支小队一样在你的本机项目里协作。

GitHub：github.com/tt-a1i/hive
官网：hivehq.dev/

img_6a4da673d250830.webp

它解决的不是“又一个聊天框”问题

现在很多 AI Coding 工具的问题不是不够强，而是强了之后反而更难管。

比如我自己经常遇到这些场景：

  • 一个终端里跑 Claude Code，另一个终端里跑 Codex，再开一个窗口看测试；
  • 一个 agent 在实现功能，另一个 agent 想做 code review，但上下文和任务状态全靠我手动搬；
  • 长任务跑了半小时，中间到底做了什么，只能翻 scrollback；
  • 想让多个 agent 分工：一个写代码，一个查资料，一个跑测试，一个审 diff，但缺少一个“团队协作层”。

单个 CLI agent 很像一个能力很强的同事，但如果你同时叫来四五个同事干活，总得有白板、有任务清单、有状态、有汇报机制。

Hive 做的就是这层。

Hive 的核心想法

Hive 里有两类角色：

  1. Orchestrator：负责拆任务、派活、收集进展；
  2. Worker：负责具体执行，比如 coder、reviewer、tester，或者你自定义的任何角色。

关键点是：这些角色都不是“模拟出来的子 agent”。它们是真实跑在你电脑上的 CLI 进程。

比如 Orchestrator 可以是一个真实的 claude 进程，Worker 可以是真实的 codex、opencode、gemini 进程。Hive 给每个进程分配真实 PTY，然后在它们的 shell 里注入一个小型 team 协议，让它们可以互相派单、汇报、查看任务。

它大概怎么工作

简化一下，Hive 的结构是这样：

浏览器 UI：任务、团队、终端、汇报
        |
        | HTTP + WebSocket
        v
Hive Runtime：SQLite 元数据、PTY 生命周期、任务调度
        |
        +-- Orchestrator PTY  例如 claude
        +-- Worker PTY        例如 codex
        +-- Worker PTY        例如 opencode
        +-- Worker PTY        例如 geminiworkspace 里的任务图：
<workspace>/.hive/tasks.md

这里有几个设计我自己比较在意：

  • 本机优先：Runtime 只监听 127.0.0.1，不做云端托管；
  • 真实 PTY：agent 不是 API mock，也不是网页里的假终端，而是真 CLI；
  • 任务图是 Markdown：核心任务状态落在 <workspace>/.hive/tasks.md，你可以直接在编辑器里看；
  • 不绑定某一家模型：Claude Code、Codex、OpenCode、Gemini 都可以接，自定义命令也可以；
  • 不替你做 sandbox：它是工作台，不是安全沙箱。Worker 具有你本机 shell 的权限，所以只应该打开你信任的 workspace。

一个典型使用流程

假设我有一个项目要改一个比较复杂的功能，我会这样用 Hive：

  1. 选择本地项目目录作为 workspace；
  2. 启动一个 Orchestrator，比如 Claude Code；
  3. 添加几个 Worker，比如 coder、reviewer、tester；
  4. 跟 Orchestrator 说清楚目标；
  5. Orchestrator 用 team send 把任务派给不同 Worker；
  6. Worker 做完后用 team report 回报；
  7. 我在一个浏览器窗口里看终端、任务状态、汇报和后续 review。

这套流程的价值不是“让 AI 完全自动写完所有东西”。我反而觉得，人还是应该保留最后的判断权。

Hive 更像是把多个 CLI agent 的工作过程摆到台面上：谁在做什么，做到哪里，有没有卡住，哪些输出值得 review，都能在一个地方看见，每一个worker也都是可以打开的。

img_6a4da673d250e31.webp

安装方式

前置条件：

  • Node.js 22 或更新版本；
  • 至少装好一个 CLI Agent，并且已经登录、能在 PATH 上直接调用。

安装：

npm install -g @tt-a1i/hive
hive

启动后打开终端里打印出来的本机地址，通常是：

如果想指定端口：

hive --port 4010

升级：

hive update

如果你只是想先看一眼，不一定需要马上装 Claude Code 或 Codex。首次打开时可以试 Demo，里面有假 orchestrator、假 worker 和预录终端输出，适合快速判断这个工作流是不是你想要的。

它适合谁

我觉得 Hive 适合这几类人：

  • 已经在用 Claude Code / Codex CLI / OpenCode / Gemini CLI 的开发者；
  • 经常同时开多个终端跑 AI Coding 任务的人；
  • 想把“实现 / review / 测试 / 调研”拆给不同 agent 的人；
  • 喜欢本地优先、不想把整个开发工作流搬到云端的人；
  • 想研究多 Agent 协作形态，但又不想从零写 PTY、任务调度和 UI 的人。

它不太适合想要“打开网页，输入一句话，自动部署上线”的场景。Hive 不是 SaaS，也不是托管 agent 平台。它更像一个本地控制台，把你已经在用的 CLI agent 组织起来。

当前支持的 Agent 预设

目前内置了一些常用预设：

预设命令
Claude Codeclaude
Codexcodex
OpenCodeopencode
Geminigemini
自定义任意可执行文件

自定义命令这个点很重要，因为我不希望 Hive 变成只服务某一家模型或某一个 CLI 的壳。AI Coding 的工具层变化太快了，工作台应该尽量中立。

我为什么觉得这件事重要

过去我们讨论 AI Coding，经常把重点放在模型能力上：会不会写代码、能不能过测试、上下文够不够长。

这些当然重要。但当模型能力逐渐够用之后，新的问题会变成：

  • 工作流是否可观察；
  • 任务状态是否稳定；
  • 多个 agent 之间是否能协作；
  • 人类 review 是否被放在正确的位置；
  • 失败之后能不能恢复，而不是从头再来。

说白了，harness 会越来越重要。

Hive 现在做的还只是一个本地起点：真实 PTY、团队协议、任务图、浏览器工作台。后面我想继续往跨 agent 记忆、更多任务视图、review 流程、长期运行任务这些方向走。

如果你也在折腾 CLI agent、多 Agent 编排、AI Coding 工作流，欢迎试试，也欢迎提 issue。

GitHub：github.com/tt-a1i/hive
官网：hivehq.dev/
npm：www.npmjs.com/package/@tt…

img_6a4da673d251132.webp

相关文章

精彩推荐