Jev 爆火之后，我们真正该重新想想 Agent 到底该怎么“下决定”

Jev 爆火之后，我们真正该重新想想 Agent 到底该怎么“下决定”

摘要

Jev 最近火起来的时候，很多人第一反应是：模型是不是终于不聊天了，开始用更接近机器的方式干活。这个说法足够抓人，但把它原封不动搬进工程设计里，很容易走偏。

模型确实可以不输出长文本，改成 Choice、Score、Noul 这类受约束的结果，但这不代表它正在用 0 和 1 直接操纵机器。更值得工程师关注的，是模型输出第一次能够比较稳定地带着概率、版本、证据状态和失败路径进入策略层。它可能不会让系统一夜之间快两倍，却有机会把“模型说什么就尽量执行什么”，改造成“模型提供判断，策略层决定是否行动”。

不过，这件事没有宣传得那么轻松。受限输出压住的是一部分格式和解析问题，不是业务语义错误；概率写进接口也不等于概率可信；类型契约能消除歧义，也会让团队提前承诺业务世界。本文想聊的不是怎样复制 Jev，而是从它的走红中抽出一个更实际的问题：当一个模型频繁扮演软件系统里的“判断模块”，我们到底需要什么样的接口、责任边界和验证方法。

关键词：Jev；结构化输出；受限判断；类型契约；校准概率；策略路由；MCP；A2A；AG-UI

0. 先是现象火了，但真正的问题藏在后面

Jev 最近在开发者圈子里确实火了一把。

它和传统聊天模型的观感很不一样。传统模型常常是一段分析加一个结论，甚至分析写得很热闹，结论却埋在中间；Jev 这类受限判断模型则更像是被提前规定好“只能从这几个问题、几个答案里做选择”。它可以直接输出 Choice、Score、Noul，再加上概率和置信度。

评论区出现了两种很有意思的说法：

这两个说法之所以很有趣，是因为它们把复杂的趋势压缩成了极有画面感的口号。但画面感强不等于工程上成立。

模型不输出散文，确实已经发生了；输出对程序更友好，也可以从接口角度讨论。但“不生成自然语言”推不出“模型已经在操纵机器底层”，更推不出“统一语言将取代自然语言”。中间至少漏掉了序列化、协议、权限、状态机、策略路由和人工责任。

所以我并不打算给 Jev 贴一个“范式革命”或“只是噱头”的标签。真正有意思的问题是：当模型成为系统中的一个判断模块，我们该怎样设计一个既让程序好消费、又不让模型假装无所不知的接口？

答案不是继续让模型多说话，也不是把自然语言一脚踢开，而是把判断变成可校验、可校准、可路由、可追责的软件契约。

1. Jev 让人兴奋，是因为模型开始“下判断”而不是“编故事”

传统 Agent 的常见链路，是先让模型生成自然语言，再靠正则、JSON parser、字段映射或另一个模型把结论抠出来。链路越长，出错方式就越多。模型可能先道歉，再解释，最后才给出答案；答案又可能藏在一段自我修正里。下游拿到的不是一个结论，而是一段需要再次理解的材料。

受限判断模型的做法是提前把问题、选项、评分尺度和命题定义清楚，让模型只能在这些边界内回答。一个典型的订单复核结果，可能长这样：

{
"task_id": "order-review",
"primitive": "Choice",
"distribution": {
"auto_approve": 0.02,
"manual_review": 0.86,
"reject": 0.12
},
"selected": "manual_review",
"confidence": 0.86,
"fallback": "needs_more_context"
}

输出不再是开放散文，而是一份程序可以直接消费的结果。模型没有把整个思考过程都讲出来，而是在预设空间内给出一个判断和概率分布。

但这里需要克制一点。更快、输出更短、解析更省，确实是受限判断可能带来的好处；可它能否让整个生产系统变快，还要看上下文编码、网络、批量、缓存、策略执行和人工复核。不能只看单次响应时间就推出系统会线性加速。

