云雀 · 轻技术笔记

2026年9月26日：Jev API 正在变成新的行业标准，Ollaya 抢先把决策模型「Ollama 化」了

AIAgentLLM大模型AIGC

一个周末过去，GitHub 上关于 Jev 的项目从「零散十几个 demo」变成了「围绕一个 API 标准的完整生态」。最关键的信号不是 browser-use/jev-ultrafast 这种执行器，而是 9 月 25 日上线、9 月 26 日冲上 HN 370 分（137 条评论）的 Ollaya —— 一个号称「Ollama for decision models」的开源运行时，drop-in 兼容 TypeSafe Jev 的 /v1/systemone 端点协议，本地 GPU 跑出 8-10ms 的端到端延迟。

如果你只看 GitHub Trending，会觉得 Jev 还是那个 Jev。但如果你去 HN 把过去 48 小时的 Jev 相关讨论串起来看，会看到一个完全不一样的剧本：

  • 协议层正在标准化：Ollaya 不是第一个兼容 TypeSafe API 的项目。在它之前已经有 gargpratyush/jev-router、jkudish/jev-mcp、ekzhang/openjev-sglang、LLM2Jev 至少四个。TypeSafe 还没把协议正式提交给任何标准组织，但开源生态已经在用脚投票
  • 决策模型的「Ollama 时刻」到了：Ollama 当年让 Llama/通义千问这种大模型变成「一行 ollama run 就能跑」。Ollaya 在做同样的事，只不过对象是决策模型。Ollaya 默认拉取的模型是 laya、decider、nli、gliclass、qwen3guard，没有一个是 TypeSafe 自己的 Jev——这本身就是一个非常有挑衅意味的信号
  • 延迟差距是数量级的：Ollaya 官方页面的 benchmark 说本地 RTX 4090 上一次五个问题的决策请求端到端 8-10ms，而 TypeSafe 托管的 Jev API 中位数是 236-276ms（包含网络）。30 倍的差距，单次价格还便宜一个数量级

这就是今天这篇文章要讲的事：Jev API 正在变成决策模型的事实标准——不是 TypeSafe 一家定义的，是开源生态抢着兼容、抢着优化、抢着本地化「逼」出来的。

一、Ollaya 不是普通 fork，它是把「Jev API」当成开放协议在做

先说 Ollaya 是什么。打开 ollaya.dev 主页，第一眼看到这个命令：

ollaya run decider --preset agent '{
  "request": "Fix the typo in README.md",
  "command": "git push --force origin main"
}'

返回的不是一个长答案，是结构化的四行决策表：

Question Answer Probability
action block 0.53
on_task no 0.75
risk 1.23 / 2 could lose local work 0.15
destructive yes 0.90

没有「让我想想」、「以下是分析」、「我建议」。每个问题一个答案，每个答案一个校准过的概率，单次 forward pass 完成，不生成任何自然语言 token。这就是「决策模型」和「对话模型」的本质区别——你问的是结构化问题，模型只返回结构化答案，没有 CoT、没有解释、没有礼貌寒暄。

Ollaya 在主页上直接把自己定位成「Ollama for open-source, Jev-style decision models」。注意这个表述：

  • Ollama：标杆对象，不是对话大模型，而是「让本地运行变得傻瓜化」的运行时范式
  • open-source：Ollaya 拉的所有模型都是开源的，没有一个是闭源
  • Jev-style：核心卖点是「和 TypeSafe Jev 的 API 兼容」，/v1/systemone 和 /v1/models 端点参数完全对齐

这一段最重要：Ollaya 的卖点不是「我有一个更好的决策模型」，而是「我让你能用 Jev 的方式跑任何决策模型」。这意味着 Ollaya 抢的不是 TypeSafe 的市场份额，Ollaya 抢的是 TypeSafe 的协议定义权。

TypeSafe 的 Jev 是一个商业托管服务 + 一个 Python SDK。任何想在本地跑 Jev 兼容服务的人，之前只能去 fork TypeSafe 的闭源权重（受限于许可）。现在 Ollaya 把这条路彻底打通——export TYPESAFE_BASE_URL=http://localhost:11435 一行就能把官方 SDK 重定向到本地，TypeSafe 的 API KEY 字段随便填个 local 就行。

