AI Agent 上线后，别只看成功率：你需要一套可观测性指标

很多团队做 AI Agent上线前会问一个问题“成功率多少”这当然要看。但只看成功率很容易误判。因为 AI Agent 的问题不是简单的成功或失败。它可能成功调用了工具但参数是错的。它可能生成了回复但用户改了 80%。它可能完成了任务但花了太多轮对话。它可能没有报错但绕了很远的路。它可能看起来完成了实际上需要人工补救。这些情况如果只看success true都看不出来。Google 开发者更新提到 Antigravity、Gemini API 等工具正在面向 agentic development 推进并强调从 prompt 到 production-ready application 的工具链。Agent 越接近生产环境可观测性越重要。你需要知道的不只是它有没有完成还要知道它怎么完成的用了几步调用了哪些工具有没有被用户打断有没有高风险动作有没有反复修改有没有人工接管最终结果有没有被采纳这就是 Agent Observability。一个最小的 Agent 观测数据可以这样定义fromdataclassesimportdataclass,fieldfromtypingimportDict,List,OptionalfromdatetimeimportdatetimedataclassclassToolCallRecord:tool_name:strok:boollatency_ms:interror_code:Optional[str]NonedataclassclassAgentRunMetrics:run_id:strtask_type:struser_id:strstarted_at:datetime finished_at:Optional[datetime]success:booltotal_steps:inttool_calls:List[ToolCallRecord]field(default_factorylist)user_revision_count:int0human_handoff:boolFalserisk_blocked:boolFalsefinal_accepted:boolFalse这里面最容易被忽略的是几个指标。第一user_revision_count。AI 输出后用户改了多少次如果一个 Agent 每次都“成功”但用户每次都要改五六轮它就不是真的好用。defrevision_rate(total_runs:int,total_revisions:int)-float:iftotal_runs0:return0.0returntotal_revisions/total_runs第二final_accepted。最终结果有没有被用户采纳很多 Agent 输出看起来完整但用户最后没用。只看生成次数会误以为系统很活跃看采纳率才知道有没有价值。defacceptance_rate(runs:List[AgentRunMetrics])-float:ifnotruns:return0.0acceptedsum(1forruninrunsifrun.final_accepted)returnaccepted/len(runs)这里可以举一个真实的指标解读。某个客服回复 Agent上线一周后后台显示成功率 92%。听起来很好。但再看细一点最终采纳率只有 31%。用户平均修改 4.8 次。人工接管率 42%。高风险话术拦截 18 次。工具调用错误率只有 3%。这说明什么不是工具接口有问题。也不是 Agent 完全不能用。而是它“能生成”但生成的内容离可直接发送还很远。这时候不应该继续吹成功率 92%而应该把它从“自动回复客户”降级成“回复草稿助手”重点优化话术边界和场景分类。这才是可观测性的价值。第三human_handoff。哪些任务最后转人工转人工不是坏事。恰恰相反它能告诉你 Agent 边界在哪里。defhandoff_rate(runs:List[AgentRunMetrics])-float:ifnotruns:return0.0handoffssum(1forruninrunsifrun.human_handoff)returnhandoffs/len(runs)第四tool_error_rate。工具调用失败率。deftool_error_rate(runs:List[AgentRunMetrics])-Dict[str,float]:stats{}forruninruns:forcallinrun.tool_calls:ifcall.tool_namenotinstats:stats[call.tool_name]{total:0,error:0}stats[call.tool_name][total]1ifnotcall.ok:stats[call.tool_name][error]1return{tool:value[error]/value[total]fortool,valueinstats.items()ifvalue[total]0}第五risk_blocked。高风险动作被拦截了多少次这个指标很重要。它不是坏消息而是安全系统在工作。defrisk_block_rate(runs:List[AgentRunMetrics])-float:ifnotruns:return0.0blockedsum(1forruninrunsifrun.risk_blocked)returnblocked/len(runs)第六step_count。Agent 完成一个任务用了几步如果一个简单任务总是绕 10 步说明 planner 或工具选择有问题。defaverage_steps(runs:List[AgentRunMetrics])-float:ifnotruns:return0.0returnsum(run.total_stepsforruninruns)/len(runs)这些指标合在一起才比单纯成功率更接近真实情况。你可以把 Agent 监控面板分成四类效果指标采纳率、用户修改次数、任务完成率。效率指标平均步骤数、平均耗时、工具调用次数。风险指标高风险拦截率、人工接管率、敏感动作触发率。稳定性指标工具错误率、超时率、JSON 解析失败率。对应一个简单的聚合函数defbuild_agent_dashboard(runs:List[AgentRunMetrics])-Dict:return{acceptance_rate:acceptance_rate(runs),handoff_rate:handoff_rate(runs),risk_block_rate:risk_block_rate(runs),average_steps:average_steps(runs),tool_error_rate:tool_error_rate(runs),}上线后你会发现有些 Agent 并不是不能用而是需要缩小任务范围。客服回复 Agent完整回复采纳率低但问题分类准确率高。那就不要让它直接写最终回复先让它做分类。代码 Agent自动修改成功率一般但解释旧代码很稳定。那就先放在代码理解环节。资料总结 Agent长报告容易漏细节但短资料摘要效果很好。那就限制输入长度和任务类型。前期做多模型测试时可以用 gpt1998.com 跑同一组任务比较不同模型在采纳率、修改次数、JSON 解析成功率、工具调用错误率上的差异。这样得到的结论比主观说“这个模型更聪明”靠谱得多。OpenAI Codex cloud 可以在后台并行处理任务代表软件工程 Agent 正在从演示走向更真实的生产流程。Agent 化工具越普及团队越需要从“能跑”进入“可观测”。AI Agent 上线后别只盯着成功率。真正重要的是用户有没有采纳人有没有少改风险有没有被拦住失败能不能被定位任务边界有没有变清楚没有这些指标Agent 只是一个黑盒。有了这些指标Agent 才可能变成可治理的系统。