2026 年 8 月 22 日，MCP 维护者发布新路线图，把 agent identity 列为五个优先级之一。路线图写道：
「如今 MCP 的授权体系以人在浏览器里点击审批为核心。这对交互式客户端运作良好，但越来越多的调用方是作为云端工作负载运行的智能体：它们自带身份，代表不在线的用户行动，或者把更窄的权限委托给子智能体。我们希望 MCP 服务端能拥有一种标准化的方式来识别并信任这些智能体身份，这种方式基于既有标准构建，而不是依赖粘贴的 API key 和长命 token。」
这段话点出了调用者的转变：从屏幕前的人，变成云端自带身份的进程。最初的 MCP 凭简单发家，零门槛写脚本就能跑；如今引入了企业身份层复杂度。智能体需要无人值守，授权审批却卡在浏览器，促成这次转向。纵观时间线，MCP 授权机制一直从人工审批向机器身份迁移，2026-08-22 路线图把这条演进主线确立为官方方向。
回答这个问题有两个角度。第一个角度是生产力杠杆。人管 AI 像带团队。打个比方，投入 5% 精力拿到 100% 产出，就是 20 倍杠杆。要维持足够大的杠杆，AI 必须有足够能动性独立工作，中间不能步步停下来等人，自主获取授权特别重要。Addy Osmani 在《Long-running Agents》中指出，生产 agent 跑起来后人不在屏幕前，编码、扫描或监控能跑数小时到数周，有些挂在事件流或数据表上处理审核、异常或分流。Teradata 对自主 agent 的界定也是自行选工具、排动作、恢复错误并推进任务，无需人在环。聊天窗口循环撑不起无人值守运转。
换个角度看，很多场景本不需要人介入。比如在线客服这类 agent，面对用户请求，背后没人坐在屏幕前等审批。MCP 协议里有专门的机制把人带回来：工具执行到一半，可以暂停下来请人做决定，我们之前专门分析过这套把人带回来的设计。可这类场景要的是全自动闭环，把审批卡在浏览器，等于给后台 agent 配一名全程在线的监督员，直接抵消代理价值。
无论放大生产力杠杆还是场景本不需要人，云端 agent 都必须自己拿到授权。早期阻碍在于：Anthropic 于 2024-11 发布 MCP 时仅支持 stdio 传输与单进程通信，无会话与授权框架，预设屏幕前坐着开发者点审批。工具调用类似本地函数，零门槛让 MCP 迅速流行，却无法支撑无人值守的云端进程。
为移走阻碍，协议分四环补齐授权能力：第一环支持远程调用，2025-03-26 变更清单引入基于 OAuth 2.1 的授权框架 PR #133，以 Streamable HTTP 取代 HTTP+SSE 支持远程部署 PR #206；第二环是机器自主凭证，2025-11-25 一周年发布帖引入扩展 SEP-1046 与 SEP-990，支持机器对机器凭据与企业策略控制，机器首次出示凭据自主获取 token；第三环是平台背书身份，2025-12-05 工作负载身份联合提案 WIF 开启即 PR 1933（SEP-1933），由平台签发短命且可密码学校验的 JWT；第四环是窄权限委托，2026-05-21 IETF OAuth 工作组草案 draft-ietf-oauth-identity-assertion-authz-grant 更新至第四版，凭据委托开始有了草案级的标准形状。2026-08-22 路线图正式把这条线确立为官方方向。
每推进一步，都在引入当初刻意回避的复杂度。最初写脚本起个 server 就能调，没有授权与会话，简单正是它发家的原因。如今为让云端 agent 自主调用，协议正在一步步把企业身份层的复杂机制叠加进来。
新路线图的目标在于：协议需要一种标准方式识别并信任 agent 身份，摆脱对粘贴 API key 和长命 token 的依赖。长命 token 像一把用很久的钥匙，丢了影响面大；短命凭证有效期短、到期自动换新、丢了很快作废。零信任默认谁都不信，每次访问都要出示可验证的身份证明，不因为身处内网就直接放行。所谓 workload identity，就是平台给每个跑在机器上的程序发一张短期、自动换新的电子身份证，程序用它证明自己是谁。Kubernetes 与 SPIFFE 与 SPIRE 这类平台本来就在做这件事。Red Hat 关于 AI agent 零信任的分析指出，agent 零信任与人的零信任不同：难点在于用户的身份要从浏览器一路传到 agent、再传到 agent 调用的下游服务，中间不能断。按照权限交集原则，agent 只能收窄用户权限，不能扩大权限。
第一个问题：一个跑在云平台上的程序，怎么向 MCP 服务端证明自己是谁？平台本来就会给它发一张短期电子身份证 JWT，WIF 机制就是让 MCP 服务端直接校验这张卡，程序不用单独注册一个 OAuth 客户端。该机制对应 WIF 提案 PR 1933 即 SEP-1933，由 IETF WIMSE 工作组联合主席 Pieter Kasselman 于 2025-12-05 开启，截至 2026-08-25 处于 Draft 状态。作者在 2025-12-17 回应自研质疑时表示这里没有任何自研成分，完全是 RFC 7523 加上 OpenID Connect Discovery；维护者规划的推进路径包括合规测试、TypeScript SDK 实现 PR #2572 与扩展评审。
第二个问题：用户已经登录了公司账号，一个应用想替用户去用 MCP 工具，怎么办？应用拿着用户的单点登录身份，向企业 IdP 申领一枚专用 token，直接去 MCP 服务端换取访问权限，全程不需要弹出浏览器窗口让用户点击同意。该机制对应 IETF 草案 draft-ietf-oauth-identity-assertion-authz-grant，2026-05-21 更新至 v4，简称 ID-JAG。MCP 对应的 Enterprise-Managed Authorization 扩展维护者自述已 stable，文档明确要求不要将用户重定向到授权端点；草案也规定同一枚 ID-JAG 禁止在下游跳复用。企业 IdP 在签发前评估策略，权限撤销在 IdP 侧一次生效。
第三个问题：token 遭到窃取怎么办？DPoP 机制把 token 和调用方持有的私钥绑在一起，即使拿到 token，没有私钥也无法使用，服务端同时能识别重放攻击。该机制在 2023 年定稿为标准 RFC 9449，MCP 侧落地提案 SEP-1932 截至 2026-07-02 处于合规测试阶段。
这些机制建立在 2026-07-28 规范底座上：协议删除了握手与会话头 SEP-2575
与 SEP-2567，引入自包含
_meta，完成了无状态底座与基础授权加固，详见变更清单。底座已经发布，上层进程身份体系仍在施工。
这次转向不是免费的，MCP 付了两笔代价。
第一笔代价，是协议变厚了，存量实现都得改。以前协议依靠会话维系状态，服务端记得客户端是谁、之前调用过什么；去状态之后，服务端不再保留会话记忆，每个请求都必须自包含，把协议版本、客户端身份、能力范围以及要调用的工具名称一次性带齐。请求里的字段和校验规则随之变多，原有接入
MCP 的项目需要按新规则适配。技术细节上，协议删除了握手与会话头 SEP-2575
与 SEP-2567，在请求中强制增加 Mcp-Method 与
Mcp-Name 头 SEP-2243，列表返回增加 ttlMs 与
cacheScope 字段 SEP-2549，响应体引入
resultType，同时弃用动态客户端注册 DCR 转向 CIMD 即 PR
#2858，并淘汰 HTTP+SSE 传输 SEP-2596。MCP
不再是调完工具就走的轻量协议。
第二笔代价更直接：MCP 砍掉了两项刚加的能力。第一项是 Sampling，它让服务端借用客户端的模型干活：服务端发起采样请求，客户端的模型生成回复、调用服务端提供的工具，服务端一轮轮驱动这个循环；该能力于 2025-11 加入规范 SEP-1577，8 个月后的 2026-07-28 规范将其列入弃用清单 SEP-2577 并留出至少 12 个月过渡窗口。第二项是 Roots，它允许客户端把本地的文件和目录共享给服务端，服务于一个人坐在电脑前的单机交互；Roots 同样在本次修订中弃用。砍掉它们，等于表明 MCP 的重心不再覆盖写脚本的个人开发者场景。
砍掉这两项能力，确立了协议的边界，我们之前写过 MCP 2026 在协议层划定边界这条主线：MCP 专注于工具层与身份层，拒绝接管 agent 运行时，把推理循环留给客户端框架。MCP 靠写个脚本、起个 server 就能调的零门槛发家；如今为了让云端 agent 自主运转，每加一层企业身份机制，都在叠加当初刻意回避的复杂度。与此同时，OpenAI 走向了相反的方向，我们之前对比过这两条路线：OpenAI 的 Responses API 把推理状态、会话历史与托管工具都收进自己的服务端，把 agent 的核心循环直接托管在厂商云上。MCP 押注中立的工具与身份底座，自身不做运行时；OpenAI 押注连同运行时一起做。这是两套不同的技术路线在不同层次押注。
你贴在自己项目 .env 里的那把 API key，签发方随时能吊销它、限制它的额度、查看它的调用记录。签发方之所以有这个权力，是因为所有请求都带着这把钥匙经过对方的系统。这个所有请求都必须经过的点就是关口，我们之前专门分析过关口这个概念。
这次转向把关口挪到了签发 token 的一方手里。发身份证的机构，现在同时管着谁能用、怎么收回，每一次委托也落在它手里。在 ID-JAG 流程里，应用发起的请求必须先经过企业 IdP 评估策略，通过后才能换取访问权限。在 WIF 流程里，MCP 服务端信任的是云平台签发的身份，直接校验平台给出的短命 JWT。公有云平台与企业 IdP 这两类实体，正是早期写脚本的个人开发者从来不用打交道的对象。在谁能审批、谁能撤销、谁看得到委托这件事上，签发方确实占住了关口，这个判断完全成立。
这轮演进跟你有什么关系，取决于你在链路里的位置。如果你写 MCP server，server 一旦离开本机、部署到远程，就得接上已发布的 OAuth 2.1 授权框架与 issuer 校验，这部分现在就能做。客户是企业、要求走自己的 SSO 时，可以接维护者自述已 stable 的 Enterprise-Managed Authorization 扩展。WIF 还在 Draft，别提前写校验代码。
如果你写 agent 应用、让 agent 去调 MCP 工具，agent 要无人值守跑，浏览器审批这条路就不通了。现在能用的是 2025-11-25 版引入的机器对机器凭据，让 agent 自己出示凭据换 token；ID-JAG 还是 IETF 草案，等它离开草案再接。
如果你只是用现成的 agent 产品调工具，不用改任何东西，client 会处理。要留意的是，这套体系正在淘汰往 .env 里贴一把长命 API key 的习惯，新写的脚本别再这么干。判断这条路走没走通有一个明确标准：如果未来两到三个规范周期内 WIF 与 DPoP 依然停在草案阶段，主流服务端依然在透传用户凭证而非 workload 身份，默认调用者换成云端进程的判断即告失效。
这种转向在社区引发了讨论。HN 上关于新路线图的讨论拿到 269 分，过度设计批评占了较多篇幅，一条高赞评论写道：「在初版发布阶段搞一套定制的新协议，是 MCP 做过更愚蠢的事情之一」。REST 搭配 skills.md 阵营态度直接，AWS Builder Center 发文打出标题：Agent skills and CLI tools: ditch the MCP overhead。Cloudflare 的 code mode 为模型提供代码执行工具，宣称「用 1000 个 token 给智能体提供完整 API」，在文档中标注为 experimental。MCP 押注做中立的工具与身份底座，服务无人值守的生产 agent，自身不做运行时。这个赌注是否成立，是一个开放问题。