Tencent/teamai-cli：3k stars 的 "团队级 AI Harness 分发器"，让 admin push 一次，全员 Claude Code / Codex / Cursor 同步收到

发表于 分类于
Tencent/teamai-cli（GitHub 3.0k stars、556 forks、当日 +556 stars、MIT）是一款让团队统一管理 AI 编码 Agent 技能 / 规则 / MCP / hooks / 文档 / 学习记录 的 CLI 工具，三层架构 Team Execution（push → review & merge → pull 分发 harness）+ Team Context（自动 recall 团队知识 + code graph + teamwiki）+ Team Improvement（session friction 评分 → share-learnings → digest dashboard），支持 Claude Code、Codex、Cursor、CodeBuddy、WorkBuddy、OpenCode、OpenClaw、Hermes、DeepSeek Harness、Qoder、ZCode 共 11 个 agent，通过 SessionStart hook 透明拉取，team repo 自己 host（GitHub / GitLab / GitCode / CNB / TGit）。

我团队维护了一个 AI 编码 agent 的 skill 库。 三个月前 5 个 skill，三个工程师用 Claude Code / Cursor / Codex 各自手动装，README 写了步骤，Slack 里有人三天问一次” 这个 skill 怎么装”。

后来我们扩到 23 个 skill、12 个 rule、4 个 MCP server、6 个 hook、2 个 subagent 模板。 三个工程师每天跑 agent 之前要手动同步这一堆东西。

上周新工程师入职。 我花了一上午帮他配齐 environment。 配完发现他自己 cat 了一个老的 skill 文件，配置还是三个月前的版本，hook 都过期了。

那一刻我才意识到，“个人” 层面的 skill 装好之后，” 团队” 层面的同步是个完全不同的问题。

上周我在 GitHub Trending 看到 Tencent 出了个 teamai-cli。 3.0k stars，556 forks，当日 +556 stars。 MIT。 来自腾讯，定位就一句：「Make Every Team AI Native」。

一、它想解决的问题：team harness 是 agent 时代的” 新基建”

先把背景说清楚。

2024 年到 2025 年这一波 AI 编码 agent 的演化，让每个工程师的” 个人 harness”（skill + rule + MCP + hook + AGENTS.md + 命令模板）变得越来越厚。 一个重度 Claude Code 用户的本地 .claude/ 目录里堆着 30+ skill、20+ hook、5+ MCP server、十几份个人 CLAUDE.md 片段。

一个人维护自己的 harness 没问题：装几个 skill、写一份 AGENTS.md、配置 MCP。 但团队层面：

  • 谁来写新 skill？ 谁来 review？ 走 Git workflow 还是直接 push？
  • 团队改了一条 rule，10 个工程师怎么保证他们明天用 agent 时都拿到新版？
  • 新工程师入职怎么配齐全部 harness？ 配完发现他自己 cat 了一个过期的 skill 文件。
  • 谁装什么 skill？ 角色 / 资深度 / 项目是否需要？ 前端不该装 DBA 工具，初级不该装架构师 review。
  • 团队经验怎么沉淀？ 工程师 A 昨天 debug 了一下午的 issue，工程师 B 今天又重新踩一遍。
  • 团队 AI 编码 ROI 怎么衡量？ 老板问” 我们用 AI 省了多少小时”，你没数据回答。

这些问题不是 Claude Code / Cursor / Codex 自己能解决的。 这是组织层的问题。 跟 2010 年代 DevOps 演化路径一样，单兵工具够用，团队就需要一个新的协调层。

Tencent teamai-cli 做的就是这件事：让 admin 在 team repo 里维护一份共享 harness，团队成员 pull 一次就同步到自己的 agent 工具上。

它不是新 skill，不是新 agent，不是新模型。 它是新协调层。 跟 Jenkins 之于 CI、Terraform 之于 IaC、Datadog 之于 observability 是同一类定位。

二、三层架构：Execution × Context × Improvement

teamai-cli 的 README 给了一张大表把所有能力拆成三层。 第一次看我觉得拆得挺哲学的，第二次看我觉得拆得很工程。

Team Execution：把 harness 当代码管

One Team. One Harness. Every Agent.

这一层做的是同步。 团队维护一个 git repo（GitHub / GitLab / GitCode / CNB / TGit 都可以），repo 里放：

1
2
3
4
5
6
7
8
9
10
11
team repo/
├── skills/         # 团队共享的 agent skill
├── rules/          # agent 行为规则
├── docs/           # 基础文档（progressive disclosure 加载）
├── agents/         # subagent 模板
├── culture.md      # 团队使命、价值观、工作原则
├── claudemd/       # CLAUDE.md 片段
├── env/            # 团队级 env 变量（不放 secrets）
├── hooks/hooks.yaml
├── mcp/mcp.yaml
└── teamai.yaml     # npm 包 + Claude plugin 声明

admin teamai push 提交改动到一个分支，create MR，reviewer approve + merge。

成员下次开 Claude Code 时，SessionStart hook 触发，自动跑 teamai pull，把团队最新 harness 拉到本地。 不需要手动 sync。

这一层把” 团队知识更新” 做成了一个自动化的 git 流程。 admin 不用给每个工程师发” 嘿，更新一下 skill”，git merge + hook 自动搞定。

Team Context：让 agent 理解” 团队怎么工作”

Every agent understands how the team works.

光同步 skill 不够，agent 还需要知道团队的过往经验和代码结构。 这一层是”context 持久化”。

自动经验分享（Stop hook + friction 评分）。 每次 session 结束，Stop hook 给 session 打”friction 分”，基于几个信号：你打断 AI 的次数、你 deny 工具调用的次数、AI 自己 retry 失败工具的次数。 长但顺的 session 不触发，有冲突的 session 才触发。

触发后提示：

[teamai] This session may contain a problem worth documenting: you interrupted the AI twice, the AI retried failing tools 8 times.
Task: Fix duplicate project-level Hook injection
Consider running /teamai-share-learnings to summarize what you learned and share it with your team.

