产品对比

Busabase 与 ChatGPT Space：团队文档，还是可信记录

ChatGPT Space 是 OpenAI 在 2026 年 9 月 29 日推出的团队共享空间：页面、文件、表格、演示文稿和 Sites 放在一起，人、ChatGPT、Codex 和 Dots 实时在同一份材料上协作。Busabase 是面向 AI Agent 的开源数据库与工作区——agent 和人共用同一份结构化数据、文档、技能与应用，重要写入经审核成为可信记录。两者名字里都有「工作区」的意思，但重叠比看上去少：Space 围绕的是团队和 OpenAI 的 Agent 一起改的文档；Busabase 围绕的是任何 Agent 都能写入的记录，一次关键改动可以先作为可审的提案挂着，确认后才成立。

这篇写给正在判断的团队：Space 能不能顺带管住 Agent 产出的数据，还是只管文档。文章会直说 Space 更合适的场景——如果你的团队本来就泡在 ChatGPT 里，答案往往就是 Space。我们也会分清哪些是 OpenAI 官方文档写的、哪些是发布报道说的、哪些是我们自己的判断。

核实日期：2026 年 9 月 30 日（发布次日），依据 OpenAI 帮助文档与发布当天的媒体报道。凡是在这些来源里找不到的，一律写作「未见描述」，而不是「做不到」。

一句话结论

选 ChatGPT Space

：团队本来就在 ChatGPT 里干活，产出是文档、演示、表格和小网站，需要人和 AI 一起写。实时协同编辑、AI 写的文字原地接受或撤销、在页面上 @ 一个 Dot 就能让它接着干、管理员能管分享，而且什么都不用自己部署。论「AI 原生的团队文档」，它是更完整的产品。

选 Busabase

：Agent 的产出会变成别的东西依赖的数据——下一轮 Agent 会读、报表会读、对外页面会读——而且你的 Agent 不止来自一家厂商。或者某个字段的改动需要说清楚谁提的、谁批的，或者数据必须跑在你自己的机器上。

两个都用

：分工会自然出现。Space 放团队的文档和讨论，Busabase 当 Agent 写入的记录系统。ChatGPT 现在就能通过 MCP 连到 Busabase，两者不抢你同一段时间。

ChatGPT Space 今天到底做到了什么

凭第一印象写对比，比不写还糟。所以先摆事实，并注明出处。

OpenAI 官方文档写的：Space 是「你的页面、文件以及与 ChatGPT 共同完成的工作的归处」。里面有 Pages（可直接编辑的文档，支持表格）、电子表格、演示文稿、Sites（用 ChatGPT 做的网站和小工具）、图片和上传的文件，可以按主题或团队分成不同的 space。把页面以编辑权限分享出去，就能「实时一起写」。ChatGPT 生成的文字可以原地审阅——接受、要求修改或撤销。评论里可以 @ ChatGPT，「显示署名」能看到谁贡献了哪部分（如可用）。连接的应用（比如 Google Drive）保留原有权限；分享页面不会暴露私人对话和已保存的记忆。

Enterprise 管理员可以按工作区和角色管理分享，也可以关掉新的分享；已保存的 Library 文件遵循工作区的保留策略，Compliance API 可以导出或删除符合条件的文件。Space 在 Pro、Business、Enterprise 计划上取代原来的 Library，先上网页和桌面端，移动端随后。

发布报道补充的：据 VentureBeat，员工、ChatGPT、Codex 和 Dots（OpenAI 的常驻 Agent 同事，每个都有自己的云端电脑和浏览器）在同一份共享上下文上工作；多个人可以同时编辑同一个页面，各自用各自的 ChatGPT。报道还提到一个自动复核系统：对可能产生后果的操作，先对照用户指令、自定义规则和 OpenAI 内置的安全要求检查，再决定是自主执行还是需要批准。TechCrunch 提到页面可以挂常驻指令，并把这次发布定性为 OpenAI 正面迎战微软的办公套件；报道称演示文稿功能仍在陆续上线。Dots 的定价没有公布。

第一天就是个认真的产品。「ChatGPT 只是个聊天框，不是工作区」这句话，这周起不成立了。

Space 没有问的那个问题

Space 围绕一个真实的问题设计：一个团队和它的 AI 怎么一起写同一份文档而不互相踩脚？原地接受或撤销、署名、评论、对关键操作的自动复核，都是好答案。决定这篇对比的问题，在它再往后一步：

当 Agent 改了一个值，而别的 Agent、报表和应用会把它当事实来读，谁来决定它成立——这个决定又记在哪儿？