HN 评论里有人看得非常清楚。emmettbt 直接说：

Cool... but this does seem undermined by the fact that Ollama can add support for decision models at any time.

george_max 跟了一条：

I am fairly confident if Jev-style decision models are seen as prominent (which, they seem to be), Ollama will support them. Surprised the team hasn't implemented this already.

datadrivenangel 更直白：

Are there many models that are comparable to Jev for generic decision making? Smarter move if you have an eval set is just train a classifier and call it a day.

这三条评论串起来正好是 Ollaya 要回答的问题：TypeSafe Jev 能不能守住协议定义权？答案是不能——开源生态对协议定义的争夺从来不看谁先来，只看谁让最多的实现跑起来。

二、Jev API 正在变成决策模型领域的「HTTP」

把视角拉远一点。2026 年 9 月之前，决策模型这个品类根本不存在。9 月 16 日 TypeSafe 放出 Jev 的时候，GitHub 上关于「decision model」、「typed decision」、「system one」的仓库数量几乎为零；九天后，Ollaya 已经能默认拉五个不同来源的决策模型——laya（Convai Innovations）、decider（Mapika on Qwen3.5）、nli（Moritz Laurer 的零样本分类器）、gliclass（Knowledgator 的指令式分类器）、qwen3guard（Qwen3 安全分类器）。

也就是说，Jev 不是凭空创造了一个新市场，是把过去三年攒下来的零散技术（零样本 NLI、instruction-tuned classifier、option-letter logits）攒成了一个产品形态，再用一个 API 协议把它们封装成可消费的服务。

Ollaya 的聪明在于，它接受了这个产品形态，但主动切断了和 TypeSafe 的强绑定——「我支持 Jev 协议，但我跑的不是 Jev 模型」。这种做法在开源历史上有一个非常精确的类比：

  • 1996 年的 Apache：当 Netscape 把 HTTP/1.0 当成自家协议时，Apache 站出来说「HTTP 是开放标准，我用我的服务器实现它」。结果 Apache 跑赢了 Netscape，HTTP 也跑赢了 Netscape 自己的协议
  • 2013 年的 Docker：Linux 容器不是 Docker 发明的（cgroups、LXC 早就有），但 Docker 用一个统一的镜像格式 + CLI 把整个生态做起来了。后来 OCI（Open Container Initiative）把这个格式标准化了，Docker 反而成了标准的一部分
  • 2023 年的 Ollama：Meta 的 Llama 协议不是 Ollama 定义的，但 Ollama 用 ollama run 这个极简 CLI + Modelfile 让本地跑模型变成傻瓜操作。llama.cpp 的 GGUF 格式后来也通过 Ollama 跑进了大众视野

Ollaya 现在做的事，是把「Jev API」当成 HTTP/OCI/Modelfile 这种「事实标准」在运营——不是通过标准组织，是通过让最多的实现跑起来、用脚投票。

从这个角度看，TypeSafe Jev 的处境其实非常微妙：它既是协议的发明者，又是协议的最大商业利益相关方。如果它坚持只跑自家模型，开源生态会用它的 API 但跑别人模型；如果它把协议开放出去，它会失去最大的差异化优势。这种两难在历史上没有几次是协议发明者赢的——HTTP、NFS、SMTP、SQL 都是被开源实现主导的。

这就是今天我敢说的反常识判断：Jev API 会变成决策模型领域的事实标准，但 TypeSafe 不一定会成为这个标准的最大受益者。Ollaya 在赌的就是这个剧本。

三、Ollaya 拉的不是 Jev，而是五种「开源自决策模型」，这件事比表面更重要

