工程化：部署、监控、成本优化
工程化：部署、监控、成本优化
Agent 做出来只是第一步，上线运行还要考虑部署架构、稳定性、监控告警、成本控制。这篇讲 Agent 的工程化落地：服务部署、流式输出、并发处理、监控指标、成本优化、错误重试、版本管理。
大家好，我是黒漂技术佬。
Demo 好做，生产环境难。Agent 跑通了不代表就能上线，还要考虑：高并发撑不撑得住、出了问题能不能发现、一个月花多少 API 钱、出故障了怎么回滚……
这篇讲 Agent 的工程化：部署架构、监控、成本优化、错误处理、版本管理。
一、部署架构
基础架构
用户 → 前端/聊天界面 → Agent 后端服务 → 大模型API ↓ 向量数据库 工具服务（搜索、数据库等）服务形态
1. API 服务
封装成 HTTP API，前端调用。推荐 FastAPI + Python，大部分 LLM 框架都是 Python 的，对接方便。
2. 流式输出（SSE）
Agent 执行时间长，不能让用户一直等。用 Server-Sent Events 流式返回，边想边输出，用户体验好很多，不会以为卡住了。
3. WebSocket
双向通信，适合实时对话场景。比 SSE 复杂一点，但功能更强。
并发处理
- 异步框架：用 asyncio + FastAPI，异步处理请求
- 连接池：HTTP 客户端用连接池，复用连接
- 队列 + Worker：请求丢队列，Worker 慢慢处理，前端轮询或者推送结果
- 限流：按用户/按接口限流，防止被刷爆
无状态设计
服务做成无状态的，方便水平扩展。用户会话存在 Redis 或者数据库里，不存内存。
二、监控指标
上线了不监控，出问题都不知道。
核心指标
1. 业务指标
- 对话量：每天/每小时多少对话
- 任务成功率：成功完成的比例
- 用户满意度：点赞/点踩比例
- 转人工率：Agent 解决不了转人工的比例（客服场景）
2. 性能指标
- 平均响应时间：从提问到给出答案的总时间
- 首字延迟：多久开始输出第一个字（流式场景）
- 平均步数：完成一个任务平均几轮
- P95/P99 延迟：长尾耗时
3. 成本指标
- 总 token 消耗：每天/每月
- 平均每对话 token：单次对话消耗
- 工具调用次数
4. 错误指标
- 错误率：请求失败比例
- 工具调用失败率
- 超时率
- 常见错误类型分布
告警
关键指标异常要告警：错误率突增、响应时间飙升、token 消耗异常、下游 API 挂了。
三、成本优化
大模型 API 不便宜，Agent 多轮调用更贵。做好优化能省不少钱。
1. 模型选型
不是所有场景都要用最贵的模型。
| 场景 | 推荐模型 | 理由 |
|---|---|---|
| 简单问答、分类 | 小模型/便宜模型 | 足够用，省钱 |
| 工具调用、推理 | 中等模型 | 能力够用 |
| 复杂规划、长任务 | 大模型 | 能力强，减少出错反而省钱 |
策略：简单任务用小模型，复杂任务升级大模型。可以做路由，先让小模型试，搞不定再换大的。
2. 缓存
相同的问题不要重复调用模型。
- 语义缓存：问题相似就直接返回之前的答案
- 工具结果缓存：相同的搜索查询、相同的数据库查询，缓存结果
- Prompt 缓存：有些模型支持 Prompt 缓存，系统提示词部分不重复计费
缓存命中率高的话，能省很多钱。
3. 上下文压缩
- 历史对话做摘要，不用全量传
- 工具返回结果做摘要，只保留关键信息
- RAG 检索结果 rerank 之后只留最相关的几条
- 长文档先总结再给模型
上下文越短，token 越少，越快越便宜。
4. 减少步数
- 优化 Prompt，让 Agent 一步到位，少绕路
- 并行工具调用，一轮搞定多个查询
- 简单任务直接回答，不要走 Agent 循环
5. 限制最大步数
防止死循环烧 token，设最大步数上限。
6. 成本监控和告警
- 每天看 token 消耗
- 设置预算上限，超了告警
- 异常消耗及时发现
四、错误处理和重试
常见错误
- 大模型 API 报错：限流、超时、服务不可用
- 工具调用失败：第三方服务挂了、参数错了
- 模型输出格式错：Function Calling 返回的 JSON 解析失败
- 超时：某一步执行太久
重试机制
指数退避重试
失败了等一会儿再试，每次等待时间翻倍：1秒 → 2秒 → 4秒 → 放弃。
哪些要重试
- 网络错误、超时、限流 → 重试
- 参数错误、权限错误 → 不要重试，没用
- 格式解析错误 → 可以让模型重新生成一次
降级策略
主路走不通了走备用方案：
- 大模型挂了 → 切备用模型
- RAG 检索失败 → 用通用回答模板
- 工具调用失败 → 告诉用户暂时用不了，换种方式
超时控制
- 每一步设置超时时间
- 整体任务设置最大执行时间
- 超时了返回友好提示，不要一直挂着
友好的错误提示
不要把技术错误抛给用户。比如「抱歉，当前服务繁忙，请稍后再试」。
五、版本管理和灰度发布
为什么需要版本管理
- Prompt 改了效果怎么样？不知道就全量上线，容易翻车
- 模型换了、工具加了，都可能影响效果
- 出问题了要能快速回滚
版本管理
- Prompt 版本化：每次改动存一个版本
- 模型版本：记录用的什么模型、什么参数
- 工具版本：工具列表和描述也纳入版本
- 配置版本：温度、最大步数等参数
灰度发布
新版本先给一小部分用户用，没问题再全量：
- 内部测试 → 自己人先用
- 小流量灰度 → 1% 用户用新版本
- 逐步放量 → 10% → 50% → 100%
- 监控指标 → 效果不好就回滚
A/B 测试
两个版本同时跑，对比效果，数据说话，哪个好用哪个。
六、可观测性
日志
- 每个请求有 trace_id，贯穿全链路
- 记录每一步的输入输出、耗时、token
- 结构化日志（JSON），方便检索
追踪（Tracing）
Agent 多步骤的，要能看到完整链路：每一步的 Thought、Action、Observation、耗时、token。
工具
- LangSmith：LangChain 官方，调试追踪很好用
- Langfuse：开源，功能全
- OpenTelemetry：通用的可观测性框架
- 自建：ELK / Prometheus + Grafana
七、高可用设计
多模型备份
不要只依赖一家大模型服务商。主模型挂了切备用的。
限流和熔断
- 下游 API 限流了，自己这边也要限流，不要一直发请求
- 错误率太高就熔断，暂时停掉，等恢复了再开
兜底回答
实在处理不了的时候，有个兜底回复，别报错给用户。
八、工程化 Checklist
上线前对照检查：
部署
- 无状态服务，可水平扩展
- 流式输出
- 异步处理，不阻塞
- 限流机制
监控
- 核心指标监控（调用量、延迟、错误率、token）
- 告警配置
- 日志完整，有 trace_id
- 链路追踪
成本
- 模型选型合理
- 缓存机制
- 上下文压缩
- 最大步数限制
- 成本监控和预算告警
稳定性
- 重试机制（指数退避）
- 超时控制
- 降级方案
- 兜底回答
- 备用模型
版本
- Prompt 版本化
- 配置版本化
- 灰度发布能力
- 快速回滚能力
九、本篇小结
- 部署架构：API 服务 + 流式输出 + 异步并发 + 无状态水平扩展
- 监控指标：业务指标、性能、成本、错误率，关键指标要告警
- 成本优化：模型分级、缓存、上下文压缩、减少步数、限制最大步数
- 错误处理：指数退避重试、降级策略、超时控制、友好错误提示
- 版本管理：Prompt 和配置版本化、灰度发布、A/B 测试、快速回滚
- 可观测性：结构化日志、链路追踪，每一步都要能回看
- 高可用：多模型备份、限流熔断、兜底回答
- 上线前对照 Checklist 逐项检查，确保工程质量
下一篇是系列收尾实战篇：智能客服 Agent 完整实现，把前面讲的知识全部串起来，做一个完整的智能客服。
我是黒漂技术佬。