Agent Seer：从工具规格自动合成Agent评测场景

工具型Agent评测场景自动合成

于 2026-08-30 04:11:58 修改

·本内容遵循CC 4.0 BY-SA版权协议

Agent Seer 这个名字，核心指向一个很具体的问题：当我们要评测一个会调用工具的大模型 Agent 时，评测场景从哪里来。常见做法是人工构造几百上千条任务，让 Agent 去执行工具调用，再人工判断它做没做对。这个做法最大的问题是场景一旦固定，评测就容易失真，而且每加一个新工具，就要手工补一批新场景。Agent Seer 的思路是把工具规格本身当作输入，让系统理解工具的输入输出、参数约束、依赖关系和可能出错的地方，再自动合成评测场景。这样一来，评测场景的生成不再依赖人工逐条编写，而是可以跟着工具集走：工具更新，场景跟着更新；工具变多，场景数量可以更快放大。

我对这一类自动评测合成的判断是：它不会完全取代人工评测，但会在工具型 Agent 的回归测试和模型对比里变成一个很实用的环节。下面按“为什么需要、核心思路、落地流程、场景类型、评测指标、运行细节、边界坑点”这个顺序拆开讲。原文材料没有给出具体版本和代码，所以本文里涉及实现的部分都按通用实践展开，落地时以你自己的工具格式和评测目标为准。

1. 工具型 Agent 的评测，难点到底在哪

1.1 问题不是模型不会调用工具，而是你不知道该怎么考它

现在很多 Agent 项目都支持“调用外部工具”，比如查天气、订会议室、查数据库、操作内部系统。这类 Agent 的评测和普通问答评测不一样，它有很强的结构化特征：任务要给清楚，工具调用要对，参数要填得准，返回值要能被正确使用，出错了还要能恢复。

难点之一就是评测场景的覆盖度。人工写场景时，脑子里通常会沿着“正常任务”这条线走，比如“用户想要明天下午三点的会议室”，对应一个搜索会议室、预订会议室的工具调用。但真实使用里大量问题出在参数边界和异常分支：会议室容量不够怎么办，时间格式传错怎么办，没有可用时段怎么办，多个工具组合调用时顺序错了怎么办。这些场景人工也能写，但数量有限，而且特别依赖写场景的人对这个工具集的熟悉程度。

1.2 为什么工具规格是一个值得用起来的入口

工具规格就是系统里已经存在的“契约”。不管工具是用 OpenAPI 描述，还是用 JSON Schema 描述，还是用一段函数文档描述，它本身就包含了字段名、类型、必填项、可选范围、默认值、依赖关系、返回值结构。这些东西恰好是评测场景生成最需要的原材料。

从工具规格出发，比从“用户自然语言任务”出发更容易控制场景的确定性。比如规格里写了参数 capacity 是 integer，最小值 1，最大值 50，那系统就能围绕这个约束生成合法值和非法值，然后设计出“正常预订”“容量参数越界”“容量传成字符串”这几类不同场景。这种做法不需要有人去头脑风暴，只需要规格够完整。

这也是 Agent Seer 这类方法最值得关注的地方：它不是靠大模型随便生成一堆用户问题，而是先理解工具规格，再在规格约束里合成场景。前者随机性强，后者可控性强。

1.3 自动合成场景，本质上是把评测变成一种可再生的资产

我理解 Agent Seer 的价值不在于“生成速度快”这一个点，而在于评测场景从一次性人力投入，变成了可以跟着工具集持续更新的资产。新接入一个工具，跑一遍解析和生成流程，评测集就多出一批相关场景；工具升级了参数，再跑一遍，旧场景也能跟着调整。

这里要有一个预期：自动合成出来的场景不能保证每一条都完美，它更像一个“先自动化铺底，再人工抽样修正”的流程。铺底铺得越广，后面的抽样修正越有意义。

2. Agent Seer 的核心思路：工具规格是怎么变成评测场景的

2.1 第一步不是生成，而是理解

很多自动生成评测任务的做法是“给模型一段工具描述，让它编几个问题”。Agent Seer 的思路更强调先做结构化理解。工具规格里不是只有字段名和类型，还需要把下面这些信息抽出来：

输入参数：类型、必填还是选填、取值范围、格式要求、参数之间是否有依赖。
输出结构：返回字段、嵌套结构、成功状态和错误状态怎么区分。
副作用：这个工具调用会改变系统状态，还是只读查询。比如“创建订单”和“查询订单”在评测里性质完全不同。
前置条件：调用前需要先完成什么，比如需要先登录、先创建会话、先拿到某个 ID。
工具间关系：某个工具的输出是否会被另一个工具当作输入，是否存在调用顺序约束。

