Agent 评测与仿真沙盒实战：从工具调用到长程任务评估

一个完整的 Agent 评测体系，至少要从三个维度打分。第一是能力：任务完成率，也就是 Agent 在多少任务上拿到了正确结果，这是最核心的指标。第二是可靠性：包括格式合规率（是不是总能输出合法的工具调用）、危险操作率（有没有调用不该调的工具）、以及面对错误结果时能不能自我纠错。第三是效率：完成一个任务平均调用多少次工具、消耗多少 Token、多少轮交互——两个完成率相同的 Agent，效率高的那个在生产环境里明显更有价值。

三个维度要一起看，不能只看完成率。一个 Agent 可能完成率很高，但代价是每个任务都疯狂调用工具碰运气，这样的 Agent 成本爆炸，上线即亏损；另一个 Agent 完成率稍低，但每步都稳，配合人工兜底反而更好用。评测报告里应当同时呈现三个维度的指标，让决策者看到完整的画像。

评测集是评测体系的地基，每个用例至少包含三部分：任务描述（告诉 Agent 要做什么）、环境初始状态（有什么工具、什么数据）、黄金答案（正确结果或达成目标的可判定条件）。任务描述要贴近真实使用场景，不能只出「请问天气」这种一眼看穿的问题；环境初始状态决定了任务能不能复现，同一个任务在不同初始状态下跑出来的轨迹没有可比性；黄金答案要可自动判定，否则评测没法规模化。

难度分级也很重要。如果评测集里全是简单任务，完成率 95% 也说明不了什么；全是超难任务，完成率 10% 同样没有区分度。好的做法是按难度分层：简单任务验证基本功，中等任务看日常表现，困难任务测上限，并分别记录三个层级的完成率。随着 Agent 能力提升，还要持续往评测集里补充更难的任务，让评测集和 Agent 一起成长。

# 评测用例的数据结构（伪代码）
# {
#   "task": "查询订单 1024 的物流状态并生成一条摘要",
#   "env":  {"tools": ["query_order", "send_message", "web_search"]},
#   "gold": {"result_must_contain": ["已发货", "预计到达"]},
#   "level": "medium",
#   "side_effect_guard": ["禁止调用 send_message 之外的写操作"]
# }

工具调用是 Agent 评测里最容易出问题也最需要细查的部分。所谓协议正确性，就是 Agent 有没有按工具定义来调用：参数名对不对、必填参数齐不齐、参数类型合不合规、有没有调用了不存在的工具。这些问题不用看结果，直接从调用记录里就能规则化检查出来，是性价比最高的自动化评测项。

比参数错误更危险的是副作用问题。Agent 可能做对了主任务，但在过程中执行了不该执行的写操作：删了不该删的数据、给用户发了多余的私信、调用了高权限接口。评测集要为每个用例声明「副作用守卫」：允许哪些写操作、禁止哪些，评测时对整条轨迹逐条检查。这是 Agent 上线前必须过的安全关，只测最终结果正确与否，是远远不够的。

# 工具调用轨迹的规则检查（伪代码）
# 1. 遍历 Agent 的每一次工具调用记录
# 2. 检查工具名是否存在于工具表（不存在 → 幻觉调用）
# 3. 检查参数是否满足 JSON Schema（缺必填、类型错 → 格式违规）
# 4. 检查是否触发副作用守卫（越权写操作 → 危险操作）
# 5. 汇总三类违规数，计算格式合规率与危险操作率

单轮工具调用测的是「会不会用工具」，长程任务测的是「能不能完成一件事」。真实场景里的 Agent 任务往往要十几步甚至几十步：查资料、做计划、调多个工具、根据中间结果调整策略。评测长程任务，需要先把真实环境「仿真化」：在沙盒里复刻一个可控版本的工具服务、数据源和用户交互入口，让 Agent 在里面完整跑一遍任务，而不是只给一个静态问题。

仿真沙盒有三个好处：一是安全，Agent 在里面随便折腾都不会影响真实数据；二是可控，初始状态、工具行为、意外情况都可以按用例精确设定；三是可复现，同一用例可以在不同模型版本上反复跑，保证对比公平。长程任务评测除了看最终完成率，还要看轨迹质量：是否绕了远路、是否在关键节点做出了合理决策、失败时能否有效恢复。轨迹评估把「结果指标」和「过程指标」结合起来，才真正反映 Agent 的成熟度。

仿真沙盒是 Agent 评测的「试验场」：安全、可控、可复现，让长程任务的轨迹评估成为可能。