产品对比

Busabase 与 Sanity：给 AI Agent 用，差别在哪

最难的那一步，Sanity 比几乎所有人都做得早：它的 Agent Actions 默认不会改动已发布的文档——Agent 的写入会落进草稿，仍然需要人来发布。所以这篇不是「谁有审核」的对比，两家都有。真正的问题是：各自审的是什么，以及这些工作接下来要去哪。

Sanity 是内容操作系统，工作的终点是读者会看到的东西；Busabase 是 Agent 工作区，终点是其它 Agent、人和应用会当作事实来读的记录。这是两件不同的活，对很多团队来说答案是两个都要。

核实日期：2026 年 9 月 21 日，依据 Sanity 公开的 Agent Actions 文档。

一句话结论

选 Sanity

：Agent 的产出是要交付给受众的内容——网页文案、多语言营销、商品描述、编辑内容。它的 schema、本地化和发布流水线就是为这个造的，Busabase 不跟它抢。

选 Busabase

：Agent 的产出是运营性记录——补全的数据、调研、文件、可复用技能——被下一轮 Agent、内部应用或 API 调用方读取，而不是发布给读者。

两个都用

：Agent 在一边调研和维护底层事实，在另一边发布由这些事实支撑的内容。交接很自然，因为谁也没想当对方。

Sanity 今天到底提供了什么

依据它公开的文档写，不靠印象。

Sanity 把自己定位成「AI 时代的内容操作系统」，讲的是把内容变成一个受治理的知识层，同时驱动应用和 AI Agent。三块和这里有关：

Sanity Context 通过单个 MCP 端点暴露 schema 和 GROQ，让 Agent 在一次查询里跑过滤、关键词匹配和语义排序。Agent Actions 是事件驱动、理解 schema 的 API，由数据集变更触发，用来生成、转换或翻译内容。Content Agent 是对话式助手，做跨项目的批量编辑、内容审计和缺口分析。

而值得给它信用的是这一条：「默认情况下，Agent Actions 绝不会改动已发布的文档。当你提供一个已发布文档的 ID 时，操作会先创建草稿，再施加任何改动。」如果操作是针对已发布文档运行的，新值「会被写入一个新的草稿文档，并且需要被发布。」

这是一道真实的写入前关卡，而且默认开启。它可以关掉——forcePublishedWrite: true，以及标了 liveEdit: true 的 schema 本来就是那样——但安全路径是默认值，这和大多数工具放开 Agent 写入的做法正好相反。

那真正的差别在哪

两点，而且都不是「谁有审核」。

审的单位不同。Sanity 的单位是文档：审核者判断这一版文档该不该发布。Busabase 的单位是改动：审核者看到的是字段级 diff、提出它的 Agent、以及依据的来源，判断这个值该不该成为正式数据。审一整份草稿和审一个被改动的字段是两种不同的活——前者适合一个会被人读的页面，后者适合一行会被查询的记录。

工作要去的地方不同。Sanity 的内容经由发布流水线走向受众；Busabase 的记录走向被消费——下一轮 Agent、一块看板、一次 API 调用、一个把它当上下文读的技能。Busabase 里没有 Sanity 意义上的「发布」，它是成为正式数据，然后被机器和同事读取。

这也解释了范围的差异。Sanity 在内容上很深：本地化、发布批次、排期、素材流水线、编辑角色。Busabase 在工作区上很宽：结构化 Base、文档、文件、可复用技能，以及建立在同一份数据上的小应用。

按你要做的事来比

你要做的事SanityBusabase
把内容发布给受众正是本行不是它的活
本地化、发布批次、排期成熟，一等公民很弱
默认不让 Agent 碰线上内容会——默认落草稿会——重要写入走提案
审核的单位文档版本被改动的字段，带 diff
看到是哪个 Agent 提的、依据什么来源其 Agent 文档未描述挂在记录上
存放其它 Agent 当事实读的数据可通过 Context/GROQ 实现就是为这个设计的
数据旁边放可复用技能和小应用没有有
自己部署、读源码托管平台开源、本地优先、可自托管
接入任意第三方 AgentMCP 端点MCP、Agent Skill 或 OpenAPI

Sanity 确实更好的场景

产出是要发布的内容。

如果 Agent 写的东西最终出现在网站或用户会读的应用里，Sanity 的整条流水线就是为此存在的，我们没有。

规模化的多语言。

带翻译工作流的多语言内容在那边是已解决的问题，在这边是手工活。

你本来就有内容团队。

编辑角色、审核队列、发布排期都很成熟，Content Agent 也理解这种工作形态。

结构化内容建模才是你问题的难点。

GROQ 和它的 schema 工具确实强，而 Sanity Context 用一个 MCP 端点同时暴露两者，是个漂亮的设计。

什么时候你需要别的东西

Agent 的产出从不发布——它是别的软件要读的运营数据。

你需要知道是哪个 Agent 提出了某个值、依据什么证据，而不只是哪一版文档上线了。

可审的单位是字段而不是文档。为了接受一个更正过的数字而批准整份草稿，形状就不对。

工作区里要装的不止内容：Agent 复用的技能、它产出的文件、读同一批记录的小应用。

必须跑在自己的基础设施上，或者你需要能读那段代码。

两个一起用

Busabase 存事实，Sanity 发布这些事实支撑的内容。

Agent 在 Busabase 里做市场调研、补全记录、标注来源，人审重要写入。通过审核的记录经 Busabase 的 API 被需要它的东西读走——其中一部分要变成对外内容时，去 Sanity 里起草和发布，那本来就是它的活。两个产品谁也没干对方的活，谁也不需要被替换。

老实说说局限

Busabase 完全没有 Sanity 那样的内容流水线。没有本地化工作流、没有发布排期、没有素材转换、没有背后打磨了十年的编辑角色体系。如果你按内容运营来评，Sanity 赢，而且不悬。

而且 Sanity 的草稿优先默认值也意味着：这篇对比里两个产品的差距，比我们写的其它几篇都要窄。如果文档级审核对你的工作已经够了，字段级提案那点额外精度不值得你换。

常见问题

Sanity 会让 Agent 直接写已发布内容吗？
默认不会。Agent Actions 会先建草稿；要直接写已发布内容，需要 forcePublishedWrite: true，或者 schema 标了 liveEdit: true（那本来就是这个行为）。
那 Busabase 多提供了什么？
不同的审核单位和不同的来源追溯。你看到的是字段级 diff、提出它的 Agent、以及依据的来源——而不是一整份草稿文档，让你选择发布或丢弃。
两个能在同一套技术栈里吗？
能，而且这是常见形状：事实和 Agent 的工作材料在 Busabase，对外发布的内容在 Sanity。
Busabase 是 CMS 吗？
不是。它能存文档、也能给网站供数，但内容运营——本地化、排期、编辑流程——不是它造出来要做的事。
重度用 Agent 的内容团队该先上哪个？
如果产出是交付给读者的，先上 Sanity。如果 Agent 的调研和记录才是值钱的部分、发布只是它的下游，先上 Busabase。

下一步

如果你想看的是字段级审核这条路径长什么样，而不是读它的描述，接上你已经在用的 Agent，看一条重要写入以「你可以检查的形态」到达。

什么样的存储才算 AI Agent 的记录系统 · 全部对比 · 接入你的 Agent

来源：Sanity、Agent Actions、Agent Actions 操作文档、Sanity Context。引文为 Sanity 在上述核实日期的公开原话。