【免费下载链接】gpt-ossgpt-oss-120b and gpt-oss-20b are two open-weight language models by OpenAI项目地址https://gitcode.com/gh_mirrors/gp/gpt-oss点击查看免费下载导读gpt-oss开源仓库自带一套基于 TypeScript 的 API 兼容性测试工具位于 compatibility-test 目录它借助 OpenAI Agents SDKopenai/agents和底层 OpenAI 客户端验证任意 OpenAI 兼容推理服务如 vLLM、Ollama、自建 Responses API 服务器等的请求/响应数据结构是否符合预期并进一步确认该 API 能否正确完成多轮工具调用tool calling。读完本文你将掌握如何注册一个待测 Provider、运行快速冒烟测试与完整回归测试、看懂 passk 与 pass^k 指标以及理解工具调用、响应结构与流式事件三类校验的判定逻辑。这套测试解决了什么问题部署 gpt-oss 推理服务时同一个模型可能通过不同后端vLLM、Triton、Metal、Ollama 等暴露出来而客户端可能走两种不同协议Responses API与Chat Completions API。接口形状schema的细微差异——例如 reasoning 字段的存放位置、function_call的参数结构、流式事件的类型命名——都会导致上层 Agent 应用行为异常。compatibility-test/README.md 明确指出该脚本的两个核心目标校验 API 调用的形状shape即请求发出的数据结构、返回响应的字段结构是否符合预期校验 API 是否真正执行了工具调用模型是否按照工具定义发出了正确的函数调用。测试用例与工具定义测什么、用什么测测试用例以 JSONL 格式存放在 compatibility-test/cases.jsonl共 30 条每条是一个独立用例结构如下字段含义tool_name应被调用的工具名称须与 compatibility-test/tools.ts 中的定义一致input用户输入的自然语言提示expected_arguments期望模型最终解析出的工具调用参数JSON 字符串instructions可选传给 Agent 的系统指令用例覆盖 6 个工具每个工具 5 条输入变体用于考察模型在不同措辞下提取参数的能力get_weather期望{location: ...}覆盖城市名、邮编等输入get_system_health无参数工具期望{}考察空参数场景markdown_to_html期望{markdown: ...}含转义换行等复杂输入detect_language期望{text: ...}含多语种文本generate_chart期望{data: [[...]], chart_type: line|bar|scatter, ...}含可选字段title、x_label、y_labelquery_database期望{table: ..., columns: [...], limit: N, filters: ..., order_by: ...}参数约束最丰富limit范围 1~10000、默认 100。每个工具在 compatibility-test/tools.ts 中都有完整的 JSON Schema 参数定义含required与additionalProperties: false并通过convertToTool转换为openai/agents的tool()对象。execute直接返回预设的output因此测试不关心工具执行逻辑只关心模型是否发出符合 Schema 的函数调用。注册待测 Provider运行测试前需要编辑 compatibility-test/providers.ts 为待测 API 创建一条配置。仓库默认提供vllm条目export const PROVIDERS { vllm: { apiBaseUrl: http://localhost:8000/v1, apiKey: vllm, apiType: [responses, chat], // choose from responses, chat, or both modelName: openai/gpt-oss-120b, providerDetails: { // 每次请求都会带上这里的额外字段例如固定 OpenRouter 的 provider // provider: { // only: [example], // }, }, }, };关键字段说明apiBaseUrlOpenAI 兼容服务的基础地址vLLM 默认监听http://localhost:8000/v1apiKey占位密钥多数本地服务不校验但 OpenAI 客户端要求非空apiType数组可选responses、chat或两者都要——决定同一批用例分别通过哪种协议各跑一遍modelName请求中携带的模型名vLLM 场景为openai/gpt-oss-120bproviderDetailsprovider 级附加参数会作为modelSettings.providerData随每个请求透传见 compatibility-test/runCase.ts 中的modelSettings配置。测试时通过--provider name指定使用哪条配置。若替换为 Ollama可把apiBaseUrl指向http://localhost:11434/v1modelName改为gpt-oss:20b等。运行测试从冒烟到回归官方文档给出了两步运行流程compatibility-test/README.md。前置步骤 0 为在 compatibility-test 目录执行npm install依赖见 compatibility-test/package.jsonopenai/agents、ajv、listr2通过tsx直接运行 TypeScript。1. 冒烟测试——只跑 1 个用例、每个用例 1 次npm start -- --provider name -n 1 -k 12. 完整回归测试——跑全部用例每个用例重复 5 次以验证一致性npm start -- --provider name -k 5除了文档中的-n--n与-k--tries入口 compatibility-test/index.ts 还通过node:util的parseArgs暴露了完整参数集参数短选项默认值说明--cases-ccases.jsonl用例文件路径JSONL支持绝对/相对路径--provider-popenai使用PROVIDERS中的哪条配置--streaming-sfalse是否以流式模式运行注意源码中-s同时映射到streaming与strict两个布尔选项为仓库既有行为--maxTurns-t10Agent 最大工具调用轮数--n-n无全量只运行前 N 个用例且必须为正整数--strict-sfalse严格模式要求参数与expected_arguments完全一致才判通过--tries-k1每个用例重复执行的次数执行时Listr以 5 并发的方式逐条执行用例concurrent: 5每个用例的每次尝试对应一个任务。运行结束后会产出两个文件rollout_provider_时间戳.jsonl逐条运行明细含run_id用例序号_尝试序号、success、provider、test_case、tool_name、input及完整的result摘要analysis_provider_时间戳.json汇总统计详见下文指标解读。三层校验逻辑工具调用、响应形状、流式事件每个用例执行完成后compatibility-test/runCase.ts 会做三类校验最终success 工具调用成功 响应形状有效 流式时事件有效。第一层工具调用校验testToolCall遍历result.newItems找到类型为tool_call_item且rawItem.type function_call、名称与caseData.tool_name一致的工具调用随后用 Ajv 依据该工具的参数 Schema 编译并校验模型产出的arguments得到三个布尔结论calledToolAtLeastOnce是否至少调用过一次目标工具calledToolWithRightSchema参数是否符合 JSON SchemacalledToolWithRightArguments参数是否与expected_arguments深度相等递归deepEqual实现见 compatibility-test/runCase.ts 底部。testToolCall的通过条件是调用了工具、Schema 正确且——仅在strict模式下——参数完全匹配。若 Schema 正确但参数不一致会写入warning并保留actualArguments/expectedArguments便于排查但默认不判失败。第二层响应形状校验testOutputData针对两种协议分别检查 reasoning 内容是否按预期结构返回responses遍历响应的output数组查找type reasoning的条目要求content为数组、长度大于 0、每项类型为reasoning_text且文本非空对应 gpt_oss/responses_api/types.py 中ReasoningItem/ReasoningTextContentItem的定义chat检查choices[0].message中是否存在reasoning或reasoning_content字符串字段且非空由于并非每条响应都必然携带 reasoning判定采用全部响应中至少出现一次的策略。第三层流式事件校验testEvents仅在--streaming开启时生效。脚本收集所有raw_model_stream_event类型的事件并检查关键事件是否存在responses要求出现response.reasoning_text.delta与response.reasoning_text.donechat要求至少一个 chunk 的choices[0].delta.reasoning为非空字符串。如 compatibility-test/README.md 所述当前对事件只做关键事件存在性检查尚未做到用事件流重建最终响应并与response.completed对比的理想形态且 Chat Completions 的流式事件目前未纳入测试streaming下该协议会直接跳过事件校验。结果解读passk 与 pass^kcompatibility-test/analysis.ts 在运行结束后对结果做汇总按test_case::apiType将同一次尝试的多次运行分组计算两类核心指标passk前 k 次尝试中至少一次成功的任务占比——衡量偶发成功能力pass^k前 k 次尝试全部成功的任务占比——衡量一致性/稳定性这是-k 5的真正目的同一用例重复 5 次全部成功才算稳定通过。此外还统计totalTasks任务总数、totalRuns运行总次数、按 API 类型分别统计的无效响应数量、wrongInputToolCallsSchema 正确但参数错误的调用次数即文档Considerations第 3 条所描述的情形以及被跳过的非法 JSON 用例行数。控制台输出示例Summary: Provider: vllm Total input cases: 30 Tries: 5 ... passk (k1..5): 10.867, 20.933, ... pass^k (k1..5): 10.867, ... Wrong-input tool calls: 3使用须知与边界按官方文档的Considerations使用本测试工具时需注意API 形状不符即失败响应结构一旦偏离预期如缺少 reasoning 条目、字段类型不对对应用例会直接判失败——这是本工具的核心检出能力Chat API 事件当前不测试testEvents对chat类型只检查 reasoning delta且官方文档明确Events in the chat API are currently not testedSchema 正确但参数错误默认不判失败因为这类偏差更可能是提示词工程或校验器问题而非 API 实现问题模型确实成功发出了函数调用因此仅在--strict模式下才会因参数不一致而失败测试不依赖真实工具执行所有工具execute返回固定输出因此结果只反映模型是否正确发出函数调用 服务端响应结构是否合规不代表端到端工具链路可用性。这套测试工具与仓库主项目README 见 README.md中Responses API与Chat Completions两种接入方式相互印证无论你使用自带的 gpt_oss/responses_api 示例服务器、vLLM 还是其他 OpenAI 兼容后端都可以先用本工具快速确认接口契约与工具调用能力是否符合 Agents SDK 的预期。赞分享【免费下载链接】gpt-ossgpt-oss-120b and gpt-oss-20b are two open-weight language models by OpenAI项目地址https://gitcode.com/gh_mirrors/gp/gpt-oss点击查看免费下载相关推荐Composio 与 OpenAI 集成指南使用 composio/openai 将工具接入 Responses 与 Chat CompletionsComposio 与 OpenAI 集成指南使用 composio/openai 将工具接入 Responses 与 Chat Completions c人工智能AI Agent工具调用MCP 服务MCP ClientsComposio Python OpenAI 集成把 1000 工具接入 Chat Completions 与 Responses API 的完整实战Composio Python OpenAI 集成把 1000 工具接入 Chat Completions 与 Responses API 的完整实战 本篇人工智能AI Agent工具调用MCP 服务MCP Clients用 nanobot 搭建 OpenAI 兼容的 Agent API本地 /v1/chat/completions 接入指南用 nanobot 搭建 OpenAI 兼容的 Agent API本地 /v1/chat/completions 接入指南 导读 nanobot 可以把一个具人工智能AI AgentAgent 框架多智能体工具调用MCP Clients交互助手后端任务调度上一篇三步玩转EinkBro专为电子墨水屏优化的护眼浏览器上手指南下一篇Azahar与Citra的区别技术对比与功能演进分析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
【免费下载链接】gpt-ossgpt-oss-120b and gpt-oss-20b are two open-weight language models by OpenAI项目地址https://gitcode.com/gh_mirrors/gp/gpt-oss点击查看免费下载导读gpt-oss开源仓库自带一套基于 TypeScript 的 API 兼容性测试工具位于 compatibility-test 目录它借助 OpenAI Agents SDKopenai/agents和底层 OpenAI 客户端验证任意 OpenAI 兼容推理服务如 vLLM、Ollama、自建 Responses API 服务器等的请求/响应数据结构是否符合预期并进一步确认该 API 能否正确完成多轮工具调用tool calling。读完本文你将掌握如何注册一个待测 Provider、运行快速冒烟测试与完整回归测试、看懂 passk 与 pass^k 指标以及理解工具调用、响应结构与流式事件三类校验的判定逻辑。这套测试解决了什么问题部署 gpt-oss 推理服务时同一个模型可能通过不同后端vLLM、Triton、Metal、Ollama 等暴露出来而客户端可能走两种不同协议Responses API与Chat Completions API。接口形状schema的细微差异——例如 reasoning 字段的存放位置、function_call的参数结构、流式事件的类型命名——都会导致上层 Agent 应用行为异常。compatibility-test/README.md 明确指出该脚本的两个核心目标校验 API 调用的形状shape即请求发出的数据结构、返回响应的字段结构是否符合预期校验 API 是否真正执行了工具调用模型是否按照工具定义发出了正确的函数调用。测试用例与工具定义测什么、用什么测测试用例以 JSONL 格式存放在 compatibility-test/cases.jsonl共 30 条每条是一个独立用例结构如下字段含义tool_name应被调用的工具名称须与 compatibility-test/tools.ts 中的定义一致input用户输入的自然语言提示expected_arguments期望模型最终解析出的工具调用参数JSON 字符串instructions可选传给 Agent 的系统指令用例覆盖 6 个工具每个工具 5 条输入变体用于考察模型在不同措辞下提取参数的能力get_weather期望{location: ...}覆盖城市名、邮编等输入get_system_health无参数工具期望{}考察空参数场景markdown_to_html期望{markdown: ...}含转义换行等复杂输入detect_language期望{text: ...}含多语种文本generate_chart期望{data: [[...]], chart_type: line|bar|scatter, ...}含可选字段title、x_label、y_labelquery_database期望{table: ..., columns: [...], limit: N, filters: ..., order_by: ...}参数约束最丰富limit范围 1~10000、默认 100。每个工具在 compatibility-test/tools.ts 中都有完整的 JSON Schema 参数定义含required与additionalProperties: false并通过convertToTool转换为openai/agents的tool()对象。execute直接返回预设的output因此测试不关心工具执行逻辑只关心模型是否发出符合 Schema 的函数调用。注册待测 Provider运行测试前需要编辑 compatibility-test/providers.ts 为待测 API 创建一条配置。仓库默认提供vllm条目export const PROVIDERS { vllm: { apiBaseUrl: http://localhost:8000/v1, apiKey: vllm, apiType: [responses, chat], // choose from responses, chat, or both modelName: openai/gpt-oss-120b, providerDetails: { // 每次请求都会带上这里的额外字段例如固定 OpenRouter 的 provider // provider: { // only: [example], // }, }, }, };关键字段说明apiBaseUrlOpenAI 兼容服务的基础地址vLLM 默认监听http://localhost:8000/v1apiKey占位密钥多数本地服务不校验但 OpenAI 客户端要求非空apiType数组可选responses、chat或两者都要——决定同一批用例分别通过哪种协议各跑一遍modelName请求中携带的模型名vLLM 场景为openai/gpt-oss-120bproviderDetailsprovider 级附加参数会作为modelSettings.providerData随每个请求透传见 compatibility-test/runCase.ts 中的modelSettings配置。测试时通过--provider name指定使用哪条配置。若替换为 Ollama可把apiBaseUrl指向http://localhost:11434/v1modelName改为gpt-oss:20b等。运行测试从冒烟到回归官方文档给出了两步运行流程compatibility-test/README.md。前置步骤 0 为在 compatibility-test 目录执行npm install依赖见 compatibility-test/package.jsonopenai/agents、ajv、listr2通过tsx直接运行 TypeScript。1. 冒烟测试——只跑 1 个用例、每个用例 1 次npm start -- --provider name -n 1 -k 12. 完整回归测试——跑全部用例每个用例重复 5 次以验证一致性npm start -- --provider name -k 5除了文档中的-n--n与-k--tries入口 compatibility-test/index.ts 还通过node:util的parseArgs暴露了完整参数集参数短选项默认值说明--cases-ccases.jsonl用例文件路径JSONL支持绝对/相对路径--provider-popenai使用PROVIDERS中的哪条配置--streaming-sfalse是否以流式模式运行注意源码中-s同时映射到streaming与strict两个布尔选项为仓库既有行为--maxTurns-t10Agent 最大工具调用轮数--n-n无全量只运行前 N 个用例且必须为正整数--strict-sfalse严格模式要求参数与expected_arguments完全一致才判通过--tries-k1每个用例重复执行的次数执行时Listr以 5 并发的方式逐条执行用例concurrent: 5每个用例的每次尝试对应一个任务。运行结束后会产出两个文件rollout_provider_时间戳.jsonl逐条运行明细含run_id用例序号_尝试序号、success、provider、test_case、tool_name、input及完整的result摘要analysis_provider_时间戳.json汇总统计详见下文指标解读。三层校验逻辑工具调用、响应形状、流式事件每个用例执行完成后compatibility-test/runCase.ts 会做三类校验最终success 工具调用成功 响应形状有效 流式时事件有效。第一层工具调用校验testToolCall遍历result.newItems找到类型为tool_call_item且rawItem.type function_call、名称与caseData.tool_name一致的工具调用随后用 Ajv 依据该工具的参数 Schema 编译并校验模型产出的arguments得到三个布尔结论calledToolAtLeastOnce是否至少调用过一次目标工具calledToolWithRightSchema参数是否符合 JSON SchemacalledToolWithRightArguments参数是否与expected_arguments深度相等递归deepEqual实现见 compatibility-test/runCase.ts 底部。testToolCall的通过条件是调用了工具、Schema 正确且——仅在strict模式下——参数完全匹配。若 Schema 正确但参数不一致会写入warning并保留actualArguments/expectedArguments便于排查但默认不判失败。第二层响应形状校验testOutputData针对两种协议分别检查 reasoning 内容是否按预期结构返回responses遍历响应的output数组查找type reasoning的条目要求content为数组、长度大于 0、每项类型为reasoning_text且文本非空对应 gpt_oss/responses_api/types.py 中ReasoningItem/ReasoningTextContentItem的定义chat检查choices[0].message中是否存在reasoning或reasoning_content字符串字段且非空由于并非每条响应都必然携带 reasoning判定采用全部响应中至少出现一次的策略。第三层流式事件校验testEvents仅在--streaming开启时生效。脚本收集所有raw_model_stream_event类型的事件并检查关键事件是否存在responses要求出现response.reasoning_text.delta与response.reasoning_text.donechat要求至少一个 chunk 的choices[0].delta.reasoning为非空字符串。如 compatibility-test/README.md 所述当前对事件只做关键事件存在性检查尚未做到用事件流重建最终响应并与response.completed对比的理想形态且 Chat Completions 的流式事件目前未纳入测试streaming下该协议会直接跳过事件校验。结果解读passk 与 pass^kcompatibility-test/analysis.ts 在运行结束后对结果做汇总按test_case::apiType将同一次尝试的多次运行分组计算两类核心指标passk前 k 次尝试中至少一次成功的任务占比——衡量偶发成功能力pass^k前 k 次尝试全部成功的任务占比——衡量一致性/稳定性这是-k 5的真正目的同一用例重复 5 次全部成功才算稳定通过。此外还统计totalTasks任务总数、totalRuns运行总次数、按 API 类型分别统计的无效响应数量、wrongInputToolCallsSchema 正确但参数错误的调用次数即文档Considerations第 3 条所描述的情形以及被跳过的非法 JSON 用例行数。控制台输出示例Summary: Provider: vllm Total input cases: 30 Tries: 5 ... passk (k1..5): 10.867, 20.933, ... pass^k (k1..5): 10.867, ... Wrong-input tool calls: 3使用须知与边界按官方文档的Considerations使用本测试工具时需注意API 形状不符即失败响应结构一旦偏离预期如缺少 reasoning 条目、字段类型不对对应用例会直接判失败——这是本工具的核心检出能力Chat API 事件当前不测试testEvents对chat类型只检查 reasoning delta且官方文档明确Events in the chat API are currently not testedSchema 正确但参数错误默认不判失败因为这类偏差更可能是提示词工程或校验器问题而非 API 实现问题模型确实成功发出了函数调用因此仅在--strict模式下才会因参数不一致而失败测试不依赖真实工具执行所有工具execute返回固定输出因此结果只反映模型是否正确发出函数调用 服务端响应结构是否合规不代表端到端工具链路可用性。这套测试工具与仓库主项目README 见 README.md中Responses API与Chat Completions两种接入方式相互印证无论你使用自带的 gpt_oss/responses_api 示例服务器、vLLM 还是其他 OpenAI 兼容后端都可以先用本工具快速确认接口契约与工具调用能力是否符合 Agents SDK 的预期。赞分享【免费下载链接】gpt-ossgpt-oss-120b and gpt-oss-20b are two open-weight language models by OpenAI项目地址https://gitcode.com/gh_mirrors/gp/gpt-oss点击查看免费下载相关推荐Composio 与 OpenAI 集成指南使用 composio/openai 将工具接入 Responses 与 Chat CompletionsComposio 与 OpenAI 集成指南使用 composio/openai 将工具接入 Responses 与 Chat Completions c人工智能AI Agent工具调用MCP 服务MCP ClientsComposio Python OpenAI 集成把 1000 工具接入 Chat Completions 与 Responses API 的完整实战Composio Python OpenAI 集成把 1000 工具接入 Chat Completions 与 Responses API 的完整实战 本篇人工智能AI Agent工具调用MCP 服务MCP Clients用 nanobot 搭建 OpenAI 兼容的 Agent API本地 /v1/chat/completions 接入指南用 nanobot 搭建 OpenAI 兼容的 Agent API本地 /v1/chat/completions 接入指南 导读 nanobot 可以把一个具人工智能AI AgentAgent 框架多智能体工具调用MCP Clients交互助手后端任务调度上一篇三步玩转EinkBro专为电子墨水屏优化的护眼浏览器上手指南下一篇Azahar与Citra的区别技术对比与功能演进分析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
