AI Agent 的 MCP 和技能包太多了怎么办？用 GitOps 能力注册表告别上下文膨胀
你最近是不是也这样？为了让 AI 编程 Agent 变得更强大，一口气配置了十几个 MCP 服务器——文件系统的、数据库的、浏览器自动化的、Jira 的、Slack 的……再叠加一堆 Skills prompt 和自定义工作流。Agent 确实变强了，但代价呢？
每个会话启动时，Agent 要把所有 MCP 工具描述和技能指令塞进上下文。随着配置项越来越多，你的 Token 消耗在飙升，模型却越来越”迟钝”——它花在理解可用工具上的 Token 比真正解决问题的还多。这就是 AI Agent 的能力膨胀（Capability Sprawl）问题。
为什么这是一个真问题
能力膨胀不只是”有点浪费”的事情。设你配了 6 个 MCP 服务器 × 平均每个暴露 5 个工具 = 30 个工具。一个工具的描述平均 200 Token，光工具列表就吃掉 6000+ Token。再加上 Skills 的系统提示词、路由规则、配置说明——一个基础会话还没开始干活就烧掉了 5000-10000 个上下文 Token。
而且，这不仅仅是 Token 浪费的问题：
- 模型迷失：工具太多，模型频繁选错工具，或者犹豫不决产生多余推理步骤
- 上下文污染：不相关工具的描述干扰了模型的判断
- 维护噩梦：每个人都要手动维护自己的 AGENTS.md，每个项目独立配置，没有统一的版本管理
- 重复造轮子：团队内每个人重复写同样的 MCP 配置和 skill 提示词
现有方案的局限
| 维度 | 传统方案 | 问题 |
|---|---|---|
| AGENTS.md | 每个项目一个静态文件 | 不可复用，难以维护，一改全改 |
| 预置 Prompt | 加载全部 tools/skills | Token 浪费，上下文膨胀严重 |
| Cursor Rules | 项目本地规则 | 不跨项目，团队共享困难 |
| 手工裁剪 | 每次仅加载需要的工具 | 心智负担大，容易漏掉关键依赖 |
GitOps 能力注册表方案
AI Capability Registry 采用了一种不同的思路：不是决定 Agent 能做什么，而是在需要时再决定用哪个能力。
它的核心理念很简单——把你的 MCP 服务器、Skills 指令和工作流当作版本化基础设施来管理：
ai-capability-registry/
├── registry/
│ ├── workflows.yaml # 工作流定义（按任务/角色分类）
│ └── routing.md # 路由指引
├── skill-catalog.d/ # Skills 目录（来自上游 Source）
├── mcp-catalog.d/ # MCP 服务器目录
├── roles/ # 角色定义（工程师、运维、数据分析师…）
├── AGENTS.*.md.template # 五种不同粒度的集成模板
└── scripts/
└── bootstrap.sh # 初始化脚本
安装与初始化
git clone --recurse-submodules https://github.com/Friz-zy/ai-capability-registry.git ~/.ai-registry cd ~/.ai-registry ./scripts/bootstrap.sh
bootstrap.sh 会自动：同步子模块、校验配置、从上游 Source 发现并索引 Skills、生成路由索引和工作流运行时说明。
核心功能一：按需加载
能力注册表的核心不是”加载所有”，而是渐进式按需加载。标准模板 AGENTS.full-registry.md.template 采用了”bootloader”模式：
cp ~/.ai-registry/AGENTS.full-registry.md.template /path/to/project/AGENTS.md
这个模板只做了几件事：
- 告诉 Agent 去读
capability-routing.md的路由指引 - 从
workflows/workflow.md加载工作流框架 - 只有在选定工作流后，才加载对应角色的 Skills
- 只有在角色需要时，才加载具体的 MCP 服务器
效果：一个普通任务可能只需要 2-3 个工具，而不是 30 个。
核心功能二：多粒度模板
不是所有项目都需要完整注册表。注册表预置了五种模板，按复杂度递减：
| 模板 | 包含 | 适用场景 |
|---|---|---|
AGENTS.full-registry.md.template | 工作流 + 角色 + Skills + MCP | 全功能多 Agent 团队 |
AGENTS.workflows.md.template | 工作流 + 角色，无 Skills/MCP | 流程管理为主 |
AGENTS.skills.md.template | Skills 路由 + MCP | 技能精选为主 |
AGENTS.mcp.md.template | MCP 路由 | 只管理 MCP 连接 |
AGENTS.workflows-skills.md.template | 工作流 + 角色 + Skills | 无 MCP 路由 |
你可以用最小模板起步，随需求增长逐步升级——不需要一开始就搭建完整的注册表架构。
核心功能三：GitOps 工作流
所有配置都纳入 Git 版本控制：
git add mcp-catalog.d/ git commit -m "feat: add PostgreSQL MCP server entry" git push ./scripts/bootstrap.sh
能力注册 vs 普通配置管理的关键区别：
- 版本化：每个变更都有 Git 历史，可以回滚
- 可审计：谁加了什么 Skill、什么时候加的、为什么加
- 可共享：团队内一键复制注册表即可共享全部配置
- 权限分离：trusted（信任）、reviewed（已审查）、candidate（候选）三级分离
核心功能四：工作流驱动的角色路由
能力注册表不只是”工具清单”，它包含工作流引擎。先定义工作流，再让工作流决定需要哪些角色，每个角色再按需加载技能：
用户请求 → 工作流路由（workflows/routing.md） ├─ 选中的工作流 → 涉及的 Role（如 "Code Reviewer"） │ ├─ 该 Role 需要的 Skills │ │ ├─ 代码审查 Skill → MCP: git, linter, diff │ │ └─ 测试 Skill → MCP: pytest, docker │ └─ 该 Role 不需要的 Skills → 不加载 └─ 不需要的工作流 → 完全跳过
这种”工作流 → 角色 → 技能 → MCP”的四层渐进加载，是从根本上解决能力膨胀的关键。
注意事项
- 上下文成本：完整注册表的 bootloader 本身也会消耗 Token。如果你只需要一个极简配置，直接用手工裁剪更划算。注册表的目标场景是”多 Agent、多任务、多项目”的团队，而不是”一个 Agent 做一件事”的个人使用。
- 不要照搬：
AGENTS.full-registry.md.template是一个良好起点，但你需要根据你的项目实际调整路由逻辑。没有银弹。 - MCP 安全：注册表鼓励用 Docker 容器或托管端点运行 MCP 服务器，而不是
npx一键安装。安全第一，便利第二。 - bootstrap 重新运行：每次更新 registry 后需要重跑
bootstrap.sh才能生效。
总结
能力膨胀是 AI Agent 从”个人玩具”进化到”团队基础设施”时必然遇到的瓶颈。AI Capability Registry 给出的不是精简配置的建议，而是用 GitOps 工作流管理能力膨胀的工程方案——把原本藏在每个开发者 .md 文件里的零散配置，变成团队共享的版本化基础设施。
当你下次觉得”Agent 的 MCP 服务器太多了”的时候，不妨试试用能力注册表来管理它们。
项目地址：github.com/Friz-zy/ai-capability-registry | 许可：MIT 核心概念：GitOps 管理 Agent 能力、渐进式按需加载、工作流驱动的角色路由