Jev 是什么，能做什么？和 Agent 的区别，其实是一个「判断」和「执行」的分工问题

先讲一段我自己踩过的坑。

早些年我参与过一个社区产品，评论量每天几万条。最初团队想得很简单：拉一张敏感词表，命中就删。表越拉越长，一百多条规则，维护起来像在跟人玩捉迷藏------对方把「加V信」写成「加 V 信」，再写成「加薇信」，规则就漏了。后来我们改成把每条评论丢给大模型，问它「这是不是广告、要不要拦」。准确率确实上来了，账单也跟着上来了：一条评论一次调用，一天几万次；更别扭的是，模型每次返回都是一整段话，我还得从里面把「是」或「否」抠出来。

那次之后我想明白一件事：我们把「判断」和「生成」搅在一起做了。评论要不要拦，本质是个二选一的问题，答案只需要一个标签加一个概率；但大模型的工作方式是逐字往外写，它得先写「这条评论看起来像是......」，再写「因此我判断......」，最后才落到结论上。为了拿到两个字，我付了几百个 token 的钱，还等了几百毫秒。

工单分派、线索打分、告警分级、内容风控，这些活有一个共同的形状：输入是文本，候选答案事先就能列全，量足够大、值得上自动化，但又没大到要专门组一个算法团队去伺候。它们卡在中间地带------靠 if/else 撑不住，靠大模型又心疼钱和延迟。

Jev 就是冲这个位置来的。它不聊天、不写代码、不解释自己，你给它一段上下文和几个问题，它直接返回标签和概率。很多人第一次听到它，会问「它和 Agent 有什么区别」，其实这个问题问的是：判断这一步，到底该由谁来做。

场景

先把「判断」这件事在工程里的真实处境说清楚。

我后来换过一个项目，做的是 SaaS 后台的工单系统。用户提交反馈，我们要决定三件事：这条反馈归哪个团队处理、急不急、要不要转人工。当时的实现是一堆 if/else 加关键词匹配：正文里有「退款」就进财务，有「报错」就进技术，有「发货」就进物流。上线第一周就出问题------有用户写「我买的会员被重复扣款了，立刻退回来，不然我去投诉」，这条被分进了技术组，因为正文里出现了「系统」两个字。

这类问题的根源不在规则写得不够多，而在于判断这件事本身是有语义的，而正则和关键词没有语义。你没法用字符串匹配去理解「重复扣款」和「系统报错」的区别，因为它们在字面上都可能出现「系统」。

那把这些判断交给大模型行不行？行，但代价是：一条工单一次调用，一天几千条，账单肉眼可见；而且每次返回是一整段分析，我还得写解析代码把结论抠出来。解析还可能失败------模型今天返回「建议分给财务部门」，明天返回「应该由 billing 团队处理」，后天带个 Markdown 列表。为了拿到一个字段，我写了三种正则兜底。

这就是「判断」长期没人管的状态：要么写死规则，要么用大模型硬顶，中间那层是空的。

而这层空档恰好对应一大批高频、低价值、但必须有人做的决策。它们的特征是：答案空间很小（几个选项、一个概率、一个分数），输入是文本，量大，错了后果可控。这类决策不值得动用大模型，但写死规则又不够用。

Jev 想填的就是这层。它把自己定位成「软件系统里的判断器」，不生成文字，只输出结构化的决策结果。理解这一点之后，再看它和 Agent 的关系，就会清楚很多：Agent 是那个「会自己决定下一步做什么并动手执行」的程序，而 Jev 是它循环里那个「负责判断」的零件。两者不在同一层，所以「谁取代谁」这个问题本身就不成立。

原理

它和大模型的根本分歧在「输出」

要理解 Jev，先要理解它和 ChatGPT 这类模型在「输出」这件事上的分歧。

大模型是逐字生成的。你问它「这条工单该给哪个部门」，它内部是一个词一个词往外蹦的过程：先蹦出「这」，再蹦出「条」，再蹦出「工单」......直到蹦完一整段。这个机制适合写文章、写代码、做推理，因为这些东西本来就需要「展开」。但做选择题时，它也得先展开再收束，这就产生了两个浪费：时间上，生成几百个 token 要几百毫秒到几秒；成本上，输出 token 通常比输入还贵。

Jev 是直接给结论的。它不做逐字生成，而是把「这段文本属于哪个选项」「这个判断成立的概率是多少」当成一次前向计算直接算出来。你可以把它想成一个被训练过的分类器：输入是一段上下文，输出是一组预定义问题的答案。

