关于：为什么我们做 Busabase

序：座

观音坐在莲花上。

换一尊菩萨，莲花座还在那里。

我们给这个产品起名 Busabase，取的不是菩萨，是那个座。菩萨再厉害，也要有个地方坐。Agent 再厉害，也要有个地方放东西。

这篇文章讲的是我们怎么想明白这一点的。

一、五千年，一直在让更多人看得见

五千年前，人类最早写下来的东西，不是诗，不是神话。

是账。

乌鲁克的泥板上记的是大麦、牲口和欠款。文字不是为了抒情发明的，是为了记录发明的。人类靠记录协作。没有记录，就没有超过一个村子的组织。

此后每一次文明的跃迁，都伴随一次记录方式的跃迁。而每一次跃迁做的都是同一件事：让更多人看得见。

泥板，只有书吏读得懂。1494 年帕乔利写下复式记账法，商人读得懂了。1855 年一家铁路公司画出第一张组织架构图，管理者看得见组织了。1970 年 Codd 提出关系数据库，机器读得懂了——但人又读不懂了。直到 Excel。Excel 是有史以来第一个让十亿普通人握住数据的工具。

然后 Agent 来了。

它是五千年来第一种默认不留记录的劳动力。它干完活，留下的是硬盘上的代码，和聊天窗里的一段话。前者只有工程师读得懂，后者读完就散。

五千年来第一次，记录的跃迁往回走了。

二、三十个 Agent 进了公司

2026 年初，我们让三十个 Agent 进了公司。

每个同事配一个。各自的网盘，各自的会话，各自的文件。有人拿它写方案，有人拿它跑数据，有人拿它管客户。头几周所有人都很兴奋——一个 Agent 确实好用，比前一年任何工具都好用。

然后行政把工资表上传给了 Agent，因为它需要这份数据来干活。

几天后，一个程序员对着同一个 Agent 很诚恳地说：「请你努力找一下，我的工资是多少。」

我们没有防着这件事。不是疏忽，是它本身就处在一个两难里：你想让 Agent 更聪明，就得把更多数据喂给它；可喂进去的数据里，有些不该让所有人看见。数据越丰满，Agent 越强，那堆东西也越危险。

那一刻我们看清了一件事：所谓一个 Agent，本质上就是一堆文件加一个网盘。它没有权限，没有边界，没有版本。谁都能往里放，谁都能往外拿。你以为你在划分 Agent，其实你只是在划分文件夹。

一个 Agent 很好用。很多 Agent，不 work。

1975 年，Brooks 警告说：往一个延期的项目里加人，只会让它更延期。我们加了三十个 Agent。人是少了。管理成本没有少，事情也没有变简单。

三、我们把老思维原样搬了进来

问题不在 Agent。问题在我们又按「人」来分了。

组织架构图画的是人：谁归谁管，谁向谁汇报。之后一个半世纪，我们发明的一切管理工具——岗位、部门、KPI、绩效、协作软件——都在管人。

SaaS 时代，一个部门一套软件：销售用 CRM，市场用营销工具，财务用财务系统，数据各归各。我们叫它数据孤岛。

Agent 来了，我们做的第一件事，是给每个人配一个 Agent。一人一个，一人一个网盘，一人一堆会话。

于是数据孤岛变成了 Agent 孤岛。比 SaaS 时代更碎——SaaS 至少一个部门一套，Agent 是一个人一套。

这就是「Agent 越多，公司越没变好」的真正原因。Agent 越多，越像一个人越来越多的公司：热闹，但事情不一定变好。人多的公司尤其容易陷进去。你以为多了三十个员工，其实多了三十个互相看不见的抽屉。

Agent 不是失败的那个。它们各干各的，谁也接不上谁。

四、过程，和结果

一个公司要成的是事，不是养人。

Agent 和它的会话，是过程——干活的过程而已。Agent 留下来的东西，才是结果。

一个 CEO 打开公司，看到几千个 Agent、几万条会话，他不会觉得公司变好了。他会问：所以，东西呢？

所以我们要把这件事反过来。先定义要什么结果，再看需要什么。

绝大多数公司的事情，其实就那么几类：营销、销售、产研、综合管理（含财务）。不超过五类。一个网红工作室，一个电商团队，一个好莱坞制片公司，一个二十人的创业公司，拆开来都是这几件事。

不该按 Agent 分类，该按结果分类。 先把部门和 Agent 的角色放到一边，看事情。

一旦按结果分类，几件事会自己变清楚：

第一，用不到十个 Agent。 少数几个 Agent，配几个不同的 Skill，就把事做完了。给每个人训练一个自己的 Agent，成本极高，而且没有意义。我们不该以 Agent 越来越多为骄傲。

