Busabase 长得像 AI 表格，但请按它解决的问题来判断

日常聊天里，几乎每天都会有人问我们：「你们到底在解决什么问题呀？听起来是个挺抽象的产品和工具。」

这个问题问得很对。第一次看到 Busabase 的人，大多会先把它归到一个熟悉的类别里。左边一栏目录，有带字段类型的表格，还有文档。「这不就是 AI 版的 Airtable 吗？」「这不就是给 Agent 用的知识库吗？」「这不就是带 API 的 Notion 吗？」

第一眼这么猜很正常，但用它来判断就错了。锤子和肉锤长得也很像，分清手里拿的是哪个，要问的是它拿来干什么。所以这篇不罗列功能，只回答我们最常被问到的那个问题：Busabase 到底解决什么问题？你的团队有没有这个问题？

它看起来像的四样东西，各自解决什么问题

这四类产品都很好，只是各自为不同的活儿而生。

留意最后两列：每一行里，写的和读的都是同一类角色。

Busabase 的出发点，是这几行都没覆盖到的情况：整个团队里的 Agent 和人，在做同一摊业务，都需要同一份上下文、同一套做事方法。

活儿交给 Agent 之后，活儿本身得放在共享的地方

想象一家公司，日常的活儿大部分已经交给 Agent 了：写博客、发博客；更新 CRM、跑销售运营；写代码、维护项目计划、起草产品方案、帮忙做设计；发起一个报销审批，翻出上个季度的发票。

越来越少的人一整天盯着屏幕点来点去。人负责提要求、审结果、做决定。

到了这一步，有件事就变了。活儿不再待在某个人的屏幕上，也不能只待在某个 Agent 里，因为明天接手的可能是另一个 Agent，或者另一个人。客户名单、发布流程、这次上线进行到哪一步，都得放在每个 Agent、每个人都够得着的地方。

这就是我们说「Agent 应该是无状态的」的意思。Agent 是把活儿干完的方式，上下文才是活儿本身，而上下文必须共享。

刚开始用 Agent 的团队，最常犯的错误

刚开始用 Agent 的团队，大多会犯同一个错误：像招人一样招 Agent。

一个 SEO Agent，一个销售 Agent，一个项目管理 Agent，一个设计 Agent。每个都有自己的说明，自己的一堆技能。半年后，团队手里有几十个 Agent、几百个技能，大部分放在那里没人用。与此同时：

• 同一份上下文散在很多地方。 产品资料、品牌规范、当前客户名单，被分别贴进每个 Agent 的说明里，几份副本悄悄地越走越远。
• 每开一个新项目都要从零开始。 新建一个 Agent，项目背景和做事说明又得重新搭一遍。
• 团队的做事方法被锁在某个人的配置里。 怎么发一篇博客、怎么判断一条销售线索，跟着搭这个 Agent 的那个人走，别人改不了。
• 没人说得清哪个是最新的。 昨天有个 Agent 改了一条客户记录：那是最新进展，还是它从一份旧文档里猜的？

根子上是把类别搞错了。Agent 和技能一样，本质上是一个「交互入口」，是开始一件事的方式，而不是一个岗位。 照着组织架构图去设计 Agent，入口越来越多，上下文也被切碎分给了它们，每个 Agent 只知道一小块，没有一个知道得够。

我们自己的体会是：一个 Agent 配上匹配得当的上下文，比十个各握一小块上下文的 Agent 更管用。要问的不是「这件事该归哪个 Agent 管」，而是「任何一个 Agent 接手这件事时，能不能找到对的上下文和对的做法」。

Busabase 要解决的就是这个问题。不是「我们需要一个更好的表格」，也不是「我们需要一个更好的维基」，而是上下文和技能，没法在 Agent 之间、人和人之间共享。

Agent 保持无状态，上下文留在底座里

我们的做法是一种很简单的分工：让 Agent 保持无状态，把公司的知识和工作留在一个人能看见、能管理的共享底座里。

