1. 先看一个最关键的变化：MCP 正在摆脱“一问一答”#

最早期的工具协议有一个非常自然的假设：

1
LLM
2
 ↓
3
call tool
4
 ↓
5
server executes
6
 ↓
7
return result
8
 ↓
9
LLM continues

这对很多任务完全够用。

例如：

• 查天气；
• 查数据库一条记录；
• 读取一个 GitHub Issue；
• 列出某个目录；
• 获取一段日志。

这些工作通常可以在几百毫秒到几秒内结束。

问题出现在真正的 Agent Workflow。

例如 Coding Agent 可能需要：

1
读取仓库
2
  ↓
3
建立索引
4
  ↓
5
搜索调用链
6
  ↓
7
修改代码
8
  ↓
9
安装依赖
10
  ↓
11
跑单测
12
  ↓
13
跑 E2E
14
  ↓
15
发现失败
16
  ↓
17
修复
18
  ↓
19
再次验证
20
  ↓
21
生成 PR

这个过程不是一次 RPC。

它是一个长生命周期工作单元。

官方新 Roadmap 对这一点说得很直接：现代 agentic workload 已经不再适合普通 request-response 模式。任务可能持续很久，服务端可能需要流式返回结果，用户也可能需要中途 steering。

所以 MCP 接下来重点完善：

• Tasks；
• subscriptions/listen；
• progress notifications；
• server-initiated events；
• webhooks / channels；
• 长任务中的中途 steering。

这其实是在把一个工具调用协议，向“可管理任务生命周期”的方向推进。

2. 为什么 polling 对 Agent 来说是一个坏抽象？#

假设你让 Agent 发起一个耗时 15 分钟的 GPU benchmark。

最简单的协议可能是：

1
POST /run-benchmark
2
→ task_id=abc123

然后客户端不断：

1
GET /task/abc123
2
GET /task/abc123
3
GET /task/abc123
4
GET /task/abc123
5
...

这种方式当然可以工作。

但一旦 Agent 数量、并发任务和执行时间上来，问题很快就出现。

1
100 × 10 × 0.5
2
= 500 requests / second

1
pending
2
running
3
finished
4
failed

1
waiting_for_user
2
waiting_for_approval
3
blocked_by_policy
4
partial_result_available
5
retrying
6
rate_limited
7
budget_exceeded

3. Tasks 真正重要的不是“异步”，而是生命周期语义#

很多人看到 MCP Tasks，第一反应可能是：

不就是 async job 吗？

但如果只理解成 async job，会低估它的价值。

真正重要的是：Task 让协议开始承认 Agent 工作有生命周期。

例如一个成熟的任务协议至少应该逐渐回答：

1
谁创建了任务？
2
任务属于哪个用户？
3
任务当前状态是什么？
4
任务能否取消？
5
任务能否重试？
6
失败能否恢复？
7
结果保留多久？
8
客户端断线后能否重新连接？
9
任务完成后如何通知？
10
是否可以中途修改目标？
11
是否可以审批后继续？

这已经非常接近：

• Workflow Engine；
• Job Queue；
• Durable Execution；
• Agent Runtime；
• CI Pipeline。

这也是为什么 Tasks 不能只被看成一个 API 便利功能。

4. 一个很容易忽略的事实：2026-07-28 已经先把“无状态化”铺好了#

新的 Roadmap 不是从零开始。

在 2026-07-28 MCP Specification 中，已经发生了两个对生产部署非常关键的变化：

• protocol-level sessions 被移除；
• initialization handshake 被移除。

官方解释很明确：这让 MCP Server 可以更容易横向扩展，而不必要求某个实例长期保存协议会话状态。

以前你可能需要：

1
Client
2
   ↓
3
Load Balancer
4
   ↓
5
Server A ← session pinned here

如果 Server A 挂了，session state 可能就需要恢复。

无状态以后，更接近：

1
             ┌→ Server A
2
Client → LB ─┼→ Server B
3
             └→ Server C

任何请求都可以被调度到任意实例。

这对：

• Kubernetes；
• Cloudflare Workers；
• Serverless；
• Edge Runtime；
• 多区域部署；
• Auto Scaling；

都更友好。

也就是说，Roadmap 里“Agentic Messaging”与“HTTP-native Transport”其实是相互配合的：

协议本身尽量无状态，但长任务状态由明确的 Task / Event primitive 管理。

这是一个非常成熟的分层。

5. MCP 为什么越来越 HTTP-native？#

