Jev 完整实战教程：用快速决策模型驱动浏览器、记忆与预测

开发工具2026-09-20约 14 分钟JevSystem One ModelAgent工程浏览器自动化Agent记忆概率预测模型路由

很多 Agent 并不需要模型写一段完整答案。它们更常需要一个很小、很快、可以直接交给代码执行的判断：应该点击哪个元素？这条消息是否值得长期保存？一条视频进入下一轮筛选的概率是多少？

Moritz Kremb 的 Full Jev Tutorial 用一支约 22 分 41 秒的视频，把这类问题从概念讲到三个可运行的方向：语音控制浏览器、AI 长期记忆筛选，以及 YouTube 内容预测。AYi_AInotes 随后发布中文解读，把这支教程推荐给正在做 Agent、浏览器自动化和成本优化的人。

本文将两条 X 帖子整理成一篇工程阅读笔记。重点不是复述“几百倍更快”之类的宣传语，而是理解一个更有普适性的分工：让快速决策模型处理有限选项、分数和概率，让通用大模型处理真正需要语言生成和复杂推理的部分。

视频时间轴

时间	内容	工程问题
00:00	Intro	Jev 要解决什么问题
00:34	Jev explained	为什么有限决策可以比自回归生成更快
04:06	API setup	如何把模型接入实际项目
05:59	Demo 1：Voice-controlled browser	语音指令如何驱动浏览器动作
11:33	Demo 2：AI memory	如何筛选值得长期保留的事实
17:27	Demo 3：YouTube predictor	如何批量返回结构化概率
22:41	视频结束	三类应用的共同抽象

这份时间轴来自 Moritz 原帖的公开章节。AYi 的帖子也按相同时间点概括了三个 Demo，但其中的“150 毫秒”“90%”“几毛钱”等数字应理解为解读帖或演示语境中的描述，而不是本文独立完成的基准测试。

一、Jev 不是更会聊天的模型

通用语言模型的默认输出是 Token 序列。即使任务只需要一个选项，它也可能先组织解释，再输出答案，最后由业务代码解析和校验。这个路径适合开放式写作，却不一定适合高频、低延迟的内部判断。

Jev 的切入点是把问题的答案空间预先定义出来，然后直接返回结构化决策。可以把它抽象成三类输出：

Choice：从有限选项中选择一个结果，例如当前应该点击哪个 DOM 元素。
Score：给一条内容、事实或候选项打分，例如这条对话是否值得写入长期记忆。
Boolean 或概率判断：判断一个命题是否成立，或返回各类结果的概率分布。

这并不代表 Jev 可以替代通用大模型，也不代表概率就是事实。它更像处在状态输入和业务代码之间的快速决策层：输入应当尽量结构化，输出应当有明确的类型和后续动作。

状态 / 事件
  → 声明问题与合法输出空间
  → Jev 返回 Choice / Score / Boolean
  → 代码校验结果与置信度
  → 执行、回退或人工复核

二、Demo 1：语音控制浏览器

视频第一个 Demo 把语音输入、浏览器状态和 Jev 的 Choice 结合起来。用户用自然语言描述目标，语音识别模块把连续语音切成可处理的片段；浏览器运行时提供当前页面的 DOM 或可访问性状态；Jev 再从当前有效动作中选择下一步。

一个合理的分层可以写成：

语音流
  → 语音识别与分段
  → 当前任务与页面状态
  → 动态动作空间
  → Jev 选择动作
  → 浏览器执行并回传新状态

这里最重要的不是把“点击按钮”描述成一段文字，而是把可点击对象变成有限集合。例如在一个表单页面中，当前动作空间可能只有：选择出发地、选择目的地、打开日期控件、提交搜索。策略模型只需在这个集合中选择，而不是从整张网页和所有工具中自由生成下一步。

DOM 优先，但不要迷信 DOM

标准表单、按钮、链接和下拉选项通常适合用 DOM 或 Accessibility Tree 表示。相比整张截图，这种状态更容易携带角色、名称、当前值、禁用状态和可操作参数。