真正值得兴奋的，其实不是速度本身，而是模型的不确定性开始有了接口属性。

以前模型说“我很确定”，这句话通常只能供人参考，很难直接进入策略引擎。它不能和错误成本相乘，也很难被审计。现在概率变成了结构化结果的一部分，系统至少可以开始考虑：什么时候自动执行，什么时候升级强模型，什么时候补充上下文，什么时候直接交给人。

这并不是说模型从此无所不知，而是它第一次能在接口层面诚实地表达“我有多不确定”。

不过，“没有幻觉”这句宣传也得降降温。受限输出最多只能在格式层面减少错误。模型依旧可能：

• 在合法选项里选错；
• 在错误前提下给出高置信度；
• 混淆评分锚点；
• 把边界模糊的样本硬塞进某个类别；
• 在长尾场景里系统性跑偏。

类型安全保护的是输出形状，不是业务语义。它可以阻止模型写出不存在的工具名，却无法阻止一个本身定义错误的类别得到很高的概率。接口变窄之后，错误没有消失，只是更容易被统计和识别。

2. “用 0 和 1 交流”很燃，但模型其实还在正常说话、正常走网络

“模型正在用 0 和 1 跟机器交互”确实是一个很硬核的表达，但工程上应该把它理解为比喻，而不是机制。

即使模型输出的是 JSON，请求通常也还走在 HTTP、JSON、SDK、schema 校验、权限检查和状态机这一整套链路上。它并没有绕过 tokenizer、序列化、网络协议，更没有获得直接操纵硬件的能力。所谓“机器原生”，至少在目前这一阶段，更接近“应用层对机器更友好”，而不是物理层或潜空间直连。

受限判断真正带来的，是减少不必要的文本生成、解析失败和字段映射，让概率更容易进入策略。它不能自动换来比特级互联、跨模型语义一致、更低的网络开销，更不能让两个完全不同架构的模型天然互相理解。

另一条潜空间通信路线确实更贴近“模型底层”。它尝试直接传递 embedding、hidden state、KV cache 或 latent state，希望省掉 token 序列化和部分重复编码。这个方向的研究价值是真实的：通信量可能下降，部分链路也可能缩短。

但生产环境里，它面对的问题同样真实。不同模型的架构、训练目标和表征空间不同，原始向量未必能直接互换；中间表示一旦发生错误，通常很难像日志一样定位；模型升级后，旧表示可能失效；异常向量还可能比异常文本更难检测。现阶段它更适合研究、端侧或特定的同构环境，而不是直接充当需要审计和跨团队协同的业务接口。

还有一个容易被忽略的事实：Jev 类接口里的选项、评分锚点和命题，本身往往就是用自然语言写的。开发者得先回答清楚：

• 这个问题是不是单一维度的；
• 选项是否互斥；
• 真实业务能不能被现有选项覆盖；
• “低风险”和“中风险”的边界在哪里；
• 什么情况必须升级人工；
• 谁有权修改这些定义。

所以，自然语言并没有从系统里退场，只是从输出端移动到了设计端。Prompt engineering 并没有消失，它升级成了 schema engineering，而且难度未必更低。过去模型说错，团队可以说“是模型的问题”；现在接口给错，往往需要回过头审视分类维度和业务定义。

3. “统一语言”很酷，但可能把三个冲突目标硬塞在一起

“人类、计算机和模型都能看懂”听起来非常完整，实际上藏着目标冲突。

人需要命名、注释和上下文；机器需要紧凑、稳定、确定和易校验；模型则更擅长利用自然语言提示，而不是天然喜欢一种极简符号。有研究甚至专门尝试让模型放弃人类可读性，采用更压缩的通信方式。这说明“模型间效率最高”和“人必须能读懂”未必能同时成立。

更现实的目标不是让所有人看懂同一份底层文件，而是分层可读：业务人员看语义和风险，模型消费自然语言定义与上下文，程序消费字段、枚举、概率和版本，审计系统保存状态、证据与结果。