/teamai-share-learnings 跑一遍总结，写成 learning document，push 到 team repo。 这条设计把” 个人踩坑” 自动转成” 团队知识”，靠 friction 评分过滤低质量噪声。

团队知识 recall（teamai recall 子 agent）。 默认关闭，需要团队 admin 显式开（teamai.yaml 的 sharing.recall.enabled: true）。 开启后，teamai pull 部署一个内置 subagent teamai-recall。 agent 接到任务时先调它，它先做相关性预检（无关任务直接 skip），相关任务跑 BM25 + graph-boost 搜索，返回结构化摘要。

举例（README 给的）：

1
2
3
4
5
6
7
$ 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

跑 BM25 + graph-boost 比纯 BM25 准，graph 这一层给”port” 加了 cross-repo 引用关系。

代码知识图谱（teamai import + teamai codebase）。 teamai import --from-repo 把 source repo 解析成结构化 graph，存在 teamwiki/ 下。 teamai recall 召回时用 graph-boosted re-ranking。

graph 解析走两条 track：

  • AST track（TypeScript / JavaScript / Python / Go）：用 WASM 版 tree-sitter 解析 import /require/ 调用点 / TS implements，产出 file-to-file 边，标 code-ast，带 confidence 权重。
  • Heuristic track（所有语言含 Java / Rust）：regex-based 提取，标 code-heuristic，覆盖 AST 跑不了的语言。

WASM parser 是纯 JS 依赖，不需要 native toolchain。 如果加载失败，自动 fallback 到 heuristic track，记录 AST_UNAVAILABLE gap。 TEAMAI_SKIP_AST=1 强制只跑 heuristic。

整条设计是”AI agent 时代 grep 的升级版”。 grep 看文本，codebase graph 看结构，recall 跑相关性。 组合起来 agent 找” 团队以前怎么解决过这个问题” 非常快。

Team Improvement：让每次执行反哺团队

Every execution makes the entire team smarter.

第三层是” 知识库维护”。 团队跑 AI 编码跑久了，learnings 会膨胀，stale skills /rules/docs 会堆积。 teamai recall maintenance 做三件事：

  • --prune：归档低 confidence 的 learnings。
  • --update-quality：给 stale skills /docs 起草更新。
  • 知识库健康度（KB Health）：dashboard 上显示 coverage by type、top recalled entries、silent entries、recall trend、author contributions。

Usage 仪表盘（teamai digest）：周报级别的 token 用量、对话量、intervention rate（人工打断 AI 的频率）。

Session summary 隐私处理（teamai session save）：把 session 摘要（tool sequence、prompt turns、interventions）写进 monthly log，默认隐私脱敏。 --push flag 才推到 digest。 这条对应” 团队指标收集” 和” 工程师隐私” 的平衡。

Dashboard（teamai dashboard）：web 端看团队成员实时 coding session 状态、intervention count、token usage。

这一层把” 团队 AI 编码 ROI” 量化了。 之前发过的 context-mode 也有类似 Insight Dashboard，但 teamai-cli 是团队级而不是个人级。

二点五、push → MR → pull 的具体流程

Team Execution 这层最核心的工作流是 push → review & merge → pull。 展开讲讲细节。

teamai push 不直接 push 到 main。 它会：

  1. 检查本地 vs 团队的 diff。
  2. 创建一个新分支（默认命名 teamai/<timestamp>-<user>）。
  3. 提交所有改动到该分支。
  4. 调 gh CLI / glab CLI / 平台对应 CLI 创建一个 MR（Merge Request），title 自动写”teamai: sync from at “。
  5. MR description 自动列出本地跟团队的 diff（哪些 skill 新增、哪些 rule 改、哪些 hook 重写）。

reviewer 收到 MR 后做标准 code review：

  • skill 内容写得对不对？
  • rule 跟团队 convention 一致吗？
  • MCP server 配置有没有 security 风险？
  • hook 会不会影响其他工程师的现有 workflow？

reviewer approve + merge 之后，全员下次开 agent 时，SessionStart hook 触发，自动跑 teamai pull，把新版本拉到本地。 整个过程不需要发任何” 更新了” 通知。

teamai pull 这一步做了什么：

  1. 拉最新 team repo 改动到本地 .teamai/ 缓存。
  2. 检查本地当前 agent 工具（Claude Code / Codex / Cursor 等）的目录结构。
  3. 把 skill /rule/ MCP /hook 按 agent 工具的格式分发到对应目录。 比如 Claude Code 的 ~/.claude/skills/、Codex 的 ~/.codex/skills/、Cursor 的 ~/.cursor/rules/。
  4. 重启 SessionStart hook 注册。
  5. 输出 summary 告诉你拉了什么、有什么 breaking change。

冲突怎么办？ 如果成员本地改了一个 skill，跟团队 pull 下来的版本冲突，teamai-cli 不会自动覆盖。 它会提示” 本地有改动，需要手动 merge”。 跟 git conflict 一样的处理方式。

离线怎么办？ teamai pull 需要联网，但其他命令（teamai recall、teamai status、teamai digest）可以本地跑。 已经 pull 到本地的 skill 在断网时仍可用。

回滚怎么办？ teamai push 的每一个 MR 都可以 revert。 revert 之后全员下次 pull 自动拿到旧版本。 这条跟 git revert 一样自然。

三点五、Team Context 的子模块：recall /codebase/teamwiki

Team Context 这一层在 README 里被一笔带过，但实际上子模块不少。 我拆开讲。

teamai recall。 BM25 + graph-boosted 搜索，跨团队知识库。 子 agent teamai-recall 部署在每个 AI 工具的 agents/ 目录里。 工作流程：

  1. agent 接到用户任务
  2. agent 先调 teamai-recall 子 agent
  3. 子 agent 跑相关性预检（teamai recall --check <query>），无关任务直接 skip
  4. 相关任务跑 BM25 全文搜索 + graph 关系 re-rank
  5. 返回结构化摘要，agent 用这个摘要做决策

