MCP 进企业：用 Catalog 和 Profile 管好你的 AI 工具集

2026-05-15 26 预计阅读时间：1 分钟
来源：docker.com AI 摘要 原文链接

免责声明：本文为 AI 摘要整理，建议结合原文阅读。摘要可能省略上下文、版本差异或边界条件，不作为官方说明。

预计阅读时间：10 分钟

Anthropic 的 Model Context Protocol（MCP）正在从"个人开发者玩一玩"走向"团队正式采用"。最近正式发布的 Custom MCP Catalogs 和 MCP Profiles 就是这一步的关键基础设施——前者解决"组织怎么分发批准的工具集"，后者解决"开发者怎么快速搭起来跑起来"。两个能力互补，拼在一起就是企业级 MCP 的完整交付链路。

为什么企业需要 Catalog，而不是让每个人自己找 MCP Server

过去用 MCP，流程大致是：开发者自己搜 GitHub，找一个看起来靠谱的 MCP Server，手动配 JSON，祈祷它能跑。问题很明显——

  • 版本不可控：同一个 Slack MCP Server，三个人可能用了三个不同 fork。
  • 安全盲区：没人审计过这个 Server 到底读了哪些文件、调了哪些外部 API。
  • 重复劳动：每个新人都得从零摸索一遍配置。

Custom Catalog 的思路很简单：组织维护一个"批准清单"，开发者从清单里选，而不是从互联网上捡。

一个 Catalog 就是一个经过审核的 MCP Server 集合。团队可以把内部自建的 Server 和社区精选的 Server 打包在一起，统一版本、统一描述、统一入口。新成员入职时，不需要到处问"你们用的哪个 MCP Server"，直接看 Catalog 就行。

Profile：把"配环境"从半小时压缩到一条命令

Catalog 解决了"从哪拿"，Profile 解决的是"怎么跑"。

一个 MCP Profile 是一组预配置的 MCP Server 及其运行参数。它描述的是：哪些 Server 要启动、用什么 transport（stdio / SSE）、传什么环境变量、挂什么参数。

开发者拿到一个 Profile，一条命令就能把整套工具链拉起来，而不是逐个编辑 mcp_config.json。这对以下场景尤其有用：

  • 新项目启动：项目模板自带一个 Profile，拉完代码 AI 工具链就就绪了。
  • 角色分工：前端工程师和后端工程师用不同的 Profile，各自只暴露需要的工具。
  • 环境切换：本地开发用一套 Profile（连本地数据库），CI 环境用另一套（连 staging 服务）。

实战：搭建一个团队 Catalog 和开发 Profile

下面用一个具体例子走完整个流程。假设你的团队需要三个 MCP Server：一个内部文档检索、一个 GitHub 代码搜索、一个 PostgreSQL 查询。

1. 定义 Catalog——团队批准的 Server 清单

创建一个 catalog.yaml，列出批准的 MCP Server 及其元数据：

# catalog.yaml — 团队批准的 MCP Server 清单
name: team-platform-catalog
version: 1.2.0
description: 平台工程团队批准的 MCP 工具集
maintainer: platform-team@company.com

servers:
  internal-docs:
    source: git+https://git.internal.company.com/mcp/mcp-docs-search.git#v2.1.0
    description: 搜索内部 Confluence 和 Markdown 文档
    capabilities:
      - tools: search_docs, get_page_content
    audit_status: approved
    audit_date: "2025-06-10"

  github-search:
    source: npm:@anthropic/mcp-server-github@0.3.8
    description: 搜索 GitHub 仓库、PR 和代码
    capabilities:
      - tools: search_repos, search_code, list_prs
    audit_status: approved
    audit_date: "2025-06-08"

  postgres-query:
    source: pip:mcp-server-postgres@1.0.4
    description: 对 PostgreSQL 执行只读查询（限 staging 环境）
    capabilities:
      - tools: query, list_tables, describe_table
    audit_status: approved-with-conditions
    conditions: 仅允许 SELECT，禁止写操作；仅连 staging DB
    audit_date: "2025-06-12"

几点注意：

  • source 支持 git 仓库、npm 包、pip 包等多种来源，版本号必须锁定。
  • audit_status 和 audit_date 是企业自己加的字段，用来追踪安全审核状态。Catalog 本身不强制这些字段，但强烈建议加上。
  • conditions 标注使用约束，比如 PostgreSQL Server 只允许只读查询。

2. 定义 Profile——开发者一键启动的配置包

接下来创建一个 profile.yaml，把 Catalog 里的 Server 组合成一个可运行配置：

# profile.yaml — 后端工程师的开发 Profile
name: backend-dev
description: 后端日常开发所需的 MCP 工具链
catalog: team-platform-catalog@1.2.0

