AI Agent 上线后别只盯调用成功率很多团队第一次把 AI Agent 接进真实流程时最容易盯住一个指标调用成功率。这个指标当然要看但它只回答了一个很窄的问题系统有没有正常返回。生产环境里更重要的问题是Agent 的建议有没有被业务采纳人工有没有大量改写工具失败是否集中在某几个外部依赖高风险动作有没有被拦住出错之后能不能回滚和补偿如果这些信号没有建立起来一个 99% 调用成功率的 Agent也可能只是稳定地产生低质量建议。为什么调用成功率不够接口成功率通常只覆盖模型调用、检索调用或工具调用有没有返回 2xx。它看不到下面这些问题输出可以返回但业务人员完全不用。建议看起来完整但关键证据缺失。工具调用成功但参数选错了对象。用户每次都要人工改一大段。Agent 被护栏拦截很多次但没有人复盘原因。出错后靠人工救火没有固定补偿路径。所以我更建议把上线后的监控拆成“可用、可信、可控”三层来看而不是只看系统是否活着。上线后先看 6 个生产信号1. 建议采纳率采纳率不是简单地问“用户点没点确认”而是看 Agent 的输出是否进入了真实业务动作。可以拆成三类直接采纳用户基本不改直接执行。修改后采纳用户改了一部分再执行。放弃用户没有采用或者转人工重做。这个指标能很快暴露“demo 看起来不错真实场景没人敢用”的问题。2. 人工改动率如果每条输出都要人改 60% 以上系统不一定是失败但它大概率还不是自动化系统。这里可以记录标题、摘要、正文、参数分别被改了多少。哪些字段最常被人工覆盖。改动后是否提高了通过率或满意度。人工改动不是噪音它是非常有价值的训练信号和流程信号。3. 工具失败分布工具调用失败不要只记一个总数。要按错误类型和外部依赖拆开信号应该记录什么参数错误schema 校验失败、缺字段、格式不合法权限错误无权限、越权、审批未通过外部依赖错误超时、限流、5xx、连接失败业务拒绝库存不足、状态不允许、对象不存在这样才能判断问题是在提示词、工具定义、权限模型还是外部系统稳定性。4. 高风险动作拦截率生产 Agent 一旦能写数据、发消息、改配置、触发工单就必须记录高风险动作的拦截情况。这里要看两个方向拦得住越权、金额超限、删除、批量操作是否被拦截。别乱拦正常业务动作是否频繁被误伤。护栏不是摆设。拦截记录应该能回放到具体输入、工具、参数、规则和人工审批结果。5. 回滚和补偿触发有副作用的 Agent不能只设计“成功路径”。比如发错消息后是否能撤回或补发说明。重复创建工单后是否能合并或关闭。写错字段后是否能恢复上一个版本。外部接口半成功时是否有补偿任务。上线后要记录补偿触发次数、补偿是否成功、是否需要人工介入。这个指标比“有没有报错”更接近真实生产风险。6. 审计链完整率当业务问“为什么 Agent 当时这么做”时系统不能只剩一句模型输出。至少要能查到用户输入和上下文版本。命中的知识、引用或检索结果。模型、提示词和路由策略版本。工具调用入参、出参、错误码和重试链路。人工确认、拒绝或改写记录。审计链完整率可以作为一个硬指标关键事件是否都有可回放证据。一个更实用的日志结构不需要一开始就上很复杂的平台但关键字段要先留出来{trace_id:agent-run-20260706-001,scenario:support_ticket_triage,model_route:fast_model_with_escalation,adoption:edited_then_accepted,human_edit_ratio:0.32,tool_calls:[{tool:create_ticket,status:blocked,reason:missing_required_approval}],risk_guardrail:{triggered:true,rule:write_action_requires_human_confirm},audit_complete:true}这类结构化记录的价值不只是排障。它还能帮助团队判断下一轮应该优化提示词、知识库、工具定义、权限规则还是业务流程本身。上线第一周怎么复盘我通常会建议第一周不要急着扩大范围而是先做一个轻量复盘抽样 20 到 50 条真实运行记录。标出直接采纳、修改采纳、放弃三类。把失败按“模型、知识、工具、权限、流程”归因。看高风险拦截是否有误伤或漏拦。检查每条关键动作是否能完整回放。如果这些信号都比较健康再考虑扩大场景或提高自动化比例。小结AI Agent 上线后调用成功率只是底线不是质量指标。真正需要持续看的是采纳率、人工改动率、工具失败分布、高风险动作拦截、回滚补偿和审计链完整率。这些指标能帮助团队回答一个更关键的问题这个 Agent 不是“能不能跑”而是能不能在真实业务里被信任、被控制、被持续改进。