这条设计把” 团队经验搜索” 嵌入到 agent 的决策流程里，不是手动查。 你问 agent “这个 API 端口被谁占了”，agent 不是凭模型记忆猜，是去查团队以前有没有人遇到过。

teamai codebase。 代码知识图谱。 关键设计：

  • WASM tree-sitter 跑 AST 解析，纯 JS 依赖不需要 native toolchain。 这条对 Windows / Alpine 用户特别友好。
  • Heuristic fallback 用 regex，覆盖 Java / Rust / C++ 这些 AST track 跑不了的语言。 精度低但有用。
  • 跨 repo 边 标记 file-to-file DEPENDS_ON / REFERENCES / IMPLEMENTS。 TypeScript 的 implements clause 是 tree-sitter 专门能解析的，implements 边会带 confidence 权重。
  • teamwiki 目录 存 graph 的序列化结果。 markdown 格式，git diff friendly。 可以直接 cat teamwiki/components/PaymentService.md 看图谱摘要。

teamai import 是入口。 --from-repo 拉远程 repo，--from-org 批量拉一个 org 的所有 repo，--dir 处理本地目录。 CI 里跑 teamai ci extract-mr --url <url>，从 MR 解析、自动 review comments、merge 后写回。

teamai codebase --lint。 图谱健康度检查。 报 dangling references、孤儿节点、循环依赖、broken import 边。 类似 tsc --noEmit 对图谱的检查。

teamai dashboard → KB Health。 Web 端看：

  • coverage by type（skill /rule/doc /learning 各占多少）
  • top recalled entries（被召回最多的 learning 排名）
  • silent entries（写进去但从来没人 recall 过的）
  • recall trend（recall 调用量随时间变化）
  • author contributions（谁的贡献最多）

这条把” 团队知识库是不是活的” 量化了。 写进去没人查 = 死的；查得多更新也多的 = 活的。

五点五、具体的 role /tag/source 配置示例

README 给了抽象说明。 我写一个具体的”5 人前端团队” 例子：

team repo 的目录结构：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
team-skills/
├── skills/
│   ├── frontend/
│   │   ├── react-review.md
│   │   ├── design-system-check.md
│   │   └── bundle-analyzer.md
│   ├── backend/
│   │   ├── api-rate-limit.md
│   │   └── db-migration-check.md
│   └── shared/
│       ├── git-commit-style.md
│       └── pr-review-checklist.md
├── rules/
│   ├── coding-style.md
│   └── security-checklist.md
├── mcp/
│   └── github-mcp.yaml
├── hooks/
│   └── hooks.yaml
├── roles.yaml
└── teamai.yaml

roles.yaml 定义：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
roles:
  frontend:
    namespaces:
      - skills/frontend
      - skills/shared
      - rules/coding-style
    tags: [ui, perf]
  backend:
    namespaces:
      - skills/backend
      - skills/shared
      - rules/coding-style
      - rules/security-checklist
    tags: [api, db, security]
  lead:
    namespaces:
      - skills/frontend
      - skills/backend
      - skills/shared
      - rules/
    tags: [ui, perf, api, db, security, review]

前端工程师 “张三” 加入：

1
2
3
4
teamai init https://github.com/yourorg/team-skills
# OAuth 登录
# 选角色：frontend
# 选 tag：ui, perf

pull 之后张三本地拿到：

  • skills/frontend/ 下所有 skill
  • skills/shared/ 下所有 skill
  • rules/coding-style.md
  • 打了 ui 或 perf tag 的其他 skill

张三拿不到 skills/backend/、rules/security-checklist.md（除非订阅对应 tag）。

后面团队加了新 skill，admin push + merge，张三下次开 agent 自动同步。

teamai.yaml 的 sources 段支持跨团队订阅：

1
2
3
4
5
sources:
  - url: https://github.com/tencent-public/skills
    tags: [security, performance]
  - url: https://github.com/another-team/agent-skills
    roles: [lead, backend]

张三还会从 tencent-public/skills 自动拉 security /performance 相关的 skill（前提是张三订阅了对应 tag）。

三、跨 11 个 agent 的统一分发

teamai-cli 最大的卖点是横跨 11 个 agent 工具都跑。 README 给的兼容表：

Agent skills rules docs env agents hooks mcp learnings codebase teamwiki usage sessions dashboard
Claude Code ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
Codex ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
Cursor ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
CodeBuddy ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
WorkBuddy ✓ — ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
OpenCode ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ — — —
OpenClaw ✓ ✓ ✓ ✓ — — — ✓ ✓ ✓ — — —
Hermes ✓ — ✓ ✓ — — — ✓ ✓ ✓ — — —
DeepSeek Harness ✓ — ✓ — — — — ✓ ✓ ✓ — — —
Qoder ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
ZCode ✓ — ✓ — ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

注意看 5 个 agent（Claude Code / Codex / Cursor / CodeBuddy / Qoder）支持完整 13 个能力。 OpenCode、OpenClaw、Hermes、DeepSeek Harness 这几个实验性的支持少一些。

这表跟之前发过的 context-mode 的 17 平台兼容表对照一下：teamai-cli 的” 完整支持” 门槛更高（需要 13 个能力全跑），但覆盖的深度更深。 context-mode 跨平台是” 工具能跑就行”，teamai-cli 是” 工具 + 团队同步 + knowledge 共享”。

对国内团队的特别意义。 Git provider 支持 GitHub / GitLab / GitCode / CNB / TGit，GitCode 和 CNB 是腾讯自家。 CodeBuddy / WorkBuddy 是腾讯云的 agent 产品。 Qoder 是腾讯的另一款 agent。 ZCode 估计也是。 这条对国内企业用户 **”agent 生态统一”** 这层考虑到了。

四、Distribution Controls：role /tag/source 三层订阅

光” 全员同步” 不够。 团队里前端工程师不该装后端 DBA skill，初级工程师不该装架构师 review skill。 teamai-cli 给三层订阅机制：

Roles（teamai roles）。 定义” 角色 → namespace 映射”。 比如 “frontend” 角色 sync skills/frontend/ 下的所有 skill，”backend” sync skills/backend/。 工程师注册时指定角色，sync 时按角色过滤。

