应用场景
模型路由
从任务本身而不是硬编码清单出发，选择便宜或昂贵的模型。
问题
把每个 prompt 都发给最大的模型，会让查找类请求白白烧掉预算。
代码拿到答案后怎么做
把 `small` 任务发给快模型，只有 `large` 任务才升级。
路由请求长什么样
state 就是任务本身 — 工单、查询、prompt — 加上两个问题：difficulty（在 small、medium、large 之间 choice，描述对准每一档擅长处理什么）和 needs_tools（yes/no：回答这个问题是否需要代码执行或检索）。两个答案都带概率，所以边缘任务会表现为置信度分裂，而不是静默地走错路由。调用通常 1 积分；省下的是不用为查找和改写支付大档的价格。
升级是第二次请求，不是重建
按 difficulty 路由。评为 small 的任务直接走快模型。所有越过你置信线的 — difficulty 在档位之间分裂、工具需求不确定 — 带着你已经建好的同一 state 升级到昂贵路径，无需重新接线。逐调用记录 route、confidence 和 latency，随流量变化重新校准档位描述。
路由专属的坑
用感觉而不是行为来描述档位（“便宜 / 贵 / 更贵”）会招来前后不一致的调用；请描述任务自身的样子。不要掩盖升级路径 — 量一量线上流量会落在哪里，如果大多数任务都评到 large 档，要么你的分档不对，要么 criteria 描述过于保守。还有：按任务路由，不按用户路由 — 高级用户手滑的 typo 也该走 small 档。
请求结构
这是 playground 为该预设发送的完整请求 — 与你的服务器带 Bearer key 发往 /v1/systemone 的 JSON 相同。
curl
curl https://jevai.website/api/v1/systemone \
-H "Authorization: Bearer $JEV_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"state": "Write a SQL query that returns the top 5 customers by revenue in 2025 from tables orders(customer_id, total, created_at) and customers(id, name).",
"questions": {
"difficulty": {
"type": "choice",
"instructions": "Which model tier is enough to answer this well?",
"criteria": {
"small": "Simple lookup or rewrite a small model handles",
"medium": "Routine reasoning or code",
"large": "Multi-step reasoning, ambiguity or long context"
}
},
"needs_tools": {
"type": "noul",
"instructions": "Does answering require running code or fetching data?"
}
}
}'关于此用例的常见问题
- 路由器需要知道我的成本吗？
- 保持行为化：criteria 描述的是每一档处理什么。定价放在你的策略里 — 一个评为 small 却返回低置信度的任务是升级候选，让这条规则成立的正是那个置信度数字。
- 该声明多少个档位？
- 三档是甜点位，用行为化的措辞来写：查找与改写、常规推理或代码、多步含糊或长上下文。两档损失层次；五档开始糊成一团。
- 对非英语任务有效吗？
- 有效 — state 可以携带任务原本的语言。把 criteria 里的档位名保留为你的代码要切换的标识符。