Qoder × Jev：重新思考 Agent 如何判断和行动

Qoder 正在探索一种新的 Agent 分工：生成模型负责理解、规划，Jev 这类 System One 判断模型负责高频、边界明确的语义判断，Harness 负责权限、执行、验证与回退。本文以 Jev 为切口，介绍 Qoder 在 Agent Harness 中的相关探索，以及 Auto Mode 和浏览器自动化两个代表性案例。

Jev 为什么突然火了？

9 月 15 日，TypeSafe AI 发布了 Jev 后，很快在 AI 开发者社区里掀起了一轮密集的讨论热潮。

大家没有停留在讨论模型参数或排行榜，而是迅速用 Jev 完成各种真实、甚至有些出人意料的实验 Case：分析广告、筛选内容、压缩 Agent 上下文、控制浏览器、选择工具，甚至实时玩游戏。

一个刚刚出现的模型，为什么会让开发者如此兴奋？先看两个在社区广泛传播的案例。

1.1 社区案例1：使用 Jev 在 40 秒内分析完 724 条广告

Jev 发布后，一个很快出圈的实验来自开发者 Matthew Berman。

他拿来 37 个品牌正在投放的 724 条广告，让 Jev 逐条判断：开头用了什么 Hook、广告是什么形式、给出了什么 Offer、CTA 是什么、用户处在哪个认知阶段，广告和落地页是否一致。

他没有让模型为每条广告写一篇分析报告，而是把分析拆成一组固定问题。按照开发者公布的数据，Jev 在约 40 秒内完成了 8724 次判断。

1.2 社区案例2：在跑酷游戏里，使用 Jev 实时控制角色避障

另外一个出圈的实验，是使用 Jev 在跑酷游戏中通过连续判断来实时操控角色。

如下图所示，画面里的角色在铁轨上向前冲，障碍物不断出现。程序把当前游戏状态交给 Jev，让它从跳跃、下蹲、左移和右移中选一个动作；动作执行后，新的状态再次送入 Jev，然后继续选择。

它不需要先规划完整的一局，也不会生成一长段操作脚本。每一次，它只回答一个很小的问题：现在该往哪走？就是这样一个简单循环，让角色能够持续躲开迎面而来的障碍。

广告分析和跑酷游戏看起来毫无关系，但它们背后其实是同一种工作方式：即把复杂环境整理成当前状态和有限候选，再让模型快速回答“现在应该选什么”。

1.3 所以，Jev 到底是什么？

Jev 是 TypeSafe AI 推出的一种 System One 模型。

它不是另一个聊天机器人，也不是一个更擅长写代码的大模型。和擅长生成文本、代码与方案的通用模型不同，Jev 专门处理判断问题：应用告诉它当前发生了什么、需要判断什么，以及有哪些候选答案；它不生成长篇回复，而是返回软件可以直接使用的选择、评分或概率。

如果说通用大模型更像负责理解、思考和表达的大脑，Jev 更接近一个专门处理判断的“反射系统”。

这也解释了 Jev 为什么会迅速受到关注。它带来的不是一个更会聊天的模型，而是一种把语义判断直接放进软件运行循环的新方式。

社区随后出现的工具路由、上下文筛选、浏览器操作和 Agent 结果检查等实验，都在继续扩展同一条思路。

从社区 Demo 到 Qoder Agent Harness

广告分析和跑酷游戏，让 Jev 的特点变得非常直观：它适合进入一个持续运行的系统，在每个关键节点，根据当前状态完成一次边界明确的判断。

回到 Agent，这种需求其实更加密集。Agent 的每一次工具调用、状态变化和任务推进，都可能带来新的判断问题。

这也是 Qoder 开始实践 Jev 的原因。我们已经将它引入 Agent Harness，并选择 Auto Mode 和浏览器自动化两个典型场景进行技术实验：一个关注“当前动作能否自动执行”，另一个关注“面对当前页面，下一步应该做什么”。

在具体介绍这两个实验之前，需要先回答一个更基础的问题：为什么 Agent 需要重新设计它的判断机制？

Qoder 的判断：Jev 可能成为 Harness 的新判断层

3.1 Agent 的瓶颈不只是生成能力