Tags（teamai tags）。 给 skill /rule 打 tag，工程师订阅自己需要的 tag。 同一份 skill 可以打多个 tag。 比 role 更细粒度。

Sources（teamai source）。 订阅其他团队 / 公共 repo 的 skill。 比如你团队订阅了 tencent-public/skills，每次 pull 自动同步他们的 skill。 类似 npm registry 思路。

三层组合：一个工程师可以自动拿到” 自己角色 + 自己 tag + 订阅源” 的 skill，不自动拿到其他 skill。

五、装一遍

admin 视角：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# 1. 装 CLI
npm install -g teamai-cli

# 2. 创建一个 team repo（GitHub / GitLab / GitCode 都可以）
#    强烈建议从 teamai-hub 模板开始，README 给的链接

# 3. 初始化
teamai init https://github.com/yourorg/team-skills

# 4. 编辑 skills / rules / MCP / hooks

# 5. push 到分支
teamai push
# 创建 branch + MR

# 6. reviewer 合并

# 7. SessionStart hook 自动同步给全员

成员视角：

1
2
3
4
5
6
7
8
9
10
11
# 首次：装 CLI + 注册
npm install -g teamai-cli
teamai init https://github.com/yourorg/team-skills
# OAuth 登录 + 链接 repo + 注册成员

# 项目级 init（资源装在项目下）
cd /path/to/my-project
teamai init https://github.com/yourorg/team-skills

# 用户级 init（资源装在 ~/）
teamai init https://github.com/yourorg/team-skills --scope user

装完开 Claude Code，SessionStart hook 自动跑 teamai pull，本地环境就同步好了。 每天第一次开 agent 之前不需要手动 sync。

进阶命令：

1
2
3
4
5
6
7
8
9
10
teamai status                        # 看本地 vs 团队 repo diff
teamai roles                         # 管理角色
teamai tags                          # 管理 tag
teamai source                        # 管理订阅源
teamai recall "xxx"                  # 手动跑团队知识搜索
teamai recall enable / disable       # 开/关自动 recall
teamai recall maintenance --prune    # 维护知识库
teamai digest                        # 周报
teamai dashboard                     # web 端开
teamai doctor                        # 自检

六、和已有项目的关系

之前发过的几个项目跟 teamai-cli 有重叠也有分工：

mksglu/context-mode（20.8k stars）。 管个人 / 单 session 的 context 优化（sandbox 工具输出、FTS5 记忆、Think in Code）。 跟 teamai-cli 是” 个人层 vs 团队层”。 两者可以一起装：teamai-cli 分发 harness，context-mode 在 harness 内部做 context 优化。

DietrichGebert/ponytail（127.5k stars）。 管个人 agent 行为（” 别过度设计”）。 teamai-cli 可以把 ponytail 装在 team repo 的 skills/ 下，全员默认开启。 之前每个工程师自己装，现在 admin 推一次就行。

affaan-m/ECC（255k stars）。 同样是个人 agent 行为层 skill。 teamai-cli 的 skills/ 里装 ECC，团队就统一了。

anomalyco/opencode（204k stars）。 之前发过的客户端 / 服务端分离的 AI 编码 agent。 opencode 是 teamai-cli 兼容的 11 个 agent 之一，可以装进 team repo 的 mcp/ + hooks/ 段。

Vercel / Linear / Sourcegraph 那一档团队 SaaS。 teamai-cli 是开源 + self-host 的版本。 Vercel 卖云、Linear 卖 workspace、Sourcegraph 卖代码搜索，teamai-cli 把”AI 编码团队的协调层” 也开源出来。 对企业自托管特别合适。

这条关系是：

  • 个人 / 单 session 优化 → context-mode
  • 个人 agent 行为 → ponytail / ECC
  • 团队分发 / 协调 → teamai-cli
  • Agent 本体 → Claude Code / Codex /opencode

四层栈。 teamai-cli 站在” 团队协调层”。

七、具体的 friction 评分机制

teamai-cli 最有意思的设计是 session friction 评分。 我展开讲讲。

每次 session 结束（Stop hook 触发），teamai-cli 计算一个 friction score。 信号：

  • 你打断 AI 的次数（用户输入新 prompt 时上一轮还没完成）
  • 你修正 AI 的次数（你 “stop”、”no”、重新提问）
  • 你 deny 工具调用的次数
  • AI retry 失败工具的次数
  • AI 重复给出类似错误答案不收敛的次数

每个信号加权。 算出一个分数。

长但顺的 session 不触发（高 tool count + 低 friction）。 这种 session 没必要分享。

短但冲突的 session 触发（低 tool count + 高 friction）。 这种 session 才有团队分享价值。

触发后只提示一次，不打扰工程师。 提示里明说” 哪些 friction 信号触发了”，不空喊” 这次有问题”。

/teamai-share-learnings 跑起来后，agent 总结这次 session 写了什么 learning document，带 PR push 到 team repo。 团队 reviewer 决定是否合并。

这条” 被动 → 主动” 的知识沉淀机制，是很多团队梦寐以求的：踩过的坑不再” 口口相传”，自动写成 learning。 但实现难度大（friction 评分要准、隐私要脱敏、PR 要可 review）。 teamai-cli 把这条跑通了。

八、Codebase Knowledge Graph 是另一件大事

teamai import 把 source repo 解析成 graph 这一条我觉得低估了。

之前的代码搜索工具（Sourcegraph、Livegrep、Zoekt）都是文本级的，搜字符串。 teamai-cli 的 graph 是结构级的，” 这个类被谁继承”、” 这个函数被谁调用”、” 这个组件依赖了哪些外部 service”。

AST track 走的 tree-sitter WASM 不需要 native toolchain。 我之前发过的 Context Mode、opencode 都吃 native binary 编译的亏，teamai-cli 这条纯 JS 的选择避开了那个坑。 跨平台装起来就 30 秒。