新 Roadmap 的第二个方向是：

HTTP-native transport unification and hardening

这看起来有点抽象。

但它背后的工程目标非常明确。

今天远程 MCP Server 已经越来越像普通 Web Service：

1
DNS
2
TLS
3
HTTP
4
OAuth
5
Load Balancer
6
Gateway
7
WAF
8
Observability
9
Rate Limit
10
Identity

而不是某种特殊的“AI 网络协议”。

这是好事。

因为企业已经有几十年的 HTTP 基础设施。

如果 MCP 自己重新发明：

• session；
• transport；
• service discovery；
• auth；
• retry；
• proxy；

那它最终会变成一个很难进入企业网络的新孤岛。

相反，如果 MCP 尽量复用成熟 HTTP 语义，那么现有基础设施就可以直接工作：

1
Agent
2
  ↓
3
Enterprise Gateway
4
  ↓
5
OAuth / WIF
6
  ↓
7
Rate Limit
8
  ↓
9
Audit
10
  ↓
11
MCP Server

这也是为什么“HTTP-native”实际上是 MCP 生产化非常重要的一步。

6. 更有意思的是：官方甚至希望 local MCP 也向同一模型靠近#

Roadmap 提到一个值得注意的方向：

包括 local servers speaking Streamable HTTP over stdio

这意味着本地 MCP 与远程 MCP 的开发模型可能进一步统一。

今天开发者经常维护两套逻辑：

1
Local
2
stdio
3
process lifecycle
4
local permissions

和：

1
Remote
2
HTTP
3
OAuth
4
network retries
5
load balancing

如果最终 transport semantics 能高度统一，那么开发者可能只需要维护：

1
MCP application semantics
2
        ↓
3
Streamable HTTP semantics
4
        ↓
5
local adapter / remote adapter

这会显著降低 SDK、测试与 client implementation 的复杂度。

我的判断是：

未来“stdio MCP”和“remote MCP”会越来越像部署方式差异，而不是两套协议世界。

这是工程判断，不是官方已经承诺完成的事实。

7. Roadmap 第三个方向，可能才是 Agent 真正进入企业的门槛：Agent Identity#

现在很多 MCP Authorization Flow 的隐含前提是：

1
User
2
 ↓
3
Browser OAuth Consent
4
 ↓
5
Agent gets delegated token

对桌面 Agent 很合理。

例如：

• Claude Desktop；
• Cursor；
• VS Code；
• 本地 Codex；

用户就在电脑前。

但生产 Agent 完全不同。

它可能运行在：

• GitHub Actions；
• Kubernetes；
• Cloudflare Workers；
• Vercel Sandbox；
• AWS Lambda；
• 内部 Agent Platform；
• 长时间无人值守的 VPS。

这时候没有人会一直等着点：

1
Authorize

更麻烦的是，Agent 可能还会继续创建 Subagent。

例如：

1
Human
2
  ↓
3
Main Coding Agent
4
  ├─ Explorer Agent
5
  ├─ Test Agent
6
  └─ Deployment Agent

这时候权限应该是什么？

绝对不应该是：

1
main token
2
  ↓ copy
3
subagent token
4
  ↓ copy
5
another subagent

因为这样权限只会复制，不会缩小。

8. Roadmap 里的关键词：DPoP、WIF、Token Exchange、ID-JAG#

官方在 Agent Identity 方向明确提到：

• DPoP；
• Workload Identity Federation；
• ID-JAG；
• Enterprise-Managed Authorization；
• standard token exchange。

这些东西共同指向一个核心目标：

Agent 应该拥有“可验证的工作负载身份”，而不是到处复制长期 API Key。

我们可以把旧模型画成：

1
API_KEY=super-secret-long-lived-key
2
              ↓
3
Agent A
4
Agent B
5
CI
6
VPS
7
Docker

任何一个环境泄露，Key 都可能被长期滥用。

而未来更理想的是：

1
Workload Identity
2
      ↓
3
Identity Provider
4
      ↓
5
short-lived token
6
      ↓
7
MCP Server

如果继续委托给 Subagent：

1
Main Agent
2
scope = repo:read + repo:write + deploy:staging
3

4
       ↓ token exchange
5

6
Explorer Agent
7
scope = repo:read

这才是真正符合 Agent delegation 的权限模型。

9. 为什么 DPoP 对 Agent 特别重要？#

传统 Bearer Token 有一个简单但危险的属性：

谁拿到 Token，谁就能用。