普通工程师不需要读懂所有 TCP 报文，也能理解 flag 和业务状态；运行时 trace 不必让人逐条阅读，但摘要和关键事件应该看得懂。让所有角色共享一份“完美统一”的表示，最后往往既不高效，也难维护。

历史上类似的统一冲动已经出现过好几轮。KQML、FIPA-ACL 想统一 Agent 通信和本体，但现实中的组织常常连“客户”是什么都定义不齐。SOAP/WSDL 强调强类型和整体契约，版本与集成成本却不低。语义网希望通过 RDF/OWL 让机器理解知识，但标注成本和推理规模始终是难题。

活下来的往往不是“统一一切”的那一类，而是边界更克制的一类。Protobuf、Avro 只统一序列化和数据交换，不统一定义业务语义。MCP、A2A、AG-UI 同样如此，它们统一的是连接、调用、任务生命周期、状态和交互机制，而不是让所有团队对“客户”“风险”和“合规”给出完全相同的解释。

因此，真正值得做的不是一个包打天下的语言，而是一套能够各自演进的契约。语法会变，但版本、责任、兼容和回滚机制必须存在。

4. MCP、A2A、AG-UI 没有试图统一一切，这恰恰很务实

MCP 解决的是 Agent 怎么连接外部能力。它提供有状态连接、能力协商，以及 tools、resources、prompts 等概念。[1] 它主要回答：

• 有哪些工具可以调用；
• 怎么获取上下文和资源；
• 怎么协商能力；
• 怎么调用外部服务。

但它不负责定义“订单风险”到底是什么意思，也不会替团队计算人工复核成本和错误代价。

A2A 解决的是 Agent 之间怎么协作。它使用 Agent Card 声明身份、能力、端点、技能和认证要求，围绕 Task、Message、Artifact 组织任务。[2] 它适合处理 Agent 发现、任务创建、状态转换、产物交付和长时任务。它也没有野心统一全部领域语义，更不会替业务方设计类别和阈值。

AG-UI 面向的是 Agent 与前端、用户之间的状态交互。它关注状态管理、事件、订阅和增量更新，适合流式展示、用户中途介入、状态恢复和多端协同。[3]

三者放在一起，恰好构成了一个比较清楚的分工：

AG-UI → 前端与用户交互层
A2A → 任务协作编排层
MCP → 能力与资源接入层
确定性服务 → 数据库、工具和业务规则执行层

每一层可以单独演进。前端不需要理解某个模型的内部细节，任务编排不需要替所有领域定义实体，工具层也不需要关心页面状态。统一的是“怎么连接、怎么协商、怎么推进任务”，而不是“业务世界究竟是什么”。

这种克制不是保守，而是工程上更长久的做法。全局机制能够标准化，业务语义却高度依赖组织、场景和时间。若强行把后者写进全局协议，任何一个团队修改定义，都可能波及全网。

5. 落地时不要急着造语言，先设计一份“会进化的契约”

如果把讨论收敛成一个可落地的东西，最重要的不是发明新语法，而是定义一份类型契约。

decision_contract:
id: org.domain/order_review.v3
owner: risk–platform
primitives:
– Choice
– Score
– Noul
semantics:
intent: 决定订单是否需要人工复核
dimensions:
– id: review_action
type: Choice
options: [auto_approve, manual_review, reject]
definitions:
manual_review: 存在异常线索，但证据不足以直接拒绝
– id: risk_level
type: Score
scale: [1, 5]
anchors:
1: 无可识别风险信号
5: 可能导致资金损失或安全事故
inputs:
– order_state
– policy_version
– evidence_references
calibration:
method: isotonic
bins: 20
evaluated_at: 2026-09-20
sample_range: 2026–06–01/2026–08–31
drift_threshold: 0.05
economics:
auto_cost: 0.001
review_cost: 0.5
human_cost: 5.0
error_cost:
false_accept: 100
false_reject: 10
policy:
budget: 500
high_risk_actions: [reject]
review_required_when: risk_level >= 4
audit:
trace_id: required
state_hash: required
policy_version: required
evidence_references: required
compatibility:
previous: org.domain/order_review.v2
migration: dual_read
fallback:
– needs_more_context
– uncertain

