解构CCB Provider后端架构17种AI编码智能体如何被统一接入【免费下载链接】claude_codex_bridgeVisible multi-agent CLI workspace for mixing Codex, Claude, Gemini, Kimi, Qwen, Cursor, Copilot, Pi, OpenCode, and other AI coding agents项目地址: https://gitcode.com/gh_mirrors/cl/claude_codex_bridgeCCBclaude_codex_bridge是一个可视化的多智能体 CLI 工作区它把 Codex、Claude、Gemini、Kimi、Qwen、Cursor、Copilot、Pi、OpenCode 等17 种 AI 编码智能体通过一套统一的 Provider 后端架构接入到同一个 tmux 工作区中。本文将带你拆解这套CCB Provider 后端架构从能力清单到统一契约看懂每种 AI 编码智能体是如何即插即用的。为什么需要统一 Provider 后端每个 AI 编码智能体的脾气都不同Codex 走 App Server 协议Claude 用流式会话日志OpenCode 依赖 SQLite 存储还有一些智能体只在终端里输出裸文本。如果每种都单独对接上层的工作区调度、会话恢复、完成检测就会变成21 套代码 × N 个功能的组合爆炸。CCB 的解法是把差异全部收敛到一个Provider 后端层上层CLI、ccbd 守护进程、执行引擎只面向统一契约编程。整个运行时主干如下ccb - lib/cli/* - lib/ccbd/* - lib/provider_execution/* - lib/completion/* - lib/storage/* lib/project/* lib/workspace/*Provider 后端的四层结构在 docs/current-project-structure.md 中官方明确了 Provider 层的职责切分这也是理解整套架构的地图层目录职责核心契约层lib/provider_core/共享的元数据、运行时规格、注册表契约后端适配层lib/provider_backends/每种智能体专属的会话、协议、通信、执行辅助日志支撑层lib/provider_backends/pane_log_support/为只输出裸文本的智能体提供共享的终端日志读取逻辑执行层lib/provider_execution/Agent-first 流程面向运行时的执行层完成检测层lib/completion/判断这个智能体是否干完了活一句话概括provider_core 定义规则provider_backends 负责翻译provider_execution 负责执行。智能体的身份证ProviderManifest每个后端接入前必须先登记一张能力清单即 ProviderManifest。它用一组布尔值声明该智能体支持哪些能力class ProviderManifest: provider: str # 智能体名称 supports_resume: bool # 是否支持会话恢复 supports_permission_auto: bool # 是否支持自动授权 supports_stream_watch: bool # 是否支持流式监听 supports_subagents: bool # 是否支持子智能体 supports_workspace_attach: bool # 是否支持工作区挂载 runtime_profiles: ... # 各运行模式下的完成检测配置这张清单在 ProviderCatalog 中集中管理。目录拒绝重复注册、按名称小写归一查找并在解析完成检测配置时校验运行模式是否被支持——能力差异被显式声明而不是在运行时悄悄失败。17 种内置后端都在哪注册所有内置智能体在 builtin_backends.py 中分两类注册核心三强CORE_PROVIDER_NAMEScodex、claude、gemini扩展 14 种OPTIONAL_PROVIDER_NAMESopencode、droid、kimi、qwen、cursor、copilot、grok、pi、omp、zai、qoder、deepseek、dsh、mimo等每个智能体在 lib/provider_backends/ 下都有自己的独立目录例如 lib/provider_backends/claude/ 内包含comm.py通信、protocol.py协议解析、session.py会话管理、execution.py执行、launcher.py启动等模块——一个智能体一个抽屉互不干扰。此外codebuddy等后端目录与native_cli_support、pane_log_support、pane_quiet_support等共享支撑模块并存后者专门服务于那些不产生结构化会话日志的 shell 风格智能体CCB 直接读取终端窗格输出用统一的解析器兜底让最笨的接口也能接入统一工作区。统一契约三种适配器角色每个后端最终组装成一个 ProviderBackend 对象最多携带三种适配器契约作用ProviderSessionBinding声明如何加载/识别会话文件与 session ID用于会话隔离与恢复ProviderRuntimeLauncher负责拼装启动命令、准备运行时上下文、启动后挂钩ProviderExecutionAdapter对接执行层统一发指令—收反馈的运行时流程这套设计的精妙之处在于契约是数据不是代码新增一个智能体时你不需要改上层任何一行调度逻辑只要提供一个build_backend()工厂函数返回填满上述契约的ProviderBackend再在 builtin_backends.py 中注册一行即可。项目内置的fake、fake-codex、fake-claude等测试替身见 test_double_backends.py正是同一契约的产物也让整个矩阵可以被离线测试覆盖。上手体验三步进入统一工作区# 克隆仓库 git clone https://gitcode.com/gh_mirrors/cl/claude_codex_bridge cd claude_codex_bridge # 安装 ./install.sh之后通过ccb命令即可在同一 tmux 工作区中混合启动多个 AI 编码智能体侧边栏集中查看状态、回复与完成事件。更多安装细节可参考 docs/install-runtime-environment/完整的目录职责说明见 docs/current-project-structure.md。小结CCB 的 Provider 后端架构本质上是一套适配器 注册表 能力清单的经典模式ProviderManifest声明能力把差异显式化ProviderCatalog / Registry负责注册与解析保证名称归一、拒绝重复ProviderBackend 契约统一会话、启动与执行三种角色pane_log_support 等共享模块兜底无结构化日志的智能体。正因如此17 种 AI 编码智能体才能在同一个工作区里协作而新增一个智能体的成本被压缩到一个目录 一次注册。如果你想深入源码建议从 lib/provider_core/contracts.py 与 lib/provider_backends/ 这两个入口开始阅读。【免费下载链接】claude_codex_bridgeVisible multi-agent CLI workspace for mixing Codex, Claude, Gemini, Kimi, Qwen, Cursor, Copilot, Pi, OpenCode, and other AI coding agents项目地址: https://gitcode.com/gh_mirrors/cl/claude_codex_bridge创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考