工程化:部署、监控、成本优化

📅 2026/7/6 5:18:53
工程化:部署、监控、成本优化
工程化部署、监控、成本优化Agent 做出来只是第一步上线运行还要考虑部署架构、稳定性、监控告警、成本控制。这篇讲 Agent 的工程化落地服务部署、流式输出、并发处理、监控指标、成本优化、错误重试、版本管理。大家好我是黒漂技术佬。Demo 好做生产环境难。Agent 跑通了不代表就能上线还要考虑高并发撑不撑得住、出了问题能不能发现、一个月花多少 API 钱、出故障了怎么回滚……这篇讲 Agent 的工程化部署架构、监控、成本优化、错误处理、版本管理。一、部署架构基础架构用户 → 前端/聊天界面 → Agent 后端服务 → 大模型API ↓ 向量数据库 工具服务搜索、数据库等服务形态1. API 服务封装成 HTTP API前端调用。推荐 FastAPI Python大部分 LLM 框架都是 Python 的对接方便。2. 流式输出SSEAgent 执行时间长不能让用户一直等。用 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方便检索追踪TracingAgent 多步骤的要能看到完整链路每一步的 Thought、Action、Observation、耗时、token。工具LangSmithLangChain 官方调试追踪很好用Langfuse开源功能全OpenTelemetry通用的可观测性框架自建ELK / Prometheus Grafana七、高可用设计多模型备份不要只依赖一家大模型服务商。主模型挂了切备用的。限流和熔断下游 API 限流了自己这边也要限流不要一直发请求错误率太高就熔断暂时停掉等恢复了再开兜底回答实在处理不了的时候有个兜底回复别报错给用户。八、工程化 Checklist上线前对照检查部署无状态服务可水平扩展流式输出异步处理不阻塞限流机制监控核心指标监控调用量、延迟、错误率、token告警配置日志完整有 trace_id链路追踪成本模型选型合理缓存机制上下文压缩最大步数限制成本监控和预算告警稳定性重试机制指数退避超时控制降级方案兜底回答备用模型版本Prompt 版本化配置版本化灰度发布能力快速回滚能力九、本篇小结部署架构API 服务 流式输出 异步并发 无状态水平扩展监控指标业务指标、性能、成本、错误率关键指标要告警成本优化模型分级、缓存、上下文压缩、减少步数、限制最大步数错误处理指数退避重试、降级策略、超时控制、友好错误提示版本管理Prompt 和配置版本化、灰度发布、A/B 测试、快速回滚可观测性结构化日志、链路追踪每一步都要能回看高可用多模型备份、限流熔断、兜底回答上线前对照 Checklist 逐项检查确保工程质量下一篇是系列收尾实战篇智能客服 Agent 完整实现把前面讲的知识全部串起来做一个完整的智能客服。我是黒漂技术佬。