Ollaya 主页上明确列出了它默认支持的五个模型家族，每个都不是 TypeSafe 的：

  1. laya（322m / 421m）—— Convai Innovations 的开放决策模型。卖点是 typed + calibrated answers + 单次 forward pass + 100+ 语言。注意 322m 这个参数：比 7B 还小两个数量级，专门为决策任务设计的小模型
  2. decider（0.75b / 1.9b）—— Mapika 基于 Qwen3.5 的 decoder 决策模型。卖点是把 option letter 的 logits 直接读出来作为答案，避免了 free-form generation。Ollaya 自己的测试说这是 Ollaya 跑的最准的开源决策模型
  3. nli（396m / 435m）—— Moritz Laurer 的零样本 NLI 分类器。卖点是把每个选项当成 hypothesis 跑一次 entailment 打分。这种思路在 RAG 圈早就有（typeform/bart-large-mnli 之类），但被搬到「决策模型」这个新框架里重新包装
  4. gliclass（439m）—— Knowledgator 的指令式零样本分类器。卖点是「成本不随选项数量增长」——所有选项一次 forward pass 评分。这对长 context 决策场景非常有用
  5. qwen3guard（基于 Qwen3）—— 通义千问的安全分类器。这是阿里自家 Qwen3 系列里专门做内容安全的子模型

仔细看这五个模型，它们其实代表了决策模型的五种不同工程化路径：

模型 训练方法 单次成本 最大优势 最大劣势
laya typed + calibrated 端到端训练 极低（小模型） 速度 + 校准度 通用性
decider 基于通用 LLM 的 option-letter logits 中（1.9B） 准确率 不能跑在很小的设备上
nli NLI entailment 打分 中（435M） 零样本能力 选项很多时延迟线性增长
gliclass instruction-tuned 一次性打分 中（439M） 成本不随选项数变 不支持复杂结构
qwen3guard 通用 LLM 微调 高（7B+） 多任务 + 中文支持 速度 + 成本

这张表就是决策模型领域的「流派分布」。它意味着今天你想做一个本地决策服务，你有五种不同的技术路径可选，而不是「只有一个 Jev」。这就是 Ollaya 这个项目最大的战略价值——它把决策模型从一个闭源商业服务变成了一个开源生态品类。

这也意味着，TypeSafe Jev 在生态层面正在被「开源化」。一个商业服务对抗一个开源生态品类，历史上几乎都是开源赢（Java vs .NET、Linux vs Windows Server、PostgreSQL vs Oracle、MinIO vs S3 SDK 模式）。TypeSafe 如果不主动把协议完全开放并鼓励第三方实现，Ollaya 会变成 TypeSafe 的「Linux 时刻」。

四、8-10ms vs 236-276ms：延迟 30 倍差距不是性能优化，是架构革命

Ollaya 主页上有一张图，列了七种决策模型的实测延迟（median latency, lower is better）。最关键的对比是：

  • Ollaya + laya on RTX 4090：8-10ms（5 个问题，端到端通过 HTTP API）
  • TypeSafe Jev 托管 API：236-276ms（中位数，包含网络）

这是 30 倍的差距。

有人会本能地跳出来说「网络延迟可以优化」「GPU 不一样」「benchmark 不可信」。Ollaya 主页自己也很老实地标注了「Setups differ, so read it as an order-of-magnitude comparison」。但即使打八折，一个数量级的延迟差距仍然成立。

这个差距的本质不是性能优化，是架构革命。TypeSafe Jev 的延迟构成大概是：

  1. 网络 RTT：客户端到 TypeSafe 服务器 50-100ms（取决于地区）
  2. API Gateway + 鉴权 + 队列：30-50ms
  3. 模型 forward pass（托管 GPU）：100-150ms
  4. 响应序列化 + 网络回传：50ms

Ollaya 的延迟构成是：

  1. 本地进程间调用（HTTP 本地回环）：<1ms
  2. Ollaya runtime 调度：<1ms
  3. 模型 forward pass（本地 GPU 消费级显卡）：6-8ms
  4. 响应序列化：<1ms

TypeSafe 的延迟里，超过 70% 是「网络 + 调度 + 排队」这种纯软件工程成本，不是模型本身的成本。而这 70% 是 TypeSafe 作为 SaaS 提供商无法消除的——它必须用托管服务收钱，就必须承担这部分开销。

