LobeHub 支持异构 Agent：本地同时调 Claude Code 和 Codex

产品更新

LobeHub v2.1.56 正式支持 Heterogenous Agents，可在桌面端直接集成 Claude Code 和 Codex，实现不同 Agent Harness 共享统一接口和上下文，为多 Agent 协作和任务调度打下基础。

LobeHub 支持异构 Agent：本地同时调 Claude Code 和 Codex

LobeHub 在 v2.1.56 版本中正式支持 Heterogenous Agents（异构 Agent），这意味着你可以在 LobeHub 桌面端直接集成使用 Claude Code 和 Codex，而不需要在不同工具之间来回切换。只要本地安装了这些工具的 CLI，打开 LobeHub 后点击添加对应助手，就能立即开始工作。

这个功能看起来是个简单的集成，但背后的架构设计值得关注。LobeHub 团队把它称为「异构 Agent」，本质是让不同的 Agent Harness 共享同一套 interface 和 context。这种设计不仅解决了当下的工具切换问题，更为未来的多 Agent 协作和任务调度系统打下了基础。

LobeHub 桌面端添加 Claude Code 和 Codex 助手的界面截图

什么是异构 Agent

从 LobeChat 时代开始,LobeHub 团队就把 Agent 视为 AI 时代的一等公民。早在 2023 年的 0.x 版本,他们就做了左侧 Agent List、右侧 Topic List 的设计,这在当时算是超前的。随着 2024 年 Agent 的大爆发,产品也从 LobeChat 转型为 LobeHub,但 Agent 为核心的理念一直没变。

异构 Agent 的核心思路是:不同的 Agent 可以使用不同的 Harness(执行引擎),但它们共享统一的接口和上下文。在 LobeHub 的视角里,你创建的 agent 可以用他们自研的 Mecha Harness,也可以是 Claude Code、Codex 这些外部 harness。但基于 agent 衍生出的 topic/thread/message 体系是完全一致的。

这种设计的好处是显而易见的。围绕 agent 展开的业务能力,比如 agent group、task 系统等,都可以复用这套架构。你不需要为每种 agent 类型单独开发一套交互逻辑,也不需要在不同工具之间手动同步上下文。

实际使用场景

目前 LobeHub 已经实现了在网页版中 assign 一个 task 给 Claude Code 的功能。当你分配任务后,Claude Code agent 会在沙箱里启动自己的运行时执行任务,完成后直接提交 PR。整个流程是自动化的,你只需要在 LobeHub 界面里发起任务,然后等待结果。

这个场景对开发者来说非常实用。以往你可能需要:

  1. 在 LobeHub 里讨论需求和方案
  2. 切换到 Claude Code 或 Codex 执行具体的代码修改
  3. 手动把执行结果和上下文同步回 LobeHub
  4. 继续讨论或调整

现在这些步骤可以在一个界面里完成。更重要的是,所有的对话历史、任务状态、执行日志都在同一个 context 里,不会因为工具切换而丢失信息。

LobeHub 网页版中 assign task 给 Claude Code 并自动提交 PR 的流程示意图

Agent Group 的想象空间

LobeHub 团队提到,agent group 功能正在开发中,可以让 Codex、Claude Code 以及 LobeHub 自己的 agent 协作干活。这个方向很有意思。

目前市面上的 AI 编程工具基本都是单一 agent 模式。Cursor、Windsurf、Claude Code、Codex 各有特点,但它们都是独立工作的。如果你想让 Claude Code 负责架构设计,Codex 负责具体实现,然后用 LobeHub 的 agent 做 code review,就需要手动协调这些工具。

异构 Agent 的架构让多 agent 协作成为可能。理论上,你可以:

  • 让不同 agent 负责不同类型的任务(设计、实现、测试、文档)
  • 根据任务复杂度动态选择合适的 agent
  • 让多个 agent 并行工作,提高效率
  • 在 agent 之间传递上下文和中间结果

当然,这些场景的实现还需要解决很多问题,比如任务分解、agent 间通信、冲突处理等。但至少在架构层面,LobeHub 已经为这些可能性做好了准备。

