摘要：MCP正在从工具调用协议走向更完整的智能体基础设施。随着Agent开始代表用户长期执行任务，身份、权限委托、长任务、事件机制和工具发现逐渐成为企业落地必须解决的问题。
如果只看过去一年 MCP 的流行方式，很容易把它理解成一套“让大模型调用外部工具”的协议。
给 Claude、Codex 或其他智能体接一个数据库，做个 MCP Server；要读 GitHub，再接一个；要操作文件系统、浏览器、知识库、内部 API，就继续往上挂。很多开发者第一次接触 MCP，也正是从 tools/list 和 tools/call 开始的。
这套机制解决了一个很具体的问题：不同模型、客户端和工具之间，不必各自再写一套专用适配层。模型侧知道工具的名称、参数和返回结构，就可以在统一协议下工作。
但工具调用做起来以后，一个更难的问题很快冒出来了。
当发起调用的主体不再是坐在屏幕前的人，而是一个在云端运行数小时、甚至跨天执行任务的 Agent，服务器到底该把它当成谁？它拿到的权限来自哪个用户？主 Agent 把任务分给子 Agent 后，子 Agent 应该继承多少权限？任务结束以后，这份权限又该怎么撤销？
8 月 22 日，MCP 官方发布新版路线图。五个优先方向中，企业开发者尤其值得关注三组词：Agentic Messaging、HTTP-native Transport、Agent Identity。Tool Calling 已经相对成熟，新的难点集中到了长期任务、传输和身份体系。
MCP 开始处理那些只有进入生产环境以后才会遇到的问题。
从“人点一下同意”到“机器代表人办事”
今天互联网最成熟的授权体验，仍然围绕人来设计。
一个应用需要访问 Google Drive，浏览器跳出 OAuth 页面；用户看见授权范围，点击允许；应用拿到 Token，在一定范围内访问数据。整个流程默认用户就在现场，而且能够判断“这个应用现在是不是应该得到权限”。
Agent 的工作方式把这个假设打破了。
假设你给一个 Coding Agent 下达任务：
“把这个项目升级到新版框架，修复兼容问题，跑完测试，部署到测试环境。如果失败，先看日志自己处理。”
接下来的两三个小时里，它可能会访问代码仓库、CI、制品库、云服务器、数据库、监控平台，还可能再创建一个专门检查测试失败的子 Agent。用户并不会守在屏幕前逐个批准这些动作。
权限关系随之变成了一条链：
用户 → 主 Agent → 子 Agent → MCP Server → 企业系统。
这条链条里，单靠 API Key 很难把事情讲清楚。
服务器需要知道的不只是“这个 Key 有没有权限”，还包括：当前请求是哪一个 Agent 发起的；它是在代表谁办事；上游给它委托了什么范围；这份委托能不能继续往下传；调用发生时是否仍在有效期内。
MCP 路线图把这一块命名为 Agent Identity and Enterprise-ready Security。官方明确提出，希望服务器能够识别和信任 Agent 自身的身份，并尽量建立在既有身份标准上，减少长期 API Key 和静态 Token 的使用。
路线图里提到 DPoP、Workload Identity Federation、ID-JAG 和标准 Token Exchange。这几个名词看起来偏安全工程，背后的目标却很直观：给 Agent 建立可验证、可委托、可收回的身份和授权关系。
7月28日那次升级，已经给路线图铺好了路
8 月这份路线图有很清楚的技术铺垫。
7 月 28 日发布的新 MCP 规范已经做了一次很大的结构调整：协议核心从双向、有状态通信转向无状态的 request/response 模型。
旧版本里，客户端和服务器之间有 initialize/initialized 握手，还有 Mcp-Session-Id。这对早期交互式 MCP 很自然，可一旦服务器要在云上横向扩展，Session 就会带来额外负担。请求被负载均衡到不同实例时，后端需要共享 Session 状态，或者做粘性会话，运维复杂度马上上来。
新规范直接把这一层拿掉了。
每个请求带着自己的协议版本、客户端身份和能力信息，普通 round-robin 负载均衡就能把请求送到任意 MCP Server 实例。服务器如果确实需要跨请求状态，也可以显式返回一个 handle，让模型后续调用时把 handle 再传回来。
Agent长时间跑任务以后，request/response也不够用了
无状态 HTTP 解决了扩展问题，却没有解决长任务本身。
一个普通 API 调用可能几百毫秒完成，Agent 做一次代码重构、数据分析、仿真计算或跨系统流程，持续几十分钟并不稀奇。服务器可能中途需要用户补参数，也可能需要推送阶段结果；用户又可能在任务进行到一半时突然说：“别改数据库，只分析日志。”
因此新版路线图把 Agentic Messaging Primitives 单独列为一项。
MCP 已经引入 Tasks、subscriptions/listen 和 progress notifications。7 月规范中的 Multi Round-Trip Requests（MRTR）也值得注意：当工具执行到一半需要用户确认或补充参数时，服务器可以返回 input_required，客户端收集输入后再继续原调用，而不需要一直保持一条双向长连接。
下一阶段 MCP 还准备把 Webhook、Channel、Trigger、Event 等机制进一步组合起来。等这一块成熟以后，MCP 所承载的工作就不只是“问一句、调一个工具、回一个结果”，而会覆盖持续任务、事件驱动和中途干预。
一百个工具已经开始拖累模型，企业里可能是一千个
工具数量是另一个很现实的问题。
小型 MCP Server 挂 5 个、10 个工具，模型很容易选。企业场景很快就会越过这个规模。
一个制造企业如果认真做智能体接入，MES、ERP、PLM、WMS、QMS、设备平台、时序数据库、CAD、CAE、能耗系统、知识库都会贡献大量接口。每套系统几十个工具，加起来几百个并不夸张。
问题在于，工具表本身也要进入模型上下文。
工具越多，Prompt 越长；描述相近的工具越多，模型越容易选错。官方路线图直接指出，连接一个拥有上百个工具的服务器时，用户还没问第一个问题，模型就已经为整套 Tool Surface 支付了一遍上下文成本。
MCP 准备推动 Progressive Discovery，也就是渐进式发现。
服务器一开始只暴露很小的入口。当用户的问题收敛到某个领域，再把相关工具展开。
比如用户说：“分析 3 号产线最近一周的良率下降。”
第一层只需要识别“生产分析”这个能力；第二层再发现 MES、质量系统和设备时序数据；确定 3 号产线之后，再加载对应工序、设备和检测项的工具。模型不用从一开始就阅读采购、财务、人事和售后系统的几百个接口。
这种做法很像人进大型组织办事：先找到部门，再找到岗位，最后找到具体流程。把所有制度和所有人的电话号码一次性塞进脑子里，并不会提高办事效率。
MCP接下来的竞争点已经变了
MCP 早期的传播带有很强的插件市场色彩：一个产品宣布支持 MCP，紧接着就是“我们有几十个 Server”“几百个工具”。
到了现在，数量越来越难说明系统成熟度。
企业真正会问的，是另外一组问题：
Agent 有没有独立身份？权限是谁授予的？子 Agent 能不能越权？权限到期以后会不会自动失效？敏感操作能否要求人工批准？任务跑几个小时后能否恢复？调用链能不能审计？一千个工具怎么发现？工具返回的数据会不会污染其他用户的上下文？
这些问题听起来没有“模型又涨了多少分”那么热闹，却直接决定 Agent 能不能进入生产系统。
从 7 月的无状态核心，到 8 月的 Agent Identity、HTTP-native Transport、Tasks、Events 和 Progressive Discovery，MCP 正在把自己往一个更基础的位置推。
它最后能不能成为 Agent 时代的通用连接协议，还要看生态实现的一致性，也要看 REST、CLI、Skills 等更简单方案会不会在一些场景里胜出。社区里对 MCP 复杂度的质疑一直存在，而且并非没有道理。
不过路线已经看得很清楚：MCP 的竞争重点正在离开“模型会不会调工具”，转向“一个拥有身份、权限和长期任务的 Agent，怎样安全地进入现有 IT 世界”。
如果企业智能体下一步真要深入生产系统，这一层迟早要有人补上。
参考资料
- Model Context Protocol Blog：The New MCP Roadmap，2026-08-22
- Model Context Protocol Blog：The 2026-07-28 Specification，2026-07-28
- Horizon Daily：2026-08-23 技术资讯汇总