自己搭一个 Jev 决策模拟器：预演置信度门控再上线

我家大橘技术创作者 2026-09-21 227 阅读

先说结论

这里的“Jev 决策模拟器”不是 TypeSafe 官方产品，也不是控制台内置功能；它是一个用历史请求批量调用 System One API、按置信度分档统计的本地预演脚本。官方只提供 Playground 做单次试形状。
预演的核心不是只看答案准不准，而是看“自动处理/转人工”的比例和预估成本。置信度是第二轴：答案告诉你是什么意图，confidence 告诉你这件事能不能自动做。
成本可以按官方定价和官方示例量级推算。官方定价是 $42/十亿输入 token（官方数据）；官方 Quick start 示例请求的 input tokens 为 392（官方示例值）。单条成本约 $0.0000165（自己推算）。
阈值不是官方推荐值，应该按业务风险自己标定。保守/均衡/激进三档只是起点，不是标准答案。
上线前要查：低置信度是否有兜底、日志是否记录 model 字段（官方示例 jev-1.13.0）、失败重试是否会重复计费、超时是否降级到规则。

这个“模拟器”到底指什么

先划清边界。官方 Quick start 提到三层工具：Playground、API、Agent Skill。Playground 是控制台里手动试单条请求的工具；API 是生产中调用 /v1/systemone；Agent Skill 是给编码代理用的安装包。我们要做的“模拟器”不属于其中任何一层。它是一个自己写的 Python 脚本，把一批历史文本当输入，逐条发给 System One API，相当于一个离线流量回放器。

为什么值得做？因为官方 Confidence-gated routing 这个 pattern 讲了用置信度做第二轴的路由逻辑，但给出的是一段 if/elif 风格示例。真正上线前，你需要的不是单个 if，而是一整批样本跑出来的分流比例和预期成本。没有这个数字，阈值调多少都像在拍脑袋。

第一层：用 Playground 试单条形状

上线前的第一步，是先到 Playground 试单个请求。官方 Quick start 给了一个很实用的样本：把一段客户消息粘贴为 state，比如“Hi, I’ve been trying to connect my Stripe account for 3 days…”，然后加一个 Noul 问题：“Does this message express urgency?”。

这里的价值不是批量，而是快速验证 prompt 的形状。Noul、Choice、Score 可以混在一次调用里；Choice 适合“哪个部门处理”，Score 适合“客户有多生气”，Noul 适合“是否紧急”。我的建议是：先只放一个路由用 Choice，确认返回的 choice 和 confidence 符合预期，再往脚本里搬。Playground 不适合做批量预演，但适合把问题定义调顺。

第二层：本地预演脚本

重点来了。你可以用官方 Python SDK，安装 typesafe-sdk 后默认调用 jev-latest（官方 Quick start 说明）。下面这段脚本的思路是：读历史文本，对每条发一次 system_one 请求，记录路由答案、置信度，再按阈值分到“自动处理/转人工”两个桶，最后输出比例和成本。成本部分先按官方示例的 392 input tokens 量级做估算；如果真实响应里有 usage 字段，优先用真实值。

from typesafe_sdk import Choice, TypeSafeClient

client = TypeSafeClient()

history_texts = [
    "Hi, I've been trying to connect my Stripe account for 3 days and the integration keeps failing.",
    "Can you send me my last invoice?",
    "I want to close my account immediately.",
]

# 路由问题：Choice 会返回 choice 和 confidence，适合做阈值判断
route_question = Choice(
    instructions="Which team should handle this?",
    criteria={
        "billing": "Payment or subscription issues",
        "technical": "Bugs or integration problems",
        "sales": "Pricing or account questions",
    },
)

LOW_CONFIDENCE_THRESHOLD = 0.6

auto_count = 0
human_count = 0
total_input_tokens = 0
total_cost_usd = 0.0

for text in history_texts:
    response = client.system_one(
        state=text,
        questions={"route": route_question},
    )

    answer = response.answers["route"]
    conf = answer.confidence
    choice = answer.choice

    # 分桶：低于阈值转人工，达到阈值自动处理
    if conf < LOW_CONFIDENCE_THRESHOLD:
        human_count += 1
        bucket = "转人工"
    else:
        auto_count += 1
        bucket = "自动处理"

    # 成本估算：优先取响应中的实际 input tokens；没有则回退到官方示例 392
    try:
        input_tokens = response.usage.input_tokens
    except (AttributeError, KeyError):
        input_tokens = 392

    total_input_tokens += input_tokens
    # 官方定价：$42 / 1,000,000,000 input tokens
    cost = input_tokens * 42 / 1_000_000_000
    total_cost_usd += cost

    print(f"{choice:10s} conf={conf:.3f} -> {bucket}")