这里有个概念值得展开。心理学里有个划分叫系统一和系统二（System 1 / System 2），出自卡尼曼的《思考，快与慢》。系统一负责快速、直觉、确定的判断，比如你扫一眼消息就知道是广告，不需要逐字分析语法；系统二负责慢速、复杂的推理，比如做一道数学题。Jev 明确把自己放在系统一：它不追求「想得深」，只追求「判得快、判得准、判得便宜」。

这个定位决定了它和 Agent 的第一个分界。Agent 更像系统二------它要规划、要试错、要调用工具、要根据结果调整下一步。Jev 是系统一------它只回答一次，不追问，不规划，不执行。

它怎么接收问题

调用时你给它两样东西：一个 state，用来装待判断的上下文，可以是一段用户留言、一条日志、一条操作指令；一组 questions，用来装你想问的问题。

问题有三种类型，每种对应一类业务语义：

Choice（选择题） ：从你预定义的选项里选一个。比如工单该分给 billing 还是 technical。适合路由、分类、归因。

Noul（是非题）：返回一个 0 到 1 的概率。比如「用户是否在要求退款」。适合判断「是不是」。

Score（打分题）：按你定义的等级打分。比如紧急程度 0 到 10。适合分级、排序。

一次请求可以同时带多个问题，它们并行算完一起返回。返回的结构长这样：每个问题给出它选中的选项、各选项的概率分布，以及一个 confidence（置信度）。比如一个 Choice 问题可能返回「选 billing，概率 1.0，置信度 1.0」；一个 Noul 问题返回「0.99」。

为什么这样设计能便宜？因为它不生成文本，输出只有几十个 token 的结构化数据，输入也短。按公开的对比数据，它的响应在几十到几百毫秒，成本比通用大模型低一到两个数量级。这个差距不是「优化」出来的，是「不做生成」这件事本身省下来的。

这里我想补一句容易绕晕的地方：Choice、Noul、Score 不是三套模型，而是同一套判断能力被你用三种问法去调。你可以理解成同一台计算器，你既可以按加减，也可以按乘除，按键不同，机器还是那台。所以一次请求里三个问题混着问，返回的也是同一批结构，只是字段语义不同。工程上这一点挺重要------它意味着你不用为「分类」和「打分」分别接两套服务，一个调用就能把一条工单的归属、紧急度、是否退款全问出来。

置信度比结论更值得看

这里有个容易被忽略的点，也是我第一次接的时候没重视的：置信度比结论本身更重要。

传统大模型给你一个答案，你很难知道它有多确定。它说「这条应该分给财务」，语气和它说「这条可能分给财务」是一模一样的，你只能靠读它的措辞去猜。Jev 把概率和置信度直接暴露出来，意味着你可以在代码里写「置信度低于 0.8 就转人工」。

它训练时专门做了概率校准，目标是「说八成把握时，实际准确率真的收敛在八成附近」。这个概念叫校准（Calibration），通俗说就是「模型说自己有多确定，就真的有多确定」。传统大模型经常不校准------它可能用 99% 的自信语气说一件只有 60% 把握的事。

为什么校准重要？因为它决定了你能不能在代码里信任这个数字。如果你写 if confidence > 0.9: 自动放行，而模型的 0.9 实际只有 0.6 的准确率，那你放行的就是一批错判。校准是这套方案能不能落地的关键，后面【边界】会重点讲。

Agent 是什么，为什么它需要判断

现在说 Agent。Agent 是一个会自己决定「下一步做什么」并动手执行的程序。它有一个循环：观察当前状态 → 决定调用哪个工具 → 执行 → 看结果 → 再决定下一步。它擅长的是「多步任务」，比如「帮我把这个 bug 修了」，它要读代码、改代码、跑测试、看报错、再改。

把这个循环拆开看，你会发现里面塞满了小判断：这一步该用哪个工具？这个操作危不危险？这个结果算不算成功？要不要继续重试？这些判断以前要么写死规则（if 工具名 == "search"），要么丢给大模型（让它在思考过程里顺便判断一下）。写死规则不够灵活，丢给大模型又慢又贵------而且 Agent 循环一次可能要做好几个判断，累积起来延迟和成本都上去了。

Jev 在这套结构里的位置就很清楚了：它回答「这是什么、该不该」，Agent 回答「接下来做什么、怎么做」。 Jev 是单步的、无状态的、只输出判断；Agent 是多步的、有状态的、会改变外部世界。