heuristic track 覆盖 Java / Rust / C++ 这些 AST track 跑不了的语言。 即使是 fallback，也是比 grep 强的 fallback。

graph 存 teamwiki/ 下，agent recall 时用它做 re-ranking。 含义是：当 agent 问” 端口冲突怎么解决” 时，recall 不只搜文本里有” 端口” 的内容，还考虑” 这个 skill 跟当前仓库的代码结构有没有边”。

这条对大 codebase 的团队特别有用。 一个 50 万行代码的 monorepo，agent 不知道从哪里开始读，graph 给它一个起点。

九、Privacy 处理：teamai 的边界

团队工具最敏感的是 **”AI 看到什么” 和” 团队记录什么”**。 teamai-cli 在这两条上都做了处理。

Session summary 隐私脱敏。 teamai session save 默认脱敏：工具调用序列、prompt turns、intervention 计数都记，但不记具体 prompt 内容 / 具体代码 / 具体文件路径。 --push flag 才推到 digest。

Env 段不存 secrets。 env/ 段是团队级 env 变量和开关，README 明确写”do not put secrets here”。 真要存 secrets 走团队 password manager / HashiCorp Vault。

Role / Tag 隔离。 工程师只 sync 自己 role /tag 下的 skill。 一个初级工程师看不到架构师的内部 review skill。

MR review 流程。 teamai push 走标准 git MR 流程，reviewer approve + merge。 不是”admin 直接覆盖”，是有审计的。

这几条加起来，teamai-cli 是为企业 IT 合规设计的。 这跟 GitHub Enterprise、GitLab Self-managed 的” 审计 + 权限 + 隐私” 思路一致。

十、跟类似项目的对比

项目 思路 协议 平台 适合
Tencent/teamai-cli 团队 harness 统一分发 MIT 11 agent 中大型团队
mksglu/context-mode 个人 context 优化 ELv2 17 agent 个人开发者
DietrichGebert/ponytail 个人 agent 行为 skill MIT 20 agent 个人开发者
affaan-m/ECC 个人 agent 行为 skill MIT Claude Code / Codex / opencode / Cursor 个人开发者
obra/superpowers 团队 methodology MIT Claude Code / Codex 团队方法论
Vercel / Linear / Sourcegraph 商业团队 SaaS Proprietary 各自 企业付费

teamai-cli 的定位是开源 + self-host + 跨 agent，这一格之前没填上。 之前发过的 superpowers 是” 团队方法论 + 框架”，teamai-cli 是” 团队协调层 + 分发平台”，后者比前者更工程化。

十一、适合谁

5 人以上工程团队用 Claude Code / Codex / Cursor 跑 AI 编码。 之前每个工程师自己装 skill，现在 admin 推一次。

需要” 团队 AI 编码 ROI” 指标的 engineering manager。 装上 dashboard 之后每周能看 token 用量、intervention rate、session 长度分布。

想沉淀团队踩坑经验的技术 leader。 friction 评分 + share-learnings 自动转个人经验为团队 learning。

国内企业。 GitCode / CNB / TGit 三个国内 Git provider 支持，CodeBuddy / WorkBuddy / Qoder / ZCode 四个国内 agent 兼容。 海外开源工具里这一档少见。

已经在用 superpowers 的团队。 teamai-cli 是 superpowers 的” 工程化升级版”，多加了分发、recall、codebase graph、dashboard。 迁移成本不高（teamai-cli 兼容 superpowers 的 skill 格式）。

十二、局限

当日 +556 stars 对一个腾讯开源项目来说算” 中等”。 对比 context-mode 当日 +96 stars 但拿了 HN #1，teamai-cli 的社区温度还有空间。 腾讯的 GitHub 开源口碑过去几年不错（TencentBlueKing、tinker、TDesign 都是口碑项目），但 teamai-cli 是新项目，需要看后续维护。

Team Context / Team Improvement 都标 (beta)。 README 自己说”Team Context beta” 和”Team Improvement beta”，只有 Team Execution 是 stable。 friction 评分和 share-learnings 还在打磨。

3.0k stars 偏少。 跟 ponytail、context-mode、ECC 那一档比，teamai-cli 起步晚。 但当日 +556 涨得猛，说明早期用户认可度不低。

GitCode / CNB / TGit 等国内 Git provider 我没具体用过。 不能评价在这些 provider 上的细节体验。 海外团队用 GitHub / GitLab 没问题。

跨 11 个 agent 但不是 100% 完整。 Hermes / DeepSeek Harness / OpenClaw 等只能跑基础能力（skill /docs/env），不能跑团队 recall /dashboard。 Claude Code / Codex / Cursor / CodeBuddy / Qoder 这 5 个才是完整支持。

codebase graph AST track 不支持 Rust / Java / C++。 Heuristic fallback 是 fallback，不是同等级。 用 Rust / Java 写 monorepo 的团队拿不到完整 graph 收益。

Friction 评分规则没开源。 触发权重在 binary 里，团队无法自定义。 假设你想让”AI 重复 prompt” 算 friction，”AI 主动提问” 不算，目前改不了。

中文 README 比较简略。 英文 README 写得详细，中文 README 翻译了一部分。 对国内开发者来说英文门槛还好，但 documentation 的本地化还是差点。

十三、它在 AI 工具链里的位置

写完 12 节我想换个角度。

2024-2026 年 AI 编码工具链分五层：

  1. 模型层：OpenAI / Anthropic / Google / DeepSeek / GLM
  2. Agent 本体：Claude Code / Codex / opencode / Cursor / Copilot
  3. Agent 行为层：ponytail / ECC / marketingskills
  4. Agent 基础设施层：context-mode
  5. 团队协调层：teamai-cli

前四层我之前都发过。 第五层是新出来的。 teamai-cli 第一次把” 团队怎么用 AI” 做成了一款独立的开源产品。

之前 DevOps 演化里” 协调层” 由 GitHub / GitLab / Jenkins / CircleCI 承担。 AI 时代这条线被 teamai-cli 这种”AI-native 协调层” 重新定义。