如果日志、Prompt、环境变量、Crash Dump 或恶意 Tool 泄露了 Token，攻击者往往可以直接重放。

DPoP 的目标之一，是把 Token 与持有者的密钥证明绑定。

简单理解：

1
Bearer token:
2
I have token → therefore I am allowed

DPoP：

1
I have token
2
+
3
I can prove possession of bound private key
4
→ therefore I am allowed

对于会自动执行大量 Tool Call 的 Agent，这个差异非常重要。

因为 Agent Runtime 本身就是一个高频接触凭据的系统。

10. Agent Identity 不是“OAuth 再复杂一点”#

我认为这里最容易出现一个误区：

MCP 已经支持 OAuth，所以 Agent 身份问题解决了。

不对。

Human Delegation 与 Workload Identity 是两种不同问题。

1
王奕章授权 Coding Agent
2
读取 GitHub 仓库

1
GitHub Actions 中的 Agent
2
以 workflow workload 的身份
3
访问某个 MCP Server

1
Main Agent
2
授权 Test Agent
3
只能读取测试结果
4
不能修改生产环境

11. 第四个方向非常现实：工具太多了，模型真的会被拖垮#

Roadmap 在 Improved Primitives 中点出了一个非常典型的问题：

一个 MCP Server 如果有 100 个工具，模型在用户提出第一个问题之前，就可能已经为整个工具表面支付 Context 成本。

这和我之前观察 Coding Agent Harness 时遇到的问题完全一致。

很多人以为：

1
more tools = more capable agent

实际上在超过某个规模以后，很可能变成：

1
more tools
2
→ larger system context
3
→ more similar tool descriptions
4
→ harder tool selection
5
→ more wrong calls
6
→ higher latency
7
→ higher token cost

这可以称为：

Tool Surface Area Problem

12. 一个 200 Tool MCP Server 的隐藏成本#

假设平均一个 Tool Schema，包括：

• name；
• description；
• JSON schema；
• 参数说明；

占 250 tokens。

200 个工具就是：

1
200 × 250
2
= 50,000 tokens

还没问问题，Context 就已经消耗 5 万 token。

如果某个 Agent 一天创建 1000 个 session：

1
50,000 × 1,000
2
= 50,000,000 input tokens

即使 KV cache、prefix cache、prompt cache 能降低部分推理成本，也无法完全消除：

• tool selection complexity；
• retrieval noise；
• schema ambiguity；
• model attention competition。

所以新 Roadmap 提出的 progressive discovery 非常值得关注。

13. Progressive Discovery：不要先把整个工具箱砸给模型#

更合理的方式应该像搜索。

例如：

1
User:
2
帮我检查 Cloudflare Pages 部署为什么失败

第一阶段模型只看到：

1
search_tools(query)
2
get_tool_group(name)

然后：

1
search_tools("Cloudflare Pages deployment logs")

返回：

1
pages.get_deployment
2
pages.get_logs
3
pages.retry_deployment

这时候模型才加载这三个工具的完整 schema。

于是上下文从：

1
200 tools
2
50k tokens

变成：

1
2 discovery tools
2
+
3
3 relevant tools

这种架构和：

• RAG；
• command palette；
• package lazy loading；
• capability registry；

非常像。

14. Progressive Tool Discovery 会改变 MCP Server 的设计方式#

以前 MCP Server 很容易做成：

1
one server
2
  ├─ 150 tools
3
  ├─ 200 resources
4
  └─ 30 prompts

以后可能更合理的是：

1
entry capability
2
      ↓
3
capability discovery
4
      ↓
5
load relevant namespace
6
      ↓
7
expose narrowed tool set

这里甚至会出现新的优化指标：

1
Tool Discovery Precision
2
Tool Discovery Recall
3
Tool Schema Tokens per Task
4
Wrong Tool Invocation Rate
5
Time to First Correct Tool

这些指标比单纯统计“有多少 MCP tools”更有意义。

15. 一个很有意思的行业呼应：Harness 已经在主动缩 Tool Surface#

这次 Roadmap 的 progressive discovery 并不是纯理论问题。

Harness 今年重构自己的 MCP Server 时，就把原本 130+ tools 收缩成 11 个高层工具，再通过 registry-based dispatch 支撑 125+ resource types。

Harness 官方给出的估算是：

1
tool definition context
2
约 26% of 200K context
3
        ↓
4
约 1.6%

官方文章：

https://www.harness.io/blog/harness-mcp-server-redesign