所以「Jev 会不会取代 Agent」这个问题本身就不成立。它们不在同一层。真正的关系是：Agent 在它的循环里需要做很多次小判断，这些判断可以交给 Jev。

我自己的判断是：Jev 不是 Agent 的竞品，是 Agent 的零件。 一个成熟的 Agent 大概会这样分工------重活交给 GPT、Claude 慢慢想，小判断丢给 Jev 秒回，能写死的逻辑交给普通代码，实在拿不准的留给人。这四层各司其职，不是互相替代。

实例

原理讲了 Jev 输出什么、Agent 负责什么，这一章用一个最小可跑的工单分派例子，把「判断层」和「执行层」怎么接起来走一遍。

场景回到开头那个 SaaS 后台：用户提交一条反馈，我们要判断它属于哪个团队、急不急、要不要转人工。

第一步：先分清判断和执行

在这个流程里，判断是「这条反馈属于哪类、急不急」，执行是「根据判断结果，把工单塞进对应队列、发通知、必要时打电话叫人」。

判断交给 Jev，执行是普通的业务代码------不需要 Agent，因为流程是固定的。只有当「下一步做什么」本身不固定时，才需要 Agent 介入。这一步想清楚，能省掉很多过度设计。我见过有人一上来就上 Agent 框架，结果发现流程是死的，白白增加了一层复杂度。

第二步：定义问题和选项

Jev 的输出质量，一半取决于你怎么定义问题。选项要互斥、要覆盖真实情况、描述要能区分开。我一般会把选项写成「业务同事能看懂的一句话」，而不是一个词，因为模型是靠描述来区分的。

questions = {
    "department": {
        "type": "choice",
        "instructions": "这条反馈应该由哪个团队处理",
        "criteria": {
            "billing": "扣费、退款、发票、订阅相关",
            "technical": "功能报错、崩溃、无法使用",
            "logistics": "发货、物流、破损、错发漏发",
        },
    },
    "is_urgent": {
        "type": "noul",
        "instructions": "用户是否表达了强烈的时间紧迫感或投诉威胁",
    },
}

这里 department 是选择题，is_urgent 是是非题。注意 criteria 里的描述是给模型看的判断依据，写得越具体，边界越清楚。如果你把 billing 写成「钱的问题」，把 technical 写成「技术问题」，模型在「重复扣款」这种同时沾边的输入上就会摇摆。

第三步：拼上下文，发请求

state 里除了用户原文，我习惯把一点结构化信息也带上，比如用户等级、历史工单数。因为这些信息会影响判断，但模型从原文里看不到。

state = """
用户等级：VIP3
历史工单数：2
反馈原文：我买的年度会员昨天被你们系统重复扣款了368元，
立刻原路退回并取消多扣的，不然我直接去12315投诉！
"""

发出去之后，你会拿到类似这样的返回：department 选中 billing，概率 1.0；is_urgent 返回 0.99。跑完该看到的是：模型没有被「投诉」这个词带偏去判成「技术问题」，而是结合「重复扣款」判到了财务。这正是关键词方案做不到的地方------它看的是语义，不是字面。

第四步：用置信度做路由

这是最关键的一步，也是很多人第一次接会踩的坑。不要直接 if department == "billing" 就完事，要把置信度也纳入判断：

if dept.confidence >= 0.8 and urgent.noul >= 0.8:
    route_to(dept.choice, priority="high")
else:
    route_to_human(state)  # 置信度不够，转人工

跑完该看到的是：大部分工单被自动分派，少数模糊的进了人工队列。人工只看模型拿不准的那一小撮，工作量降下来，而且不会因为模型判错而背锅------因为低置信度的根本没自动放行。

我一般还会把低置信度的样本记下来，攒一段时间回头看，它们往往暴露的是选项定义的问题，而不是模型的问题。

第五步：这一步和 Agent 的关系

如果后面你想让「处理工单」这件事更自动，比如工单进了财务队列后，Agent 自己去查订单、发起退款、回复用户，那这个 Agent 在每一步都可以用 Jev 做判断：这一步该不该查订单、这个退款金额是否异常、这条回复能不能直接发。

Jev 是 Agent 循环里的「判断器」，Agent 是那个「执行器」。两者叠起来，才是完整的自动化。但注意顺序------先把判断层跑通、验证准了，再谈执行层。反过来做，你会在一个判断都不准的 Agent 上浪费大量调试时间。

边界

能跑通不等于该用。这一章讲这条路径的局限和坑。