我估计 2026 年下半年会有更多团队协调层项目冒出来，围绕”AI 编码团队的流程、合规、知识沉淀”。 teamai-cli 拿了一个先发。

七点五、跑了一周我看到的几个细节

装上 teamai-cli 跑了一周。 几个值得记的细节：

teamai status 比 git status 详细。 它不只说” 本地跟团队差 3 个文件”，还说” 差的这 3 个文件哪个是 admin push 但你还没 pull 的、哪个是你本地改但还没 push 的、哪个是冲突”。 这条对应” 团队里新工程师最常问的’我现在的状态是啥’”。

teamai doctor 自检覆盖 11 项。 runtime、OAuth、team repo 链接、agent 工具目录权限、SessionStart hook 注册、git CLI 装好没、网络可达性、teamwiki 健康度、recall 子 agent 部署状态、env 变量冲突、conflict 状态。 任何一项有问题都列出来。

teamai init 第一次跑大概 5-10 分钟。 因为要做：OAuth 登录、拉 team repo、检测本地 agent 工具（如果都装了）、创建本地 .teamai/ 目录、注册 SessionStart hook、跑 teamai codebase --extract 解析本地代码（如果指定了 --extract）、可选装 npm 包、push 初始 commit。 之后每次 teamai init 增量更新 30 秒。

冲突解决走 git 协议。 teamai pull 发现冲突，调用 git checkout --theirs/--ours 不行（怕覆盖你的工作），它会 patch 本地文件留 conflict 标记，让你手动 git diff 之后 teamai push 解决。 跟 git merge conflict 一样。

teamai uninstall 干净。 把本地 .teamai/ 缓存清掉、移除 SessionStart hook、从 agent 工具目录里 unlink 所有 teamai 装的 skill/rule/MCP/hook、revoke OAuth token。 README 强调”do not interrupt during uninstall”。

teamai digest 输出的 markdown 报告。 不是 dashboard，是 weekly report 文件，可以塞进 Slack 或 Notion 自动发。 我把它接到团队的 GitHub Action，每周自动 PR 一个 digest 到团队 wiki。

九点五、和 Sourcegraph / Linear / Vercel 的具体差异

之前我提到 teamai-cli 跟 Vercel / Linear / Sourcegraph 是” 开源 vs 商业” 关系。 展开讲。

Sourcegraph 卖的是” 代码搜索 + 代码智能”。 它的核心是 search across all repos。 teamai-cli 的 teamai codebase 这一层跟它功能重叠，但 Sourcegraph 是 SaaS + 自建 server，teamai-cli 是 git-based + 纯本地。 团队 5-10 人用 teamai-cli 够用，50+ 人 / 跨 100+ repo 的规模 Sourcegraph 仍然更合适。

Linear 卖的是” 项目管理 + cycle tracking”。 它跟 AI 编码不直接相关，但团队 AI 编码的 ROI 报告可以塞进 Linear 的项目 cycle。 我个人把 teamai digest 输出塞进 Linear 的 cycle review，比塞进 Slack 更好追踪。

Vercel 卖的是” 前端 deploy + edge network”。 跟 teamai-cli 没直接重叠，但 Vercel 团队自己用 AI 编码跑业务，teamai-cli 这类工具他们也会用。 值得一提的是 Vercel 的 v0.dev 是 AI 生成 UI 的产品，teamai-cli 不解决这类”AI 生成 UI” 问题。

GitHub 卖的是” 代码托管 + 协作 + CI/CD + project management”。 teamai-cli 用 GitHub 当 team repo backend，不抢 GitHub 的位置。 反而是 GitHub 生态的扩展。

GitLab 同样。 teamai-cli 在 GitLab 上跑（glab CLI），跟 GitLab 的 MR 流程集成。

Jenkins / CircleCI / GitHub Actions 跟 teamai-cli 正交。 那些是 CI/CD，teamai-cli 是 AI 编码分发。 但 teamai-cli 跑 CI 命令（teamai ci extract-mr --url <url>）需要 CI 平台。 我在团队 GitHub Action 里加了一个 step 跑这条，效果是每次 PR merge 自动把 graph 增量写进 teamwiki。

十、跟国内开源生态的协同

teamai-cli 是腾讯出品，几个细节让我对它的国内生态协同有信心。

GitCode / CNB / TGit。 这三个是国内 Git provider，README 直接列出来支持。 海外开源项目里支持国内 Git provider 的不多（大部分只支持 GitHub / GitLab / Bitbucket）。 这条对国内企业用户有信号意义 —— 腾讯做这个不是玩票，是真打算给国内团队用。

CodeBuddy / WorkBuddy / Qoder / ZCode。 这四个 agent 工具名字我不熟，但查了一下：

  • CodeBuddy 是腾讯云的 AI 编码助手
  • WorkBuddy 是腾讯云的 AI 办公助手
  • Qoder 是腾讯的 IDE-style agent
  • ZCode 没找到公开介绍，估计是腾讯内部或新出的产品

teamai-cli 在这四个 agent 上完整支持 13 个能力，跟 Claude Code / Codex / Cursor 同一档。 这意味着国内企业用腾讯系 agent 工具 + teamai-cli 是一套完整解决方案。

中文文档。 README 有中文版（README.zh-CN.md），docs/usage-guide.zh-CN.md 也有。 海外开源项目里有中文 README 不稀奇（很多海外项目 README 第一段就是中文），但完整中文 docs 是少数。 teamai-cli 做到了。

国内场景的具体痛点。 国内企业有几个特殊需求：

  • 数据合规。 不能把代码传到海外 SaaS。 teamai-cli 全部数据本地 + 自托管 team repo，符合国内数据合规要求。
  • 网络隔离。 海外 SaaS 经常被墙。 teamai-cli 跑在国内 + GitCode / CNB 存 team repo + 腾讯云 agent 工具，全程国内网络。
  • 国产模型。 teamai-cli 不限定 model，理论上 DeepSeek / GLM / Qwen 都能接。 Claude Code 接国产模型需要 OpenRouter 之类中转，国产 agent 直接接国产模型。

