单仓库的天花板
一个团队把 teamai-cli 用起来之后（接入流程），配置资产很快会突破团队边界：
- 平台团队沉淀了「内部部署平台的使用 Skills」——所有业务团队都需要
- 安全团队维护着「安全编码红线 Rules」——应该全组织强制生效
- 数据团队整理了「数据查询规范」——和分析相关的团队都想用
- 某个业务团队打磨出一个特别好的代码审查 Skill——隔壁团队眼馋
按单仓库模式，这些需求的解法是「把内容复制一份到各自仓库」——于是回到了配置管理的老路：同一份资产 N 个副本，更新不同步，质量参差。
teamai-cli 的 source 机制给出了正确的解法：仓库引用仓库。你的团队仓库可以订阅其他团队的仓库作为「源」，源仓库的 Skills 按需引入进来，源头更新时所有订阅方跟进。这是软件包管理器（npm、pip）的思想在 AI 配置领域的复刻——依赖声明 + 中心源 + 版本同步。
source 的两个核心命令
添加源
teamai source add <git-url> --name <名称>把一个 teamai 仓库声明为你的上游源。比如业务团队订阅平台团队的经验库：
teamai source add https://github.com/your-org/TeamAi-Platform --name platform浏览源内容
teamai source browse列出已订阅源里有哪些可用的 Skills 和配置，按需引入。引入的粒度由你控制——订阅整个源仓库，还是只挑其中几个 Skills，取决于源仓库的角色划分方式。
联邦架构下的三种经典角色
跨团队订阅机制天然长出三种「仓库角色」，各自有不同的运营方式：
平台源（被多方订阅）：平台/基建/安全团队的仓库。运营要点是稳定——变更走严格审核（你是别人的上游，你的一次 push 影响全组织），语义化描述、审慎的破坏性变更管理是基本功。
业务仓库（订阅 + 自有）：普通业务团队的仓库，混合形态——一半是自己团队的私有配置（业务领域 Skills），一半是订阅的平台资产。运营要点是边界清晰：订阅来的内容不直接改（改了下次同步就丢），需要的定制用本地包装层实现。
公开源（跨组织）：开源社区的 teamai 仓库。比如某个开源项目维护者把自己的开发 Skills 发布出来，外部团队订阅引入。这是「全球经验市场」的雏形。
引入外部 Skills 的安全纪律
订阅机制带来了效率，也带来了供应链式的风险面：你引入的 Skills 是「给 AI 执行的指令」，来源不可信的 Skills 等于给 AI 注入不可信指令。 引入外部源时的四条纪律：
- 只订阅可信来源——内部先有审核共识，再订阅；外部源先人工审读 Skills 内容，再引入
- 引入后本地 review——source browse 看到的内容在启用前过目一遍，特别是包含脚本执行、工具调用的 Skills
- 锁定与跟进策略——重要生产环境的团队，源更新后先在测试成员/项目上观察一轮再全员同步
- 敏感信息隔离——订阅源的 Skills 不应该接触你的本地凭证；配置分层原则（共享层与个人层分离）在跨团队场景下更加重要
这套纪律和软件供应链安全的思路完全一致——AI 配置是新型依赖，依赖管理的历史教训直接适用。
组织落地的推进路线
想在组织里推行「经验联邦」，推荐三步走：
第一步，单点验证（1~2 个月）。 挑一个协作密度高的团队把本团队仓库用起来，攒出第一批高质量 Skills——没有内部的成功案例，跨团队推广无从谈起。
第二步，竖起第一个平台源。 从平台团队（或最有经验沉淀的团队）选一个，把通用性资产发布为组织级源，让 2~3 个团队订阅试用，跑通「源更新 → 订阅方同步」的全链路。
第三步，联邦成型。 更多团队建仓、更多源被发布，组织内形成「平台源 + 业务仓库」的网络。此时配套建立两件事：源的发布审核标准（什么内容够格成为组织级源），以及跨源去重机制（避免两个平台源提供重叠的 Skills）。
source 命令速查表
联邦机制的核心命令就两条，配合日常同步命令使用：
| 命令 | 作用 | 使用时机 |
|---|---|---|
teamai source add <git-url> --name <名称> | 把一个仓库声明为上游源 | 决定订阅时执行一次 |
teamai source browse | 浏览已订阅源里可用的 Skills 与配置 | 引入内容之前挑选 |
teamai pull | 同步源更新与自有配置 | 日常，或 SessionStart Hook 自动 |
teamai status | 检查本地与远端差异 | 确认订阅内容已落位 |
teamai list | 查看当前实际启用的技能 | 引入后核对结果 |
跨团队订阅 FAQ
Q：订阅来的 Skill 可以直接改吗？ 不可以。源更新时订阅内容跟着同步，本地直接改会在下次同步时被覆盖。需要定制时用本地包装层实现——定制逻辑与源内容分离，源升级和本地定制互不干扰。
Q：源仓库更新后，什么时候到达我的团队？ 节奏与团队内配置一致：手动 pull 立即生效，SessionStart Hook 则在下次会话启动时自动跟进。生产环境团队建议用前文安全纪律里的观察策略：源更新先在个别成员或项目上跑一轮，再全员同步。
Q：能同时订阅多个源吗？
可以。add 命令自带 --name 参数，每个源独立声明、独立命名——平台源、安全源各自接入，browse 时分开浏览。订阅是声明式关系，加和删都是一条命令的事。
Q：怎么判断该不该订阅某个源？ 回到安全纪律四条：来源可信（内部有审核共识，外部已人工审读）、内容 review 过、跟进策略明确、与现有 Skills 无重叠。跨源去重是联邦运营的长期课题——两个源提供重叠 Skills，和团队内功能重叠的 Skills 一样，会让 AI 行为不可预测。
Q：订阅关系和「复制一份过来」到底差在哪？ 复制得到的是副本——源头更新后副本原地过期，N 个订阅方就是 N 份失步风险；订阅得到的是引用——源头一次更新，所有订阅方在下次同步时跟进。前者省了一分钟，后者省掉的是永久的同步人力。
与其他协作形态的关系
把视角拉远：teamai 的 source 联邦解决的是「配置与经验」的跨团队流动，组织里还有别的 AI 协作形态在并行——Multica 这类 agent 管理平台解决「AI 执行任务的项目管理」，AgentDock 这类运行时解决「AI 操作真实机器」。
三者的关系是分层互补：运行时管执行环境，管理平台管任务协作，teamai 管知识与配置。一个成熟的 AI 组织最终会三层都有——而 teamai 的联邦机制，是三层里最容易被低估、但复利效应最强的一层：知识资产每多一个团队订阅，边际成本为零，边际价值递增。