它和常见 JSON Schema 最大的区别，不只是字段定义，而是把业务语义、校准信息、成本风险、版本兼容和失败路径一起写进契约。概率、阈值和错误成本不再是散落在业务代码里的魔法数字，而是可以版本化、灰度和回滚的属性。

概率接口也应该保留完整分布，不能只丢一个最终选项。下面是一个 TypeScript 风格的定义：

type DecisionPrimitive =
| ChoiceResult
| ScoreResult
| NoulResult;

interface BaseDecision {
contract_id: string;
contract_version: string;
model: {
provider: string;
name: string;
version: string;
};
calibration: {
evaluated_at: string;
method: string;
sample_range?: [string, string];
};
trace: {
trace_id: string;
state_hash?: string;
policy_version?: string;
};
fallback?: "other" | "uncertain" | "needs_more_context";
}

interface ChoiceResult extends BaseDecision {
type: "Choice";
distribution: Record<string, number>;
selected: string;
confidence: number;
}

interface ScoreResult extends BaseDecision {
type: "Score";
scale: [number, number];
value: number;
distribution?: number[];
confidence: number;
}

interface NoulResult extends BaseDecision {
type: "Noul";
statement: string;
probability: number;
confidence: number;
}

只保存 selected 会丢掉重新计算阈值、调整策略和分析事故所需的信息。系统至少应该能区分：模型不确定、证据冲突、字段缺失、概率未经充分校准，以及输入可能已经漂移。

路由层也不该用一堆硬编码阈值草草了事。可以用成本、风险预算和校准质量构造一个策略函数：

from dataclasses import dataclass

@dataclass
class CostTable:
auto_cost: float
review_cost: float
human_cost: float
error_cost: dict[str, float]

def expected_risk(decision, cost: CostTable) –> float:
# 根据预测类别、错误成本、校准质量和证据状态计算
...

def route(decision, cost: CostTable, risk_budget: float) –> str:
if expected_risk(decision, cost) > risk_budget:
return "human"

if decision.confidence >= 0.98:
return "auto"

if decision.confidence >= 0.85:
return "review"

return "human"

0.9、0.95 这种阈值不能拍脑袋固化。不同错误代价、人工容量、模型版本和证据质量，可能对应完全不同的策略。阈值应该从契约、成本和校准状态中计算出来，而不是成为另一个无人敢动的常量。

逃逸口也不是给接口打补丁。固定枚举注定无法覆盖未来全部情况，必须显式保留 other、uncertain、needs_more_context、needs_human。逃逸口命中率升高，可能意味着新类别、分布漂移、政策变化或选项边界遗漏；但它不能直接证明其中任何一项。还要结合输入统计、人工复核方向、校准误差和时间序列一起看。

6. 推荐架构：模型负责判断，人负责定义，策略引擎负责行动

一个相对稳妥的架构可以分成几个阶段：

事件或用户输入
↓
开放模型：解释、改写、组织证据
↓
状态构造与上下文筛选
↓
受限判断模型：Choice / Score / Noul
↓
确定性策略引擎：权限、阈值、预算
↓
┌──────────┬────────────┬──────────┐
自动执行 复核或强模型 人工或拒绝
└──────────┴────────────┴──────────┘
↓
审计、回放、漂移与校准更新

模型输出只是策略引擎的一项输入。真正决定要不要执行动作的，还包括权限、状态、预算、审计和回滚机制。

自然语言依然很重要，只是位置变了。它适合定义语义、处理长尾、协商异常和复盘事故；结构化消息适合承担稳定、高频、能够自动验证的流程。两者不是替代关系，而是分工关系。

可以把系统大致分成四层：

自然语言不再独自承担执行责任，但它仍是团队发现未知、命名新问题和调整边界的主要工具。

7. 想证明这套架构有价值，四组实验比讲道理更有用