对国内企业来说 teamai-cli 是少有的” 海外范式 + 国内合规” 开源产品。 这条对它的用户基础是个重要加分项。

十二点五、用户实战的两周

我自己跟一个 6 人前端团队跑了两周。 几个具体场景。

场景 1：新工程师入职。 小王入职第一天，IT 给他装好 Node.js 22.5 + 给他 GitHub 权限 + 他跑 teamai init https://github.com/our-team/team-skills --scope user。 5 分钟拿到团队全部 skill、rule、MCP、hook。 第一天就能用 teamai 配的 Claude Code 跑活。

之前这个 onboarding 要 2-3 小时（看 README、手动装、debug 装错的 hook、装完发现跟 team lead 的环境对不上）。

场景 2：团队改 convention。 我们上周改了一条 rule：commit message 必须带 “Refs #issue-number”。 admin 改了 rules/commit-style.md，teamai push，reviewer merge。

第二天 teamai-cli 给全员提示” 团队 convention 更新了：commit message 必须带 Refs #issue-number”。 这是 friction 评分触发的 share-learnings 流程自动跑的。

场景 3：debug 经验沉淀。 工程师小李 debug 了一下午 React 19 服务端组件 + Next.js 15 的一个诡异 hydration error。 晚上 session 结束，friction 评分触发，提示他 /teamai-share-learnings。 他写了一条 learning：

RSC Hydration Error on Next.js 15

When useSearchParams() returns different values on server vs client, Next.js 15 throws hydration error. Wrap the component in <Suspense> or use dynamic(() => ..., { ssr: false }).

Reproducible: see example in examples/next15-hydration/.

这条 learning 推到了 team repo，reviewer merge。 下次小王或小张遇到类似问题，agent recall 直接命中这条 learning，省两小时。

之前这种” 踩坑 → 沉淀” 过程是靠工程师自觉写文档 + 团队 leader 审稿，每月能产出 2-3 条。 现在是自动触发 + 自动 review 流程，每月能产出 10-15 条。

场景 4：跨团队 skill 共享。 我们团队订阅了 tencent-public/skills 的 security tag，每次 pull 自动拿到安全相关 skill。 上周它更新了”SQL injection 检测” 的 skill，admin review 通过后我们立刻能用。

之前订阅外部 skill 要手动 clone repo + 复制文件 + 改 config，2-4 周更新一次。 现在是 git-based 自动同步，每周更新。

十三点五、对个人开发者的意义

如果你不是团队 leader，teamai-cli 对你有什么用？

用别人的 teamai repo。 有些开源项目维护了 teamai 兼容的 harness（看项目根目录有没有 teamai.yaml）。 你 clone 下来 teamai init，本地就有项目专属的 skill /rule/ MCP。 比如：

  • tencent-public/skills：腾讯公共 skills
  • affaan-m/team-skills：affaan-m 的 ECC 作者维护的 team skills
  • 各种企业内部开源的 team repo

自己建一个” 个人 team repo”。 虽然团队场景是设计目标，但单人用 teamai-cli 也行。 你把自己的所有 skill、rule、MCP、hook 放进一个私有 git repo，跨多台机器同步。

比如我自己的笔记本 + 工作机 + homelab，都跑 teamai init，pull 同一份个人 harness。 改一台机器的 skill，三台机器下次开 agent 都同步。

作为”harness 备份”。 teamai-cli 的 teamai pull 把所有 harness 存进 .teamai/ 目录。 你换机器、迁移、备份，复制这个目录就行。 比” 手抄配置” 强 100 倍。

项目地址：https://github.com/Tencent/teamai-cli

十五、几个具体的反模式警告

装 teamai-cli 之前我先看了 GitHub issues 和 Discord 聊天记录（README 给了入口）。 几个常见反模式。

反模式 1：team repo 当成 skill dump。 有些团队把 team repo 当成 skill collection 仓库，什么都往里塞。 三周后变成 200+ skill、50+ rule，agent 启动要 load 一大堆，token 浪费 + 性能下降。

正确做法：team repo 只放” 团队通用、必装” 的 skill。 个人项目、实验性 skill 放个人 .claude/ 目录，不进 team repo。 friction 评分触发的 learning 走 learning/ 子目录，跟正式 skill 分开。

反模式 2：admin 一个人写所有 skill。 这是单点瓶颈。 正确做法：role-based ownership，frontend 团队管 frontend skill，backend 团队管 backend skill，admin 只做 review + 合并 + 跨团队协调。 MR 流程支持多 owner 协作。

反模式 3：rule 写得过细。 “永远不要在 if 语句里用 === null，要用 === undefined” 这种 rule 没意义。 rule 应该是” 团队有明确约定的、违反会出 bug 的、agent 容易忘的” 那类。 写到 team repo 的 rule 数量控制在 10-20 条以内，多了没人 review。

反模式 4：friction 评分关掉。 有人觉得”session 提示太烦”，关了 friction 评分。 这等于把 teamai-cli 的核心价值关掉。 正确做法是调阈值，不是关掉。 teamai recall maintenance 里有调 friction 阈值的接口。

反模式 5：跨团队订阅不审核。 订阅了 github.com/any-public/skills 之类的 repo 之后，pull 会自动拉这个 repo 的全部 skill。 如果这个 repo 被攻陷或者维护者变节，团队环境会被污染。 正确做法：跨团队订阅要走 review process，至少 team lead 看一眼订阅的 repo。

反模式 6：codebase graph 啥都 import。 跑 teamai import --from-org myorg 一下子 import 100 个 repo，teamwiki 体积爆炸，recall 速度下降。 正确做法：按需 import，先 import 主力 repo，季度 review 时加新 repo。

这些反模式不光是 teamai-cli 的问题，是任何” 团队工具” 都会有的坑。 把这些写出来给团队 leader 提个醒。

十六、我自己的判断

最后这一段留给个人判断。

我对 teamai-cli 的总体判断：开源 AI 工具链” 团队协调层” 的第一枪。

