ChatGPT Space 和 Dots 把 Agent 请进了文档，那它们写下的「事实」谁来审？

2026 年 9 月 29 日的 DevDay 上，OpenAI 把 Agent 正式请进了文档。人、ChatGPT、Codex，以及一种新的常驻 Agent——Dots，现在可以在同一个页面里同时工作。承载这一切的产品叫 ChatGPT Space。

这是真正的一步，值得认真对待。但它也留下了一个在发布周很容易被忽略的问题：文档是 Agent 跟你说话的地方；而记录，是下一个 Agent、周一的报表、面向客户的应用当作事实去读的东西。Space 把前者做得很好。这篇文章谈的是后者。

发布了什么

• Space 是团队在 ChatGPT 里的家。 OpenAI 帮助中心的说法是「存放你的页面、文件以及与 ChatGPT 共同工作的地方」。里面有 Pages（可编辑文档）、表格、演示文稿、Sites（用 ChatGPT 搭建的网站和小工具）、图片和上传文件，可按主题或团队分成不同的 space。对 Pro、Business、Enterprise 用户，它取代了原来的 Library。据 TechCrunch，Slides 会在「未来几周」陆续开放。
• Dots 是常驻的 Agent 同事。 VentureBeat 的描述是：一种「在员工关掉聊天窗口之后仍继续工作」的持久 Agent，每个都有自己的云端电脑和浏览器。在页面里 @ 一个 Dot 或 ChatGPT，它就接着往下做。页面还可以挂上常设指令——Sam Altman 举的例子是：定时查看团队频道，把发现的内容更新到页面上。
• 所有人实时编辑同一个页面。 「多名有编辑权限的员工可以同时编辑同一个 Page，每个人都用自己的 ChatGPT 对着这份共同的文档工作。」在可用时，「Show attribution」能显示每段内容是谁贡献的。
• 生成的文字就地审阅。 Pages 文档写道：「在原处审阅生成的文字。你可以接受、要求修改，或撤销。」
• 有后果的操作会先过一道自动检查。 一套「自动审查系统会根据用户指令、Custom Rules 和 OpenAI 内置的安全要求，检查可能产生后果的操作」，再决定是自主执行还是等人批准。Custom Rules「可以允许特定操作、要求批准，或直接禁止」。

目前面向 Pro、Business、Enterprise，先上网页版和桌面版，移动端稍后。额外 Dots 和更高容量的价格，OpenAI 尚未公布。

OpenAI 做对了什么

到目前为止，大多数「文档里的 AI」其实是一个按钮：选中文字、改写、贴回去。Space 走得更远——它让 Agent 成为共同工作的参与者，而不是某个人手里的工具。

有三个设计值得点名：

1. 共享上下文，而不是各聊各的。 每个人带着自己的 ChatGPT，但大家对着的是同一个页面。团队用 AI 最常见的毛病——五个人在五个对话里拿到五个答案，没人知道最后哪个进了方案——在这里被直接消除了。
2. 审阅就在文字所在的地方。 接受、要求修改、撤销，都在原处完成。你在上下文里判断生成的内容，而不是在侧边栏里。对写作来说，这就是对的形态。
3. 自主，但前面有一道检查。 自动审查加上可以「允许 / 要求批准 / 禁止」的 Custom Rules，是一道货真价实的执行前控制。一个有自己浏览器、全天候运行的 Agent 正需要这个，而 OpenAI 第一天就把它带上了，没有留到以后再补。

如果一个团队的产出主要是文字——方案、简报、会议纪要、发布文档——Space 就是很好的默认选择，很多团队不需要别的。

文档是 Agent 说话的地方，记录是 Agent 读取的东西

现在，跟着一份工作走出页面看看。

设想一个 Dot 挂着常设指令：盯着销售频道，保持客户计划是最新的。周二它写下：这家客户的续约日期推迟到了 3 月，合同金额 8.4 万美元。客户负责人看了一眼，读起来没问题，点了接受。

这段话从此承担了两份工作。对页面里的人来说，它是文字：是上下文，随时可以重读，说一句就能改。对下游的一切来说，它是断言。预测 Agent 读取续约日期；财务报表读取合同金额；一个用 Codex 搭续约看板的任务两者都读。它们没有一个是像客户负责人那样「看」这段话的，也没有一个知道，它是在两个会之间用四秒钟被接受的。