技术选型不能只靠架构图。真正要判断的是：收益究竟来自哪里，维护成本又有多高。

首先得回答“它比谁强”。至少需要规则或既有流程、受限判断模型、同规模开放模型加 JSON Schema、传统分类器这四组基线。如果最后一组已经够用，就没有必要上大模型；如果开放模型加 JSON Schema 和受限模型效果接近，说明收益可能主要来自结构化，而不是特定架构；如果受限模型相比既有流程只是快了一点点，却让人工复核和 schema 维护翻倍，那方向本身就要重新考虑。

观察指标也不能只有准确率。ECE、Brier score、P50/P95/P99、单条与总成本、分布外召回、判断数量增加后的扩展性、人工修改率和错误后果，都值得进入报告。

其次是 schema 的维护成本。很多团队一开始只计算模型费用，却忽略了选项设计、标注争议、schema 变更、下游影响、重新校准和事故排查。如果一个业务类别每个月都在剧烈变化，固定枚举不仅没有省成本，反而制造了新的协调负担。此时长尾请求交给开放模型或人工处理，可能比强行类型化更划算。

第三组实验要验证概率是否真的可用。这里更建议按时间切分数据，而不是随机切分，因为概率和 schema 最容易在实际部署后失效。测试范围至少应该覆盖高置信度区间的真实正确率、各类别校准误差、未来时间段漂移、输入长度变化、政策版本切换、人工修改方向，以及阈值变化对错误成本的影响。

如果高置信度错误持续集中在某几个类别，往往说明问题出在数据、标签或评分锚点，而不是“阈值设得还不够高”。盲目提高阈值，只会让系统要么过度拒绝，要么把更多样本丢给人工。

最后可以测试逃逸口能否成为漂移探测器。单独看 other 或 uncertain 的命中率并不够，最好同时观察输入 embedding、最近邻距离、标签变化率、人工修改率和校准误差。多个信号一起变化时，才更有理由怀疑分布漂移；只有逃逸口升高，可能只是提示被改坏、采样变化、上下文截断或上游数据退化。

8. 模型变快只是一个表象，接口责任才重新分配了

“模型更快、更便宜”很容易被当成受限判断的全部价值，但真正值得拆解的是成本结构。一次判断可以粗略拆成上下文、模型、解码、解析、策略和执行几个阶段；完整成本也不只是模型调用费，还包括输出、解析、人工复核、错误、schema 维护和监控校准。

即便单次推理变快，如果团队为了维护分类体系不断增加人力，速度优势也可能被抵消。反过来，如果类型化让高风险动作减少、人工复核集中到真正不确定的样本上，那么即使模型本身不是最便宜的一环，整体收益仍然可能成立。

错误也同样需要分层。开放文本链路的问题往往具有乘性：生成错一点，解析再错一点，字段映射再错一点，最后策略还可能理解错。受限输出和严格 schema 能压住后面几环，但输入表示错误、schema 定义错误、分类错误和阈值错误并不会自动消失。

这里出现了一个微妙但重要的变化：错误从“不可控的输出格式”变成了“可统计的分类风险”。后者依然危险，却至少可以校准、可以设阈值、可以比较不同策略。系统不再被动补救，而是开始管理一个风险源。

代价敏感决策是概率接口的价值落点。设动作集合为 (a \\in A)，真实状态为 (y)，模型输出概率为 (p(y\\mid x))，错误代价为 (C(y,a))，人工复核成本为 (r)，策略引擎就可以比较期望损失：

R(a) = Σ_y p(y|x) · C(y, a)
a* = argmin_a [ R(a) + I(a = review) · r ]

这样系统可以主动选择“补充上下文”“升级模型”“人工复核”或“拒绝”，而不是只根据一个自信度字段二选一。当然，这个模型成立的前提是概率经过校准，而且业务确实能够给错误代价和人工成本赋值。若概率只是模型随口说出的自信，它反而会成为误导策略引擎的新风险。