一个 Agent 在完成长任务时，不只是在理解需求和生成内容。它还需要沿着任务轨迹不断判断：

• 当前动作是否安全，是否需要用户确认？
  
• 下一步应该调用哪个工具、Skill 或模型？
  
• 当前操作是否正在推进目标？
  
• 页面是否已经进入预期状态？
  
• Agent 是否陷入循环或偏离任务？
  
• 任务是否真正完成，结果是否需要复核？

今天，这些判断大多隐藏在主模型的推理过程中。主模型既要理解和规划，也要同时完成路由、分类、状态识别和结果检查。

这让我们开始重新思考：其中一部分高频、候选有限、结果需要直接进入软件分支的判断，是否可以从主模型的完整推理中拆出来？

3.2 重新划分生成、判断和执行的职责

Qoder 并不把 Jev 看作另一个可以替换主模型的新模型。

我们更关心的是，它能否成为 Agent Harness 中一个新的系统角色：将一部分原本隐藏在主模型推理中的判断拆出来，变成可以独立设计、观察、测试和优化的能力。

这套分工可以概括为：生成负责解决开放问题，Jev 负责边界明确的语义判断，Harness 负责把判断变成受控行动。

不过其中最重要的边界是：Jev 判断，Harness 授权与执行。Jev 本身并不拥有权限；它可以选择浏览器的下一步候选动作，但它不直接控制浏览器；它可以认为任务已经完成，但这个判断不能替代对真实结果的验收。

在 Qoder 的架构中，判断模型提供的是语义信号。确定性规则、用户授权、执行前检查和结果验证，仍然由 Harness 负责。

Qoder 如何实践：从 Auto Mode 到浏览器自动化

我们首先选择了两个性质不同、但都需要高频判断的场景：Auto Mode 和浏览器自动化。

这两个实验的流程并不相同，但遵循同一个原则：Harness 决定什么时候需要判断、提供哪些候选，以及判断结果如何被使用；Jev 只回答事先框定的问题。

图1:Harness 判断模型

每个场景中，Jev 的判断结果如何落地，由 Harness 按该场景的规则决定：Auto Mode 落到放行或阻止，浏览器自动化落到执行、重新观察或交回主 Agent。

4.1 Auto Mode：用 Jev 判断操作能否自动执行

Coding Agent 在完成一个任务时，会不断读取文件、修改代码、运行命令和调用外部工具。每一步都询问用户，Agent 会变得迟钝；所有动作都默认放行，又会带来不可接受的风险。

因此，Auto Mode 真正要解决的并不是“如何执行”，而是：面对当前动作和上下文，什么时候可以自动执行，什么时候必须停下来？

Qoder Harness 已经拥有一套确定性的权限规则。目标和影响明确的常规操作，可以由规则直接允许；触及明确限制的动作，可以直接阻止。只有规则无法覆盖、必须结合用户要求和操作语义才能判断时，才进入模型判定。

原有链路由通用 LLM 完成这一环节：先进行快速判断；没有获得放行的动作，再进入更深入的复核。

在这项实验中，我们只替换了中间的语义判断环节。Harness 先整理判断所需的状态，Jev 再通过一次结构化选择返回“允许”或“阻止”，最终结果仍由 Qoder Harness 落实。

图2：Auto Mode 判断链路

当前 Jev 提示词中的固定规则，可归纳为以下几类：

用户也可以补充自己的规则。通过用户级配置，用户可以描述通常允许的操作、需要谨慎处理的操作，以及工作环境。这些信息作为判断参考，在统一安全边界内适应不同工作习惯；它们不是强制放行指令，不能覆盖硬拒绝策略或已有权限限制，仓库文件也不能自行注入这些规则。

例如，在用户级 settings.json 中合并以下 autoMode 配置，即可补充个人工作约定（示例仅展示自定义规则，不包含模型接入配置）：

{
  "autoMode": {
    "allow": [
      "允许运行项目已有的构建、测试和代码格式检查命令。"
    ],
    "soft_deny": [
      "未获得本次明确授权时，不要发布软件包或修改生产服务。"
    ],
    "environment": [
      "本地 tmp/demo-output 目录只存放可重新生成的演示产物。"
    ]
  }
}