技术实现的考量

LobeHub 团队透露,异构 Agent 这个想法去年 8 月就有了,但一直没做。原因是当时他们还没有自研的 Agent Harness,如果只是简单集成外部工具,意义不大。

这个决策很理性。如果只是做个工具集成,用户体验不会有本质提升,反而可能因为适配问题带来新的麻烦。只有当你有了自己的 agent 实现,理解了 agent 的核心抽象,才能设计出真正通用的架构。

从技术角度看,异构 Agent 的实现需要解决几个关键问题:

1. 统一的接口抽象

不同的 agent 工具有不同的 API 和交互方式。Claude Code 和 Codex 的命令行接口、参数格式、返回结果都不一样。LobeHub 需要定义一套统一的接口,把这些差异屏蔽掉。

这个接口需要足够通用,能覆盖大部分 agent 的能力,同时又要足够灵活,允许不同 agent 暴露自己的特性。这是个典型的抽象层设计问题,做得好可以大幅降低集成成本,做得不好就会变成最小公约数,限制了各个 agent 的发挥。

2. 上下文管理

多个 agent 共享上下文是异构 Agent 的核心价值。但上下文的同步和管理并不简单。

首先是上下文的粒度问题。是共享整个对话历史,还是只共享特定的 topic 或 thread?如果粒度太粗,可能会给 agent 带来太多无关信息;如果粒度太细,又可能丢失重要的背景。

其次是上下文的格式问题。不同 agent 对上下文的理解可能不同。比如 Claude Code 可能更关注代码相关的上下文,而 LobeHub 的通用 agent 可能需要更多的对话历史。如何在统一格式和个性化需求之间取得平衡,是个挑战。

3. 执行环境隔离

不同 agent 的执行环境可能有冲突。Claude Code 和 Codex 都需要访问本地文件系统,如果它们同时修改同一个文件,就可能出问题。

LobeHub 提到 Claude Code agent 会在沙箱里启动运行时,这是个好的实践。但沙箱的实现也有很多细节需要考虑,比如文件系统的映射、网络访问的控制、资源使用的限制等。

与竞品的对比

目前市面上还没有类似的产品。Cursor、Windsurf 这些 AI IDE 都是单一 agent 模式,虽然它们也在探索 multi-agent 的方向,但主要是在自己的生态内实现,没有开放给外部 agent。

Replit 的 Agent 模式也是封闭的,虽然功能强大,但你只能用 Replit 提供的 agent,不能集成其他工具。

LobeHub 的异构 Agent 架构更开放。它不是要替代 Claude Code 或 Codex,而是把它们整合到一个统一的工作流里。这种思路更符合开发者的实际需求——大部分人不会只用一个工具,而是根据任务选择最合适的工具。

当然,开放性也带来了复杂度。LobeHub 需要适配不同工具的更新,处理各种边界情况,维护成本会比封闭系统高。但如果做好了,用户粘性会更强,因为你提供的是一个平台,而不是一个工具。

未来的可能性

异构 Agent 的架构为 LobeHub 打开了很多可能性:

1. 更多 agent 的集成

除了 Claude Code 和 Codex,未来可以集成更多类型的 agent。比如:

  • 专注于测试的 agent(如 Playwright、Cypress 的 AI 助手)
  • 专注于文档的 agent(如 Mintlify、GitBook 的 AI 功能)
  • 专注于 DevOps 的 agent(如 Kubernetes、Terraform 的 AI 工具)

每个领域都有专业的工具,如果能把它们整合到一个平台上,开发者就不需要在多个工具之间切换了。

2. Agent 市场

LobeHub 已经有了 Agent 市场,但目前主要是基于 Mecha Harness 的 agent。如果异构 Agent 架构成熟了,可以开放给第三方开发者,让他们把自己的 agent 接入 LobeHub。

这样就形成了一个生态:用户可以在 LobeHub 上找到各种专业的 agent,开发者可以通过 LobeHub 触达更多用户。这个模式有点像 VS Code 的插件市场,但更进一步,因为 agent 之间可以协作。