但 Canvas、地图、复杂遮罩、视觉排序和 DOM 与画面不一致的页面，仍然需要截图或视觉模型。实际系统应该按状态类型选择输入：

结构化表单 → DOM / Accessibility Tree
视觉布局 → 截图 / 视觉模型
两者冲突 → 暂停动作，重新确认状态

语音不等于可以自动执行一切

语音入口只改变了用户表达意图的方式，并没有降低浏览器动作的风险。查询航班、筛选结果和打开页面可以是只读操作；提交表单、发送消息、购买商品和修改账户设置则必须进入确认流程。

只读查询       → 自动执行
可逆筛选       → 自动执行 + 状态校验
外部提交       → 明确确认
付款 / 删除     → 人工确认 + 幂等键 + 审计

三、Demo 2：给长期记忆做“脱水”

第二个 Demo 处理 Agent 记忆的常见矛盾：上下文越长，成本和检索负担越高；摘要做得过于激进，又可能把精确的偏好、约束和技术细节一起丢掉。

视频展示的思路不是让大模型每隔一段时间重写整份摘要，而是让 Jev 对新增消息做快速筛选或评分：这条内容是不是长期有价值？它是否属于用户偏好、稳定事实、工作规则或项目决策？如果不值得长期保存，就不进入持久化记忆；如果值得保存，则保留原文或进入后续更严格的写入流程。

新消息
  → Jev 判断重要性 / 类型 / 分数
  → 临时上下文继续参与当前任务
  → 低价值内容不写入长期记忆
  → 高价值内容保留原文并进入向量库或结构化存储

评分不是删除授权

这是把 Demo 变成生产系统时最需要补上的边界。一个 Score 只能表达模型判断，不应直接成为不可逆删除的唯一凭据。更稳妥的实现是把记忆分成多个状态：

状态	处理方式
`candidate`	保留原文，等待后续规则或人工复核
`accepted`	写入长期记忆，并记录来源与时间
`rejected`	默认不进入长期记忆，但保留短期会话上下文
`expired`	根据明确的保留策略清理

对于安全规则、付款信息、身份信息和用户明确要求“记住”的内容，不能仅靠模型分数决定是否保留。应当加入确定性规则、来源追踪、用户可见的删除入口和审计记录。

保留原文，避免摘要损失

AYi 的解读强调了“核心事实保留字面原文”的方向。这一方向有实际价值：长期记忆不一定需要重新生成一段漂亮摘要，很多时候更需要保存原始约束、配置值和用户的精确措辞。Jev 可以负责“是否值得进入下一层”，而不是负责重写所有记忆。

四、Demo 3：YouTube 概率预测器

第三个 Demo 把 Jev 放到批量内容筛选场景。它不要求模型为每条视频写一篇分析，而是对标题、描述、频道信息或其他结构化特征做快速判断，返回进入下一轮的概率或标签。

视频元数据
  → 批量构造统一输入
  → 并发执行多个判断
  → 返回概率 / Score / Choice
  → 按阈值分层
  → 少量候选交给通用模型深度分析

这是一种典型的两阶段架构：

第一阶段用低延迟、结构化的决策模型处理大规模候选集。
第二阶段只把高潜、边界或需要解释的样本交给通用大模型。
最终输出由业务规则、历史标注和人工抽检共同校验。

概率输出适合排序和分层，不适合直接当作“爆款保证”。要评估它是否有用，至少需要离线标注集、时间切分、校准曲线、精确率/召回率，以及不同频道和内容类型上的分层结果。

五、三个 Demo 的共同架构

表面上，浏览器、记忆和 YouTube 预测是三个不同产品；从工程角度看，它们都把“大模型写答案”改成了“模型做有限决策”。

场景	输入状态	Jev 输出	后续系统
浏览器控制	DOM、任务、可用元素	`Choice`	浏览器执行器
记忆筛选	新消息、记忆规则	`Score` / 标签	记忆存储与生命周期
YouTube 预测	视频特征、预测目标	概率 / `Score`	排序、筛选、深度分析