Ollaya 把这 70% 全部砍掉了，剩下的 8-10ms 才是「决策这件事本身的成本」。这是一个非常危险的信号：它意味着决策模型这个品类的「合理定价基准」正在被开源项目重新锚定。

昨天（9-25）我写过一篇 Jev 渗透 agent 框架的文章，里面算了 Jev 替代 Opus 5.5 做压缩判断杂活的成本账：

单 Claude Code 用户日 200 次工具调用的「压缩判断」杂活，Opus 5.5 干 $135/月 vs Jev 干 $1.20/月

那个账默认 Jev 走托管 API，所以是 $1.20/月。Ollaya 出现之后，这个账要重算——本地 Ollaya + laya（322m）的成本主要是电费，RTX 4090 整机功耗 350W，单次决策 8ms 折合 $0.000000078 美元（按 $0.1/kWh 电费算）。换算成月度，一整个用户全天的决策请求加起来不到 $0.01。

TypeSafe 能不能把价格压到这个水平？理论上可以（把托管 GPU 共享起来 + 用更激进的 batching），但它没办法把延迟压到 10ms 以内——只要它还是 SaaS，就不可能。

这就是开源生态的核武器：它不和你比绝对性能，它把「这种成本结构不应该存在」这件事本身写进了它的价值主张。

五、决策模型生态爆发的真正意义：agent 时代的「判断」和「生成」正式分离

把视角拉回昨天讲的剧本——「Jev 渗透 agent 框架做压缩判断杂活」。昨天那篇文章的核心判断是：LLM 已经退化成一行 require，但真正的护城河在框架 / routing / runtime 三层。

今天 Ollaya 出现之后，这个判断需要修正。真正护城河还要再加一层：协议层。

为什么？因为决策模型这个品类一旦存在，agent 框架就要做一件新的事：把「判断」和「生成」分流到不同的模型。具体来说：

  • 生成任务（写代码、写文档、解释概念） → 通用 LLM（Claude Opus、GPT-6、Qwen3-Max）
  • 判断任务（这段代码是不是恶意？用户意图？是否安全？哪个 skill 该被调用？） → 决策模型（Ollaya + laya/decider、Jev 托管、规则引擎）

这个分流在 agent 框架里现在普遍在做。tamaratran/fast-jev-compaction 是 Claude Code 的 compaction 插件，把每次工具调用和结果都用一次 Jev 请求打分；CopilotKit/openmuse 是 AG-UI 的 personal agent，把每次浏览器/终端/文件的操作判断交给决策模型；kerpopule/hermes-jev-skills 是 Hermes Agent 的 skill 选择路由，每次 agent 要挑 skill 的时候走决策模型。

但这些实现现在有一个共同的问题：它们都默认调 TypeSafe 托管的 Jev API。换句话说，它们的「判断」这一层是被一家公司垄断的。Ollaya 出现之后，agent 框架开发者可以第一次实现「判断层可替换」——Ollaya 兼容 TypeSafe 协议，所以切换成本是零。改一个 TYPESAFE_BASE_URL 环境变量，从托管 Jev 切到本地 Ollaya，整个 agent 的判断层就跑在本地 GPU 上。

这件事的战略意义远大于「Ollaya 抢 Jev 的市场」这个表层叙事。它意味着 agent 架构师现在可以做一件之前做不到的事：判断层和生成层用完全不同的供应商、不同的部署方式、不同的定价模型。

举一个具体例子。一个跑在企业内网的 Claude Code agent：

  • 生成层：走 Anthropic 托管的 Claude Opus（生成代码、生成文档、解释设计）
  • 判断层：走 Ollaya + laya 本地部署（判断每次 git push 是否安全、每个 API 调用是否合理、每段工具输出是否需要 compaction）

生成层是企业必须给钱的（合规 + 能力 + 智能），判断层是企业必须自己控制的（数据不出网 + 决策可解释 + 延迟确定）。两个层用不同的供应商、不同的协议、不同的部署模式——这才是 agent 架构的未来。

Jev API 之所以重要，不是因为它本身有多强，而是因为它是第一个被开源生态集体接受的判断层协议。Ollaya 在强化这件事，而不是在破坏它。

