MCP Tasks 是 MCP 的官方扩展，用来处理不能在一次短请求里完成的工作。服务端不必让连接一直等到结束，而是先创建一个带状态和有效期的任务；客户端之后通过任务 ID 查询进度，必要时继续提供输入，最终取回结果。
先用一句话抓住它
MCP Tasks 把「调用工具后原地等」改成「拿到取件号，过一会儿查进度，完成后再取结果」。
普通工具调用适合查一条记录、读一个文件这类秒级操作。深度检索、批量分析、长时间代码执行或等待外部审批，可能持续几分钟甚至更久。用一个同步请求硬撑到底，会遇到超时、断线和无法恢复的问题。
为什么最近受到关注
Tasks 曾以实验形态出现，后来根据早期使用反馈重做，并在 MCP 2026-07-28 版本中成为官方扩展 SEP-2663。2026 年 8 月发布的新路线图再次把 Tasks、事件通知和更成熟的长任务组合列为重点，因此它在 MCP 开发者生态里快速升温。
它补的是智能体基础设施里的一个现实缺口：Agent 越来越能承担长时任务，但底层工具协议若仍假设所有调用立即返回，就会在最需要可靠性的地方掉链子。
它怎样工作
Tasks 是协商使用的扩展，不是服务端可以单方面强塞给所有客户端的行为。客户端在一次请求的元数据里明确选择 Tasks，服务端才可以返回创建任务的结果。随后客户端用 tasks/get 查询，直到任务进入完成、失败、取消等终态。
任务需要有明确的生命周期：状态、创建时间、过期策略、可否取消，以及结果保存多久。扩展当前主要围绕长时间工具调用设计；未来的 webhook 或 channel 可以减少轮询，但轮询仍是最容易跨环境实现的基础方案。
和普通 Tool Calling、队列的区别
Tool Calling 描述模型怎样表达「我要调用这个工具」。MCP Tasks 描述这次调用耗时较长时，客户端与服务端怎样保持状态并晚点拿结果。前者是调用意图，后者是执行生命周期。
它也不等于完整的工作队列。任务扩展定义协议两端看得见的状态和操作，但服务端内部用数据库、消息队列还是进程内执行，由实现者决定。生产系统仍需自己解决持久化、重试、幂等、资源配额和故障恢复。
适合哪些场景
适合 MCP Tasks 的工作通常有两个特征：完成时间明显超过普通请求，且中途断开后仍希望继续。例如大仓库代码扫描、多文档研究、批量媒体处理、异步部署检查，以及需要等待人类确认的流程。
毫秒或秒级调用没必要任务化，否则一次简单读取也要经历创建、查询和清理，复杂度与延迟都会上升。
限制与实践要点
客户端与服务端都必须支持 2026-07-28 及之后的协议版本和 Tasks 扩展，旧版实验实现与新版并非线缆兼容。服务端还要防止任务无限堆积：设置超时、到期清理、并发上限和取消路径，并确保同一个任务 ID 不会泄露给无权用户。
轮询间隔也要克制。查得太频繁会把后台任务变成前台压力；查得太慢又会让用户感觉卡住。更好的界面会展示最后状态、下一次建议查询时间，以及任务失败后能否重试。