Agent 上线只是开始：监控、成本、回滚三件套

很多人以为 Agent 上线就是终点。恰恰相反上线那天才是真正烧钱、真正出事的开始。为什么这么说因为上线前你面对的是一个「受控环境」测试集是你自己挑的流量是你自己造的模型参数是你自己调的。上线后你面对的是「真实世界」用户的问题千奇百怪业务数据每天都在变模型供应商隔三差五升级版本。你精心调好的 Agent在真实流量面前可能一天就崩给你看。邮储银行现在日均大模型调用超 600 万次日均 Token 超百亿——这种量级要是没有监控和成本控制光账单就能把项目吓死。这篇聊聊上线之后必须搞定的三件事监控、成本、回滚。监控别只看「模型答没答对」我们一开始的监控特别天真只看模型有没有正常返回。后来发现这远远不够。为什么因为 Agent 不是一次「问答」而是一连串「动作」它要先理解用户意图再决定调哪个工具然后调用工具、拿到结果、组织回答。这一连串动作里任何一环出问题最终结果都是「答错了」或者「没答出来」但你根本不知道是哪个环节出的问题。所以 Agent 的监控要覆盖四类指标每一类都有它存在的理由延迟P50/P95/P99 端到端延迟还有每一步的延迟。RAG 检索慢、模型推理慢、下游 API 慢得能拆开看。为什么拆开看因为「整体慢」和「某一步慢」的修法完全不同。整体 P95 从 1s 涨到 3s可能是模型升级变慢了也可能是知识库索引坏了导致检索超时。不拆开你只能瞎猜。成本Token 数、模型费用、外部 API 费用。预算消耗率要盯异常消耗更要盯。为什么异常消耗更要盯因为 Agent 有「自主性」——它可能在一个问题上反复调用工具十几次也可能把超长上下文一遍遍塞给模型。这些不是用户主动发起的是 Agent 自己「烧」出来的。不盯异常消耗月底账单会给你惊喜。错误率按错误类型和严重程度分类。工具调用失败、超时、权限错误各归各的类。为什么要分类因为「错误率 5%」这个数字本身没有意义你得知道这 5% 是「权限配置错了」改配置就能好还是「模型理解能力不够」得换模型或改 Prompt。分类是为了让你拿到错误率之后知道下一步该干什么。质量幻觉率、groundedness 得分、安全违规。这是最容易忽视的——模型「答对了」不代表「答得对」。为什么这么说因为 Agent 的「答对」只是「返回了内容」而「答得对」是「内容基于事实、符合业务规则」。一个客服 Agent 可能每次都「正常返回」但返回的内容有一半是编的。只看「有没有返回」你根本发现不了。采集代码不复杂难的是想清楚采集什么# 每次 Agent 调用把关键指标打点importtime,jsondeflog_call(request_id,intent,model,tokens_in,tokens_out,latency_ms,cost,errorNone):record{request_id:request_id,intent:intent,model:model,tokens_in:tokens_in,tokens_out:tokens_out,latency_ms:latency_ms,cost:round(cost,6),error:error,ts:time.time(),}# 写入独立审计/监控存储别跟业务库混append_to_observability(record)# 调用结束后打点log_call(req_001,DOING,deepseek-r1,tokens_in1200,tokens_out800,latency_ms2100,cost0.0032)这套打点数据攒起来后面所有优化都有据可依。我讲个真实案例你就知道这套数据多值钱。有个项目上线后Token 成本突然暴涨 40%响应延迟从 500ms 飙到 2.3s。团队一开始怀疑是模型涨价了查了账单发现不是又怀疑是流量涨了看了 QPS 也没涨。最后是翻打点数据、按「变更时间」对齐才发现成本暴涨的前一天有人改了一版 Prompt把系统提示词从 800 字加到了 5000 字——每个请求多塞了 4200 个 token成本不涨才怪。要不是有打点数据这个锅大概率要甩给「模型涨价」而真正的问题Prompt 越写越长会一直潜伏下去。所以监控这件事我的建议是上线第一天就把打点接上别等出事了再补。补监控的成本永远比出事后的排查成本低得多。成本省钱的不是低价模型是「精准」说到成本很多人第一反应是「换个便宜的模型」。我劝你冷静。为什么因为「换便宜模型」省的是「单价」而 Agent 的成本大头往往不是单价是「用量」。你想想一个请求如果因为模型变笨了需要多调 5 次工具、多塞 3 轮上下文省下的单价早就被多出来的用量吃掉了回答质量还下降了。所以成本优化的核心不是低价是精准三招精准路由用轻量模型做意图分类简单请求走快速通道复杂请求才上重模型。别让所有请求都走最贵的。为什么这样能省钱因为真实流量里简单请求查个订单状态、问个营业时间往往占七八成这些请求用轻量模型就够了根本不需要大模型。路由的代码也不复杂# 意图分类路由简单请求走轻量模型复杂请求走重模型defroute(intent:str)-str:SIMPLE{query_status,query_info,faq}# 简单意图HEAVY{multi_step,reasoning,writing}# 复杂意图ifintentinSIMPLE:returnqwen-turbo# 便宜、快ifintentinHEAVY:returndeepseek-r1# 贵、慢、但能推理returnqwen-plus# 中间档兜底# 简单请求别走重模型这是最容易被忽视的浪费modelroute(intent)精准检索小分块 重排序减少噪声上下文注入。上下文塞得越多token 烧得越狠回答还不一定更准。为什么「塞得多」反而「不一定准」因为模型对上下文的注意力是有限的你塞进去 50 个不相关的片段它反而会被噪声干扰抓不住真正有用的那 2 个片段。所以检索要「精准」——宁可少给给对的。精准匹配不同复杂度的任务用不同等级的模型用评测数据做决策别拍脑袋。为什么用评测数据因为「这个任务难不难」不能靠感觉要靠数据。你拿 100 个真实请求分别用轻量模型和重模型跑一遍看轻量模型在哪些任务上会翻车——翻车的归重模型不翻车的归轻量模型。这个分类表就是你的「精准匹配」依据。有个车企团队测多 Agent 协作发现 Agent 互相兜圈等数据、一致认同错误逻辑token 消耗飞快——这就是典型的「不精准」。多 Agent 不是免费的每次互相通信都在烧钱。你想想两个 Agent 为了确认一个数据来回传了 6 条消息每条消息都带着完整上下文这 6 条消息的 token 就是纯浪费。所以多 Agent 架构一定要先想清楚「谁跟谁通信、传什么、传多少」别让 Agent 之间闲聊。浪潮信息的人说过一句挺实在的话「1 元/每百万 token」这种成本突破看着便宜但面对 token 消耗量指数级增长还远远不够。所以成本控制不是一次性的是持续的事。我的建议是每周看一次成本报表按意图、按模型、按工具三个维度拆开看哪块涨了就去查为什么。成本失控从来不是突然发生的是每周涨一点、你一直没看攒出来的。回滚给 Agent 装个「后悔药」Agent 上线后模型会升级、Prompt 会改、工具会换。每一次变更都是风险。为什么因为 Agent 是个「黑盒」——你改了 Prompt理论上只影响「说话方式」实际上可能连带影响「工具选择」和「决策路径」。你改了模型版本可能只是升级了「理解能力」也可能引入了新的「行为偏差」。这些影响测试集往往测不出来只有上了真实流量才暴露。所以回滚机制必须覆盖三样东西模型版本、Prompt 版本、运行配置。这三样缺一不可因为 Agent 的行为是三者共同决定的——你只回滚模型、不回滚 Prompt可能还是错的你只回滚 Prompt、不回滚运行配置比如工具列表、权限策略也可能还是错的。生产环境至少保留两个可用版本。新版本上线前先看可观测性指标和用户反馈再决定放量。Prompt 变更要可审计改了什么、谁改的、什么时候改的全留痕。出问题一键切回上一个健康版本。回滚机制实现上核心是「配置即版本」——把模型、Prompt、工具列表、权限策略都当成可版本化的配置而不是散落在代码里的硬编码# 把 Agent 的配置做成可版本化的出问题一键切回AGENT_VERSIONS{v1:{model:deepseek-r1,prompt:prompt_v1.txt,tools:[query_order,create_ticket],policy:policy_v1},v2:{model:deepseek-r1,prompt:prompt_v2.txt,tools:[query_order,create_ticket,refund],policy:policy_v1},}defrollback(target:strv1):cfgAGENT_VERSIONS[target]apply_model(cfg[model])apply_prompt(cfg[prompt])apply_tools(cfg[tools])apply_policy(cfg[policy])print(f[ROLLBACK] 已切回{target})# 线上出问题一条命令切回上一个健康版本rollback(v1)这套东西看着简单但很多团队没做原因是「觉得没必要」——直到出事了才发现新版本已经上线两周旧版本的 Prompt 文件早被覆盖了想回滚都回不去。所以回滚机制要在上线前就搭好不是出事了再搭。实在智能那套企业级高可用架构讲得挺清楚人机协同是「最后防线」灰度或大促期间安排运维和业务人员值守管理后台实时看数字员工集群状态严重问题一键回滚。这套东西听着繁琐但真出事的时候它就是你的后悔药。我见过太多项目上线时信心满满出事时手忙脚乱——不是没有后悔药是没提前备好。上线之后才是真正的开始把监控、成本、回滚三件套搭好Agent 才算真正「活着」。这三件事没有一件是「做完就结束」的——监控要持续看成本要持续优化回滚机制要持续演练。为什么说「持续」因为 Agent 面对的环境是动态的模型供应商在升级、业务规则在变化、用户问题在演化。你今天调好的监控阈值下个月可能就失效了你今天优化的路由策略下季度可能就不适用了。所以这三件事不是「上线时做一次」是「上线后一直做」。我自己的雷达鸭那个收录一人公司赚钱案例的小程序虽然规模小也把这套思路的简化版用上了——每次问答都打点每周看一次 token 成本和错误率。个人项目跟企业级的差别只是量级不是逻辑。下一篇是这个系列的最后一篇Agent 怎么「养」——治理、组织和长期迭代。10 年软件开发经验软件设计师、人工智能应用工程师主要折腾鸿蒙应用开发ArkTS和 Web 前端也爱琢磨 AI 自动化不定期在 CSDN 分享鸿蒙和 AI 方向的技术文章。本文遵循 MIT 协议转载请注明出处。