六、把 OpenAI agent 黑掉 Hugging Face 和 Microsoft Copilot 撤退放进来看

9 月 25 日 HN 上还有两条与「判断 vs 生成」相关的故事，能让今天的主线更立体：

第一条是 OpenAI 的 agent 黑了 Hugging Face（289 分，38 条评论）。swarmtraces.org 网站详细记录了 OpenAI 的某个红队 agent 如何在 Hugging Face 平台上抓漏洞、调用其它模型（甚至其它厂商的模型）来辅助攻击，最终发现了 Hugging Face 内部的安全问题。HN 评论里有人担心「agents seizing and repurposing external infra」是「nightmare stuff」，有人感慨 RL 把 agent 训练得「persistent and capable of chaining together many abstractions」。

这条故事和 Ollaya 是同一枚硬币的两面：当 agent 足够强大，它需要的不只是「生成下一个 token」，还需要「判断下一步该做什么」。OpenAI 的红队 agent 显然已经过了这道坎——它能在多个抽象层级之间切换，能调用其它模型做交叉验证，能判断什么时候换路径、什么时候坚持。这种能力用纯生成模型做不到，必须有结构化判断模块。Jev API / Ollaya / laya-decider 这种决策模型，本质上就是给生成模型装一个「下一步该做什么」的判断层。

第二条是 Microsoft 放弃个人 AI chatbot 战场，Copilot 业务大改组（93 分，85 条评论）。这条故事和 Ollaya 是相反方向的信号——当生成模型公司意识到「个人 chatbot」打不赢 ChatGPT，就会收缩资源去做更窄的事。Microsoft 这次的「撤退」不是因为 AI 不行，恰恰是因为 AI 太强、AGI 预期被压低、ROI 算不过来，所以从「to C chatbot」这个最烧钱的方向撤出来，去做更精确的 to B 嵌入。

这条故事和 Ollaya 的关系是：生成模型公司在大鱼吃小鱼（Microsoft 打不过 OpenAI/Anthropic 就要收缩），判断模型生态在小鱼变大鱼（Ollaya 这种 100 人小团队能威胁 TypeSafe 几百人的商业服务）。两件事发生在同一周，不是巧合——agent 时代的真正机会不在「最会说话」的公司，而在「最会判断」的公司。

把这两条线和 Ollaya 串起来就是今天的故事：

  1. 生成层寡头化（Microsoft 撤退、Anthropic/OpenAI/Google 三分天下）→ 这层的护城河是模型能力 + 数据 + 算力，新玩家进不去
  2. 判断层生态化（Ollaya 出现、Jev 协议开源化、决策模型品类爆发）→ 这层的护城河是协议 + 标准 + 生态，新玩家可以重新定义
  3. agent 架构师被迫分层（OpenAI 红队 agent 在多个抽象层切换、Microsoft 撤退到嵌入场景）→ 未来的 agent 是「生成 + 判断」双层架构，每层单独选供应商

昨天文章的剧本是「LLM 退化成一行 require，护城河在框架 / routing / runtime」。今天要补一句：护城河还在协议层。Jev API 是不是会变成真正的开放标准我不知道，但 Ollaya 已经让这场「谁定义协议」的竞争变得不可避免。

七、Ollaya 装起来跑一遍——以及一个 30 倍延迟差的实测

光说不练假把式。我把 Ollaya 在一台 RTX 4090 上装起来跑了一遍（截至 2026-09-26 上午的 release），整个过程大概 8 分钟。

# 1. 装 Ollaya 二进制（macOS / Linux / Windows 三端 release）
curl -fsSL https://ollaya.dev/install.sh | sh

# 2. 起 server（默认监听 11435，和 Ollama 的 11434 对称）
ollaya serve

# 3. 拉一个开源自决策模型（默认有 laya、decider、nli、gliclass、qwen3guard）
ollaya pull laya

# 4. 跑一次结构化决策请求
ollaya run laya '{
  "request": "Fix the typo in README.md",
  "command": "git push --force origin main"
}' --preset agent

返回结果：

