十月下旬这波模型更新，对做工程的人来说其实是个不错的机会：趁旧实现还在跑，拿它当基线，回头把真实业务任务再验一遍。
OpenAI 在 10 月 26 日的更新日志里发布了 GPT-6.1 Terra。它的模型文档写得很清楚：工具调用必须走 Responses API。对已有应用来说，这个集成细节比发布会的标题重要得多——文本请求在某个端点上跑通，并不代表同一条路由就能跑你的工具。
所以这次把范围刻意收小：只比较你 RelayRouter 账户里实际可用的模型路由，做一次文本分类。这是冒烟测试，不是给新闻里提到的模型排名。
先挑一个能验证的业务判断
假设一个客服队列需要打初始标签：账单、访问权限、待复核。最后一类不能省——一张含糊的工单，不该因为应用非要一个标签，就被自信地分错。
发请求之前先写三个合成用例。这些用例检查的是接线和基本输出行为。真要上生产评估，得有代表性样本、困难案例、必要的重复运行，还得由负责这个队列的团队来复核。
配置账户里真实存在的路由
创建一个 RelayRouter API 密钥，然后从当前控制台复制 Base URL 和模型 ID。用那条路由暴露出来的模型 ID，别拿模型的营销名去猜标点符号拼标识符。
macOS/Linux 下的设置用你本地提供的值：
export RELAYROUTER_BASE_URL='COPY_HTTPS_BASE_URL_FROM_CONSOLE'
export RELAYROUTER_API_KEY='YOUR_SERVER_SIDE_KEY'
export RELAYROUTER_MODELS='AVAILABLE_MODEL_A,AVAILABLE_MODEL_B'
python compare_routes.py > smoke-test.jsonl
可下载的 compare_routes.py 只用 Python 标准库，会在控制台 Base URL 后面追加 /chat/completions。选路由时，挑那些文档里写明支持这种纯文本请求形态的。如果 Base URL 本身就以 /chat/completions 结尾，路径会重复。
请求契约保持最小
核心请求故意写得很普通：模型填控制台里的可用模型 ID，stream 设为 false，消息里一条 system、一条 user。system 要求把工单当数据看，只返回一个 JSON，键是 category，值只能是账单、访问权限或待复核，看不清就用待复核。user 放一条合成工单，比如“同一个月的账单被扣了两次”。
本地检查器会验证正常完成、把返回文本解析成 JSON、要求恰好一个字段、检查类别是否在允许范围内，再和预期标签比对。在提示词里要 JSON，本身并不等于强制了 schema。
脚本每次请求打印一条记录：请求的模型、返回的模型元数据、耗时、供应商给出的用量、以及校验结果。它不打印密钥，也不打印工单文本。它也不会自动重试——重复调用会改变测试成本，得有明确的策略。
先看失败，再看平均值
传输错误、HTTP 错误、无效 JSON、标签错误，是四种不同的结果，要保留这个区别。一个很快返回但类别错了的响应，不算快速成功。
要做更大规模的评估，就比较被接受的结果、耗时分布、重试次数，以及账户里的实际扣费。光看 token 数不是账单，三个用例也撑不起延迟基准。记录足够的上下文，路由更新之后你还能重跑这个实验。
文本契约跑通之后，再去单独测图像输入或工具调用。每项能力配一个独立的验收用例，并检查端点要求。工具测试先放在沙箱里，只做无害动作，再考虑让它改业务记录。
RelayRouter 能提供你想比较的那些可用路由的 API 连接，但验收、复核和上线节奏仍由你的应用掌控。当前可用性和功能支持以控制台为准。
从注册一个 RelayRouter 账户、选一条可用路由开始，跑你业务团队能看懂的最小检查。然后扩的是证据，不只是提示词。
热门跟贴