Busabase = Vercel + Notion + Supabase + Skill Manager
朋友以为 Busabase 就是 Vercel。更贴的等式：部署 + 文档 + 数据 + Context + Skill Manager——换模型也能接着干，而不是锁死在某一个厂商会话。
Busabase = Vercel + Notion + Supabase + Skill Manager
朋友散步时问：Busabase 不就是部署个网站吗？跟 Vercel 差不多啊。Agent 怎么协作？我平时用 Cursor、Codex、龙虾，也能自己搞一套啊。
问题不在「能不能上线一个页面」。问题在：做完之后，下一个 Agent 还能不能接着干——还是一切又锁回某一台电脑、某一个厂商会话里。
一句更贴的说法是：
Busabase ≈ Vercel + Notion + Supabase + …… + Context + Skill Manager
不是其中任何一个单独拿出来；是叠起来之后，才变成「人与 Agent 共用的工作底座」。
旧错觉：以为在「部署」，其实在堆绑定
以前那套流程大家太熟了：
做一个网站 → 找 Vercel 部署 → 再接 database → HTML / 文件不知扔哪 → 协作靠再买身份认证、再买共享 → 搞不定就卡住。
这不是夸张。它解决的是「给人看的站点能不能打开」。
它不解决：「我换一个大模型，还能不能接上刚才那个项目做到一半的事」。
会话停在 Codex 里，Skill 只在这部电脑的龙虾能用——外面开不了电脑、额度用光、想换 Muse / Cursor / 另一个 Agent：你调的不是「同一份工作」，你调的是私有记忆和本机文件。那不叫协作，叫搬家。
换模型不难。难的是 Skill 锁在一台电脑上。
等式拆开：每一层你其实都缺过
朋友拿 Vercel 来比，是因为看见了「能上线」那一层。拆开看：
| 层 | 你以为自己在买 | 真正缺的 |
|---|---|---|
| Vercel | 部署 / 托管 / 打开一个页面 | 工作区身份与托管，而不是只给人看的静态站 |
| Notion | 文档、wiki、协作白板 | Agent 也能引用的 Doc，而不是只给人扫一眼的页面 |
| Supabase | Database / API | 结构化记录与关系——下一个 Agent 能读的事实 |
| Skill Manager | （多数栈根本没有这一层） | Playbooks / Skill：操作手册放进共享底座，任意接入的 Agent 动手前先查 |
| Context | （散落在会话和本机） | 项目上下文不绑死在某一个供应商会话里 |
拼起来，才是官方那句：
The System of Record for AI Agents
不同 Agent，同一个共享底座。
打开一个 Base，跟接入的 Agent 说：初始化、连进来。Skill、文档、应用落进同一棵工作区节点树；身份与权限是工作区的一部分——谁登录、谁只读、谁的写入要进审核——而不是事后再拼三家 SaaS。
为什么 Context + Skill Manager 才是换模型的关键
Agent 本身没有记忆。这不是缺陷，是设计：会话可以换，模型可以换；留下来的是结构化记录、文档、Skill 和应用。Playbooks 把 Skill 收成目录，接入的 Agent 动手前先查「这个空间里这件事该怎么做」。
举个具体的：
你有一个炒股 Skill，只躺在这部电脑上——龙虾用得到，Muse 用不到。
把它放进 Base——龙虾接入能用，Muse 接入也能用。你就可以随便切换 AI，而不必把半成品会话绑死在某一家。
多人公司也一样：一千个人可以有一千个不同的 Agent，但共享同一套 Skill 与同一份事实。协作不是「Agent 之间神秘开会」；多数产品里所谓 Agent 协作，本质仍是会话。真正能跨工具、跨人续上的，是共享的 System of Record——Context 在底座里，Skill Manager 管手册，而不是管某一个厂商的聊天记录。
也别被「给 AI 塞一个记忆文件」骗了。文件摆在某一个 Agent 私有上下文里，你会锁死它——日后加价、换工具、换会话，你都得照付迁移税。主张很简单：不要把记忆绑死在某一个 AI 里；要绑，就绑在可换 Agent 的共享底座上。
写入怎么管：Change Request，而不是黑盒改库
只共享、不管控，工作区会变成不可审计的泥潭。
Busabase 的写法是：Agent 读工作区上下文 → 写入一律以 Change Request 提交（带说明、字段级 diff、作者与历史）→ 由权限决定当场合并，还是进 Inbox 等人审 → 改动可查看、可追溯、可撤回。
Agent 读取工作区（Context + Skill）
↓
写入数据 / 文档 / Skill / 应用改动 → Change Request
↓
权限：当场合并，或等待审核
↓
可检查 · 可归因 · 可撤回
这才是「多 Agent 接同一份库」时站得住的协作：不是把记忆塞进某一个供应商，而是把事实与方法留在人和 Agent 都能打开的地方。
权限：方向清楚，粒度仍在演进
Cloud 侧已有 Space、角色、身份，以及「写权限当场合并 / 只能提 Change Request」这类边界；节点也有 ACL。运营场景里常见的诉求——每个客户一个文件夹、多数 Agent 只读、少数 Operation Agent 可写——正是我们要把数据权限做清楚的方向。
说一句老实话：细粒度「谁能看见哪份客户数据」仍在补齐，不该装成已经完工的营销话术。但产品模型是清楚的：共享 Skill 与共享事实在先；权限把读/写与审核边界钉住；Change Request 让每一次写入可审。
这跟「再买一个 Vercel」差在哪
| 单点工具（Vercel / Notion / DB…） | Busabase（叠起来） | |
|---|---|---|
| 主要交付 | 页面、文档或库表之一 | 人与 Agent 共用的记录、文档、Skill、应用 |
| 换模型 / 换 Agent | 会话与本机手册常要重讲、重拷 | 连上同一 Base；Context + Skill Manager 还在 |
| 协作 | 再买身份、共享、权限拼装 | 工作区身份 + 权限 + Change Request |
| Agent 记忆 | 容易锁进厂商会话或本机文件 | Agent 无状态；工作留在工作区 |
你可以继续用 Vercel 发站点、用 Notion 写给人看的稿、用 Supabase 扛某一类 API。那都是另一件事。
Busabase 解决的是：Agent 干活的 Context 和 Skill，别再散落在会话和本机里。
下一步
打开 busabase.com，起一个 Base，把你正在用的 Skill 放进去，再换一个 Agent 接上——看它能不能接着干，而不是让你再讲一遍项目。
相关阅读：别再做 AI 读不了的软件 · Busabase 解决的是什么