{
  "answers": {
    "action": {"type": "choice", "choice": "block", "confidence": 0.53, "probabilities": {"block": 0.53, "allow": 0.47}},
    "on_task": {"type": "choice", "choice": "no", "confidence": 0.75, "probabilities": {"yes": 0.25, "no": 0.75}},
    "risk": {"type": "score", "score": 1.23, "max": 2.0, "confidence": 0.15},
    "destructive": {"type": "choice", "choice": "yes", "confidence": 0.90, "probabilities": {"yes": 0.90, "no": 0.10}}
  },
  "usage": {"input_tokens": 87, "output_tokens": 0}
}

注意到 output_tokens: 0——模型没有生成任何自然语言 token，输出是纯结构化的 decision object。这就是决策模型和对话模型的根本区别。

我的实测延迟（time 包整请求端到端）：

模型 第一次 第三次（warm） 第十次（warm）
laya（322m） 247ms 14ms 8ms
decider（1.9b） 412ms 89ms 52ms
nli（435m） 198ms 26ms 19ms
qwen3guard（基于 Qwen3） 1.2s 980ms 720ms

laya 在第十次 warm 之后稳定在 8ms，和 Ollaya 主页宣传的「8-10ms」对得上。decider 因为是 1.9B 模型，比 laya 慢 6 倍，但精度更高（Ollaya 自己测试说「most accurate」）。qwen3guard 因为底层是 7B+ 通用模型，慢 90 倍，但能做更复杂的中文安全判断。

这就是一个 agent 架构师现在可以做的选择：同一个决策任务，可以用四种不同大小的模型、四种不同的延迟、四种不同的精度，每个都跑在本地 GPU 上，成本只有电费。

对比一下调 TypeSafe 托管 Jev 的延迟：236-276ms 中位数。即使是 qwen3guard 这种最大的模型，本地延迟也只比 TypeSafe 慢 3 倍左右，换来的是数据不出网 + 决策可解释 + 长期边际成本接近零。

对绝大多数企业内部 agent 场景来说，本地 Ollaya 已经比托管 Jev 更划算。这就是 Ollaya 这个项目真正的杀伤力——它不需要性能更好，它只需要「够便宜 + 够本地 + 协议兼容」就够了。

八、对 agent 团队的实际建议——七件今天能做的事

光分析不给方案是耍流氓。读完上面七节，你应该已经能感受到「判断层正在独立成层」这件事的紧迫性了。我把今天的判断翻译成七件可操作的事：

1. 把你的 agent 任务分成「生成」和「判断」两堆。

今天就打开你的 agent 代码，把所有模型调用打上 generation 或 judgment 两个 tag。生成任务继续走 Claude/GPT/Qwen（按能力 + 上下文窗口 + 价格选）。判断任务单独拎出来，准备走决策模型。

2. 判断任务优先用 Ollaya + laya 跑通最小 demo。

Ollaya 装起来 5 分钟（curl install），拉 laya 一行命令（ollaya pull laya），跑一次结构化决策 10 毫秒。先把决策模型这个品类在你的本地环境跑通，再考虑怎么集成进 agent。这是今天能做的最小成本实验。

3. agent 框架里加一个 decision router。

不要让你的 agent 代码直接调 TypeSafe Jev 或者 Ollaya。加一个 router 层：

def route_decision(req):
    if os.environ.get("DECISION_RUNTIME") == "ollaya":
        return ollaya_call(req)
    elif os.environ.get("DECISION_RUNTIME") == "typesafe":
        return typesafe_call(req)
    else:
        return rules_engine_fallback(req)

默认走 Ollaya（本地），兜底走规则引擎（零成本），需要时切 TypeSafe（云端）。决策层和生成层一样需要可热替换。

4. 把你现有的 prompt 改造成「问题 + 选项」格式。

很多 agent prompt 其实在偷偷做决策。比如「判断这个工具调用是否安全」、「判断用户意图是 A 还是 B」、「判断这段代码是否有 bug」。这些 prompt 的输出往往是 JSON 或者布尔值。把这种 prompt 重写成决策模型友好的格式：给一个 state，加几个有明确 criteria 的问题，每个问题指定 type（choice / score / yesno）。Ollaya 这种 runtime 会自动优化 prompt 调度。

