AREX Feed Article
Busabase 推出 MIT 开源 agent 数据库与工作区，让 agent 产出沉淀为可复用的数据、文档与技能
10 月 9 日，Keras 作者 François Chollet（）在中写道，现在使用 AI agent 的感觉仍然很像单机游戏：它们替你干活，但结果被困在彼此隔离的聊天记录里，什么也积累不下来。帖文称，Busabase 团队（）正在推出一个以 MIT 许可开源的 agent 数据库与工作区来解决这个问题：agent 不再把工作丢给稍纵即逝的对话，而是直接写入结构化工作区，把产出变成整个团队可访问、可复用的数据、文档与技能。
帖文附带的链接指向 。经核验，该站点与 GitHub 仓库 都把项目描述为面向 AI agent 的开源（MIT）数据库与工作区，agent 与人共享同一份结构化数据、文档、技能与应用。
帖文之外：一条可核验的时间线
这条帖文发布于 10 月 9 日 16:31 UTC（北京时间 10 月 10 日 0:31），帖末的短链接解析后正是 busabase.com 首页。
产品能力的描述来自项目方自身的材料（官网、仓库文档与帖文）；这些材料本身可以核验：仓库的 是标准 MIT 许可证，署名 Copyright (c) 2026 Busabase；仓库主要语言为 TypeScript，创建于 6 月 23 日，截至 10 月 10 日核验时有 436 个 star 和 27 个 fork。Releases 列表里最近的 10 个版本，从 9 月 17 日的 v0.70.0 一路排到 10 月 8 日的 ；项目博客从 8 月中旬起持续更新。
这些时间点表明，Busabase 并非 10 月 9 日才出现的项目。10 月 9 日当天，显示该项目上线并获得当天的 Launch of the Day 奖项。
每次写入都是一条变更请求
官网把要解决的问题描述为：agent 的工作会散落在个人的聊天窗口里，人一离开，工作也跟着离开。Busabase 的做法是让 agent 与人在同一个工作区里读写同一份内容，并且不绑定某一家的模型或工具。仓库 README 列出的接入通道有 Agent Skill、MCP、OpenAPI、CLI 和对话式的 ACP，支持列表包含 Claude Code、Codex、Cursor、Gemini CLI、OpenCode、OpenClaw、Hermes、Buda AI、n8n 等；官网称可以连接 40 多个外部 agent，并提供 Codex、Claude Code、DeepSeek Harness 的插件入口。
写入路径上，Busabase 与普通表格、文档工具的做法不同：agent 的每次写入都以 Change Request（变更请求）的形式出现，带有说明、字段级差异、作者和历史记录。权限决定这条修改是立即合并，还是进入收件箱等待人工复核。README 列出了几种控制手段：被限制为 changeRequest 级别的凭证只能提出修改；单次调用可以带上 autoMerge: false；用命令行安装内容时，可以用 --require-review 把改动拦到复核之后。官网 FAQ 补充，被拒绝的工作不会进入正式数据，批准、要求修改或拒绝的每一次决定都会留在记录里。
工作区里留下什么：数据、文档、技能与应用
工作区的内容以几类一等节点存在：Bases（带类型的记录、关联、视图与表单）、Docs、Files、Drives、Skills、AirApps、Whiteboards 和 Workflows。技能是保存在工作区里的 SKILL.md 操作说明与提示词，Playbooks 把它们汇总成目录，供每个接入的 agent 在执行前查阅；AirApps 则是建立在同一份数据之上的界面，比如让 agent 把一个 Base 变成 CRM 或内容工作台。项目提供模板，一条命令就能装好一整个工作区：数据表、视图、文档、示例数据、应用和给 agent 的使用说明。
README 列出的典型场景包括：软件交付（反馈、任务、规格、发布说明）、SEO 与内容（关键词、简报、草稿、已发布页面）、CRM（公司、联系人、拜访记录）、团队记忆（决策与来源）以及数据集标注。在自我定位上，README 把它与三类产品区分开：给人直接编辑的 Airtable、Notion 一类工具，负责存储的 Postgres，只服务于单个 agent 回忆的 agent memory 与向量数据库；Busabase 给自己划定的位置是「人和 agent 共用的工作区」，自身跑在 Postgres 或嵌入式 PGlite 之上。
从 npx 一行命令到三种部署方式
README 给出的起步方式是 npx busabase server，然后打开 http://localhost:15419/dashboard/local：不需要数据库、账号或配置，服务自带嵌入式数据库 PGlite、本地文件存储和一个演示工作区。官方还提供 Docker 镜像（docker run --rm -p 15419:15419 -v ~/.busabase/data:/data busabase/busabase）、面向 macOS、Windows 和 Linux 的桌面版（可离线运行、数据留在本地），以及托管的多用户版本 Busabase Cloud；本地数据默认放在 ~/.busabase/data/，也可以改接外部 Postgres 或兼容 S3 的存储。
按，开源版本免费；Cloud 从免费层起步，Plus 为每席位每月 10 美元、Pro 为每席位每月 20 美元，两档均按年计费。Cloud Connect 用一条认证隧道把本地工作区接到 Cloud，数据留在本机，本地 agent 继续运行。
部署前还有一条写在 README 里的边界：开源服务器面向可信的本地机器或私有网络设计，在没有认证和反向代理的情况下，不应把写入端点暴露到公网；远程访问建议使用受限凭证和 Cloud Connect。
帖文下方的赞许、替代方案与质疑
截至 10 月 10 日核验时，这条帖文获得约 8 万次浏览、580 余个点赞、104 条回复和 29 次引用转发。回复与引用里，肯定与质疑并存。
引用帖文写道「这看起来不错」，并说自己最后总是让 agents 互相写简报，再由他像个人肉中层经理一样去提醒它们审阅和处理这些简报；这条引用获得约 50 个点赞。 则质疑帖文的前提：他认为「当前 agent 无法沉淀此前工作」的说法并不成立，连 ChatGPT 这类主流平台都能写入文件系统，只要有一点数据卫生习惯，用最基础的知识管理手段就能追踪一切；在他看来，这至少在过去半年里已不属于软件问题，关键在工作方法，而现有软件栈已经覆盖了相关用例。 则给出了替代方案：可以直接用一个原生支持多用户、多 agent 且不会遗忘的工具。
还有一些回复指向同一个问题：怎么防止 agent 往共享工作区里写下不值得留下的内容。 问：「你怎么阻止 agent 把垃圾写进共享工作区？」 把问题归结为信任：「难的不是存储，是信任。如果一个 agent 把错误的东西写进共享工作区，下一个 agent 就会把它当成事实。共享记忆需要来源标注和撤回机制，否则错误会像成果一样快速累积。」