快速工作流分支
让模型在获准路径中做选择，再由确定性的业务代码执行分支。
决策模型 · Liquid
用更少的输出决定下一步。
当工作流已经拥有上下文，只需要一个明确、机器可读的结果来继续时，Liquid D1 就适合放在这个位置。
调用时使用准确的模型 ID。积分规则与其他决策模型一样，按照 Jev 规则计费。
一个决策边界
liquid/d1状态输入，路由输出。
状态
账户有逾期账单，但已验证付款方式。
选择
路由到重试付款
评分
置信度 0.91
Noul
缺少同意时不要联系用户
动作留在你的应用中，决策保持可审计。
输入
状态 + 类型化问题
输出
Choice · Score · Noul
计费
与 Jev 相同
接口
POST /v1/systemone
为什么使用它
为运营路由准备的紧凑模型。
在队列、门控和交接场景中使用小而明确的决策面，让下一步清楚可见。
类型化控制信号
保持输出为 choice、score 或 noul，下游代码无需解释散文式文本。
可检查的状态
把状态、问题、答案和置信度一起记录，方便调试与审核。
适用位置
放在判断与动作交接的位置。
当合法的下一步已经确定、执行由应用负责时，Liquid D1 很适合承担判断。
模式适合处理合适的边界
队列路由
选择团队、队列或优先级
返回获准的路由
策略门控
检查规则是否满足
明确阻止或继续
工作流交接
选择下一位负责人或工具
把权限留在业务代码中
调用模型
让请求保持小，让结果真正有用。
同一套 Jev API 约定可以让你比较 Liquid D1 与其他决策模型，无需重写集成。
- 将 model 设置为下方显示的准确模型 ID。
- 把当前状态作为紧凑字符串或可序列化的 JSON 值发送。
- 提出一个或多个类型化问题，并在业务代码中处理返回结果。
模型 ID 为 liquid/d1。
把业务上下文放到 state，把决策约定放到 questions。
把低置信度或 noul 结果当作正式兜底路径，而不是异常。
调用示例
curl -X POST https://thejevai.com/v1/systemone \
-H "Authorization: Bearer <API_KEY>" \
-H "Content-Type: application/json" \
-d '{
"model": "liquid/d1",
"state": "A customer request needs a safe next step.",
"questions": {
"route": {
"type": "choice",
"instructions": "Choose the correct next step.",
"criteria": {
"continue": "Continue the approved workflow",
"review": "Send the case for human review"
}
}
}
}'API Key 应保存在服务端。Playground 会通过登录会话使用相同的请求结构。
如何构建
让日常决策变得明确。
Liquid D1 适合作为有边界、可重复的工作流决策起点。
客服分流
将工单路由到正确团队，同时让最终回复仍由业务代码控制。
支付保护
在重试、退款或升级支付案例前检查一组紧凑条件。
工具选择
从获准的工具路径中做选择，再由权限层决定是否执行。
常见问题
几个实际的集成问题。
如何选择 Liquid D1？
在 POST /v1/systemone 请求中将 model 设置为 liquid/d1，也可以在 Playground 的模型选择器中选择 Liquid D1。
Liquid D1 的收费不同吗？
不单独计费。它使用支持的决策模型共用的 Jev 积分规则。请用自己的工作负载重新验证延迟和输出质量。
应该让模型直接调用工具吗？
不应该。使用类型化答案选择允许的路径，再由应用执行认证、权限、限流和副作用控制。
参考资料
让决策约定易于检查。
OpenRouter 模型页面
查看 Liquid D1 当前的供应商列表和可用性。
Jev API 文档
参考统一的接口、认证和类型化响应格式。
代表性测试集
为预期路由、模糊案例和明确升级路径保留测试样本。
从一个有边界的问题开始
让每个工作流分支都有清晰负责人。
用少量获准结果试用 Liquid D1，再针对真实路由案例进行评测。