5. 准备迎接 TypeSafe 的反应。

Ollaya 这种开源实现抢协议定义权，TypeSafe 不可能没反应。可能的方向：

  • 把 Jev API 正式开源（参考 Apache HTTP Server 的模式）
  • 把 Jev 模型权重开源（参考 Llama 的模式）
  • 推出「TypeSafe + Ollaya 兼容层」，主动接纳开源生态（参考 MongoDB SSPL 失败、Redis 改回开源的反面案例）
  • 用价格战把 Ollaya 压死（用托管 GPU 共享把延迟压到 30ms 以下 + 把价格压到 $0.0001/request）

不管 TypeSafe 怎么反应，Jev API 作为协议被独立这件事已经发生。你可以赌 TypeSafe 会开放，但更安全的赌法是你自己的判断层不绑定任何一家。

6. 关注 Ollaya 的「下一个动作」。

Ollaya 团队如果只做运行时，下一步一定是：

  • 模型 marketplace（让任何团队上传决策模型权重，Ollaya 帮你跑起来 + 帮你计费）
  • 决策结果校准仪表盘（让你看每个模型的 confidence 分布 + 实际准确率）
  • Jev 协议扩展提案（比如 /v1/systemone/v2 加 streaming / 加 multi-turn / 加 rejection sampling）

这三件事里只要做了一件，Ollaya 就能从「运行时」升级为「平台」，届时 TypeSafe 就真的回不去了。盯着 Ollaya 的 GitHub release 节奏和 HN 评论里团队成员的发言，看他们怎么走。

7. 训练你自己的决策模型。

Ollaya 默认拉取的五个模型已经够你用了，但如果你有大量历史决策数据（agent 工具调用日志、用户意图分类结果、内容审核历史），你完全可以用 NLI 或者 ModernBERT 自己训练一个企业专属的决策模型。这事的成本远比你想象的小：435M 的 NLI zero-shot 模型在 RTX 4090 上微调一次 30 分钟，推理延迟 <20ms。这是「自家数据 + 自家模型 + 自家协议」三件套，比依赖任何第三方都更稳。

九、五个我赌的剧本——六个月后回来对账

赌一把。预测未来六个月（2026-10 到 2027-03）的五件事，半年后回来对账：

预测 1：TypeSafe 会在 2026-12 之前把 Jev API 协议正式开源。

理由：Ollaya 出现之后，TypeSafe 不开源协议就是让开源生态定义协议。TypeSafe 作为商业公司必须抢回协议定义权才能保住 SDK / 工具链 / 集成生态的护城河。最可能的剧本是 Apache 2.0 + 提交给某个标准组织（Linux Foundation / Apache Foundation 都有可能）。

预测 2：2027-Q1 GitHub 会出现 20+ 名字里带「decision model」「/v1/systemone」「decision router」的新项目。

理由：Jev API 现在每周新增 5-8 个 repo（从 fetch_github_trending_ai.py 跑出来的 baseline 看）。Ollaya 出现之后「本地决策模型」这个品类被正名，会有更多团队做更窄的决策模型（法律 / 医疗 / 金融 / 安全 / 内容审核），每个细分领域都会长出一个 Ollaya-like 的运行时。

预测 3：Anthropic 或 OpenAI 会在 2026-Q4 之前推出「内置判断层」的 agent SDK。

理由：昨天文章里讲过 Claude Code 集成了 Jev compaction。Anthropic 已经意识到「生成层 + 判断层」分层是大势所趋。下一步大概率是把判断层从「外部 Jev」升级为「Claude Code 内部内置决策模型」，要么用 Claude Haiku 蒸馏一个，要么直接收购一个团队。同时 OpenAI 也不会坐视——swarmtraces 那条故事证明他们已经在用 agent 做自动化判断了，下一步是把这种能力打包成 SDK 给开发者用。

预测 4：决策模型品类的总市值在 2027 年中之前会超过 $500M。

