Vercel Functions 拉长到 30 分钟，AI 应用终于不用拆碎任务了？

Vercel 在 2026 年 6 月 15 日宣布，Pro 和 Enterprise 团队的 Node.js 与 Python Vercel Functions 可将最大执行时间配置到 30 分钟。对 AI 应用来说，这意味着长推理、工具调用、文档处理、OCR 和流式生成不必一律拆成碎片任务。但 30 分钟不是万能钥匙：它需要 Fluid Compute，超过 800 秒部分仍是 beta，长任务仍要设计超时、幂等、重试、成本监控和队列边界。

摘要：30 分钟解决的是“中长任务”，不是所有后台任务

过去在 Serverless 上做 AI 应用，开发者经常被超时时间卡住。一个文档总结、长上下文分析、代码仓库扫描、网页抓取、OCR、多轮工具调用，可能还没等大模型跑完，函数就已经超时。

Vercel 在 2026 年 6 月 15 日宣布，Pro 和 Enterprise 团队现在可以把 Node.js 与 Python runtime 的 Vercel Functions 最大执行时间配置到 30 分钟。这对 AI 应用是一个很现实的变化：很多原本被迫拆成多个短任务、队列、回调、轮询的流程，现在可以在一个更长的函数生命周期里完成。

但标题里的问题要谨慎回答：AI 应用不是终于“完全不用拆任务”了，而是“不必把所有中长任务都拆得很碎”。超过 800 秒的部分仍是 beta，而且需要启用 Fluid Compute。超过 30 分钟、并行 fan-out、GPU 推理、大批量数据处理、必须可靠重试的任务，仍然更适合队列、Workflow、后台 worker 或专门计算平台。

如果你正在搭建 AI 应用，可以继续阅读站内 AI 工作流教程、Vercel 相关内容、AI SDK 教程 和 Agent 开发文章。

Vercel 这次到底更新了什么

最大执行时间可到 30 分钟

根据 Vercel changelog，Pro 和 Enterprise 团队现在可以把 Node.js 与 Python runtime 的 Vercel Functions 最大执行时间配置到 30 分钟，也就是 1800 秒。Vercel 同时说明，Hobby 用户可以使用 60 秒执行时长。

需要注意，这不是所有 runtime、所有计划、所有项目自动生效。文章讨论的核心对象，是 Node.js 与 Python runtime、Pro/Enterprise 团队、并启用相关 Fluid Compute 能力的 Vercel Functions。

超过 800 秒仍是 beta

Vercel 明确写到，超过 800 秒的执行时长目前处于 beta。也就是说，如果你要把关键生产流程拉到 20 到 30 分钟，需要更谨慎地验证稳定性、错误处理、日志、告警和成本。

需要 Fluid Compute

官方更新提到，要配置超过 800 秒的执行时长，必须启用 Fluid Compute。Fluid Compute 是 Vercel 面向更长执行、I/O 等待和 AI 工作负载优化的计算模式。它让函数可以更好地处理长时间等待模型、数据库、外部 API 或工具调用的场景。

配置方式仍是 maxDuration

在 Next.js 项目里，常见做法是在 route handler 或 server action 所在文件导出 maxDuration。例如：

export const maxDuration = 1800;

export async function POST(request: Request) {
  // Long-running AI task here
  return Response.json({ ok: true });
}

也可以根据项目框架和 Vercel 配置使用对应方式。正式配置前，应以 Vercel 最新文档为准。

为什么 AI 应用特别需要更长函数

大模型不是每次都秒回

简单聊天可能几秒返回，但真实 AI 应用常常包含多步操作：读取用户文件、抽取文本、分块、检索、调用模型、调用工具、再次汇总、生成结构化结果。只要其中某一步慢，整体执行时间就会被拉长。

Agent 会把一次请求变成多轮执行

Agent 应用不是一次 prompt 就结束。它可能先规划，再搜索，再调用数据库，再跑代码，再检查结果，再继续调用模型。过去为了绕过短超时，开发者不得不把每一步拆成任务表、队列、状态机和轮询接口。

文档处理和 OCR 经常是中长任务

上传一份长 PDF、财务表格、合同、论文或代码压缩包，后端需要做解析、清洗、分块、embedding、摘要和校验。这类任务不一定长到几个小时，但很容易超过 60 秒或 5 分钟。

流式体验也需要后端持续存活

很多 AI 产品会把进度和结果流式返回给前端。后端如果很快超时，前端就只能改成轮询或断点续跑。更长函数让“一个请求持续流式产出结果”的实现空间更大。

哪些任务可以少拆一些

长文档总结和结构化抽取

例如用户上传 100 页 PDF，希望得到摘要、关键条款、风险点、表格提取和 FAQ。以前可能要拆成“上传 -> 队列 -> 解析 -> 轮询 -> 汇总”。现在对于中等规模文档，可以考虑在一个 30 分钟窗口内完成解析与汇总，并通过 streaming 返回进度。