第一，它做不了生成类的事。 写文案、写代码、总结文档、解释原因，这些它一概做不了，因为它根本不生成文本。如果需求是「帮我写一段回复」，继续交给通用大模型，别硬套 Jev。我见过有人想用它做客服自动回复，方向就错了------它只能判断「这条该不该回复」，不能写回复内容。

第二，它的「聪明」是有上限的。 有工程师做过对比，拿一个几百 M 参数的开源分类模型复刻，效果和 Jev 差不多，结论是「Jev 治的是贵和慢，治不了笨」。这话不好听但大体成立：它本质是一个工程化很好的分类器。如果你的场景需要复杂推理，比如「根据这段合同判断双方责任划分」，它的准确率不会比大模型高，因为它本来就没打算做推理。需要推理的场景，继续用大模型。

第三，置信度必须自己在业务数据上验。 官方说做了概率校准，但校准是在它的训练分布上做的，你的业务数据分布可能不一样。我一般会先做一件事：拿一批有历史人工结论的旧数据，喂给它跑一遍，看「它说 0.9 把握的那些，实际对了多少」。如果对不上，那置信度阈值就不能照搬默认值。这一步不做，直接上生产，很可能出现「模型很自信但判错了」的情况，而且因为你信了置信度，反而更容易放行错判。这是我认为最容易被跳过、后果最严重的一步。

第四，选项设计错了，它救不回来。 如果两个选项的语义有重叠，比如「物流问题」和「发货问题」，模型会在两者之间摇摆，置信度普遍偏低。这不是模型的错，是问题定义没做好。选项要互斥、要穷尽、要用业务语言描述。我的经验是：如果你自己都说不清两个选项的区别，别指望模型能分清。

第五，别指望它替代人工兜底。 它的价值在于「把简单判断自动化，把人工留给难的」，不是「全自动」。凡是判断错了代价很高的场景，比如直接放行一笔大额退款，一定要保留人工复核或二次校验，哪怕置信度很高。置信度是概率，不是保证。

那什么时候该用？ 我的判断标准是三条同时满足：判断对象是文本、选项事先能列清楚、量大到值得自动化但没大到值得专门训模型。三条缺一条，就再想想。缺第一条（比如判断对象是图片），它做不了；缺第二条（选项说不清），它判不准；缺第三条（量很小），人工看看就行，接它反而是增加复杂度。

还有一点值得说清楚：Jev 的「无状态」是优点，也是限制。它每次只看你给的那一段 state，不会记得上一轮问了什么、判过什么。这在工单分派这种「一条一判」的场景里正好------不需要上下文，也就没有状态管理的麻烦。但如果你要判断的是「这个用户最近三次提问是不是在重复骚扰」，那就得你自己把历史拼进 state 里，或者在外面维护一个会话状态再传给它。它不替你记，也不该替你记，因为一旦有了状态，它就从「判断器」变成了「有记忆的系统」，复杂度会往上跳一个量级。我倾向于让它保持无状态，把状态放在业务代码里管，这样出问题时排查路径最短。

小结

回到开头那个凌晨两点的告警场景。当时的困境是「判断这件事没人管」：规则写不完，大模型又贵又慢。Jev 给的是一个新选项------把判断单独抽出来，做成一层又快又便宜的「智能 if/else」。

记住这几条：

1. Jev 不是「小号大模型」，是「不做生成」的模型。 它的快和便宜来自「不写字」，不是来自「优化得好」。理解了这一点，你就不会拿它去做它做不了的事。

2. 它回答「是什么、该不该」，Agent 回答「接下来做什么、怎么做」。 两者是判断层和执行层的分工，不是替代关系。Agent 的循环里塞满了小判断，这些判断可以交给 Jev。

3. 置信度比结论更值得看。 代码里用置信度做路由、做转人工，比直接用结论安全得多。这也是它和「关键词匹配」最本质的区别------它不仅告诉你答案，还告诉你它有多确定。

4. 落地前先拿旧数据验校准。 在你自己业务分布上验过「说九成把握是不是真有九成」，再定阈值。这一步不做，后面都是空中楼阁。

5. 它治贵和慢，不治笨。 需要复杂推理的场景，继续用大模型；能写死的逻辑，继续写死。

最后留一个问题给你自己：你手头有没有那种「量大、选项清楚、但一直靠人看」的判断环节？如果有，那大概就是 Jev 该站的位置；如果没有，那说明你现在的流程还没到需要它的规模------这也是一种有价值的判断。