Jev放开之后，Agent开始分工

Jev突然放开候补名单，给新用户赠送1.2亿Token，输出还不收费。紧接着，社区里出现了一批速度夸张的Demo：语音助手、浏览器自动化、表单填写，甚至和另一个大模型组队，在《我的世界》里用8分43秒击杀末影龙。

这些演示很容易把注意力带到"又一个更快的模型"上。但真正值得关注的地方，可能没那么热闹：Jev被设计成了一个专门做判断的模型。它不负责长篇解释，也不试图独自包办整个任务，而是把选项、评分、概率或下一步动作快速交给程序执行。

这意味着Agent的组织方式正在发生变化。一个模型负责想清楚目标，另一个模型负责在瞬间做选择，确定性的代码负责把动作真正落地。Minecraft只是一个足够直观的实验场。

一、Jev的关键变化：把输出压缩成判断

根据TypeSafe AI公布的信息，Jev取消了候补名单，新用户注册后可以获得5美元额度，官方折算为1.2亿Token。输入价格约为每百万Token 0.042美元，输出则免费。

这里的"输出免费"需要准确理解。它并不代表模型不消耗计算资源，而是产品计费策略针对Jev的输出形态做了特殊设计。

传统大模型通常返回一段自然语言：

我建议先打开备忘录，然后创建一条新的记录......
​

Jev更像是在返回一个严格受限的决策结果：

{
  "action": "open_notes",
  "confidence": 0.97
}
​

或者：

{
  "next_action": "attack",
  "target": "ender_dragon",
  "score": 0.91
}
​

输出内容短，结构固定，调用频率却可以很高。模型不需要花大量Token解释自己为什么这么判断，程序也不需要从自然语言中猜测下一步该做什么。

这类模型的价值，主要来自三个特征：

• 低延迟：适合频繁调用和实时交互；
• 结构化输出：结果可以直接进入程序控制流；
• 低单位成本：适合大量细粒度判断。

它更接近Agent系统里的决策函数，而不是一个面向用户的聊天窗口。

当然，Jev并非只能输出单个按钮。评分、概率、分类、风险判断、工具选择，都可以纳入这类能力。关键在于，输出空间需要被提前定义，结果能够被后续程序可靠消费。

二、8分43秒屠龙，靠的是三层系统

Jev和GPT-6 Astra组队完成《我的世界》末影龙挑战，最容易被忽略的细节，是这次任务并没有让某一个模型负责所有操作。

按照开源代码和相关报告，这套系统大致拆成三层：

1. Astra负责高层规划

Astra承担的是相对复杂、低频的任务，例如：

• 当前处于哪个阶段；
• 是否需要寻找村庄或补给；
• 什么时候进入下界；
• 如何准备床、铁镐等资源；
• 什么时候执行末影龙攻击；
• 当前计划是否需要调整。

这类问题需要结合较长上下文进行推理，涉及目标拆解、资源管理和失败恢复。它不适合每几十毫秒调用一次。

2. Jev负责局部决策

Jev处理的是执行过程中的快速判断：

• 选择哪一个动作；
• 是否继续沿当前路线移动；
• 是否躲避龙息；
• 是否满足攻击条件；
• 当前目标是否还在安全范围；
• 遇到风险时是否中止动作。

这些判断的输入通常是当前游戏状态和候选动作集合，输出可以是一个动作、一个评分或一个概率。

3. 代码负责确定性执行

真正操作游戏角色的部分，仍然由程序完成。

例如"定时床攻击"这个动作，并不是模型直接控制每一个键盘事件，而是代码负责：

1. 放置床；
2. 调整瞄准方向；
3. 检查末影龙位置；
4. 检查玩家与掩体条件；
5. 满足条件后引爆；
6. 发现危险时中止动作。

模型只需要决定是否选择这个动作，以及在关键节点上做判断。每个动作内部的机械流程由执行器完成。

这是一种很典型的Agent工程分层：

• 模型负责不确定性；
• 程序负责确定性；
• 环境负责提供状态和反馈。

如果让大模型直接控制每一次按键，延迟、成本和错误率都会迅速上升。更麻烦的是，模型一旦卡在某个动作上，整个任务可能都会停下来。

三、规划和行动为什么要异步

Minecraft案例里最有价值的技术细节，是规划器和动作循环没有完全串行化。