类型系统带来的另一个变化，是责任从“模型负责说得漂亮”转向“团队提前承诺业务世界”。每新增一个枚举值，都意味着补充定义、积累样本、更新测试、重新校准、通知下游、设计兼容和审计事故口径。

自然语言适合表达还没被命名的异常，类型系统则要求团队提前下判断。因此，合理方式不是“把一切都类型化”，而是按稳定性划分：

类型化不是表达能力低，而是承诺能力高。它适合承担承诺，不适合吞噬所有未知。

9. MCP、A2A、AG-UI 的边界，反映了协议的生存智慧

协议设计其实也有一条反复被验证的经验：活得久的协议通常只统一机制，不统一意义。

MCP、A2A、AG-UI 分别承担能力接入、任务协作和前端交互。它们没有试图规定所有团队对业务实体的共同理解，因为全局语义一致的成本太高。KQML 和 FIPA-ACL 需要协作方先就通信意图和本体达成一致；SOAP/WSDL 的强契约和版本成本不低；语义网则需要大量标注与机器推理。

相比之下，Protobuf 和 Avro 只解决序列化和数据交换；MCP、A2A、AG-UI 则把语义留给具体领域。它们没有放弃一致性，只是把一致性的边界从“业务意义”调整成“连接、调用、任务推进和消息交换”。

一个可演进的契约注册表，也应该保持同样的克制。它管理的是版本、owner、兼容策略、消费者和灰度状态，而不是重新定义“风险是什么”。例如：

registry_entry:
contract_id: org.risk/order_review.v3
owner: risk–platform
compatibility: additive
previous_versions:
– org.risk/order_review.v2
consumers:
– service: payment–gateway
minimum_contract_version: v2
– service: audit–service
minimum_contract_version: v3
lifecycle:
draft: 2026-08-01
canary: 2026-09-01
stable: 2026-09-20
deprecation_date: 2026-12-31
validation:
schema_check: required
shadow_evaluation: required
consumer_compatibility: required
rollback:
previous_stable: org.risk/order_review.v2

如果注册表开始规定所有团队的业务本体，它就不再是接口目录，而会变成一个谁都不敢升级的全局语义数据库。

可演进也不等于随意变更。至少应该区分新增可选字段、修改枚举语义、删除字段、收紧类型，以及改变判断含义或风险口径。不同变化对消费者的影响完全不同。生产环境还需要契约 owner、消费者清单、影子评估、灰度比例、错误预算和回滚触发器。只有版本号而没有兼容策略，和没有版本管理其实差不多。

10. 概率真正有价值的那一天，是从“展示属性”变成“系统属性”

模型输出 confidence: 0.97，并不代表真实正确率就是 97%。如果概率没有校准，策略引擎就会把模型的自信误当成客观可靠性。

ECE 可以用来衡量预测置信度和实际正确率之间的偏离程度：

import numpy as np

def expected_calibration_error(
probabilities, labels, bins=20
):
probabilities = np.asarray(probabilities)
labels = np.asarray(labels)

bin_edges = np.linspace(0, 1, bins + 1)
bin_ids = np.clip(
np.digitize(probabilities, bin_edges[:–1]), 1, bins
) – 1

ece = 0.0
for i in range(bins):
mask = bin_ids == i
if mask.sum() == 0:
continue

accuracy = labels[mask].mean()
confidence = probabilities[mask].mean()
weight = mask.mean()

ece += weight * abs(accuracy – confidence)

return ece

ECE 只是工具之一，而且受分箱方式影响。看到一个很小的数值，不能马上宣布模型可靠，还需要结合可靠性图、样本量、类别错误和时间窗口。

校准数据本身也有门道。常见误区包括用训练集内部数据自证、忽略时间漂移、把类别不平衡解释成模型自信、用极少样本支撑边界区间，以及模型换版本后继续沿用旧校准结果。真正有代表性的评估数据，应该覆盖正常样本、分布外样本、信息缺失样本、高风险边界样本、历史事故样本、不同时间窗口、不同模型版本和人工修改后样本。