3. 企业级的 agent 编排

对于企业用户来说,agent 编排是个刚需。一个复杂的软件项目可能需要多个 agent 协作:需求分析、架构设计、代码实现、测试、部署、监控等。

如果 LobeHub 能提供一套 agent 编排的能力,让企业可以定义自己的工作流,指定哪些任务用哪些 agent,设置 agent 之间的依赖关系,那就能解决很多实际问题。

这个方向的竞争对手是 LangChain、LlamaIndex 这些 agent 框架,但 LobeHub 的优势是有完整的用户界面,降低了使用门槛。

当前的限制

虽然异构 Agent 的前景很好,但目前还有一些限制:

  1. 仅支持桌面端:这个功能目前只在桌面端可用,因为需要调用本地的 CLI 工具。网页版虽然可以 assign task,但执行还是在本地。这限制了使用场景,尤其是对于团队协作来说。

  2. agent group 还在开发中:多 agent 协作是异构 Agent 的核心价值,但这个功能还没完全做好。目前只能单独使用每个 agent,不能让它们协作。

  3. 支持的 agent 类型有限:目前只支持 Claude Code 和 Codex,其他工具还不能集成。虽然架构是通用的,但每个工具的适配都需要时间。

  4. 上下文同步的完整性:不同 agent 之间的上下文同步做到什么程度,目前还不清楚。比如 Claude Code 执行任务时产生的中间状态,能否完整地同步到 LobeHub?这些细节会影响实际使用体验。

对开发者的意义

异构 Agent 对开发者来说意味着什么?最直接的好处是减少工具切换。如果你同时在用 LobeHub、Claude Code、Codex,现在可以在一个界面里完成大部分工作。

更深层的意义是工作流的整合。以往你可能需要:

  • 在 LobeHub 里讨论方案
  • 在 Claude Code 里实现代码
  • 在 Codex 里做重构
  • 在 GitHub 里提交 PR
  • 回到 LobeHub 继续讨论

每个步骤都需要手动操作,上下文需要手动同步。现在这些步骤可以自动化,甚至可以并行执行。

对于团队来说,异构 Agent 还能提高协作效率。如果团队成员使用不同的 agent 工具,以往很难共享上下文和工作状态。现在通过 LobeHub,大家可以看到同一个 agent 的执行历史,理解彼此的工作进展。

技术选型的启示

LobeHub 的异构 Agent 架构给技术选型带来了一些启示:

  1. 抽象层的价值:在快速变化的 AI 领域,工具层出不穷。如果每次都深度绑定一个工具,切换成本会很高。通过抽象层,可以降低对具体工具的依赖,保持灵活性。

  2. 开放 vs 封闭:封闭系统可以提供更好的集成体验,但限制了用户的选择。开放系统更灵活,但需要处理更多的复杂度。LobeHub 选择了开放的路线,这对于开发者工具来说是正确的方向。

  3. 渐进式实现:异构 Agent 的完整愿景很大,但 LobeHub 选择了渐进式实现。先支持基本的集成,再做 agent group,最后做编排系统。这种节奏比较稳健,可以根据用户反馈调整方向。

总结

LobeHub v2.1.56 的异构 Agent 功能是个有意思的尝试。它不是简单的工具集成,而是在架构层面为多 agent 协作做准备。虽然目前功能还比较基础,但方向是对的。

对于开发者来说,这个功能的价值取决于你的工作流。如果你本来就在用 LobeHub、Claude Code、Codex,那这个功能可以明显提高效率。如果你只用其中一个工具,那价值就没那么大。

更值得关注的是 LobeHub 的产品思路。他们没有试图做一个大而全的 AI IDE,而是做一个 agent 平台,整合各种专业工具。这个定位很清晰,也符合开发者的实际需求。

接下来值得关注的是 agent group 功能的实现。如果能做好多 agent 协作,LobeHub 就不只是个工具集成平台,而是一个真正的 agent 编排系统。那时候它的价值会更大。

参考来源