报告提到，规划器默认大约每15秒检查一次更新，阶段变化也可以触发刷新。第一次计划生成后，动作控制循环可以继续按照已有计划执行，而不必每完成一个小动作就等待Astra重新思考。

这可以抽象成两个并行循环：

如果规划和执行完全串行，系统会变成：

观察状态
→ 调用大模型
→ 等待返回
→ 执行动作
→ 再调用大模型
​

每一步都要承担模型延迟。一次动作可能只需要几十毫秒，但规划模型可能需要几秒，最终画面就会变得卡顿。

异步设计则允许系统在已有计划下继续推进：

高层计划：寻找村庄 → 准备资源 → 进入末地 → 攻击末影龙

当前执行：沿路线移动、躲避攻击、调整位置
​

只要长期目标没有发生变化，底层控制就可以继续工作。等规划器发现阶段变化、资源不足或风险上升时，再更新计划。

这也是报告中提到的131次Jev决策和35次Astra调用能够共同完成任务的原因。模型调用次数不等于动作次数，流畅的画面也不意味着每一帧都由模型决定。

四、8分43秒背后的工程含义

8分43秒击杀末影龙当然很有传播力，但单看这个数字，很容易把注意力带偏。

它至少包含四个变量：

• 模型决策质量；
• 游戏状态读取方式；
• 工具和执行器实现；
• 失败尝试与策略调整。

如果Agent可以读取游戏中的结构化状态，相当于获得了比普通玩家更完整的观测能力。它知道坐标、资源、敌人位置和环境条件，行动方式自然不同于只依靠视觉和经验的人类玩家。

此外，最终成功也可能建立在此前失败尝试的基础上。相关讨论提到，Agent能够读取测试过程中的状态信息，这与测试时训练或Test-Time Training的思路有些接近：失败不会完全丢失，后续尝试可以吸收之前的经验。

这带来一个重要区别：

• 一次成功运行，说明系统具备完成任务的可能；
• 大量重复运行仍然稳定成功，才说明系统具备工程可靠性。

对于Agent系统，平均耗时和单次最低耗时都不够。还需要观察：

• 成功率；
• 失败类型；
• 平均重试次数；
• 任务成本分布；
• 极端状态下是否能够安全退出；
• 环境变化后是否还能泛化。

所以，0.97美元完成一次挑战很吸引人，但它更像一次系统演示，不能直接推导出所有复杂任务都能以类似成本完成。

五、Jev更适合嵌入Agent的边界位置

Jev真正可能产生生产价值的地方，不一定是游戏，而是各种需要大量"小判断"的工作流。

上下文压缩

Agent运行时间一长，上下文会不断膨胀。传统做法通常是让主模型写一段摘要，把旧消息压缩成新的上下文。

这种方式的问题很明显：

• 摘要可能遗漏关键细节；
• 原始工具结果被改写后难以恢复；
• 每次压缩都需要消耗较多Token；
• 摘要质量会影响后续所有判断。

fast-jev-compaction采用了另一种思路：把上下文整理拆成多个判断。

例如：

这次工具调用的结果，后面还需要吗？
如果需要，保留全文还是保留关键字段？
这条历史消息是否已经失去价值？
该结果是否可以安全截断？
​

Jev只负责判断保留、截断还是删除，具体的上下文修改由代码执行。

这种方式的好处，是可以尽量保留原始用户消息和关键工具结果，减少摘要模型对事实的二次改写。

对应的开源项目：

GitHub - tamaratran/fast-jev-compaction: Claude Code plugin that replaces the compaction summary with Jev decisions: every tool call and result is scored in one fast request, stale ones are dropped or truncated, everything kept stays verbatim. · GitHub

但这里也有边界。如果系统无法明确判断一段上下文的未来用途，过早删除可能造成隐性损失。生产环境中通常需要保留可恢复机制，例如原始消息归档、压缩决策日志和回滚策略。

Agent评测

LangChain公布的Jev-as-a-Judge实验，也体现了同样的方向。

在固定样本上，不同模型对Agent输出进行反复评分。Jev被用于判断答案是否满足规则、是否完成任务、是否存在错误。

这类任务通常不需要长篇解释，更关心稳定的结构化结果：

{
  "pass": true,
  "score": 4,
  "reason_code": "complete_and_relevant"
}
​

评测系统的成本和稳定性很重要。一个评估模型如果每次评分都给出不同结论，或者为了几百个样本消耗大量Token，整个评测流程就很难规模化。

工具调用与模型路由

