我自己在大模型应用这块已经待了快两年中间带团队做过几个 Agent 项目从最早几个人在测试环境里自嗨到后来把 Agent 塞进真实业务里接受全天候流量毒打这个过程中踩过的坑、趟出来的路比看任何论文都来得刻骨铭心。不少人问我Agent 上线之后到底该怎么管跟普通后端服务有什么区别为什么模型一会儿聪明一会儿蠢今天我把生产环境里持续监控与迭代的完整实践整理成一篇长文尽量把那些文档里不写、只有跑到线上才会遇到的东西讲透。这篇内容核心解决三个问题第一Agent 在生产环境里到底要监控什么指标怎么设计才不会三天两头误报第二模型行为和 Prompt 一直在变迭代机制怎么搭才能既快又不翻车第三线上出了幺蛾子怎么从日志和链路里快速定位根因。适合刚把 Agent 推到生产环境、或者正在准备上线的同学也适合后端转大模型应用开发、想建立一套完整可观测体系的工程师。1. 动手之前先想清楚 AI Agent 在生产环境到底要观察什么很多团队把 Agent 当成普通 API 服务来监控看 QPS、看延迟、看错误率、看 CPU这套东西当然没有错但远远不够。Agent 的特殊性在于它不是一个“请求进、响应出”的确定性系统而是一个由大模型驱动、按步骤决策、可能调用多个工具、还可能自我纠错的复杂流程。如果只盯着基础设施指标你看到的永远是“服务活着”但完全不知道这个 Agent 有没有在认真干活、有没有在执行用户压根不想要的步骤。1.1 Agent 与传统服务的本质差异调用链从“线性”变成“网状”传统后端服务一次请求的调用链基本是固定的A 调 BB 调 C最后返回链路是一条相对清晰的线。哪怕有分支分支也是预先定义好的逻辑可穷举。Agent 完全不是这个玩法它的一次任务可能经历“理解意图 - 拆解计划 - 调用工具 - 观察结果 - 修正计划 - 再次调用”这种循环而且每一轮的决策都受上一轮结果影响甚至同一个 Prompt 在不同时间点发过去模型都可能给出完全不同的计划。这意味着原来那套以“接口”为中心的监控粒度要往下沉。你不能只知道“工具调用接口返回了 200”你还得知道模型为什么要调用这个工具、这次调用是第几轮发起的、工具返回的结果被模型采纳了还是忽略掉了、Agent 总共花了多少轮才结束、用户是否中途不耐烦地反复发送相同内容。这些信息藏在应用日志和模型输入输出里不单独做一层面向 Agent 语义的埋点和采集根本看不见。我见过最典型的翻车案例是一个客服 Agent 上线后接口可用性 99.99%延迟中位数 800ms看起来一切正常但用户满意度直线下降。最后翻日志发现Agent 在超过一半的会话里都陷入“问用户问题 - 等用户回答 - 再问下一个问题”的死循环从不调用查订单接口因为 Prompt 里那句“尽可能收集完整信息后再操作”被模型理解成了“必须把用户问到无话可说”。如果只按传统指标监控这个问题可能要过好几周才会被投诉逼出来。1.2 监控设计三板斧指标、日志、链路但维度要多一层“语义层”我一直坚持的基础设施三层还是那套指标Metrics看趋势和告警日志Logs看细节和现场链路Traces看请求在系统里的完整路径。但对 Agent 而言每层都要额外加一个“语义视角”。指标层除了常规的 QPS、延迟、错误率还要加任务级指标任务完成率、任务平均轮数、工具调用成功率、单任务 Token 消耗、拒绝服务率用户在任务中途放弃的比例。日志层除了框架自动打的访问日志还要把模型输入输出、思维链摘要、工具入参和出参、每一步的决策结果全部结构化成 JSON 落盘这是之后排查一切诡异问题的底牌。链路层建议一个用户请求从进来开始就生成一个全局 Trace ID模型调用、工具调用、知识库检索、缓存命中全都挂在这个 Trace 之下。很多团队用 LangChain 或 LangGraph 这类框架它们自带一些 Callback 机制可以很自然地把事件串起来但如果你自己写编排逻辑就得在代码里手工传好 Trace ID。1.3 我在生产环境里最先落地的 5 个核心指标监控体系不要一上来就铺得又大又全先盯住最要命的五个指标跑两周把告警阈值调好再逐步扩展。第一个是任务级完成率也就是用户发起的任务中Agent 走到明确结束状态正常给出最终答案、完成工单、成功下单的比例。这个指标直接反映 Agent 的“靠谱程度”。第二个是平均决策轮数。一个简单查天气的任务如果平均要 6 轮才结束说明模型在无效试探Prompt 或者工具定义出了问题。第三个是工具调用失败率。注意这里失败了不仅指 HTTP 5xx还包括工具返回了业务错误码、模型拿到的结果无法被解析、工具吐出的数据结构意外变化。第四个是单任务 Token 消耗分模型输入 Token 和输出 Token 分别统计。很多成本爆炸的坑都是从输出 Token 悄悄变多开始的。第五个是用户重复提问率即用户在同一会话里把相近意思的话发了两次以上。这个指标非常灵敏Agent 没理解用户意图、或回答没解决用户的问题都会直接体现出来。2. 监控体系落地从埋点到告警的完整实操指标设计得再好埋点埋得稀烂也是白搭。这一章我直接把实践中的做法摊开讲包括埋点埋在哪里最合适、日志结构怎么设计查询效率最高、告警规则怎么定才不会一周后就被全员屏蔽。2.1 埋点设计尽可能把“模型调用”和“业务动作”绑在一起埋点最核心的原则是每个模型调用都得能对应到它最终引发的业务动作。假如模型只是说了一段话但没有触发任何工具调用那这段对话是纯生成假如模型决定调用查单接口那就得把这次调用的原因模型输出里的 tool_call_id、传入的参数、工具返回的原始结果、模型拿到结果后生成的下一条内容完整记录下来。我这里建议不要只打日志要把这些事件用一个统一的事件模型发到消息队列或者直接写到时序数据库每个事件最少包含这些字段trace_id、session_id、user_id脱敏后、agent_version、prompt_version、model_name、model_provider、timestamp、event_type、event_detail。event_type 建议至少区分 planning、tool_call、tool_result、llm_generate、final_answer、error 这几类后面查问题时能少写一半过滤条件。埋点尽量在框架的抽象层统一做千万别在业务代码里分散地手工打点。我见过有团队在每个工具函数里自己 log.info 了一堆乱七八糟的字符串后来想统计工具调用成功率发现根本没法聚合。用装饰器、中间件或者回调钩子统一收口既省力又不会漏。2.2 日志规范的取舍JSON 结构化日志与 Token 消耗采样日志必须 JSON 结构化这是底线。非结构化的纯文本日志在排查的时候简直就是噩梦。每条日志的时间戳要统一用毫秒级 ISO8601时区统一用 UTC 存放展示层再转换到本地时区否则多个服务实例混在一起排时间线时会疯掉。关于模型输入输出和 Token 消耗这类日志有个很现实的取舍问题全量记录会带来巨大的存储成本尤其输出 Token 多的 Agent 任务一条日志可能几十 KB。我的做法是全量记录元信息模型名、Token 数、耗时、错误码、trace 关联对完整输入输出默认按 10% 采样记录遇到错误、重试、超时的任务则无条件全量记录。这样既控制了成本又保证了出问题时一定有现场。Token 消耗这个指标不要只记总 Token 数最好分拆成 prompt_tokens 和 completion_tokens同时记录调用了几次模型、是否走了缓存。很多模型网关都支持返回这些明细直接透传进日志就行。成本分析的大头往往藏在“同一个任务反复重试导致模型被调用了 N 次”这种场景里光看总 Token 是看不出问题的。2.3 告警规则怎么定才不变成“狼来了”告警规则的原则是宁可延迟不要误报。误报几次之后团队就会对所有告警免疫真正出大事的时候反而没人看。任务级完成率这个指标不建议用固定阈值触发比如“低于 90% 就告警”因为不同任务类型难度差别太大。我给每个 Agent 技能Skill单独设基线例如查天气类任务基线完成率 98%多轮复杂推理类任务基线 85%按基线下降幅度告警比如“连续 10 分钟完成率低于基线 10 个百分点”才触发。平均决策轮数可以参考另一套规则超过基线 1.5 倍持续 15 分钟以上就要关注重点看是不是 Prompt 最近改过、还是某个外部依赖返回格式变化导致模型反复修正。工具调用失败率建议按单个工具拆开算某个不常用的工具失败率一高经常是因为上游接口悄悄改了字段Agent 解析不到数据就在那里原地打转。告警通知也要分级P0 级别任务完成率暴跌、大量 5xx、Token 消耗异常飙升直接打电话或发短信P1 级别特定工具失败率升高、单任务轮数异常发到值班群P2 级别指标缓慢劣化、采样日志发现 Prompt 版本行为偏移进日报和 weekly review。2.4 成本与性能监控Token 计量、延迟和限流设计的实战考量成本监控如果等月底看账单再喊“怎么花了这么多钱”就已经晚了。我在生产环境里是给每个任务类型预估一个 Token 消耗上限按实际消耗与预估的比值作为 cost_ratio 指标超过 1.2 就要告警。同时按 API Key、按业务线、按用户等级做 Token 消耗拆分防止某个测试用户不小心触发了一个疯跑的循环任务把预算烧掉大半。延迟监控的坑在于大模型输出是流式的用户第一 token 到达时间TTFT和完整输出时间Total Latency要分开看。TTFT 反映的是模型服务端和网络链路Total Latency 还包含模型输出长度的影响。Agent 如果调用工具多工具响应慢会直接拖垮整个体验所以要单独观察“工具调用耗时占任务总耗时的比例”这个值超过 70% 就要考虑换工具实现、加缓存或者改并行调用。限流设计这块常见误区是只给下游 API 做限流忽略了 LLM 提供商自己的限流。模型侧限流通常是按 token_per_minute 和 requests_per_minute 双层限制一定要在网关侧做令牌桶不然 Agent 一高并发模型服务直接抛 429重试策略写得不好就会产生雪崩。这里我强烈建议把重试的退避策略从固定间隔改成指数退避加抖动重试次数收敛在 3 次以内避免一次任务里对同一个模型调用重试十几次。3. 迭代体系把“模型升级”当成一次正经发布上线只是开始真正折磨人的是后续的持续迭代。很多团队把 Agent 的迭代还停留在“改个 Prompt 就上线”的阶段结果改了之后好不好全靠感觉出问题也不知道怎么回滚。Agent 的迭代必须要有体系和纪律否则你根本分不清某个行为变化到底是模型底层升级导致的还是自己的 Prompt 改动导致的。3.1 评估集与回归集没有评估集的迭代都是靠运气我见过太多团队压根没有评估集迭代 Agent 靠“我觉得这样回答更好”来判断。这种模式在小规模实验里勉强能跑一旦正式业务并发起来一定会翻车。评估集不是拍脑袋攒二十条测试用例就完事要分三层。第一层是核心场景回归集覆盖产品最核心的 10 到 20 个用户场景每个场景包含完整的多轮对话历史和期望结果。期望结果不要只写“回答正确”要拆成几个维度是否完成了用户目标、是否在最少的轮数内完成、是否调用了正确的工具、是否有幻觉内容、是否违反了安全策略。第二层是边界与异常集专门收集那些容易让 Agent 迷糊的输入模糊歧义表达、用户中途改需求、工具返回空数据、模型连续失败后用户表达不满、越权请求等。每个边界用例都应是线上真实遇到过的 Case 沉淀而成而不是纯靠脑补。第三层是回归基线库也就是历史出过问题、后来修好的 Case 集合每次迭代之后都要跑一遍确保之前修过的问题没有复发。这个库非常重要很多团队只往前看不往回看结果同一个坑每月踩一次。评估方式上不要只会人工打分。小规模用 LLM-as-a-Judge 做初筛是可行的但 Judge 模型和业务模型不要用同一家同一版本尽量交叉验证。人工抽检每周做一轮专门验证 LLM Judge 拿不准的边界 Case。打分维度建议至少包含任务完成度、正确性、效率、安全合规、语气与体验五个方面。3.2 灰度与回滚模型版本、Prompt 版本、Agent 配置版本如何联动模型升级从来不是模型方发个公告你就能拍板切换的。我踩过一次大坑底层模型厂商升级了一个版本意图理解能力确实变强了但我们某个业务 Prompt 里的 few-shot 示例格式却没跟上结果模型“自作聪明”地改变了工具参数的填法线上直接出现一波报错。从那以后我就定了一个规矩任何模型版本切换都必须走灰度流程同时把模型版本、Prompt 版本、Agent 代码版本、依赖的工具版本四个维度打成一个“可发布单元”。灰度方案建议按流量比例灰度先放 5%观察任务完成率和用户投诉再逐步加到 20%、50%、100%。每一步都要对比新旧版本的指标差异尤其是完成率、平均轮数、Token 消耗和用户重问率。如果新版本完成率下降超过两个百分点立即回滚不要犹豫不要试图通过半夜热修 Prompt 把问题“救回来”。版本管理工具我推荐用 Git 管理 Prompt 和 Agent 配置每次变更都走 MR 评审发布时自动生成版本号并且把版本号注入运行时上下文。这样每一条线上日志都能追溯到当时跑的是哪个 Prompt 版本和哪个模型版本排查“昨天还好好的今天怎么抽风了”这类问题时第一步就是看版本时间线。3.3 反馈闭环线上数据回流到评估集的管道设计评估集最怕的是“变成一个静态文件半年不更新”。真正有效的评估集必须是活的持续从线上吸收新 Case。我设计了一个比较轻量的反馈管道线上 Agent 每次任务结束如果触发以下条件之一这条会话就会被打上“值得复盘”的标签——用户重问两次及以上、最终回答被用户点踩、任务完成轮数超过基线 1.5 倍、模型输出违反预设规则、工具调用连续失败后 Agent 仍坚持重试。带标签的会话自动进入一个待标注队列每周由产品和研发一起抽样标注标注结果通过一个半自动评审流程进入评估集。具体做法是先用 LLM 做初判比如判断“这个 Case 里 Agent 是否完成了用户目标”给出一份建议再由人工确认或修改最后把高质量 Case 追加到对应分类的评估集里。这样评估集每一周都会从真实世界吸收新的“毒打经验”比任何内部头脑风暴都来得真实。这套反馈闭环还有个额外好处它能顺带帮你发现产品层面的问题。如果某个业务线的用户重问率持续偏高可能不是 Agent 能力不行而是这个业务线的用户习惯、服务流程本身就不适合用纯 Agent 处理需要人机协同兜底。这类发现用拍脑袋很难察觉数据管道跑起来之后自然就浮出水面。4. 生产环境排查实录几个让我印象深刻的坑监控和迭代讲完了来点真实的战场记录。下面这几个问题每一个都让我和团队在凌晨的会议室里对着日志怀疑人生写出来给大家做个参考遇到类似现象能少走弯路。4.1 上下文泄漏每次请求长一截最后直接把 Token 打爆我们有一个文档问答型 Agent上线两周后突然收到成本告警Token 消耗环比涨了 180%。第一反应是流量涨了但查了 QPS 没有明显变化。后来把单任务 Token 消耗按时间切出来看发现每个任务的输入 Token 都在缓慢爬升而且爬升的速率跟会话轮数正相关。翻日志后发现Agent 在处理每一条新消息时把整个会话历史都塞进上下文其中还包含之前几轮模型输出里的完整思考链和工具返回的原始长文本。这个 Agent 做文档问答时工具会返回多段文档切片每段切片都接近上限长度好几轮下来上下文里塞满了重复的、被裁减过的文档内容输入 Token 自然爆炸式增长。解决思路有两个方向一是主动压缩对历史消息做摘要间隔 N 轮后把早期的消息摘要成几条短消息二是控制工具返回内容体量文档切片在进 Prompt 前先做相关性阈值过滤只用最高分的那一两段。两个方向我们都做了Token 消耗降回到正常水平任务完成率反而因为没那么多噪声而有所提升。这个坑也告诉我们监控 Token 消耗不是成本部门的任务它直接关系到 Agent 的上下文质量。4.2 Prompt 漂移没人动过 Prompt行为却变了有段时间一个电商导购 Agent 的“比价推荐”功能表现越来越差明明没人改过 Prompt。一开始怀疑是用户输入变复杂了后来对比了前后两周的模型输出发现模型开始倾向于给用户罗列一堆参数表格而不是直接给出推荐结论。这个变化不在我们的意图里但模型就是“自己发展”出了这种风格。这种情况就是典型的 Prompt 漂移底层模型是第三方托管服务厂商会不定期更新模型权重和推理配置名义上还是同一个模型版本号实际上行为已经悄悄变了。模型推理的随机性也值得一提温度参数如果不固定行为波动会更明显。另一个常见来源是 few-shot 示例的顺序变化同样的示例换了个排列顺序模型输出的风格都能差出一大截。应对 Prompt 漂移没有一劳永逸的办法只有一套微习惯固定采样参数温度、top_p 等要在配置里显式写死不要依赖模型服务的默认值few-shot 示例在发布后不要轻易改顺序改完必须跑回归集每周用同一个固定的“哨兵问题集”去探测模型行为把模型输出的分布记录下来对比周与周之间的漂移幅度。如果漂移幅度超过阈值说明模型服务方有变化要重新评估当前 Prompt 是否还适配。4.3 Arthas 在生产环境排查 Java Agent 问题的使用心得我们核心链路有一部分 Agent 编排代码跑在 Java 服务上有次线上出现一个诡异问题Agent 任务偶发卡住没有报错日志停在某一步线程池也没有被打满但用户端一直收不到最终回复。这种问题很难通过加日志来复现因为它是偶发的而且一加日志可能就改变了时序。这时候用到了 Arthas。Arthas 是一个 Java 诊断工具可以直接连接到运行中的 JVM 进程不需要重启服务也不需要改代码。我通过 Arthas 的 thread 命令查找处于 BLOCKED 或 WAITING 状态的线程拿到线程栈之后发现有个工作线程卡在一个 HTTP 调用上等下游服务响应等了几分钟都没有超时中断。问题根因是某次发布时把 HTTP 客户端的连接超时设置从 3 秒改成了 0表示无限等待而下游服务又刚好出现了一次长时间的 GC 停顿请求就悬挂住了。Arthas 还帮我解决过另一个问题线上同学的代码里发生了 JSON 循环引用序列化抛异常但因为异常被 catch 吞掉了日志里只有一行 debug 级别记录完全不起眼。用 Arthas 的 watch 命令动态观察序列化方法的入参和返回直接看到了哪个对象图里出现了自引用。生产环境排查这类问题时Arthas 真的是一个不用不行的利器前提是团队要有严格的线上操作审批流程这类动态诊断命令在使用时要做好审计。4.4 Agent 卡死与重试风暴回调链路的“隐形炸弹”Agent 卡死还有一种很隐蔽的原因就是回调链路坏了。我们有个 Agent 会通过 WebSocket 向用户实时推送“正在查询订单”这类中间状态然后等前端确认后继续执行。有次前端某个版本更新不再对 WebSocket 的 ready 事件做出响应Agent 在等待前端确认这一步就永久挂起了任务既不失败也不结束就卡在那里。日志里的现象是没有错误没有超时一切看着都很正常。排查思路要从“没有日志”入手先把超时机制加上。无论 Agent 在等工具、等用户还是等外部回调任何等待都必须有上限超过上限就进入超时兜底分支要么自动重试要么主动结束并把当前状态交给人工。另一个教训是重试风暴一次下游订单服务抖动Agent 里配的工具在捕获异常后进行了三次重试但因为有多个 Agent 实例并发处理相似任务下游服务一恢复瞬间涌入大量重试请求直接把下游打满。后来给所有工具调用配置了全局级别的熔断器连续失败超过阈值直接降级返回“稍后再试”不再把压力传导给下游。5. 常见问题速查表与避坑清单最后这部分把日常运维 Agent 时遇到的高频问题整理成速查表再单独列几条我最想提醒的细节。这些内容不是从哪本手册上抄下来的全是实战里花了真金白银换来的。5.1 监控迭代高频问题速查表现象可能原因排查手段任务完成率下降但接口无报错Prompt 改版或模型行为漂移对比版本时间线回放近期带标签会话跑回归集单任务 Token 消耗异常飙升上下文泄漏、工具结果未压缩、模型重试过多分析 Token 消耗按轮次拆解查上下文组装逻辑Agent 偶发卡住无日志外部调用无超时、回调无人响应、线程池耗尽用 Arthas 看线程栈排查等待点给所有等待加上限模型输出风格突然变化底层模型服务更新、采样参数漂移固定采样参数跑哨兵问题集对比行为分布用户重问率高意图理解偏差、工具选择错误、答案未解决问题给重问会话打标签人工标注后入评估集下游服务被请求打爆工具重试策略过强、无熔断全局熔断器指数退避限制重试次数模型服务返回 429触发了供应商限流网关令牌桶限流任务排队削峰新模型表现好但线上回报变差灰度不充分、评估集未覆盖线上场景按流量比例灰度扩展边界评估集5.2 我踩过之后最想提醒的 5 个细节第一Agent 的所有外部等待都必须有超时和兜底分支。不要相信任何“它肯定会返回”的假设网络会抖、服务会挂、用户会关页面Agent 编排层必须把这些异常情况当成正常逻辑处理否则线上一定会出现“进程活着但任务全卡死”的诡异状态。第二Prompt 不是代码但它比代码更需要版本管理。代码改动有编译期兜底Prompt 改动上线时可能完全没毛病几天后才在长尾请求上暴露问题。Prompt 必须进 Git每次改动都要绑版本号任何线上日志都要能追溯到当时跑的 Prompt 长什么样。第三模型输出一定要做校验与结构化解析不要假设模型永远按 JSON Schema 输出。哪怕加了强约束也要写一个解析失败后的修正分支。这个分支虽然简单但能省掉大量因为你以为模型会乖乖听话而导致的线上事故。第四评估集一定要持续从线上回流新案例。静态评估集最大的风险不是覆盖不全而是随着业务演化它慢慢变成一套“自我感觉良好”的摆设跟真实用户完全脱节。第五不要把工具的成功率等同于 Agent 的成功率。工具调用返回 200 只代表 HTTP 层通了不代表返回的数据是模型想要的、也不代表业务结果是对的。真正能反映 Agent 质量的是任务级完成率和用户侧体验指标监控体系一定要把这两层指标建立起来。最后再分享一点个人体会做 Agent 生产环境运维这么久我最大的感受是别把 Agent 当成一个“更聪明的接口”它本质上是一个需要持续调教的数字员工。你给它定的流程、给的工具、教的历史经验任何一个角落出了问题它都会用一种看似合理但其实跑偏的方式体现出来。监控体系的意义不是让你在出问题时能快速找到责任人而是让你能尽早发现它“快要不正常了”在用户感知之前把问题消化掉。这套持续监控与迭代的机制说到底是把 Agent 的不可控性一点点关进笼子里。