对一段文字点「接受」或「撤销」，审的是文字，审的人就是正在看的人，发生在写的那一刻。之所以好用，是因为读者和审核人是同一个人。记录里的一个字段不一样：下一个读它的往往不是人，而这次审核本身必须作为记录的一部分留下来——原来是什么、改成了什么、谁提的、谁认的。

自动复核回答的是隔壁的问题——这个 Agent 现在该不该执行这个操作？它保护的是操作本身，和「结果这个值该不该进入正式数据」不是一回事。截至 2026 年 9 月 30 日，OpenAI 没有描述带 schema 的记录库、针对 Agent 写入的字段级 diff 或提案、版本历史，也没有描述让 OpenAI 以外的 Agent 通过公开 API 或 MCP 访问 Space 的途径。

为什么这是结构性的差别

我们不认为这是下一个小版本就会补上的缺口，因为它来自两个产品各自为什么而生。

Space 的基本单位是文档，它的 Agent 是 OpenAI 自家的：ChatGPT、Codex、Dots，在 OpenAI 的产品里、带着你团队的上下文干活。正因为编辑器、模型、Agent 都归一家，协同编辑的体验才这么顺。

Busabase 的基本单位是 Base 里带 schema 的记录，旁边还有文档、技能和应用；它的 Agent 是你已经在用的那些：Claude Code、Cursor、Codex、OpenClaw，或者通过 MCP 接进来的 ChatGPT 本身。当三家厂商的 Agent 往同一份数据里写，审核就不可能长在其中任何一家的编辑器里——它只能放在数据的写入路径上，并且事后一直挂在记录上。

所以「AI 能不能在我们团队的材料上干活」，两边都说能。真正的分界是：这份材料是给人读的文档，还是给系统读的记录。

按你要做的事来比

看行，别看总数。如果你真正要做的是前三行，用 Space 就对了，这篇可以不往下读。

你要做的事ChatGPT SpaceBusabase
和团队、AI 一起写文档、演示和网站就是为此而生——和 ChatGPT、Codex、Dots 实时协同支持文档，但不是它的本行
@ 一下就把下一步交给 Agent可以——ChatGPT 或 Dot没有内置 Agent，你自带
保留 AI 写的文字之前先审一眼原地接受、修改或撤销重要写入走 Change Request
存带 schema、供 Agent 查询的结构化记录有电子表格和页面内表格；未见带 schema 的记录库Base 带类型字段，通过 API 和 MCP 读写
在值成为正式数据之前看到字段级 diff、提案人、审核人未见描述Change Request，连同历史挂在记录上
让 OpenAI 以外的 Agent（Claude Code、Cursor、OpenClaw）读写未见描述可以——MCP、Agent Skill 或 OpenAPI
管理员管分享和留存工作区与角色级控制、保留策略、Compliance API（Enterprise）空间成员角色；凭据的权限决定写入是直接合并还是等待审核
跑在自己的机器上，或者读源码未见描述——由 OpenAI 托管可以——MIT、本地优先、可自托管

ChatGPT Space 确实更好的场景

这一节不是客套。

团队本来就在 ChatGPT 里。

任何工具最难的都是让人用起来。大家每天早上都会打开 ChatGPT，长在里面的工作区，胜过一个更好但要专门记得去打开的。

交付物就是文档、演示或网站。

Space 就是为 AI 原生的页面、演示和小网站、多人实时一起写而做的。Busabase 的文档编辑够用，但不在一个量级。

你要的是能接着干活的 Agent。

有自己云端电脑和浏览器、在页面上 @ 一下就接手的 Dots，和数据库是两种帮手。我们没有对应的东西。

你要托管、要管理员控制。

Enterprise 的分享控制、保留策略和 Compliance API，什么都不用部署、不用升级。对很多公司来说，这比本页其他内容都重要。

什么时候你需要别的东西

Agent 的产出会被当成事实来读。

记录会喂给下一轮 Agent、报表、公开页面或 API 调用方，错值在有人看到之前就传出去了。

你的 Agent 来自不止一家。

一个仓库用 Claude Code，另一个用 Cursor，OpenClaw 定时跑，ChatGPT 做调研——全都写同一份数据。

你得说清一个值是谁提的、谁批的。

针对的是记录里的一个字段，包括它改之前长什么样——不是页面上的一段话。

数据必须留在你自己的基础设施上。

自托管、数据驻留，或者需要能读存数据的那段代码。

在找 ChatGPT Space 的替代品？

要看你想替代的是 Space 的哪一半，两半的老实答案不一样。

如果你要的是「和 AI 一起写团队文档、演示和网站」的替代品，Busabase 不是。继续用 Space，或者看看别的文档套件——那不是我们做的事。

