一个人把 AI 用顺并不难，难的是十个人别把同一个坑踩十遍。
你看一眼团队现在的状态，可能会撞上这些情况。
- 每个人都有一套自己的 CLAUDE.md、AGENTS.md、skills 和 rules，彼此差不多，又始终对不齐
- 新成员加入项目，要重新告诉 AI 接口怎么写、测试怎么跑、哪些目录不能动
- 有人用 Claude Code，有人用 Cursor，有人用 Codex，同一条规范被复制成三四种格式
- 某位同事把 hook、MCP 和环境变量调顺了，配置却只留在他的电脑里
- 一次棘手排查终于解决，过程和教训跟着会话一起沉底，下一位同事还会从头查起
- 团队文档写了很多「系统是什么」，真正能告诉 agent「该改哪些文件、先跑什么测试」的内容却很少
- 新增了一条 rule 或一个 skill，没人知道它是否减少了纠正和返工
- 大家都觉得自己用 AI 的效率更高了，团队却说不清哪些经验值得复用、哪些配置应该淘汰
这些问题看起来很散，其实都指向同一个缺口。个人的 AI 能力已经起来了，团队还没有一条让配置、规范和经验流动起来的管道。
团队 AI 协作最难的，也就不是再给每个人装一个更强的工具，而是让一个人踩过的坑，下一次能在正确的时机帮到另一个人。经验要流动，还得流得准。
腾讯在 2026 年 4 月 27 日开源了 teamai-cli，npm 包在 5 月 1 日发布。截至 8 月 20 日，项目最新版本是 v0.20.0，有 389 stars、36 forks。它还不到四个月大，远谈不上成熟，但迭代速度很快，目标也很明确，做一套面向 AI agent 的团队 Harness 分发系统。
我觉得它最值得看的不是某个命令，而是背后的判断。团队的 AI 经验，应该像代码一样被版本化、被评审，也被验证。
团队问题不是一层，而是四个断点
「团队 AI 协作做得不好」太笼统了。沿着实际工作流拆开，会看到四个连续的断点。
配置孤岛最容易被看见。CLAUDE.md、AGENTS.md、skills、rules、hooks、MCP server 默认都散在个人机器上。你的 agent 学会了团队规范，换一位同事，AI 又从零开始。
多工具碎片紧跟在后面。Claude Code 读 .claude/，Cursor 有 .cursor/rules，Codex 认 AGENTS.md 和 config.toml。同一条规范要翻译成多套格式，hooks 和 MCP 也各有各的写法。工具一多，团队很快就有了三四套事实标准。
经验不沉淀最隐蔽，也最贵。排查过程、review 教训和 agent 的失败重试留在会话记录里。问题解决了，经验也跟着消失。同一个坑不是只付一次钱，而是每个后来者都可能再付一遍。
没有度量让改进只能靠感觉。新加的 rule 有没有减少纠正，新 skill 有没有真的被调用，哪里摩擦最多，团队通常答不上来。
这四层有先后关系。很多团队把 CLAUDE.md 或 AGENTS.md 提交进项目仓库，就以为共享问题解决了。其实只打通了第一层。配置能流动，不等于经验能沉淀；经验能沉淀，也不等于它能在正确的任务里被召回。
现有方案为什么总差一截
把原生配置提交进代码仓库，是最轻也最稳的起点。它能解决项目级共享，成本几乎为零。但跨工具时要维护多份等价配置，组织级约定没有自然归宿，Harness 的改动也容易混在普通代码 MR 里，没人专门审它的影响范围。
Anthropic 的 managed skills 和 plugin marketplace 适合全员使用 Claude 的团队。配置能由组织统一下发，管理体验也更完整。代价是范围被单一厂商圈住，只要团队里还有 Cursor、Codex 或别的工具，这条链路就会断。
再轻一点，可以建一个私有 Git 仓库，用脚本或 symlink 把 skills 同步到各工具目录。技术上不难，组织上却很脆。脚本通常靠某个热心人维护，没有独立评审，没有经验回流，也没有效果数据。时间一长，它会变成另一个没人敢动的内部工具。
这些方案各自能解一段。TeamAI 想做的，是把分发、沉淀和度量接成三个闭环。
分发闭环，MR 不是流程负担，而是信任闸门
TeamAI 把 skills、rules、docs、hooks、MCP、env、agent 定义和 culture.md 收进一个共享 Git 仓库，再翻译到不同 AI 工具的原生目录。
官方使用指南明确列出的目标包括 Claude Code、Codex、CodeBuddy、Cursor 和 WorkBuddy，文档里还提到 Gemini CLI 与 Windsurf。不同页面的支持名单并不完全一致，采用前最好按自己的工具组合实测。
核心链路很短。
成员接入只需要安装 CLI，再初始化团队仓库。
npm install -g teamai-cli
teamai init https://github.com/yourorg/your-teamai-repo
之后，成员通过 teamai push 提交 Harness 变更。工具创建分支和 Merge Request，reviewer 合并后，共享仓库成为新的事实来源。下一次 AI 会话启动时，SessionStart hook 自动执行 pull，把更新同步到各工具的原生目录。
这里真正有价值的是 MR 评审。一个能向全员下发 hooks 和 MCP server 的系统，如果任何人都能直接改，它本身就是供应链风险。TeamAI 把 Harness 变更提到和代码变更相同的治理级别，评审不是附加功能，而是这套分发机制成立的前提。
MCP 的密钥处理也把现实代价摆在了台面上。团队在 mcp/mcp.yaml 里用 ${VAR} 占位，pull 时 TeamAI 会把变量解析为明文，再写进 Claude、Cursor、Codex 各自的配置文件。官方的理由很实际，从 Dock 或 Launchpad 启动的 IDE 不继承 shell 环境变量，运行时展开经常得到空值，MCP server 随后返回 401。
便利性赢了，安全性要补课。官方会把文件权限设为 0600，也要求项目级 MCP 配置进入 .gitignore，但 token 明文落盘仍是事实。对密钥管理有硬性要求的团队，这可能不是提醒，而是否决项。
知识闭环，别记录所有会话，只记录真正较劲过的会话
TeamAI 最有想法的部分，是它没有把「知识沉淀」理解成自动保存全部聊天记录。
Session 结束时，Stop hook 会观察几类摩擦信号，包括用户打断或纠正 agent、拒绝工具调用、agent 反复重试失败工具。工具调用很多但一路顺滑的会话不会触发；真正和问题较过劲的会话，才提示成员运行 /teamai-share-learnings。
提示里会给出很具体的原因，例如 you interrupted the AI twice, the AI retried failing tools 8 times。它没有假装自己能自动判断什么是真理，只是指出，这次会话可能藏着一个值得整理的问题。
这套机制也在真实使用中被修过。用户在 issue #228 里指出，评分早已从「调用规模」转向「摩擦程度」，旧提示却还在展示工具调用次数。几百次调用很显眼，却不能说明会话是否值得沉淀。v0.19.0 随后把提示改成摩擦信号加脱敏任务摘要。一个小小的文案变化，背后是对信噪比的重新校准。
确认分享后，TeamAI 会把经验整理成 learning 文档并推回团队仓库。等另一个成员遇到相关任务，内置的 teamai-recall subagent 会提取关键词，先做相关性预检，再用 BM25 加代码知识图谱检索 learnings、docs、rules 和 skills。命中代码知识时，结果还能附上 Sources:，直接给出源文件入口。
recall 默认关闭，这个默认值很克制。空知识库的主动召回，只会制造 token 消耗和错误自信。前面提到的 issue #232 与 issue #233 也给了两条很实用的提醒。
一条是弱相关结果要尽早停，不要让主 agent 把「检索到了」误解成「答案可靠」。另一条是 learning 要多写「怎么改」，少写「它是什么」。一段架构概览不如一句具体的改动路径，例如涉及哪些文件、先跑哪组测试、哪个配置最容易漏。
这个判断不只适用于 TeamAI。给 agent 的团队知识，价值不在完整，而在能否缩短下一次行动的路径。
度量闭环，数据应该用来改系统，不是给人排名
teamai dashboard 默认在 3721 端口启动，按成员展示 AI 会话状态。它关注三类人工干预信号，分别是按 ESC 打断、拒绝工具调用，以及 agent 停止后 60 秒内带纠正语义的追加 prompt。
隐私边界相对清楚，统计只保存计数，不保存 prompt 或 transcript 内容。数据聚合进 stats/*.yaml，teamai digest 可以生成周报，用来观察人均干预率、token 与轮数的变化。
这些数据最合理的用法，是验证 Harness 是否真的在变好。某条 code review rule 上线后，相关任务的纠正有没有减少；一批 skills 推送两周后，哪些一次都没被调用。没有这层反馈，团队只能不断往仓库里加内容，最后得到一座越来越贵的配置博物馆。
但官方周报里的 Session Autonomy 排行榜很容易被误用。干预次数高，可能是 Harness 有缺口，也可能只是这个人接了更难、更模糊的任务。把它拿去考核个人，数据会迅速失真。度量要先服务系统改进，团队成员才会愿意暴露真实摩擦。
落地别跳级，先让管道里有水
这套系统不适合一口气全开。更稳的做法，是让每个阶段先产生可见价值，再进入下一层。
10 分钟，只同步 rules。 建一个 GitHub、TGit 或 CNB 仓库，放入 5 到 10 条最重要的团队规范。第一阶段的验收很简单，新成员初始化后，agent 已经知道项目最基本的约定。别急着搬完整知识库，先证明「改一处、全员生效」能稳定工作。
第 1 周，扩资源并定 scope。 把成熟的 skills、hooks 和 MCP 声明逐步迁入。project scope 适合项目级规范，user scope 适合跨项目约定。大组织可以用 --inherit-user-scope 叠加组织层与项目层，但 env、hooks、MCP 等执行面配置不继承，仍留在项目层受控。
这一周也要把治理闸门装上。将 sharing.hooks.autoApply 设为 false，让成员手动确认 hooks 注入；开启 requireTeamScripts: true，把脚本限制在受管目录。任何成员都应知道，紧急时可以用 TEAMAI_HOOKS_DISABLED=1 关闭团队 hooks。
第 2 到 4 周，再开知识召回。 先积累一批真正有行动价值的 learnings，再让一两个自愿尝鲜的成员开启 recall。观察弱相关任务能否被预检拦住，也检查召回内容里有多少是在告诉 agent「怎么改」。知识还稀的时候，全员开启 recall 带来的往往是 token 账单，不是帮助。
第 2 个月起，只看趋势。 开 dashboard，先在小范围里用 teamai digest 对比 Harness 变更前后的干预率。调用为零的 skill 可以下架，频繁触发纠正的环节应该补 rule 或 learning。第一个月更适合当基线期，不要急着宣布提效。
如果团队使用自建 GitLab 或 Gitea，还得先停一下。目前官方支持的是 GitHub、TGit 和 CNB，通用 provider 仍在 issue #300 里排队。OpenCode 也处在用户提需求的阶段，见 issue #303。
什么团队适合，什么团队先别上
TeamAI 更适合多工具并存、已有个人 Harness 积累、又确实被重复踩坑困扰的团队。还需要一个明确的 owner，愿意维护仓库、组织评审、清理低价值内容。没有人负责，Git 仓库只会把知识散落从聊天记录迁移到另一个坟场。
单工具小团队未必需要它。五个人都用 Claude Code，把 .claude/ 提交进仓库，再配合官方 marketplace，可能已经足够。团队连最基本的 rules 都没有，也不该从 dashboard 和 recall 起步。工具解决的是管道，管道里得先有水。
成熟度同样要算进决策。teamai-cli 写作时还不到四个月，API 与行为继续变化很正常。许可证文件与 npm manifest 都是 MIT，但 GitHub 的 SPDX 检测目前显示 NOASSERTION。如果公司流程依赖自动扫描，这一步需要额外处理。
token 明文落盘和多工具支持差异，也不该只留在风险清单里。生产采用前，最好用真实项目跑一轮小范围试点。
我对 TeamAI 的最终判断是，它值得关注，但现在更像一个方向正确、仍在快速长大的系统，而不是拿来就能全公司铺开的标准答案。
它真正留下来的，也许不是 teamai pull 这个命令，而是三个更耐用的问题。
-
团队的 Harness 有没有共同的事实来源？
-
一个人解决过的问题，能不能在下一次任务里准确帮到另一个人？
-
新加的一条 rule，后来有没有被数据证明有效？
这三个问题能答出来，团队 AI 协作才算越过了「每个人各自用得很好」的阶段。到那时，用的是 TeamAI，还是另一套工具，反而没那么重要。