最近在折腾 AI Agent 项目用 Evibe 搭了一套应用层的壳子整体体验相当顺。但真正让我停下来思考的反而是上线前那个看似基础的问题项目该往哪儿发Evibe 提供了 Agent 内置发布同时又能接 Vercel 和 Cloudflare Pages这三条路到底有什么本质区别网上聊这个问题的内容大多只停留在“都能部署网站”的层面很少讲透背后的架构差异和适用边界。我花了两个晚上把三条链路都实测了一遍这篇就把我在实际项目中踩过的坑、对比过的数据、以及最终的选型逻辑一次性说清楚希望能帮你少走弯路。1. 先理清楚这三个发布选项分别是谁给你的1.1 一句话定位发布方式不同意味着你托管应用的位置和方式完全不同先说结论性的定位Vercel 和 Cloudflare Pages 是外部托管平台Evibe 把项目打包后推送上去由它们负责跑你的前端资源和边缘函数而 Agent 内置发布是 Evibe 自己的一套托管机制项目不出 Evibe 的平台域由平台直接对外提供服务。很多人会把“部署”理解成“把文件传上去”其实在 AI Agent 场景下部署的复杂度远不止静态文件它涉及到服务端函数、鉴权、流式响应、数据库连接等一堆周边设施。你选的发布方式决定了这些能力由谁来提供、怎么提供、以及你能控制到什么程度。拿我的项目举例一个给内部团队用的客服 Agent前端是 React 套件后端逻辑里有一个 API 路由用来转发大模型请求、做流式输出同时还要处理会话历史。这个结构看起来简单但真要上线你会发现“前端跑在哪”只是最小的问题真正的关键是“API 路由跑在哪”“边缘节点怎么处理超时”“日志去哪看”。这三条发布路径本质上是把这些问题交给了不同的处理者。Vercel 交给了 Vercel 的 Serverless FunctionsCloudflare Pages 交给了 Pages Functions 和 Workers 运行时而 Agent 内置发布则交给了 Evibe 的平台运行时。搞清楚这一点后面所有的对比都有了解释框架。1.2 从部署链路看三者差异不是“放上去”那么简单完整走一遍你就明白了。Vercel 的部署链路是你在 Evibe 里配置好 Git 仓库或上传构建产物Evibe 调用 Vercel 的 API 创建项目把构建后的文件推上去然后 Vercel 生成一个*.vercel.app域名所有流量都走 Vercel 的全球边缘网络。Cloudflare Pages 链路类似但推送目标换成了 Cloudflare域名变成*.pages.dev而在函数能力上Pages 会把你项目里的functions目录编译成 Pages Functions跑在 Cloudflare 的 Workers 运行时上。Agent 内置发布则完全不一样你不需要注册 Vercel 或 Cloudflare 账号也不需要配置任何外部平台的 token。Evibe 在平台内部会启动一个隔离的运行时环境把你的 Agent 应用容器化跑起来然后给你一个 Evibe 域名的公开访问地址。你只需要点“发布”按钮剩下的事情平台包办。这三条链路最大的区别在于你自己持有多少基础设施控制权。Vercel 和 Cloudflare 都是独立的外部平台你可以在它们后台看到请求日志、设置域名、配置缓存策略甚至把项目导出迁移到其他地方而 Agent 内置发布更像“托管到底”的模式控制台能力相对有限你是在一个黑盒里使用。2. Vercel 发布全栈前端方案AI 应用的最常见归宿2.1 Vercel 到底强在哪里从边缘函数到流式响应的完整配套Vercel 在 AI 应用生态里的地位几乎像默认选项。很多人选择它并不是因为名气大而是它的大多数组件天生就是为前端全栈应用设计的尤其是边缘函数对 AI 场景的适配度相当高。我一个很深的感受是Vercel 对“流式响应”的支持非常成熟。做 AI Agent 项目的人都知道大模型接口返回内容时用户希望看到打字机式的逐字输出而不是等待十几秒后一次性出现。Vercel 的 Serverless Functions 支持流式响应配合前端项目里的ReadableStream你可以很轻松地实现一个实时输出效果。还有个细节是 Vercel 的增量部署和预览链接。每次你从 Evibe 发布更新Vercel 会自动生成一个独立的预览 URL你可以先自己点开看看效果再决定要不要切到正式域名。这个对于 Agent 这类需要反复调对话效果的项目来说实在太重要了我平时调 prompt 都是先发预览链接直接在真机环境里测试而不是等全部改完再上线。Vercel 全球边缘网络的节点覆盖也比较均匀国内访问虽然谈不上快但上海、杭州这些地方的实测响应在 800ms 左右对一个依赖后端 AI 接口的应用来说是可以接受的。2.2 在 Evibe 场景下用 Vercel 发布有什么值得特别留意的如果你在 Evibe 里走 Vercel 发布首先要在 Vercel 后台生成一个 Access Token然后把这个 Token 配到 Evibe 的部署设置里。这一步本身不难但有一个容易忽略的地方Vercel 的 Token 有权限范围建议只给它分配projects相关的读写权限不要图省事直接勾全部权限防止泄漏之后被人拿来操作你所有项目。另一个值得注意的点是环境变量管理。AI Agent 项目通常需要存各种 API Key我在 Evibe 里配置完环境变量后Evibe 会把它们注入到构建阶段但如果你在 Vercel 后台也配置了一份同名的环境变量后者的优先级会覆盖前者。我一开始没留意结果本地调试用 Key A线上跑的是 Key B排查了大半天才找到原因。还有一点必须提Vercel 的 Serverless Functions 默认执行超时限制对 AI 场景不够友好。免费版和 Hobby 计划的函数超时是 10 秒到 60 秒不等假如你的 Agent 逻辑里有多轮工具调用累计耗时很容易超过这个限制。我的做法是尽量把单次请求的耗时控制住比如把工具调用的超时时间调低让 90% 以上的请求能在十几秒内返回完整结果。2.3 Vercel 方案的隐性成本与限制免费额度用完之后才是真正的考验Vercel 的免费额度看起来很大方但如果你的 Agent 项目访问量上来了免费额度会消耗得快得超乎想象。Hobby 套餐每个月包含 100GB 的带宽和一定量的函数调用时长听起来不少但一个带流式输出的对话页面单次会话可能就会产生几 MB 甚至几十 MB 的流量遇到稍微重度一点的用户一个月跑掉几十 GB 很正常。我原先以为免费的够用结果项目上线第二周一天之内带宽就用掉了 40%。后来我是把前端静态资源放 Vercel高频的 Agent 请求改走其他方式才把额度省下来。这个事给我的教训是选型时不能只看“免费”要估算你的场景下带宽会怎么增长Vercel 的收费在量上来之后其实不算便宜。另外Vercel 的免费套餐有个容易踩的暗坑部署预览链接有数量限制且会在一定天数后过期。如果你一次迭代很多版本旧链接会自动失效这在协作场景下容易让小伙伴点开发现页面 404。不要慌这是正常行为重新发布一个链接即可。3. Cloudflare Pages 发布边缘优先预算紧张时候的真香选择3.1 Cloudflare Pages 和 Vercel 的底层差异从缓存策略到运行时生态Cloudflare Pages 的底层思路和 Vercel 有本质差异。Vercel 更像“把应用部署到边缘网络的托管服务”而 Cloudflare Pages 是“把静态资源放到全球边缘缓存 函数按需执行”的组合。这意味着 Pages 在处理静态资源的响应速度上非常夸张因为它天然就是 CDN 架构。Pages 的免费额度比 Vercel 更大方无限带宽这个点对个人项目来说吸引力很大。我在迁移一个纯展示型的 Agent 落地页到 Pages 之后流量成本直接降到零响应速度还比之前 Vercel 快了不少可以说花钱最少体验最稳。运行时方面Pages Functions 是基于 Cloudflare Workers 的它的优势是冷启动低、并发能力强而且不需要额外付费就有足够的执行额度。Workers 的免费计划每天有 10 万次请求额度个人项目正常情况下用不完一半。但 Pages 也有它自己的局限最突出的是生态和周边工具相对 Vercel 少一些。比如流式响应的支持也能做到但需要你手动处理ReadableStream的格式不像 Vercel 那边模板和 SDK 都现成再比如 Vercel 的一键集成很多Pages 这边就得自己在 Worker 里写逻辑。3.2 那些文档里不写但实际会踩到的点函数路径与应用框架的兼容问题Pages 最容易出问题的地方在函数路径。Pages Functions 要求函数文件放在项目根目录的functions文件夹里文件名即路由路径。这意味着如果你在 Evibe 里用了某个框架自己的 API 目录结构函数文件路径对不上部署上去之后请求就可能 404。我遇到过的一个典型问题在本地调试时一切正常部署到 Cloudflare Pages 之后Agent 前端能打开但一发消息请求直接返回 404。查了大半天最后发现是 Pages 对functions/api/chat.ts的处理路径和我预期的不一致。解决办法也很简单要么调整函数文件路径要么在_routes.json里显式声明哪些路径走函数处理。另一个坑是 Pages 的静态资源缓存策略比较激进。你改完一行代码发布新版浏览器可能还是拿到旧的 JS 文件页面看起来像“没更新”。Vercel 那边会自动处理带 hash 的文件名Pages 则需要你自己注意版本号。在 Evibe 发布配置里我建议把静态资源的文件名改成带内容的或者每次发版后访问时强制刷新一次 CDN 缓存。3.3 什么场景下优先选 Cloudflare Pages看清你的应用是“轻交互”还是“重计算”我总结下来的判断标准是如果你的 Agent 应用是偏展示型、内容型或者交互逻辑不复杂、主要靠前端调外部 API那 Cloudflare Pages 是性价比最高的选择而如果应用需要复杂的服务端逻辑、多链路的状态维护、以及和框架的强绑定那 Pages 会让你在某些环节多花时间。对我那个客服 Agent 来说它属于重交互、轻计算服务端逻辑其实很薄主要就是转发请求和拼接上下文所以我最后把它从 Vercel 迁到了 Pages效果不错。但你如果做的是那种需要服务端状态会话、长连接、或者有大量后台任务的应用Pages 的 Worker 模型实现起来会比较别扭这时候 Vercel 的 Serverless Functions 体验更友好。4. Agent 内置发布一键出活的背后是一套被托管起来的部署体系4.1 内置发布到底是什么平台域名的托管环境和外部部署有本质区别Agent 内置发布是 Evibe 自己提供的一体化发布能力。你不需要准备 Vercel Token也不需要理解 Cloudflare 的配置在 Evibe 的发布面板点击“发布”平台会自动完成构建、启动、域名分配整个流程最终给你一个xxx.evibe.app之类的平台域名。这套机制对新手来说极其友好几分钟就能把一个 Agent 应用公开到互联网。我当时第一次测试内置发布时从点击按钮到拿到可访问链接前后不超过两分钟这种体验是任何外部部署方案都比不了的。从技术架构上说内置发布很可能用的是容器或沙箱来托管应用平台会做一些基础的负载均衡和域名管理。因为它在 Evibe 自己的基础设施上所以 Evibe 可以直接调用一些内部服务来增强你的 Agent 能力比如平台内置的持久化存储、用户会话管理这些是你在 Vercel 或 Cloudflare 上需要自己另找方案解决的。4.2 内置发布的实时体验快但限制也明显我实测下来内置发布的请求延迟会比外部平台略高一些尤其是在冷启动时有时候首屏加载要等两三秒。这个热度差异其实不难理解平台托管要考虑多租户隔离冷启动优化空间有限而 Vercel 和 Cloudflare 的边缘节点就在离用户更近的位置客观上有优势。限制方面最明显的是域名绑定。内置发布通常只能用平台提供的二级域名如果你想用自己的域名需要看平台是否支持 CNAME 绑定。更麻烦的是一些企业级场景里对固定出口 IP 有要求内置发布如果没法保证这一点集成就很困难。还有一个容易忽略的问题内置发布的可观测性。外部平台有完整的访问日志、性能监控、告警通知你出事能查到线索而内置发布控制台通常只会给你一个最基本的“应用是否存活”的状态出了问题你只能靠应用本身的日志去猜。做个人演示项目没问题但一旦项目进入生产阶段这点会让你相当难受。4.3 内置发布的适用人群适合验证想法但长期项目要慎重我的判断是Agent 内置发布最适合两类人一类是想快速验证产品想法、还不确定要不要投入精力做的早期阶段另一类是完全不懂部署的小白只是想把自己的 Agent 作品分享给朋友看看。但如果你打算长期运营甚至要接入付费、要做 SEO、要接入第三方服务那我建议尽快迁到外部平台。原因很简单可迁移性差。内置发布的应用你可能拿不到完整的日志和监控数据也不好迁移到别处一旦哪天你打算把项目迁到自己的服务器出口会比较痛苦。我自己的经验是早期用内置发布跑 MVP验证了确实有价值之后两周之内就把整个应用迁移到了 Cloudflare Pages 上。迁移过程其实不难但如果一开始就部署在外部平台后面还能省掉一次折腾。5. 三套方案全方位对比与决策清单5.1 一张表看明白核心差异费用、网络、运行时、控制权为了让你看得清楚我把自己实测的数据和体验整理成了表格方便对比对比维度VercelCloudflare PagesAgent 内置发布部署方式推送到 Vercel 边缘网络推送到 Cloudflare CDN平台容器托管免费额度100GB 带宽/月无限带宽平台自带无单独计费函数能力Serverless FunctionsPages FunctionsWorkers 运行时平台内置运行时冷启动速度中等较快中等偏慢流式响应支持完善支持但需手动处理视平台实现而定自定义域名支持支持有限支持日志与监控完善完善基础适用人群全栈开发者强调性价比的开发者新手、快速验证这张表最核心的信息在于“函数能力”这一行你的应用是否依赖服务端逻辑直接决定了该看哪几行。如果纯静态落地页五秒能搞定一旦有后端逻辑你就得开始纠结函数运行时和冷启动这些事。5.2 按项目类型快速选型对号入座不纠结按照我这些年见过的情况项目类型和发布方案大致可以这么对应个人博客、作品集、App 落地页Cloudflare Pages免费额度大响应快毫无负担。带 AI 对话、流式输出的 Agent 应用Vercel模板和周边生态最省心尤其适合 Next.js 类的全栈项目。想要快速把实验性 Agent 分享给朋友、客户看效果Agent 内置发布点一个按钮就完事。有企业合规要求需要日志审计、数据库私有化部署三者都不够建议直接用云服务器自建但这是另一个话题了。这套对应关系并不是绝对的但它能帮你快速排除掉大部分纠结选项。我自己在做的项目本质上是“带交互的 Agent 应用”所以我最终选择了 Cloudflare Pages 加一层外部 API 网关的组合兼顾了速度和成本。5.3 组合拳思路不是非得三选一混着用才是高手其实还有一个很多人没注意到的地方三者不是互斥的。我在实际项目中经常做的是“双通道策略”正式环境用 Cloudflare Pages临时演示用 Agent 内置发布两者面向不同的访问人群。这个思路的好处是内置发布给你一条极速通道来验证改动而 Pages 那边的正式链接不受影响。尤其是你每次改完 prompt 或者 Agent 行为逻辑先在内置发布上测一轮确认对话内容没问题再同步到正式环境这样容错率高很多。另外还有一个进阶玩法把前端静态资源放 Cloudflare Pages把 Agent 逻辑封装成独立服务部署在 Vercel然后通过 Pages 的函数转发请求。这样你拥有 Pages 的免费带宽又享受到 Vercel 对 API 生态的完善支持缺点是架构复杂度上来了。如果你只是做个人项目我不建议一上来就搞这种组合先把一套方案跑通更重要。6. 常见问题与实操避坑6.1 为什么我部署成功了但访问链接打不开命中的高频问题之一这个问题在三个平台都遇到过最常见的原因有三个一是构建产物缺失比如你忘了把dist目录设置成输出目录平台部署上去的是个空壳二是函数路径不对尤其是 Cloudflare Pages 的functions目录结构问题三是环境变量缺失导致运行时直接报错。排查思路也很直接先在平台自带的后台看构建日志确认有没有报错然后在本地模拟生产环境跑一次把环境变量都配齐了测一轮最后用浏览器的开发者工具看网络请求是 404 还是 500基本就能定位到原因。6.2 部署之后日志、权限、域名、环境变量、自定义配置经常出问题的根源我遇到最多的场景集中在两个方面环境变量管理不统一以及自定义域名配置不规范。环境变量的问题根源在于Evibe、部署平台、你的本地环境是三套独立的配置存储。你常常在本地配了一遍在 Evibe 又配了一遍Vercel 后台可能还有一份三份配置很容易不一致。我的习惯是只保留一个真源所有环境变量统一在 Evibe 的发布配置里维护部署平台后台不再手动添加这样能避免很多莫名奇妙的线上问题。域名配置上如果你要用自己的域名记得在平台里做 CNAME 解析之外还要等 SSL 证书自动签发这个过程有时候需要几分钟。有人刚配置完就打不开其实是证书还没生效等五分钟再访问就好这不是故障。6.3 遇到雾里看花的报错信息我的四个排查步骤不管用哪套发布方案遇到报错不要慌按这个顺序排查基本能解决大半问题看构建日志构建阶段报错占一半以上平台控制台里的日志是最直接的信息源。看运行时日志构建成功但请求报错说明是运行时问题去平台后台看函数日志。本地复现把生产环境变量抄到本地跑一遍同样的逻辑能复现就能调试。简化问题如果请求链路太长先用一个最简单的hello world接口打在线上测通了再逐步加逻辑。这套流程帮我处理过不少疑难杂症尤其是第四步说穿了就是“二分法”但真的能省下大量排查时间。6.4 结合我自己的项目给出最终建议做了这么多对比和实测回到最初的问题我的最终建议是如果你刚接触 Evibe只是想把一个 Agent 想法快速跑起来看效果直接用 Agent 内置发布别折腾外部平台当你跑了一段时间确认这个项目值得长期维护再花半天时间迁到 Cloudflare Pages 或 Vercel。至于在 Pages 和 Vercel 之间怎么选看你的应用负载。重前端、轻后端选 Cloudflare Pages能省下不少流量费用前后端逻辑都复杂选 Vercel周边工具链成熟开发效率更高。这两个平台迁移成本都不高先上车再说后换也不亏。我之前有个项目就是先在 Vercel 上跑了一个月后来发现流量大头全在静态资源上于是把前端直接搬到了 Cloudflare PagesAPI 层继续留在 Vercel。这样组合下来月成本接近零访问速度还更快了。这些都是可以慢慢优化的最重要的是先发布出来让你的 Agent 被真实用户用起来你才会知道下一步该怎么走。
