拿 key 第一件事：用一把 key 跑六个模型做能力探测，先摸清每个后端能干什么

为什么第一步是探测而不是直接写业务

聚合站的价值在于一个 key 背后挂着多个后端。但这不等于每个后端在能力上完全等价：模型之间的差别不只在「聪明程度」，更在接口特性的支持面上。有人需要的是一次能返回 JSON 的结构化输出，有人需要流式首字速度，有人需要模型读图，有人需要工具调用做多步编排。

如果直接拿主业务去试，失败成本很高：一次报错可能被误判成「这个模型不行」，实际上只是参数没配对。更稳妥的做法是先用一组无关业务的小提示词，把每个后端扫一遍，得到一张自己的能力矩阵，再决定在哪一层封装什么。

探测要覆盖的四个维度

流式：后端是否按增量返回、是否在推理类模型上先吐思考内容。这决定你的前端能否做打字机效果，以及超时策略怎么设。

工具调用：模型是否能按约定的 schema 返回工具调用结构，是否支持多轮工具结果回填，是否强制或可选。这决定你能不能在它上面做 agent 式流程。

JSON 模式 / 结构化输出：是否能稳定返回可解析的 JSON，是否支持 schema 约束，还是只能靠提示词「请输出 JSON」然后自己兜底解析。这决定做抽取、分类、表单填充时选谁。

视觉：是否接受图片输入、支持什么形式（URL 还是 base64）、单次能带几张。这决定多模态功能是否可行。

除这四项外，还可顺带记录：是否支持系统提示词、是否支持温度等采样参数、上下文用量返回与否。这些不影响选型方向，但影响封装层的默认参数。

提示词怎么设计

原则是短、可判定、互不干扰。每个维度用一到两条最小样例，不要用业务真实数据。

• 流式：让模型输出一段固定长度的文字，例如数到二十。看返回是整块还是分片，首片延迟大概在什么量级。
• 工具：给一个只有一个函数的工具定义（比如查天气），问一个必须调用它的问题。看它返回的是文本还是一段工具调用结构。
• JSON：给一句「以 JSON 返回字段 a、b」并要求字段值可预测，然后直接尝试解析。比「请用 JSON 回答」这种模糊要求更能暴露真实行为。
• 视觉：用一张内容明确、答案唯一的图（比如纯色方块或简单几何图形），问图里是什么颜色或形状。答案可判定，才能区分「真读到了图」和「在编」。

每组提示词都配上明确的判定标准，写进脚本注释里，避免过几周回来看不懂结果。

脚本结构

不需要复杂框架，核心是一个循环加一张结果表。

目标列表 = [后端A, 后端B, ...]
结果 = {}
for 模型 in 目标列表:
    for 维度, 用例 in 用例表:
        尝试:
            响应 = 调用(模型, 用例.请求)
            结果[模型][维度] = 判定(响应, 用例.期望)
        捕获 异常 as e:
            结果[模型][维度] = 记录错误类型(e)

几个要点：

• 每个维度独立 try。一个维度不支持，不能让整轮扫描中断，否则你只看到第一个失败就停了。
• 区分错误类型。参数不被支持通常是请求阶段的错误；能力缺失可能是模型直接以自然语言拒绝或返回空结构。两类要分开记，前者说明「不支持这个参数」，后者说明「支持接口但做不好」。
• 加超时和重试上限。推理较慢的后端在长输出上可能很慢，但探测用例都很短，超时设得保守一些即可，避免一次卡住拖住整轮。
• 结果落成表格。终端打印一份，同时写一份结构化文件（JSON 或 CSV），后面做选型时直接查。

结果怎么读

把矩阵按「支持 / 部分支持 / 不支持 / 报错」四档标记，然后按业务分层决策：

• 需要即时反馈的交互界面，压在有流式且首字快的后端上。
• 需要程序化消费的输出，压在 JSON 模式稳定的后端上；不稳定的后端并非不能用，但要加解析兜底和重试。
• 需要查外部数据或多步操作的流程，压在工具调用可靠的后端上；只支持单轮工具的后端可以承担简单分支。
• 多模态功能只放在视觉确实可判定的后端上，不要靠猜。

同一维度上多个后端都合格时，再考虑成本与配额。这里要注意计费口径：调用按官方价的倍数扣费，因此「哪家便宜」不是唯一变量，能力是否匹配需求更重要——用错后端导致的返工，比单价差异贵得多。

常见坑

• 把参数错误当能力缺失。没传对消息结构就下结论，会误杀一个本来可用的后端。
• 用模糊提示词测 JSON。模型会「看起来像 JSON」，解析时才炸；一定要用可解析性作为判定标准。
• 只测一次。结构化输出和工具调用都有波动，关键维度至少跑几条不同表述的样例，记录通过率而不是单次结果。
• 忽略返回里的用量信息。顺手记录输入输出用量，后面做成本估算和上下文长度规划时会用到。
• 忘了把脚本和结果一起留档。能力会随后端更新变化，保留脚本就能定期重跑，形成对比。

把探测变成常规动作

一次性扫描只解决「现在能干什么」。更稳的做法是把这套脚本固定下来，在接入新后端、或者关键功能上线前重跑一遍，用同一套用例做对比。矩阵有变化时，封装层的默认模型和降级顺序也应该跟着调整。这样你的业务代码只依赖「能力」，而不是依赖某个具体模型名。