8 月底才开源的 teamai-cli，星标曲线在 9 月第一周近乎垂直：GitHub Trending 数据显示日增 841 星、总量 3904 星。它要解决的问题在 AI 编程普及后才开始出现：团队里每个开发者都在用 AI 写代码，但每个人调教出来的 AI 各不相同。你花一个月摸清的项目规范，写在自己的 CLAUDE.md 里；同事用 Cursor，他的技能躺在另一套配置文件中。人员一流动，经验就跟着清零。
腾讯把这个「团队 AI 经验共享层」做成了一个开源 CLI：所有技能、规则、hooks、MCP 配置集中放在一个 Git 仓库里，走正常的分支加合并请求流程审核，然后同步到 Claude Code、Codex、Cursor、CodeBuddy 等 11 种编码 Agent。npm 上的发布记录显示出很快的迭代速度，9 月 9 日一天内连发 0.24.0-beta.1 到 beta.3 三个版本，9 月 11 日凌晨 beta.6 已就位，稳定版停在 0.23.1。
三层架构：执行、语境、改进
README 把产品拆成三层，每层对应一个独立的问题。
Team Execution（执行层） 解决「让每个 Agent 按团队的方式工作」。管理员把资源放进团队仓库的固定目录：技能放 skills/<name>/SKILL.md，规则放 rules/*.md，hooks 放 hooks/hooks.yaml，MCP 配置放 mcp/mcp.yaml，甚至有一份 culture.md 承载团队使命与协作准则，它会被注入每个 Agent 的 CLAUDE.md 或 AGENTS.md，成为每次会话的默认底色。
Team Context（语境层，beta） 解决「让每个 Agent 理解整个团队」，包含经验文档（learnings）、代码知识图谱和团队 wiki。
Team Improvement（改进层，beta） 解决「让每一次执行都变成团队能力的积累」，包含会话记录、每周摘要和使用看板。
三层各自独立，又连成一条闭环：执行层把规范铺下去，语境层让 Agent 干活前先查团队已知什么，改进层再从日常执行中回收新经验。
分发机制：push → 审核 → pull
同步流程刻意做得「土」，完全复用工程团队已有的 Git 习惯：
teamai push → 创建分支 + 合并请求 → 评审人批准 + 合并
↓
SessionStart hook → teamai pull → 同步到本地各 AI 工具经验进入团队资产库前必须过一道人类评审。经过这道流程，「AI 配置」脱离了个人随手改的本地文件状态，成了和业务代码同级的受管资产：谁改了规范、为什么改、改了哪些行，在合并请求的 diff 里全部留痕。成员本地只需 teamai init 关联仓库，SessionStart hook 会在每次会话启动时自动 pull，保证各 Agent 拿到的始终是最新版规范。
分发粒度也有设计。管理员可以按项目（projects）、按角色（roles）、按标签（tags）三个维度控制谁同步什么：前端工程师不必同步后端的技能包，某个项目私有的经验文档也不会流向全公司。learnings/ 根目录全员共享，learnings/<project-id>/ 则是项目隔离的。此外还支持订阅其他团队的技能仓库，跨组复用不需要复制粘贴。
并不是每个 Agent 都能吃下全部资源类型。从 README 的功能矩阵看，第一梯队（Claude Code、Codex、Cursor、CodeBuddy、Qoder）13 项能力全绿；WorkBuddy 缺 agents 分发；OpenCode 的改进层三项全部空缺；DeepSeek Harness 只支持 skills、docs 加语境层三项。矩阵直接决定了「一套配置、多端生效」的成色，选型时值得逐列核对。
摩擦信号：什么时候该沉淀经验
改进层最有意思的机制是自动经验沉淀。每次会话结束，Stop hook 会给这场会话打一个「摩擦分」，信号包括：你打断了 AI、纠正了它的输出、拒绝了某次工具调用、AI 反复重试失败的工具。一场很长但顺滑的会话（工具调用很多、零摩擦）不会触发提示；一场你和 AI 反复较劲的会话才会。分数够高时，AI 会收到这样的建议：
[teamai] 本场会话可能包含值得记录的问题：你两次打断 AI，
AI 重试失败工具 8 次。
任务：修复项目级 Hook 重复注入
建议运行 /teamai-share-learnings 总结经验并分享给团队。这个设计的隐含判断很准：值得沉淀的是「人和 AI 在哪里发生过冲突」，而非「AI 干了多少活」。冲突点意味着现有规范或知识库有缺口，可能缺一条规则、缺一份文档，或者技能写得有歧义。/teamai-share-learnings 会把会话总结成经验文档推到团队仓库，每场会话最多提示一次，避免打扰；团队也可以用 sharing.contributeHint.enabled: false 关掉提示、保留其余 hook 能力。
沉淀只是入口，知识库还需要运营。teamai recall maintenance 负责保洁：归档低置信度的经验、标记过时的技能和文档、为陈旧条目草拟更新，支持先 --dry-run 预览再实际执行。命令表里还有 recall promote，把被反复验证的高置信度 learning 晋升为正式的技能、规则或文档。经验在这里有完整的生命周期：摩擦触发 → 进入 learnings → 验证 → 晋升为规范 → 过时后归档。
知识检索：会话启动前的团队记忆
语境层的 recall 机制让 Agent 在动手前先查「团队以前怎么解决这类问题」。这个功能默认关闭，需要显式开启（teamai recall enable）。开启后 teamai pull 会在每个 AI 工具的 agents/ 目录部署一个 teamai-recall 子代理，它在任务开始前提取关键词、检索团队知识库、读取命中的源文件、返回结构化摘要。检索前有一道相关性预检（teamai recall --check），任务与团队知识无关时直接跳过，不浪费 token。中文 README 的命令表标注其检索实现是 BM25 加图谱增强重排序。
手动查询的效果大致如下：
$ teamai recall "port conflict"
[1/2] MR review caught a port-conflict bug ★1 [user]
Author: member-a | Score: 18.5 | Tags: troubleshooting, networking
[2/2] Deployment configuration best practices [project]
Author: member-b | Score: 12.0 | Tags: deploy, config
Matched: conflict | Missing: port代码知识图谱：让检索带着结构信息
recall 的重排序依赖一张代码知识图谱。teamai import 把源码仓库解析成结构化图谱存入 teamwiki/，节点是组件、接口、配置，边是跨仓库的依赖关系。边的生成走双轨：
- AST 轨道：对 TypeScript/JavaScript、Python、Go，用 WASM 版 tree-sitter 解析器精确解析
import/require、调用点和 TS 的implements子句，生成带置信度权重的DEPENDS_ON/REFERENCES/IMPLEMENTS边； - 启发式轨道：对 AST 覆盖不到的语言（Java、Rust 等）用正则抽取补位。
WASM 解析器是纯 JavaScript 依赖，不需要本地编译工具链；加载失败时自动降级到启发式轨道并记录 AST_UNAVAILABLE 缺口，也可以用 TEAMAI_SKIP_AST=1 强制只走启发式。当 recall 命中的是代码页面时，结果会附带 Sources: 行列出相关源文件路径，Agent 拿到的是改代码的直接起点，省去了自己重新探索仓库的过程。
配套的 teamai codebase --reconcile 能把产品文档和提取出的代码知识做对账，--lint 则检查本地图谱的健康度。CI 场景下还有 teamai ci extract-mr：从合并请求中提取知识、发评论、合并后写回知识库，让知识沉淀搭上代码评审的既有流程。
透明度与隐私：部署前要看清的几处
作为部署在每个人本机、且会话数据会被上传共享的工具，teamai-cli 的隐私边界值得单独核对。
会话摘要（teamai session save）是隐私脱敏后的摘要，供每周摘要的 Session Highlights 使用。摩擦提示里包含「脱敏后的单行任务摘要」。这些设计说明作者意识到数据敏感性，但部署前团队仍应自己过一遍 hooks/hooks.yaml 和分享链路，确认脱敏粒度符合自己的合规要求。env/ 目录的官方备注也明确「不建议直接放密钥」，共享仓库里应该只放开关类配置。
recall 默认关闭是一个正确的默认值：自动检索意味着每次任务前都可能把团队知识库内容送进模型上下文，是否接受这个开销和暴露面，应该由团队显式决定，而不是工具替你决定。
一个判断：分发是 AI 编程的下一层
单看每个功能，teamai-cli 没有不可复制的技术壁垒：共享仓库加 hook 注入并不神秘，tree-sitter 建图谱在 IDE 里也是成熟做法。它的价值在于把分散的事实组合成了完整的闭环，并且踩准了一个正在发生的转移。
过去一年，编码 Agent 的竞争焦点在单兵能力：更长的上下文、更强的工具调用、更准的代码生成。当单兵能力趋同之后，下一个拉开差距的变量是组织侧的配置资产：同一个开发者，用一家把自己的规范、经验、知识图谱持续喂给 Agent 的团队配置，和用一份半年没更新的全局 CLAUDE.md，产出差距会越拉越大。个人级的配置管理工具（各种 CLAUDE.md 生成器、技能包管理器）已经很多，团队级的分发和沉淀层此前几乎空白。teamai-cli 的星标曲线之所以这么陡，背后是一个真实存在却长期没人做统一抽象的需求。
风险同样在这条曲线上。日增 841 星的热度来自「第一个」的卡位，热度能维持多久取决于 beta 层的完成度：语境和改进两层目前都标着 beta，摩擦分的具体算法、知识库在百人规模下的检索质量，都还没有经过大规模验证。npm 上 9 月 9 日到 11 日连发 6 个 beta 版本的节奏，既是活跃度证明，也说明 API 还在快速变动期，生产环境采用需要把版本锁定和变更跟踪纳入考虑。
对个人开发者，它解决的是「经验资产化」：/teamai-share-learnings 把踩坑变成文档，recall promote 把文档变成规范。对小团队，它是零成本的规范统一方案，一个 Git 仓库加两条命令就能跑起来，teamai-hub 组织下还有预装模板仓库可以直接复刻。对已经有平台工程团队的大厂，README 里的架构表基本就是一份现成的选型清单，逐列核对支持矩阵，再决定自建还是采用。
仓库地址：Tencent/teamai-cli（MIT 协议），安装：npm install -g teamai-cli。