---
author: OOMOL
author_url: https://oomol.com/zh-cn/about/
datePublished: 2026-09-18
title: 让 AI 学会做选择：Jev 带来的 5 个 Agent Skill 灵感
description: 从音乐创作、游戏 NPC 到 Skill 路由，探索 Jev 的 5 个应用灵感，并通过 OOMOL 新增的 Cloudflare
  Workers AI Provider，将 Jev 判断能力接入自己的 Agent 工作流。
lang: zh-CN
canonical_url: https://oomol.com/zh-cn/blog/jev-agent-skills/
markdown_url: https://oomol.com/zh-cn/blog/jev-agent-skills.md
---

![Jev 的五个应用灵感：音乐创作、游戏 NPC、点子评审、Skill 路由与日志筛选](/blog/jev-agent-skills/zh-cn-cover.webp)

写出十个标题之后，哪个值得留下？装了几十个 Skill 之后，这次任务该调用谁？游戏里的守卫看到一个可疑的人，应该继续巡逻、上前盘问，还是拉响警报？

这些任务的输出可能只有一个选项，但要选得合适，往往需要理解上下文。

TypeSafe 于 2026 年 9 月 15 日推出 Jev 的早期访问版本，专门用于这类判断任务：接收文本或结构化状态，根据预先定义的问题类型，返回选项或评分，以及相应的概率信息。开发者可以把这些结果接入程序，决定下一步怎么走。[官方介绍](https://typesafe.ai/blog/introducing-system-one-models-and-jev)

Jev 当前接收文本输入。图片、音频和视频需要先转换为文本描述或结构化字段，再交给它判断。[输入要求](https://docs.typesafe.ai/models)

对关注 Agent 和 Skills 的 OOMOL 读者来说，Jev 带来的一个值得尝试的方向是：**把工作流中反复出现的判断单独提取出来，写清标准，再把判断与后续动作组织成可复用的 Skill。**

OOMOL 已新增支持 Jev 的 Cloudflare Workers AI Provider。完成连接后，就可以在自己的 Agent 工作流中调用 Jev，把下面这些思路用到具体任务里。

## Jev 的基本原理：把语义判断变成程序可用的结果

从公开的技术说明来看，Jev 是一种面向结构化决策的模型，TypeSafe 将这类模型称为 **System One 模型**。一次请求包含两部分：`state` 提供待判断的内容和背景，`questions` 定义要问的问题、答案类型与判断标准。模型返回带类型约束的结果，程序可以直接用它做分支、排序或路由。[官方技术概述](https://docs.typesafe.ai/introduction)

它提供三种基本判断类型：

| 类型 | 解决什么问题 | 返回什么 |
| --- | --- | --- |
| **Choice：选择** | 从预设选项中选一个，例如给消息分类 | 选中的选项、各选项的概率分布，以及置信度 |
| **Score：评分** | 根据事先定义的有序等级评估程度 | 评分、各等级的概率分布，以及置信度；评分可以落在两个等级之间 |
| **Noul：真假判断** | 判断一个明确陈述是否成立 | 0 到 1 之间的“是”的概率，不附带单独的置信度字段 |

这些问题可以放进同一次请求，围绕同一份 `state` 独立、并行地评估。同一次请求中的问题不会读取彼此的答案；如果后一个判断确实依赖前一个结果，就由程序拿到结果后再发起下一次请求。[问题类型与组合方式](https://docs.typesafe.ai/primitives)

生成式语言模型通常逐个 token 生成回答文本。根据 TypeSafe 的说明，Jev 采用面向这些受约束结果的并行采样方式，直接输出判断与概率，省去了生成自由文本答案的过程。它的训练方法称为 **RLCD（Reinforcement Learning for Calibrated Decisions，面向校准决策的强化学习）**，目标包括让输出概率更贴近实际发生频率。[模型设计](https://typesafe.ai/blog/introducing-system-one-models-and-jev) · [RLCD 说明](https://docs.typesafe.ai/introduction/machine-learning-primer)

“概率校准”可以这样理解：在足够多、相似的判断中，被赋予 80% 概率的事件，理想情况下应当大约有 80% 真正发生。这是统计意义上的目标，不能保证某一次回答正确。Choice 和 Score 的 `confidence` 则由概率分布计算得到，用来概括结果有多集中，不能直接当成“这次回答正确的概率”。是否自动执行、补充信息或交给人工复核，仍由程序规则决定，并需要用实际数据验证。[概率与置信度](https://docs.typesafe.ai/confidence)

## 一个简单例子：把一条售后消息分到正确的位置

假设一家网店收到消息：

> 今天收到的台灯，灯罩裂了，请帮我换一个。

开发者把这条消息作为 `state`，并提前定义三个问题。下面是为了说明流程而编写的结果示例，**并非实际调用返回值**：

| 提前定义的问题 | 示例结果 | 程序怎样使用 |
| --- | --- | --- |
| Choice：属于“售后换货、物流查询、售前咨询、其他”中的哪一类？ | 售后换货 92%、物流查询 3%、售前咨询 1%、其他 4%；选择“售后换货” | 根据路由规则，送入换货工单队列 |
| Noul：客户是否明确要求换货？ | 0.98，即模型估计“是”的概率为 98% | 给工单添加“明确提出换货”的标记 |
| Score：语气属于“平静、中等不满、强烈不满”中的什么程度？ | 评分接近“中等不满”等级 | 作为客服查看工单时的参考信息 |

这个过程像一张事先设计好的分拣表：**人定义问题和选项，Jev 根据消息做判断，程序决定分到哪里。** 如果消息太含糊，各选项的概率接近，程序也可以将它转入待复核队列。

这里的 98% 表示“明确要求换货”这一判断为“是”的概率，不表示客户有“98% 的不满”。模型也没有完成换货：查订单、核对规则、生成回复和实际处理，需要由其他工具、生成模型或客服继续完成。

## 生成、判断、执行，可以各有分工

以挑选文章标题为例，一条工作流可以这样拆开：

- 生成模型根据素材写出十个候选标题。
- Jev 按清晰度、具体性，以及承诺是否有素材依据等固定标准评估。
- 代码汇总结果，把候选标题和评分交给作者选择。

生成模型负责提出候选，Jev 负责语义判断，代码负责计算与执行。Skill 则描述这套流程：需要什么输入、如何调用工具、遇到不确定结果怎么办，以及最终交付什么。

这种分工也让调试更具体。标题不好，可以检查生成要求；排序不合理，可以调整评判标准；结果算错了，就检查汇总逻辑。

社区已经出现了一些很有意思的探索。下面五个项目分别展示了这种分工可以走向哪里。其中既有附带 `SKILL.md` 的工具，也有应用和代码库；应用案例需要额外封装，才能成为 Agent 可直接使用的 Skill。

## 1. 音乐创作：让模型选择音乐参数，让程序生成音符

[Jev Playground](https://github.com/wustep/jev-playground) 将音乐创作拆成一组有限选择：曲子的情绪基调、结构、调性、节拍、速度、音色与乐句。Jev 选择这些参数，程序再将它们展开为音符、乐谱和播放结果，并支持 MIDI 导出。

这个设计给 Skill 开发提供了一个直观例子。用户可以先描述用途，比如“一段适合夜晚读书的背景音乐”，工作流再将描述转成参数选择，调用已有的音乐程序，交付乐谱和 MIDI。

这是一种可以继续封装的“音乐方案 Skill”。它的可控性来自明确的选项：想调整音乐情绪，可以修改对应参数；想改变节奏，可以改速度与节拍。

项目也提供无需 API Key 的离线模式，使用启发式逻辑。体验时要区分离线结果和真实 Jev 调用；听到音乐本身，并不能证明模型参与了创作。

## 2. 游戏 NPC：把守卫的判断过程展示出来

[HEIST//ONE](https://github.com/AbdelStark/heist-one) 是一个博物馆潜行游戏。玩家通过伪装、证件、灯光和噪声影响守卫的判断；Jev 评估威胁、可疑程度、战术意图和关注目标，代码处理物理、寻路、合法动作与胜负。

有意思的地方在于，界面能展示守卫收到的证据、模型给出的概率，以及最终执行的行为。

当守卫突然追过来时，开发者可以观察：它看到了什么？哪个判断发生了变化？程序怎样把判断转成行动？

这种方式适合继续做成可复用的 NPC 决策流程：输入角色能感知到的局部状态，从预设动作中选择一个，再由游戏引擎检查和执行。角色的可选动作与执行规则都由开发者定义。

项目默认使用无需 API Key 的脚本模式；启用 Jev 后才会实际调用模型。作者提供了真实调用的运行记录，但单次运行记录不足以说明它在不同场景中的稳定性。

## 3. 点子评审：让几个方案接受同一套提问

[Kill My Idea](https://github.com/monteduro/killmyidea) 把创业点子评估做成了一个小工具：向 Jev 提出十个问题，包括八个评分维度，以及对点子类别和表述清晰程度的判断，再由程序加权得出 KILL（放弃）、FIX（修改）或 SHIP（推出）的建议。

它还会根据赚钱、开源或纯好玩等目标，调整评分重点。

这个项目可以启发一种“方案对比 Skill”：一次输入多个点子，使用相同的维度评估，再把差异并排展示。用户能更容易看见，哪些方案表达清楚，哪些依赖尚未验证的假设，哪些值得先做一个小实验。

固定标准有助于比较。评分仍需要接受现实检验，尤其要验证目标用户是否有需求、是否愿意使用或付费。项目说明还提到，成功完成的评估默认会在服务端归档，表单提供不参与归档的选项。

## 4. Skill 路由：给 Agent 留下“无需 Skill”的选项

Skill 越多，选择就越重要。

[Jev Agent Skill Router](https://github.com/GodsBoy/jev-agent-skill-router) 接收用户请求与 Skill 目录，返回三类结果之一：选择某个 Skill、无需 Skill，或需要复核。项目本身负责路由，后续加载和执行要由其他程序完成。

这对维护大量 Skills 的人很有启发。路由器除了要回答“哪个最相关”，还需要处理任务边界：用户只是问一个概念，可能无需专门的 Skill；多个 Skill 都看起来合适，则需要进一步检查。无需 Skill，也不等于后续一定不会调用工具。

如果把这个过程做成一个可观察的面板，展示请求、候选项、选择结果与不确定性，就能帮助维护者发现描述过于相似、职责交叉或触发范围过宽的 Skill。

对于 OOMOL 这样的 Apps 与 Skills 使用场景，这是一个值得探索的设计方向。这里讨论的是社区项目带来的启发，具体接入仍需开发与验证。

## 5. 日志筛选：先判断哪些值得继续分析

[Jev Logs](https://github.com/reachjalil/jevlogs) 为日志添加诊断价值、优先级和路由判断，帮助选择哪些日志值得交给大模型继续分析，同时保留原始归档链路。项目同时提供 npm 包与 `SKILL.md`，负责筛选和路由，根因分析由后续流程完成。

这类流程适合用来处理重复出现的初筛任务：先识别需要进一步关注的内容，再调用分析能力更强的模型。

这里的关键是保留复查依据。被跳过的日志仍然归档，后续才能检查是否漏掉了有价值的线索。能节省多少成本，要看实际日志分布、筛选错误，以及下游模型的调用方式。

## 从一个“标题评审 Skill”开始

![标题评审流程：生成模型提出候选，通过 OOMOL Provider 调用 Jev 判断，代码汇总并由作者复核；Skill 保存整个流程的输入要求、判断标准和复核规则](/blog/jev-agent-skills/zh-cn-workflow.webp)

*图 1：以标题评审为例，生成、判断与复核各有分工；图示为概念说明，非产品界面或实测结果。*

如果要把这些思路用到日常工作，我们建议先尝试一个范围明确、输出容易检查的任务，比如标题评审。

可以先写下这样的任务要求：

> 根据原始素材，评估十个候选标题的清晰度、具体性，以及是否包含素材未支持的承诺。保留各项结果，列出值得人工复核的标题，由作者决定最终采用哪一个。

接下来，把流程中的几个约定写清楚：

| 约定 | 标题评审中的例子 |
| --- | --- |
| 输入 | 原始素材、目标读者、候选标题 |
| 判断标准 | 能否看出主题，是否具体，承诺是否有素材依据 |
| 结果用途 | 帮助比较和复核，保留各维度结果 |
| 例外处理 | 素材不足或判断不确定时，交给作者检查 |
| 验证方法 | 用包含好标题、差标题和模糊案例的真实样本检查结果 |

先跑通这一小段流程，再考虑批量处理和更多工具。尤其是中文内容，官方说明 Jev 当前在英文上的准确性最好，其他语言需要用自己的样本验证。[模型与语言支持](https://docs.typesafe.ai/models)

## 在 OOMOL 中连接 Provider，开始使用 Jev

**OOMOL 已新增支持 Jev 的 Cloudflare Workers AI Provider，接上就可以使用。** Jev 由 TypeSafe 开发，Cloudflare 提供模型访问入口，OOMOL 则把这个入口接入 Agent 的工具使用流程。Cloudflare 的模型目录已列出 [Jev](https://developers.cloudflare.com/ai/models/typesafe/jev/)。

可以从前面的标题评审开始：

1. 在 [OOMOL 控制台](https://console.oomol.com/)中，完成 Cloudflare Workers AI Provider 的连接配置。
2. 准备原始素材和候选标题，告诉 Agent 要比较哪些维度，并明确要求调用 Jev。
3. 查看返回的判断，将需要修改或人工复核的标题挑出来，再决定下一步。

例如，连接完成后，可以把下面这段任务交给 Agent：

> 使用已连接的 Cloudflare Workers AI Provider 调用 Jev，评估下面十个标题。请结合原始素材，分别判断标题是否清楚、是否具体，以及是否包含素材未支持的承诺。整理成对比表，保留各项判断，把需要我复核的标题单独列出。

Agent 会先将任务拆成 Jev 支持的判断问题，再将返回结果整理成表格和文字说明。Jev 在其中负责判断。

跑通之后，可以把输入要求、评判标准、调用步骤和复核规则整理成一个标题评审 Skill。下次换一批素材，继续沿用同一套流程。类似地，也可以从候选方案比较、内容分类或日志初筛开始。

**Provider 提供模型调用入口，Skill 保存完成任务的方法。** 本文中的音乐、游戏和路由项目提供了设计参考；要复用它们的完整玩法，仍需接入相应程序和执行逻辑。

需要进一步设计判断问题时，可以参考 [TypeSafe 官方 Skill](https://github.com/typesafe-ai/skills)。使用其他 MCP 接入方式的开发者，也可以查看社区的 [jev-mcp](https://github.com/rashedInt32/jev-mcp)。

## 好的判断，需要清楚的问题和可检查的结果

Jev 让分类、评分和选择更容易成为程序的一部分。使用时，仍然需要定义候选项、判断标准，以及选错之后如何处理。

官方也列出了计数、数学、日期比较与复杂间接推理等局限。因此，明确的计算应交给代码；结构正确的输出，也需要检查判断是否符合实际。[已知能力局限](https://docs.typesafe.ai/model-jaggedness/jev-1.13)

从这些项目中，OOMOL 读者可以带走一个具体的开发思路：找到工作流里那个反复出现的选择，为它准备足够的上下文，写出可以验证的标准，再将结果连接到下一步动作。

可以从挑一个标题、选一个 Skill，或决定一条日志是否需要深入分析开始。把输入、判断、执行和复核连起来，才构成一项能够重复使用的能力。

## 用 Leina Agent，在聊天里开始体验

如果你想先体验 Agent 能做什么，可以从 **[Leina Agent](https://leina.ai/)** 开始。创建并运行一个 Agent，就可以先和它聊天、体验 GPT 等模型的对话能力，再按自己的任务逐步添加工具。可选模型以 Leina 当前提供的配置为准。

Leina 可以接入 **Discord、Slack、Microsoft Teams、微信（WeChat）、飞书和钉钉**等常见聊天工具。完成对应渠道的接入后，在手机或电脑上打开你平时使用的聊天应用，就能把任务交给 Agent，无需先自己部署网关或编写 API 调用代码。

可以按下面三步开始：

1. **创建 Agent**：打开 [leina.ai](https://leina.ai/)，从开始使用入口进入，创建并运行自己的 Leina Agent。
2. **接入常用聊天工具**：按所选平台的接入说明完成配置，在手机或电脑上发出第一条消息。
3. **从一个小任务开始**：先让它解释概念、整理你发来的文字或提出几个标题；需要访问其他应用时，再添加相应的 Connector 并完成授权。

例如，你可以直接发给它：

> 用一个生活中的例子解释 Jev，然后根据下面这段素材，帮我写五个标题。

有了具体任务，再给 Agent 配置所需的 **Connector（应用连接器）**。它们让 Agent 能在授权范围内访问其他服务，把聊天中的需求继续落实为工作。你可以根据自己的需要配置不同的 Connector，也可以把跑通的步骤整理成 Skill，留给下次使用。

想进一步体验本文的 Jev 判断流程，就为 Agent 配置支持 Jev 的 Cloudflare Workers AI Provider 连接，再发送前面的标题评审要求。日常聊天和生成标题由对话模型完成；明确调用 Jev 后，才是在体验它的分类、评分与选择能力。

**[前往 Leina，创建你的 Agent](https://leina.ai/)**，先从一条消息开始。如果已经有自己的 Agent，也可以继续通过 [OOMOL 控制台](https://console.oomol.com/)连接 Provider，沿用现有的工作方式。

---

*资料说明：本文基于 2026 年 9 月 18 日的 Jev 调研报告整理，并复核了 TypeSafe 官方介绍、模型文档与能力局限。社区项目描述来自报告所核验的作者说明；本文未复现社区演示或进行性能测试。OOMOL 新增 Provider 及 Leina 体验入口、渠道支持的信息结合产品团队说明与 Leina 官网整理；本文未进行该 Provider 的实际调用测试。文中的社区应用与 Skill 延伸方案不等同于 OOMOL 已上线的完整应用。*