关于 AI 原生团队的一点思考 · Frannie

每个团队都有一些“大家都知道、但没人写下来”的东西。过去，这些东西靠老同事口口相传；现在，团队里多了一批新成员——AI agent。它们不喝咖啡，不参加午饭闲聊，也就永远听不到那些“口口相传”。

这篇文章想聊的就是这件事：当 agent 真正成为团队的一员，团队的知识应该放在哪里，又该怎样被维护。

01 十个人，十个版本的团队

先说我观察到的痛点。

一个团队真正有价值的知识，往往不在文档里，而在几位资深同事的脑子里：这个接口为什么不能直接改，那个客户为什么要单独处理，上次线上事故之后我们约定了什么。新人要花好几个月，才能把这些“为什么”慢慢拼起来。

AI agent 的加入，让这个问题变得更明显。每个人都在用自己的 agent，每个 agent 都有自己私有的上下文——有人给它写了详细的说明，有人什么也没写，有人上个月纠正过它一次，有人从没纠正过。结果是：十个人用 agent，就有十个不同“版本”的团队。

更让人沮丧的是重复踩坑。A 的 agent 上周犯过的错误，A 已经教会它了；但 B 的 agent 这周会原样再犯一次，因为那次教训只留在了 A 的对话记录里。

入职和离职也一样。新人来了，他的 agent 和他一样一无所知；老同事走了，他脑子里的东西和他电脑里那个被“调教”得很好的 agent 一起离开。

02 个人记忆与团队记忆：先分开

说到“共享记忆”，很容易走向另一个极端：把所有人的对话都收集起来，统一管理。我认为这是错的。

我更愿意把记忆分成两类：

  • 个人记忆：我习惯怎么写代码、我喜欢什么样的回复风格、我手头正在想的半成品念头。它是私有的、本地的，属于个人。
  • 团队记忆：命名约定、架构决策、发布流程、不能碰的红线、“我们为什么这么做”。它是共享的，属于团队，由团队维护。

这两者不应该混在一起。个人和 agent 之间的对话，应该像个人笔记本一样被尊重——管理员不该能翻看别人的聊天记录，团队也不需要。团队要的不是每个人的思考过程，而是思考之后被确认下来的结论。

分开之后，二者之间可以有一座桥：个人在工作中发现了值得全队知道的东西，可以主动把它“提”出来，变成团队记忆的候选。但这一步是主动的，而不是被收集的。

03 分层：不是记得越多越好

团队记忆一旦开始积累，下一个问题就来了：东西越来越多，全都塞给 agent，它反而会抓不住重点。人也一样，一份五十页的“新人必读”，基本等于没有。

我比较认同的做法是分层：

层级 内容
全局原则 整个团队都适用的少数几条：价值取向、安全红线、协作方式。
领域 / 模块约定 某个代码库、某个业务线自己的规矩和历史决策。
任务级上下文 这一次要做的事所需的具体背景，用完即止。

agent 在做一件具体的事时，只加载和它相关的那几层。现在很多 coding agent 都支持在仓库里放一份类似 AGENTS.md 的说明文件，并且可以在子目录里再放更具体的版本——这本质上就是一种朴素的分层。思路是对的，值得推广到代码之外的地方。

04 没有评审的记忆，只是传言

这是我最想强调的一点。

如果任何人、任何 agent 都可以随手往团队记忆里写东西，那么用不了多久，它就会变成一个充满过时信息、相互矛盾、甚至是错误结论的垃圾场。agent 会很认真地遵守一条三个月前就已经被推翻的约定。

一条没有被评审过的记忆，只是一条传言。

所以我觉得，团队记忆应该像代码一样拥有生命周期：

图：团队记忆的生命周期，和代码很像

提出的人可以是人，也可以是 agent——agent 在完成任务时发现“这里有个坑”，完全可以起草一条建议。但写进去之前，要有一个明确的维护者看过、点头。写进去之后，它有版本、有历史，出了问题可以回滚。不再适用的时候，要有人愿意把它删掉。

“删掉”这件事常被忽略。记忆不是越多越好，一份定期修剪的记忆，比一份只增不减的记忆可靠得多。

05 记忆、规则与检查：诚实面对边界

还有一件需要说实话的事：把一条约定写进记忆，并不意味着它就会被遵守。agent 可能会忽略它，可能会误解它，也可能在上下文太长时根本没注意到它。人也一样。

所以我会把团队知识大致分成三种：

  • 可以被机器强制的：格式规范、禁止提交密钥、某些接口不能被调用。这类东西最好变成自动检查，而不是靠“记得”。
  • 只能被提醒的：“这个模块改动前最好先和某个团队打招呼”。写进记忆，让 agent 和人在合适的时候看到。
  • 只能由人判断的：取舍、优先级、对用户的感受。记忆可以提供背景，但决定权在人。

把这三者混为一谈，要么会让人对记忆产生不切实际的期待，要么会把本该自动化的东西留给运气。记忆是提醒，不是保证。能变成检查的，就尽量变成检查。

06 让每一次任务都回流

如果说前面讲的是“怎么存”，那这一节讲的是“怎么长”。

一个健康的团队记忆，不是某次集中整理出来的，而是在日常工作里一点点长出来的。修完一个 bug，顺手留下一句“为什么会这样”；做完一个决策，记下当时考虑过、但没有选的方案；agent 被纠正了一次，把这次纠正变成一条候选记忆，交给维护者看。

我理想中的状态是：每完成一个任务，团队都比之前聪明一点点。不是某个人更聪明了，也不是某个人的 agent 更聪明了，而是整个团队共享的那一份上下文更完整了。下一个人、下一个 agent 再来做类似的事时，起点就更高。

这件事听起来不难，难在习惯。它需要回流的成本足够低，低到顺手就能完成；也需要评审的节奏足够快，快到大家愿意继续提。

07 结语：模型人人都有，上下文只属于你们

在 AI 时代，一个团队真正的护城河是什么？

我越来越觉得不是模型。大家能用到的模型差不多，今天领先的能力，过几个月就会普及。真正拉开差距的，是团队自己积累下来的那些东西：踩过的坑、做过的决定、形成的默契、说得清楚的“为什么”。

这些东西过去一直存在，只是散落在某些人的脑子里和无数条聊天记录里。agent 的到来，逼着我们把它们拿出来，整理好，放在一个人和 agent 都能读到、都能改进、也都能信任的地方。

换句话说，我们不只是在给 agent 写说明书，我们是在第一次认真地给团队写下它自己的记忆。

留给你的几个问题

  1. 你的团队里，有哪一条“大家都知道”的规矩，其实从来没有被写下来过？
  2. 如果明天团队里最资深的那个人离开，哪些知识会跟着他一起消失？
  3. 你的 agent 上一次犯同样的错误，是什么时候？那次教训，团队里的其他人知道吗？