第二，Agent 应该是过客。 用完就走，随时可换，模型也随时可换。今天用 Claude Code，明天用 Codex，后天换一个更便宜的——没关系，因为东西不在它那里。

第三，真正要管的不是 Agent，是事情。 或者叫数据管理，或者叫 context 管理。你需要一个 shared space，把事情的上下文放在那里，让所有 Agent 和所有人都从同一个地方读写。

留下来的，是那个放结果的地方。那就是座。

五、十年前，同一件事的另一面

我们认得这个座，因为我们做了十年。

十年前，我在一家企业里做内部系统。采购来的 SaaS 都是标准化的，满足不了需求，于是全公司的人都在用 Excel 处理数据——每个人一张表，每张表一个版本。我做了「数据库多维表格」这种东西，让团队不用写代码也能搭出自己的数据应用。那就是 Vika。

那时候，做软件很难，管数据很容易——数据就在 Excel 里，谁都看得见。

今天反过来了。AI 编程让做一个定制应用变得很简单，几句话就出来。可数据变得难管了：它散在几十个 Agent 的网盘和会话里，谁也看不全。

十年前的瓶颈是造应用。今天的瓶颈是留数据。 同一个问题翻了个面，我们在两面都站过。

六、为什么不让它全自动

说到这里，有人会说：那就全自动吧，让 Agent 自己往座上放东西，人别管了。

我们反对。

Agent 干的每一件事，最终都是给另一批人用的。营销 Agent 写的文案是给客户看的，销售 Agent 整理的线索是给销售用的，财务 Agent 出的报表是给老板看的。所谓品味、所谓判断，就是判断这个产出有没有满足那批人。

好不好，是人说了算的。连模型本身，也是人喂出来的品味——是人先告诉它什么叫好，它才知道什么叫好。

所以执行可以全交给 Agent，判断要留给人。人要做的，是根据数据和事情去判断，而不是不停地去造 Agent。

这里有一个工程问题。Git 给了代码一个「合并」按钮：谁改的，改了什么，能不能退回去，一清二楚。可数据库、文档、表格、文件——公司里绝大多数的东西——从来没有过这个按钮。

以前没有也就算了，人改得慢。现在 Agent 干活这么快，一分钟能改几百条，没有这个按钮就是灾难。

Agent 做的任何一件事都必须满足三条：人能追溯，能回滚，有历史。

在 Busabase 里，Agent 不直接写。Agent 提议，人合并。每一次改动都是一个变更请求：谁提的、改了什么、谁批的、什么时候合并的，全在。批错了，回滚。

企业落地 AI，买的不是 Agent 有多聪明。企业买的是确定性。我们做的一切，都是为了确定性。

七、Apps for Agents：一种新的形态

Agent 往座上放东西，人来审——那人怎么看？

这就要说到我们主张的一件事：Build Apps for Agents。

一般来说，Agent 是 Agent，App 是 App。App 是给人点的，Agent 是跟人聊的。

但我们说的「Apps for Agents」是另一种东西：一个 App，由 Agent 去操作，人扮演观看和微调的角色。

反过来也成立：你造一个 Agent，它就得配一个 App。Agent 需要一个地方把结果摆出来，人才看得见、审得了。光有聊天窗口，人什么都看不见。

所以它既不是单独的 App，也不是单独的 Agent。是一种新形态。

它长什么样？一张朴实无华的表——本质就是个数据库。你点一下，它变成一个 CRM。Agent 读的是左手边那份数据，人看的是右手边那个界面，同一份东西。你需要看板，它长出看板；你需要日历，它长出日历。像贾维斯一样，随叫随到。但底下永远是同一个数据库。

我们以前习惯的软件开发和部署方式——写代码、发版本、部署上线——恰恰是最难落地的那一环。而这种 App 是随机应变的，不是固定的。

你不再「开发」应用。你召唤它。

八、每天的画面

我们一直在找 AI 落地的最佳实践。拿自己团队做实验，现在大概是这个画面：

以事情为起点。 每天打开，看到的是各种待办事项和结果的看板，不是 Agent 列表。看板每天都在变。事情之外，再去接 Agent。从 Agent 开始的一天，是从聊天窗口开始的——乱。从事情开始的一天，是从「今天要成什么」开始的。

承载数据结构。 所谓事情，就是各种数据结构：数据库、文档、Skill、文件。放在一个工作区里。

满足双向需求。 它既要让人看得舒服——表格、看板、文档、应用；也要让 Agent 读写得顺——结构化、有接口、有权限。

随机应变的应用。 上一节说过了。

具体的流程就两步。打开工作区——手机也行——看到应用、事项、数据。基于这些数据，面向不同的人和不同的 Agent，继续改造。