只有把这些信息整理成结构化表示，后面的场景合成才有约束可依。否则生成出来的场景很容易出现“工具根本处理不了”或者“执行到一半就必然失败”的情况。

2.2 合成评测场景的几条主线

把理解到的规格信息组合起来，就能沿几条主线合成场景：

正常流程：给定合法输入，要求 Agent 正确调用工具并完成任务。
边界条件：参数接近最小值、最大值、空值、超长文本、特殊字符、重复提交。
参数错误：缺少必填参数、传了错误类型、范围越界、格式不对。
组合调用：一个任务需要连续调用多个工具，前一个工具的输出传给后一个工具。
状态依赖：某一步失败后如何重试，或者需要先完成前置步骤。
用户表达歧义：同一个工具调用意图，用不同自然语言表达出来。

这几条主线覆盖了工具型 Agent 最常见的失败模式。实际落地时，我的建议是先把正常流程和参数错误这两类做扎实，再扩展组合调用和状态依赖。不要一上来就追求生成特别复杂的多工具场景，因为复杂场景一旦出问题，你很难判断是“场景本身有问题”还是“Agent 能力不够”。

2.3 合成出来的不是题面，而是完整评测用例

这里容易有一个误解：以为合成场景就是生成一段用户问题。实际上评测用例里至少还要包含工具调用的预期结果和判断标准。

一个完整用例通常包括：

任务描述：给 Agent 看的自然语言指令。
可调用工具集：这次评测允许使用哪些工具。
初始状态：是否需要先准备数据、登录态、前置记录。
预期结果：完成标志是什么，比如正确调用某个工具、参数值正确、返回结果被正确处理。
判分规则：任务成功、参数正确、工具选择正确、失败后是否恢复。

没有这些信息，生成再多的用户问题也没办法自动化判分。这也是我认为 Agent Seer 这类系统最有工程价值的部分：它把“场景生成”和“判分规则”放在一起合成，而不是只生成题面。

3. 实际落地时，解析和生成流程可以怎么设计

3.1 工具规格的解析与规范化

第一步是把各种来源的工具描述统一成一份结构化中间表示。比如一份 OpenAPI 定义里，一个接口通常包含 method、path、parameters、requestBody、responses。一份函数文档则可能有函数名、参数列表、返回值说明。

可以先把工具描述转成类似下面这样的统一结构：

JSON

