企业官网建设流程全解析

CLM vs Jev：开源决策层正在改写 Agent 的底层逻辑

如果你正在做 Agent，大概率见过这种浪费：一个分类、路由、权限判断，也要调大模型生成一堆 token，然后应用层立刻把它们丢掉。慢、贵，还容易格式跑偏。

Jev 和 CLM 都在解决这个问题，但路线完全不同。一个更像托管决策 API，一个更像你能自己掌控的决策层。下面把架构、性能、成本和适用场景拆开讲。

CLM 到底是什么

CLM 全称 Contrastive Language Models，对比语言模型。团队把它称为 System One 模型，借鉴的是认知科学里快速、直觉式决策的概念。目前发布的是 CLM-8B，设计非常克制：

• 用冻结的 Qwen3-8B 作为共享编码器。
• 上面挂两个轻量投影头，每个大约 2000 万参数。一个编码状态，一个编码动作。
• 训练用双向 InfoNCE 损失，把匹配的状态动作对拉近，把不匹配的推远。
• 训练分三段：6000 万 Nemotron 问答对，3000 万合成难负样本，100 万智能体轨迹。

推理时更直接。模型先编码当前状态，再拿这个嵌入去和候选动作嵌入比相似度，选最近的那个。没有 token 生成，没有自回归解码，就是一次相似度计算。

缓存才是 CLM 的经济学杀手锏

状态编码器和动作编码器分开，带来一个 Jev 那种单体架构不容易复制的优势：动作嵌入缓存。

企业 Agent 的动作集通常很稳定。IT 支持 Agent 可能就 50 个动作：重置密码、开通权限、建工单、升级到安全团队。客服 Agent 可能就 30 个路由选项。这些动作不会每分钟变一次。

CLM 可以先把这些动作编码一次，缓存起来，后面每个请求只编码变化的状态，再和缓存动作算相似度。

实际延迟差距很明显。单张 RTX 4090，重复状态加 3 个或 50 个动作时，p50 从大约 1.7 到 2.0 毫秒降到 0.6 到 0.7 毫秒。如果每个状态都是全新的，优势会缩小，但动作缓存仍然省掉大量重复计算。

这不是小优化，是架构级的复利。

Jev 仍然强的地方

Jev 没停步，某些场景依然有优势。

• Jev 用 RLCD 训练，显式优化概率校准。它说 70% 紧急，那大致 70% 的相似预测应该是对的。风险评分、审核分流、需要人工介入阈值的工作流，很吃这一点。
• 工具调用准确率，Jev 仍领先。BFCL v4 上，Jev 99.2%，CLM 95.2%。WikiRacing 上，Jev 完成 30/30，CLM 完成 26/30。
• 差距不算巨大，但生产系统里错一次工具调用有后果时，几个百分点很重要。
• 价格很激进。每百万输入 token 0.042 美元，输出免费，在合适分类任务上大约是前沿 LLM 的 1/445。
• TypeSafe 把 Jev 定位成即插即用决策层。LangChain 的 AutoModeMiddleware 集成，让已经在那个生态里的团队很容易上手。

速度对比要放回场景里看

“比 Jev 快 9 倍”这个标题数字，得拆开看。

T-Rex 游戏测试里，CLM-8B 决策 16.5 毫秒，Jev 149.8 毫秒。候选动作大约 1000 个时，CLM 快 13 倍。这些是受控测试里的真实数字，但对应的是动作缓存收益最大的负载。

9 倍不是通用倍数。它是动作集大且稳定、大量请求共享缓存时的最佳情况。动作空间动态变化，或者每次状态都新，速度优势会收窄。

VentureBeat 的报道也说得比较准：零样本测试里 CLM-8B 快至 9 倍，两项游戏任务成功率和 Jev 打平，但工具调用准确率让步，WikiRacing 完成任务更少。

编码验证器这个用例被低估了

CLM 最有价值的演示之一，不在主决策循环，而在二级验证。

流程是这样：强生成模型比如 Opus 5 先产出多个候选代码方案，微调后的 CLM-8B 来评估并挑最好的。CLM 不写代码，它只给已有方案排序。

结果很能说明问题：

• DeepSWE 上，Opus 5 单次尝试成功率从 73.7% 提到 81.6%。
• Terminal-Bench 2.1 上，从 84.0% 提到 87.6%。
• CLM-8B 在这两个基准上作为验证器达到新的 SOTA，同一角色比 Jev 快 4 到 6 倍。

这个模式，用强 LLM 生成候选，用快速对比模型做选择，天然适合 CLM。动作集就是候选方案，状态就是任务描述，决策就是排序。

目标用户和市场位置

CLM 和 Jev 的用户有重叠，但定位不同。

CLM 是 Apache 2.0 开源，可以自托管。冻结骨干加轻量投影头，微调便宜，只训 2000 万参数的投影头，不用动 80 亿的全模型。单张 GPU 就能适配专有领域，数据不用出内网。

这对受监管行业很重要。金融公司不能把客户交互数据发到第三方 API 做每次路由。医疗机构也不能随便把患者查询送到外部分类服务。CLM 给这类团队一条自托管 System One 的路径。

Jev 的目标市场不一样。它 API 优先，LangChain 集成顺滑，适合不想管基础设施、只想用决策智能的团队。每百万 token 0.042 美元，在高吞吐分类场景下，当自托管 GPU 成本高于 API 账单时，吸引力很强。

System One 这个品类还在形成。Jev 的发布证明需求是真的。Vercel 报告说，Jev 接入 AI Gateway 后 24 小时内，接近 13% 的付费团队采用，是 GPT-5.6 首日采用率的两倍，也是 Claude Fable 5.1 的六倍多。这不是小众好奇，是团队真的想要不用全生成模型调用的决策层。

两者共同解决的痛点

Agent 循环把大量算力浪费在不需要文本生成的决策上。

一个支持工单是不是紧急，该哪个部门处理，某个工具调用有没有风险，这些事调用前沿 LLM 属于架构过度。模型生成 token，应用立刻丢弃。慢、贵，还容易偏离输出 schema。

System One 模型就是来消除这种浪费的。CLM 和 Jev 都返回带概率的类型化结构化输出，都在毫秒级完成，成本都比生成方案低几个数量级。

区别在解法。Jev 用专用架构，RLCD 端到端训练。CLM 用冻结骨干加对比投影头。都能用，没有谁在所有场景都绝对更优。

总结

CLM-8B 是对比 LM 团队的第一版，不是终局。有消息说 2026 年 10 月会来一个更大的 CLM-35B 多模态版本。

如果 8B 已经在几个基准上追平 Jev，而且在缓存友好场景明显更快，35B 有可能缩小准确率差距，同时保留架构优势。

更深层的趋势是 Agent 系统开始分层。不是一个模型包办所有事，而是生成模型做推理和内容，System One 模型做快速决策，确定性代码做执行和授权。Jev 和 CLM 在抢中间层，这种竞争会让速度和成本继续快速改进。

今天做 Agent，实际要问的不是抽象意义上谁更好，而是：

• 你的决策负载更适合缓存动作嵌入，还是校准概率输出？
• 你需要自托管，还是 API 简单更重要？
• 你的动作集是否稳定到能吃下 CLM 的缓存红利？

不同团队答案不同。好消息是，现在两个选项都在，一个闭源，一个开源。