这个工作区，我们叫空间站。一个人可以有一个，放几个 Agent；后来再放进别的人。它从一个人开始，长成一个团队。

这真的就是一个 shared space。A shared, structured environment——人和 Agent 一起在里面干活。

我们有一条判断 AI 有没有真正落地的标准：它能自循环、自进化；同时人可以随时介入、随时微调。 我们自己的 SEO 就是这么跑的：每天 Agent 出一份报告，报告生成 issues，人决定做不做，做了就写文章，文章上线，再出下一份报告。

老实说，我们目前没有哪个环节完全达到这条标准。研发的那部分都还没有。但我们看到曙光了。

九、看不见的时代

智能会变得无限便宜。这一点我们和 OpenAI、Anthropic 看法一致。

但有一件事在同时发生：Agent 时代正在以普通人读不懂的形式发生。

Agent 干的活，以两种形式存在：硬盘上的代码，和聊天窗口里的文字。前者只有工程师能读，后者读完就散。一个做电商的、一个做行政的、一个拍视频的，看不见他的 Agent 到底做了什么、改了什么、留下了什么。

看不见，就谈不上掌控。掌控从来是看得见的函数。

五千年来每一次记录的跃迁，都是让更多人看得见。Agent 是第一次倒退——它的产出回到了只有工程师读得懂的形态。

如果没有人做这个座：十亿人在用 AI，但没有一个人看得见 AI 在干什么。那不是掌控 AI，是被 AI 掌控——不是被机器，是被自己看不懂的东西。

这就是我们不做模型的原因。菩萨已经有人在造了，而且造得很好。没有人造座——一个普通人看得见、点得动、审得了、退得回的座。

OpenAI 和 Anthropic 在造菩萨。我们造座。

十、这就是 Busabase

Busabase 是 Database & Workspace for Agents。在它上面，长出各种结构化数据和应用，最终形成 Apps for Agents 这种形态。

把它放到坐标上：一头是 Notion，给人的，人写得舒服，程序读不了。另一头是 Supabase，给程序员的，本质是一个 Postgres 加一个控制台，人看不懂。Busabase 在中间：人和 Agent 都能读写的结构化数据。数据库、知识库、应用库、技能库、记录系统、工作区——都是同一个东西的不同叫法。

这些叫法里，记录系统是唯一带着义务的那个。它的意思是：两个来源打架的时候，以它为准。而一个存储想配得上这句话，只能靠管住「Agent 写入」和「记录落库」之间发生的事——Busabase 整个产品就是围着这件事建的。

跟 Linear 的区别也在这里。Linear 管的是过程——issue、项目、周期。issue 关掉之后，Linear 什么都不留。Busabase 留的是结果。

它唯一的 AI 能力，是连接你的 Agent——Codex、Claude Code、Buda，或者任何一个。它对外不可见，除非你分享。它可以私有化部署。

我们算过一笔账。全球会用 Excel 的人，五到十亿。Excel 是上一个让十亿普通人握住数据的工具。以前他们用 Office 干活；以后他们操作 AI 来干 Office 的活。

那个 Office，就是 Busabase。

你是 AI 的老板。Agent 会换，模型会换。座不换。

十一、愿景、使命、信念，和三个承诺

愿景：Push humanity forward。

人不该把最宝贵的时间耗在地球上的重复劳动和互相争抢里。Buda 说，人类该重返月球。我们说：别停在月球，往更远的地方去。

人不会因此闲下来。人会更忙——忙着判断、忙着品味、忙着调整。但那是人该忙的事。

使命：让十亿人掌控自己的 AI。

掌控的意思是看得见。十亿个会用 Excel 的人，每一个都能看见自己的 AI 做了什么、改了什么、留下了什么——而且点得动、审得了、退得回。

信念：好不好，是人说了算的。

Agent 可以干活，模型可以变强。但什么叫好，从来是人定义的。我们把执行交给 Agent，把判断留给人。这不是保守，是分工。

三个承诺：

不往这个产品里放 AI。 不做模型，不做聊天，不做 Agent。Busabase 永远只是座。
你的数据是你的。 私有，属于每一个人自己。我们保护它，不碰它，不拿它训练任何东西。
永远不把你锁在里面。 开源，可自托管，整个座可以搬走。只有能带走的数据，才真是你的。

十二、我们的计划

我们押一个判断：到 2030 年，一家公司的组织架构图上画的不再是人，是事。 画在上面的每一件事，底下都有一个座。

先给自己的团队建一个座。
把一起干活的人拉进来。
让 Agent 往里写，让人来审。
让结果自己生出下一件事——人保留最后一票。

我们现在在第三步。第四步，我们自己也还没完全做到。

尾

菩萨很厉害。

但再厉害的菩萨，也需要一个底座。