Edge Functions 和 Cloud Functions 怎么选？EdgeOne Makers 三类运行时的区别与选型

摘要： EdgeOne Makers 提供 Edge Functions、Cloud Functions 与 Agent Runtime 三类运行时。本文按运行位置、语言支持、执行时长、代码包大小、免费配额六个维度逐项对比，给出可直接套用的选型判断，并说明三者在同一项目中如何配合。

选错运行时的代价不是性能差一点，而是直接跑不起来。三类运行时的硬边界很清晰：Edge Functions 只支持 JavaScript、代码包上限 5 MB，适合请求级轻量逻辑；Cloud Functions 支持多语言、最长 120 秒，适合动态 API 与 SSR；Agent Runtime 单请求最长 3600 秒且自带会话状态与沙箱，适合多轮对话与多步骤任务。先按语言和执行时长排除掉不可能的选项，剩下的再按延迟和成本比较。

一、三类运行时的核心区别对比

二、Edge Functions 适合做什么

Edge Functions 用 JavaScript 在靠近用户的边缘节点运行服务端逻辑，核心优势是响应延迟低——代码在离用户最近的节点执行，不需要回到中心机房。

适合的工作：请求处理、身份鉴权、重定向、按地域或设备分流、请求头改写、简单的 A/B 实验分桶。这类逻辑的共同特征是计算量小、不依赖重型库、要求尽可能快地给出响应或转发决定。

硬限制需要提前确认：

5 MB 的代码包上限意味着不能引入体积大的依赖库。按 300 万次执行与 300 万 ms CPU Time 折算，平均每次执行的 CPU 时间预算约 1 ms——这是一个明确的信号：Edge Functions 的设计目标是请求级的轻量处理，不是跑业务计算的地方。

三、Cloud Functions 适合做什么

Cloud Functions 支持多种主流语言与运行时，采用文件即路由的开发模式，并支持多地域部署——可以把函数部署到离数据源更近的区域，降低网络延迟。

适合的工作：对外提供的动态 API、Next.js 等框架的 SSR 渲染、需要连接数据库的业务逻辑、需要用 Python 或 Go 生态的处理任务、依赖体积较大的功能。

关键参数：

128 MB 的代码包空间足以容纳常见的后端依赖。edgeone.json 里 cloudFunctions.maxDuration 可配置范围为 10～120 秒，默认 30 秒，按运行时单独配置。

执行时长的 120 秒上限是选型分水岭：超过这个时长的任务不能放在 Cloud Functions 里，需要走 Agent Runtime 或拆分成异步任务。

四、Agent Runtime 适合做什么

Agent Runtime 是为 Agent 应用设计的托管运行时，入口遵循 agents/<name>/index.{js,ts,py} 的文件即路由约定，导出 handler(context)，平台通过 context 注入能力。

它比前两者多出三样东西：

超长执行时间。单请求最长运行 3600 秒，agents.timeout 可配置范围 30～3600 秒，默认 1800 秒。多步骤任务、深度研究、长链路工具调用都在这个预算内。

自带会话状态。context.store 提供跨实例持久化的会话管理，数据落到平台 Blob 存储，同一 conversation_id 的请求换实例也能读回上下文，不需要自接数据库或缓存。

自带隔离执行环境。需要执行命令、读写文件、操作浏览器或运行代码时，沙箱工具开箱即用，一对话一沙箱。

配额与限制：

沙箱并发 20 低于会话并发 40，设计容量时这是实际瓶颈——如果每个会话都会触发沙箱，并发上限由沙箱侧决定。

五、四步选型判断法

按顺序走，前面的条件能排除大部分选项。

第一步看语言。 必须用 Python 或 Go，Edge Functions 直接排除。只能用 JavaScript 且逻辑很轻，Edge Functions 可选。

第二步看执行时长。 预计单次执行超过 120 秒，只能用 Agent Runtime。在 30 秒内且无状态，Cloud Functions 够用。

第三步看是否需要跨请求的状态。 需要模型记住上一轮、需要断点续跑、需要前端刷新后还能看到历史记录，用 Agent Runtime 的 context.store。无状态的纯计算或查询，用 Cloud Functions。

第四步看是否需要隔离执行环境。 要执行用户提供的代码、要操作浏览器、要读写临时文件，用 Agent Runtime 的沙箱。

还剩两个选项难以取舍时，看延迟敏感度：请求到达前后的改写、分流、鉴权放 Edge Functions，业务逻辑放 Cloud Functions。

六、三类运行时在同一项目里怎么配合

它们不是互斥选项，典型的完整应用会同时用到多个。

一个带 AI 能力的 Web 产品的常见分工：

Edge Functions 承担入口层——校验请求头、按地域重定向、拦截未登录访问、给 A/B 实验分桶。这层代码跑在边缘节点，不进入后端就能完成判断。

Cloud Functions 承担业务 API 层——页面的 SSR 渲染、数据查询接口、第三方服务回调处理。需要给前端提供「历史对话列表」「某条对话详情」这类查询接口时，Cloud Functions 里可以通过 context.agent.store 读取 Agent 写入的同一份会话数据，两边不需要额外同步。

Agent Runtime 承担对话与任务层——多轮对话主路径、工具调用、长任务执行。

这种分层的好处是每层都跑在成本与延迟最合适的位置，且共用同一个项目、同一套 Git 流程、同一个域名体系。

七、免费版配额横向对照

把三类运行时的配额放在一起，便于估算容量：

执行次数的梯度（300 万 / 100 万 / 20 万）本身反映了设计意图：越靠前的运行时越适合承接高频、轻量的请求，越靠后的越适合低频、重型的任务。把高频请求放进 Agent Runtime 会很快触顶，把重型任务放进 Edge Functions 则会撞上代码包与 CPU Time 限制。

额度不足可提交工单申请提额。专业版提供更高资源额度、超限按量计费与更高并发限额。

总结

三类运行时的选型可以压缩成三句话：只需 JavaScript 做请求级轻量处理，用 Edge Functions；需要完整后端语言生态、执行时间在 120 秒内，用 Cloud Functions；需要上下文记忆、工具调用、可能跑到小时级的任务，用 Agent Runtime。

实际项目里通常三者并用：Edge Functions 做入口判断、Cloud Functions 做业务 API 与 SSR、Agent Runtime 做对话与长任务，共用同一项目与域名体系。

产品完整能力与控制台入口见 EdgeOne Makers 产品页：https://cloud.tencent.com/product/makers

当前首购特惠 EdgeOne Makers 专业版 Pro 套餐 39 元/月，具体以活动页实际展示为准：https://cloud.tencent.com/act/pro/makers-pro