重复是学习之母。——狄更斯

TeamAI：让团队的 AI 协作拥有同一套语言、记忆与进化路径

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

当 AI 编程助手逐渐进入日常研发流程，真正需要解决的问题，已经不只是“某个模型能不能写代码”。

一个人可以给 AI 一段提示词，让它完成一次代码修改；但一个团队想让不同成员、不同项目、不同 AI 工具中的代理都按同样的方式工作，就会遇到更多现实问题：

团队的开发规范怎样同步给每一个 AI
已经沉淀的技能、规则和文档怎样持续分发
不同成员使用不同 AI 工具时，如何避免工作方式彼此割裂
一次任务中的纠正、失败和经验，怎样从个人会话变成团队资产
大型代码库的结构、依赖和规则，怎样变成 AI 可检索、可理解的知识

TeamAI 给出的答案是：把团队经验做成一套可以管理、同步、检索和持续改进的 Harness。

它的目标非常明确：Make Every Team AI Native。

TeamAI 管理团队的 Skills、Rules、MCP 和 Knowledge，并将这些资源分发到 Claude Code、Codex、CodeBuddy、WorkBuddy、OpenCode、Cursor 等 AI Agent 中。它不只是一个用于安装资源的命令行工具，更试图把团队执行方式、团队上下文和团队改进过程连接起来。

当 AI 从个人工具变成团队成员

AI 工具的能力正在快速增长，但团队协作的难题不会因为模型变强而自动消失。

如果每位成员各自维护提示词、规则文件、MCP 配置、技能目录和工作习惯，那么团队中的 AI 很快会出现另一种分裂：

有的人让 AI 先写计划，有的人让 AI 直接修改。

有的人给 AI 配了代码审查规则，有的人没有。

有的人把项目文档、经验和排障记录整理给 AI，有的人每次都从零开始解释。

有的人使用 Claude Code，有的人使用 Codex、Cursor 或 OpenCode，资源格式与注入方式又各不相同。

最终，团队里虽然有很多 AI，却没有形成真正可复用的 AI 协作能力。

TeamAI 希望把这些零散内容放进同一个团队共享仓库中，让技能、规则、文档、环境变量、Hooks、MCP 配置和代理定义能够沿着统一流程进入成员本地的 AI 工具。

它所强调的不是某一个代理如何表现，而是整个团队如何让每一个代理都理解并遵循团队的工作方式。

三层架构：执行、上下文与改进

TeamAI 将产品架构划分为三个层次：

层次	目标	当前 CLI 中的内容
Team Execution	让每个 Agent 按团队方式工作	`init`、`pull`、`push`、Skills、Rules、Agents、Hooks、MCP、环境变量
Team Context	让每个 Agent 理解团队	Recall、Learnings、代码库图谱、TeamWiki
Team Improvement	让每次执行都推动团队进步	基于摩擦的经验分享、Sessions、Digest、Dashboard

这三层构成了一条从“让 AI 做事”到“让 AI 理解团队”，再到“让 AI 协作持续变得更好”的路径。

Team Execution：先让 AI 用同一种方式工作

执行层是 TeamAI 当前最直接的能力。

团队可以把各类资源维护在共享 Git 仓库中，再通过 push → review & merge → pull 的流程分发给成员。

1
2
3

teamai push → create branch + MR → reviewer approves + merges
                                         ↓
              SessionStart hook → teamai pull → synced to local AI tools

这条流程把团队资源的更新纳入熟悉的协作节奏。

成员在本地调整资源后，通过 teamai push 推送到分支并创建合并请求。经过审查与合并后，其他成员的 AI 会话启动时，可以通过 SessionStart Hook 触发 teamai pull，把最新资源同步到本地 AI 工具中。

于是，团队规则不再需要依靠口头传达，也不需要每个人手动复制粘贴。

它们可以像代码一样被维护、被审查、被合并，并被自动带入团队成员的 AI 工作环境。

Team Context：让 AI 不只会执行，还知道团队已经学到了什么

仅仅把技能和规则分发给代理还不够。

