# 久挂即超时：长任务工具四范式实测 ## 概述 当工具的执行时间从"几秒"滑向"几分钟甚至几小时"，几乎所有主流智能体框架都会撞上同一堵墙——**30 秒墙**。云函数超时、负载均衡器杀掉空闲连接、移动端休眠、网关 504，工具还在后台跑，调用方却早已断开。WorkOS 在 2025-12 披露的 MCP `Tasks` 原语、Tian Pan 在 2026-03 给出的 async job 模式、Fastio 在 2026 年总结的五策略，本质上都在回答同一个问题：**工具调用方不该和工具执行方绑死在同一条连接上**。本期实测四大范式——同步阻塞、流式进度、异步任务轮询、持久化工作流引擎——在超时存活率、副作用安全、人机协作、回滚能力上的真实表现，结论是：四者不是替代关系，而是按任务时长叠加的分层栈，缺一层都会在第一个真实负载到来时静默崩塌。 ## 四范式对比表 | 维度 | 同步阻塞 | 流式进度 | 异步任务轮询 | 持久化工作流引擎 | |------|----------|----------|--------------|------------------| | 典型实现 | 传统 `tools/call` | SSE / `RunStreamingAsync` / `progressToken` | MCP `Tasks` / `202 Accepted` + `task_id` | Temporal / Durable Task / LangGraph / CF Think fibers | | 任务时长上限 | < 10s | < 请求连接寿命 | < TTL（默认分钟级，可调） | 数小时～数天（Claude 实测 30h、Google 7 天） | | 连接占用 | 全程阻塞 | 全程占用（持续推流） | 仅握手瞬间 | 零占用（状态外置） | | 超时后可恢复 | 否，静默失败 | 否，半截流被丢弃 | 是，靠 `task_id` 重新拉取 | 是，checkpoint-replay 回到断点 | | 副作用安全（重试） | 差，易重复执行 | 差 | 中，靠幂等键 | 强，step 级幂等 + 补偿 | | 进度可见性 | 无 | 实时 token/百分比 | `pollInterval` 轮询 + 通知 | 事件日志 + 结构化 `progress.json` | | 人机协作（HITL） | 不支持 | 弱 | `input_required` 状态 | 原生支持（零算力挂起） | | 上手成本 | 极低 | 低 | 中（需任务存储） | 高（需工作流引擎） | ## 深度分析 ### 一、30 秒墙：同步范式为何必然失配 绝大多数智能体框架的默认心智模型是"一次 HTTP 请求里跑完整个 agent loop"。LangChain、基础版 LlamaIndex 都把完整推理循环同步塞进请求处理器——演示能跑，一旦任务超过 30 秒就静默崩。失配有三层：协议层，HTTP 为同步请求-响应设计，超过 30 秒就在和协议对抗；基础设施层，云函数、负载均衡器、移动端会主动杀掉长连接；分布式层，最阴险的是"客户端超时、agent 仍在后台跑、输出再也取不回"——若客户端重试，就出现两个 agent 跑同一任务，副作用（发邮件、写记录、扣款）被双倍触发。 更残酷的是算术：一个每分钟存活率 99% 的任务，60 分钟不间断完成的概率只剩 **55%**。也就是说，盲目加超时（把负载均衡调到 5 分钟）只是把崩塌点后移，失败模式依然是静默的。结论：**同步范式只配处理 < 10 秒的工具**，这是物理上限而非配置问题。变现上，这是企业级 agent 训练营最该先打破的认知——大量学员把"能跑 demo"误当成"能上生产"。 ### 二、流式进度的边界：看得见不等于不超时 流式是过渡范式。Microsoft Agent Framework 的 `RunStreamingAsync`、MCP 的 `progressToken`、OpenAI 的 SSE，让工具边跑边推 token 和百分比，UX 上"活着"。但它**仍全程占用连接**：进度可见只解决了焦虑，没解决超时——连接照样会被网关切。Fastio 明确指出，要区分 time-to-first-token（2 秒首字）和总响应时间（45 秒完成），如果一刀切 20 秒超时，会把一个完全健康的流式响应误杀。 流式范式的真实定位是**"秒级到分钟级"任务的体验优化层**，而不是长任务的执行层。它的致命假设是"调用方会一直在线听"。一旦工具跑到第 90 秒、客户端已断开，那些推送出去的进度通知就成了无人接收的广播。实测中，流式最常见的工程误用是：把它当作长任务的银弹，结果在 30 秒墙前比纯同步死得更难看（因为已经推了一半、用户以为要成了）。**变现提示**：流式适合做"代码解释器、实时搜索"这类秒级工具的卖点，但绝不能进"批量处理、深度研究"的训练营大纲作为主架构。 ### 三、MCP Tasks：call-now, fetch-later 协议深拆 2025-11-25 版 MCP 引入的 `Tasks` 原语，是 2026 年最值得关注的长任务标准化方案。核心机制是 **call-now, fetch-later**：调用方在普通 `tools/call` 的 params 里加一个 `task` 字段（目前只有 `ttl`），接收方立即返回一个 durable handle（`taskId` + `status: working` + `pollInterval`），真实工作在后台继续，调用方稍后用 `tasks/get` 轮询、`tasks/result` 阻塞取结果、`tasks/cancel` 取消。 ```json // 调用方：发起异步任务 { "method": "tools/call", "params": { "name": "get_weather", "arguments": {"city": "New York"}, "task": { "ttl": 60000 } } } // 接收方：立即返回 durable handle { "result": { "task": { "taskId": "786512e2-...", "status": "working", "pollInterval": 5000, "ttl": 60000 } } } ``` 它定义了五状态机 `working → input_required → completed/failed/cancelled`，状态转移 append-only（终态不可逆，防止重试中看到 `completed→working` 回退）。两层协商很精妙：全局 `capabilities.tasks` 声明哪些请求可异步，工具级 `execution.taskSupport`（`forbidden/optional/required`）再细化到单个工具——让快工具声明"我永远秒回，别 task 化"、慢工具声明"我很 batch，必须 task"。**变现评估**：MCP Tasks 是把"agentic automation 做成基础设施"的关键拼图，做企业 MCP 集成、多租户长任务平台的训练营可以直接以此为骨架，含金量远高于"又包了一层 LangChain"。 ### 四、幂等键：为什么 agent 比普通 API 更需要它 普通 REST 只在写接口建议用幂等键，对 agent 而言它是**非可选**。原因在于 agent 的重试链路更长更脆弱：网络在 `202` 返回前断开，调用方无法判断任务是否被接受，正确做法是重试——没有幂等键就会 spawn 第二个 agent。Tian Pan 给出的 agent 专属增强是：**每个有副作用的工具调用都应携带一个由 `task_id:step_index` 派生的幂等键**，hash 后作为 key。这样 agent 从 checkpoint 恢复、重放同一步骤时，重试的工具调用产生相同效果，不会重复扣款/发邮件。 MCP 侧的实现要点呼应了这一点：协议不强制任务创建幂等，但"真实网络会重试"，WorkOS 建议接受 idempotency key 或对稳定输入做 hash 去重到同一 `taskId`。配套还有 TTL 绑定：每个 task 必须绑定创建者的授权上下文（用户/租户/API client），`tasks/get|result|cancel` 全部校验该绑定，否则当作"任务不存在"返回——防止 taskId 被枚举越权。**这是长任务范式从"能跑"到"敢上线"的分水岭**。训练营若不教这层，学员做出来的 agent 一上量就会出现"重复执行 + 数据泄漏"双重事故。 ### 五、轮询 vs Webhook：真相源原则 团队一上异步就本能想做 webhook，但 webhook 失效模式很隐蔽：被防火墙吞、接收端短暂宕机时静默失败、重试乱序、要求调用方有公网可达的 HTTP 服务（移动端、NAT 后的开发机根本做不到）。实战铁律是 **"poll for truth, listen for speed"**——把轮询当真相源，把 webhook 当优化。客户端按指数退避轮询 `GET /tasks/{id}`（1 秒起步、30 秒封顶）直到终态；webhook 命中则提前停止轮询，两者正确叠加。 MCP 把同一原则写进了协议：`tasks/get` 是权威，`notifications/tasks/status` 是 best-effort 推送；即便通知全丢，轮询也能追上。Webhook 侧要做到：签名、带 event id 去重、服务端指数退避重试、提供 replay 端点让客户端补拉漏掉的事件。**实测中最常见的翻车**：只配 webhook 不配轮询，任务卡在终态前、用户等不到结果。变现上，这是"可靠 agent 通信"模块的标准考点，可设计成对比实验作业。 ### 六、持久化引擎：checkpoint-replay 的四栈横评 当任务跨小时乃至跨天，单纯的 async task 不够，需要持久化工作流引擎。Fastio 2026 横评给出的格局：**Temporal** 最成熟、跨语言、重试/超时/状态持久一体，但学习曲线陡；**Microsoft Durable Task**（.NET/Python/Java/TS）自动 checkpoint 每次状态转移（含 LLM 响应、工具结果、控制流决策），Azure 生态首选；**LangGraph** 配 checkpointer 即拥有持久化执行，可随时暂停恢复；**Cloudflare Project Think** 2026 初引入 "fibers"，用协同部署的 SQLite 让 checkpoint 快且本地，`ctx.stash()` 中途存执行状态： ```js async function researchLoop(ctx, topics) { for (const topic of topics) { const findings = await agent.research(topic); ctx.stash({ topic, findings, completedAt: Date.now() }); // 中途落盘 } } // worker 重启 → onFiberRecovered 触发 → 从最后 stash 点恢复 ``` 核心机制是 **checkpoint-replay**：每次 LLM/外部调用前先记日志，进程重启时回放日志、用缓存结果替代真实重调，从失败点继续、不重复 API 调用。这层最大的价值是支撑 HITL——agent 带完整执行态（推理链、工作记忆、工具历史）挂起，人类花几小时几天才回应，期间零算力，回应后亚秒级恢复。实测中 Claude 自主编码已跑 **30+ 小时**、Google Agent Runtime 维持状态 **7 天**，没有持久化引擎这根本不可能。**变现**：durable agent 是 2026 高客单训练营的旗舰主题，Temporal + 某个 LLM 框架的组合课最有商业价值。 ### 七、工具级范式标注：把选择权交给 Schema 四范式不该由框架一刀切，而应下沉到工具声明。MCP 的 `execution.taskSupport` 三态（`forbidden/optional/required`）是最佳实践样本：让每个工具在 `tools/list` 自报家门——天气查询声明 `forbidden`（永远同步、别异步化），批量 ETL 声明 `required`（必须 task，否则拒绝）。配合全局 capability 协商，形成"快工具走同步低延迟、慢工具走异步高可靠"的混合调度，调用方无需为每个工具写特判逻辑。 匹配基础设施到任务时长是另一条决策线：**< 10 秒同步、< 1 小时 async + 轮询、> 数小时用工作流引擎**。小时边界之所以关键，是因为轮询型异步要求客户端保持 session 主动轮询；多小时任务里客户端会断开重连，必须把任务持久化到被显式确认之前，而非随轮询 session 结束就消失。**变现提示**：可做"工具 Schema 自动标注 execution.taskSupport"的小工具，作为训练营的配套交付物。 ### 八、生产架构分层：四范式是叠加不是二选一 四范式真正的工程姿态是**分层栈**，Fastio 给出的生产堆叠如下：底层 checkpoint 在每个有意义的工件后落盘；其上 message queue（Redis+BullMQ / RabbitMQ / SQS）解耦"决定做什么"与"去做"，让 worker 与 orchestrator 独立崩溃互不影响；再上 durable execution 包裹 agent 核心逻辑做自动 replay；timeout/retry 策略守护每个外部调用（区分 429/5xx 可重试 vs 401/400/上下文溢出不可重试，指数退避+jitter，熔断器按服务隔离）；最上层进度报告（结构化 `progress.json` + Slack/邮件/webhook 通知）喂人和监控。 监控盯四个指标：**任务完成率、中位时长、每外部服务的重试频率、checkpoint 恢复次数**——重试飙升说明依赖在退化、恢复次数上升说明基础设施不稳。这套栈不要 Day 1 全上：从 checkpoint 起步，要并行加队列，手动 checkpoint 维护不动了再上 durable 框架，接外部服务加 timeout 策略，人开始问"好了吗"再加进度报告。**可靠性必须匹配任务时长：5 分钟的任务要 checkpoint，5 小时的任务要全套栈**。 ## 长任务工具四范式决策架构 ```mermaid flowchart TD Q["工具预期执行时长？"] --> S1{"< 10秒？"} S1 -->|是| P1["范式一：同步阻塞
tools/call 直返"] S1 -->|否| S2{"< 连接寿命 ~1分钟？"} S2 -->|是| P2["范式二：流式进度
SSE / progressToken / RunStreamingAsync"] S2 -->|否| S3{"< 1小时 且 客户端在线轮询？"} S3 -->|是| P3["范式三：异步任务轮询
MCP Tasks / 202 + task_id
poll 真相源 + webhook 优化"] S3 -->|否| P4["范式四：持久化工作流引擎
Temporal / Durable Task / LangGraph / CF fibers
checkpoint-replay + HITL 零算力挂起"] P1 -.失败点.-> F1["30秒墙 / 静默失败 / 重试双倍副作用"] P2 -.失败点.-> F2["连接被网关切 / 半截流丢弃"] P3 -.失败点.-> F3["缺幂等键→重复执行"] P4 -.失败点.-> F4["学习曲线陡 / 引擎依赖"] P3 --> I["幂等键 task_id:step_index
+ TTL 授权上下文绑定"] P4 --> C["监控: 完成率/中位时长/重试频率/恢复次数"] ``` ## 推荐方案 **秒级工具（代码解释、单次搜索、计算）**：范式一同步直返即可，但务必配请求级 timeout（10–20s）和只对 429/5xx 重试的策略，别给秒级工具套异步壳——那是徒增复杂度。 **分钟级工具（深度研究、批量转换、多步抓取）**：范式三异步任务轮询是性价比最优解。若已用 MCP，直接上 `Tasks` 原语并正确实现 `tasks/get|result|cancel` + 幂等键；自研则照 202 Accepted + `task_id` + 轮询模板。**不要**用流式硬扛（范式二会在网关前先死）。 **小时～天级任务（周级内容工作流、长周期数据处理）**：范式四持久化引擎不可省。Azure 生态选 Microsoft Durable Task，通用跨语言选 Temporal，已在 LangChain 生态则用 LangGraph checkpointer。HITL 场景的零算力挂起是它的杀手锏。 **所有范式的共同底线**：幂等键（`task_id:step_index`）、轮询为真相源、状态 append-only 终态不可逆、监控四指标。这四条无论选哪层都必须有，是"敢上线"与"只是 demo"的分界。 **变现优先级**：① "MCP Tasks + 多租户长任务平台"训练营（企业 MCP 集成，高客单）；② "Temporal/LangGraph 持久化 durable agent"旗舰课（30h+ 自主任务，技术含量最高）；③ "异步工具通信：轮询/webhook/幂等"模块课（通用基础设施，受众最广）。流式（范式二）只适合做秒级工具的卖点包装，不宜作为长任务主线。 ## 参考来源 1. [MCP Async Tasks: Building long-running workflows for AI Agents — WorkOS](https://workos.com/blog/mcp-async-tasks-ai-agent-workflows) — MCP 2025-11-25 Tasks 原语（call-now/fetch-later、五状态机、两层 capability 协商、execution.taskSupport）完整技术指南 2. [How to Handle Long-Running Tasks in AI Agents (2026) — Fastio](https://fast.io/resources/ai-agent-long-running-tasks/) — 长任务失败算术（99%/分钟→55%/60分钟）、五策略分层栈、Temporal/Durable Task/LangGraph/CF Think fibers 横评 3. [Async Agent Workflows: Designing for Long-Running Tasks — Tian Pan](https://tianpan.co/blog/2026-03-07-async-agent-workflows-long-running-task-design) — 30 秒墙、HTTP 失配、202 Accepted 异步任务模式、agent 幂等键、轮询 vs webhook 真相源原则 4. [Running Agents — Microsoft Agent Framework / Microsoft Learn](https://learn.microsoft.com/en-us/agent-framework/agents/running-agents) — streaming vs non-streaming 运行模式、RunStreamingAsync 行为 5. [Build Long-Running AI Agents on Azure App Service with Microsoft Agent Framework — Azure](https://azure.github.io/AppService/2025/10/21/app-service-agent-framework.html) — Azure App Service + Agent Framework 长跑 agent 托管、Durable Functions 解决 AI timeout > [!tip] 51学通信知识星球 > **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 > **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 > **当前规模**：5200 篇主题 / 990 个回答，198 元/年。 > **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 > **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。