BearDrive深度介绍：Agent时代的Google Drive，开源、自托管、让AI团队的上下文不再丢失

2026-08-13 12:28 👁️ 47 阅读 👍 3 赞
BearDrive AI Agent文件同步 开源共享文件夹 自托管文件同步 AGPL-3.0 RAG上下文共享 AI团队知识库 Runbear Agent版Dropbox 跨Agent协作

AI编程助手在工作时会产生大量有价值的文件：Claude Code写出的调研报告、Codex生成的HTML分析页、Cursor产出的CSV数据、设计Agent输出的资源文件。这些文件往往”出生在某一个人的笔记本里，死在某一个人的笔记本里”——同事和他的Agent都不知道这份文件存在，于是重复研究、重复劳动。

Runbear团队在2026年8月12日于Product Hunt发布了https://github.com/runbear-io/beardrive（GitHub组织页描述为"Google Drive for AI agents——与团队共享文件，跨Agent共享上下文。开源，无需服务器”），并在同日登上Product Hunt当日第7名。这款工具要解决的正是这个痛点：把任意本地文件夹变成AI Agent团队的共享卷，文件一写入就秒级同步给团队成员及其Agent，每次修改都留痕、可归属、可恢复。

它到底解决什么问题

Runbear创始人Snow在Product Hunt发布帖里讲了一个很具体的场景：团队里每个人都在用Claude Code，每个人的Agent都在产出真正有用的东西——竞品调研、发布计划、分析报告、幻灯片。但这些文件全都躺在各自的笔记本里。同事会去重新研究一遍你的Agent已经搞清楚的问题，因为他和他的Agent根本无从知道那份文件存在。

传统的解决方案在这个场景下全都失灵：

  • 粘贴进Notion：手动搬运，没人能坚持
  • Git：为调研文档和运营产物做PR工作流是错配，非工程师根本不会碰
  • Dropbox/Google Drive：能同步字节，但告诉你”谁在什么设备、什么时候改了什么”吗？告诉你”哪些文档被Agent高频读取但已经三个月没更新”吗？

BearDrive的解法很聪明：不改变Agent的工作方式。它就是一个文件夹，真实文件、真实路径、就在你已经在用的那个目录里。Agent不用调新API、不用把文件转成Notion页面，直接读写本地文件，后台自动同步。

核心特点

1. 文件系统原生，零集成成本

bdrive init可以把任意文件夹变成一个同步项目。文件就是磁盘上的真实文件，任何工具、编辑器、Agent都能用，不需要特殊SDK。重命名或移动文件夹也没问题——状态由稳定ID标识，而非路径。

2. 秒级同步，跨设备收敛

通过共享hub，多台设备上的变更在写入后数秒内就能同步到其他成员。每台设备只写自己的append-only日志，因此不需要锁服务。

3. 自动版本化与归属

每一次同步的修改都会成为一个被保留的版本，归属于具体的人或Agent，并且可恢复。用bdrive log可以看到每一行的变更记录：

  1. 2026-06-17 09:14:02 put notes/memory.md snow@runbear.io on macbook (412 B)
  2. 2026-06-17 09:14:55 put notes/memory.md agent@runbear.io on linux-vm (501 B)
  3. 2026-06-17 09:15:11 delete notes/draft.md snow@runbear.io on macbook

“谁最后改了文件X？”→ bdrive log -p -n 1。”设备Y做了什么？”→ bdrive log -n 0然后按设备名过滤。历史是内容寻址的——被覆盖和被删除的文件仍然保留在日志里，blob存放在~/.bdrive/volumes/<id>/blobs/下。

4. 公开分享链接与网页视图

每个文件都会获得一个链接，你可以直接丢进Slack；队友打开的是一个网页视图，不需要安装任何东西。

5. 自托管，对象存储后端随意选

hub是一个bdrive Web服务器，你或Runbear自己运行，后端可以是S3、GCS、R2、MinIO或普通文件夹。客户端通过HTTPS与hub同步，从不直接接触存储。

自托管只需一个二进制：bdrive serve。

6. 读取热度(Read Heat)：把文档健康度画出来

