部署 Agent 的难点不是「把服务跑起来」，而是：长任务怎么不超时、并发上来怎么不崩、成本怎么不失控、出问题怎么回滚。
参考架构
不是每个项目都需要全部组件。但只要你做长任务或高并发，队列/工作流和数据层迟早要有。
同步、流式与异步
| 任务时长 | 方式 | 实现 |
|---|---|---|
| < 5 秒 | 同步 JSON | 普通 HTTP |
| 5–30 秒 | 流式 | SSE / WebSocket |
| 30 秒–数分钟 | 异步任务 | 返回 task_id，轮询/推送 |
| 数分钟–数天 | 工作流 | 持久化执行 + 通知 |
经验法则：用户等待超过 10 秒，就应该给进度反馈；超过 30 秒，就应该异步化。
流式输出要注意：
- 首 token 之前先发一个
status事件，避免界面空白； - 工具调用时发送
tool_start/tool_end事件； - 错误要在流里发送，而不是直接断开；
- 客户端要能重连（带 last_event_id）；
- 代理层（Nginx、CDN）要关闭缓冲。
无状态与有状态
无状态 API + 外部状态最容易扩展：
请求 → 加载 state → 执行一步 → 保存 state → 返回每一步都可以落到任意 worker，崩溃后可恢复。缺点是每步都要读写存储。
有状态会话（如 Durable Objects）适合：
- 需要 WebSocket 长连接；
- 多步任务需要强一致的状态；
- 需要定时器/调度；
- 同一会话串行处理。
选择取决于一致性需求与扩展方式。不要用进程内内存保存任务状态——部署、重启、扩容都会丢。
队列与工作流
长任务放进队列：
API → 创建 task（status=queued）→ 入队 → 返回 task_id
Worker → 消费 → 执行 → 更新 status/progress → 通知要点：
- 幂等消费：消息可能重复投递；
- 可见性超时：处理时间超过租约会被重新投递；
- 死信队列：多次失败后人工处理；
- 进度上报：用户能看到「第 3/6 步」；
- 取消：用户取消后，worker 要能停止；
- 优先级：付费用户/紧急任务单独队列。
工作流（Temporal、Cloudflare Workflows 等）进一步提供持久化、补偿、跨天等待。
并发与限流
三层限流：
- 入口：每用户/租户 QPS、并发任务数；
- 模型：每分钟 token、请求数，避免触发供应商 429；
- 工具：每个下游独立并发池，避免拖垮。
limiter = TokenBucket(rate=60, burst=10) # 每用户
if not limiter.allow(user_id):
return 429, {"retry_after": limiter.retry_after(user_id)}并发不是越高越好。Agent 的每次请求可能持续几十秒，占用连接和内存。按「同时进行的任务数」而不是 QPS 估算容量。
缓存
| 缓存 | 内容 | 失效 |
|---|---|---|
| 提示缓存 | 系统提示、工具定义 | 内容变化 |
| 检索缓存 | query → 文档 ID | 文档更新 |
| 工具缓存 | 只读查询结果 | TTL / 事件 |
| 语义缓存 | 相似问题 → 答案 | 谨慎，需校验 |
| 会话缓存 | 最近消息 | TTL |
语义缓存风险最高：两个问题「看起来相似」但答案不同（例如不同订单），会返回错误结果。至少要带 scope 过滤和相似度阈值。
容量估算
并发任务数 = 峰值 QPS × 平均任务时长
模型并发 = 并发任务数 × 平均每任务模型调用数 / 平均调用时长例：峰值 20 QPS，平均任务 30 秒 → 600 个并发任务。如果每个任务 5 次模型调用、每次 3 秒，模型侧并发约 1000。这通常会超过供应商配额，需要排队、限流或分批。
不要只看平均。P95 任务可能跑 3 分钟，长尾会占住资源。
SLO
定义可测量的目标：
- 可用性 99.9%；
- 同步请求 P95 < 8 秒；
- 异步任务 95% 在 5 分钟内完成；
- 任务成功率 > 90%；
- 单任务成本 < 0.5 元；
- 安全拦截零漏报（对已知攻击集）。
SLO 要能驱动架构决策。例如「P95 < 8 秒」可能要求跳过重排、限制步数、流式输出。
发布与回滚
Agent 的「版本」包括：
- 代码；
- 提示词；
- 模型版本；
- 工具 Schema；
- 知识库索引。
发布策略：
- 灰度：5% → 20% → 50% → 100%；
- 影子：新版本只记录不返回，对比质量；
- 开关：按用户/租户启用；
- 回滚：提示词、模型、代码都能一键切回；
- 数据兼容：State Schema 变更要考虑旧检查点。
不要同时改多个变量。一次只改一个，跑完评估再继续。
成本控制
- 每租户预算与配额；
- 单任务硬上限；
- 模型路由；
- 提示缓存；
- 工具结果裁剪；
- 输出长度限制；
- 异常用量告警；
- 按功能/租户拆分账单。
一个实用做法：在 API 层给每个请求打上 tenant_id、feature、prompt_version，账单可以按维度聚合。否则月底只知道「总费用涨了」，不知道从哪来。
部署形态
| 形态 | 优点 | 缺点 | 适合 |
|---|---|---|---|
| Serverless | 免运维、弹性 | 超时、冷启动、状态受限 | 短任务、事件驱动 |
| 容器 | 可控、长任务 | 运维、扩缩容 | 复杂 Agent |
| 边缘 | 低延迟、就近 | 运行时限制 | 轻量推理/编排 |
| 托管平台 | 快 | 锁定、黑盒 | 验证与中小项目 |
混合很常见：边缘/Serverless 接入 + 容器跑长任务 + 托管向量库。
反模式
网关超时、连接断开、用户以为失败。超过 30 秒就异步化。
扩容/重启就丢。状态必须外部化。
供应商 429、成本飙升、下游被打挂。
出问题无法归因。灰度、单变量、可回滚。
Agent 活着但答得不对，也是故障。质量指标要进监控。
检查清单
- 按任务时长选择同步/流式/异步
- 状态外部化，可恢复
- 长任务走队列/工作流，幂等消费
- 三层限流与并发上限
- 缓存有 scope 与失效策略
- 有 SLO 与容量估算
- 发布可灰度、可回滚
- 成本按租户/功能可归因
- 质量指标进监控
- 有降级与人工兜底
小结
- 部署的核心是任务时长、状态、并发与成本，而不是「用哪个云」。
- 超过 30 秒异步化，状态外部化，长任务用队列/工作流。
- 限流分入口、模型、工具三层。
- 版本包括代码、提示、模型、工具、索引，必须能一起回滚。
- 成本要能按维度归因，否则无法优化。
下一篇看一个具体的部署平台：Cloudflare 的 Workers、Durable Objects 与 Agents SDK。