多轮工具调用型 Agent

例如市场调研 agent、代码解释 agent、报表生成 agent，需要多次调用搜索、数据库、内部 API 和模型。30 分钟窗口可以减少状态拆分和重入复杂度。

AI 代码分析和仓库扫描

小到中型仓库的代码理解、风险扫描、README 生成、测试建议，可以在长函数中完成更多上下文读取和分析。但大型 monorepo 仍然建议拆分任务和缓存索引。

长音频或视频的轻量处理

如果任务是转写后的摘要、章节划分、字幕整理、脚本生成，30 分钟可能足够。但真正的视频转码、GPU 推理、批量渲染不应放在普通 Vercel Function 里硬跑。

哪些任务仍然应该拆

超过 30 分钟的后台作业

如果任务本身可能跑 40 分钟、2 小时甚至更久，不要因为 30 分钟上限变长就硬塞进 Function。长时间作业更适合队列、worker、Workflow、定时任务或专门的计算平台。

大规模 fan-out 并行任务

例如要处理 10,000 个文件、扫描整个组织的仓库、批量生成 embedding、批量跑评测。这类任务需要分片、重试、进度记录和并发控制，而不是一个函数从头跑到尾。

强可靠任务

支付、订单、账单、权限变更、数据迁移等任务必须有幂等、事务、重试和审计。即使 30 分钟足够，也不应简单依赖一个长 HTTP 请求完成全部流程。

GPU 或高 CPU 推理

Vercel Functions 更适合 Web 后端、AI 编排、I/O 和外部模型调用。真正重 GPU 推理、模型训练、视频生成、大规模向量计算，仍应交给专门推理服务或计算集群。

架构上可以怎么改

从“强拆状态机”变成“长函数加轻状态”

过去为了避免超时，很多 AI 流程被拆成过多小步骤，每一步写数据库状态，再由前端轮询。30 分钟窗口出现后，中等复杂度任务可以简化为：一次请求启动，后端流式返回进度，必要时把阶段性结果写入数据库。

保留 checkpoint

即使函数可以跑 30 分钟，也要保留关键 checkpoint。例如文档解析完成、embedding 完成、模型初稿完成、最终报告完成。这样即便中途失败，也能从最近节点恢复，而不是全部重跑。

把用户可见进度流式返回

长任务不能让用户盯着空白页面。推荐使用 streaming、Server-Sent Events 或前端进度状态，让用户知道当前在解析、检索、调用模型、校验还是生成报告。

让可重复任务异步化

如果任务结果可以稍后查看，例如夜间批量报告、全库索引、周期性评测，就没必要强行放在一次用户请求里。长函数更适合交互式、用户正在等待的中长任务。

成本和计费要重新算

时间变长不代表成本可忽略

函数能跑更久，也意味着一次错误调用可能占用更长时间。AI 应用还叠加模型费用、检索费用、外部 API 费用和数据库费用。30 分钟窗口给了更大自由度，也放大了失控调用的成本风险。

设置用户级和任务级预算

建议每个长任务都有预算上限：最多调用多少次模型、最多处理多少页文档、最多运行多少工具步骤、最多生成多少 token。超过阈值时，应暂停并提示用户确认。

监控超时和接近超时

不要只看成功率。应记录每次任务耗时、接近 800 秒的比例、接近 1800 秒的比例、失败阶段、重试次数和外部 API 耗时。超过某个阈值后，就说明该任务需要拆分或换架构。

工程落地建议

先从 5 到 15 分钟任务试点

不要一上来就把生产任务拉到 30 分钟。先选择能稳定在 5 到 15 分钟完成的 AI 任务，观察日志、成本、用户等待体验和失败恢复。

给每个长函数加超时保护

即使平台允许 1800 秒，也应该在业务代码里设置更细的阶段超时。例如外部搜索最多 30 秒，单次模型调用最多 120 秒，单个工具调用最多 60 秒。这样能避免某个依赖把整个函数拖死。

把长任务和普通 API 分开

不要让普通读写 API 和长 AI 任务共享同一个 route 和监控口径。长任务应独立命名、独立日志、独立告警，方便定位成本和稳定性问题。

保持幂等

用户刷新页面、网络断开、前端重试、平台重试，都可能让任务重复执行。长任务应有 task id、幂等 key 和状态表，避免重复收费、重复写入或重复发送通知。

和队列 / Workflow 怎么选

优先用长函数的情况

用户正在等待结果，任务通常在 30 分钟内完成，需要持续返回进度，状态拆分成本高，而且失败后可以让用户重试。这类任务适合先考虑长函数。

优先用队列的情况

任务量大、可以异步完成、需要可靠重试、需要并发限制、可能超过 30 分钟、失败后必须自动恢复。这类任务仍应使用队列或 worker。

优先用 Workflow 的情况

任务天然分阶段，例如“抓取 -> 清洗 -> 生成 -> 审核 -> 发布”，并且每一步都需要持久状态、人工审批或单独重试，那么 Workflow 或状态机更适合。