Agent面对多个工具时，可以先让Jev做一层快速判断：

• 当前请求是否需要调用工具；
• 哪个工具最合适；
• 工具参数是否存在明显风险；
• 是否需要升级到更强的主模型；
• 当前回答是否需要人工确认。

模型路由也是类似逻辑：

简单分类 → Jev
结构化提取 → Jev
高风险决策 → 主模型或人工审核
复杂规划 → Astra等推理模型
​

这会把一次大模型调用拆成多个更小的判断节点，整体成本可能下降，系统响应速度也更容易控制。

但前提是路由规则本身足够可靠。路由模型判断错了，后面即使接入再强的主模型，也可能从一开始就走错路径。

六、真正的成本不只在Token

Jev的价格确实有吸引力，但做技术选型时，不能只看每百万Token多少钱。

一个完整Agent的成本至少包括：

成本项	需要关注的问题
模型调用	输入Token、调用次数、重试次数
系统延迟	单次判断耗时是否影响用户体验
执行器	工具、浏览器、沙箱、游戏环境的运行成本
失败恢复	判断错误后是否需要重新规划
观测与审计	是否能追踪每次决策依据
人工兜底	高风险操作是否需要审核
服务稳定性	限流、宕机、配额和可用区问题

尤其在实时Agent里，模型成本有时并不是大头。浏览器、云主机、数据库、向量检索、截图和视频流，可能才是主要资源消耗。

另一个容易被忽略的问题是，低延迟模型往往需要更严格的输入约束。输入状态不完整、字段含义不稳定、候选动作定义不清楚，都会让模型的快速判断失去意义。

Jev擅长的是：

• 状态边界清晰；
• 候选项有限；
• 输出格式固定；
• 错误可以检测和恢复；
• 判断频率较高；
• 对长文本解释要求不高。

它不适合直接承担：

• 开放式产品设计；
• 长链路技术方案论证；
• 没有明确状态空间的复杂决策；
• 高风险且不可回滚的业务操作；
• 需要强事实核验的最终结论。

可以把它放在决策链中，但不应该因为它便宜，就让它成为所有决策的默认入口。

七、Agent正在从单模型走向分工协作

过去的Agent设计，很容易形成一种单体结构：

用户请求
→ 一个大模型
→ 工具调用
→ 一个大模型
→ 最终结果
​

这种方式开发简单，早期验证也快。但随着任务复杂度增加，模型会同时承担规划、记忆、工具选择、动作控制、结果评估等多个职责。

职责越多，系统越难调试。一个错误发生后，很难判断到底是：

• 目标理解错了；
• 计划拆解错了；
• 工具选择错了；
• 上下文丢失了；
• 动作执行错了；
• 结果评估错了。

Jev这类模型带来的启发，是把Agent拆成多个决策边界：

每个环节可以选择不同能力、不同成本的模型。

复杂推理交给高能力模型，局部选择交给低延迟模型，机械动作交给代码，风险动作交给人工。这种架构并不新，但过去模型的延迟和成本让它很难大规模落地。现在，低价、低延迟、结构化输出的模型开始把这条路重新推到工程现场。

真正值得观察的，不是Jev能否在某个Demo里跑得多快，而是它能否稳定嵌入生产系统：

• 是否有清晰的决策协议；
• 是否能追踪每次选择；
• 是否支持失败重试；
• 是否能对错误判断进行隔离；
• 是否能在模型不可用时降级；
• 是否有足够的数据验证决策质量。

如果这些问题没有解决，Agent只是从一个大模型变成了几个小模型，复杂度并不会凭空消失。

Jev开放后引发的这轮实验，价值就在于它把一个长期存在的工程问题摆到了台面上：复杂任务是否必须由同一个模型从头做到尾？

Minecraft给出的答案很直接。高层规划可以持续更新，动作选择可以快速判断，具体执行交给程序，系统依靠环境反馈不断修正。

这套思路不会自动让Agent变得可靠，但它让可靠性有了更清晰的落点。模型不必承担所有工作，工程系统也终于可以围绕不同类型的智能能力重新分层。

从这个角度看，Jev的意义不只是一次免费额度活动，也不只是一个"哑巴AI"的传播标签。它更像是在提醒开发者：当模型开始进入实时工作流，决定系统上限的，往往不再是单个模型会不会长篇推理，而是团队能否把规划、判断、执行和恢复设计成一条可控的链路。