如果你要的是一个地方，让 Agent 产出的数据有结构、经审核、任何 Agent 都能用——每条记录都带提案人、审核人和历史，开源，能跑在你自己的机器上——那 Busabase 在这件事上是替代品。更多时候它是补充：文档留在 Space，Agent 产出的记录放进 Busabase。

Busabase 的做法不同在哪

重要的写入可以先变成一份 Change Request，而不是一次静默修改。提案带着字段级 diff、提出它的 Agent，以及依据来源。人打开它，看清到底会改什么，然后批准、评论或驳回。到这一步它才成为正式数据——而且提案人、审核人、提交和历史会一直挂在这条记录上。

有三件事它刻意不是：

它不是每次写入都要人批。审核与后果成正比——低风险操作照样快，密钥有合并权限的 Agent 直接合并。决定权在密钥的权限级别，而不是一刀切的规则。

它不绑定某一家 Agent。同一个 Base 可以通过 MCP、Agent Skill 和 OpenAPI 访问，提出一个值的 Agent 和下一个读它的 Agent 可以来自不同公司。

它也不只是托管服务。Busabase 采用 MIT 协议、本地优先：npx busabase server 就能在你自己的机器上起一个工作区；想要托管时，还有 Busabase Cloud。

两个一起用

对很多团队，最顺的安排是两个都用。人和 Dots 在 Space 里起草、讨论、做演示。当某个结论需要变成一条记录——一次供应商决策、一次客户信息更新、一个价格、一次政策例外——ChatGPT 通过 MCP 把它作为提案写进 Busabase，负责人审过字段级改动，之后其他所有 Agent 都从这里读到已确认的值。

这条链上有两道审核，保护的东西不同：ChatGPT 的应用确认保护的是这次工具调用；Busabase 的 Change Request 决定这些字段能不能成为正式数据。如何把 ChatGPT 接入 Busabase。

老实说说局限

Busabase 比 OpenAI 做的任何东西都年轻、都小。它没有 Space 那种水准的实时协同编辑，没有演示文稿，也没有会自己出去帮你干活的内置 Agent。如果你按「和 AI 一起写东西的日常体验」来评，Space 赢，而且赢得不悬。

Busabase 也不是应用后端——不做 OLTP，不接高频机器写入，不做向量召回。那是 Postgres 和向量库的活。

还有，这篇写于发布次日。OpenAI 迭代很快，文中好几处「未见描述」都可能变化，变了我们会更新。

常见问题

ChatGPT Space 对 AI 的改动有审核环节吗？
有，两种。页面上 AI 生成的文字可以原地接受、修改或撤销；发布报道还描述了一个自动复核系统，会检查可能产生后果的操作，必要时要求批准。截至 2026 年 9 月 30 日未见描述的，是针对结构化记录的字段级 diff 或提案，以及版本历史。
Claude Code 或 Cursor 能写进 ChatGPT Space 吗？
截至 2026 年 9 月 30 日，OpenAI 没有描述面向非 OpenAI Agent 的公开 API 或 MCP 访问方式。Space 是围绕 ChatGPT、Codex 和 Dots 设计的；从 Google Drive 等连接应用链接进来的文件保留原有权限。
ChatGPT Space 算数据库吗？
它有电子表格，页面里也能放表格。但 OpenAI 没有把它描述成一个存放带 schema 记录、供其他系统读写的地方。那正是 Busabase 要做的部分。
ChatGPT 能往 Busabase 里写吗？
能，通过 MCP，在 ChatGPT 的应用管控和 Busabase 密钥的权限范围内。如果给的是提案级密钥，它的写入会作为 Change Request 进来，等人审核。
Busabase 是不是每次 Agent 写入都要人批？
不是。审核与后果成正比，是立即合并还是等人，由密钥的权限级别决定。
ChatGPT Space 能自托管吗？
截至 2026 年 9 月 30 日，未见自托管或数据驻留选项的描述。Busabase 用 npx busabase server 就能在你自己的机器上跑，也可以部署在你自己的基础设施上。

下一步

想看写入路径长什么样而不是读它的描述，最快的路是在自己机器上运行 npx busabase server，接上 ChatGPT 或你已经在用的 Agent，看一份 Change Request 真的进来。

把 ChatGPT 接入 Busabase · 接入其他 Agent · 浏览模板 · 阅读文档 · 什么样的存储才算 AI Agent 的记录系统

来源——OpenAI：ChatGPT Space 概览、Space 中的 Pages、ChatGPT Space 企业版管理。发布报道（2026 年 9 月 29 日）：VentureBeat、TechCrunch。关于 Dots 和自动复核的内容来自发布报道，而非 OpenAI 文档。OpenAI 迭代很快，本页陈述的是上述核实日期时点的公开信息。