校准不会让模型认识未知类别。它的价值是诚实表达：在当前评估范围内，这个判断大概有多可靠。

因此，生产输出最好把概率、证据质量和校准状态分层展示：

{
"decision": "manual_review",
"distribution": {
"auto_approve": 0.02,
"manual_review": 0.86,
"reject": 0.12
},
"confidence": 0.86,
"calibration": {
"method": "isotonic",
"evaluated_at": "2026-09-20",
"evaluation_range": [
"2026-06-01",
"2026-08-31"
],
"ece": 0.018,
"sample_count": 84200
},
"evidence": {
"retrieved_documents": 4,
"conflicting_signals": 1,
"missing_fields": ["device_risk"],
"state_hash": "sha256:9c8f…"
},
"fallback": "needs_more_context"
}

策略层看到的不应该只是“模型很确定”，而应该知道不确定来自哪里：分类本身不稳定、证据相互冲突、关键字段缺失、输入偏离评估集，还是当前概率尚未充分校准。不同原因理应触发不同动作，而不是一股脑丢给人工。

阈值也一样。它可以从错误成本、人工成本、校准质量和风险预算计算出来，但真实环境还要考虑类别先验、人工容量、政策约束和模型版本。核心原则是：阈值不是静态配置，而是业务代价、证据质量和模型可靠性共同产生的计算结果。

11. 自然语言不会退场，它只是不再独自承担执行责任

自然语言真正的优势不是词汇量大，而是组合能力强。它可以描述尚未进入枚举的新情况、多条件交织的例外、现有规则的反例、需求中的矛盾，也可以承担事故复盘、跨团队协商和新类别的初步命名。

受限判断则适合处理已经被命名、边界相对稳定、错误代价可以计算的问题。因此，合理系统并不是“开放模型对受限模型”二选一，而是：

开放模型：发现新情况、组织证据、生成候选
↓
人：定义语义、建立类别、决定责任
↓
受限模型：稳定判断、概率输出、可审计
↓
策略引擎：阈值、权限、预算、动作选择

自然语言从最终答案退居到类别定义、边界协商、长尾处理和事故解释。它没有被取消，只是不再一个人扛下全部执行责任。

新情况进入系统后，也不应该只做一次临时处理，而是形成发现到固化的闭环：开放模型发现长尾或冲突，人判断并归类，团队提出新的候选类别或拆分维度，再进行影子评估、契约设计、小流量灰度、错误与人工负担评估，最后决定正式发布或回滚。

这套闭环能够避免两种极端：过早类型化尚未稳定的概念，以及长期让人工处理已经稳定、高频的问题。接口演进的目标不是消灭自然语言，而是把已经稳定的不确定性转化为可计算、可路由的判断。

如果非要给“机器原生”一个工程上更有用的定义，它更像下面这样：

• 判断有固定 schema；
• 动作有权限边界；
• 不确定性有概率表示；
• 概率有校准依据；
• 决策有成本函数；
• 接口有版本和责任；
• 未知情况有逃逸路径；
• 执行结果可以审计和回放。

这不会让系统变成一台不需要人的“纯机器”，但可以让模型从“说什么就执行什么”，变成“提供判断，由策略层决定是否行动”。

12. 实验设计得再细一点，才不会被自己的假设说服

实验不只是为了证明想法正确，也为了给自己留一条退路。一个相对完整的验证框架，至少需要四组：

结果也不能只报一个总体准确率，至少要把总体准确率、类别准确率、高置信度与低置信度区间正确率、ECE、Brier score、P50/P95/P99、单任务成本、总成本、人工修改率、错误后果和逃逸口命中率拆开看。

更重要的是预先写下证伪条件：

• 如果准确率优势很小，但校准、尾部延迟、错误成本或人工负担明显更优，说明方向仍可能成立；
• 如果开放模型加 JSON Schema 和受限模型效果接近，说明主要收益可能来自结构化；
• 如果 schema 维护成本超过推理和人工成本，说明业务不适合完全类型化；
• 如果高置信度样本仍集中发生严重错误，说明概率不能直接承担高风险动作；
• 如果逃逸口命中率上升，却无法预测真实漂移，说明这个指标可能被滥用；
• 如果新版本阈值变化导致高风险动作激增，说明阈值必须随契约灰度。