Space 描述的两种审阅机制都是真的，但它们瞄准的是不同的东西：

前两种在 OpenAI 的文档和媒体报道里都有描述。截至 2026 年 9 月 30 日，第三种没有：我们没有找到关于带 schema 的结构化记录、针对 Agent 写入的字段级 diff 或「提案—合并」流程，以及页面版本历史的描述。页面里可以放表格，所以结构本身是可能的；没被描述的，是这样一个地方——一个被改动的值以提案的形式到达，带着旧值、新值和来源，在任何东西把它当真之前。

这不是文档产品的缺陷。文档是为人读而优化的，人读页面时会带上自己的判断。缺口只在下一个读者不是人的时候才出现。

是哪些 Agent？

第二个悬而未决的问题是：谁在这个房间里。Space 围绕的是人、ChatGPT、Codex 和 Dots。截至 2026 年 9 月 30 日，OpenAI 尚未描述让其他厂商的 Agent 读写 Space 内容的公开 API 或 MCP 接入。

作为首发范围，这完全合理，但和今天很多团队的实际工作方式不一样。2026 年一个典型的研发或运营团队会同时用好几个 Agent：仓库里是 Claude Code，编辑器里是 Cursor，后台任务交给 Codex，调研在 ChatGPT 里做，再加一两个定时跑的智能体。如果这些 Agent 共同依赖的事实只住在某一家厂商的工作区里，其他 Agent 要么够不着，要么只能读副本。

这个季度可以做的四件事

几周之内，Space 就会到很多团队手里。在 Agent 开始大量往里写之前，有四个决定值得有意识地做：

1. 把产出分成「文字」和「记录」两类。 发布简报是文字。续约日期、价格、编制人数、准入供应商名单、政策阈值——这些是记录，哪怕它们第一次出现是在一段话里。把清单写下来，它比你想的短。
2. 给记录一个有 schema、带来源的位置。 会被其他 Agent 消费的事实应该落在字段里，附上支撑它的来源、以及提出它的是哪个 Agent 或哪个人。段落可以链接到记录，但不应该就是记录。
3. 审核强度与后果成正比。 不要给每次写入都设关卡——那样人会开始不看就点通过，最后等于什么都没审。只卡重要的写入：会改变金额、承诺、合规，或客户所见内容的值。其余的照样快。
4. 记录系统保持 Agent 中立。 每项工作用最合适的 Agent，包括 Dots。但事实所在的地方，应该以同一套规则接受所有 Agent 的写入——这样换一个或加一个 Agent，不意味着要把「真相」搬家。

Busabase 的位置

Busabase 是面向 AI Agent 的开源数据库与工作区——agent 和人共用同一份结构化数据、文档、技能与应用，重要写入经审核成为可信记录。

它的定位是和 Space 这样的工具并存，而不是取代它。写作、规划、讨论继续在页面里做；当一份工作产出了会被其他 Agent 读取的事实，就把它送进 Busabase 的记录。ChatGPT 现在就能做到：通过它的 MCP 应用，ChatGPT 可以读取 Busabase 并提出记录；给它提案级权限时，结果会以带字段级 diff 和来源的 Change Request 到达，而不是悄悄成为正式数据（连接 ChatGPT）。Claude Code、Cursor、Codex 等其他 Agent 通过 MCP、Agent Skill 或 OpenAPI 写入同一批记录，遵守同一套审核规则。低风险的写入，以及本来就有合并权限的密钥，会直接通过。

它是 MIT 许可的，一条命令就能在本地跑起来，不需要账号：

npx busabase server
# → http://localhost:15419/dashboard/local

想看范围、共享、Agent 接入和数据驻留的逐项对比，可以读 Busabase 与 ChatGPT Space 对比。里面同样写明了 Space 更合适的场景。

---

利益相关声明：我在 Busabase 工作。在「记录应该放在哪」这件事上我们并不中立，所以上文关于 ChatGPT Space 的每一处说法，都引自或限定于 OpenAI 和媒体在核实日之前公开的内容。凡写「未描述」的，意思是我们找过但没找到，而不是它做不到。

来源：ChatGPT Space 帮助中心、使用 Pages、ChatGPT Space 企业版说明、VentureBeat：Dots 与 Space、TechCrunch：发布报道。核实于 2026 年 9 月 30 日。Space 前一天才发布，变化会很快，依赖任何细节之前请先查看一手来源。