bb Provider 插件体系揭秘:为什么 Claude Code、Codex、Pi 都以插件形式运行 bb Provider 插件体系揭秘为什么 Claude Code、Codex、Pi 都以插件形式运行【免费下载链接】bbThe agent IDE that builds itself项目地址: https://gitcode.com/gh_mirrors/bb14/bbbb 是一个智能体 IDEAgent IDE它的核心理念是Provider 即插件——Claude Code、Codex、Pi 这些 AI 编程助手并不是内置功能而是以插件的形式注册进 bb 的。本文将带你拆解 bb 的 Provider 插件体系数据如何从各家 AI 助手流进统一的时间线官方插件为何享受零特权以及一条 JSON-RPC 协议如何撑起整个生态。一、什么是 bb 里的Provider在 bb 中Provider 就是可以被用来跑一个线程Thread的编程智能体。你开一个新对话在输入框下方挑选 Claude Code、Codex 或 Pibb 就会驱动对应机器上的 CLI 干活并把它的每一步操作实时流式渲染到时间线上。官方定义见 docs/provider-plugin-api.md设计目标是——一个 Provider 接触到的一切都归它的插件所有把智能体的原生输出翻译成 bb 的数据模型、投影到时间线、决定工具如何呈现而核心保持尽可能Provider 无关。也就是说bb 核心不认识Claude Code这四个字。它只认识一套极简的语义词汇message · reasoning · command · fileChange · fileRead · search webSearch · webFetch · imageView · delegation · planSteps · compaction · tool二、分层架构数据是怎么流转的每个 Provider 的输出都会经过这样一条流水线前两层归插件其余归核心host agent ─► bridge(插件) ─► thread/delta(核心词汇) ─► delta 装配器(核心) ─► ThreadEvent ─► 持久化 ─► 时间线投影 ─► 渲染器Bridge桥接层运行在宿主机上的插件进程负责翻译方言——把 Claude Code 的流式输出、Codex CLI 的报文、Pi 的 RPC 事件统统翻译成同一套thread/delta语义增量。核心运行时只负责保证时间线不变量ID 铸造、轮次生命周期、顺序从不对 Provider ID 做分支判断。协议细节在 docs/provider-bridge-protocol.md 中有完整描述一条行分隔 JSON-RPC 2.0通道贯穿双向initialize握手交换版本与能力turn/start、provider/health等命令构成完整契约。三、四大官方 Provider 插件一览bb 内置了 4 个 Provider 插件全部位于plugins/目录且在插件市场中统一归类为agents-and-providers插件驱动的智能体亮点文档provider-claude-codeClaude Code CLI三档权限模式、检查点分叉、手动压缩PLUGIN_OVERVIEW.mdprovider-codexCodex CLI≥0.136.0服务分层选择器、目标Goal动作、语音 AI 服务PLUGIN_OVERVIEW.mdprovider-piPi coding agent≥0.84.0原生技能目录同步、扩展对话框直通用户README.mdprovider-acp所有 ACP 智能体Cursor、opencode、omp、Grok Build、Hermes Agent 一网打尽还支持自定义 JSON 接入PLUGIN_OVERVIEW.md几个值得玩味的细节一个插件可以拥有多个 ProviderACP 插件同时管理 Cursor 和用户自定义的任意 ACP 智能体它们共享同一个family分组键。健康检查、用量、安装状态都由插件自己回答比如 Pi 插件会探测pi --version ≥ 0.84.0并在设置里提供一键npm install更新动作。技能目录也是插件的知识Pi 的技能~/.pi/agent/skills等由插件声明后bb 才会把它们与 bb 自身技能并列展示——核心不持有任何 Provider 政策。四、零特权原则官方插件与第三方一视同仁这是 bb 插件体系最硬核的设计四条原则来自 provider-plugin-api.md零第一方特权官方 Provider 只用公开 API任何特殊逻辑要么升级为公开原语要么删除每个事实只存一处能力要么声明、要么上报不能两者兼有核心只懂小词汇表其余全部是带声明式呈现的扩展类型每个客户端都能无插件代码渲染一切插件渲染器只是 Web 端的增强移动端渲染声明式基线。分布方式上更绝不存在daemon 内置 Provider这条捷径。桥接层以内容寻址的插件产物下发daemon 按校验哈希缓存——第一方 Provider 和市场里任何第三方 Provider 走的是同一条路信任模型完全等同。仓库里还有一个金丝雀示例 examples/plugins/echo-provider/它只用公开 SDK 就实现了 Provider 的全部能力注册、桥接、工具、扩展词汇、技能根目录……并配有 conformance 一致性测试套件。如果你写出的示例需要导入 bb 的私有包那就说明公开 API 有漏洞——这个项目把这条规则用测试钉死了。五、上手指南三步跑起来安装 bb 并连接本机daemon 会扫描宿主上已安装的智能体 CLI确保对应 CLI 已登录例如在宿主机上执行claude/codex login完成签到bb 会自动读取登录态展示账户与套餐新开线程、挑选 Provider 即可在输入框下方的 Provider 选择器里挑 Claude Code、Codex 或 Pi发送消息时间线开始流动。所有 Provider 的权限模式、推理档位、服务分层都可以按用户设置覆盖默认值由插件声明如completedTurnDisplay控制已完成轮次是折叠成一行Worked for还是平铺展示。六、这套架构为什么重要回到开头的问题为什么 Claude Code、Codex、Pi 都以插件形式运行版本解耦桥接层随插件升级而不是随 daemon 升级各家 CLI 快速迭代不会撕裂 bb 核心生态开放任何会说 ACP 的智能体甚至你自己写一个都能以id displayName command三条 JSON 接入一致性体验Web、移动端、CLI 面对的是同一套ThreadEvent与声明式呈现换 Provider 就像换浏览器标签页。对想深入源码的读者推荐阅读路径docs/provider-plugin-api.mdProvider 插件 API 完整参考docs/provider-bridge-protocol.md桥接协议与分工契约plugins/provider-codex/src/bridge/bridge.ts最完整的第一方桥接实现packages/provider-bridge-protocol/协议模式与一致性工具包一句话总结bb 把接一个 AI 编程助手从核心开发的脏活变成了插件市场的标准动作。这正是它敢于自称能自我构建的智能体 IDE的底气所在。【免费下载链接】bbThe agent IDE that builds itself项目地址: https://gitcode.com/gh_mirrors/bb14/bb创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考