n = len(history_texts)
print("自动处理比例: {:.1%}".format(auto_count / n))
print("转人工比例: {:.1%}".format(human_count / n))
print(f"预估输入 token 总量: {total_input_tokens}")
print(f"预估成本: ${total_cost_usd:.6f}")

这段代码不是直接上生产的，而是让你在办公桌旁边把分流比例跑出来。你可以把 history_texts 替换成真实历史工单、客服消息或内部标注集。需要注意，官方 Confidence 文档明确说 Noul 不返回 confidence；confidence 只出现在 Choice 和 Score 上。所以如果你要做置信度门控，路由问题应该用 Choice 或 Score，不要拿 Noul 做阈值。

成本估算：官方数据与推算

官方 TypeSafe AI 首页给出的价格是 $42/十亿输入 token（官方数据）。官方 Quick start 示例请求的 input tokens 量级是 392（官方示例值）。按这个量级计算：

单条成本 = 392 / 1,000,000,000 × 42 = 0.000016464，约 $0.0000165（自己推算）
1000 条成本 ≈ $0.0165（自己推算）
1000000 条成本 ≈ $16.5（自己推算）

需要强调，这只是一个用于预演的量级。你的 state 长度差异很大，真实账单要以 API 返回的 usage 为准。我更建议在脚本里落地“优先读 response.usage.input_tokens”的逻辑，而不是硬编码 392。392 只适合快速估预算。

阈值怎么调：一个从保守到激进的起点表

官方 Confidence-gated routing 里有一个例子：低于 0.6 转人工，查询余额 0.6 够用，批准转账要 >0.85。这不是普适标准，而是按风险分层。官方 Confidence 文档也说得明白：正确的阈值取决于领域和模型在你自己数据上的表现，应该从保守开始，用真实样本调。

下面三档表是给决策分流用的起点，不是官方推荐值。要按业务风险自己标定。

档位	自动处理阈值	策略	主要取舍
保守	0.85	只有高置信自动，其余转人工	漏放风险低，人工量大
均衡	0.70	中高置信自动，低置信转人工	人工量与风险平衡
激进	0.55	中低置信也自动，极低才转人工	人工量小，漏放风险升高

使用建议：如果你做的是支付、账户变更等破坏性操作，自动阈值至少应高于查询类操作。同一个系统内可以按动作分别设置阈值，这正是官方文档里“Thresholds scale with risk”的意思。先把保守档跑一遍，拿到自动/转人工比例，如果人工比例高得无法接受，再逐步放宽，而不是直接抄一个 0.7。

上线前检查清单

低置信度必须有兜底：阈值以下的请求不能直接返回“无法处理”，必须转到人工队列、规则引擎或让用户确认。
日志记录 model 版本字段：官方 Quick start 示例响应包含 model 字段 jev-1.13.0。上线后回放问题、对比版本行为时，缺少这个字段会非常难受。
失败重试是否会重复计费：API 按 token 计费，超时或 5xx 重试可能导致同一请求被计多次。要限制重试次数，并对失败请求做幂等或去重。
超时降级到规则：不能因为模型 API 超时就让主流程阻塞。设计一个规则分类器或人工队列作为 fallback。
Noul 不做置信度门控：如果你需要 confidence，用 Choice 或 Score；Noul 不返回 confidence。

这次没核实的

TypeSafe API 对输出 token、网络错误重试是否单独计费的具体规则，未能核实。
Playground 是否有历史保存、速率限制、请求量配额等能力，未能核实。
官方是否给出通用置信度阈值推荐，未能核实；现有文档只说按领域和风险自己调整。

参考来源

TypeSafe AI Quick start：https://docs.typesafe.ai/introduction/quickstart
Confidence-gated routing：https://docs.typesafe.ai/patterns/confidence-routing
Confidence：https://docs.typesafe.ai/confidence
TypeSafe AI 官网（定价）：https://typesafe.ai/

# Agent # 教程

评论区

0 条评论

登录后可评论。