bb

为什么选择 bb？

当工作不再局限于编辑器内单个聊天面板时，bb 更有价值。它为拥有多个编程智能体的开发者提供持久空间，用于分派任务、检查活动、必要时介入，并接入更广泛的自动化。

bb 更像智能体工作台或管理平台。仍可看文件、编辑、打开终端和操作仓库，但更高层的工作对象是会话：与智能体、环境和项目关联的运行中工程任务。

另一特色是允许智能体修改开发环境本身。重复需求可变成插件、命令、面板或技能，无需等产品团队开发。对流程独特、通用 IDE 功能总差一点的开发者尤其有吸引力。

灵活性也把部分责任交还用户。商业编辑器可优化整合体验并隐藏细节，bb 则更多开放底层生态。想掌控时很强大，只需可靠补全和单个助手时则可能多余。

核心工作流程

bb 位于智能体之上，不替换其智能。认证和大部分执行仍由 Claude Code、Codex、Cursor、Pi 等负责，bb 提供选择与协调它们的工作区。

小任务仍像普通智能体编程：打开项目、建会话、选服务、描述修改并跟踪。多个独立或依赖任务时区别更明显：分别开会话、创建子任务，并用 worktree 或不同环境减少并行冲突。

服务商可按任务选择，而非将整个仓库绑定一家产品。可分别安排长时间实现、集中审查，或更适合现有订阅的任务。因此，主动采用多服务商时，bb 最有价值。

适用场景

同时执行多项长期任务是典型场景，如一边排查 CI、一边开发功能、另一边审查迁移。bb 给它们独立标识，以整组运行中工作为中心，避免普通聊天面板难以管理。

也可打造团队专用环境。仓库发布检查、任务系统、文档规范或部署命令太特殊时，插件可把它们融入工作台，而非另维护分散脚本和浏览器标签。

它也适合从桌面界面外发起工作的开发自动化实验。外部脚本或服务可创建会话，留待开发者检查。与全自动 issue 到 PR 系统不同，重点仍是开发者掌控的工作区，让自动和交互工作交汇。

同类工具对比

主要直接编辑代码的开发者更熟悉 Cursor 和 Windsurf：编辑器是中心，周围集成智能体。bb 则以智能体及其任务为中心，文件编辑是配套手段之一。

Kiro 更强调结构化、规格驱动，适合希望将需求和实现计划显式纳入流程的团队。bb 对任务形式限制较少，更重视围绕不同智能体与插件自建环境。

Google Antigravity 同样强调智能体优先和多智能体协调，但取舍不同。bb 开源、围绕已有服务与订阅运行，开放大量定制入口；Antigravity 更一体化。比较重点是由谁掌控编排层，而不只是哪个智能体会写某个函数。

配置建议

初次评估建议用稳定版而非 Nightly，只连接常用服务商，先判断会话模式是否改善工作，不必在配置时比较所有智能体。

标准包启动命令：

npx bb-app@latest

较新 npm 可能要求明确允许原生依赖安装脚本。若提示缺少原生绑定，使用文档中的允许列表命令：

npx --allow-scripts=better-sqlite3,node-pty,@parcel/watcher bb-app@latest

macOS Apple Silicon 的桌面安装最简单。Linux 若遇 alpha AppImage 问题，可用 npm 版。Windows 应将 WSL2 视为实际运行环境，在 Linux 内安装 Node.js、Git、智能体 CLI，并从该环境存放或访问仓库，而非期待原生 PowerShell 行为。

尽量在 bb 外完成服务商认证，复用已登录 CLI，减少一层账号配置。必要时可提供显式密钥，但不必因有选项就加凭证，以免多服务环境更难理解。

隐私敏感部署在对外开放服务器前，应检查遥测和远程访问。可用以下方式关闭本次启动的匿名生产遥测：

BB_TELEMETRY=false npx bb-app@latest

不必立即开发插件。先确认哪些重复流程值得纳入环境，让插件承载真实重复行为，而不只是演示 IDE 能修改自身。

迁移建议

从 Cursor、Windsurf 等迁入，不必第一天复刻整套 IDE。bb 可与现有编辑器并用，先迁移智能体协调，手动编辑仍用熟悉工具，证明有用后再逐步迁入更多功能。

保持现有 Claude Code、Codex、Cursor 等独立可用，让 bb 管理已有安装，避免换工作区时同时更换模型和凭证，也便于分辨问题来自 bb 还是服务商。

自定义插件团队应更谨慎。项目仍快速迭代，部分 API 标为实验性。关键内部流程尽量避开实验接口，需复现时固定版本，升级按软件变更测试，不能默认一直兼容。