Agent 会换。你会换模型，团队里不同的人也会偏爱不同的助手。这不应该意味着一切重来。留下来的是底座：

• 记录：客户、商机、任务、内容计划、发票、决定。结构化存放，任何 Agent 都能准确地读、准确地改。
• 文档：人或 Agent 开工前需要知道的背景。
• 技能：重复性工作的做法，比如怎么发一篇博客、怎么跟进一条线索、怎么发起一个审批。
• 应用：基于同一份数据的小界面，给想「看」而不想「问」的人用。

每个人用惯了哪个 Agent，就让哪个 Agent 接到同一个底座上。开工时读已有的东西，做完把结果写回去。下一个 Agent、下一个人，接着往下做，而不是从头再来。

共享技能：做法改一次，处处生效

大家最容易低估的，是技能这部分。

在 Busabase 里，技能是工作区里的一个节点，和表格、文档一样。Busabase 给 Agent 的说明要求它们每次开工都先做同一件事：在工作区里搜一下，这件事有没有已经写好的技能和提示词，有就照着做。一个 Agent 能把很多种活儿都干好，靠的就是这个。它不需要是「SEO Agent」，也能按你们团队的方式发一篇博客，只要它找得到你们的发布技能。

这带来两个变化：

1. 一致。 不管谁来提要求、哪个 Agent 来干，做法都是同一套，因为只有这一套。
2. 谁负责，谁能改。 负责这摊业务的人，可以直接在工作区里用大白话修改做法，不用找工程师。所有 Agent 下一次运行，用的就是新版本。

可以这么想：以前做法记在每个 Agent 自己的脑子里，现在写进了团队的手册，所有 Agent 都看同一本手册。

共享上下文，不等于共享记忆

这件事很容易被叫成「共享记忆」。我们刻意不用这个词，因为它说的是另一件事。

记忆是一个 Agent 自己记得的东西：只属于它、比较模糊、也很难核对。它有用，但它属于那个 Agent。

共享上下文是团队能拿出来指着说「就是这个」的东西：一条客户记录、一套做法、一次进度更新，有负责人、有来源，谁改过都查得到。当你问「这个项目这周有什么变化」，答案应该来自后者。

两者的区别，我们在《Agent 记忆、知识库与记录系统》里写得更细。

那它为什么长得像表格？

因为表格是把上下文交给机器最清楚的方式。客户的续约日期放在一个有类型的字段里，任何 Agent 都能直接读、直接改，不用猜；同一个日期埋在一段话里，就做不到。

表格是形状，共享上下文才是目的。文档、技能、应用放在表格旁边，也是同一个道理：每一种都是某一类上下文最清楚的形状。

也正因为 Agent 会以机器的速度往这份共享上下文里写东西，底座还要让它保持可信。你来决定每个 Agent 能看什么、能改什么；重要的写入可以先变成一份提议，你审过再生效，其余的照样很快；改了什么、谁改的，随时查得到。完整的论述在我们的《AI Agent 的记录系统》页面里。

给负责人的四个问题

如果你在带一个用 Agent 干活的团队或业务，可以问问自己：

• 你知道团队一共搭了多少个 Agent、多少个技能吗？真正在用的有几个？
• 搭这个 Agent 的人明天要是走了，还有别人能改它的做法吗？
• 同一份背景、同一套规则，有没有被贴进不止一个 Agent？
• 想知道这周有什么变化时，你是问一个 Agent，还是开一个会？

如果这些答案让你不安，问题多半不在 Agent 身上，而在你的上下文放在哪里。

拿一个项目试试

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

想知道它对你有没有用，不需要先调整团队，从一个项目开始就行：

1. 把这个项目最近的进度和你们团队的做法放进一个工作区。
2. 接上你已经在用的 Agent，各个 Agent 的接法在这里。
3. 问它：「这个项目这周有哪些变化？」

免费开始使用 Busabase Cloud，或者下载 Personal Desktop，所有数据都留在你自己的电脑上。想省点事，模板中心里有现成的工作区，连技能都已经写好了。