从工具规格到评测场景：Agent Seer自动合成评测数据实战

Agent Seer 实战如何从工具规格中自动合成评测场景作为一名长期做 Agent 应用开发和评测的技术博主我最近一直在研究一个方向如何系统化地评测 Agent 的工具调用能力。手写测试用例成本高、覆盖不全而且一旦工具接口变化维护量就非常大。于是我把目光放到了 Agent Seer 这套思路上——从工具规格理解出发程序化合成评测场景把“评测样本生产”从纯手工变成“半自动流水线”。本文就围绕这套思路从核心概念、流程设计、工程实现到常见坑位完整拆解一遍适合正在做 Agent 评测平台、工具调用型 Agent 项目或者对 LLM 应用测试体系感兴趣的开发者。1. 背景Agent 评测为什么越来越难1.1 从“模型答题”到“Agent 干活”传统的 NLP 评测比如文本分类、阅读理解、翻译本质上是在测“模型能不能答对一道题”。输入是文本输出是文本打分规则相对固定。但到了 Agent 时代事情发生了变化。大模型不再直接输出最终答案而是需要根据用户指令决定调用哪个工具、填入什么参数、处理什么返回值。比如用户说“帮我查一下明天上海的最高气温”模型可能需要先调用一个天气查询工具传参city上海、date明天拿到结果后再组织成自然语言回复。这就带来了评测层面的新问题模型的输出结构从“一段文本”变成了“结构化工具调用序列”正确性判断从“语义是否一致”变成了“工具是否选对、参数是否合法、调用顺序是否合理”评测数据需要同时覆盖任务描述、期望工具调用、期望参数、可能的异常分支复杂度远高于普通问答数据。所以Agent 评测本质上是在测“模型在真实任务环境中的行为表现”而不是单纯的“模型知识量”。1.2 手工评测数据的三个痛点早期做 Agent 评测数据集常见做法是找标注人员写一批“用户指令 期望工具调用”的样本。这种做法的痛点非常明显成本高。一份高质量样本不仅要有用户问题还要有准确的工具调用参数、边界情况和错误分支标注一个人的产出效率远低于普通文本标注。覆盖不全。手工写样本时很容易集中在最常见的几条路径上比如“查询天气只查当天”却忽略了“日期参数格式错误”“城市名为空”“温度单位传了非法枚举值”这些边界场景。维护困难。工具接口一改参数名或者新增了一个枚举值所有手工样本都要跟着改。一次接口升级可能让人想辞职。这三个痛点恰好是合成数据能够发挥作用的地方。1.3 Agent Seer 的核心思路Agent Seer 的思路可以概括为一句话把工具规格tool spec当作唯一事实源从中自动推导出评测场景。也就是说与其让标注员想象“用户会怎么用这个工具”不如让程序直接读取工具的参数定义、类型约束、必填字段、枚举范围然后根据这些约束批量生成合法参数、边界参数和非法参数再包装成自然的用户任务描述最终形成一份结构化的评测集。这样做有三个明显的好处工具规格本身就是结构化数据机器容易解析天然适合程序化处理参数约束决定了评测场景的边界从约束出发能覆盖到手工标注容易漏掉的情况工具接口变化时只要重新跑一遍生成流程就能得到与最新规格匹配的评测集。下面我把这套思路拆解开逐步说明它到底是怎么落地实现的。2. 核心概念拆解2.1 工具规格是什么这里的“工具规格”不是指自然语言写的使用说明书而是指结构化、机器可读的工具接口描述。常见的形式有三种OpenAI Function Calling 格式用 JSON Schema 描述参数OpenAPI Specification整套 REST API 的接口定义企业内部自研的 Tool Registry通常也是 JSON 或 YAML 格式。不管哪种形式核心信息都包含信息项说明示例工具名称模型调用时使用的唯一标识get_weather工具描述说明工具的作用帮助模型选择工具查询指定城市未来几天的天气参数类型每个参数的数据类型string、integer、array参数约束枚举、范围、长度、正则等unit: [celsius, fahrenheit]必填参数调用时必须提供的参数列表required: [city]在 Agent Seer 的流程中工具规格是整个评测场景生成器的“输入源”。所以第一步永远是把工具规格整理成标准格式并确保它的描述足够清晰。2.2 评测场景的组成要素一份可用的 Agent 评测场景不能只是“用户问一句话”。它至少需要包含以下要素用户任务描述一段自然语言指令模拟真实用户的需求期望工具调用模型应该调用哪个工具、传入什么参数场景类型属于正常场景、边界场景还是异常场景检查点评测时重点检查哪些参数以及使用什么规则判断正确难度标签便于后续做分层分析比如 easy / medium / hard。把评测场景结构化之后评测系统才能根据“期望工具调用 检查点”自动打分而不是靠人工去看模型的输出。2.3 “合成”不等于“编造”说到合成数据很多人的第一反应是“这是不是让 AI 随便编”其实不是。Agent Seer 里的“合成”强调的是基于约束的程序化生成。合成的基础是工具规格中的参数约束不是凭空想象生成的场景必须满足规格约束合法性可以用 JSON Schema 校验器验证合成过程需要可控比如指定生成数量、场景类型比例、随机种子对于纯程序生成不了的自然语言描述可以用模板 LLM 改写来辅助但核心结构仍然由程序控制。换句话说合成评测场景是一个“规则在前、生成为辅”的流程而不是让 LLM 随意自由发挥。3. 从工具规格到评测场景整体流程设计3.1 流程总览一次完整的评测场景合成流程可以拆成六个步骤读取工具规格加载 JSON Schema 或 OpenAPI 描述解析参数约束提取参数类型、必填项、枚举、范围、默认值生成基础参数组合根据约束随机组合合法参数构造边界与异常参数生成边界值、缺失参数、类型错误、枚举外值等渲染自然语言任务把参数组合填入任务模板形成用户指令校验并导出用 JSON Schema 校验正例合法性负例则校验其“确实非法”最后去重导出。需要注意的是这六个步骤并不是顺序执行一遍就结束。实际工程中第 3 到第 5 步往往需要循环多轮直到生成足够数量且不重复的场景。3.2 场景分类体系在设计生成器前先确定场景分类。我的经验是至少分为五类场景类型说明例子正常场景参数完全合法直接调用即可查询今天北京的天气默认值场景用户省略了有默认值的参数只提供城市温度单位用默认值边界场景参数值位于约束的上限、下限字符串长度为最大长度缺失参数场景缺少必填参数只提供了城市没提供日期非法参数场景参数值不满足约束温度单位传了kelvin3.3 正例与负例的生成策略正例生成是核心。基本思想是先枚举合法参数域再按参数域做笛卡尔积然后采样组合。如果参数域很大可以配合随机采样来避免组合爆炸。负例生成则更讲究技巧。常见的策略包括直接删除必填参数把参数值替换成其他类型传入枚举定义之外的值构造超过最大长度的字符串传入不匹配正则格式的字符串传入空字符串、null、空数组等边界值。负例的价值在于评测 Agent 的“抗误导能力”好的 Agent 在参数非法时应该拒绝对工具的调用或者先向用户确认信息而不是带着错误参数强行调用。4. 实战实现一个最小合成评测场景生成器下面进入实操环节。我用 Python 实现一个最小可运行的 Agent 评测场景生成器目标是从一个 JSON Schema 格式的工具规格出发自动生成正例和负例评测场景。这个示例完整展示了 Agent Seer 的核心流程。实际生产环境建议在此基础上扩展 LLM 描述改写、更丰富的参数生成策略和数据库去重。4.1 环境准备所需环境非常轻量Python 3.9 及以上jsonschema库用于参数合法性校验安装依赖pip install jsonschema我使用的jsonschema版本是 4.x如果你的环境版本较旧建议升级。版本差异通常不会影响本示例的核心逻辑。4.2 项目结构为了便于理解我按照分层设计来组织代码agent-seer-demo/ ├── specs/ │ └── weather_tool.json ├── src/ │ ├── spec_parser.py │ ├── scene_generator.py │ ├── scene_validator.py │ └── run_generate.py ├── output/ └── requirements.txt每个文件的职责如下文件职责specs/weather_tool.json工具规格定义描述天气查询工具src/spec_parser.py解析工具规格提取参数约束src/scene_generator.py生成正例、负例场景src/scene_validator.py校验场景合法性和去重src/run_generate.py主入口串联整个生成流程4.3 准备工具规格我们先定义一个天气查询工具。文件路径specs/weather_tool.json{ name: get_weather, description: 查询指定城市在指定日期的天气情况支持温度单位切换。, parameters: { type: object, properties: { city: { type: string, minLength: 2, maxLength: 32, description: 城市名称例如北京、上海 }, date: { type: string, pattern: ^\\d{4}-\\d{2}-\\d{2}$, description: 查询日期格式为 YYYY-MM-DD }, unit: { type: string, enum: [celsius, fahrenheit], default: celsius, description: 温度单位默认 celsius } }, required: [city, date] } }观察这个规格可以发现city必填长度限制在 2 到 32 之间date必填必须是YYYY-MM-DD格式unit非必填可选值只有celsius和fahrenheit默认是celsius三个参数共同构成了场景生成的约束空间。值得强调的是工具描述这段自然语言也应该写得足够清晰因为后续如果要用 LLM 辅助改写任务描述工具描述是模型理解工具行为的关键上下文。4.4 解析工具规格解析模块的职责很简单读取 JSON提取参数约束。文件路径src/spec_parser.pyimport json from typing import Any, Dict class ToolSpecParser: 解析工具规格提取生成场景所需的约束信息。 def __init__(self, spec_path: str): with open(spec_path, r, encodingutf-8) as f: self.spec json.load(f) self.tool_name self.spec[name] self.tool_desc self.spec[description] self.parameters self.spec.get(parameters, {}) self.properties self.parameters.get(properties, {}) self.required set(self.parameters.get(required, [])) def get_default_value(self, prop_name: str) - Any: 获取参数的默认值没有则返回 None。 return self.properties.get(prop_name, {}).get(default) def get_enum_values(self, prop_name: str): 获取参数的枚举值列表。 return self.properties.get(prop_name, {}).get(enum, []) def get_type(self, prop_name: str) - str: 获取参数的类型。 return self.properties.get(prop_name, {}).get(type, ) def get_min_length(self, prop_name: str) - int: 获取字符串最小长度约束。 return self.properties.get(prop_name, {}).get(minLength, 0) def get_max_length(self, prop_name: str) - int: 获取字符串最大长度约束。 return self.properties.get(prop_name, {}).get(maxLength, 0) def is_required(self, prop_name: str) - bool: 判断参数是否必填。 return prop_name in self.required def get_description(self, prop_name: str) - str: 获取参数描述。 return self.properties.get(prop_name, {}).get(description, )解析器把规格转换成了 Python 数据结构后续生成器只需要调用这些方法不需要再关心 JSON 的层级关系。4.5 生成评测场景场景生成器是整个流程的核心。文件路径src/scene_generator.pyimport copy import random from datetime import datetime, timedelta from typing import Any, Dict, List from spec_parser import ToolSpecParser class SceneGenerator: 从工具规格中合成评测场景。 def __init__(self, parser: ToolSpecParser, seed: int 42): self.parser parser self.seed seed self.random random.Random(seed) self.city_pool [北京, 上海, 广州, 深圳, 杭州, 成都, 武汉, 西安] self.scene_counter 0 def _next_scene_id(self, prefix: str) - str: 生成场景 ID。 self.scene_counter 1 return f{prefix}_{self.scene_counter:04d} def _random_date(self) - str: 生成一个合法的日期字符串范围为今天起 7 天内。 today datetime.now().date() delta self.random.randint(0, 7) target today timedelta(daysdelta) return target.strftime(%Y-%m-%d) def _build_scene(self, args: Dict[str, Any], task: str, scene_type: str, difficulty: str, valid: bool) - Dict[str, Any]: 构造一条标准评测场景。 return { scene_id: self._next_scene_id(scene), tool_name: self.parser.tool_name, user_task: task, expected_tool_call: { name: self.parser.tool_name, arguments: args }, type: scene_type, difficulty: difficulty, valid: valid } def generate_positive_normal(self, num: int 10) - List[Dict]: 生成正常场景所有参数合法。 scenes [] for _ in range(num): city self.random.choice(self.city_pool) date self._random_date() unit self.random.choice([celsius, fahrenheit]) args {city: city, date: date, unit: unit} task f帮我查一下{date} {city}的天气温度单位用{unit}。 scenes.append(self._build_scene( args, task, positive_normal, easy, True )) return scenes def generate_positive_default(self, num: int 5) - List[Dict]: 生成默认值场景省略有默认值的参数。 scenes [] for _ in range(num): city self.random.choice(self.city_pool) date self._random_date() args {city: city, date: date} task f帮我查一下{date} {city}的天气。 scenes.append(self._build_scene( args, task, positive_default, easy, True )) return scenes def generate_boundary(self, num: int 5) - List[Dict]: 生成边界场景参数值贴近约束极限。 scenes [] max_len_city 长 * self.parser.get_max_length(city) for _ in range(num): city self.random.choice([max_len_city, self.random.choice(self.city_pool)]) date self._random_date() args {city: city, date: date} task f帮我查一下{date} {city} 的天气。 scenes.append(self._build_scene( args, task, boundary, medium, True )) return scenes def generate_negative_missing_required(self, num: int 5) - List[Dict]: 生成缺失必填参数场景。 scenes [] for _ in range(num): city self.random.choice(self.city_pool) args {city: city} task f帮我查一下{city}今天的天气。 scenes.append(self._build_scene( args, task, negative_missing, hard, False )) return scenes def generate_negative_wrong_enum(self, num: int 5) - List[Dict]: 生成非法枚举参数场景。 scenes [] for _ in range(num): city self.random.choice(self.city_pool) date self._random_date() args {city: city, date: date, unit: kelvin} task f帮我查一下{date} {city}的天气用 kelvin 显示。 scenes.append(self._build_scene( args, task, negative_enum, medium, False )) return scenes def generate_negative_wrong_type(self, num: int 5) - List[Dict]: 生成类型错误参数场景。 scenes [] for _ in range(num): date self._random_date() args {city: 12345, date: date} task f帮我查一下今天 12345 的天气。 scenes.append(self._build_scene( args, task, negative_type, hard, False )) return scenes这里有几处设计值得说明。场景 ID 使用scene_0001这种格式并在生成器内部维护计数器保证 ID 唯一。正常场景里的unit参数我随机取了celsius和fahrenheit两种这是因为我需要覆盖不同枚举值对模型理解能力的影响。默认值场景则有意省略unit用来评测模型是否正确理解“参数有默认值”这一语义。负例设计上我区分了“缺失必填参数”和“非法枚举参数”。这两种负例的评测目标不同前者看模型能不能发现参数不完整后者看模型会不会无条件接受用户的指令。实际项目里还可以增加更多负例类型比如字符串超长、日期格式错误、参数为 null 等。4.6 校验与去重生成之后不能直接当评测集使用需要先校验。文件路径src/scene_validator.pyimport json from typing import List from jsonschema import Draft7Validator class SceneValidator: 校验合成场景是否满足工具规格约束并做去重。 def __init__(self, spec_path: str): with open(spec_path, r, encodingutf-8) as f: self.spec json.load(f) schema self.spec[parameters] self.validator Draft7Validator(schema) def is_valid_arguments(self, arguments: dict) - bool: 判断参数是否通过 JSON Schema 校验。 return self.validator.is_valid(arguments) def validate_scene(self, scene: dict) - bool: 根据场景的 valid 标记判断校验结果是否符合预期。 args scene[expected_tool_call][arguments] is_valid self.is_valid_arguments(args) return is_valid scene[valid] def deduplicate(self, scenes: List[dict]) - List[dict]: 按 user_task 去重保留第一条。 seen set() result [] for scene in scenes: task scene[user_task] if task in seen: continue seen.add(task) result.append(scene) return result这里要特别注意校验器的逻辑与生成器是分离的。生成器负责产生候选场景校验器负责用规格约束检验结果两者不能混在一起否则容易把生成器的 bug 带进评测集。分离设计让你可以在不修改生成逻辑的前提下独立增强校验规则。4.7 主入口最后串联整个流程。文件路径src/run_generate.pyimport json import os from collections import Counter from spec_parser import ToolSpecParser from scene_generator import SceneGenerator from scene_validator import SceneValidator def main(): base_dir os.path.dirname(os.path.dirname(os.path.abspath(__file__))) spec_path os.path.join(base_dir, specs, weather_tool.json) output_dir os.path.join(base_dir, output) os.makedirs(output_dir, exist_okTrue) parser ToolSpecParser(spec_path) generator SceneGenerator(parser, seed2024) validator SceneValidator(spec_path) scenes [] scenes generator.generate_positive_normal(10) scenes generator.generate_positive_default(5) scenes generator.generate_boundary(5) scenes generator.generate_negative_missing_required(5) scenes generator.generate_negative_wrong_enum(5) scenes generator.generate_negative_wrong_type(5) scenes validator.deduplicate(scenes) # 全部场景都应通过校验 failed [] for scene in scenes: if not validator.validate_scene(scene): failed.append(scene[scene_id]) if failed: print(f[WARN] 以下场景校验失败: {failed}) else: print(f[INFO] 全部 {len(scenes)} 条场景校验通过) type_counter Counter(scene[type] for scene in scenes) print([INFO] 场景类型分布:) for scene_type, count in sorted(type_counter.items()): print(f {scene_type}: {count}) output_path os.path.join(output_dir, eval_scenes.json) with open(output_path, w, encodingutf-8) as f: json.dump(scenes, f, ensure_asciiFalse, indent2) print(f[INFO] 评测集已导出到: {output_path}) if __name__ __main__: main()运行命令cd agent-seer-demo python src/run_generate.py预期输出大致如下[INFO] 全部 35 条场景校验通过 [INFO] 场景类型分布: boundary: 5 negative_enum: 5 negative_missing: 5 negative_type: 5 positive_default: 5 positive_normal: 10 [INFO] 评测集已导出到: output/eval_scenes.json需要提醒的是这个生成器目前依赖一份内置的城市列表实际项目中应该从业务数据源读取或者引入外部知识库来扩展实体池。4.8 输出格式说明output/eval_scenes.json中每条场景的结构如下{ scene_id: scene_0001, tool_name: get_weather, user_task: 帮我查一下2025-06-10 北京的天气温度单位用fahrenheit。, expected_tool_call: { name: get_weather, arguments: { city: 北京, date: 2025-06-10, unit: fahrenheit } }, type: positive_normal, difficulty: easy, valid: true }注意valid字段。它标记了这条场景期望模型做出的行为方向true表示模型应该成功构造工具调用false表示模型应该识别出参数异常拒绝调用或向用户确认。评测系统读取这个字段后才能自动判断模型行为是否正确。5. 评测执行与结果分析有了评测集还需要一套指标来衡量 Agent 的表现。这里给出一个适用于工具调用型 Agent 的最小指标体系。5.1 核心指标指标名称计算方式说明工具调用准确率正确调用数 / 总场景数模型最终选对工具的比例参数匹配率参数完全正确的调用数 / 总调用数在工具选对的前提下参数是否完全正确正例通过率正例中调用成功的比例反映模型完成正常任务的能力负例拦截率负例中被拒绝或正确修正的比例反映模型对非法参数的敏感度综合通过率加权平均按正负例比例加权便于横向比较5.2 结果样例假设我们跑完 35 条场景得到这样一份结果场景类型场景数通过数通过率正常场景10990%默认值场景55100%边界场景5360%缺失参数场景5240%非法枚举场景5360%类型错误场景5480%从这个结果能快速定位模型的短板。比如缺失参数场景通过率只有 40%说明模型倾向于“强行补全参数”而不是向用户确认信息这是个典型的工具调用安全性问题。5.3 分层分析的价值合成评测场景的一大优势是场景自带分层标签。通过type和difficulty两个维度可以分析模型在不同难度下的退化曲线easy 场景通过率高hard 场景骤降说明模型对复杂语义理解不足正例通过率高但负例拦截率低说明模型“太听话”不会拒绝非法请求特定工具上的参数匹配率偏低说明该工具的描述可能不够清晰需要优化工具规格文本。这类分析结论可以直接反哺到两个方向一是 Agent 的 Prompt 优化二是工具规格的描述优化。6. 常见问题与排查思路在实际落地过程中我遇到了不少问题。下面整理一份高频问题清单供大家参考。问题现象常见原因解决思路生成的场景同质化严重模板数量少、随机种子固定、实体池太小扩充实体池增加模板变体使用 LLM 对任务描述做改写负例被模型误判为正例负例设计特征不明显模型默认“用户说的都对”增加组合缺失参数、隐性类型错误等难负例并在评测提示词中要求模型识别参数合法性工具规格变更后评测集失效场景生成结果与规格强耦合没有建立依赖关系将规格版本写入评测集元信息规格变更时触发重新生成JSON Schema 校验结果与预期不符日期字符串走了当前日期而规格校验的是静态模式检查正则表达式必要时在生成器内部固定日期范围生成数量不可控参数组合空间太大或太小使用采样策略设定每类场景的目标数量场景 ID 重复多次运行生成器但没有重置计数器每次运行重新实例化生成器或在 ID 中加入运行时间戳这里重点展开第一个问题。程序化生成的场景很容易出现“换汤不换药”的情况尤其是任务描述完全依赖固定模板时。常见的缓解手段是为同一组参数准备多个不同的模板引入同义词替换和句式变换对生成后的自然语言部分调用 LLM 做 paraphrase但保留参数信息不变增加人工抽检环节确保改写后的文本语义一致。7. 最佳实践与工程建议这一节的内容来自我在实际项目中反复踩坑后总结出的经验建议收藏。7.1 把工具规格当作唯一事实源工具规格是合成评测场景的基础所以它的质量直接决定评测集质量。建议把工具规格当作代码一样管理纳入版本控制每次修改都要走评审流程。规格中以下几个信息点尤其重要参数的description要写清楚边界含义比如“日期格式为 YYYY-MM-DD”枚举值要完整不要漏掉业务上允许的值必填参数不可随意变更这是 Agent 调用行为的硬约束。7.2 场景分层要服务于评测目标不要盲目追求场景总数。先明确评测目标再确定各场景类型的比例。如果目标是评估日常任务完成能力正例应该占 70% 以上如果目标是评估 Agent 的安全性和稳定性负例比例需要提高到 50% 左右如果是模型发版前的回归测试建议正负例比例均衡并保证边界场景有一定覆盖。7.3 评测集需要与训练集隔离这一点容易被忽略。如果你用合成评测场景来评估一个模型而这些场景恰好也出现在模型的训练数据中评测结果就会虚高。工程上建议评测集独立存放加入生成时间和规格版本信息定期重新生成评测集避免模型“记住”固定题目对于需要长期对比的基准集保留一份冻结版本另建动态评测集用于迭代分析。7.4 引入 LLM 辅助但保持程序化校验LLM 可以用来改写任务描述、生成更自然的对话开场白但核心的“参数构造 合法性校验”必须由程序完成。原因很直接LLM 生成参数有随机性可能编造出规格中不存在的枚举值或者日期不合理。一个稳妥的分工是程序负责根据约束生成参数组合LLM 只负责把参数组合包装成自然语言任务最终再用 JSON Schema 对整条场景做一次终检。7.5 记录评测成本Agent 评测通常比普通模型评测贵因为一次评测要跑多轮模型调用。建议在评测系统里记录每个场景的 token 消耗单场景平均耗时失败重试次数工具调用次数与最终成功调用次数。这些成本数据不仅有助于预算管理也能帮助定位性能瓶颈。7.6 从最小闭环开始第一次落地时不要一上来就做一个覆盖几十个工具的大平台。先选一个工具比如get_weather或者一个内部查询接口把这个最小闭环跑通工具规格 → 场景生成 → 评测执行 → 结果分析闭环跑通后再逐步扩展工具数量、场景类型和评测指标。这样做的好处是每一步优化的效果都能被清晰观察不至于陷入“大系统一堆故障”的泥潭。8. 总结与学习路线这篇文章围绕 Agent Seer 的核心思路完整介绍了如何从工具规格出发合成一套可用的 Agent 评测场景。从概念上讲我们厘清了工具规格、评测场景、合成数据三者的关系从实践上讲我们实现了一个包含解析、生成、校验、导出的最小生成器从工程上讲我们讨论了分层设计、成本记录、版本管理等落地时的关键问题。对于正在做 Agent 应用的开发者我建议下一步按这样几条路线深入扩展规格解析能力支持 OpenAPI、YAML 格式并处理嵌套对象和数组参数丰富场景生成策略引入组合缺失、跨工具联动、多轮对话等复杂场景建设评测报告体系把生成、执行、分析三个环节做成可视化平台研究工具描述的自动优化利用评测结果反向改进工具规格文本提升 Agent 的工具选择准确率。推荐你先跑通本文的代码示例在这个基础上动手改一改换一个你自己的工具规格增加一两类负例跑一次完整生成和校验。把最小闭环跑通之后你就能真正体会到“从工具规格到评测场景”这条流水线的价值。如果文章对你有帮助也欢迎收藏备用后续遇到 Agent 评测相关的问题可以随时回来对照这套流程排查。