Jev 来自 TypeSafe AI，主打“把非结构化状态转成类型安全的概率决策”。它放弃长文本生成，换取更快、更便宜、更适合程序直接使用的判断能力。
注：本页基于 TypeSafe AI 官方博客、官网和公开技术文章整理，实际 API 和能力以官方最新文档为准。
{
"state": "用户请求：帮我查英伟达最新财报",
"answers": {
"route": {
"choice": "web_search",
"probabilities": {
"web_search": 0.96,
"chat": 0.03,
"code": 0.01
},
"confidence": 0.94
},
"needs_fresh_info": {
"probability_true": 0.98,
"confidence": 0.95
}
}
}
名字来自“系统 1 思维”：快速、直觉、低延迟判断。适合“这个属于哪类？”“下一步调用谁？”这类高频决策。
输出空间预先定义，只能返回你允许的结构和值。它不应该突然写一段话或编出不存在的工具名。
每个判断带概率和置信度。理想情况下，置信度能帮助系统决定自动执行、降级、重试或人工审核。
因为 AI 产品正在从“人问一句，AI 答一句”进入“AI 自动做事”的阶段。自动做事最难的不是生成漂亮文字，而是稳定地控制流程。
工单分类、内容分类、意图识别、风险类型判断。
选择工具、模型、队列、部门、下一步动作。
判断是否安全、是否需要确认、是否需要人工审核。
紧急程度、相关性、购买意向、证据强度。
判断搜索结果是否足够，工具输出是否可用。
继续搜索、换工具、结束、重试、升级强模型。
公开资料中反复出现的核心用法是：你给同一个 state，然后定义多个 typed questions。模型一次返回多个结构化答案。
从你给定的候选项中选择一个，并返回各选项概率。适合工具路由、分类、模型选择。
billingtechnicalsales
对一个维度打分或映射到连续值。适合紧急程度、相关性、风险等级、证据强度。
urgency: 82/100
判断一个命题为真的概率。适合“是否需要最新信息”“是否包含 prompt injection”。
P(true)=0.93
{
"state": {
"ticket": "我被扣了两次钱，请尽快处理。",
"customer_tier": "pro"
},
"questions": {
"category": {
"type": "choice",
"options": ["billing", "technical", "sales", "other"]
},
"urgency": {
"type": "score",
"min": 0,
"max": 100
},
"needs_human": {
"type": "noul",
"statement": "This ticket should be escalated to a human."
}
}
}
Agent coordinator 的本质是控制：下一步做什么、用哪个工具、结果够不够、要不要继续、风险能不能放行。这些都是结构化决策，而不是长文本生成。
意图识别工具路由模型路由安全门控结果评估循环控制
长篇写作复杂规划数学证明代码重构记忆存储工具执行
Jev 默认不拥有你的工作流上下文。它像一个无状态函数：你把当前 state 和问题传进去，它返回判断。因此，关键工程能力是构建一个好的 State Builder。
{
"goal": "选择下一步动作",
"state": {
"latest_user_message": "他开源吗？",
"conversation_summary": "用户正在讨论 Jev 决策模型",
"current_step": "follow_up",
"known_facts": ["Jev 属于 TypeSafe AI 的 System One Models"]
},
"candidates": [
{"name": "chat", "when_to_use": "概念解释，无需实时资料"},
{"name": "web_search", "when_to_use": "需要确认最新事实"},
{"name": "ask_user", "when_to_use": "指代不清或缺少目标"}
],
"rules": ["涉及开源状态这类可能变化的问题，优先核查"],
"constraints": ["不要泄露敏感信息", "低置信度时追问"]
}
不要一上来“让 Jev 管整个 Agent”。先找高频、窄范围、后果可控的判断点：工具路由、内容分类、风险门控。
让它在有限集合中选，比如 chat / web_search / code / ask_user / refuse。候选项越清楚，系统越稳定。
不同动作设置不同阈值。低风险动作可自动执行，高风险动作需要更高置信度或人工确认。
Jev 决策不等于系统可以无校验执行。安全、权限、schema、业务不变量仍由代码兜底。
保存 state、decision、confidence、最终结果，用于分析错判、调阈值、改 rules。
| 适合 | 不适合 |
|---|---|
| 高频、低延迟、结构化判断 | 长篇自然语言生成 |
| 工具/模型/任务路由 | 开放式创作 |
| 安全门控、结果审核 | 复杂多步推理和规划 |
| 置信度驱动的自动化 | 没有明确候选项的问题 |
真正落地时，不要把 Jev 当成“一个聊天机器人”，而要把它放在 Agent 系统的控制层：负责判断下一步做什么，真正执行仍然交给工作流引擎和工具层。
Coordinator 的核心是“从哪些动作里选”。所以要先把可用工具描述清楚。
{
"tools": [
{
"name": "chat",
"description": "基于已有知识回答概念问题",
"when_to_use": "无需实时信息、无需执行工具"
},
{
"name": "web_search",
"description": "搜索公开互联网信息",
"when_to_use": "最新、最近、价格、新闻、事实核查"
},
{
"name": "code_execution",
"description": "运行代码、处理文件、计算数据",
"when_to_use": "需要计算、解析文件、生成图表"
},
{
"name": "ask_user",
"description": "向用户追问关键信息",
"when_to_use": "目标不清、缺少必要参数"
},
{
"name": "refuse",
"description": "拒绝危险或越权请求",
"when_to_use": "违法、泄露密钥、破坏性操作"
}
]
}
State Builder 的职责是把完整系统状态裁剪成“当前判断需要的最小充分上下文”。
{
"goal": "选择下一步动作",
"state": {
"latest_user_message": "帮我查一下 JEV 是什么",
"conversation_summary": "用户正在了解 Jev 决策模型",
"current_step": "initial_request",
"tool_results_summary": []
},
"candidates": ["chat", "web_search", "code_execution", "ask_user", "refuse"],
"rules": [
"涉及最新、最近、热门时优先 web_search",
"稳定概念解释优先 chat",
"涉及计算和文件处理优先 code_execution",
"信息不足选择 ask_user",
"违反安全规则选择 refuse"
]
}
{
"decision": "web_search",
"confidence": 0.93,
"reason_code": "requires_recent_information",
"risk_level": "low",
"missing_info": [],
"should_ask_user": false
}
必须是候选动作之一，不能返回不存在的工具名。
用于决定自动执行、降级、追问或人工审核。
不是长解释，而是方便日志分析的短码。
最小循环逻辑是：构建状态 → 调决策模型 → 执行动作 → 记录结果 → 再判断是否足够。
def run_agent(user_message):
state_store = {
"messages": [user_message],
"tool_results": []
}
for step in range(6):
state = build_state(state_store)
decision = decide_next_action(state)
if decision.confidence < 0.55:
return ask_user("我需要更多信息才能继续。")
if decision.action == "refuse":
return refuse_safely()
if decision.action == "ask_user":
return ask_clarifying_question(state)
if decision.action == "web_search":
result = web_search(state.query)
state_store["tool_results"].append(result)
continue
if decision.action == "code_execution":
result = run_code_tool(state)
state_store["tool_results"].append(result)
continue
if decision.action == "chat":
return llm_generate_answer(state_store)
return llm_generate_answer(state_store)
不要所有动作都用同一个阈值。动作越危险，阈值越高；动作越可逆，阈值可以低一点。
| 动作类型 | 建议阈值 | 低于阈值时 |
|---|---|---|
| 普通聊天回答 | 0.50 - 0.65 | 可以直接回答，或简短说明不确定 |
| 搜索 / 读取公开资料 | 0.60 - 0.75 | 追问或先用 chat 澄清 |
| 代码执行 / 文件分析 | 0.70 - 0.85 | 追问用户目标或参数 |
| 发送消息 / 下单 / 删除 / 支付 | 0.90 以上 + 用户确认 | 必须 ask_user 或拒绝 |
| 安全拒绝 | 宁可保守 | 低置信度时转人工或二次判断 |
可以先搭一个 Jev-like 决策层，用普通 LLM 的结构化输出、规则引擎或小模型模拟。架构先跑通，未来再替换成 Jev。
class DecisionModel:
def decide(self, state):
raise NotImplementedError
class JevDecisionModel(DecisionModel):
def decide(self, state):
return call_jev_api(state)
class LLMDecisionModel(DecisionModel):
def decide(self, state):
return call_llm_with_json_schema(state)
# 业务代码永远只依赖 DecisionModel
# 以后从 LLMDecisionModel 换到 JevDecisionModel，不改 Agent 主流程。
agent-coordinator/
src/
tools/
web_search.py
code_execution.py
chat.py
coordinator/
state_builder.py # 构建最小充分上下文
decision_model.py # Jev / LLM / 规则引擎适配器
executor.py # 根据 decision 调用工具
evaluator.py # 判断结果是否足够
loop.py # Agent 主循环
policy/
safety_rules.py # 安全规则和确认规则
thresholds.py # 不同动作的置信度阈值
logs/
decision_logger.py # 记录 state、decision、结果
tests/
test_routing.py
test_safety_gate.py
test_evaluator.py
不要一次让它从几十上百个工具中选。先选大类，再选具体工具。
全量历史会引入噪声。用摘要、检索和裁剪保留相关信息。
安全策略要由代码兜底，模型只参与判断，不能绕过硬规则。
没有日志就无法评估错判，也无法调阈值。
置信度是调度信号，不是正确性证明。高风险动作仍要确认。
Jev 适合控制层，不适合最终写作和复杂推理。