引入 Jev 之后，我们围绕文件操作、代码推送、软件包发布及生产资源操作等场景，对 Jev 与原有 LLM 权限判定链路进行了多轮对照，在自建测评中，两种方案的效果接近，但是 Jev 简化了模型判定过程。平均权限判定耗时从 3.13 秒降至 0.53 秒，减少约 83%。 在双方均通过的同案例、同轮次任务中，任务平均耗时也减少了约 18%。

这些结果初步显示，专用判断模型在接近现有任务表现的同时，简化判定流程、减少执行等待，并为降低判定成本提供空间。

4.2 浏览器自动化：用 Jev 选择下一步页面操作

浏览器自动化真正困难的，往往不是“能不能点击页面”，而是：在当前状态下，下一步应该做什么。

一个简单的“搜索浏览器自动化”任务，实际会被拆成一系列连续判断：哪个输入框是目标？输入完成后应该点击搜索，还是选择自动补全？页面是否仍在加载？结果出现后，是继续操作，还是已经可以结束？

我们正在用 Jev 探索这类局部决策问题。主 Agent 只需要给出目标，browser-use 插件读取当前页面的 URL 和 AX 无障碍树，并将可交互元素整理成有限的动作候选。Jev 不直接生成任意脚本，而是在这些候选中选择下一步，例如点击、输入、滚动，或者返回 WAIT、DONE、REVIEW、BLOCKED。

如下是 Qoder Browser Use 的 Node REPL（即让 Agent 根据当前任务，动态生成 JavaScript 代码来控制浏览器）生成的一次代码决策示例：

var decision = await tab.jev.decide({ goal: 'Scroll down to see more search results' });
nodeRepl.write(decision);

如下是一个复杂场景的任务示例，把「一个带可见完成条件的单步操作目标」整体委托给 Jev：

var { createBrowserAgent } = await import('browser_agent');
var agent = await createBrowserAgent();

var result = await agent.run({
  goal: "Submit a Google search for 'ai coding' and wait until the results page is displayed",
  url: 'https://www.google.com/',
  inputs: { searchQuery: 'ai coding' },
});
nodeRepl.write(result);

整个过程形成一个简单的闭环：观察页面 → 生成候选 → Jev 选择动作 → 本地校验并执行 → 重新观察。

这里一个重要设计是把“决策”和“执行”分开。Jev 负责回答“下一步做什么”，Harness 负责回答“这个动作现在是否还能执行”。在动作真正派发之前，本地会再次检查 URL 和页面状态是否已经变化；如果观察已经过期，就重新进入决策，而不是继续执行旧动作。同时通过最大步数、运行时间、无进展检测和取消机制，避免 Agent 陷入无限循环。

图3：浏览器自动化闭环

这个实验关注的并不是让 Jev 接管整个浏览器 Agent，而是把一个更小、更清晰的问题交给它：在目标已经明确的情况下，能否持续完成“下一步做什么”的判断，并在不确定时及时停下来。

这也是我们接下来想验证的核心：哪些浏览器局部决策可以由 Jev 连续完成，哪些情况仍然应该交回主 Agent 或用户。

接下来：构建更完整的 Agent 判断机制

本文展开的 Auto Mode 和浏览器自动化，只是 Qoder 整体探索中的两个代表性切面：一个发生在动作执行之前，一个发生在任务运行过程中。它们用于说明判断模型如何进入真实 Agent 链路，而不是列举这条路线的全部工作。

我们更关注的，是围绕 Agent 判断建立一套完整的系统机制，包括判断边界、上下文组织、判断结果执行、可观察、可验证和可回退等。

这些工作共同指向的是一个更基础的系统问题：Agent 能否形成一套清晰的判断机制，让生成模型、专用判断模型、确定性规则和用户，在各自适合的位置上协作？

Jev 为 Agent Harness 提供了一种新的可能，但它不是所有判断问题的答案。真正重要的，是 Harness 能否理解每种能力的边界，并把模型判断转化为可控、可验证的系统行为。

本文只展开了其中两个场景。Qoder CLI 正在围绕判断边界、上下文组织、执行控制、验证与回退持续推进相关探索，并完善生成、判断、规则、执行和人之间的协作方式。

而 Harness，正是这种新分工真正发生的地方。