exo 如何用 eval_tool_calls 与 scenarios.toml 验证工具调用的解析正确性【免费下载链接】exoRun frontier AI locally.项目地址: https://gitcode.com/GitHub_Trending/exo8/exo当你在 exo 集群上运行本地模型需要确认模型产生的工具调用function calling在三种 API 格式——OpenAI Chat Completions、Claude Messages、OpenAI Responses——下都能被正确解析时仓库内置的 bench/eval_tool_calls.py 就是为这件事写的它把 bench/scenarios.toml 中定义的一系列测试会话发给一个正在运行的 exo 集群逐项检查模型是否返回了工具调用、函数名是否正确、参数是否为合法 JSON 且包含必需字段。运行前提是集群的 HTTP API 已经可达脚本默认连接localhost:52415可用--host/--port或环境变量EXO_HOST/EXO_PORT覆盖且待测模型已存在于集群的/models列表中。两个文件各自承担什么scenarios.toml声明两类内容[tools.name]表定义函数 schema字段包括description、required和properties.key可含type、enum、description数组项还可以再嵌套items子表。脚本加载时会把每个 tool 转换成 OpenAI 标准的{type: function, function: {...}}定义。[[scenarios]]表定义一条测试会话常用字段name、descriptionmessages多轮对话role 支持user/assistant/tool。assistant 消息可携带tool_calls每项含id、name、arguments内联表tool消息用tool_call_id关联上一轮的调用expect_tool_call该场景是否期望模型发起工具调用expected_function、required_arg_keys期望的函数名与参数必含键tools限定该场景只暴露哪些 tool省略则所有 tool 都下发tool_result提供工具执行结果用于触发“拿到工具结果后追问”的第二阶段nested_array_keyrequired_item_keys参数里含嵌套对象数组时的深度校验。仓库现有的工具定义示例原样摘自 bench/scenarios.toml[tools.get_current_weather] description Get the current weather in a given location required [location] [tools.get_current_weather.properties.location] type string description City and state, e.g. San Francisco, CA [[scenarios]] name weather_simple description Basic weather query - get_current_weather expect_tool_call true expected_function get_current_weather required_arg_keys [location] [[scenarios.messages]] role user content Whats the weather like in Tokyo right now?eval_tool_calls.py负责执行与判定加载场景后通过三个 API 适配器把同一份会话翻译成对应格式的请求统一使用temperature 0.0、max_tokens/max_output_tokens4096分别 POST 到/v1/chat/completions、/v1/messages、/v1/responses再把三种响应格式统一解析成“finish_reason、有无 tool_call、函数名、arguments 字符串、文本内容”后再跑同一套检查——这正是“跨格式验证解析正确性”的关键不同 API 的响应差异在解析层被抹平比较的是同一组断言。每个场景会做哪些检查第一阶段phase 为tool_callexpect_tool_call true时依次检查finish_reason_tool_callsfinish_reason 是否为tool_calls、has_tool_call、correct_function函数名是否等于expected_function、valid_argumentsarguments 必须是能解析的 JSON 对象且包含required_arg_keys中所有键若配置了nested_array_key还会检查valid_nested_structure——对应键必须是非空数组、每项是对象且包含required_item_keys。expect_tool_call false时检查finish_reason_stop、no_tool_call、has_content有非空文本。第二阶段phase 为follow_up只在场景配置了tool_result且第一阶段确实返回了工具调用时执行脚本把该工具调用作为 assistant 消息、tool_result作为工具结果追加进对话再发一次请求要求 finish_reason 为stop、不再发起新工具调用、且有非空内容。多轮场景示例摘自 scenarios.toml[[scenarios]] name calculator_multi_turn description Math query - tool result - model reports the answer expect_tool_call true expected_function calculate required_arg_keys [expression] [scenarios.tool_result] result 491682 [[scenarios.messages]] role user content Use the calculator to compute 1847 * 263 5921scenarios.toml 内置了 13 个场景覆盖单轮调用weather_simple、calculator_simple、带工具结果的多轮calculator_multi_turn等、链式调用chained_tool_calls_three的会话里已含两次完成的天气查询期望模型发出第三次、嵌套对象数组nested_schema_tool_call用create_todos校验todos数组项必须含content/status/priority、工具名完整性tool_name_integrity文件注释说明它是防止 harmony token 如|channel|混入函数名的回归场景以及两个不应触发工具的负例no_tool_joke、no_tool_factual。运行评估仓库是 uv workspacebench与tools都是成员见 pyproject.tomlnix flake 里也定义了可直接调用的exo-eval-tool-calls应用见 python/parts.nix。--model接受/models中的短名或 HuggingFace ID模型不在集群中时可加--force-download脚本会通过/models/add从 HuggingFace 拉入。最短主路径从仓库根目录执行模型名是脚本自带帮助中的示例uv sync --all-packages uv run python bench/eval_tool_calls.py --model mlx-community/Qwen3-30B-A3B-4bit脚本执行时会经历一个 planning 阶段解析模型、从/instance/previews按--min-nodes默认 1/--max-nodes默认 4、--sharding、--instance-meta筛选 placement集群尚未稳定出 placement 时会按指数退避重试最长等--settle-timeout默认 60s。随后检查各节点上的模型文件缺失则自动发起下载并等待完成磁盘不足会报错并提示使用--danger-delete-downloads。最后通过POST /instance创建一个真实的推理实例跑完所有场景后删除该实例并等待其消失。运行前需要明确这些副作用脚本会在你的集群上创建并最终删除一个实例、可能向节点下载模型文件--danger-delete-downloads在磁盘不足时会按“从小到大”删除已有模型文件来腾空间只有在接受丢失现有模型时才应传这个开关。脚本内置帮助中给出的几条示例命令my-model需替换为你集群中实际的模型名# 只测单一 API 格式重复 3 次 uv run python bench/eval_tool_calls.py --model my-model --api openai --repeat 3 # 按名称只跑指定场景 uv run python bench/eval_tool_calls.py --model my-model --api all --scenarios weather_simple calculator_multi_turn # JSON 结果输出到 stdout 而不是文件 uv run python bench/eval_tool_calls.py --model my-model --stdout常用开关--api取值openai/claude/responses/all默认all即三种格式各跑一遍--scenarios按名称精确匹配若没有任何匹配会打印可用场景名列表并以退出码 1 结束——可以反过来用它查场景名--concurrency默认 1必须 ≥ 1让多个场景在同一实例上并行执行--timeout是 HTTP 超时默认 7200s--verbose会把完整请求/响应 JSON 打到 stderr用于定位某一条失败的具体内容。怎么判断结果终端按场景逐条输出每行标注 API 与场景名随后是该场景每个 phase 的PASS/FAIL与耗时再列出每项检查的/-失败时附!错误行例如Invalid JSON: ...、Missing keys: [location]、todos[0] missing keys: [...]这类由校验函数给出的具体原因。结尾汇总结构固定数值随结果变化Total: passed/total passed (百分比%) Tool call: passed/total passed Follow-up: passed/total passed Avg latency: ms openai: passed/total passed claude: passed/total passed responses: passed/total passed若存在失败项还会单独列出Failed:明细场景名 API phase 错误。机器可读的结果默认写入bench/eval_results.json--json-out相对工作目录解析每条记录含name、api、phase、passed、checks、error、latency_ms顶层还带集群状态快照。进程退出码在所有场景通过时为 0否则为 1可直接用作 CI 判定。边界与限制本脚本验证的是“工具调用解析是否正确”不是吞吐或生成质量吞吐量测试走exo_bench方法论见 bench/METHODOLOGY.md两者互不替代。follow_up结果行数可能少于场景数它只在配置了tool_result且第一阶段真的返回了工具调用时才会产生。valid_arguments校验的是 JSON 结构与必需键的存在性不校验参数取值是否业务上正确例如不会断言location恰好是 Tokyo函数名是否匹配则由correct_function单独负责。集群未运行、模型无法解析或没有可用 placement 时脚本会直接报错退出典型信息包括Model not found in /models: model和No valid placements matched your filters.通用参数与实例生命周期逻辑集中在 tools/src/exo_tools/harness.py排查连接与 placement 问题时可以先看这里。想扩展验证面时按上述字段约定在 scenarios.toml 中新增一个[[scenarios]]表即可嵌套校验加nested_array_key/required_item_keys只暴露部分工具加tools列表然后用--scenarios 新场景名单跑确认。【免费下载链接】exoRun frontier AI locally.项目地址: https://gitcode.com/GitHub_Trending/exo8/exo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考