TL;DR
- 上一篇关于 Jev 的文章留下了一句话没有收尾：企业里绝大多数 AI 流量是路由、分诊、分类和闸门——是决策，不是文章。
- 如果这句话成立，那么单体式的智能体循环就是错的形状。你正在把分支逻辑交给一个采样过程去解释。
- Jev 把智能体拆成两个层面：决策层（从不生成），和生成层（只做生成）——中间夹一层用代码写的控制层。
- 控制流从自然语言搬回代码，于是它能被测试、被版本化、被 diff。
- 准确率数字在专用任务上并不亮眼（厂商自家看板上 67.8% 对 74.1%）。这些数字支撑得起的架构是带升级机制的级联，不是替换。
- 在信任之前要测的是校准，不是速度。
那句需要一个产品来收尾的话
Jev 发布时最扎人的是这一句：
企业里绝大多数生产环境的 AI 流量不是创意工作。它是路由、分诊、分类和闸门。把它喂给自回归引擎是范畴错误：你付一整段文章的钱，只为拿一个标签，还顺带继承了一段没人会读的文本的延迟。这有点像为了确认办公室的灯关没关，去委托一份四千字的备忘录。
那是一个诊断。它描述了一种大多数企业都有、看不见、并且默默接受了的成本结构。它缺的是治疗方案。
Jev 就是治疗方案——你给它一个 state 和一组带类型的 questions，它返回带类型的答案：在你给定的选项上的概率分布，中间什么都不生成。但模型本身不是重点。重点是：当决策层不再待在语言模型内部，你系统的形状会变成什么样。
这个形状和大多数团队已经建起来的东西差别够大，值得认真走一遍。
我们实际建成的架构
今天企业里几乎每一个生产级智能体，都是一个模型在干四份活：
- 理解状态。
- 决定下一步。
- 执行——通常是把工具调用作为文本吐出来。
- 叙述结果。
第 2 步和第 4 步共用同一个引擎，问题就出在这里。在 ReAct 式的循环里，分支就是文章。智能体”想”：我应该先查一下这个客户的订单，然后吐出 get_order(...)。终止条件也是文章——某种”我已完成任务”的变体，你的 harness 用正则去搜它，然后祈祷能解析成功。
所以，想想大多数企业智能体实际上是什么：控制流是用自然语言写的，由一个采样过程来解释。
这是个存分支逻辑的奇怪地方。而且它的贵法很具体。输出 token 是贵的那种。在一个决策形状的步骤里，你付这些输出 token 换来一个标签，还继承了那一段永远不会展示给任何人的文字的延迟。
现在数一下一次客服智能体运行里的决策：
- 这该进哪个队列？
- 这是退款还是换货？
- 这位客户在那个金额上有权限吗？
- 这个是不是已经在别处解决了？
- 这条回复够不够好，能直接发？
五个分支。几乎没有一处是文章。今天你为每一个都生成一两句话——而那句话恰恰是不可靠的部分，因为三周前改过的一个 prompt，可能已经悄悄改变了这个分支的走向。
Jev 做了什么，一段话讲完
你发一个 state——文本、JSON、一份文档——和一组问题。问题有三种原语：choice（从最多 255 个选项里挑一个，返回 choice 加 probabilities 和 confidence）、score（把一个 state 放到 2–10 级的有序评分表上，返回 score、legend 和分布）、noul（一个 yes/no 陈述为真的概率，返回单一数字）。同一个 state 上的所有问题是并行求值的，所以问五个和问一个的差别很小。什么都不生成：所有可能的答案都是你事先枚举好的——这正是输出天然满足 schema 的原因。
厂商报告的经济性：端到端 70–500 毫秒，输入每百万 token 0.042 美元、输出免费，工作负载跑分标题数字是快 193.6 倍、便宜 444.6 倍。最后一对数字请当作天花板来读——一个什么都不输出的模型，在延迟基准上天然就快。真正站得住的只有定价模型，因为它来自架构本身，而不是来自某次跑分。
这就是调用一个函数和委托一份备忘录的区别。
拆分：两个层面，中间一层控制
一旦决策有了自己的引擎，智能体就不再是一个循环，而是三层：
┌───────────────────────────────────────┐
│ CONTROL LAYER │
│ (code) │
│ thresholds · escalation · retries │
│ audit log · deterministic backstops │
└──────┬─────────────────────────┬──────┘
│ │
┌──────────────────────▼──────┐ ┌──────────────▼──────────────────┐
│ DECISION PLANE │ │ GENERATION PLANE │
│ (Jev) │ │ (LLM) │
│─────────────────────────────│ │─────────────────────────────────│
│ route triage │ │ write synthesise │
│ classify score │ │ explain reason │
│ gate verify │ │ code plan │
│─────────────────────────────│ │─────────────────────────────────│
│ typed · calibrated │ │ free-form · unconstrained │
│ 70–500ms · ~free │ │ seconds · expensive │
│ no rationale │ │ rationale included │
└─────────────────────────────┘ └─────────────────────────────────┘这张图里有两件事值得注意。
决策层承担了大多数调用，生成层承担了大多数 token。 这是两张不同的账单。把它们分开，你才能针对各自真正的约束去优化——前者是延迟，后者是每个 token 的质量。
架构现在活在控制层里，不在模型里。 这就把可靠性鸿沟里那句话拉回来了：智能体不是”LLM 加工具”，而是一个系统，LLM 只是其中一个组件。Jev 让这句话从愿景变成字面事实——因为它把分支决策从模型里逼了出来，逼进你能看见的代码里。
六件会变的事
1. 控制流搬回代码
分支变成一个你读取并据以行动的类型化值，而不是一句你祈祷它稳定的句子。
以前，路由策略住在 system prompt 里：“把工单归类为：账单、技术、账户三者之一。” 没人能评审它，没人能 diff 它，而且任何一次不相干的 prompt 改动都可能扰动它。
现在，选项集和判据是事先声明的，住在版本控制里、紧挨着对它们做分支的代码。你可以给分支写单元测试。你可以 diff 一次策略变更，看清楚究竟动了什么。
那个令人不适的推论恰恰是有用的：你的路由规则成了可评审的产物，也就意味着它成了某个人要负责评审的工作。 那些一直靠改 prompt 悄悄调整客服路由的团队，得开始把它当成一次带评审和审批的策略变更。这是一次治理上的改进，而头一个月它会感觉像摩擦。
2. 行动前检查终于有了一个数值输入
问任何一个做过护栏的人它是怎么工作的，你会得到两种答案之一。要么是确定性的——正则、白名单、schema 校验；要么是 system prompt 里一句客气的叮嘱，请模型务必小心——那不是控制，那是许愿。
一个经过校准的打分器给了你第三种选择。一个被记录下来的例子：一条含义模糊的 rm -rf，以 0.56 的概率被评为不可逆，而模型对这个判断本身只有 0.33 的把握。一个可以设阈值的数字，而且这个数字告诉你模型自己也不确定——这恰恰是你希望出现在”转人工”路径上的信号。
但要注意那个二阶风险，因为它很容易被忽略。一个读取攻击者可控文本的闸门，是一个新的攻击面。 state 里的对抗性内容可以改变答案。所以决策层是增加了一层概率性检查，而不是取代确定性检查。如果你对一次破坏性工具调用的唯一防线，是一个正在阅读攻击者所写文档的模型，那你只是把问题挪了个地方，并没有解决它。白名单还得留着。
3. 可靠性的数学换了形状
复利问题是真的，而且不讲情面：每步 95% 可靠性的智能体，在 20 步任务上的成功率是 36%。直觉会让人把 Jev 读成这个问题的解药。它不是，而诚实的版本更有意思。
Jev 比它要对标定价的那些前沿模型更不准——在厂商自己的基准上，在每一个任务上都是。所以这个改进的形状不是”每一步现在都 99% 了”。
而是系统现在知道自己不知道了。一个 95% 准确、但报告 0.4 置信度的步骤，是一个你能升级处理的步骤。一个 95% 准确、什么也不报告的步骤，逼你像信任那个报告 0.98 的步骤一样去信任它。校准把一个不可见的失败变成一条可见的分支，而可见的分支才是你能绕开的分支。
两个诚实的提醒。校准是聚合意义上的：0.9 不意味着这一个答案是对的，它意味着你在 0.9 上给出的那些答案大约有 90% 是对的。而且它是你必须用自己的数据去验证的性质——一个你没测过的置信度分数，只是装饰。
4. 成本塌了，于是扇出成了更便宜的那个直觉
按输入每百万 token 0.042 美元、输出免费算，一张 300 token 的客服工单大约 0.0000126 美元——大约每 10 万张工单 1.26 美元。在这个价位上，过去两年塑造你设计的那套算术反过来了。
旧直觉：把所有东西塞进一个 prompt，因为每一次额外的模型调用都是又一次往返、又一堆 token。于是有了巨大的分类器 prompt、“在一次回复里做完这五件事”的指令，以及你从文章里解析出来的脆弱 JSON。
新直觉：对同一个 state 一次问十三个窄问题。TypeSafe 测过一个 13 问的批处理，比十三次串行调用便宜 12.2 倍、快 10 倍；而且因为问题是对着同一次 state 读取并行跑的，多问几个延迟几乎不动。
这不只是更便宜。十三个各自带判据的问题，是十三个可测试的单元；而一个干五件事的 prompt，是一坨无法测试的东西。便宜的扇出是更好的工程，不只是更好的经济账。
5. 决策落到了交互阈值以下
70–500 毫秒，多数接近 100 毫秒，而前沿模型是秒级。300 毫秒附近有一条真实的线：低于它，一个决策可以内联在关键路径上而没人察觉；高于一秒，你就得绕着它设计——藏在转圈后面，或者干脆挪出这次请求。
今天大多数企业护栏之所以被抽样或者被推迟，正是因为它们慢到没法在每次调用上跑。于是你最终说出那句没人愿意承认的话：我们大概只检查 5% 的工具调用。 在决策层的延迟下，你可以全部检查。内联，是”控制”和”抽样”之间的区别。
6. 治理在同一个动作里既变好也变差
**变好的部分：**决策策略成了一等产物。选项和判据事先声明，评审者读的是评分表，而不是从 system prompt 里推断意图。它有版本、能 diff，也不会因为有人顺手整理了 prompt 就变化。
变差的部分：没有逐条决策的理据，因为本来就没有推理。而且 schema 合法不等于正确——模型会返回一个格式漂亮的标签，然后路由到错误的队列。“零幻觉”这个说法保证的是类型，不是真相。一个自信错误的闸门比没有闸门更糟，因为它静默地失败，而且规模化地失败。
对涉及监管、审计或用户信任的决策，缺少推理链本身就足以否决。至于一次路由跳转或者队列选择，本来也没人会去读那段解释。
准确率问题，直说
这一节决定你到底该不该在意，所以值得说得不客气。
在厂商自家看板上——711 个案例、四个任务，参考答案是两个前沿模型判断的平均值而非标准答案——Jev 总分 67.8%，最好的对比模型 74.1%。发票处理：61.8% 对 79.1%。客服：76.0% 对 78.3%。差距在每个任务上都一致，而且这个看板是厂商自己公开的。
独立测试在一项埋了缺陷的十二段文本分类任务上：Jev 抓出了 7 个中的 6 个；前沿模型全部抓出——代价大约是 25 倍的延迟和成本的一小部分，但不是打平，而且在最要紧的那件事上没打平，也就是对缺陷的召回率。
所以：天真地替换，你会输。 这个赛道里所有厂商的图表都是延迟和成本图表。如果你在准确率才是硬约束的地方，把 LLM 换成决策模型，你会交付一个更差、更快、更便宜的系统，财务部门会高兴大约一个季度。
这就是为什么这些数字支撑起来的架构不是替换，而是级联：
state ──▶ ┌──────────────┐ p ≥ threshold ┌─────────────────┐
│ DECISION │─────────────────▶│ act │
│ PLANE (Jev) │ └─────────────────┘
└──────┬───────┘
│ p < threshold
▼
┌──────────────┐ ┌──────────────────────────┐
│ ESCALATE │───────▶│ GENERATION PLANE (LLM) │
│ │ │ or human reviewer │
└──────────────┘ └──────────────────────────┘
│
▼
log the probability vectorJev 先用最低的成本对所有东西做第一道决策。低于阈值的，往上升一级。概率向量随每一次决策被记录下来。
于是你 70–80% 的量跑在决策层的经济性上，剩下的保留前沿判断力——而你之所以能这么做，是因为那个便宜的模型给的是校准过的置信度，而不是看起来很合理的文章。最后半句才是全部诀窍。一个说不出自己有多确定的便宜模型，没法参与级联：你没有任何信号可以用来路由。
它适合哪里，不适合哪里
| 用例 | 决策形状 | 答错的代价 | 契合度 |
|---|---|---|---|
| 客服工单分诊与路由 | choice + score | 小 | 强 |
| 工具调用与不可逆操作闸门 | noul | 大——设阈值，并配确定性兜底 | 强 |
| 智能体循环内的模型路由 | choice | 小 | 强 |
| 对 LLM 输出打分与校验 | score | 中 | 强 |
| 单据、理赔、发票处理 | choice + 抽取校验 | 大——升级机制是必须的 | 有条件 |
| 合规打标与 PII 分类 | noul + choice | 大——需要审计设计 | 有条件 |
| 规划、综合、写代码、新颖推理 | — | — | 否 |
| 任何需要可审计理据的决策 | — | — | 否 |
这张表里的规律不在于你在哪个行业。它在于答错的代价，以及有没有人会来问一句为什么。
一个参考形状
拿供应商发票录入来说——就是最初那场演示问的问题，但这次当成生产系统来跑，而不是演示。
读取。 格式允许的地方就用确定性解析，剩下的脏活交给生成层。抽取是写作类工作；它确实是 LLM 该干的事。
决策。 一次调用，几个问题，对着同一个 state 求值：
POST /v1/systemone
{
"model": "jev-latest",
"state": "<invoice text, PO reference, vendor history, prior payments>",
"questions": {
"routing": { "type": "choice", "options": ["straight_through", "review", "reject"],
"criteria": "Straight through only when the PO matches exactly..." },
"p_fraud": { "type": "noul", "instructions": "This invoice is fraudulent." },
"p_duplicate":{ "type": "noul", "instructions": "This invoice duplicates a prior payment." },
"po_match": { "type": "score", "levels": 5,
"criteria": "How well the line items match the purchase order." }
}
}在代码里分支，依据数字而不是句子：
const { routing, p_fraud, p_duplicate, po_match } = await jev(state, questions);
// 下面的阈值只是示例。信任任何一个之前，先用你自己的数据测过。
if (p_fraud.noul > 0.9 || p_duplicate.noul > 0.9) return reject();
if (routing.confidence < 0.7 || po_match.score < 3 || po_match.confidence < 0.6)
return escalate({ reason: "low confidence", routing, po_match });
// 给复核人的摘要是写作类工作——交给生成层。
if (needsReviewerNote) await llm.summarise(state, routing);
return straightThrough(routing);把概率向量随决策一起记下来。 那份日志现在就是你的审计痕迹，而且它比你从来没读过的那些文章更好：它记录了系统当时相信什么、有多确信、越过了哪条阈值。当复核人推翻一个决策时，你手上有产生它的那个确切数字——这同时也是你日后调阈值需要的数据。
注意控制流变成了什么。是 if 语句。它可测试、可评审，而且不会因为有人改了一句 prompt 就变。
周一该做什么
1. 测出那个比例。 给过去三十天的 LLM 调用做埋点，把每一次标成”决策形状”或”生成形状”。几乎没人有这个数字，而它就是全部的立项理由。在大多数企业技术栈里，它落在 60% 到 80% 之间。这是测出来的，不是断言的。
2. 测校准，不是测准确率。 从生产 trace 里建一个有标注的集合，按模型报告的置信度分桶，检查每个桶里的实际命中率。如果 0.9 那个桶只有 60% 的时候是对的，那你手上是一个打分器，不是校准过的模型——而你在它上面设的每一个阈值，都只是一个披着数字外衣的猜测。这一个测试就决定了级联能不能成立。
3. 从那个象限开始。 答错便宜、答慢昂贵的那个象限。然后再挣得把这件事往更要紧的决策推近的权利。
4. 把阈值写进代码并做版本化。 阈值就是策略。没有版本化的策略不是策略。
5. 留住 LLM。 这是一次拆分，不是替换。当决策流量不再和它抢预算，生成层会变得更有用而不是更没用——因为你终于付得起给它该有的上下文和该有的认真，而写作本来就配得上这些。
要点
好引用的说法是 200 倍。站得住的那个说法更窄，也有用得多：决策层从来不是语言模型该干的活，而企业一直在为一句分支语句支付生成的价格。
一旦接受这个拆分，架构就会围着它重排。能确定性的地方就确定性。必须生成性的地方就生成性。中间放一个校准过的概率和一条明确的阈值——这比把边界放在 system prompt 里的一句句子里，要好得多。
办公室的灯关没关，不需要一份备忘录。它需要一个开关、一条关于谁可以碰它的策略，和一份谁碰过的日志。这三样东西，第一次都是你能买到的了。
有意思的说法不是某个模型变快了。而是你架构里的某一层，原来一直待错了地方。
常见问题
为什么 Jev 会改变智能体的架构？
因为企业里绝大多数智能体流量是决策形状的——路由、分诊、分类、闸门——而今天每一个这样的决策，都是一个自回归模型生成文本产生的。这让你的控制流变成了由采样过程解释的自然语言。当决策有了自己的引擎，它们就变成你代码里据以分支的类型化值，控制流因此回到软件里，在那里它可以被测试、被版本化、被评审。
智能体架构里的”决策层”是什么？
它是智能体里负责结构化选择而非文章的那一层：进哪个队列、用哪个模型、调哪个工具、这件事安不安全、这个结果够不够好。在 Jev 的架构里，它和生成层（负责写、推理、综合）分开，两者由一层用代码写的控制层连接，控制层持有阈值、升级规则和审计日志。决策层承担大多数调用，生成层承担大多数 token。
我可以用 Jev 替换智能体里的 LLM 吗？
不可以，而且这么做只会让系统更差。在厂商自家基准上，Jev 是 67.8%，最好的同类 LLM 是 74.1%；发票处理上是 61.8% 对 79.1%；独立测试里它抓出了 7 个埋入缺陷中的 6 个，而前沿模型全部抓出。这些数字支撑的架构是级联：决策模型处理所有它有把握的部分，低置信度的案例升级给 LLM 或人工。
置信度阈值应该怎么设？
设在代码里，值放进版本控制，而且只有在用你自己的标注数据测过校准之后才设。按报告的置信度把预测分桶，检查每个桶里的实际命中率。如果 0.9 那个桶只有 60% 的时候是对的，那任何阈值都还没有意义。因为校准是聚合意义上的，0.9 的置信度意味着在 0.9 上给出的答案大约 90% 是对的——而不是某一个具体答案是对的。
把决策模型当护栏用有什么风险？
三个。state 里的对抗性内容会改变答案，所以一个读取攻击者可控文本的概率性闸门是新攻击面——确定性的白名单要留着。schema 合法不等于正确：模型可以返回一个格式漂亮的标签，却路由到错误的目的地，而”零幻觉”说的是输出类型，不是真相。另外它没有推理链，所以闸门出错时是静默失败。当它规模化发生时，自信的错误比没有闸门更糟。
哪些企业用例最适合 Jev？
从答错便宜、答慢昂贵的地方开始：客服工单分诊与路由、智能体循环内的模型路由、对 LLM 输出打分与校验，以及由确定性检查兜底的工具调用护栏。单据和发票处理属于有条件契合，升级机制必须当作强制项。长程规划、综合、代码生成，以及任何需要可审计理据的决策，完全不适合。
关于作者
Vinci Rufus 是一位技术专家与作者，专注于构建可靠的 AI 系统与智能体架构。他写作的主题是生产级 AI 落地的实际挑战，以及把演示级智能体和生产就绪系统区分开的那些架构模式。他的作品涵盖那个拒绝写字的模型、AI 智能体的可靠性鸿沟，以及智能体工作流设计。