servers:
  internal-docs:
    from_catalog: internal-docs
    transport: stdio
    env:
      DOC_SEARCH_ENDPOINT: "https://search.internal.company.com"

  github-search:
    from_catalog: github-search
    transport: stdio
    env:
      GITHUB_TOKEN: "${GITHUB_TOKEN}"  # 从宿主机环境变量注入

  postgres-query:
    from_catalog: postgres-query
    transport: stdio
    env:
      PG_HOST: "staging-db.internal.company.com"
      PG_PORT: "5432"
      PG_DATABASE: "app_staging"
      PG_USER: "readonly_dev"
      PG_PASSWORD: "${PG_STAGING_PASSWORD}"  # 从环境变量注入，不硬编码

关键设计点：

  • from_catalog 引用 Catalog 中的条目，版本和来源由 Catalog 控制，Profile 不重复声明。
  • 敏感值用 ${ENV_VAR} 占位，运行时从宿主机环境变量注入，避免密码写进 YAML。
  • transport: stdio 是本地开发最常用的模式；如果 Server 部署在远端，改为 sse 并指定 URL。

3. 用 CLI 启动 Profile

假设你用的是 Anthropic 官方 MCP CLI（或兼容客户端），启动流程如下：

# 1. 设置环境变量（敏感信息不入库）
export GITHUB_TOKEN="ghp_xxxxxxxxxxxx"
export PG_STAGING_PASSWORD="staging_ro_pwd"

# 2. 注册 Catalog（从本地或远程加载）
mcp catalog add ./catalog.yaml
# 或从远程 URL 加载：
# mcp catalog add https://platform.internal.company.com/mcp/catalogs/team-platform-catalog.yaml

# 3. 用 Profile 启动 MCP 工具链
mcp profile run ./profile.yaml

# 输出类似：
# ✓ internal-docs    (stdio)  running on pid 18234
# ✓ github-search    (stdio)  running on pid 18235
# ✓ postgres-query   (stdio)  running on pid 18236
# Profile "backend-dev" is active. 3 servers connected.

启动后，你的 AI 客户端（Claude Desktop、IDE 插件等）就能直接调用这三个 Server 提供的工具。

4. 为 CI 环境准备一个不同的 Profile

本地开发连 staging DB，CI 环境可能需要不同的参数。再建一个 profile-ci.yaml：

name: backend-ci
description: CI 流水线中使用的 MCP 工具链（只保留文档和代码搜索）
catalog: team-platform-catalog@1.2.0

servers:
  internal-docs:
    from_catalog: internal-docs
    transport: sse
    url: "https://mcp-docs.internal.company.com/sse"

  github-search:
    from_catalog: github-search
    transport: stdio
    env:
      GITHUB_TOKEN: "${CI_GITHUB_TOKEN}"

CI Profile 去掉了 PostgreSQL Server（CI 不需要查库），并把文档搜索改为 SSE 远端模式。这样不同环境用不同 Profile，工具集和传输方式都精确匹配场景。

采纳建议与注意事项

先从小 Catalog 开始。 不要一上来就把市面上所有 MCP Server 都塞进 Catalog。选 3-5 个团队高频使用的，审核通过后再逐步扩展。Catalog 的价值在于"批准清单"，清单太长反而失去筛选意义。

版本锁定是底线。 Catalog 里的每个 Server 必须锁定具体版本号（npm 的 @0.3.8、pip 的 @1.0.4、git 的 #v2.1.0）。允许模糊版本号会让"批准"失去意义——你批准的是 0.3.8，但有人拉了 0.4.0，新版本可能引入了未审计的行为。

Profile 分角色，不要做"万能大礼包"。 前端工程师不需要 PostgreSQL 查询工具，数据分析师不需要 GitHub 代码搜索。按角色或项目拆 Profile，既减少启动负担，也缩小了工具暴露面——这是安全上的最佳实践。

敏感配置走环境变量，不要写进 Profile 文件。 上面的例子中 GITHUB_TOKEN 和数据库密码都用 ${...} 占位。Profile YAML 很可能进 Git 仓库，硬编码密码等于公开泄露。

建立审核流程再开 Catalog。 Catalog 的核心承诺是"这里的 Server 是安全的"。如果没有真正的安全审核（代码审查、行为分析、权限检查），Catalog 就只是个链接列表，信任基础不存在。建议：每个 Server 入 Catalog 前至少经过一轮代码审查和运行行为记录。

Catalog 和 Profile 的版本要联动。 Catalog 升级（比如 PostgreSQL Server 从 1.0.4 升到 1.1.0）后，引用它的 Profile 应该有机制感知到变更。最简单的做法：Profile 里声明 catalog: team-platform-catalog@1.2.0，锁定 Catalog 版本；Catalog 升级后，Profile 显式更新引用版本，而不是自动跟随。

MCP 的企业采用难点从来不是协议本身，而是"怎么管"。Custom Catalogs 给了组织一个可控的分发通道，Profiles 给了开发者一个零摩擦的启动方式。两者配合，MCP 从"个人工具"变成"团队基础设施"的路径才算真正打通。

# AI # Docker # 云原生 # 后端

相关推荐