生产级 Agent 部署与可观测——给 Agent 装行车记录仪这是「Agent 工程化」系列的第十篇。第九篇装了护栏Agent 终于敢上线了。但上线只是开始——线上 Agent 出了岔子你怎么知道这篇讲可观测日志、trace、指标、告警让 Agent 的一举一动都在掌握之中。事故现场下错一单谁来解释上线一个月坏消息来了用户投诉我昨天让你们的助手订酒店它给我订成了另外一家你打开后台想查它当时到底干了什么——结果发现只有对话记录没有调用记录。不知道它调了哪个工具、参数是什么、返回了什么、花了多少钱。你完全无法回答为什么订错了。这就是没有可观测性的后果出事的时候你是个瞎子。Agent 不是普通程序——它是多步、随机、会自我决策的。普通程序出错堆栈一目了然Agent 出错你得知道它那一百步里哪一步想错了。所以 Agent 上线第一件事不是加功能是装行车记录仪。可观测的核心全链路 trace行车记录仪要录什么Agent 每一步的完整信息记录项例子用途第几步第 7 轮循环定位卡在哪思考内容“我决定查一下酒店评分”复盘决策过程调的哪个工具search_hotel检查工具选择参数是什么{city: 三亚, date: 明天}检查参数幻觉工具返回什么酒店列表 JSON检查数据对不对花了多少钱0.03 元成本核算耗时多久1.2 秒性能监控用户是谁user_123会话归属一条 trace 长这样[2026-08-01 14:03:22] turn7 thought: 用户要订酒店先查三亚的 action: search_hotel(city三亚, date明天, budget800) result: 3 家酒店均价 700 cost: 0.03 元 | latency: 1.2s关键原则先记录再优化。很多团队喜欢先搞聪明的诊断其实把每一步老实记下来80% 的问题都能事后还原。trace 落地三步写入写 trace 不要阻塞主流程三步走defrecord_turn(turn):db.batch_append({# 1. 批量写入别逐条插入session:turn.session,turn:turn.no,thought:turn.thought,action:turn.action,result:truncate(turn.result,2000),# 2. 长内容截断cost:turn.cost,latency:turn.latency,})三个要点批量写入每条 trace 都立刻 INSERT 会拖垮数据库攒一批一起写见踩坑部分长内容截断工具返回可能几万字trace 里存截断版呼应第 4 篇的截断异步不阻塞记录动作不能拖慢主流程用异步或消息队列生产级考虑降级、告警、审计1. 降级策略挂了也要能说话Agent 依赖的外部服务查航班、查天气随时可能挂。查航班的服务挂了Agent 就整个崩溃吗不应该——降级方案降级等级做法用户体验缓存兜底先给缓存/历史数据正常稍旧简化回答用通用知识答标注实时数据不可用可用但提醒明确告知“航班服务暂时不可用请稍后”诚实降级的原则流程不崩体验降级诚实告知。让用户得到次优答案远好于得到一个报错。2. 告警别等用户投诉才知道可观测不只是事后查更要事前报警。设几个核心告警指标指标阈值示例说明单会话成本超预算 2 倍可能跑飞了失败率连续 10 次工具失败服务可能挂了平均轮次从 4 轮涨到 15 轮可能出 bug响应时间P95 超 10 秒性能劣化告警的时机第九篇的未解决标记就是天然告警源——Agent 连续标记未解决说明它在这个场景上持续失败该人工介入了。3. 审计日志合规刚需涉及钱、隐私的操作审计日志是硬要求谁在什么时间通过哪个 Agent做了什么写操作。这个和 trace 分开存、只增不改、定期归档——出事时能向用户和监管交代。踩坑日志打太多数据库先崩了可观测最容易犯的错过度记录。每个 trace 存全量日志量是业务数据的几十倍数据库先扛不住。两个直接后果存储爆炸一天几百万条 trace磁盘告急查询变慢查一条记录要扫大表事故复盘反而更慢解法按优先级手段说明批量写入攒 100 条 / 每秒刷一次别逐条 INSERT长内容截断工具结果、思考全文只存截断版2000 字符内分级存储热数据最近 7 天在快表冷数据归档到对象存储采样正常会话 10% 采样异常会话 100% 全录记住trace 的粒度要够用而不是全量。你复盘事故时需要的是关键轨迹不是每一字节的原文。小结Agent 必须装行车记录仪多步自决策的程序出错了要能还原每一步trace 记什么步骤、思考、工具、参数、结果、成本、耗时——先记录再优化trace 落地三要点批量写入、长内容截断、异步不阻塞生产三件套降级挂了也能说话、告警别等投诉、审计合规刚需别过度记录够用就好不然数据库先崩下篇预告行车记录仪装好了你能看到 Agent 的一举一动了。但下一个问题冒出来你改了版 prompt到底是变好了还是变坏了感觉好像更聪明了不算数得能量化。系列最后一篇讲Agent 评测与回归怎么建测试集、怎么量化质量、怎么用坏案例驱动迭代——把整个系列串起来。本系列路线从 0 到 1Agent 是什么 → 手写最小 ReAct → Function Calling 与工具设计 → 上下文管理 → Memory 记忆系统 → RAG 知识库 → Skill 自学习 → 编排模式与多 Agent → 给 Agent 装护栏 → 生产部署与可观测 → 评测与回归 生产级 Agent 部署与可观测——给 Agent 装「行车记录仪」
生产级 Agent 部署与可观测——给 Agent 装行车记录仪这是「Agent 工程化」系列的第十篇。第九篇装了护栏Agent 终于敢上线了。但上线只是开始——线上 Agent 出了岔子你怎么知道这篇讲可观测日志、trace、指标、告警让 Agent 的一举一动都在掌握之中。事故现场下错一单谁来解释上线一个月坏消息来了用户投诉我昨天让你们的助手订酒店它给我订成了另外一家你打开后台想查它当时到底干了什么——结果发现只有对话记录没有调用记录。不知道它调了哪个工具、参数是什么、返回了什么、花了多少钱。你完全无法回答为什么订错了。这就是没有可观测性的后果出事的时候你是个瞎子。Agent 不是普通程序——它是多步、随机、会自我决策的。普通程序出错堆栈一目了然Agent 出错你得知道它那一百步里哪一步想错了。所以 Agent 上线第一件事不是加功能是装行车记录仪。可观测的核心全链路 trace行车记录仪要录什么Agent 每一步的完整信息记录项例子用途第几步第 7 轮循环定位卡在哪思考内容“我决定查一下酒店评分”复盘决策过程调的哪个工具search_hotel检查工具选择参数是什么{city: 三亚, date: 明天}检查参数幻觉工具返回什么酒店列表 JSON检查数据对不对花了多少钱0.03 元成本核算耗时多久1.2 秒性能监控用户是谁user_123会话归属一条 trace 长这样[2026-08-01 14:03:22] turn7 thought: 用户要订酒店先查三亚的 action: search_hotel(city三亚, date明天, budget800) result: 3 家酒店均价 700 cost: 0.03 元 | latency: 1.2s关键原则先记录再优化。很多团队喜欢先搞聪明的诊断其实把每一步老实记下来80% 的问题都能事后还原。trace 落地三步写入写 trace 不要阻塞主流程三步走defrecord_turn(turn):db.batch_append({# 1. 批量写入别逐条插入session:turn.session,turn:turn.no,thought:turn.thought,action:turn.action,result:truncate(turn.result,2000),# 2. 长内容截断cost:turn.cost,latency:turn.latency,})三个要点批量写入每条 trace 都立刻 INSERT 会拖垮数据库攒一批一起写见踩坑部分长内容截断工具返回可能几万字trace 里存截断版呼应第 4 篇的截断异步不阻塞记录动作不能拖慢主流程用异步或消息队列生产级考虑降级、告警、审计1. 降级策略挂了也要能说话Agent 依赖的外部服务查航班、查天气随时可能挂。查航班的服务挂了Agent 就整个崩溃吗不应该——降级方案降级等级做法用户体验缓存兜底先给缓存/历史数据正常稍旧简化回答用通用知识答标注实时数据不可用可用但提醒明确告知“航班服务暂时不可用请稍后”诚实降级的原则流程不崩体验降级诚实告知。让用户得到次优答案远好于得到一个报错。2. 告警别等用户投诉才知道可观测不只是事后查更要事前报警。设几个核心告警指标指标阈值示例说明单会话成本超预算 2 倍可能跑飞了失败率连续 10 次工具失败服务可能挂了平均轮次从 4 轮涨到 15 轮可能出 bug响应时间P95 超 10 秒性能劣化告警的时机第九篇的未解决标记就是天然告警源——Agent 连续标记未解决说明它在这个场景上持续失败该人工介入了。3. 审计日志合规刚需涉及钱、隐私的操作审计日志是硬要求谁在什么时间通过哪个 Agent做了什么写操作。这个和 trace 分开存、只增不改、定期归档——出事时能向用户和监管交代。踩坑日志打太多数据库先崩了可观测最容易犯的错过度记录。每个 trace 存全量日志量是业务数据的几十倍数据库先扛不住。两个直接后果存储爆炸一天几百万条 trace磁盘告急查询变慢查一条记录要扫大表事故复盘反而更慢解法按优先级手段说明批量写入攒 100 条 / 每秒刷一次别逐条 INSERT长内容截断工具结果、思考全文只存截断版2000 字符内分级存储热数据最近 7 天在快表冷数据归档到对象存储采样正常会话 10% 采样异常会话 100% 全录记住trace 的粒度要够用而不是全量。你复盘事故时需要的是关键轨迹不是每一字节的原文。小结Agent 必须装行车记录仪多步自决策的程序出错了要能还原每一步trace 记什么步骤、思考、工具、参数、结果、成本、耗时——先记录再优化trace 落地三要点批量写入、长内容截断、异步不阻塞生产三件套降级挂了也能说话、告警别等投诉、审计合规刚需别过度记录够用就好不然数据库先崩下篇预告行车记录仪装好了你能看到 Agent 的一举一动了。但下一个问题冒出来你改了版 prompt到底是变好了还是变坏了感觉好像更聪明了不算数得能量化。系列最后一篇讲Agent 评测与回归怎么建测试集、怎么量化质量、怎么用坏案例驱动迭代——把整个系列串起来。本系列路线从 0 到 1Agent 是什么 → 手写最小 ReAct → Function Calling 与工具设计 → 上下文管理 → Memory 记忆系统 → RAG 知识库 → Skill 自学习 → 编排模式与多 Agent → 给 Agent 装护栏 → 生产部署与可观测 → 评测与回归