3.5 MCP 认证——连外部工具时怎么证明"我是我"

概念

前面讲了 Harness 要接入工具、Loop 要调用工具。但工具不是你想调就能调的——尤其是企业的内部系统，你说"我是 AI Agent，给我数据"，人家凭什么信你？

这就需要认证（Authentication）。MCP（Model Context Protocol）作为连接 AI 模型和外部工具的协议，定义了一套认证机制。核心问题就一个：怎么证明"我是我"，以及令牌怎么管。

用法

选型前先分清两件事：① 以谁的身份访问——以用户身份（代表某个员工操作）还是以服务身份（Agent 代表自己）；② 用什么流程拿凭据——授权码（需人点确认）、客户端凭证（无人值守）或预生成令牌（PAT）。协议版本（OAuth 2.0 / 2.1）是另一层选择，与凭据类型正交——2.1 对授权码强制 PKCE，不代表「有人在场才能用 2.1」。下表是「有没有人在场」这一最快判断的速查：

选型的第一判断标准是：有没有人在场。

三种方式的对比：

技术原理差异（为什么不是「新版就一定用新版」）

• PAT（Personal Access Token） ：最简单——你在目标系统的后台点一下生成一个长期令牌，把它作为 Authorization: Bearer 放进配置即可，没有浏览器、没有同意页、没有回调。代价是它 长期有效、静态 ：泄露了就等于门一直开着，只能靠手动撤销。所以它适合 没有人在场 的场景（CI 流水线、后端服务、定时脚本、机器对机器）。它 不是 MCP 规范定义的机制 ，而是服务器方为了方便无人值守场景，额外提供的一种简化 bearer 凭证。

• OAuth 2.1 ：MCP 规范明确要求的现代方案。它在 OAuth 2.0 基础上做了「安全收敛」，关键强化点：

• 强制 PKCE ：所有客户端（不只是无密钥的公共客户端）都必须用 PKCE，把授权码和发起请求绑定，防止授权码被截获后被他人兑换。

• 短命令牌 + 刷新轮换 ：访问令牌短期有效，降低泄露影响；刷新令牌轮换进一步收敛风险。

• 受众绑定（RFC 8707 Resource Indicators） ：令牌明确标注「只给某个 MCP 服务器用」，服务器必须校验令牌确实是签发给自己的，杜绝「令牌透传」滥用。

• 元数据发现与动态注册（RFC 8414 / 7591 / 9728） ：客户端能自动发现授权服务器、自动注册，无需人工把一堆参数抄来抄去。

• 代价是它 需要一个人走一遍浏览器授权流 ，所以适合 有人在场 的交互式接入。

• OAuth 2.0 ：OAuth 2.1 的前身，同样是「授权码 / 客户端凭证」这套流程，但 PKCE 是可选而非强制，且缺少 2.1 收敛掉的一些不安全用法（如隐式流）。在 MCP 语境下，它主要用于 兼容尚未升级到 2.1 的老授权服务器 的过渡场景；能用 2.1 就优先 2.1。

选型口诀

有人在场、能点浏览器授权   → OAuth 2.1（首选）

无人值守 / CI / 机器对机器  → PAT 或 OAuth 客户端凭证

只能对接老授权服务器        → OAuth 2.0（过渡，尽快升级）

选完认证方式，还要管好令牌的四件事：

中立的配置示意（把凭证放到环境变量，不写死在代码里）：

{

  "mcpServers": {

    "example-crm": {

      "command": "uvx",

      "args": ["example-crm-mcp-server"],

      "env": {

        "CRM_ACCESS_TOKEN": "从系统后台生成的 PAT，仅用于无人值守场景"

      }

    }

  }

}

示例

假设客户现场部署了一个 MCP Server，连接他们的内部知识库。你需要给 Agent 配置认证：

场景 A：Agent 在客服工作台上用，客服登录后使用

选 OAuth 2.1：客服登录工作台 → 工作台跳转授权页面 → 客服点"同意" → 拿到 access_token → Agent 用这个 token 调 MCP Server。

场景 B：Agent 每天凌晨 2 点自动跑知识库索引更新

没人在场，选 PAT：管理员预先生成一个 PAT → 存到密钥管理服务 → Agent 取出来用。

场景 C：客户的授权服务器还没升级到 OAuth 2.1，只能用 OAuth 2.0

只能对接老授权服务器，选 OAuth 2.0（过渡）：用 OAuth 2.0 流程拿令牌 → 用 token 调 MCP Server → 同时推动对方尽快升级到 2.1。

问题处理：客户现场 MCP 老是连不上怎么排查

这是交付时最常见的问题。按以下顺序排查：

在客户现场，MCP 老是连不上（红色状态），怎么排查？

按从外到内的顺序查，别一上来就怀疑配置文件：

**① 网络出口。**客户内网常见屏蔽公网 443 出站，导致 npx 拉包直接失败。表现是安装阶段就卡住，而非连接阶段。进场前先问清出网策略，必要时提前在本地准备好离线包。

**② 配置层级选错。**用户级配置在 ~/.workbuddy/mcp.json（全项目生效），项目级在 /.workbuddy/mcp.json（仅当前项目）。写在项目级却在别的项目里用，自然连不上。客户现场的通用系统建议放用户级。

**③ 凭据与权限。**Token 过期、权限范围不够、企业应用未授权给当前成员，都会表现为红色。

**练手建议：**官方推荐先用企业微信机器人跑通一次——配置最简单，成功后显示绿色状态，能帮你确认「问题在环境还是在配置」这个分界点。

这不只是技术问题。

MCP 连不上，很多时候是合规边界没谈清的技术表现。

**⚠️ 风险提示：**排查时最容易忽略的是"配置层级"这一层。客户环境的 MCP Server 地址可能跟开发环境不一样，如果用了配置中心，要确认配置中心推下来的值是最新的。另一个常见坑是：令牌没过期但 scope 不对——令牌能认证通过，但调用具体工具时返回 403。这不是认证问题，是授权问题。

3.6 本章小结

• Prompt 工程 = 把需求拆成角色/指令/约束/示例/输出格式五要素，写成模型能执行的规格，不是聊天

• 上下文管理 = 在有限窗口里"选而不是全塞"，系统 Prompt 必塞、历史对话摘要塞、RAG 按 Top-K 塞、全量知识库不塞

• Harness 五件套 = 工具接入 + 输入输出契约 + 错误处理 + 护栏门禁 + 可观测，缺一件都可能在客户现场崩

• Loop 退出条件 = 任务完成 / 最大步数 / 人工关卡 / 超时 / 错误次数，必须在设计阶段定好，不能靠模型自己判断

• MCP 认证选型 = 看有没有人在场：有人在用 OAuth 2.1，没人用 PAT 或 OAuth 客户端凭证，只能对接老授权服务器才用 OAuth 2.0（过渡）；令牌管好存、轮、撤、审计四件事

• MCP 连不上排查 = 网络出口 → 配置层级 → 凭据权限，口诀：先通不通，再对不对，最后认不认

一句话总结：FDE 和普通用户的差别，就是把一次成功变成一套系统——Prompt 是规格、上下文是预算、Harness 是车架、Loop 是刹车、MCP 认证是驾照，缺一个都上不了路。