摘要
Success Rate 是 Agent 评估里最直观的指标：任务最后是否完成。但对能调用工具、读取私有数据、写入系统的 Agent 来说，最终答案只是结果的一部分。真正需要评估的是整条 trajectory：模型怎样选择工具，传了什么参数，用了哪些证据，是否越权，是否产生副作用，是否在不确定时转人工。
近年来的 benchmark 也在朝这个方向变化。AgentDS 覆盖 6 个行业、17 个数据科学挑战，并比较 AI-only 与 human-AI collaboration；DSBench 包含 466 个数据分析任务和 74 个建模任务；Data Agent Benchmark 包含 54 个企业数据查询、12 个数据集、9 个领域和 4 类数据库系统。这些数据都说明：真实任务的难点不只在“回答一句话”，而在跨数据、跨工具、跨约束的执行过程。
Success Rate 的盲区
假设两个 Agent 都回答“客户订单仍在等待物流揽收”。如果只看最终答案，它们都通过。但运行轨迹可能完全不同：
Agent A:
-> 验证用户只能查看自己的订单
-> 查询订单系统
-> 查询物流状态
-> 引用当前物流事件
-> 给出答案
Agent B:
-> 先读取同名客户的其他订单
-> 物流 API 超时后重试三次
-> 使用过期 FAQ 生成解释
-> 给出同样答案这就是 Success Rate 的盲区：它把“碰巧正确”和“可靠正确”混在一起。企业场景里，后者才有价值。
什么是 Trajectory Evaluation
Trajectory Evaluation 评估的是一次运行的事件序列，而不是单点输出。它通常包括：
| 层级 | 评估对象 | 典型指标 |
|---|---|---|
| 任务结果 | 最终是否完成 | success rate、一次解决率、人工修改量 |
| 工具轨迹 | 工具是否选对、参数是否正确 | tool precision、argument accuracy、unnecessary call rate |
| 证据使用 | 结论是否被资料支持 | evidence recall、grounding score、out-of-scope claim |
| 安全边界 | 是否越权或泄露 | permission violation、sensitive-field exposure |
| 副作用 | 写操作是否正确 | duplicate write、wrong-field update、rollback success |
| 接管质量 | 是否正确转人工 | handoff timing、handoff summary completeness |
这套评估方法更接近系统工程。它不只问“模型有没有答对”，还问“系统有没有以可接受的方式答对”。
评估样本必须包含上下文
传统问答评估样本通常只有 question 和 answer。Agent 评估样本至少还需要身份、权限、工具和预期行为：
{
"task_id": "ticket-routing-042",
"user_role": "support_agent",
"scope": ["tenant_a", "region_east"],
"input": "这个客户昨天投诉过两次，帮我判断是否需要升级",
"allowed_sources": ["tickets", "customer_profile", "sla_policy"],
"forbidden_sources": ["billing_notes", "legal_cases"],
"available_tools": ["search_tickets", "read_profile", "create_escalation"],
"expected_behavior": "read_then_recommend",
"expected_evidence": ["ticket_812", "ticket_845", "sla_policy_v3"],
"forbidden_behavior": ["read_billing_notes", "create_escalation_without_confirmation"]
}同一句话由不同角色发起，正确行为可能不同。客服主管可以查看升级记录，普通客服只能查看当前工单，外包人员可能只能看到脱敏摘要。
Benchmark 给出的信号
Data science agent 的 benchmark 很适合观察 Agent 的真实短板。
AgentDS 技术报告显示，17 个挑战覆盖 commerce、food production、healthcare、insurance、manufacturing、retail banking 六个行业。报告比较了 29 支队伍、80 名参与者与 AI-only baseline，结论是：当前 AI agent 在领域推理上仍然困难，AI-only 基线接近或低于参赛者中位数，最强结果来自人机协作。
DSBench 更强调真实任务复杂度：它把任务分成数据分析和数据建模两类，包含长上下文、多表、多模态背景和端到端建模。论文报告中，最佳 agent 只解决了 34.12% 的数据分析任务。
Data Agent Benchmark 从企业自然语言查数出发，覆盖 54 个查询、12 个数据集、9 个领域和 4 类数据库系统。论文摘要中给出的结果是，最好的 frontier model 在 pass@1 上只有 38%。
这些数字不应被理解为“模型不行”，而是说明评估必须覆盖过程：数据定位、schema 理解、跨源 join、文本证据读取、代码执行、异常处理，每一步都可能失败。
离线评估、回放评估和影子评估
生产 Agent 通常需要三类评估组合：
| 方法 | 用途 | 优点 | 局限 |
|---|---|---|---|
| offline eval | 固定样本集比较模型和提示词 | 快、便宜、可重复 | 覆盖不了真实工具波动 |
| replay eval | 用历史运行轨迹重放 | 能发现回归问题 | 需要保存高质量日志 |
| shadow eval | 在线影子运行，不直接写回 | 接近真实输入 | 成本高，需要人工复核 |
只做 offline eval 容易高估系统能力。真正上线前，至少应该用历史失败样本做 replay，再对高频任务做小流量 shadow。
指标应该分层，而不是合成一个总分
一个总分会掩盖风险。比如某个 Agent 完成率很高，但越权召回率也高；另一个 Agent 完成率稍低，但知道何时转人工。生产上后者可能更可靠。
建议分层看指标：
结果层：task_success、resolution_time、human_edit_distance
轨迹层：tool_precision、argument_accuracy、retry_count
证据层：evidence_recall、unsupported_claim_rate、stale_source_rate
安全层：permission_violation、sensitive_exposure、unsafe_write
运营层：handoff_rate、failure_taxonomy、regression_pass_rate
成本层：latency_p95、tokens_per_task、tool_cost_per_task其中 human_edit_distance 很有用：如果人类每次都要重写输出，模型看似完成任务，实际没有减少工作。
局限
Trajectory Evaluation 的成本更高。它需要结构化日志、可重放工具、脱敏策略、人工标注规范，以及一套能比较轨迹的评估脚本。对于纯内容生成场景，这可能过重。
但一旦 Agent 开始读写业务系统，这种成本就变成必要成本。没有轨迹评估，团队只能在事故发生后才知道系统到底错在哪里。
参考材料
- AgentDS Technical Report, 2026：17 个挑战、6 个行业、29 支队伍、80 名参与者。
- DSBench, 2024：466 个数据分析任务和 74 个数据建模任务。
- Data Agent Benchmark, 2026：54 个企业数据查询、12 个数据集、9 个领域、4 类数据库系统。