一个团队在长期开发中会不断积累经验：遇到过的问题、被修正过的错误、有效的排障方式、代码库中的结构关系、跨项目依赖、部署约束和业务规则。

如果这些内容始终停留在个人记忆、零散聊天记录和临时文档中，那么每次新的 AI 会话开始时，代理仍然像第一次进入团队一样陌生。

TeamAI 的 Team Context 层试图把积累的团队经验组织为可搜索的知识库，让 AI 在需要时自动回忆。

Team Improvement：让每次执行都留下可供团队使用的东西

真正成熟的团队协作，不只是完成当前任务，也会从任务中不断提炼更好的工作方法。

TeamAI 的改进层围绕会话、使用情况、团队摘要、仪表盘和知识维护展开。

一次任务中出现的中断、纠正、工具调用失败、反复重试，可能都是值得记录的摩擦信号。它们意味着当前的 Skills、Rules、文档或知识库也许还不够完善。

TeamAI 希望把这些信号变成团队可以消化的改进机会，而不是让它们随着会话结束一同消失。

一个共享仓库，装下团队的 AI 工作方式

TeamAI 将不同类型的团队资源组织在共享仓库中。

资源	团队仓库中的位置	作用
Skills	`skills/<name>/SKILL.md`	为 Agent 提供可复用技能
Rules	`rules/*.md`	定义团队规则
Docs	`docs/`	保存基础项目文档，并支持渐进式加载
Agents	`agents/<name>.yaml`	定义 Agent
Culture	`culture.md`	保存团队使命、价值观和工作原则
CLAUDE.md	`claudemd/*.md`	管理相关说明内容
Env	`env/`	保存共享团队级环境变量与开关
Hooks	`hooks/hooks.yaml`	管理 Hook 配置
MCP	`mcp/mcp.yaml`	管理 MCP 配置
Packages	`teamai.yaml`	管理 npm 包与 Claude Code 插件
Models	—	并非每个提供商都已实现

其中，culture.md 具有一种很特别的定位。

它承载团队使命、价值观和工作原则，并会被注入每个 Agent 的 CLAUDE.md 或 AGENTS.md 中。这样一来，团队文化不再只是文档首页的一段文字，而能够成为每次 AI 会话继承的一部分。

对于团队而言，这种共享并不局限于技术规则。

“代码应该如何修改”“什么样的变更需要先计划”“怎样处理风险”“怎样进行审查”“团队重视什么”都可以成为 AI 工作环境中的长期约束与共同语言。

从初始化开始，让团队资源进入本地 AI 工具

安装 TeamAI CLI 的方式很直接：

1	npm install -g teamai-cli

对于团队管理员或个人使用者，可以先创建一个共享体验仓库，再执行初始化。

成员可以在项目范围内初始化：

1 2	cd /path/to/my-project teamai init https://github.com/yourorg/yourrepo

也可以选择用户范围的安装方式：

1	teamai init https://github.com/yourorg/yourrepo --scope user

项目范围会将资源安装在项目目录下。

用户范围则会将资源安装在用户目录中。

初始化完成后，每一次 AI 会话都可以自动拉取管理员发布的最新 Skills、Rules 与其他 Harness 更新，不需要成员手动执行同步操作。

这使得团队资源的更新拥有了一种持续流动的能力。

团队管理员负责维护共享内容，成员获得经过审查的最新版本，AI 工具则在会话启动时接收这些内容。

一支团队，可以有角色，也可以有选择

并不是每位成员都需要拥有完全相同的 AI 资源。

前端开发、后端开发、测试、运维、架构和产品协作，可能都需要不同的 Skills、Rules 和文档集合。若所有资源无差别分发，不仅容易造成冗余，也会让每个成员的本地 AI 环境变得臃肿。

TeamAI 提供了分发控制能力。

能力	命令	作用
Roles	`teamai roles`	定义角色到命名空间的映射，让成员只同步与其角色相关的 Skills
Tags	`teamai tags`	为 Skills 与 Rules 添加标签，让成员只订阅需要的标签
Sources	`teamai source`	订阅额外的 Skill 仓库，包括其他团队的公开仓库或组织内共享仓库