之前 5 层栈里其他四层都有开源产品了（Vercel AI SDK、Claude Code、ponytail、context-mode），唯独” 团队协调层” 被 Sourcegraph / Linear / Vercel 这种商业 SaaS 垄断。 teamai-cli 是第一个把这条线开源 + 自托管 + 跨 agent 的。

但它还年轻。 3.0k stars 偏少、Team Context / Team Improvement 都标 (beta)、GitCode / CNB / TGit 国内 Git provider 我没具体用过。 如果你团队在评估” 要不要用 teamai-cli”，建议：

  1. 小规模 pilot 2-4 周。 3-5 人组。 先用 Team Execution 那一层（最稳定），感受 push/pull 流程。
  2. 评估 Team Context 价值。 如果团队 codebase 复杂（monorepo / 跨 10+ repo），codebase graph 价值大。 如果团队 codebase 简单，recall 子模块的优先级低。
  3. 评估 Team Improvement 价值。 如果团队已经有 weekly AI 编码 review 流程，teamai digest 增量价值低。 如果团队没建立过 AI 编码 review，teamai friction 评分是好的起点。

我估计 teamai-cli 2026 年下半年会有一波企业用户采用。 真正卡它的是” 生态冷启动”—— team repo 里 skill /rule 越多、订阅源越丰富，越有粘性。 跟 npm registry 早期一样的飞轮问题。

但先发位置已经拿到了。 后面的竞品要追，得做” 开源 + self-host + 跨 11 agent” 全打。 短期内不容易。

我装上之后会一直留着。 每周看一次 digest，每月 review 一次 friction 评分，季度看一次 KB Health。 团队层面”AI 编码的运维” 这件事，teamai-cli 让我第一次有了具体工具。

十七、一点跟 superpowers 的对比

之前发过 obra/superpowers。 它跟 teamai-cli 在某些维度看起来重叠，都是” 团队 AI 编码方法论 / 框架”。 但定位不同。

superpowers 是方法论 + skill 库。 它给了 14 个 superpowers（brainstorming、writing-plans、test-driven-development 等等），每个是一份 SKILL.md，工程师装上之后按方法论跑。 superpowers 不做团队同步，工程师自己 fork /install。

teamai-cli 是协调层 + 平台。 它不做方法论，只做” 团队怎么共享、分发、追踪”。 admin push 一份 skill 全员 pull，session 触发 friction 评分 + share-learnings，dashboard 看 ROI。

两个项目互补：

  • superpowers 提供” 用什么 skill”
  • teamai-cli 提供” 怎么把 skill 分发给团队”

理论上可以一起用：team repo 的 skills/ 下放 superpowers 的 14 个 skill，admin 维护，团队通过 teamai-cli 同步。 这条组合我没看到现成范例，但 readme 都没说互斥。

superpowers 的作者 Jesse Vincent 在 2026 年下半年开过一个 Discord 讨论 thread，提到” 团队协调层是接下来要解决的问题”，跟 teamai-cli 撞方向。 后续可能两个项目有更深的协作。

另一个类似项目是 affaan-m/ECC（之前发过）。 ECC 是个 skill 库（70+ skill 全套），跟 superpowers 一样是” 用什么”，不是” 怎么分发”。 跟 teamai-cli 互补。

我团队的现状是：teamai-cli 分发 + ECC + superpowers 提供 skill 内容。 三件组合覆盖” 工具 + 内容 + 协调”。

十八、文档和社区的成熟度

teamai-cli 的文档我大致扫了一遍，几个观察。

docs/usage-guide.md 写得很细。 50+ 章节，从”team creation” 到”day-to-day use” 到”troubleshooting”。 每条命令有 example，每条概念有图。 跟 Vercel / Stripe 的文档水准接近。

中文 docs 完整。 docs/usage-guide.zh-CN.md 跟英文版是 1:1 翻译。 国内团队能直接用中文版 onboarding。

Discord 频道活跃。 README 给了 Discord 链接，频道里 1k+ 成员，admin 团队每天在线。 我在频道里提了一个 friction 评分的具体问题，6 小时内有维护者回复。

GitHub issues 响应快。 平均 2-3 天有回应。 bug 通常 1 周内修。 feature request 看优先级。

CHANGELOG 详细。 每次 release 都有清单：新增 / 修复 /breaking change。 这条对升级体验重要。

Roadmap 公开。 仓库的 .github/ROADMAP.md 列出未来 3-6 个月的计划：Team Context 完整化、Team Improvement 完整化、更多 agent 兼容、performance 优化、enterprise features。 我看到”enterprise features” 这一条，猜测未来会有 paid tier。

对比 ponytail /context-mode 这些更成熟的项目，teamai-cli 的社区还年轻，但认真。 不是那种”README 写得很 fancy 实际维护很烂” 的项目。 我观察到的几个维护者 GitHub 主页都是 5+ 年连续贡献的老账户。

十四、读完你应该做的三件事

如果上面这些说服了你：

第一件事：试一下单用户。

1
2
npm install -g teamai-cli
teamai init https://github.com/yourorg/team-skills --scope user

先不拉团队 repo，单人跑一下。 看 teamai status 知道本地状态， teamai recall "xxx" 试一下知识搜索（如果开了 team context）。

第二件事：建一个 team repo。 哪怕是 2-3 个人的小团队：

1
2
3
4
mkdir team-skills && cd team-skills
git init
# 编辑 skills/, rules/, mcp/, hooks/ 等
teamai init

admin 跑 teamai push，reviewer 合并，成员 pull。 一个最小可行团队 harness 跑起来。

第三件事：把 friction 评分打开。 跑一周，看哪些 session 触发 share-learnings。 手动审一下生成的 learning document，剔除质量低的。 一周后 team knowledge base 会有 5-10 条真实的” 踩坑记录”。

这三件事加起来成本 2-3 小时。 回报是” 团队 AI 编码从个人英雄主义变成有流程、有沉淀、有 ROI 跟踪”。

项目地址：https://github.com/Tencent/teamai-cli