Agent架构新思路：把决策能力从大模型里拆出来

文章目录

- [1. 为什么我们急需一个"不会说话"的 AI](#1. 为什么我们急需一个"不会说话"的 AI)
- [2. Jev 的核心思想：Decision，而不是 Generation](#2. Jev 的核心思想：Decision，而不是 Generation)
- - [2.1 Choice：选择题](#2.1 Choice：选择题)
  - [2.2 Score：打分题](#2.2 Score：打分题)
  - [2.3 Noul：判断题](#2.3 Noul：判断题)
- [3. 真正重要的不是"快"，是 Calibrated Confidence](#3. 真正重要的不是"快"，是 Calibrated Confidence)
- [4. Jev 最适合放在哪？答：Agent Loop 的决策点](#4. Jev 最适合放在哪？答：Agent Loop 的决策点)
- [5. 第一个实战场景：Tool Selection](#5. 第一个实战场景：Tool Selection)
- [6. 第二个实战场景：Model Routing](#6. 第二个实战场景：Model Routing)
- [7. 第三个方向：Guardrail](#7. 第三个方向：Guardrail)
- [8. Jev-as-a-Judge：一个很值得关注的新方向](#8. Jev-as-a-Judge：一个很值得关注的新方向)
- [9. 生态为啥发展这么快？](#9. 生态为啥发展这么快？)
- [10. 这让我想到 Harness](#10. 这让我想到 Harness)
- [11. Jev 也不是万能的](#11. Jev 也不是万能的)
- [12. 我更想说的是：一种新的 AI 分工方式](#12. 我更想说的是：一种新的 AI 分工方式)
- [13. 长期来看，Agent 会变成"异构计算系统"](#13. 长期来看，Agent 会变成"异构计算系统")
- 结语

P.S. 无意间发现了一个巨牛的人工智能教程，非常通俗易懂，对AI感兴趣的朋友强烈推荐去看看，传送门https://blog.csdn.net/H1727548

先说个背景：我是个写代码的。这几年最大的感受就是，AI 圈出新东西的速度，比我换头像的频率还快。

好吧说正经的。最近 TypeSafe AI 发了个新模型，叫 Jev，2026 年 9 月 15 号的事。我第一反应是：又来一个换皮 LLM？结果仔细一看，好家伙------它根本不生成文本。

一个字都不生成。

它只干一件事：做决策。你给它一个状态，告诉它要判断什么，它直接甩你一个结构化结果，还带概率。

官方管这叫 System One Model。

这名字起得挺妙。翻译成人话就是：我这模型不走脑子，走直觉。但你要真信了你就输了------因为它连直觉都给你标好了概率，比你的直觉可靠多了。

1. 为什么我们急需一个"不会说话"的 AI

先说说现在这套玩法有多离谱。

假设你做个客服系统，用户发来这么一句：

复制代码

I've been trying to connect my Stripe account for 3 days and it keeps failing. I'm losing sales. Please help ASAP.

你想判断三件事：急不急？该转给谁？用户气成什么样了？

现在的主流做法是：把这句话丢给 LLM，让它......写作文。

复制代码

用户消息
  ↓
LLM
  ↓
生成：
{
  "urgent": true,
  "department": "billing",
  "emotion": "frustrated"
}
  ↓
解析 JSON
  ↓
验证 Schema
  ↓
程序继续执行

你品品这个过程。你只是想要三个字段，结果你启动了一个以"预测下一个词"为生的模型，让它吭哧吭哧吐几百个 token，最后你还得写个 JSON.parse 把它从废话里捞出来。

这就像你去食堂打饭，明明只要一个番茄炒蛋，师傅非要先给你表演一段颠勺，再讲十分钟他祖传的炒菜心法，最后才往你盘子里放了两块西红柿。

而你真正需要的，其实就这三行：

复制代码

urgent = true
department = billing
emotion = frustrated

为了这三个变量，你养了一个会写诗的模型。

本质上，这就是在拿一个 Text Generator 模拟 Function。用大炮打蚊子，蚊子还嫌你吵。

Jev 想改的就是这一层。它的官方描述特别硬核：

复制代码

Unstructured state in, typed probabilistic decisions out.

翻译：你往里倒一坨乱七八糟的状态，它往外吐一个带类型、带概率的决策。

没有长篇大论，没有 JSON 解析，更没有"让我为您详细解释一下"。

官方还给起了个称呼：frontier-intelligence function call。听着就比"会聊天的聊天机器人"高级不少。

2. Jev 的核心思想：Decision，而不是 Generation

传统 LLM 的工作方式大家都熟：

复制代码

Context → Token → Token → Token → Token → Answer

一个 token 一个 token 往外挤，前一个没出来，后一个就得排队。像极了早高峰的地铁：明明你只是要出站，前面的人不走，你也动不了。

Jev 不一样。它拿到 State 之后，几个问题一起评估：

复制代码

State ──┬── urgent?
        ├── department?
        ├── risk?
        └── completed?

一起判断，直接返回结构化结果。目前它主要提供三种"决策原语"，听着玄乎，其实特别直白。

2.1 Choice：选择题

从几个明确选项里挑一个。比如：这活儿到底该谁干？

复制代码

Which team should handle this request?
- Billing
- Technical Support
- Sales
- Security

它直接返回：

复制代码

Technical Support   0.91
Billing             0.06
Sales               0.02
Security            0.01

看到没，连"我拿不准"都给你量化了。你要是问传统 LLM，它能给你分析一小时每个部门的优劣势，最后告诉你"建议结合实际情况综合考虑"------说了等于没说。

2.2 Score：打分题

按你定好的评分标准打分。比如风险等级：

复制代码

Risk Level:
0 = Safe
1 = Low
2 = Medium
3 = High

它返回对应评分和概率分布。相当于你把评分标准丢给它，它帮你当评委，还不收评审费。

2.3 Noul：判断题

这个最有意思。名字我一开始还以为是拼错了，后来发现人家就是干这个的：某个判断成立的概率是多少？

比如：这个操作危不危险？

它不给你写"是的，我认为这个操作可能存在一定的危险性，建议谨慎处理"。

它直接给你：

复制代码

risk_probability = 0.87

然后你的代码立刻就能用：

python 复制代码

if risk_probability &gt; 0.8:
    require_confirmation()

你品品这个差别。一个是写作文，一个是给变量赋值。作为程序员，我当场就想给它磕一个------这才是给机器用的接口。

3. 真正重要的不是"快"，是 Calibrated Confidence

很多人一上来先关注速度。确实，官方公布的数据里，在合适的任务上，Jev 比传统 LLM 快几十倍到接近两百倍，典型推理延迟大概 70--500ms。

价格更是离谱：$0.042 / 1M input tokens，output 不收费。

对，不收费。因为根本没有 output 生成。你雇了个只回答"是/否/可能"的员工，还不用给他发工资------老板做梦都能笑醒。

但我觉得真正值得琢磨的不是快，是另一个能力：Calibrated Confidence，校准过的置信度。

现在的 LLM 经常这样：

复制代码

I am 95% confident that this request is malicious.

95%？你问它这 95% 哪来的？它说：就是 95%，我很确定。

这就像你问程序员"这功能什么时候能上线"，他说"快了快了，95% 明天能好"。你信吗？我反正是见过太多"快了"最后变成"下个季度"。

问题在于：模型说 95% 的时候，长期来看它真的有 95% 的概率对吗？大多数情况下，那只是它生成的一段文本，不是真校准过的统计量。

TypeSafe 为此用了一种新训练方法：RLCD，Reinforcement Learning for Calibrated Decisions。翻译：强化学习，让它学会知道自己有多确定。

这件事对 Agent 太重要了。因为成熟的自动化系统不该只会喊 YES/NO，而是应该这样：

复制代码

High Confidence    → 自动执行
Medium Confidence  → 再验证一下
Low Confidence     → 交给更强的模型 / 人

说白了，Confidence 本身成了程序控制流的一部分。

以前我们说"置信度"，觉得是个学术概念。现在它直接变成了 if 语句。我愿称之为：把玄学变成了工程。

4. Jev 最适合放在哪？答：Agent Loop 的决策点

答案其实特别清楚------Agent 循环里那些"要做决策"的地方。

现在一个典型 Agent Loop 长这样：

复制代码

LLM → 选 Tool → 执行 Tool → LLM → 看结果 → LLM → 判断干完没 → LLM → 决定下一步

你仔细看，这里面真正需要"生成语言"的地方其实没几个。大部分步骤本质上是：

复制代码

选哪个工具？继续还是重试？停下来吗？安全吗？做完了吗？派哪个 Agent？

全是 Decision Problem。

所以可以改成：

复制代码

Agent State
   ├── Jev（决策）
   │     ├── Route
   │     ├── Risk Check
   │     ├── Select Tool
   │     └── Completed?
   └── LLM（生成 / 推理）

LangChain 在 Jev 发布两天后就写了篇文章，观点也是这个：Agent Loop 里大量步骤是 decision，不是 generation。然后直接给了 TypeSafeClassifier 集成，让 Jev 能当决策组件插进工作流。

这事有意思的地方在于：未来的 Agent 架构里，LLM 不一定是所有控制流的中心了。

想想还挺唏嘘的。以前 LLM 是绝对主角，现在有人开始说：哥们儿，你往后稍稍，有些活真不需要你亲自来。

5. 第一个实战场景：Tool Selection

这是我觉得 Jev 最好理解、也最现实的落地方向。因为现在的 Agent 普遍面临一个问题：

工具越来越多。

早期一个 Agent 可能就四五个工具：Search、Calculator、Database、Email。现在呢？MCP、Skills、Plugins、Browser、SaaS API、企业工具......一个 Agent 几十上百个工具已经不稀奇。

传统做法是：把所有工具 schema 全塞进 prompt，让 LLM 自己挑。

复制代码

Prompt
  Tool A schema
  Tool B schema
  Tool C schema
  ...
  Tool Z schema
  ↓
LLM
  ↓
选择 Tool + 生成 arguments

这就有两个问题。

第一，工具越多，上下文越大。一百个工具 schema 塞进去，光说明书就比用户的问题长好几倍。模型读完之后可能选择困难症发作，直接开始胡言乱语。

第二，选工具和生成参数被绑在一起了。这其实是两件事：选工具是分类问题，生成参数才是生成问题。

完全可以拆开：

复制代码

100 Tools → Jev → 选中 Tool #37 → 只把 #37 的 Schema 给 LLM → LLM 生成参数

也就是：

复制代码

Jev 选。LLM 填参数。代码执行。

这就像点菜：Jev 负责"我们吃火锅"，LLM 负责"给我来份毛肚"，后厨负责上菜。各干各的，谁也不累着谁。

目前已经有人在 100 个 mock 工具的环境里测这个模式了。效果咋样我先不吹，反正方向我是看好的。

6. 第二个实战场景：Model Routing

这个场景我觉得更适合生产环境：模型路由。

现在的 AI 系统没必要每个问题都调最强最贵的模型。就像你没必要顿顿去五星级酒店吃饭，楼下包子铺也挺香。

流程可以是这样：

复制代码

用户请求 → Jev 判断任务难度
  ├── Simple   → Fast Model
  ├── Medium   → Balanced Model
  └── Complex  → Frontier Model

这做的其实是语义层面的路由。相比传统规则：

复制代码

if token_count &gt; 1000:

Jev 判断的是：这任务在语义上到底复不复杂？

未来 AI Gateway 大概会长这样：

复制代码

Request
  ↓
Decision Model
  ├── Cheap Model
  ├── Medium Model
  └── Frontier Model

社区里已经有人拿它给 Claude Code、Codex 这类 Coding Agent 做动态路由了。省钱省到姥姥家。

7. 第三个方向：Guardrail

Agent 越来越能操作真实世界之后，一个问题会越来越要命：

这个动作，到底能不能干？

比如 Coding Agent 准备执行：

复制代码

rm -rf ...

或者：

复制代码

DROP TABLE

又或者 Agent 准备发邮件、付款、改生产环境、删资源、提交代码。

这时候可以在前面加一个决策层：

复制代码

Agent proposed action → Jev → Risk Evaluation
  ├── Allow
  ├── Confirm
  └── Block

Vercel 在介绍 Jev 和 Agent Loop 结合时特意强调了一句：真正的工具执行和权限控制，还是得由应用代码来管。

也就是说，Jev 可以当风险评估师，但最终拍板权在 Harness 手里。

这个边界划得挺清醒。毕竟，让模型自己决定"我能不能删库"，就跟让猴子管理香蕉仓库一样，听着就不靠谱。

8. Jev-as-a-Judge：一个很值得关注的新方向

Jev 发布没几天，LangChain 又搞了个有意思的实验：让 Jev 当 Agent 的裁判。

现在 Agent 评测大致两条路线。

Code-based Eval：快、便宜、稳定，但只能判断"非常确定"的事。

LLM-as-a-Judge：能理解复杂语义，但贵、慢，而且评分不稳定------同一个答案，它心情好给 8 分，心情不好给 5 分。

Jev 恰好卡在两者中间：

复制代码

Code Eval（确定性）
    ▲
    │
   Jev
    │
    ▼
LLM-as-Judge（语义化）

LangChain 在 9 月 20 号放出一组初步实验，用 Jev 评价 Agent 输出，平均调用时间大概 0.44 秒，而且连续评分时方差比几个生成式 Judge 模型低不少。

当然，这只是规模有限的早期实验，不能直接说 Jev 全面碾压 LLM-as-a-Judge。

但它至少说明一件事：评测本身，可能就是决策模型的天菜任务。

毕竟，裁判最重要的是什么？不是文采，是稳定。你见过哪个裁判赛后写八百字小作文解释为什么判你犯规的？没有。都是一声哨响，完事。

9. 生态为啥发展这么快？

Jev 是 9 月 15 号才发布的，结果短短几天，周围就冒出一圈生态。

LangChain 集成有了，Vercel AI Gateway 接入了，社区里还冒出 Jev MCP、Coding Agent Router、Tool-call Guard、Agent Reviewer、Context Compaction、Claude Code/Codex Router、n8n Node、Home Assistant 集成......甚至还有个社区维护的 awesome-jev 项目，收录了一堆相关资料。

当然，这里面很多还是实验和 PoC，成熟度参差不齐，你不能把"项目数量"直接等同于"生产采用率"。但它至少说明：开发者们正在很积极地给 Decision Model 找位置。

而且你观察这些项目会发现一个规律：没人让 Jev 写文章、写代码、聊天、总结长文。

大家全在让它干这些：

复制代码

Route、Select、Score、Rank、Judge、Check、Gate、Filter

换句话说，Jev 目前真正找到产品契合度的方向，不是替代 LLM，而是钻进 LLM 周围的控制平面。

你看，人民群众的眼睛是雪亮的。该让 AI 摸鱼写周报的活，大家一个都没分给它------因为那活我们自己都懒得干。

10. 这让我想到 Harness

以前聊 Agent，大家注意力全在模型上：你用的什么模型？GPT 还是 Claude？

但最近一年越来越明显：决定一个 Agent 能力上限的，早就不只是模型了，是 Harness------运行它的那套框架。

一个成熟的 Agent Runtime 要管的东西多了：Context、Memory、Tools、MCP、Permissions、State、Retry、Observability、Evaluation、Execution。

从这个角度看，Jev 最准确的位置应该叫：Decision Plane（决策平面）。

未来的 Agent Harness 可以粗略拆成三层：

复制代码

┌───────────────────────────────┐
│         Agent Harness          │
│            State               │
│              │                 │
│     ┌────────▼────────┐        │
│     │  Decision Plane │        │
│     │      Jev        │        │
│     └────────┬────────┘        │
│   ┌──────────┴──────────┐      │
│   ▼                     ▼      │
│ Reasoning Plane   Execution    │
│     (LLM)          Plane       │
│                  (Tools / Code)│
└───────────────────────────────┘

Decision Plane 负责：该不该？选哪个？风险多大？继续还是停？路由到哪？

Reasoning Plane 负责：为什么？怎么干？生成什么？怎么规划？

Execution Plane 负责：干就完了。

用一句话概括：

复制代码

Jev decides. LLM reasons and generates. Harness executes and governs.

Jev 拍板，LLM 吹牛加干活，Harness 管钱管人管合规。

这团队结构我太熟了------我们公司就这样：拍板的领导、干活的员工，还有那个啥都管的人事部。

11. Jev 也不是万能的

任何一个新技术刚出来，都容易被过度解读。Jev 也一样。

先说它至少有的几个明显边界。

**它不是 LLM Replacement。**写文章、开放式问答、代码生成、复杂推理、长文本总结、自由对话------这些还是生成式模型的强项。你让 Jev 写情书试试？它只会告诉你"表白成功率：0.37"。

**Closed Decision Space 非常重要。**Jev 最擅长的是"从已知候选项里做判断"，核心问题是 Which one?，不是 Invent one。别指望它给你创造答案，它不是许愿池。

**Confidence 不能盲目信任。**哪怕模型做了校准，也不意味着 confidence > 0.8 就适合所有业务。落地时你还得用自己的生产数据过一遍：

复制代码

Offline Eval → Threshold Calibration → Shadow Traffic → Production

尤其在金融、安全、生产系统变更这些高风险场景，别把模型概率直接当业务政策用。模型说 0.87 很危险，那是它的判断；你要是没验证就信了，那你就很危险。

**现在仍然非常早期。**截至 2026 年 9 月 20 号，Jev 发布才五天左右。现在看到的大部分案例，本质上还是 Demo、PoC、Experiment、Early Integration。

所以现在最合理的态度，不是急着宣布"Decision Model 要替代 LLM"，而是观察一个问题：

哪些原本让 LLM 干的活，其实根本不需要生成能力？

这个问题，可能比 Jev 这个产品本身更重要。

12. 我更想说的是：一种新的 AI 分工方式

过去几年，AI 应用的架构特别容易变成：

复制代码

Everything → LLM

遇到什么问题，都去问 LLM。就像家里只有一把锤子，看什么都像钉子------虽然大部分时候那其实是螺丝。

Jev 代表的方向更像这样：

复制代码

Task
 ├── Decision   → Jev
 ├── Reasoning  → LLM
 └── Execution  → Code

不同类型的问题，交给不同类型的计算系统解决。

这其实特别符合传统软件工程的思路：数据库管存储，消息队列管异步，搜索引擎管检索，规则引擎管确定性策略，LLM 管开放式推理和生成，Decision Model 管"模糊但结构化"的判断。

而 Harness 负责把这一切组织起来。

说白了，就是别让一个模型什么都干。什么都干 = 什么都干不好，这话在职场成立，在 AI 架构里也成立。

13. 长期来看，Agent 会变成"异构计算系统"

现在我们天天讨论：哪个模型最强？GPT？Claude？Gemini？DeepSeek？

但未来更有价值的问题可能是：这个任务的哪一部分，该交给哪个模型？

于是未来一个 Agent 可能同时跑着一堆模型：

复制代码

Small Model      → 快速分类
Decision Model   → 路由 / 裁判
Reasoning Model  → 复杂规划
Code Model       → 写代码
Vision Model     → 看图
Embedding Model  → 检索

最终拼成一个 Agent Harness：

复制代码

Agent Harness
 ├── Decision Model
 ├── Reasoning Model
 └── Tools / Execution
        │
        ▼
      Action

所以从这个角度看，Jev 可能压根不是 LLM 的"竞争者"。

它更像是在提醒我们：

LLM 不应该成为 AI 系统里的 CPU。

或者说得更直白点：不是所有智能任务，都需要走一遍 Token Generation。

有些事，一个概率就够了。

结语

我最近越来越明显地感觉到一个趋势：

AI 工程正在从 Prompt Engineering 走向 Context Engineering，然后进入 Harness Engineering。

而 Harness Engineering 的一个重要变化就是：开始把"大模型"拆开来看。

生成是一种能力。推理是一种能力。检索是一种能力。记忆是一种能力。

决策，同样是一种能力。

Jev 真正有意思的地方，不是"终于出现了一个比 LLM 快的模型"，而是它提出了另一种可能：

我们过去可能让 LLM 做了太多它根本不需要做的事。

就像你让一个博士去拧螺丝，他不是不能拧，是贵，还容易想太多。

如果这条路线最终成立，未来 Agent 的核心架构可能会从 Everything → LLM 演进成：

复制代码

Decision   → Decision Model
Reasoning  → Reasoning Model
Generation → Generative Model
Execution  → Code &amp; Tools
Governance → Harness

到那时候，我们评价一个 AI 系统，可能不再问"你用的什么大模型"，而是问：

"你是怎么把这些不同类型的智能组织起来的？"

这或许才是 Jev 给 Agent Engineering 带来的最大启发。

反正我已经开始重新审视自己代码里那些"为了 AI 而 AI"的部分了。

......然后发现，我代码里那些 if else，好像比 LLM 还靠谱。

P.S. 无意间发现了一个巨牛的人工智能教程，非常通俗易懂，对AI感兴趣的朋友强烈推荐去看看，传送门https://blog.csdn.net/H1727548