浏览器点击按钮、压缩编程会话、筛选训练数据、让无人机绕过障碍，这些任务出现在同一份 Jev 项目清单里，乍看很难归为一类。
仔细看各项目交给模型的输入，区别就清楚了。模型面对的通常是一小组按钮、几段工具输出、几个动作，或一个已经定义好的评分表。开发者预先处理了大量问题：哪些信息可见，哪些答案有效，哪些动作允许执行，服务超时后如何继续。
因此，读这二十个项目，比挑出一个“最强应用”更有价值的做法，是比较它们怎样划分模型与程序的职责。本文沿原清单核对了项目资料，并围绕候选、记忆、时间、证据和演示数据展开分析。以下没有安装实测或胜率排名，资料截止到 2026 年 9 月 23 日。
一、候选集合决定了模型能够成功到什么程度
jev-ultrafast 的默认循环把网页可操作元素组织成带编号的候选，让模型选择操作和对应目标。浏览器里的长页面，经过观察代码处理，变成了一个有限动作问题。
类似的做法也出现在 Blink 与 neo4jev 中。前者沿文件和目录名称分配探索路径，后者把图节点的出边交给模型选择。这些工具并没有要求模型一次性理解全部仓库或整个知识图谱。
有限选项让输出更容易使用，也会引入一个容易忽略的上限：正确答案必须先进入候选集合。
以代码定位为例。假设目标逻辑藏在一个名字毫无提示的文件里，路径筛选阶段没把它留住，后续模型即使在剩余候选中选得很准确，也无法找回被排除的正确文件。类似地，网页观察器漏掉一个自绘控件，决策模型再快也选不到它。
可以用一个简化计算说明：候选构造保留正确目标的比例是 90%，在正确目标存在时，模型选对的比例是 95%，则这两步联合成功率为 0.90 × 0.95 = 85.5%。这是条件概率的演示计算，不是任何项目的实测结果，也还没有计入执行失败。
因此，比较候选式系统时，至少要分别统计候选遗漏、选错目标和执行失败。只报告“模型在候选中有多准”，会掩盖前面的信息损失。
json-render 的 Jev 实验 提供了另一个例子：应用准备好组件实例、属性和可用动作，模型从中选择、排列与放置。未准备的文案和数据仍需要应用提供。组件树通过校验，说明它符合结构约束；页面是否完成用户想办的事，需要另外验收。
二、筛选上下文会改变后续判断的证据
把无关内容挡在上下文外，通常比等窗口装满后再压缩更直接。Winnow 就在工具结果进入上下文时工作，隐藏部分内容并留下召回入口。fast-jev-compaction 则在历史会话上决定哪些工具调用与结果继续保留。
两者都在影响后续模型看见什么。接入时需要同时考察“保留了多少信息”与“模型是否还能找到正确证据”。
设想一次排错：第一次读取的长日志里有一条不起眼的时区警告，当时正在检查网络连接，所以它被认为相关性很低。后来网络问题排除，时区警告成为关键线索。原始文本保存在磁盘上，只完成了恢复条件的一部分；Agent 还得知道有这一段文本、能拿到对应键，并愿意重新读取。
这个例子提示了一个不同于压缩率的指标：任务变化后，关键证据的恢复成功率。可以设计前半段任务与后半段追问，专门观察系统能不能恢复先前隐藏的信息。
还有数据来源问题。工具输出中的指令、报错和引用材料需要保持身份，不应因为被摘要进一句话，就变成了用户要求或已经核实的事实。更短的上下文可能读起来更顺，却也可能模糊证据来源。
TypeSafe 的 State 文档 将状态定义为供问题共同评估的材料，并说明当前 Jev 接受文本形式的状态。开发者把复杂环境整理成状态时，应保留来源与缺失信息，而不只追求长度。原始日志、工具结果、用户约束最好能追溯到各自记录。
三、模型答得快，还要在答案有效时执行
浏览器里，一次选择对应的是某个时刻的页面。模型还在返回结果时，列表可能刷新，弹窗可能出现。编号依然是 7，背后的对象却可能已经变化。
jev-ultrafast 将已观察的节点与执行绑定，并在动作前重新检查状态，这说明速度优化与状态一致性需要一起处理。直接把编号解释成“现在页面上的第七个按钮”，会丢掉原来观察所附带的含义。
可以给每次决策附上一个由应用记录的凭据：
{
"observation_id": "view-1042",
"candidate_set_id": "controls-1042",
"selected_target": "button-7",
"action": "click",
"expires_after_ms": 800,
"policy_version": "review-only-v1"
}
这是本文的设计示例，不是某个项目现成的 API。800 毫秒也只是占位值，实际预算由场景决定。执行器应核对观察是否仍有效、目标是否还是同一个对象，以及这次动作是否已经成功执行过。
Jev-drone 在仿真中把这个分工表现得更直观：高频控制与安全反射由代码承担，Jev 以较低频率提供战术判断。模型返回的“爬升”建议，还需要经过当前状态下的约束检查。它展示的是分层设计，不足以证明同一方案可以直接搬到真实飞行器。
typesafe-mario 从模拟器遥测与内存解析状态，再选择有限控制动作；OneVOneJev 在模型服务不可用时使用启发式回退。阅读这类项目，可以重点追问：模型等候期间，环境继续变化还是暂停？迟到答案会被丢弃还是照常执行？回退动作与模型动作是否使用同样的约束？
“一次请求并行问多个问题”也有时间上的前提。官方的 speculative fan-out 模式让多个问题共同读取当前状态，再由代码选用相关答案。若第二个判断必须观察第一个动作执行后的新页面，就不能靠提前并行提问得到那份新证据。
四、判断分数与完成证据需要不同的记录方式
一个审查工具可以说“这段改动看起来符合需求”，但只有实际运行记录能证明某条测试命令是否执行过。即使命令确实执行过，也还要核对它检查的是哪份代码。
jev-review 将风险、文件、证据和严重度组织成多个判断阶段；Canny 则记录事件，让确定性规则约束完成声明。前者帮助组织审阅注意力，后者提供一种把声明与执行记录对照的实现。
从中可以整理出两条独立记录：一条保存模型在给定材料上的判断，另一条保存工具实际做了什么。不要只留下一个总分或“通过”。
| 判断记录 | 执行记录 |
|---|---|
| 模型与问题版本 | 被检查的代码或数据版本 |
| 使用的证据标识 | 实际命令与目标环境 |
| 原始类别、分布或评分 | 开始、结束与退出状态 |
| 不确定与失败原因 | 输出存档及后续修改 |
这个区分同样适用于交易项目，但这里仅讨论软件结构。Prism 的 Jev 服务 将结果用于旁路记录与建议，现有确定性逻辑继续决定执行。这允许团队在不改变原策略行为的条件下比较两种判断。
注意限定范围：Jev 分支仅提供建议，不代表 Prism 整个程序没有执行交易的能力。判断模块的权限和应用的总权限，应该分别描述。
至于 killmyidea 这样的评分演示，最终分类由多维分数、权重和阈值计算而来。它能帮助整理讨论维度；一份看起来果断的结论，也可能只是权重配置的结果。若输入材料本来就缺乏用户需求证据，多个分项不会自动补齐这些事实。
五、演示、模拟与实测需要保留各自的名字
核对清单时，最值得修订的往往是一个形容词、一行版本号，或一个数字前面的限定条件。
例如，jev-curate 当前 README 把 24.0 行/秒标为单节点本地 mock 基准，将 1500+ 行/秒列为集群目标。这不能改写成真实 Jev 服务已经达到 1500 行/秒，也不能把 mock 的 24 行/秒当成服务端容量。
jarrodwatts/jev-trader 明确区分 mock 模型、真实模型、模拟成交和真实发送。看到一个持续跳动的看板，只能说明某条展示链路在运行；需要继续检查它消费的是哪一种数据和决策。
jev-codex-router 的 README 也限定了历史模拟节省数字的范围，说明它并非实际额度节省测量，亦不能用来证明当前策略。用旧策略回放得到的数字介绍新版本，会让读者误判证据。
json-render 则在官方 Jev 指南里注明相关 API 尚未发布，需要从源码构建。仓库中存在功能、在线演示能使用功能、稳定包已经发布功能，是三个需要分别核对的状态。
由此，一份项目比较表最好多出几列：运行模式、版本、输入规模、计时范围、失败样本、数据是否来自真实服务。没有这些字段，把所有数字排在一起，只会得到一张整齐但无法解释的排名。
怎样从项目清单里形成自己的试验
可以先给现有任务画出五个位置：观察材料、构造候选、请求判断、执行动作、验证结果。选一个项目时，明确它替换了哪一段，其他部分继续使用原实现。
比如研究检索，可以让新工具只重排现有候选，保存原始顺序作对照；研究上下文筛选，可以让它只标出“建议隐藏”，先不真的隐藏；研究审查，可以先把模型判断与已有人工记录放在一起看。这样发生变化时，比较容易追溯原因。
再设计几类故障：候选里没有正确答案、关键证据在上下文边缘、页面在模型返回前变化、API 返回错误、旧测试记录之后又发生修改。它们分别对应前文的候选、记忆、时间、服务与证据问题。
最后统计整个任务是否完成，以及失败在哪里。模型调用变便宜以后，我们更容易加入额外的判断；也更需要确认这些判断是否真的改变了结果。一次没有后续作用的评分，即使只花很少的钱，也会增加要维护的接口和日志。
这批项目值得阅读的共同原因，是开发者把复杂任务拆出了可观察、可比较的小决策。真正移植到自己系统里的，可以是一种候选构造办法、一条恢复路径，或一份绑定版本的完成记录。先把这些部分做清楚，再决定要不要更换模型。
延伸阅读：Jev 与 Laya：从置信度到自动决策的验收边界，讨论概率校准、风险阈值与模型裁判。