可以把通用模型放在需要语言能力的地方，把 Jev 放在需要大量、快速、可校验判断的地方：

用户目标 / 业务规则
  → 状态标准化
  → 快速决策层
  → 阈值、策略、权限和幂等校验
  → 通用模型深度处理或确定性执行
  → 结果、成本、延迟和人工接管记录

六、接入时不要只复制 API 示例

Moritz 视频在 04:06 展示了 API setup，但本文不复述未在公开帖子中完整呈现的代码。真正接入时，需要先确认当前 SDK 或网关文档中的模型 ID、认证方式、请求结构、返回类型、错误码和计费口径。一个抽象的调用契约应至少包含：

type DecisionRequest = {
  state: unknown
  question: string
  output: "choice" | "score" | "boolean"
  options?: string[]
  threshold?: number
}

type DecisionResult = {
  value: string | number | boolean
  probabilities?: Record<string, number>
  model: string
  latencyMs: number
  requestId?: string
}

生产代码还应该保存：模型 ID、输入版本、状态版本、调用耗时、重试次数、回退路径、费用估计和最终人工结果。否则，出现误点击、记忆误收录或预测偏差时，无法判断问题来自状态抽取、模型判断、阈值设置还是执行层。

七、哪些数字可以引用，哪些不能直接承诺

AYi 的帖子用“150 毫秒”“输出 Token 免费”“上下文消耗降低 90%”“整个大盘几毛钱”等数字突出 Jev 的潜力。它们可以作为原帖观点和演示线索，但不能脱离实验条件直接写成 GPT88 或任何生产系统的性能保证。

至少要区分四种证据：

视频章节：证明视频讨论了哪些 Demo，不证明所有任务的平均性能。
单次演示：证明某次运行发生过，不证明成功率、P95 或稳定性。
作者转述：保留归属，不等同于独立复测。
工程基准：需要公开脚本、固定数据集、重复次数、失败定义和完整成本口径。

建议用下面的指标重新测量自己的系统：

{
  "task_id": "memory-filter-001",
  "success": true,
  "elapsed_ms": 150,
  "fallback_count": 0,
  "retry_count": 0,
  "estimated_cost": 0,
  "human_takeover": false
}

不要只记录平均值。浏览器自动化应记录 P50/P95、动作失败率和页面变化后的恢复率；记忆系统应记录误收录率和误丢弃率；预测器应记录校准误差、不同数据切片上的精确率/召回率，以及阈值变化对人工审核量的影响。

八、落地检查清单

已定义每个决策的合法输出空间和 unknown / 人工复核路径。
浏览器动作包含目标元素、参数、状态版本和风险等级。
记忆评分不会直接授权不可逆删除。
用户明确要求保留的内容有确定性规则保护。
概率输出经过标注集和时间切分验证，而不是只看演示结果。
通用模型与快速决策模型的职责、回退条件和成本上限已版本化。
付款、发送、删除、发布和权限修改默认需要确认。
记录模型 ID、request ID、延迟、费用、重试和人工接管。
基准测试覆盖标准路径、页面变化、异常输入和服务不可用。

来源与边界

原始教程：Moritz Kremb｜Full Jev Tutorial。公开章节为：00:00 Intro、00:34 Jev explained、04:06 API setup、05:59 Voice-controlled browser、11:33 AI memory、17:27 YouTube predictor。

中文解读：AYi_AInotes｜Jev 完整实战与三个 Demo。

本文保留了两条帖子的主题、时间轴和三个应用方向，并将视频/解读中的观点与本文新增的工程建议分开。文中关于 150 毫秒、90% 和成本的描述属于 AYi 帖子的转述或演示语境；本文没有把它们当作独立基准，也没有声称 GPT88、Jev 或 Browser Agent 在所有数据和网页上都能达到这些结果。API 类型、状态机、风险门禁和评测指标是面向工程落地的整理，不是对 Moritz 视频内部实现的逐行还原。