这和 MCP Roadmap 现在提出的 progressive discovery，方向高度一致：

不是让模型看到更多工具，而是让模型在正确的时间看到正确的工具。

16. 为什么这对 Coding Agent 特别重要？#

Coding Agent 的工具集合天然会膨胀。

一个成熟 Coding Agent 可能同时接：

1
filesystem
2
shell
3
git
4
github
5
browser
6
postgres
7
cloudflare
8
vercel
9
sentry
10
slack
11
jira
12
notion
13
linear
14
docker
15
kubernetes

每个系统再暴露几十个操作，很快就能达到几百工具。

如果全部加载：

1
Agent = LLM + 300 tools

表面能力很强。

但模型每次都要在几百个候选之间判断：

“我现在应该调用哪一个？”

所以未来成熟 Harness 很可能需要额外一层：

1
Intent
2
 ↓
3
Capability Router
4
 ↓
5
Relevant MCP Namespace
6
 ↓
7
Tool Selection
8
 ↓
9
Execution

而不是：

1
Intent
2
 ↓
3
300 tools
4
 ↓
5
pray

17. Improved Primitives 里还有一个容易被忽略的问题：结果契约不稳定#

官方 Roadmap 提到：

tools/call response 现在可能以不止一种形式表达相同输出。

问题在于 MCP Server 开发者未必知道 Client 最终会把哪一种形式展示给模型。

这会导致一种非常隐蔽的兼容性问题：

1
Server returns:
2
structuredContent
3
+
4
text content

Client A：

1
prefer structuredContent

Client B：

1
prefer text

Client C：

1
merge both

于是同一个 Tool，在不同 Agent Client 中可能产生不同上下文。

对于普通 UI，这叫 rendering difference。

对于 Agent，这可能直接变成：

behavior difference

因为模型看到的输入变了。

所以结果契约标准化，本质上也是 Agent determinism 的一部分。

18. 这和“同模型不同 Harness 表现不同”是同一个问题#

今天大家已经越来越接受：

1
Agent Quality ≠ Model Quality

更接近：

1
Agent Quality
2
= Model
3
× Context
4
× Tools
5
× Runtime
6
× Policy
7
× Verification

如果 Tool Result Contract 不一致：

1
same model
2
same task
3
same server

也可能因为 Client serialization 不同而产生不同结果。

因此 MCP primitive 的严格程度，会直接影响跨客户端 Agent 行为的一致性。

19. 第五个方向为什么是 SDK Developer Experience？#

很多协议 Roadmap 会把 SDK DX 放在比较低的位置。

MCP 反而把它列成五大 priority 之一。

官方给出的一个原因非常有时代特征：

越来越多开发者不是自己逐行阅读 SDK，而是让 Coding Agent 根据 SDK 文档直接生成 MCP Client / Server。

这意味着：

1
Documentation Quality
2
        ↓
3
Agent-generated Code Quality

以前糟糕文档的后果可能是：

开发者多查半小时 Stack Overflow。

现在糟糕文档的后果可能是：

1
Coding Agent
2
  ↓
3
learns outdated API
4
  ↓
5
creates wrong implementation
6
  ↓
7
passes shallow test
8
  ↓
9
ships to production

SDK DX 已经不只是“开发者体验”，还是Agent Coding Correctness 的输入数据质量。

20. MCP SDK 以后需要一种新的指标：Agent Legibility#

传统 SDK 经常优化：

1
Human Readability
2
API Consistency
3
Type Safety
4
Docs Completeness

未来可能还需要一个维度：

Agent Legibility

也就是：

1
一个 Coding Agent
2
能不能仅凭官方文档
3
生成正确、最新、符合安全边界的实现？

可以设计一个 benchmark：

1
只允许读取官方 SDK docs
2
实现一个具备 auth + tools + progress 的 MCP Server

1
First-pass conformance rate
2
Retry count
3
Deprecated API usage
4
Security misconfiguration count

21. Roadmap 五个方向，其实可以合并成一个更大的架构图#

把它们放在一起：

1
                 ┌────────────────────┐
2
                 │    Agent Client    │
3
                 └─────────┬──────────┘
4
                           │
5
                  Progressive Discovery
6
                           │
7
                 ┌─────────▼──────────┐
8
                 │ Capability Surface │
9
                 └─────────┬──────────┘
10
                           │
11
                    HTTP-native MCP
12
                           │
13
              ┌────────────▼────────────┐
14
              │ Identity / Authorization│
