# MCP 2026 新主线：把编排流程从大模型手里拿回来，交给硬代码

> 原标题：MCP 2026 的新主线：在协议层划定一条确定的边界

- 来源：Computing Life · Share · 鸭哥调研
- 发布时间：2026-06-29T00:00:00.000Z
- AX AI 日报：https://ai-daily.ax0x.ai/items/41423
- 原文：https://yage.ai/share/mcp-2026-certainty-layering-20260629.html

## 摘要

MCP 2026 路线图引入 Tasks 原语，核心思路是把状态轮询、超时重试这类编排工作从大模型剥离，交给宿主应用的确定性代码。协议底层用 created、working 和三种终态组成状态机，大模型只负责发起任务和解读最终结果，不再参与中间过程。工具开发者可以通过 execution.taskSupport 的三态机制（forbidden、opti...

## 推荐理由

MCP 2026 路线图引入 Tasks 原语，核心是把状态轮询和超时重试从大模型剥离，交给宿主应用的确定性代码——这个分层思路对 agent 开发者有实打实的价值。文章有 SEP-1686 做技术支撑，细节够硬。没给更高分是因为它毕竟还是协议层面的设计讨论，影响范围集中在 MCP 生态内，还没到整个行业都得关注的程度。

## 锐评

这条路线图的核心判断很实在：别让大模型当状态机。SEP-1686 提案用 created、working 加三种终态组成的状态机，把轮询、超时、重试这些机械活从提示词里剥离，交还给宿主应用的硬代码。大模型只负责发起任务和解读最终结果，中间过程完全不参与。这个分工逻辑是对的，因为轮询需要稳定可预测，而大模型天生有随机性，靠自然语言去推断任务是否结束，翻车概率太高。

工具开发者可以通过 execution.taskSupport 的三态机制（forbidden、optional、required）自己决定每个工具走同步还是异步，协议层不替人做决定。这点比较务实，轻量测试三秒出结果的工具没必要硬上异步状态机。

但得打个折。Tasks 目前贴着实验性标签，推送机制还没有标准 webhook，只能靠 SSE 轮询，失败重启语义和结果清理策略都没定型。文章自己也承认，多智能体嵌套时外层硬代码包着内层多智能体纠错闭环，这种套娃设计怎么传诊断信号，协议还没答案。现阶段别急着把跑得好好的系统推倒重写，但每季度扫一眼规范演进，当成观察智能体架构趋势的信号，确实值得做。