让大模型帮我们干活时，如果遇到耗时较长的任务，比如整理大型代码库，或在后台清洗数十万条医疗分子数据，开发者经常会遇到一件头疼事。
你本想让它在后台盯着任务跑完。结果它调工具查了一次状态，发现还在处理，下一次查询时可能就记错了任务名字，或者只查了一次就误以为任务已经搞定，拿着残缺的结果直接交差。
只要让智能体去跑超过 30 秒的任务，在现有的开发模式下，几乎肯定会撞上这个难题。
以前的解决办法是给大模型套上层层提示词，在规则里强行要求它按步骤轮询。但这东西天生有随机性。越是用死规则框它的每一步过程，代码就写得越臃肿，最后不仅管不住它，开发者大半时间反而在忙着给它收拾残局。
探讨 AI 时代的另一种安全感时，我们曾谈到开发理念的转变：以往程序员的安全感来自过程确定，习惯用硬编码把每一个因果分支锁死；但在 AI 时代，与其用条条框框限制它每一步的过程，不如转向结果确定，只要定义好终点，写好自动运行的验收脚本，让它在执行和纠错的闭环里自己去摸索。
不过，随着这套模式在实际生产中落地，人们很快就发现了局限：走任何一个极端，工程上都有副作用。
把所有环节都用硬编码死死管住，或者把所有事情都甩给大模型看守，这两种极端在实际系统设计中都行不通。
有价值的架构设计，不是盲目追求某一端，而是看清这条不确定性光谱，为不同的具体环节找到合适的位置。
最近发布的 Model Context Protocol 2026 路线图引入了专门处理异步任务的 Tasks 原语。
这套来自 SEP-1686 提案的标准，在协议底层作出了清晰的划分。它不只是方便调用异步接口的协议补丁，而是在协议层重新厘清了大模型与传统代码的分工，对智能体应用做了一次确定性分层。
Tasks 原语的设计思路是：大模型不该再去承担状态轮询、超时计算、重试监控这类流程工作。
协议在底层规定了一套状态机。异步任务创建后先进入 created 状态，接着是 working 状态，最后只有三种不可逆的终态：成功完成、宣告失败，或由用户中途取消。
这些生命周期的状态变化，完全由宿主应用里用确定性代码写成的机制来驱动，大模型不参与中间轮询状态的判断。
在此期间，宿主应用可以直接调用协议规定的四个基础 JSON-RPC 方法（tasks/get、tasks/result、tasks/list、tasks/cancel）查询状态、拉取结果。大模型既不用管后台跑了多少秒，不用写循环代码，也无需理会各种复杂的临时任务标识符。
为什么把编排流程放在过程确定性这一端？
因为轮询、超时、重试的核心特征是稳定和可预测，而这恰恰是确定性代码的强项。
如果把这些看守工作全交给大模型，指望它靠自然语言去推断任务是否结束、需不需要继续等待，结果往往不可靠。
SEP-1686 提案中列举的代码迁移、深度研究（Deep Research）等案例，说的就是这类痛点。
比如以前做自动代码迁移工具，为了让大模型在漫长的转换中不掉线，开发者不得不把任务拆成启动和状态查询两个工具，指望它在提示词引导下一遍遍去轮询。但模型经常在轮询一两次后就出现幻觉，不是记错任务名，就是误以为任务已完成而提前退出。
协议层把这些需要过程确定的编排职责收了回来，让宿主应用在底层用确定性代码处理所有轮询。等拿到最终结果，再把数据呈给大模型处理。大模型刚开始只要发出一个带任务标记的请求，接着就可以去干别的了。
MCP 规范了编排层的确定性，为整个生命周期画好了严密的轨道，但它并不限制工具内部怎么运行。
无论工具内部是跑一段普通的文件读写，还是执行复杂的深度研究，协议层都不加限制。
这在实际应用中引发了新的矛盾：如果工具内部也是个多智能体系统（比如宿主调用了深度研究工具后，它在内部又启动了三个子智能体去同步跑检索和整理），这会怎么样？
这样一来，外层是一个用过程代码锁死的外壳，内部却包裹着一个用多智能体纠错闭环驱动的内核。
这种外层确定、内层随机的套娃设计，在工程实践中真的能自洽吗？
当内层的多智能体在模糊推理中遇到异常、在闭环里挣扎时，我们怎么在不打破外层硬代码状态机的前提下，把里面的诊断日志和控制信号传出来？
面对这种不同确定性层次的嵌套，目前的协议规范并没有给出答案，但这正是未来复杂智能体架构避不开的问题。
大模型的工具调用链路千变万化。哪些工具该走异步轮询，哪些该走普通同步？
MCP 并没有一刀切地替开发者做决定，而是通过能力协商，提供了一个名为 execution.taskSupport 的三态机制：
这套机制的设计思路是：协议层不替开发者做决定，只提供通用的通信框架和状态机。
至于每个工具到底该落在光谱的哪一端，选择权直接下放给了具体的工具开发者。
比如一个分子属性分析工具，在轻量测试下三秒就能出结果，开发者可以把它设为 optional 甚至直接同步。但一旦进入生产环境、需要处理数十万数据点时，开发者完全可以根据实际耗时，动态将其声明为 required，强制系统接入异步状态机。
比起编排和协商上的划分，Tasks 协议的其他细节就显得常规多了。
比如状态机里的 input_required 状态。当任务跑到一半需要人工干预（比如输入双重验证码、确认敏感操作的临时授权）时，协议层提供了一个标准接口，允许将 pending 请求抛给宿主应用向用户索要数据，拿到后再回到 working 状态继续推进。
这谈不上新发明，只是把主流开发工具早已普及的做法，顺理成章地收编进了规范本身。
同样，让大模型只负责发起任务和理解最终结果，不插手中间过程，也是对大模型推理边界的理性划分。
不过，我们也得客观面对当下的局限。
虽然 SEP-1686 提案已正式采纳 Tasks，并将其写入 MCP 2025-11-25 规范，但这套机制目前仍贴着实验性标签。任务失败后的重启语义、结果生命周期的清理策略，以及不依赖轮询的推送机制（目前还没有标准的 webhook，只能靠 SSE），都未在生态中完全定型。
至于更上一层的多智能体图（Agent Graphs），在目前的路线图里更像是一个方向性宣言。绝大多数涉及跨智能体复杂协作的生产系统，至今依然高度依赖开发者手搓的框架代码。
安全方面，2025 年密集爆发的安全事故（比如恶意 GitHub issue 注入，导致大模型在没有物理隔离的情况下私自读取并外泄代码）倒逼规范在年底迅速补齐了 OAuth 2.1 等企业级认证，用细粒度临时授权和命名空间隔离，把智能体关进沙盒。
目前阶段，开发者大可不必急着动手，把运行平稳的系统推倒用新协议重写。
不过，每季度扫一遍底层规范的演进与提案流，把它当成观察智能体演化趋势的长期信号，确实有必要。
底层技术演进的背后，有一条实用的架构原则：构建智能体系统并让 AI 处理长异步任务时，应当先梳理整条业务链路的所有步骤，明确区分推理与编排。
第一，纯粹的推理。凡是需要理解模糊上下文、用自然语言把关质量，或者根据业务场景灵活决策的环节，都应当留给大模型。在这部分，开发者需要接受过程的不确定性，在外层设计可核对的验收标准，而不是用硬编码限制模型推理。利用成本降低的 token，让模型在执行与纠错的闭环里摸索，最终产出确定的结果。
第二，纯粹的编排。凡是状态轮询、重试监控、超时计算、任务取消这类机械的流程步骤，都应当从提示词中剥离，交还给宿主应用中用确定性代码实现的逻辑。在这些环节，应当追求过程确定，用硬编码锁死每一个因果分支。
把编排工作交给大模型，指望用提示词让它扮演状态机，是目前智能体系统中常见的架构错误。理清两者的边界，由确定性代码负责流程编排，由大模型负责内容推理，是构建稳定智能体系统的基础。