15
              │ DPoP / WIF / Exchange   │
16
              └────────────┬────────────┘
17
                           │
18
                  ┌────────▼────────┐
19
                  │    MCP Server    │
20
                  └────────┬────────┘
21
                           │
22
                      Task Runtime
23
                           │
24
              ┌────────────▼────────────┐
25
              │ Event / Progress / Push │
26
              └─────────────────────────┘

你会发现它已经覆盖：

• capability discovery；
• transport；
• identity；
• delegation；
• task lifecycle；
• events；
• result contract；
• SDK conformance。

这就是为什么我认为 MCP 正在从：

1
Model ↔ Tool Protocol

向：

1
Agent ↔ Runtime Capability Protocol

演化。

再次强调：

“Agent Runtime Protocol”是本文的工程归纳，不是 MCP 官方给自己改的新名字。

22. 但 MCP 并不会替代 Harness#

看到这里很容易走到另一个极端：

那以后 Agent Harness 都由 MCP 解决？

不会。

MCP 解决的是 interoperable protocol primitives。

Harness 仍然负责：

1
prompt policy
2
context selection
3
memory
4
planning
5
subagent orchestration
6
sandbox
7
verification
8
budget
9
retry policy
10
model routing
11
human approval

可以理解为：

1
                 Agent Harness
2
        ┌──────────────────────────┐
3
        │ Planning                 │
4
        │ Context                  │
5
        │ Memory                   │
6
        │ Verification             │
7
        │ Policy                   │
8
        │ Budget                   │
9
        │                          │
10
        │      MCP Client          │
11
        └────────────┬─────────────┘
12
                     │
13
                     ▼
14
                  MCP Layer
15
                     │
16
                     ▼
17
               External Systems

MCP 是 Harness 的基础设施层之一，而不是 Harness 本身。

23. Roadmap 对 MCP Gateway 也有一个重要暗示#

如果未来 MCP 真正出现：

• workload identity；
• token exchange；
• progressive discovery；
• event channels；
• task lifecycle；

那么企业里的 MCP Gateway 也会从今天的：

1
proxy + auth + audit

升级成：

1
Identity Broker
2
Capability Router
3
Policy Enforcement Point
4
Task Event Gateway
5
Audit Plane
6
Rate Limit
7
Cost Control

也就是说 MCP Gateway 可能越来越像 Agent Control Plane 的一部分。

这与 Cloudflare、Harness、Snowflake 等厂商近期围绕 MCP Gateway、AI Gateway、Agent policy 的投入是同一条趋势。

24. 对个人开发者来说，现在最值得做的不是“等新规范”#

Roadmap 里的很多东西还在演进。

因此现在最糟糕的做法是：

等所有标准都稳定以后再设计架构。

更合理的是提前把系统设计成可迁移。

1
run_full_ci()

1
start_ci()
2
→ task_id
3

4
get_task(task_id)
5
subscribe_task(task_id)

1
short-lived credential
2
workload identity
3
scoped token

1
.env
2
API_TOKEN=永久管理员凭据

1
discovery
2
namespace
3
routing
4
lazy loading

1
{
2
  "status": "success",
3
  "data": {},
4
  "summary": "...",
5
  "metadata": {}
6
}

25. 如果你正在做 Coding Agent，可以现在做这四组实验#

1
20 tools
2
50 tools
3
100 tools
4
200 tools

1
Tool Selection Accuracy
2
Wrong Tool Call Rate
3
Input Tokens
4
TTFT
5
Task Success Rate

1
poll every 2 seconds

1
push / subscription

1
request count
2
server CPU
3
network traffic
4
completion notification delay
5
client complexity

1
Main Agent
2
Explorer Agent
3
Deployment Agent

1
Explorer 是否能 deploy？
2
Deployment token 是否能读取不相关 repo？
3
token 泄露后多久失效？
4
是否能 revoke 单个 workload？

1
Claude
2
Codex
3
Cursor
4
VS Code
5
自研 Agent

26. 我会特别关注的三个指标#

未来评估 MCP 架构，我认为至少应该加入三个指标。

1
总 Tool Schema Tokens
2
+
3
Tool Result Tokens
4
+
5
Protocol Metadata Tokens
6
───────────────────────
7
成功任务数

1
任务实际需要权限
2
────────────────
3
Agent 实际获得权限

1
server state changed
2
        ↓
3
agent became aware

27. MCP 未来最大的风险：协议越来越强，也越来越复杂#

Roadmap 的方向基本合理。

