AI 编程 agent 越来越多，Claude Code、Codex、Cursor、CodeBuddy、WorkBuddy 各自为政。每人在本地维护一套 skills、rules、docs，很快就会出现「我这里的 Claude 知道公司规范，你那里不知道」的割裂。腾讯开源的 teamai-cli（项目名 TeamAI）试图用 Git 把这些问题统一管起来：给团队的 AI 工具配一副公用的 Harness，让 skills、规则、文档、hooks 甚至 MCP 配置都能像代码一样版本化、可评审、可分发。当前版本 0.20.0，MIT 协议，可以直接 npm 安装。
功能全景：不造新 agent，而是给已有 agent 发装备 TeamAI 的定位不是再做一个聊天式 IDE，而是做 agent 的「团队 Harness」。管理员把团队资产提交到一个共享 Git 仓库，成员通过 teamai init 绑定仓库，之后的 teamai pull 会把资源注入到本地各个 AI 工具的目录里，例如 ~/.claude/skills/ 、 ~/.codex/skills/ 、 ~/.cursor/skills/ 等。支持的资产类型覆盖四类：
• skills ：Markdown 技能卡，可被 Claude、Codex、Cursor 等工具识别；
• rules ：团队编码规范、审查规则；
• docs ：项目文档、流程说明；
• hooks / mcp ：自定义 SessionStart/PreToolUse 等 hook，以及团队 MCP Server 配置。
分发链路是「push → 创建 MR → 评审合并 → pull 注入」。所有 git 操作都在隔离 worktree 里完成，不会污染成员当前的工作区和分支。知识资产进仓库 main 分支的 .teamai/ 目录；成员注册、会话摘要、投票、使用统计等上报数据走独立的 teamai-reports 孤儿分支，避免把业务仓 main 弄脏。
最快的方式是直接装 npm 包：
npm install -g teamai-cli 想从源码跑，仓库依赖很常规：TypeScript、tsup、Vitest、simple-git、commander、zod、gray-matter、yaml 等，没有额外运行时。常规流程如下：
git clone https://github.com/Tencent/teamai-cli.git cd teamai-cli npm install npm run build # tsup 打包 npm test # vitest npm run test:e2e # e2e 用例 TeamAI 的初始化分两种模式，小团队和个人建议不要混在一起用。
多仓模式： 业务代码与团队配置分开。先建一个共享经验仓库，给成员写权限，然后在业务项目里执行：
cd /path/to/my-project teamai init https://github.com/yourorg/yourrepo 默认是 project scope，资源落到项目目录；如果希望个人配置跨项目复用，可以加 --scope user 。更灵活的是分层： --inherit-user-scope 让当前项目继承用户级 scope 的安全资源和可检索知识，同时保持项目级 scope 独立。
单仓模式： 业务仓库本身就是团队仓库，适合独立项目或不愿维护第二个仓库的团队。
cd /path/to/my-project teamai init . # 交互式选择 AI 工具 teamai init . --agent claude,codex # 非交互，只启用指定工具 单仓模式的好处是「clone 即初始化」： .teamai/teamai.yaml 里会写入 mode: self ，成员 clone 后第一次运行 teamai 命令或 AI 会话就能自动完成本地设置，不需要再背仓库地址和角色参数。
日常命令主要是这几条：
teamai push # 把本地改动推到分支并创建 MR teamai pull # 同步团队资源到本地 teamai status # 看本地与团队仓的差异 teamai hooks list | inject # 管理已注入的 hooks teamai source add teamai recall enable # 开启团队知识召回（默认关闭） 除了分发 Harness，TeamAI 还想把团队踩过的坑沉淀成可检索知识。机制分三步：
1. 自动经验沉淀 ：每次 AI 会话结束，Stop hook 会根据「摩擦信号」打分——你打断或纠正过 AI、拒绝过工具调用、AI 反复重试失败工具——又长又顺的会话不会触发，只有真正较劲过的会话才会被提示。
2. 写入团队仓库 ：摩擦分数达标后，AI 会建议你运行 /teamai-share-learnings skill，把总结写到 .teamai/learnings/ 。
3. 召回 ： teamai recall enable 开启后，每次任务前会先调用内置的 teamai-recall 子 agent 检索团队知识，排序用 BM25 + 代码图谱增强。
这里有一个值得尊敬的设计诚实：recall 明确按分数返回 top 结果，但 不会 按查询词覆盖度过滤。如果结果里出现 Matched: conflict | Missing: port ，说明关键区分词没命中，这条只是主题相邻，而不是答案。README 自己写得很清楚——「分数本身说不清」。这意味着召回结果需要调用方二次判断，不能当成绝对答案直接用。
TeamAI 把所有状态收敛到 Git，而不是自建服务端。架构大致四层：
• 团队 Git 仓库 ：main 分支放 .teamai/ 知识资产，孤儿分支放上报数据， teamwiki/ 放 teamai import 生成的代码知识图谱；
• teamai CLI ： init / pull / push / recall / import 等命令，基于 simple-git 操作仓库；
• 注入层 ：把 skills、hooks、mcp、recall 子 agent 写到各 AI 工具约定的本地目录；
• AI 工具层 ：Claude Code、Codex、Cursor、CodeBuddy、WorkBuddy 等最终消费这些配置。
因为用 Git 托管，天然获得版本、分支、MR 评审和回滚能力；代价是整个团队必须依赖同一个 Git 平台（GitHub / TGit / CNB），且仓库权限要配好。
TeamAI 的想法很完整，但也不是没有门槛。首先，版本号是 0.20.0，说明 API 和命令还在快速迭代，生产环境大规模推广前最好锁定版本并跑通测试。其次，Harness 这套抽象对两三人的小团队可能过重——如果全组只有一个人用 Claude Code，直接维护 .claude/ 目录反而更简单。
另外，知识库虽然美好，但 recall 默认关闭，说明团队需要先建立「愿意记录、愿意检索」的习惯，否则沉淀出来的 learnings 只会变成静态 Markdown。自动经验沉淀依赖摩擦信号评分，也可能漏掉那些看似顺利、实际上埋了坑的会话。MCP 和 hooks 配置一旦写错，会通过 pull 同步到全队，MR 评审是唯一的防守闸门。
TeamAI 给了一个很清晰的思路：与其让每个人的 AI agent 各自野蛮生长，不如把 skills、rules、docs 当成团队代码资产来管。对已经在混用多个 AI 编程工具的团队，teamai-cli 能把散装配置收敛到一个 Git 仓库，减少「你本地和我本地不一样」的问题。单仓模式让个人也能先跑起来，而知识库和代码图谱则在团队规模放大后才会显出复利。teamai-cli 不是万能方案，但至少把「团队 AI 协作」这件事，从口头约定变成了可版本、可评审、可回滚的工程实践。
#团队AI# #知识库# #技能同步# #代码图谱# #开源工具#
粤ICP备14082021号
免费POC，
零成本试错