{

"tool_id": "booking.create",

"description": "创建会议室预订",

"parameters": {

"room_id": {"type": "string", "required": true, "format": "uuid"},

"start_time": {"type": "string", "required": true, "format": "datetime"},

"end_time": {"type": "string", "required": true, "format": "datetime"},

"capacity": {"type": "integer", "required": false, "minimum": 1, "maximum": 50}

"output": {

"booking_id": {"type": "string"},

"status": {"type": "string", "enum": ["confirmed", "rejected"]}

"side_effect": true,

"preconditions": ["auth.login"]

}

这一步不需要模型，用规则解析就行。重点是把每个参数的约束、返回结构、副作用和前置条件都提取出来。如果原始规格本身写得模糊，解析出来的中间结构也会模糊，后面生成场景的质量就不可控。

这个阶段建议加一个校验环节：把解析结果和原始规格做一次抽样对比。因为 OpenAPI 文件有时候嵌套层级很深，解析器容易漏字段，尤其容易漏掉 response 里的错误结构。

3.2 场景合成的最小流程

拿到规范化结构后，可以按“种子参数 → 约束变换 → 任务描述构造 → 预期结果生成 → 可用性过滤”的顺序生成场景。

先说种子参数。每个参数都可以先取一组合法值作为种子，比如 room_id 取一个测试用 UUID，start_time 取明天上午 9 点。然后对种子做约束变换：改成边界值、改成空值、改成错误类型、改成超长值。变换的时候要保留记录，这样你才知道这条场景是在测哪个点。

预期结果生成可以分两种方式。规则明确的，比如参数校验类场景，预期结果就是当前工具返回参数错误，这类用模板直接生成。需要推理的，比如组合调用场景，可能需要借助大模型来补全中间步骤，但最终还要人工或者规则确认。

下面给一个通用流程示意，不是某个具体系统的实现：

PYTHON

def synthesize_scenarios(tool_spec):

scenarios = []

for param_name, param in tool_spec["parameters"].items():

valid_values = build_valid_values(param)

invalid_values = build_invalid_values(param)

for value in valid_values:

scenarios.append(scenario_happy_path(tool_spec, param_name, value))

for value in invalid_values[:5]:

scenarios.append(scenario_param_error(tool_spec, param_name, value))

# 组合调用和状态依赖场景单独处理

scenarios += scenario_multi_tool(tool_spec)

return filter_valid_scenarios(scenarios)

这个流程看起来简单，但有一个关键点：不要用同一个模板套所有工具。不同工具的参数语义差很多，比如 capacity 是个整数，但时间参数有前后顺序约束。模板只能负责结构，具体约束必须来自工具规格本身。

3.3 场景有效性校验：生成完不等于能用

合成出来的场景，至少要做三层过滤：

可执行性：场景里的工具调用在初始状态下能真正执行，不会因为缺少前置条件而必然失败。
预期正确性：预期结果和工具实际行为一致，不能出现“Agent 明明调用对了，但预期结果写错了”的情况。
非退化性：场景不能太简单，比如用户指令直接等价于工具名，这样测不出 Agent 的理解和推理能力，只测出两个字面匹配。

非退化性这个点最容易忽略。你生成一百条场景，可能其中三四十条是“用户说查天气，Agent 调天气工具”这种直给任务，区分度很低。要让它有区分度，就得在任务描述里加一层自然语言转写，加一点约束隐含，甚至加一个需要 Agent 自己判断该不该调用工具的场景。

这里可以多加一句经验：如果生成出的场景里，大量任务的用户指令和工具描述几乎一字不差，说明合成策略偏简单了。建议在任务描述构造环节引入“意思相同但说法不同”的重写，同时保留原始判定逻辑。

4. 评测场景有哪些类型，质量怎么判断

4.1 一张表看清常见合成场景类型

我把工具型 Agent 评测里最常见的合成场景大概分成六类：

场景类型	典型内容	主要考察点	适合生成方式
正常流程	用合法参数完成一次工具调用	工具选择、参数填充、结果使用	模板 + 合法种子值
边界参数	参数取最小值、最大值、空字符串	边界理解、精度处理	规则变换
参数异常	缺少必填、类型错误、越界	错误处理、提示生成	规则变换
用户表述歧义	间接表达工具意图	意图识别、口语化理解	大模型改写
多工具组合	按顺序调用多个工具，输出接力	过程规划、中间结果传递	依赖图扩展
失败恢复	某次调用失败后重试或换方案	异常恢复、鲁棒性	状态注入 + 场景编排

实际评测时，我不建议六类场景平均分配。正常流程和参数异常通常应该是主体，大约占一半；边界参数和用户表述歧义各占两成；多工具组合和失败恢复数量可以少一点，但难度和权重可以更高。

4.2 场景质量的五个判断标准

给一条合成场景打分，我看五个维度：

可解性：在正确调用工具的前提下，任务确实能完成。
确定性：同一条场景不会因为初始状态不同而出现两个互相矛盾的预期结果。
区分度：能力强和弱的 Agent 在这条场景上应该有明显表现差异。
覆盖度：整套场景是否覆盖了工具规格里的关键参数、异常分支和工具间关系。
可复现性：同样的评测跑两遍，结果基本一致，不能因为时序、并发、随机性导致评分波动。

这五个标准里，确定性是工程上最容易被破坏的。举例来说，一个查询库存的工具，如果初始状态没有固定库存数量，Agent 查询结果就不确定，预期结果也没法写死。合成场景时必须给工具准备固定的初始数据，否则这条场景只能做过程判断，不能做结果判断。

4.3 判断“这条场景有没有价值”的三条经验

我个人的经验是这样：一条评测场景有没有价值，先看它能不能区分出不同能力的 Agent，再看它会不会误伤正确行为。

“误伤正确行为”特别麻烦。比如你设计了一条场景，要求 Agent 必须先查询再预订，但实际业务里用户可能已经知道会议室 ID，直接预订也是合理的。如果场景预期写死了调用顺序，一个更聪明的 Agent 反而被判错。

为了让场景更稳，预期结果里要区分“必要约束”和“倾向性约束”。必要约束是必须满足的，比如最终结果正确、必填参数合法；倾向性约束是标注但不强制，比如调用顺序可以不同、查询次数可以不同。评测打分时，必要约束占主要权重。

5. 从单工具到多工具：难度分级和评测指标怎么设

5.1 先给场景分难度等级

同样是从工具规格合成场景，难度差别可以很大。我把合成场景的难度分成三档：

基础档：单工具，直接调用，参数合法。适合验证 Agent 能不能理解工具接口。
进阶档：单工具或双工具，包含参数歧义、边界条件、失败重试。适合验证 Agent 的稳定性。
困难档：多工具串联，需要从问题描述中拆出多个步骤，并且在中间失败时重新规划。适合验证 Agent 的规划和恢复能力。

分难度等级有个非常实际的好处：模型迭代时可以先看基础档有没有退化。基础档分数下滑，通常意味着工具理解能力有问题，而不是规划能力有问题。困难档则更适合在能力比较接近的两个版本之间做对比。

这里提醒一句：不要用同一个评测集给所有模型横排，然后直接说谁强谁弱。不同模型对工具描述格式的敏感度不一样，有的模型善于处理 JSON 格式的工具描述，有的更擅长自然语言描述。评测时至少要用一致的输入格式，或者同时提供 JSON 和自然语言两种描述，避免把“格式适应能力”当成“工具调用能力”。

5.2 评测执行阶段要记录什么

评测执行器要做的事情不复杂：给 Agent 发任务，允许它调用指定工具，收集它的工具调用序列和最终回复，再按判分规则打分。但执行阶段记录的字段越细，后面分析越容易。

建议至少记录这些字段：

场景 ID 和场景类型。
初始状态，包括预置数据和工具状态。
Agent 的完整调用序列，包括每次调用的工具名、参数和返回值。
关键步骤是否命中预期，比如参数正确性、工具选择正确性。
最终结果是否正确。
任务耗时、调用次数、重试次数。
Agent 的中间思考信息和最终回复。

有了这些记录，你才能回答“分数没变但能力变了”这类问题。有时候某个版本成功率没变，但调用次数变多了，说明 Agent 虽然在兜底，但效率下降了。不记录调用轨迹，这类问题根本发现不了。

5.3 指标设计要围绕评测目标走

评测指标不要只放一个成功率。工具型 Agent 评测至少要覆盖三个层面：

任务成功率：最终任务完成的比例。
工具调用准确率：每次工具选择是否正确，参数是否合法。
效率和恢复能力：平均调用次数、失败后重试成功率、无意义重复调用比例。

另外还有一个容易被忽略的指标：合法调用率。也就是 Agent 发起的工具调用中，有多少是工具规格允许的。有的 Agent 在拿不准时会出现幻觉，调用一个并不存在的工具，或者强行填充一个不存在的参数。这个指标对工具型 Agent 尤其重要，因为它在真实业务里会直接变成线上报错。

合成评测集最大的优势就在这里：因为场景里的工具集和规格都是固定的，你可以轻松统计“非法调用次数”。这在开放域问答评测里很难做到，但在工具评测里是必要指标。

6. 接入评测流程后，运行细节最容易出问题

6.1 最小可运行流程：先跑通一条，再跑整套

我建议把 Agent Seer 这类评测框架的落地拆成四步：

解析：把工具集转成统一结构，出一次解析报告，人工抽检 20 到 30 个工具描述。
生成：按场景类型分别生成，先只生成正常流程和参数异常两类。
校验：跑一次“伪执行”，也就是用脚本模拟工具返回值，确认预期结果和工具行为一致。
评测：接上真实 Agent 和真实工具环境，先跑 10 条场景，确认日志、判分、输出目录都正常。

不要跳过第 3 步。用真实工具环境直接验证场景，出问题时你分不清是场景的问题还是 Agent 的问题。先用脚本模拟工具，确保场景本身可解，再换真实 Agent，排查链路就清晰很多。

6.2 批量评测时的队列、命名和重试

场景数量一旦上百，批量评测就要注意几个工程问题。

首先是任务队列。不要全部并发执行，尤其是评测工具带副作用的时候。并发会带来状态竞争，比如两条场景同时改同一个会议室状态，结果就不可复现了。我自己一般先把所有场景排成队列，限制并发数在 4 到 8，根据工具响应速度和 Agent 推理速度调整。

其次是输出命名。每条场景生成的日志、轨迹、结果文件，命名里至少要包含场景 ID 和场景类型。不要只用时间戳，否则排查某一条具体场景时，很难定位到对应日志。

然后是重试策略。评测时网络抖动、工具临时故障都可能造成误判。我建议区分“ Agent 主动重试”和“评测框架重试”。评测框架重试只应在基础设施异常时触发，比如网络超时、服务不可用；Agent 自己的失败恢复是评测对象，不能由框架代劳，否则成功率就虚高了。

6.3 常见问题排查顺序

如果评测结果异常，先不要怀疑 Agent 能力，按这个顺序排查：

看场景本身：初始状态是否正确，预期结果是否和工具行为一致。
看输入格式：任务描述是否有歧义，工具描述是否被完整传给 Agent。
看判分逻辑：判分规则是否太严，把正确行为误判成错误。
看资源占用：并发是否过高，工具服务是否被压垮。
看版本一致：Agent 用的工具描述和评测环境里的工具规格是不是同一个版本。

这个排查顺序里，第 1 步最常见。很多时候不是 Agent 不行，而是场景里的初始状态没有写好。比如一条场景假设“系统里已经存在一间可预订的会议室”，但评测环境运行到这条时，那间会议室已经被上一条场景占用了。这种问题不查状态，查一天 Agent 也查不出结果。

6.4 日志设计要让人能“顺藤摸瓜”

评测日志不要只记最终得分。每条场景的日志里，至少要把工具调用序列和每一步的输入输出串起来。我常用的做法是给同一场景的所有相关事件打同一个 request_id，然后按时间顺序记录事件流。

日志格式不用太复杂，但字段要稳定：

JSON

{

"request_id": "scenario_0027",

"event_type": "tool_call",

"tool_name": "booking.create",

"arguments": {"room_id": "room_a", "start_time": "2026-01-01 09:00"},

"result": {"status": "confirmed"},

"elapsed_ms": 830

}

有了这种日志，排查时只需要按 request_id 过滤，就能看到 Agent 从理解任务到最终完成的全过程。没有这个过程记录，你只能知道“错了”，但永远不知道“错在哪一步”。

7. 边界和坑点：合成评测能做什么，不能做什么

7.1 合成评测解决不了所有评测问题

从工具规格合成场景，本质上是从“系统的能力范围”出发，而不是从“真实用户的行为”出发。它擅长测工具的契约理解、参数处理、调用顺序，但不擅长测真实世界里的开放性问题。

比如真实用户可能会问“明天那个重要的客户要来，帮我安排一下”，这句话里隐含了查客户信息、查会议室、考虑客户偏好等多个环节，而且每个环节都充满不确定性。工具规格里没有“客户重要程度”这个字段，合成系统很难自动构造出这类任务背后的真实意图。

另一个边界是长期任务。Agent Seer 这类方法合成的场景通常可以在几步到十几步内完成。如果评测目标是测一个需要执行半小时、中间跨多个异步回调的 Agent，单纯从工具规格合成场景就不够，还需要在评测环境里模拟异步事件、超时和状态变化。

7.2 和真实样本结合，才是更稳的使用姿势

我的建议是不要把合成评测当作唯一评测来源，而是把它和三类真实样本结合：

线上日志里抽取的真实用户请求，保留真实表达的随意性和隐含信息。
人工编写的核心场景，用来覆盖业务上最重要、最不能出错的链路。
合成场景，用来做大范围覆盖和回归。

这个组合的好处是：真实样本保证评测和实际业务相关，人工场景保证重点链路有明确预期，合成场景保证覆盖度和更新速度。三者各管一段。

7.3 真正落地时，最该盯住的是什么

如果要给一个最直接的建议，我会说：对 Agent Seer 这类自动合成评测方案，最该盯住的不是“能生成多少条场景”，而是“生成出来的场景有没有经过有效性校验，判分规则是否和工具行为一致”。

很多项目把场景生成当成一个数量游戏，生成了几千条评测用例，结果里面一大半是可解性存疑、预期结果模糊的垃圾场景。用这样的评测集去对比模型，得到的结论没有参考价值。宁可生成 300 条经过校验的高质量场景，也不要生成 3000 条来源不明的低质量场景。

在我看过的不少工具型 Agent 项目里，真正把模型压垮的往往不是“不知道怎么调用工具”，而是评测场景本身的问题：初始状态没固定、预期结果写得太死、工具版本没对齐。把这些问题先清干净，再去讨论模型能力才有意义。

如果你现在正打算做一个工具型 Agent 的评测体系，不妨先按这个顺序走：选一个固定的小工具集，写清楚工具规格，让生成系统产出第一批正常流程和参数异常场景，人工抽检校正，跑出一份基线分数。然后再慢慢扩展边界和多工具场景。这样每一步都有明确反馈，也最容易发现问题出在生成环节、执行环节还是判分环节。