没有证伪条件的项目，很容易把预期价值包装成已经验证的事实。

测试数据也建议按时间划分：历史窗口用于训练和校准，近期窗口用于验证，未来窗口用于最终测试。模型在未来窗口保持校准，只能说明在测试时间范围内表现尚可，不能推出永久可靠。上线后仍要持续观察实际正确率与预测概率的差距、other 和 uncertain 命中率、人工修改方向、输入长度、字段缺失、高风险动作频率、模型版本和政策版本。

最后，报告还应该区分模型层、系统层和组织层。模型层讨论判断是否正确、概率是否可靠；系统层讨论延迟、成本、自动执行和审计；组织层讨论维护成本、协调成本与责任。模型基准不能替代协议评估，协议使用量也不能替代生产实验，组织里的维护负担同样不能只用延迟和准确率解释。

13. 这些坑，工程里通常出现得比预期更早

过度分类会制造虚假精度。 把一个二元问题拆成二十个类别，并不会自动让决策更精细。类别过细可能导致概率分散、标注不一致、样本不足、下游难以消费，以及校准更困难。通常更合理的做法是分层：先判断能否自动执行，再在必要时做细分类。

高置信度不等于外部事实成立。 概率描述的是模型在给定输入、训练数据和评估范围内的判断，不证明客观事实。涉及资金、医疗、身份、司法和关键基础设施时，还需要证据引用、独立规则、权限审批、执行限额、人工复核和回滚机制。

低风险动作自动执行久了，系统容易失去可观测性。 一开始团队可能认真检查模型输出，连续跑顺几个月后，注意力就会下降。最好保留自动动作抽样复核、完整概率分布、字段突变监控、模型版本与业务结果关联，并为高风险动作保留双读机制。

全局统一 schema 会把旧问题重新制造一遍。 所有团队共享一份全局业务定义，会形成极强的隐式耦合。应该明确 owner、命名空间、领域边界、版本协商、兼容窗口、影子评估和双读迁移。契约注册表是领域接口目录，不是所有系统共同维护的全局语义本体。

14. 写在最后：真正变化的是接口，不是自然语言退场

Jev 的爆火，确实反映了一个真实需求：模型不再只是“回答者”，而可能成为软件系统中的一个判断模块。

但它不代表模型已经进入机器底层，也不代表自然语言会因此消失。更可能发生的是职责分层：

• 自然语言负责定义业务语义、处理长尾和协调异常；
• 模型负责解释状态、生成候选或给出受限判断；
• 结构化接口负责连接工具、服务和协议；
• 策略引擎负责权限、阈值和预算；
• 审计系统负责保存证据、状态和结果。

真正值得建设的，不是一种包打天下的统一语言，而是一套同时具备可验证、可演进、可拒绝能力的契约体系。

可验证，意味着输出、权限和证据能够审计；可演进，意味着 schema、模型、阈值和策略能够版本化；可拒绝，意味着未知输入可以表达不确定、请求更多上下文或转交人工。

类型契约的价值，不在于让模型少说话，而在于让模型承担它真正能够承担的判断责任，把剩余的不确定性交给更适合处理它的系统。

如果只留一句话，我会这样写：Jev 最值得借鉴的，不是“不聊天”，而是把模型的不确定性变成可计算、可路由、可追责的接口。

引用来源

[1] Model Context Protocol，Specification
https://modelcontextprotocol.io/specification/2025-11-25/

[2] Google，Core Concepts and Components in A2A
https://docs.google.com/document/d/1dIewhy5Dn17aXs8qGYrjkxkW-RpAAd2K8UpgfVZ1na8/

[3] AG-UI Documentation，State Management
https://docs.ag-ui.com/concepts/state