主题
边缘部署 vs 集群部署
你刚写完一个 Agent 原型：前端提交需求，后端调用模型，产物流式返回。本地测试很流畅，但上线后你发现，有的用户点击半天没反应，有的报告生成到一半被中断，而批量跑历史产物评估时，账单直接翻了几倍。这些差异本质上不是模型问题，而是部署位置选错了。
要点
- Agent 项目的部署边界，要从任务生命周期拆起：需求接收、资料召回、结构生成、产物流式输出、审稿改写、交付检查和质量评估，对延迟、运行时和可观测性的要求不同。
- 同步 API、鉴权、轻量状态读取和流式返回适合靠近用户；资料索引、批量审稿、产物评估和 trace 聚合更适合后台 worker 或集群。
- Cloudflare Workers 适合作为边缘入口和轻量调度层，承接「接住请求、校验上下文、转发 token 流、投递后台任务」这类短任务。
- 集群部署的价值在于稳定运行长任务、复用 Python 与浏览器自动化生态、控制并发与重试，并把评估、索引和治理任务放到可观测的执行环境里。
1. 先拆任务请求的延迟预算
Agent 项目里，用户提交的是一条由多个 Agent 协作完成的任务，范围超过单次模型调用。一次任务可能会经历需求解析、资料召回、结构生成、产物流式输出、审稿、改写、交付检查和质量评估。每一步都在消耗时间，但用户对它们的等待预期并不相同。
可以先把链路拆成三类：
| 路径 | 典型任务 | 用户是否等待 |
|---|---|---|
| 同步路径 | 接收需求、鉴权、读取任务状态、触发 Agent 任务、流式返回产物 | 等待 |
| 后台路径 | 写回资料卡片、保存 trace、更新任务事件、聚合质量指标 | 不等待 |
| 离线路径 | 批量重建向量索引、全量质量评估、产物批量审稿、历史产物风格再分析 | 不应在请求内等待 |
边缘部署最适合优化第一类路径。用户打开页面、提交需求、看到产物开始流式输出，这些动作越靠近用户，首字节时间越稳定。第二、第三类路径更关心可靠性、重试、资源控制和成本，放进可观测的后台执行环境更容易排查问题。
2. 边缘部署解决什么问题
传统集群通常部署在少数区域。用户请求要先到某个数据中心，再由服务端调用模型、数据库和工具。对于跨地区使用的产品，网络往返会成为固定成本，尤其会影响任务创建、状态轮询和 token 流转发这几类频繁动作。
边缘部署的思路是把轻量计算放到离用户更近的节点。以 Cloudflare Workers 这类平台为例，Agent 项目可以把下面几类能力放在边缘：
- API 网关：鉴权、限流、参数校验、路由。
- 轻量编排：选择任务模板、读取任务状态、生成任务事件、调度下游服务。
- 流式返回：把模型或后台服务的 token 流转发给前端。
- 边缘缓存：缓存项目配置、风格摘要、公开资料摘要和低频变更的配置。
- 异步触发：通过队列或后台任务启动资料写回、trace 持久化和指标聚合。
这些任务的共同点是：执行时间短、资源占用低、与用户请求强相关。
从实现机制上看，主流边缘平台通常基于 V8 isolate 或类似的无容器运行时。以 Cloudflare Workers 为例，单个 isolate 的启动时间以毫秒计，内存占用也远低于传统容器，这让入口层在处理短时任务时往往可以避免传统 serverless 数秒级的冷启动。Vercel 的 Fluid Compute 则通过让多个并发请求共享同一个实例，并把计费粒度从墙钟时间改为实际 CPU 活动时间，进一步降低了入口层在流式场景下的延迟和成本。换句话说，边缘真正的优势不是「无限算力」，而是「请求入口离用户近、启动快、按实际活跃计算计费」。
3. 集群部署仍然有必要
Agent 系统里也有很多任务不适合放到边缘：
- 批量抓取网页并清洗正文。
- 对大量历史产物重新切 chunk、生成 embedding，更新检索索引。
- 对整批产物跑质量评估。
- 使用 Python 生态处理复杂文档、PDF、NLP、浏览器自动化或模型推理。
- 运行需要较长时间、较大内存或本地依赖的任务。
这些任务更适合在集群、容器平台或专门 worker 上运行。它们追求的是可控、可重试、可扩容和可观测。对 Agent 项目来说，后台执行环境还要保存完整 trace，方便定位是资料召回、Prompt 组装、审稿规则还是模型输出造成了质量波动。
从 Kubernetes 的工程实践看，它提供了容器编排、GPU 节点调度、基于队列深度的 HPA 以及 Jobs/CronJobs 等机制，适合运行需要持续在线、长生命周期或批处理的 Agent 任务。例如，批量抓取 500 篇文章、清洗正文、重建向量索引并重新评估产物质量，这类任务天然适合用 Kubernetes Jobs 或「消息队列 + KEDA 伸缩」的 worker 来执行，因为它们有明确的重试边界、资源隔离和完成状态。此外，把推理引擎（如 vLLM）部署在专门的 GPU 节点池上，并通过节点亲和或污点隔离，也能让高吞吐模型服务获得更稳定的延迟。
边缘和集群可以按任务的等待关系组合起来：
txt
浏览器
-> 边缘 API（Hono / Workers）
-> 同步读写轻量状态
-> 调用模型网关或 Agent 编排服务
-> 流式返回产物
-> 投递后台队列
-> 后台 worker / 集群
-> 资料索引
-> 批量审稿
-> trace 与指标聚合
-> 长任务重试4. Agent 项目里的部署边界
可以按下面的表来做第一版边界设计：
| 模块 | 推荐位置 | 原因 |
|---|---|---|
| 用户请求入口 | 边缘 | 降低首字节时间，统一鉴权和限流 |
| 任务状态读取 | 边缘 + 就近存储 | 页面刷新、断线恢复和流式续写需要低延迟 |
| Prompt 组装 | 边缘或轻量编排服务 | 依赖资料大小；上下文过大时转到编排服务 |
| LLM 流式代理 | 边缘 | 适合转发 token 流，减少前端等待感 |
| 资料检索 | 边缘调度 + 专用检索服务 | 查询可近端发起，索引维护放在后台更稳 |
| Agent 任务编排 | 轻量服务或集群 | 需要管理步骤、状态、失败分类和重试 |
| 批量向量化 | 后台 worker / 集群 | 计算重、耗时长、需要重试 |
| 全量审稿评估 | 后台 worker / 集群 | 不应阻塞用户请求，需要保留评估结果 |
| trace 写入 | 边缘采样 + 后台持久化 | 避免主路径等待存储写入，同时保留排查证据 |
这张表的重点是：边缘负责「接住用户、尽快响应、稳定转发」；后台负责「慢工作、重工作、可重试工作」。Agent 编排层位于两者之间，它既要响应用户任务，也要把长步骤拆给后台 worker。
5. 什么时候选择边缘优先
满足下面条件时，可以优先把 API 层放到边缘：
- 用户分布在多个地区。
- 前端需要流式展示生成结果。
- 请求里有较多轻量状态读取、鉴权、路由和任务事件写入逻辑。
- 后端主要是调用外部模型、检索服务和工具，而不是本地重计算。
- 团队希望用 TypeScript 贯穿前后端和共享 schema。
Agent 项目的同步链路通常符合这些条件。用户提交需求后，系统可以先在边缘完成校验、任务创建和流式代理，再把资料写回、质量评估和索引更新交给后台服务。
不过，选择边缘优先时也要检查运行限制。例如，Vercel Edge Functions 需要在 25 秒内开始发送响应，虽然后续可以流式输出最长 300 秒；Cloudflare Workers 的单个请求也有执行时间上限。对于需求解析、鉴权、任务创建和 token 流转发这类短时动作，这些限制通常不构成问题；但如果 Agent 需要连续思考很多轮或调用重型工具，仍然要把重活交给后台执行环境。
6. 什么时候选择集群优先
如果项目有下面特征，集群或容器平台会更合适：
- 需要长时间运行的任务。
- 依赖 Python 数据处理、机器学习库或浏览器自动化。
- 需要访问内网资源、私有数据库或复杂文件系统。
- 对 CPU、内存、GPU 有明确需求。
- 需要对任务队列、并发、重试和工作负载做细粒度控制。
- 需要把评估结果、trace、失败样本和人工审稿记录汇总到同一套治理任务里。
例如，批量抓取 500 篇参考文章、清洗正文、重建检索索引并重新跑审稿评估，就不适合放在用户请求路径上，也不适合只靠边缘函数完成。它需要明确的任务队列、重试策略、资源限制和失败样本记录。
成本上也有一个经验参考：当流量较低或不稳定时，serverless 按请求/按 token 计费可以避免空闲成本；但当流量持续稳定且规模扩大时，Kubernetes 的固定节点成本往往会被摊薄。Latitude 的分析指出，在每天约 1 亿到 2 亿 token 的区间附近，Kubernetes 可能开始比 serverless 更经济。这个数字会因模型大小、GPU 利用率、人员运维成本等因素而变化，所以不要把它当作绝对阈值，而是作为成本估算的一个锚点。
7. 小结
Agent 项目的部署策略，可以概括成一句话：边缘处理请求入口和流式体验，后台处理重任务和长期治理。
这条边界由链路拆分决定：用户正在等待的部分尽量靠近用户，用户不等待的部分放到更可控的执行环境里。现实中，很多团队采用混合架构：用边缘或 serverless 处理入口和流式体验，用 Kubernetes 集群处理后台重任务与长期治理。对 Agent 项目而言，部署选型最终服务于三件事：让产物更快出现，让长任务可重试，让质量问题能通过 trace 和评估结果继续追踪。