在 AI 代理驱动的开发流程中，多任务并行已成为常态，但单一工作区容易导致上下文污染和敏感数据泄露。Beehive 作为多工作区代理协调器，通过严格的隔离机制解决了这些痛点，确保每个代理任务独立运行，同时支持高效切换和协调。
上下文分区：Hive 与 Comb 模型的核心隔离
Beehive 的设计核心是 “hive/comb” 架构，其中 hive 对应一个 GitHub 仓库引用，comb 则是该仓库在特定分支上的完整独立克隆，每个 comb 拥有独立的 .git 目录。这种分区方式避免了 git worktree 的复杂性和状态共享风险，天然支持上下文隔离。
例如，在处理多个 issue 时，可以为同一 hive 创建多个 comb，每个 comb 运行独立的 AI 代理任务，如一个 comb 处理认证模块，另一个处理测试逻辑。隔离确保代理无法访问其他 comb 的未提交变更或历史，避免泄露。
工程参数配置：
- Hive 添加：输入 GitHub repo URL，Beehive 自动验证存在性并存储元数据。推荐使用私有 repo 时配置 gh auth token。
- Comb 创建：指定分支（如 feat/oauth），克隆深度默认 full（可设 --depth=1 加速小变更）。大 repo 克隆阈值设 1min，超时回滚。
- 目录路径：默认～/.beehive/combs/{hive_id}/{comb_id}，监控磁盘使用 < 10GB/hive。
此机制比 tmux/zellij tabs 更安全，后者仅目录切换易误操作导致泄露。
安全切换：持久 PTY 终端与代理窗格
Beehive 支持真实 PTY 会话，终端状态在 hive/comb 切换时持久化，支持一键跳转多任务。代理窗格集成如 Claude Code，直接在 grid 布局中启动 CLI 代理。
安全手 off 通过 comb 边界实现：切换时不共享进程状态，仅复制必要 env vars（如 PATH、GIT_CONFIG）。跨 comb 协调使用外部工具如 gh pr，防止直接文件访问。
落地清单：
- 终端启动：
npm test或git status，实时 sidebar 更新分支状态。 - 代理集成：窗格命令
claude-code --model opus-4.6 --dir ~/comb，任务提示如 “add OAuth2 to src/auth.ts”。 - 复制 Comb：duplicate 未提交工作，参数 --copy-uncommitted=true，风险控制：仅本地复制，不 push。
- 切换延迟：<500ms，监控 PTY 重连失败率 <1%。
HN 讨论中，作者强调此设计简化了从 zellij tabs 到隔离 dirs 的迁移：“I used to have to do this in tabs in zellij /sessions in tmux and remember which sessions is which issue /ticket。”
跨工作区协调：无泄露下的协作策略
尽管隔离严格，Beehive 支持跨 hive 协调，如 monorepo 内多 repo。通过 dropdown 切换 hive，持久终端确保连续性。避免泄露的关键是无共享状态，所有交互 via CLI 工具。
参数与监控：
- 协调阈值：hive 数 ≤10，comb/hive ≤20，总内存 <2GB (Tauri 轻量)。
- 回滚策略：comb 失败时
rm -rf comb_dir，git clean -fdx。 - 监控点：
指标 阈值 告警 克隆时间 >2min 优化 depth 磁盘增长 >5GB/day 清理旧 comb PTY 掉线 >5% 重启 app 代理输出泄露 关键词扫描 隔离验证
扩展时，可集成 Zellij 内嵌终端，进一步分层隔离。
风险与优化
潜在风险包括大 repo 克隆慢（缓解：预热热门 branch）和 macOS 专属（PR Linux）。相比 Conductor 等工具，Beehive 更专注 git 隔离而非通用 workflow。
总体，Beehive 提供生产级多代理隔离，适用于 solo dev 监督 3-5 并行任务。
资料来源：
- HN Show HN: https://news.ycombinator.com/item?id=47135425
- 项目官网: https://storozhenko98.github.io/beehive/
- GitHub: https://github.com/storozhenko98/beehive
（正文字数约 950）