MCP 真正难的已经不是“怎么接”，而是怎么收权限、控风险、做治理

我一开始以为 MCP 最大的问题是协议本身，后来发现不是。协议反而是这件事里最容易的一部分。真正麻烦的，是当你的工具越来越多、模型越来越会主动调用工具之后，谁来决定它能调用什么、在什么上下文里调用、出了问题怎么追。

这也是我现在看 MCP 的核心判断：它当然值得关注，但对开发者来说，真正要投入时间的不是“再接几个 server”，而是尽快把权限边界、注册治理、审计链路和默认拒绝策略补起来。否则 MCP 很容易从“统一工具接口”变成“统一扩大攻击面”。

为什么这个话题现在值得写

过去一年，MCP 从一个新协议，开始变成越来越多 AI 工具默认支持的连接层。Anthropic 在 2024 年底公开发布 MCP，定位就是让模型和外部系统建立标准化双向连接。随后 GitHub 把官方 MCP Server 做成了公开项目，后面又继续补 Projects 工具、HTTP server mode、OAuth scope filtering，以及 Registry、allowlist、Lockdown 这类明显偏治理的能力。

这说明一件事：生态已经默认 MCP 会继续扩散，问题不再是“它会不会流行”，而是“流行之后你怎么管”。连平台方的产品更新都在从“增加工具”转向“限制工具、筛选工具、治理工具”。这不是锦上添花，而是进入生产环境后的必修课。

我为什么不建议把重点放在“多接几个工具”

很多团队第一次用 MCP，动作都差不多：先把 GitHub、Filesystem、数据库、浏览器自动化、搜索全接上，然后让模型“自己决定”。这个阶段 demo 很容易惊艳，但只要进真实仓库，问题马上会出来：

工具描述太宽，模型会误选工具；
权限是“通给模型”的，不是“按任务临时给”的；
不同 server 组合后会出现跨边界副作用；
日志能看到调用发生了，但很难还原“为什么会这么调”；
你以为自己在做上下文增强，实际上在做能力外放。

这不是危言耸听。只要你把一个能读文件的 MCP server、一个能操作 Git 的 server、再加一个会接收不可信输入的上下文入口放在一起，风险模型就不再是单工具风险，而是组合风险。很多团队目前低估的，恰恰是这个组合效应。

真正有价值的不是“接得更多”，而是把工具面收窄

我现在更认可的做法不是给模型一个“大工具箱”，而是给它一个“任务态工具集”。也就是说，同样是 GitHub MCP Server，不同任务暴露出来的工具应该不同。比如：

# PR review 任务：只读优先
TOOLS=read_issue,read_pr,read_file,search_code

# triage 任务：允许写 issue，但不允许改仓库文件
TOOLS=read_issue,create_issue,add_comment,label_issue

# release 任务：允许读 tag / workflow，但不允许直接 push 默认分支
TOOLS=list_tags,read_release,dispatch_workflow

这看起来比“一把梭全开”麻烦很多，但工程上更稳。因为你终于可以把权限跟任务绑定，而不是跟模型绑定。模型本身并不可靠，任务边界才是你真正能控制的东西。

一个更像生产系统的 MCP 配置方式

如果你只是个人开发者，完全没必要一上来做一套复杂平台。但最少也应该把配置切成三层：

基础层：server 定义、认证方式、调用超时、重试策略；
策略层：哪些任务可以使用哪些工具，哪些资源路径可以访问；
审计层：任务 ID、用户 ID、模型 ID、工具调用轨迹、审批点。

伪配置大概会像这样：

servers:
  github:
    mode: http
    auth: oauth
    timeout_ms: 15000
  filesystem:
    mode: stdio
    allow_paths:
      - /workspace/project
      - /workspace/docs

policies:
  pr_review:
    allow:
      - github.read_pull_request
      - github.get_file_contents
    deny:
      - github.merge_pull_request
      - filesystem.write

  local_refactor:
    allow:
      - filesystem.read
      - filesystem.write
    require_approval:
      - shell.exec

audit:
  trace: true
  persist_tool_calls: true
  redact_secrets: true

这个配置没什么“黑科技”，但它代表了一种方向：MCP 不应该只停留在连接器层，而应该变成你 AI 工作流里的受控基础设施。

被夸大的地方也很明显

现在有一种很常见的叙事：有了 MCP，模型就能像人一样使用软件。这个说法我一直不太买账。MCP 解决的是工具接入一致性，不解决任务理解、状态恢复、审批设计、失败补偿，也不替你解决权限最小化。

换句话说，MCP 更像 USB-C，不是“自动驾驶大脑”。接口统一了，确实能加快生态扩张，但统一接口不等于统一可控性。越是统一，越需要把治理补上。

个人开发者和小团队该怎么投入

如果我是个人开发者，我不会先去追“最多支持多少个 MCP server”。我会优先验证三件事：

能不能把常用任务拆成 2 到 3 组固定工具集；
能不能做到默认拒绝，只对单任务放开必要能力；
失败后能不能从日志里复盘出模型的调用路径。

如果你是小团队，我会再加一条：尽快把“谁能安装什么 MCP server”从个人偏好变成团队规则。GitHub 这类平台开始做 registry 和 allowlist，不是因为它们保守，而是因为只靠本地配置文件已经不够了。

我的判断

MCP 值得重度关注，但关注点应该从“协议红不红”切换到“能不能治理”。现在还只把 MCP 当接线板的团队，后面大概率要补一轮权限、审计和策略债。

它不是没用，恰恰相反，正因为它开始变得有用，治理才变成了主问题。接下来真正有长期价值的机会，不一定是再做一个 MCP server，而是把 registry、审批、审计、策略编排、风险扫描这些“脏活累活”做成可复用基础设施。