但它也带来一个明显风险：

MCP 会不会从一个很简单的 Tool Protocol，逐渐变成一个过度复杂的 Agent Platform Protocol？

因为现在已经在讨论：

1
Tasks
2
Events
3
Subscriptions
4
Identity
5
Delegation
6
Discovery
7
Result Types
8
Transport
9
Extensions

如果所有东西都进入 Core，协议很容易膨胀。

好消息是当前 MCP 的治理方向相对克制。

官方正在把不少能力放入：

1
extensions
2
experimental extensions
3
Working Groups
4
SEPs

而不是所有能力都强塞进核心规范。

这点非常重要。

28. 为什么 Extension Model 会决定 MCP 能不能长期活下来？#

成熟协议一般都要面对一个矛盾：

1
Core 太小
2
→ 不够用
3

4
Core 太大
5
→ 难实现、难兼容、难演进

MCP 更合理的结构应该是：

1
Small Stable Core
2
        ↓
3
Official Extensions
4
        ↓
5
Experimental Extensions
6
        ↓
7
Domain-specific Extensions

例如：

1
finance
2
healthcare
3
coding
4
payments
5
browser automation

都可能有不同扩展需求。

如果 extension lifecycle 做好，MCP 才能避免变成“一个协议解决全世界”。

29. 对 MCP Server 作者来说，Roadmap 带来的迁移清单#

现在可以开始检查：

30. 对 Agent Client 作者来说，重点则完全不同#

Agent Client 应该开始准备：

1
Task-aware runtime
2
Event subscription
3
Reconnect
4
Capability cache
5
Progressive discovery
6
Identity delegation
7
Result normalization

尤其不要再假设：

1
MCP call == short synchronous function call

这个假设未来会越来越不成立。

31. 对企业平台来说，未来需要的是 MCP Control Plane#

当 MCP Server 从 5 个增长到 500 个以后，企业不会继续手工配置：

1
server URL
2
OAuth client
3
scope
4
allowed tools

最终一定会出现：

1
MCP Registry
2
MCP Gateway
3
Identity Broker
4
Policy Engine
5
Audit
6
Observability
7
Cost Control

我更倾向把这一整层叫：

Agent Capability Control Plane

因为它管理的不只是 MCP connection，而是 Agent 能力本身。

32. 一个可能的生产架构#

1
                    Human / CI / Agent
2
                           │
3
                           ▼
4
                  ┌─────────────────┐
5
                  │ Agent Harness   │
6
                  │ plan/context    │
7
                  │ verify/budget   │
8
                  └────────┬────────┘
9
                           │
10
                           ▼
11
                  ┌─────────────────┐
12
                  │ MCP Gateway     │
13
                  │ discovery      │
14
                  │ policy         │
15
                  │ audit          │
16
                  └────────┬────────┘
17
                           │
18
                 Workload Identity
19
                           │
20
              ┌────────────┼────────────┐
21
              ▼            ▼            ▼
22
         GitHub MCP   Cloud MCP    Internal MCP
23
              │            │            │
24
              └────────────┼────────────┘
25
                           │
26
                           ▼
27
                     Task Runtime
28
                           │
29
                    Events / Progress
30
                           │
31
                           ▼
32
                     Agent Harness

这套架构里 MCP 不负责“思考”。

它负责的是：

让能力、任务、身份与结果以可互操作方式流动。

33. 新 Roadmap 真正释放的三个信号#

如果只记住三件事，我认为是这三个。

34. 最后：MCP 下一阶段竞争的不是“谁接的工具最多”#

2025 年 MCP 的竞争很容易量化：

1
支持多少 MCP Server？
2
有多少 Tools？
3
接了多少 SaaS？

2026 年以后，这些指标会越来越没有区分度。

真正重要的可能变成：

1
能不能让长任务稳定运行？
2

3
能不能让 Agent 拥有自己的短期身份？
4

5
能不能把权限正确委托给 Subagent？
6

7
能不能在几百个工具中只暴露当前需要的几个？
8

9
能不能跨 Client 保持结果语义一致？
10

11
能不能在 Agent 中断、重连、扩缩容以后继续完成工作？

所以我更愿意这样理解新的 MCP Roadmap：

MCP 的第一阶段解决了“模型怎么调用外部世界”；下一阶段开始解决“Agent 怎么在外部世界里长期、可控、可扩展地工作”。

这两句话听起来很接近。

但对应的工程复杂度完全不是一个数量级。

参考资料#