几个典型架构示例

AI 文档分析工具

用户上传 PDF 后，Vercel Function 启动解析、分块、检索和总结，并通过 streaming 返回阶段进度。每完成一个阶段写入数据库 checkpoint。如果接近超时，保存状态并提示用户继续处理。

AI 研究报告生成器

用户提交主题后，函数执行搜索、抓取、来源去重、摘要、结构化写作和引用整理。小报告可以在长函数内完成；深度研究报告仍应拆成多个任务并允许后台继续执行。

AI 编程助手后台任务

对中小型仓库，函数可以读取关键文件、生成风险报告、输出修复建议。对大型仓库，应先建立索引，再让长函数只处理本次相关上下文。

企业知识库问答

长函数适合处理“上传资料后立刻生成知识库摘要”这类交互任务。但全量知识库重建、批量 embedding、定期同步仍应异步化。

不要忽视用户体验

30 分钟不是用户愿意等 30 分钟

平台允许函数跑 30 分钟，不代表用户愿意在页面上等 30 分钟。对于超过 2 到 3 分钟的任务，最好提供进度、取消、后台通知和稍后查看入口。

让用户知道任务在做什么

长任务应拆成用户可理解的阶段：读取文件、提取文本、检索资料、生成草稿、校验结果、输出报告。不要只显示一个转圈动画。

提供取消和恢复

如果用户发现上传错文件或问题写错，应能取消任务。任务失败后，应能从 checkpoint 恢复，而不是让用户重新上传和重新等待。

安全与合规边界

长任务会放大密钥泄露风险

AI 长任务常常访问多个外部 API、数据库和模型服务。不要把密钥写入日志，不要把完整环境变量传给模型，不要让 agent 自由读取不相关文件。

限制工具调用范围

如果函数中运行 agent，要限制它能调用哪些工具、访问哪些数据、写入哪些位置。执行时间变长后，错误工具调用造成的影响也会变大。

记录审计日志

长任务应记录用户、输入文件、调用工具、模型、耗时、输出摘要和错误阶段。涉及企业数据时，还应有数据保留和删除策略。

结论：不用过度拆碎，但仍要设计边界

Vercel Functions 拉长到 30 分钟，对 AI 应用是一个实用更新。它让很多过去被迫拆碎的中长任务可以用更直接的方式实现，尤其是长文档分析、多轮工具调用、流式生成、轻量 agent 和交互式报告。

但 30 分钟不是后台系统的全部答案。超过 800 秒仍是 beta，超过 30 分钟仍会超时，成本和错误影响会被放大。真正稳妥的架构，是把长函数用于用户可等待、可流式、可恢复的中长任务；把队列、Workflow、worker 用于超长、批量、强可靠和高并发任务。

所以答案是：AI 应用终于不用把所有任务都拆得很碎了，但仍然不能放弃任务边界、状态恢复、成本控制和人工可观察性。

FAQ

Vercel Functions 现在真的能跑 30 分钟吗？

根据 Vercel 2026 年 6 月 15 日 changelog，Pro 和 Enterprise 团队的 Node.js 与 Python runtime 可以配置到 30 分钟。超过 800 秒部分仍是 beta，并且需要 Fluid Compute。

Hobby 用户也能用 30 分钟吗？

官方 changelog 提到 Hobby 用户可使用 60 秒执行时长。30 分钟能力面向 Pro 和 Enterprise 团队。

是不是 AI 任务都不用拆队列了？

不是。中长交互任务可以少拆一些，但超过 30 分钟、大规模批处理、强可靠任务和 GPU 推理仍然应使用队列、Workflow、worker 或专门计算平台。

30 分钟适合哪些 AI 场景？

适合长文档总结、OCR 后结构化抽取、多轮工具调用、轻量 agent、研究报告生成、流式输出等通常能在 30 分钟内完成的任务。

maxDuration 应该直接设 1800 吗？

不建议无脑设到最大。应按任务实际需要设置，并在业务代码里增加阶段超时、预算上限、日志和告警。

长函数比队列更好吗？

不是同一类工具。长函数适合用户正在等待的中长请求；队列适合异步、批量、可重试、强可靠或可能超过 30 分钟的任务。

Fluid Compute 是必须的吗？

如果要配置超过 800 秒的执行时长，Vercel changelog 明确要求启用 Fluid Compute。具体项目配置应以 Vercel 最新文档为准。

长函数会不会更贵？

可能。执行时间变长、模型调用更多、外部 API 更多，都会增加成本。应设置任务预算、用户限额和监控告警。

参考来源

本文事实信息参考 Vercel 官方 Vercel Functions can now run up to 30 minutes、Functions duration docs、Fluid Compute docs 和 Functions runtimes docs。执行时长、计划限制、beta 状态和计费规则可能继续变化，正式上线前请以 Vercel 最新官方页面为准。