一个人用 AI，往往觉得它无所不能：它学会了你的写法，记得你的项目，一周比一周好用。可一旦把它带进团队，怪事就来了：Agent 越加越多，效果却不见涨，最后人反而招得更多。
不只是你这么觉得。MIT 的 NANDA 项目在 2025 年发布的报告《生成式 AI 鸿沟》里说，企业的生成式 AI 试点，只有大约 5% 带来了明显的收入增长。作者没有怪模型不够好，而是指向一个学习断层：通用的 AI 工具，不会去学、也不会去适应一家公司自己的做事方式。
过去两年，我们一直在真实的团队里落地 Agent，做法前后换了五代：聊天机器人加工具；跑在终端里的编程 Agent；把个人电脑当成长期记忆的 Agent；给 Agent 分岗位、搭成一家「AI 公司」；最后才是今天在用的这一套。这篇文章，是踩完坑之后留下来的东西。一句话概括：别再造更多的 Agent。让 Agent 无状态，把记忆交给团队。
一个人好用的 AI，为什么进了团队就不灵了
每个 Agent 的记忆，都是一座孤岛
让 Agent 记住你教过它的东西，对一个人、一台电脑来说是真正的突破。可到了团队里，同样的记忆反而成了问题。
举个例子。销售部的 A 和 B，各自做了一个「回客户邮件」的 Agent。B 的那个越用越好，A 的那个一直跟不上。B 的 Agent 学会的东西，A 的 Agent 一点都拿不到，因为每个 Agent 的记忆，都待在搭它的那个人那里。最理想的情况显而易见：A 和 B 用同一个 Agent。偏偏是 Agent 自带的记忆，把他们隔开了。
Agent 越多，要人去对接的地方越多
在我们的前公司，上过一套 ERP，系统本身八位数。为了落地，二十多个人梳理了整整一年业务；上线以后，各个部门还得去招更懂系统、也更贵的人。系统之外，差不多又花了一倍。它对公司后来的发展有帮助，但没有省钱。软件最终是给人用的，人依然是瓶颈：系统做得越完善，越需要更强的人去用它。
Agent 也在重复这个故事。每多一个 Agent，就多一个交互点；每个交互点，都需要有人去喂它、查它、把它接到其他工作上。这正是《人月神话》里的老道理：两个人之间一条沟通线，十个人四十五条，五十个人一千二百二十五条。大家讲「人才密度」就是这个原因，Agent 也一样，我们叫它智能密度：Agent 越少越好，每一个越强越好。
感觉快了，不等于真的快了
METR 在 2025 年做过一个随机对照实验：16 位资深开源开发者，在自己维护多年的项目里做了 246 个真实任务。允许用 AI 的任务，反而慢了 19%。开始之前，他们预计 AI 能让自己快 24%；做完之后，他们还是觉得自己快了 20%。那是 2025 年初的工具，METR 后来也标注这个结果已经过时。但道理没变：一个人觉得自己快了，说明不了整个团队的产出有没有变多。
一、让 Agent 无状态，记忆归团队
Agent 带着智商来就够了。团队知道的东西，放在团队自己的一个地方。我们把它叫做上下文数据库（Context Database），里面有四样东西：
- 资料：文档和数据。
- 规则：做事的手册和技能。
- 权限：谁能看什么，谁能改什么。
- 历史：谁改过什么，什么时候改的。
整个团队只有这一份上下文，所有 Agent 都读它。你要管的是这一份，而不是去追每个 Agent 各自记住了什么。
这样做有三个好处。第一，换 Agent 不丢东西：今天在 Claude Code 和 Codex 之间切换也好，明年换一批新的也好，都没关系。第二，同事之间不再是孤岛：B 教会的，A 当天下午就能用上。第三，人走了，教过的东西还留在团队里。
做开发的朋友会觉得眼熟。互联网架构早就学会了这件事：服务是无状态的，状态都在数据库里，所以服务可以随时换、随时扩。团队用 AI，要学的是同一件事：无状态的 Agent，加一个上下文数据库。
如果你在纠结这份「状态」该放在哪，我们在《记忆、知识库、记录系统：AI Agent 的三层存储到底差在哪》里做过对比。
二、按权限分 Agent，不按岗位分
几乎所有人落地 Agent，都会下意识地照搬组织架构：销售 Agent、SEO Agent、项目管理 Agent。我们也这么做过，搭了一家有岗位的「AI 公司」，后来又亲手推翻了。
人类为什么需要组织架构？因为一个人的能力有限，没办法全能，所以要分工，三个臭皮匠顶个诸葛亮。AI 不一样：它几乎全能，还能无限复制，等于你手上有一亿个诸葛亮。再按组织架构把它拆开，就是把一亿个诸葛亮，拆成十个臭皮匠。我们实地看到的正是这样：Agent 拆得越多，效果越差，需要的人反而越多。Agent 之间每交接一次，活儿就被稀释一点。
真正站得住的拆法只有一种：按权限拆，也就是它能碰哪些数据。大多数团队，有两个 Agent 就够了：
- 一个对内：权限大，团队里所有人都用它。
- 一个对外：服务客户和合作伙伴，只给它够用的最小权限。客服 Agent 总不能看得到工资表吧？
我们今天看到的多 Agent，很多只是因为权限不一样，而不是岗位不一样。
三、技能越少越好，大家用同一份
每个人有了 Agent，就都想写自己的技能。很快，同一件活儿，团队里有十个不同的技能，没有一个是集了众人之力的。
技能是什么？我们的定义是：SOP，加上背后的知识和规范。它之所以要单独存在，是因为它是一个按钮：人想让 AI 按某种方式做一件事，就去按它。按钮越多，闲置的就越多。哪天写了一百个技能的那位同事离职了，这一百个技能谁来接？
所以落地越深，技能越少。把团队的知识搬回共享的上下文里，技能只留下同时满足两条规矩的：
- 每周都有人用。 一周都没人碰，它就不需要存在。
- 需要人来判断。 纯执行、不需要品味的活儿，直接全自动，不用再惦记。
筛到最后剩下的通常不多，那就是团队做事方式里最核心的部分。这几个技能要有人负责、不断更新。十个版本留哪一个，是管理，也是品味。
四、把判断留给人
不要去全自动一个业务。团队做出的东西，最终都要摆到客户面前，而客户的要求一直在往上走。察觉到要求又往上走了，这就是判断，也就是品味。没人提要求、没人看结果的 AI，会越来越中庸、越来越大路货。能被全自动的业务，谁都能抄。
Klarna 就是那个有名的例子。2025 年 5 月，它的 CEO 接受彭博采访时说，「AI 优先」的客服确实便宜，但质量更差了，公司重新开始招人，让客户想找真人时永远找得到。
可人也不可能每一步都盯着。三个习惯，让人站在对的位置上：
- 每天一个入口。 在关键环节，给团队一个每天真的会打开、会回复的技能入口。交给一个有追求、有品味的人负责，每周至少迭代一次。
- 每周一份周报。 自动化的终点不是把结果交付了，而是产出一份带建议行动的日报或周报，由人批准该做的、拦下不该做的。比如一个 SEO Agent，每天报告昨天的流量、建议今天写哪个关键词，还会提醒你：上个月涨的流量，搜的都是跟你产品没关系的词。
- 定期一场务虚会。 最难的不是把 AI 接进业务，而是讨论清楚什么叫好、什么不好。要让一群人坐下来谈，还要不断引入外部视角，因为内部的同事有时候不方便说真话。
人做操作，是瓶颈；人做判断，是护城河。
这样做的团队，发生了什么变化
三个合作中的团队（不点名）：
- 一家游戏科技公司，合作一个月。原本计划扩招 50 到 100 名研发，现在停止了扩招，并计划把大约 20% 的人转岗。
- 第二家公司，合作三个月。人员转岗，开了更多业务线。
- 一家电商企业，砍掉了每月的 SEO agency 服务费，改由一个人负责。这个人每天做的，就是看 Agent 交上来的日报，然后拍板。
三家都是同一个变化：人从操作，换到了判断。
这周就能做的三件事
- 把团队搭过的 Agent 列出来，问一句：明天换成 Claude Code 或 Codex，活儿还能接着干吗？ 干不了，说明团队的知识被锁在了 Agent 里，而不是在团队里。
- 数一数有多少个技能。 把写死在里面的知识搬回共享上下文，再用那两条规矩筛一遍，两条都不满足的，删掉或者直接全自动。
- 每个流程，指出「人拍板的那一下」。 指不出来，就别上生产。
Busabase 在其中的位置
我们做 Busabase，就是为了做这样一个上下文数据库：数据表、文档、技能、应用放在一处，团队里每个 Agent、每个人都用同一份。它是开源的，MIT 协议，可以跑在你自己的电脑上，团队协作就用 Busabase Cloud，接上你已经在用的 Agent 就行。
上面每一条，在 Busabase 里都有现成的样子：
- 记忆归团队：所有 Agent 读写同一个工作区。
- 按权限分：API Key 分四档：只读、变更请求、写入、管理。拿「变更请求」档 Key 的 Agent 可以提议改动，但不能合并自己的提议。
- 技能越少：技能放在共享的工作区里，所有人用同一版本，写它的人走了，技能还在。
- 人做判断：提议的改动在收件箱里等人审核；日报、周报写进数据表和文档，在一个地方看、一个地方批。
想看更完整的论述，可以先读《Busabase 长得像 AI 表格，但请按它解决的问题来判断》。想动手试，就从一个项目开始：把它最近的进度和团队的做法放进一个工作区，接上你已经在用的 Agent，然后问它：这周有哪些变化？
免费开始使用 Busabase Cloud，或者去模板中心挑一个现成的工作区。
别给人做系统，别造更多 Agent。上下文交给 AI，品味留给人。