这是BearDrive最有想象力的一项能力。hub的Insights面板按”被Agent读取的次数 × 距离上次更新的时长”给每个文件画热力图。被高频读取但久未更新的文件会被标红——这就是风险清单：被重度依赖却在悄悄腐烂的文档。

Runbear的原话很犀利：”你的Agent信任一份从三月份起就没人更新的文档。”Read Heat把被动的文件服务器变成了主动的系统健康监视器。

7. 离线可用

断网情况下文件操作和本地日志照常工作，网络恢复后自动推送。

8. 开源协议AGPL-3.0

服务端、团队、历史、链接功能的代码都在GitHub上公开。

5分钟上手

自托管hub（约10分钟）

  1. # 在一台服务器上
  2. bdrive serve --remote s3://your-bucket/beardrive \
  3. --aws-region us-east-1 \
  4. --aws-access-key-id XXX \
  5. --aws-secret-access-key YYY

客户端接入

  1. # 在每台设备上，登录到你的hub
  2. bdrive login https://your-hub
  4. # 进入要同步的文件夹，初始化
  5. cd ~/workspace && bdrive init
  6. # 输出：
  7. # initialized /Users/snow/workspace
  8. # project: workspace (p-7f3a2c91)
  9. # daemon: running (pid 55434, scan 3s, remote sync 10s)
  11. # 在另一台机器上连接同一个项目
  12. bdrive login https://your-hub && cd ~/workspace && bdrive init
  13. # 文件会出现并保持同步

查看状态

  1. bdrive status
  2. # device: macbook (d380dea58598) as snow@runbear.io
  3. # volume: agent-workspace
  4. # remote: s3://acme-beardrive/agent-workspace
  5. # daemon: running (pid 55434)
  6. # files: 142 (3.4 MiB)
  7. # pending: 0

BearDrive Cloud托管版（零配置，bdrive login直连）目前在其官网beardrive.ai处于waitlist阶段，自托管版现在就能用。

典型使用场景

1. 团队知识库与Runbook

让Runbook、事故响应文档、运营手册保持最新，且对Agent可读，自动化工作流从最新上下文起步。

2. Agent辅助内容编辑与发布

Agent可以直接在原地更新报告或文档；同一个文件立即对队友和其他Agent可用，消除”粘贴副本+同步混乱”的老问题。

3. 文档健康与维护

用reads × freshness热力图找出”被高频读取但已过时”的文档，优先更新。

4. 跨Agent工作流

一个Agent的输出是另一个Agent的输入——BearDrive保留产物及其版本，而不是散落各处。

5. 自托管项目与数据所有权

需要在自有基础设施内保留AI产出文件的组织，可以把BearDrive跑在自己的S3/GCS/R2/MinIO或普通文件夹上。

真实问题与使用边界

BearDrive不是银弹，以下几个边界要在引入前看清：

1. 它不是专业的memory-DB或知识召回系统

BearDrive是给文件用的共享文件夹，应该与专门的记忆工具配对使用。Memory工具通过MCP服务器召回特定事实或上下文，BearDrive则是那些被召回上下文所产生出来的产物（报告、会议记录、设计文档）的目的地。它占据的是一个独特定位：AI驱动工作的活跃共享文件系统。

2. 不是Git式工作流

BearDrive刻意不像基于仓库的PR工作流，它是文件夹中心的同步。如果你的团队需要代码审查、分支管理、PR流程，那是Git的地盘，BearDrive不替代。

3. Beta阶段，免费不等于永久免费

目前公开测试阶段完全免费，但Runbear的商业模型很清楚：AGPL-3.0开源自托管永久免费，托管服务按团队收费。未来托管版定价会落地，自托管用户不受影响。

4. 自托管有运维责任

当你选择自托管时，存储、备份和运维责任由你自己承担。如果后端是S3/GCS/R2/MinIO或普通文件夹，你需要自己管理这些基础设施。另外需要注意：如果更改远程后端（例如从file://改为s3://），下次同步会把所有内容推送到新远程；所有共享该卷的设备都必须指向新URL，否则会出现分歧。

5. 项目级权限，冲突处理偏”最后写入者生效”

