记录问题，验证判断，留下证据

Jev 到底输出什么#

按照 TypeSafe AI 的公开资料，Jev 属于它定义的 System One 模型。请求主要由两部分组成：

• state：待判断的文本状态；
• questions：预先声明的类型化问题。

目前公开的三类问题原语是：

关键点是，候选集合由调用方定义。模型不能临时发明一个枚举值，也没有“顺便解释一下”的输出通道。它做的是一次受约束的决策，而不是一轮开放式写作。

这和 JSON 模式不是一回事。普通模型通常还是先生成 token，再由调用方校验 JSON；Jev 的接口从问题定义开始就限制了结果空间。官方把它描述成一种面向决策的模型，并使用 RLCD（Reinforcement Learning for Calibrated Decisions）强调概率校准。

当然，类型安全不等于事实正确。如果调用方给了三个错误选项，Jev 仍然只能从这三个选项里选一个。所谓“不会输出类型错误”，解决的是格式和边界问题，不是现实世界的真伪问题。

为什么“只做选择”很重要#

对 Agent 系统来说，生成和选择是两种不同的工作。

生成适合写邮件、写代码、解释证据；选择适合把已经明确的流程分支交给模型判断。后者更容易测试，也更容易重放：输入状态、问题 schema、模型版本和结果都可以作为一条结构化记录保存下来。

这会减少一类常见的脆弱代码：先让模型写“我认为应该进入官网核验阶段”，再用关键词匹配去猜它到底选了哪条路径。使用 choice 后，程序拿到的直接是 verify_official_jd 这样的枚举值，旁边附带概率，而不是一段需要二次解释的句子。

它也更适合高频、低延迟的判断。Jev 不需要为每个决定生成完整的自然语言答案，官方资料强调了并行采样、较低输入价格和输出免费等特征。具体价格、限速和模型别名会变化，接入时应该以 TypeSafe AI 官方文档 为准，而不是把第三方文章里的数字当成长期承诺。

放到 Boss Watch 里，应该放在哪一层#

我们的求职工作台确实有一些适合 Jev 的位置，但边界必须写清楚。

它可以帮助做：

1. 在已捕获的岗位事实中选择下一条只读分析路径；
2. 判断一段页面证据是否满足某个预设条件；
3. 对候选岗位做固定量表评分，并返回排序依据的概率信息；
4. 在多个浏览器动作候选中选择一个“下一步意图”。

它不能替代：

1. 登录、二维码、验证码和平台风控的人工作业；
2. 对外发送消息、投递简历或接受面试的审批；
3. 岗位、联系人和投递状态这类领域事实的持久化；
4. 对页面内容真实性的最终确认。

尤其要注意：模型选择了一个动作，不代表动作已经获准执行。 在 Boss Watch 里，选择结果最多只能进入预览、证据核验或审批队列。真正的外部写操作仍然需要绑定会话、对话、收件人、精确内容哈希和过期时间的人工批准凭证。

这正好契合我们一直坚持的分层：模型负责提出结构化判断，领域服务负责事实和权限，浏览器执行器负责在新鲜页面上完成已批准的动作。Jev 可以让“判断”这一层更窄、更可测，但不能把其他层的责任吞掉。

接入时要留意的现实问题#

Jev 的接口不是 OpenAI 兼容的 chat.completions。它使用自己的 System One 请求形态，因此不能简单地把一个 OpenAI SDK 的 base_url 换掉就假设所有代码都能工作。接入前要确认官方端点、模型版本、问题 schema 和返回字段，并把这些内容固定进适配器测试。

另一个现实问题是概率的解释。校准概率适合在一批预测上评估，不是对某一次选择的正确性担保。我们仍然需要保留原始状态快照、问题定义、模型版本、结果和后续人工修正，才能知道系统到底是在稳定地帮助判断，还是只是稳定地犯同一种错误。

我的结论#

Jev 最有价值的地方，不是“又多了一个模型供应商”，而是它把 Agent 中经常被自然语言掩盖的那部分工作单独拿了出来：在有限选项中做一个可记录、可测试、可校准的选择。

如果任务需要长文本、解释和开放式创作，Jev 不是替代品。如果任务本来就应该返回一个枚举、一个分数或一个是否判断，它值得作为专门的决策模型评估。

对我们的系统来说，下一步不是把它接到所有流程，而是先选一个只读、可回放的选择点做离线评估。只有当输入快照、schema、结果和人工基线都能对齐时，才讨论是否进入在线路径；无论如何，选择结果都不会自动扩大为外部执行权限。

参考资料#

• EggStriker：JEV / Jev 是什么
• TypeSafe AI 官方网站