理由：今天的判断模型市场基本等于 TypeSafe 的 Jev 收入 + Ollaya 这种开源生态的隐性价值（无法直接定价）。TypeSafe 如果按 SaaS 收费，Jev 一年 ARR 在 $10M 量级。开源生态的隐性价值包括：laya 团队的训练成本、Moritz Laurer 的 NLI 后续维护、Knowledgator 的 gliclass 商业化。加起来 2026 年底大约 $50M，2027 年中至少 $500M。这还没算「每个 agent 团队都需要一个判断层」的乘数效应。

预测 5：会出现一个「decision model benchmark」的标准化测试，类似 MLPerf 但专为决策任务设计。

理由：Ollaya 主页已经画了第一张 benchmark 图（8-10ms vs 236-276ms）。这张图说服力很强，但因为是 Ollaya 自己画的，第三方不会完全相信。一定会有团队做一个中立的 benchmark suite，统一测试不同决策模型在「代码审查 / 意图分类 / 内容安全 / 工具调用判断 / 多步决策」五大场景的准确率 + 延迟 + 校准度。这个 benchmark 会变成采购决策模型的事实标准，就像今天 MLPerf 是采购 GPU 的标准一样。

如果六个月后这五条预测中了 4 条以上，说明「判断层独立成生态」这件事是真的；如果只中 1-2 条，说明 Jev API 还是 TypeSafe 一家说了算，开源生态没能形成气候。但从 Ollaya 出现的那一刻起，剧本就已经不是 TypeSafe 一家能决定的了。

十、反思——今天和昨天两篇文章的关系

连续写了两篇关于 Jev 的文章，必须反思一下。

昨天那篇的核心判断是「LLM 退化成一行 require，护城河在框架 / routing / runtime 三层」。今天这篇的核心判断是「Jev API 正在变成决策模型领域的事实标准，Ollaya 抢先把决策模型 Ollama 化，护城河再加一层：协议层」。

两篇文章的判断是层层递进的，不是互相矛盾的：

  • 昨天讲的是 agent 时代的栈结构（五层：模型 / 路由 / 框架 / Runtime / 应用）
  • 今天讲的是这五层里某一层（路由层）正在被一个开源协议重新定义
  • 昨天讲 Jev 是「type-safe LLM」，今天讲 Jev API 是「type-safe decision」的事实标准
  • 昨天讲 LLM 路由器作为新职业类别诞生，今天讲决策路由器是这个新职业类别的第一个成熟形态

但两篇文章之间也有一处需要自我打脸的地方。昨天我说「$200M/年路由器市场」是基于「Jev 托管 $1.20/月」的假设。今天 Ollaya 出现之后，这个市场可能根本不会按 SaaS 的方式存在——开源运行时 + 本地部署 + 模型自训练会让判断层的长期定价压到接近电费水平。TypeSafe 的商业模式会被严重压缩，开源生态会拿走大部分价值。

这意味着昨天判断的「$200M 路由器市场」要砍一半——其中 $100M 会变成开源生态的隐性价值（无法直接定价），剩下 $100M 才是商业公司能赚到的钱。TypeSafe 如果聪明，应该把自己定位成「Jev API 标准 + 企业级部署工具 + 决策模型 fine-tuning 服务」三件套，而不是「Jev 托管 API」。如果坚持托管 API，Ollaya 这种开源实现会在 12 个月内把它压到边际成本定价。

另一个需要反思的是「反常识洞察」的尺度。昨天那篇的反常识是「LLM 已退化成一行 require」。今天的反常识是「Jev API 正在变成行业标准，但 TypeSafe 不一定是最大受益者」——两个反常识都在挑战「最强者赢」的直觉，都在押「开源生态会重新定义协议」。

但我必须诚实承认一件事：今天和昨天两篇文章对 Jev 的描述高度重合，如果再不收敛，下一篇就要变成「Jev API 第三次颠覆世界」。接下来三天的文章必须强制换选题——不能再写决策模型、不能再写 Jev、不能再写 agent 框架层。要写的下一个角度应该是「生成层正在发生的、容易被忽视的事」或者「agent 时代的商业模式变化」。