BearDrive的权限粒度停在项目级。低权重的第三方测评提到”文件写入后直接同步，没有上传前审核”——这意味着如果一个Agent写出了敏感内容，它会直接进同步流。对权限有细粒度要求的企业，目前需要在文件夹规划阶段就把敏感内容隔离到独立目录。

6. 文档仍在完善

有测评指出BearDrive的文档覆盖面有限（但开源性质允许社区贡献）。核心CLI和自托管指南可用，但深度运维、异常排查的文档还在补齐。claudepluginhub上的插件页提供了一些诊断命令（如bdrive status、bdrive log、daemon.log路径），实际使用时需要结合README和源码。

7. 0.x版本，API可能变动

项目仍处于早期阶段，CLI命令、hub协议、配置格式在未来的1.0之前都有可能调整。生产关键系统引入需要评估升级成本。

与相似工具的定位差异

维度 BearDrive Dropbox/Google Drive Git Notion
同步对象 Agent产生的文件 任意文件 代码与文本 结构化页面
Agent身份归属 原生支持 不支持 依赖commit author 不支持
读取轨迹分析 Read Heat热力图 无 无 无
工作流 文件夹中心，秒级同步 文件夹中心，秒级同步 仓库中心，PR工作流 工作区中心，手动搬运
自托管 AGPL-3.0，单二进制 否 是 否
协议 AGPL-3.0 专有 GPL-2.0等 专有

BearDrive的护城河不在”自动同步”这一层——Dropbox、Google Drive、Notion都能补这块。它的护城河在四样东西：Agent身份归因、读取轨迹、版本可追溯、上下文治理。再加上”无云端凭据碰你的电脑”的自托管数据主权，切的是企业数据主权，不只是便利。

适合谁

1. 多Agent协作的团队

团队里有多人使用Claude Code、Codex、Cursor、Gemini等Agent，且Agent产出需要互相可见。这是BearDrive的主场。

2. 重视数据主权的组织

金融、医疗、法律等合规要求高的行业，可以把hub跑在自己的S3/GCS/R2/MinIO上，存储完全归自己。

3. AI原生工作流的研究/咨询/代理机构

调研报告、竞品分析、客户交付物都是Agent产出的文件，需要团队共享和客户交付。

4. 个人多设备用户

在自己的MacBook Pro和Mac mini之间同步Agent产出，不需要复杂的云账号体系。

不适合谁

  • 需要细粒度文件权限的企业：目前权限停在项目级
  • 需要代码审查工作流的团队：那是Git的地盘，BearDrive不替代
  • 需要专业memory-DB的团队：BearDrive是文件共享层，应该与专门的记忆工具配对
  • 不愿意承担自托管运维的团队：要么等BearDrive Cloud托管版结束waitlist，要么接受运维责任
  • 生产关键系统：0.x版本，API可能变动，建议先在独立shared/目录试点

一个判断

BearDrive押注的是一个真实且正在扩大的痛点：AI Agent正在制造一种新型文件混乱。它的聪明之处在于不改变Agent的工作方式——Agent继续写本地文件，BearDrive在后台把”本地”扩展成”团队级”。这种”文件系统原生”的思路，比”再来一个工作区让你迁移进去”的玩法要尊重得多。

但BearDrive也不是来替代什么的万能工具。它不替代你的wiki、不替代你的代码仓库、不替代专业的memory-DB。它做的是在它们之间创造连接组织——由Agent自身驱动的活跃共享文件系统。

Runbear团队自己的说法是：”We run our whole company on it. Our strategy wiki, sales collateral, and research sync across the CEO, marketing, dev, and support projects through BearDrive, and each team’s agents read and write it every day. This launch was planned in it.”如果一个内部已经全员使用Claude Code的团队愿意把整个公司跑在这上面，说明核心能力是经得起真实工作负载考验的。

对于正在被”Agent产出文件散落各处”困扰的团队，BearDrive值得现在就试——但先只同步独立的shared/目录，放报告和研究资料，别碰项目根目录、合同、客户数据和密钥。等1.0发布、托管版定价落地、文档更完善之后，再考虑扩大同步范围。