角色让资源分发能够与团队职责相匹配。

标签让成员可以按需要订阅资源。

来源则让团队可以接入额外的 Skill 仓库，让可复用的工作能力不必局限于一个单独团队仓库。

这让 TeamAI 的共享机制并不是简单地“把所有文件同步到每个人机器上”，而是允许团队根据角色、标签和来源建立更细致的资源流动路径。

让经验不再只存在于一次会话中

AI 会话中有很多看似微小、但实际上很有价值的信号。

用户中断了 AI。

用户纠正了 AI。

用户拒绝了一次工具调用。

AI 反复重试失败的工具。

这些事件说明，任务中可能出现了值得记录的问题，也可能暴露出团队当前规则、技能或文档中的空缺。

TeamAI 会在会话结束时通过 Stop Hook 对会话进行摩擦评分。

当会话中出现值得关注的摩擦信号时，系统可以提示成员考虑运行 /teamai-share-learnings，把这次任务中的经验进行总结并共享给团队。

[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.

提示会列出触发它的非零摩擦信号，并在可用时包含经过脱敏处理的首个任务摘要。

这种设计并不是要求把每次会话都强行变成文档，而是在摩擦出现时提醒团队：这里可能有一条经验值得留下。

一次被多次纠正的任务，可能意味着规则没有说清楚。

一次反复失败的工具调用，可能意味着环境、文档或流程需要更新。

一次复杂的排障过程，可能意味着团队应该沉淀一份新的技能或知识条目。

当这些经验通过共享进入团队知识库，下一位成员和下一次 AI 会话就不必再从同一个坑里重新出发。

Recall：让 AI 在开始任务前先回忆团队经验

TeamAI 的知识召回能力默认关闭，需要团队显式启用。

1
2
3

teamai recall enable
teamai recall disable
teamai recall status

启用后，teamai pull 会将内置的 teamai-recall Subagent 部署到每个 AI 工具的 agents/ 目录中。

当 AI 开始处理任务前，可以调用该 Subagent 搜索团队积累的知识。搜索命中结果会以排序形式呈现，包含作者、分数、标签和匹配信息。

1	teamai recall "port conflict"

它能够让代理在处理问题前，先查看团队是否已经有过相关经验。

例如，某个端口冲突问题是否曾在合并请求审查中被发现过，某类部署配置是否已经有最佳实践，某项排障知识是否已经被团队成员沉淀。

这改变了 AI 的起点。

它不再每次都面对一片空白的上下文，而是有机会从团队已经积累的经验中找到方向。

从源码中提取结构，让代码库成为可理解的图谱

大型代码库对 AI 来说有一个天然难题：代码往往远远超过单次上下文窗口的容量。

多个仓库、数十万行代码、跨服务 RPC、消息队列、数据库依赖、深层调用链和隐藏在配置中的规则，都会让 AI 难以形成稳定的全局认知。

TeamAI 通过 teamai import 和 teamai codebase 将源代码解析为位于 teamwiki/ 下的结构化图谱。

teamai import --from-repo https://github.com/org/repo
teamai import --from-org myorg
teamai codebase --extract /path/to/repo
teamai codebase --reconcile --output /path/to/repo
teamai codebase --lint --output /path/to/repo

图谱可以保存组件、接口、配置以及跨仓库导入边。

当召回结果来自代码库页面时，结果会包含相关源文件路径，让 Agent 能够从更直接的位置开始处理代码变更，而不是重新阅读整个仓库。

代码关系的提取来自两条并行路径。

一条是 AST 路径，面向 TypeScript、JavaScript、Python 和 Go，通过 WASM tree-sitter 解析器提取 import、require、调用位置和 TypeScript 的 implements 关系，并解析到精确文件。

另一条是启发式路径，适用于所有语言，也包括 Java 和 Rust，通过正则提取关系，并标记为 code-heuristic。

当两条路径出现重叠时，AST 结果优先。

WASM 解析器是纯 JavaScript 依赖，不需要原生工具链。如果解析器无法加载，提取过程会回退到启发式路径，并记录对应状态。

这种机制并不试图让 AI 每次都重读完整源码，而是将源码中的结构信息转化为更适合检索和理解的团队知识。

TeamWiki：把海量代码压缩成 AI 可使用的知识体系

TeamAI 内置的 team-wiki-codebase Skill 面向大型代码库的 AI 认知工程。

它试图解决的问题非常典型：

痛点	具体表现
上下文装不下	多仓库与大规模代码量超出 AI 上下文窗口
关系看不清	微服务之间的 RPC、消息队列和数据库依赖分散在不同仓库
规则记不住	业务约束、状态机和配置参数隐藏在深层调用链中
回答不准确	AI 只能看到局部代码，缺少全局架构认知
Token 消耗大	每次提问都需要重新阅读大量源码

对应的解决方向，是通过架构逆向工程，将代码压缩为结构化知识库。

知识结论可以附带代码文件与行号作为证据。

组件关系可以标注为 EXTRACTED、INFERRED 或 AMBIGUOUS。

生成后可以进行准确性统计，并在超过阈值时发出警告。

AI 可以优先读取知识库，而不是直接反复读取源码，以更少的 Token 消耗获得全局架构认知。

该体系可生成架构总览、业务架构、部署架构、组件设计说明、产品代码映射、产品规则速查表、业务开发规范、反模式、RPC 契约、排障记录，以及覆盖组件依赖、调用链路、数据流、错误码、交互场景、知识三元组、风险影响面、配置参数和业务规则的图谱文档。

它不是简单把代码翻译成自然语言，而是试图建立一套让 AI 能够沿着证据、关系和检索路由理解复杂系统的知识结构。

团队知识也需要维护

知识库不是建成之后就永远正确。

随着 Skills、Rules、文档和经验不断增加，团队也会遇到新的问题：哪些经验已经不再适用，哪些技能长期无人使用，哪些规则已经过时，哪些文档需要更新。

TeamAI 提供 teamai recall maintenance 用于维护知识库健康状态。

1
2
3

teamai recall maintenance --prune --dry-run
teamai recall maintenance --prune --archive
teamai recall maintenance --update-quality

其中可以预览清理结果，也可以归档未使用的 Learnings，并针对过时的 Skills 或文档生成更新草稿。

TeamAI 的改进层还提供了使用摘要、会话保存与仪表盘能力。

能力	命令	展示内容
Usage	`teamai digest`	团队周报，包含 7 天成功率、提示、活跃时间、预估成本、缓存和纠正趋势，以及累计总量
Sessions	`teamai session save`	经隐私处理的单会话摘要，包括工具序列、提示轮次和干预情况
Dashboard	`teamai dashboard`	展示实时会话，以及本地 7 天趋势与此前 7 天趋势的对比
KB Health	`teamai dashboard`	展示知识库使用和健康状态，包括覆盖类型、常被召回条目、未被使用条目和召回趋势

这让团队不只能知道 AI 是否被使用，也能看到团队资源是否真正发挥作用。

技能有没有被调用。

知识有没有被召回。

哪些条目始终沉默。

哪些会话中持续出现纠正与摩擦。

这些都可以成为后续改进团队 AI 工作方式的依据。

从一次合并请求中提炼可复用知识

TeamAI 还提供了面向 CI 的合并请求知识提炼能力。

在合并请求或拉取请求创建、更新时，可以运行：

1	teamai ci extract-mr --mode comment

将知识建议以评论形式发布到合并请求或拉取请求中。

在合并后，可以运行：

1	teamai ci extract-mr --mode write

将 Learning 和 teamwiki/ 图谱写入团队知识仓库并推送。

这样一来，代码审查和知识沉淀可以被连接到一起。

一次合并请求不只是一次变更交付，也可能成为团队知识库增加新内容的节点。审查中发现的问题、实现中暴露的设计关系、变更中体现的规则，都有机会在合并流程中被提取和保存。

覆盖多个 AI Agent 与 Git 服务

TeamAI 的执行层支持多个 AI Agent，并在 Skills、Rules、Docs、环境变量、Agents、Hooks、MCP、Learnings、Codebase、TeamWiki、Usage、Sessions 和 Dashboard 等维度提供不同程度的能力覆盖。

README 中列出的 Agent 包括：

Claude Code
Codex
Cursor
CodeBuddy
WorkBuddy
OpenCode
OpenClaw
Hermes
DeepSeek Harness
Qoder
ZCode

在 Git 托管服务方面，TeamAI 支持 GitHub、GitLab、GitCode、CNB、TGit 和私有 Git 服务。

这让团队可以把自己的共享资源托管在已有的 Git 基础设施中，再通过 TeamAI 将资源分发到不同 AI Agent 环境。

AI 工具可以不同，团队 Harness 仍然可以保持一致。

一组围绕团队协作展开的命令

TeamAI 的命令设计围绕初始化、同步、贡献、召回、图谱、维护和诊断展开。

命令	作用
`teamai init`	初始化，包括 OAuth 登录、关联仓库、注册成员与注入 Hooks
`teamai pull`	拉取团队资源并注入本地 AI 工具
`teamai push`	将本地资源推送到分支并创建合并请求
`teamai packages`	安装声明的 npm 包和 Claude 插件
`teamai status`	显示本地与团队仓库的差异
`teamai contribute`	将会话经验贡献到团队仓库
`teamai recall <query>`	搜索团队知识库
`teamai recall enable/disable/status`	启用、关闭或查看召回状态
`teamai recall promote`	将高置信度 Learning 提升为正式知识
`teamai recall maintenance`	维护知识库健康状态
`teamai import`	导入知识
`teamai codebase --extract`	提取代码事实并在 `teamwiki/` 下建立本地图谱
`teamai codebase --reconcile`	让产品文档与提取出的代码知识进行协调
`teamai codebase --lint`	检查知识图谱健康状态
`teamai ci extract-mr`	在 CI 中从合并请求提取知识
`teamai members`	查看团队成员
`teamai roles`	管理团队角色与命名空间
`teamai tags`	管理基于标签的 Skills 与 Rules 过滤
`teamai skill exclude`	管理不参与本地同步的 Skills
`teamai source`	管理额外订阅的 Skill 来源
`teamai remove`	删除资源并创建合并请求
`teamai session save`	记录经过隐私处理的会话摘要
`teamai digest`	生成团队周度使用摘要
`teamai doctor`	诊断配置问题
`teamai uninstall`	移除全部 TeamAI 资源与 Hooks

这些命令并不是围绕单个模型能力设计的，而是围绕团队资源的生命周期设计的。

资源从哪里来，如何同步，如何被筛选，如何被更新，如何从会话中产生新经验，如何被检索，如何被维护，如何被诊断，都被纳入同一个命令行体系。

让 AI 从临时帮手变成团队能力

TeamAI 最值得关注的地方，在于它并不把 AI 协作理解为“每个人都多了一个聊天机器人”。

它把团队 AI 化看作一种更完整的工程能力。

团队要有共同的规则。

团队要有可分发的技能。

团队要有可以复用的文档和环境配置。

团队要有跨工具的一致工作方式。

团队要有可检索的历史经验。

团队要从失败、纠正和摩擦中提炼知识。

团队还要定期检查，哪些资源仍然有效，哪些知识已经陈旧，哪些工作方法值得被固化。

当这些内容被组织进共享 Git 仓库，通过审查和同步进入不同 AI Agent，AI 才不只是一个临时执行提示的工具。

它会开始继承团队的技能、规则、文化和经验。

它会在启动任务前尝试理解团队已经知道什么。

它会在任务结束后，把值得留下的摩擦与经验带回团队。

它会让一次执行不只服务于当前任务，也可能成为下一次任务更顺畅的起点。

这正是 TeamAI 所描绘的方向：不是让某一个 Agent 变得更聪明，而是让整个团队的 AI 协作逐渐拥有记忆、秩序与成长能力。