很多人以为 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,error=None):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_in=1200,tokens_out=800,latency_ms=2100,cost=0.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:return"qwen-turbo"# 便宜、快ifintentinHEAVY:return"deepseek-r1"# 贵、慢、但能推理return"qwen-plus"# 中间档兜底# 简单请求别走重模型，这是最容易被忽视的浪费model=route(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:str="v1"):cfg=AGENT_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 协议，转载请注明出处。
