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

AI模型工程笔记

511人浏览 · 2026-05-21 19:58:44

AI模型工程笔记 · 2026-05-21 19:58:44 发布

很多团队做 AI Agent，上线前会问一个问题：

“成功率多少？”

这当然要看。

但只看成功率，很容易误判。

因为 AI Agent 的问题不是简单的成功或失败。

它可能成功调用了工具，但参数是错的。
它可能生成了回复，但用户改了 80%。
它可能完成了任务，但花了太多轮对话。
它可能没有报错，但绕了很远的路。
它可能看起来完成了，实际上需要人工补救。

这些情况如果只看 success = true，都看不出来。

Google 开发者更新提到 Antigravity、Gemini API 等工具正在面向 agentic development 推进，并强调从 prompt 到 production-ready application 的工具链。

Agent 越接近生产环境，可观测性越重要。

你需要知道的不只是：

它有没有完成？

还要知道：

它怎么完成的？
用了几步？
调用了哪些工具？
有没有被用户打断？
有没有高风险动作？
有没有反复修改？
有没有人工接管？
最终结果有没有被采纳？

这就是 Agent Observability。

一个最小的 Agent 观测数据可以这样定义：

from dataclasses import dataclass, field
from typing import Dict, List, Optional
from datetime import datetime

@dataclass
class ToolCallRecord:
    tool_name: str
    ok: bool
    latency_ms: int
    error_code: Optional[str] = None

@dataclass
class AgentRunMetrics:
    run_id: str
    task_type: str
    user_id: str
    started_at: datetime
    finished_at: Optional[datetime]
    success: bool
    total_steps: int
    tool_calls: List[ToolCallRecord] = field(default_factory=list)
    user_revision_count: int = 0
    human_handoff: bool = False
    risk_blocked: bool = False
    final_accepted: bool = False

这里面最容易被忽略的是几个指标。

第一，user_revision_count。

AI 输出后，用户改了多少次？

如果一个 Agent 每次都“成功”，但用户每次都要改五六轮，它就不是真的好用。

def revision_rate(total_runs: int, total_revisions: int) -> float:
    if total_runs == 0:
        return 0.0
    return total_revisions / total_runs

第二，final_accepted。

最终结果有没有被用户采纳？

很多 Agent 输出看起来完整，但用户最后没用。只看生成次数，会误以为系统很活跃；看采纳率，才知道有没有价值。

def acceptance_rate(runs: List[AgentRunMetrics]) -> float:
    if not runs:
        return 0.0
    accepted = sum(1 for run in runs if run.final_accepted)
    return accepted / len(runs)

这里可以举一个真实的指标解读。

某个客服回复 Agent，上线一周后，后台显示成功率 92%。

听起来很好。

但再看细一点：

最终采纳率只有 31%。
用户平均修改 4.8 次。
人工接管率 42%。
高风险话术拦截 18 次。
工具调用错误率只有 3%。

这说明什么？

不是工具接口有问题。

也不是 Agent 完全不能用。

而是它“能生成”，但生成的内容离可直接发送还很远。

这时候不应该继续吹成功率 92%，而应该把它从“自动回复客户”降级成“回复草稿助手”，重点优化话术边界和场景分类。

这才是可观测性的价值。

第三，human_handoff。

哪些任务最后转人工？

转人工不是坏事。恰恰相反，它能告诉你 Agent 边界在哪里。

def handoff_rate(runs: List[AgentRunMetrics]) -> float:
    if not runs:
        return 0.0
    handoffs = sum(1 for run in runs if run.human_handoff)
    return handoffs / len(runs)

第四，tool_error_rate。

工具调用失败率。

def tool_error_rate(runs: List[AgentRunMetrics]) -> Dict[str, float]:
    stats = {}

    for run in runs:
        for call in run.tool_calls:
            if call.tool_name not in stats:
                stats[call.tool_name] = {"total": 0, "error": 0}
            stats[call.tool_name]["total"] += 1
            if not call.ok:
                stats[call.tool_name]["error"] += 1

    return {
        tool: value["error"] / value["total"]
        for tool, value in stats.items()
        if value["total"] > 0
    }

第五，risk_blocked。

高风险动作被拦截了多少次？

这个指标很重要。它不是坏消息，而是安全系统在工作。

def risk_block_rate(runs: List[AgentRunMetrics]) -> float:
    if not runs:
        return 0.0
    blocked = sum(1 for run in runs if run.risk_blocked)
    return blocked / len(runs)

第六，step_count。

Agent 完成一个任务用了几步？

如果一个简单任务总是绕 10 步，说明 planner 或工具选择有问题。

def average_steps(runs: List[AgentRunMetrics]) -> float:
    if not runs:
        return 0.0
    return sum(run.total_steps for run in runs) / len(runs)

这些指标合在一起，才比单纯成功率更接近真实情况。

你可以把 Agent 监控面板分成四类：

效果指标：采纳率、用户修改次数、任务完成率。
效率指标：平均步骤数、平均耗时、工具调用次数。
风险指标：高风险拦截率、人工接管率、敏感动作触发率。
稳定性指标：工具错误率、超时率、JSON 解析失败率。

对应一个简单的聚合函数：

def build_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),
    }