从点击一个按钮，到控制一个机器人，AI 的执行能力究竟需要跨越哪些技术门槛？

一、AI 不只要会回答，还要能够真正做事

如果说过去几年大模型竞争的核心是理解、推理和生成，那么随着 AI Agent 的发展，一个新的问题正在变得越来越重要：

AI 不仅要知道应该做什么，还要能够在真实环境中把事情做好。

让 AI 写一篇文章、总结一份报告，本质上主要是在信息空间中生成内容。但如果要求 AI 打开浏览器、操作软件、完成业务流程，甚至控制机器人，就完全是另一类问题了。

例如：

在网页中找到正确的按钮并提交表单；

在企业系统中完成订单处理和数据录入；

根据用户目标，自动调用多个工具完成复杂任务；

通过摄像头理解环境，并控制机器人抓取、移动和操作物体。

这些任务有一个共同点：AI 的输出不再只是文字，而是需要通过某种动作影响外部环境。

这也意味着，评价 AI 能力的标准正在发生变化。过去，我们经常关心模型回答得是否准确、内容是否流畅。

现在，我们还必须关心：

它能否正确理解当前环境？

它能否选择正确的动作？

它能否把动作真正执行出来？

当环境发生变化时，它能否及时调整？

它能否判断任务是否真正完成？

失败之后，它能否恢复，或者安全地交给人？

这些问题共同构成了 AI 执行能力的核心。也可以把它概括为一个更尖锐的判断：

执行能力 = 感知可观测性 × 决策正确性 × 执行可靠性 × 反馈验证能力 × 治理与恢复能力。

任何一项接近零，整体执行能力都会大打折扣。模型只是其中一个乘数。

为了理解这场变化，我们可以将 AI 执行能力放到四个具有代表性的战场中观察：软件操作、RPA、Agent 工具协作，以及 VLA。

需要先说明一点：这四个战场不是互斥分类，而是沿“数字/物理、固定流程/开放任务、界面交互/连续控制”等维度选取的四类代表性执行场景。它们之间会有重叠——一个企业 Agent 可能同时使用 RPA、业务 API 和软件操作；一个机器人系统也可能由高层 Agent 规划、再由 VLA 或专用控制器执行。分类的意义在于暴露不同执行环境下的核心难点，而不是给系统贴标签。

它们面对的环境不同，但都在尝试解决一个共同问题：

如何让 AI 将目标转化为可靠的行动？

二、战场一：软件操作——AI 如何真正使用电脑？

1. 从生成代码，到直接操作软件

最直观的 AI 执行场景，就是操作电脑和软件。例如，我们告诉 AI：

打开浏览器，进入指定网站，查找某个产品的价格，并将结果保存到表格中。

传统的聊天模型可以告诉我们应该怎么做，甚至可以生成自动化脚本。但真正的电脑操作 Agent，需要自己完成整个过程。它可能需要：

打开浏览器；

进入目标网站；

识别页面中的搜索框；

输入关键词；

读取搜索结果；

找到目标信息；

打开表格软件；

填写数据并保存文件。

这已经不是单纯的文本生成，而是一个持续与软件环境交互的过程。

2. 软件操作为什么比看起来更难？

软件界面并不是完全稳定的。同一个按钮，可能因为窗口大小、页面布局、弹窗或者加载状态而出现在不同位置。如果 Agent 仅仅记住某个按钮的坐标，就可能在界面变化之后操作失败。

因此，软件操作 Agent 通常需要解决三个问题。

第一，感知当前界面。系统需要知道页面中有哪些元素、它们处于什么状态，以及哪些元素与当前任务相关。可采用的技术包括 DOM 解析、可访问性树、界面结构识别和视觉理解等。实践中，更可靠的做法往往是混合路线：结构化信息可用时优先用结构化信息，缺失时再用视觉理解补足。

第二，将任务转化为具体动作。例如，将“提交申请”转化为查找目标表单、填写字段、检查内容和点击提交等操作。

第三，根据执行结果进行反馈。点击按钮之后，系统需要判断页面是否发生预期变化，而不能默认点击动作已经完成目标。

因此，一个典型的操作闭环可以表示为：

3. 软件操作的核心瓶颈是什么？

软件操作的关键，不只是让模型生成更准确的动作，还包括如何让动作与环境状态保持一致。

当界面结构稳定时，DOM、可访问性树或明确的 API 往往能够提供可靠的操作依据。当界面缺少结构化信息，或者需要处理复杂的视觉场景时，视觉感知就可能变得更加重要。这意味着，软件操作并不存在一种适用于所有场景的唯一技术路线。

软件操作的真正挑战，是让 AI 从“知道应该点击哪里”，走向“确认自己操作的是正确目标，并且操作产生了预期结果”。

这也是 AI 从聊天走向执行的第一个重要战场。

三、战场二：RPA——AI 如何在复杂业务流程中持续执行？

如果软件操作主要关注如何与界面交互，那么 RPA（机器人流程自动化）关注的则是如何将多个操作组织成可重复执行的业务流程。例如：

自动处理报销单；

从邮件中提取订单信息；

将数据录入企业管理系统；

定期生成业务报表；

在多个系统之间同步数据。

这些任务通常具有明确的业务规则，但也可能包含大量异常情况。

1. 传统 RPA 与 AI Agent 有什么区别？

传统 RPA 擅长按照预先定义的流程执行操作。例如：

当输入格式、界面和业务规则相对稳定时，这种方式往往非常高效。但一旦出现未预料的情况，固定流程就可能失效。例如：

邮件内容格式发生变化；

用户提供的信息不完整；

某个订单存在特殊业务规则；

页面出现新的提示或弹窗；

系统返回了无法直接匹配的错误信息。

传统 RPA 并非无法处理这些问题，但通常需要额外设计分支、异常规则和维护机制。AI Agent 的价值，则在于利用模型的理解和推理能力，处理部分非结构化信息和动态情况。

两者并不是简单的替代关系。更实用的方向，是将 AI 的灵活理解能力与 RPA 的确定性执行能力结合起来。

2. 为什么业务自动化需要“规则 + 智能”？

考虑一个发票处理任务。系统需要读取发票、提取金额、识别供应商、匹配采购记录，并决定是否进入付款流程。其中，不同环节适合不同的技术方式。

这张表说明，整个业务流程并不需要每一步都调用大模型。对于规则明确、结果可验证的任务，程序和业务规则往往更稳定；对于语义模糊、需要综合判断的任务，模型则可以发挥更大作用。

因此，成熟的业务自动化架构，通常需要明确区分：

哪些环节允许模型进行判断；

哪些环节必须遵守确定性规则；

哪些操作需要额外授权；

哪些结果必须经过验证；

哪些异常需要转交人工处理。

尤其对于付款、删除数据、审批和权限变更等高影响操作，不能仅凭模型判断就跳过必要的权限控制和业务校验。

3. RPA 的真正难点：可靠性与可维护性

业务流程往往不是一次性任务，而是需要长期、重复地运行。因此，评价一个自动化系统，不能只看它能否成功执行一次，还需要看它能否持续稳定运行。关键指标包括：

流程成功率；

单笔业务处理时间；

异常率；

人工介入比例；

失败后的恢复成本；

流程维护成本；

审计与合规可追溯性。

一个看起来很聪明、能够处理各种情况的 Agent，如果每次运行都需要大量人工检查，未必比传统 RPA 更有价值。反过来，一个完全依赖固定规则的流程，如果面对稍微复杂一点的输入就频繁失败，也很难覆盖真实业务。

因此，RPA 与 AI Agent 的结合，不应该只是给原有自动化流程增加一个大模型，而应该重新设计模型、规则、执行和验证之间的职责边界。

在业务自动化场景中，真正的竞争力不是模型能说出多么聪明的话，而是系统能否在可控成本下，持续、可靠地完成业务任务。

四、战场三：Agent 与工具协作——AI 如何自主完成复杂任务？

前两个战场主要围绕软件操作和业务流程展开。第三个战场则更加开放：Agent 不再只执行固定流程，而是根据用户目标，自主决定应该调用什么工具、采取什么步骤，以及何时调整计划。

1. 从固定流程走向动态任务规划

假设用户提出一个任务：

帮我研究三款竞品，分析它们的价格、功能和用户评价，形成一份对比报告，并保存为文件。

系统事先可能并不知道应该访问哪些网站、需要检索哪些信息，也不知道第一次搜索是否能够得到足够的结果。它需要动态地完成以下工作：

与固定的自动化流程相比，这类 Agent 具有更大的自主性。它不仅要执行动作，还需要决定接下来做什么。这也让模型的推理能力变得更加重要。

2. 为什么 Agent 的系统架构比单次推理更重要？

复杂任务通常涉及多个相互依赖的步骤。如果系统每执行一步都将完整历史重新交给模型，可能产生较高的推理成本；如果每次出现异常都重新生成整个计划，可能造成重复操作；如果没有明确的任务状态，系统可能忘记已经完成的工作；如果没有工具执行记录，也很难追踪错误来自哪个环节。

因此，Agent 系统需要围绕任务建立一套持续运行的机制。其中至少包括：

任务规划。将目标拆解成可以执行和检查的子任务。

工具调度。根据当前任务状态选择合适的工具。

状态管理。记录已完成、待执行和失败的步骤。

反馈处理。根据实际执行结果调整下一步动作。

结果验证。判断最终目标是否达成。

这些能力并不一定全部由同一个模型实现。模型可以负责复杂理解与决策，程序负责调度和状态维护，工具执行层负责具体操作，验证模块负责检查结果。这种分工可以减少不必要的模型调用，也能让系统更容易调试和维护。

3. Agent 的关键问题：什么时候应该思考，什么时候应该行动？

在 Agent 系统中，模型推理与环境操作之间存在一种重要的权衡。如果每一个细小动作都需要模型重新思考，执行过程可能变得缓慢；但如果让系统连续执行大量动作而不检查中间状态，又可能在早期出现错误之后不断偏离目标。

因此，Agent 需要决定在哪些位置进行决策，哪些动作可以组合执行，以及什么时候必须停下来检查环境。可以把这类设计归纳为几个机制：

动作分块：把确定性强、依赖少的连续操作合并执行；

检查点：在关键状态变化前后停下来重新观察；

中断条件：遇到身份验证、未知弹窗、异常返回时暂停并重新规划；

重规划触发：当执行结果偏离预期或信息不足时，回到规划层调整。

例如，在一个网页表单中：查找输入框、填写固定字段，可以组合为一个相对确定的操作序列；遇到身份验证或未知弹窗时，需要重新观察环境；点击最终提交按钮之前，可能需要检查表单内容；提交之后，需要验证服务端是否真正接受了请求。

这是一种从“每一步都让模型重新生成”走向“根据任务结构组织执行”的设计思路。当然，哪些步骤能够合并、哪些必须等待反馈，取决于任务的依赖关系和失败风险。

4. Agent 的发展方向：从单一模型走向多种机制协同

一个完整的 Agent 系统，可能同时包含：

通用 LLM：负责理解、规划和复杂推理；

专门的分类或决策模型：负责特定的状态判断和动作选择；

规则引擎：负责明确的业务约束；

工具执行器：负责实际操作；

状态机与调度器：负责控制流程；

验证模块：负责检查任务结果。

这不是说系统组件越多越好，而是说不同问题可以由更合适的机制解决。简单任务可能只需要一次模型调用和一个工具；复杂任务则可能需要多轮规划、多个工具和持续的状态反馈。

Agent 的核心能力，不只是一次决策是否正确，而是整个系统能否围绕目标，持续做出正确的决策并推进任务。

五、战场四：VLA——当 AI 开始在物理世界中执行动作

前三个战场主要发生在数字环境中。即使界面复杂、流程繁琐，系统通常仍然可以通过软件接口、网络请求或屏幕操作完成任务。但当 AI 进入机器人和物理世界，问题就进一步复杂化了。

这里需要介绍一个重要概念：VLA，即 Vision-Language-Action，视觉—语言—动作模型。

1. 什么是 VLA？

VLA 通常指将视觉信息、语言指令与动作生成结合起来的一类模型或系统。它的输出可以是动作 token、动作块、轨迹、策略，或者更高层的技能选择，具体取决于模型架构和系统分工。

例如，用户对机器人说：

把桌上的红色杯子拿起来，放到水槽旁边。

系统需要将这个自然语言目标转化为真实的物理动作。大致流程可以表示为：

这与软件操作 Agent 存在相似之处：系统需要感知环境、理解目标、执行动作，并根据反馈调整行为。但两者之间也存在重要差异。

2. 为什么物理世界的执行更加困难？

在软件环境中，点击一个按钮，通常可以通过程序接口确认是否触发了某个事件。但在物理世界中，动作执行会受到大量现实因素影响。例如，机器人抓取杯子时，需要处理：

杯子的位置和朝向；

物体的形状、材质与重量；

机械臂的运动范围；

抓取时的接触状态；

物体是否滑动；

周围环境是否发生变化。

即使机器人正确识别了杯子，也不意味着它能够成功抓取。因为识别目标只是执行链路中的一个环节。机器人还需要将感知结果转化为可执行的运动，并根据实际反馈调整动作。

这使得 VLA 面临一些数字环境中不那么突出的挑战。

第一，感知的不确定性。摄像头只能提供有限的观测信息，遮挡、光照和视角变化都可能影响判断。

第二，动作的连续性。软件操作经常以点击、输入等离散动作表示，而机器人还需要处理连续的空间运动、速度和控制信号。

第三，环境的动态变化。物体可能移动，接触状态可能改变，原先有效的动作计划也可能不再适用。

第四，失败的物理成本。错误的网页操作可能导致数据录入失败，而错误的机器人动作则可能损坏物体，甚至带来安全风险。

因此，VLA 不仅需要模型理解视觉与语言，还需要可靠的动作执行机制、反馈控制和安全约束。

3. VLA 在机器人系统栈中应承担哪一层？

一个常见误解是：采用 VLA，就意味着一个模型端到端控制所有动作。现实中的机器人系统通常仍然包含多个层次，例如：

高层任务规划：决定要完成什么目标；

中层动作规划：决定动作序列和运动路径；

底层控制：控制关节、速度和力；

反馈控制：根据传感器信息修正执行结果；

安全机制：限制危险动作并处理异常。

具体分工取决于模型架构、机器人平台和任务要求。有些系统会使用一个模型直接输出一定粒度的动作，有些系统则将高层策略与传统控制器结合起来。

因此，更准确的问题不是“VLA 是否意味着一个模型控制所有动作”，而是“VLA 在机器人系统栈中承担哪一层、与哪些传统模块协同”。不能简单地认为，采用 VLA 就意味着不再需要运动规划、控制算法或安全机制；同样，也不能认为 VLA 必然比传统机器人系统更高效。它的优势需要在具体任务、硬件条件和评价标准下验证。

VLA 的重要意义，在于探索如何让机器更直接地利用视觉和语言理解任务，并将这种理解转化为行动。而它真正面临的挑战，是让行动在不断变化的物理环境中保持准确、稳定和安全。

六、四个战场背后，其实是同一个问题

现在，我们把四个战场放在一起比较。

这四个战场并不是互相独立的。一个企业 Agent 可以同时使用 LLM、RPA 和业务 API；一个软件操作 Agent 也可以先通过视觉理解界面，再调用浏览器或系统接口完成操作；一个机器人系统则可能使用高层 Agent 制定任务计划，再由 VLA 模型或专门的控制系统执行具体动作。

它们之间真正共同的部分，是一个更一般的执行闭环：

这个闭环可以出现在浏览器、企业业务系统、软件工作台，也可以出现在机器人身上。不同场景的差异，在于它们需要什么样的感知、决策、执行和反馈机制。此外，在真实系统中，这个闭环外面还套着一层横切要求：权限、安全、审计、可观测性和人工兜底。无论是数字操作还是物理动作，越接近高影响操作，这层要求就越不可省略。

因此，我们可以从这四个战场中得到一个重要结论：

AI 执行能力不是单一模型指标，而是模型、工具、环境和控制机制共同作用的结果。

七、从四个战场反推：Jev 应放在执行链路的哪一层？

回到这个系列一直讨论的主题：Jev。本文不展开 Jev 的完整定义，只讨论一个更具体的问题：如果执行链路中存在专门的决策接口，它应该放在四战场的什么位置？

先给出判断：Jev 不是第五个战场，而是横切四个战场的决策层。它可能出现在软件操作的候选动作选择、RPA 的分支路由、Agent 的工具选择，以及 VLA 的动作块或技能选择中。

一个自然的问题是：在完整的 AI 执行链路中，是否所有决策都需要通过通用 LLM 生成自然语言来完成？

未必。很多决策可以用 LLM + 结构化输出完成，但专门决策模型在特定任务上可能具备更合适的准确率、延迟、成本和可靠性。Jev 的机会不在于“LLM 不能做”，而在于“在哪些决策点上，专门机制比通用模型更合适”。

这些任务的具体形式虽然不同，但部分环节都可能被建模为结构化决策问题。如果某个模型能够在特定任务中，以更合适的方式输出决策结果，并且满足准确率、延迟、成本和可靠性要求，那么它就有机会成为执行系统中的一个有价值的组件。

那么，什么样的决策点适合专门决策模型？可以用下面这张表来判断：

对应到四个战场，候选决策点大致如下：

软件操作：从有限候选动作中选择下一步操作；判断当前界面状态是否达到预期。

RPA：根据流程状态选择分支；对异常类型进行分类和路由。

Agent 工具协作：选择下一个工具；判断是否触发重规划。

VLA：选择动作块或技能；在给定策略下选择短时动作。

同时必须区分三个层次。

第一，决策接口更适合某个任务，不代表它能解决整个执行系统的问题。如果网页加载很慢，降低动作决策的耗时也无法消除网页等待；如果机器人缺乏准确的传感器信息，再快的决策也无法弥补感知不足。

第二，结构化决策不意味着不再需要通用模型。复杂任务的理解、开放式规划和未知情况处理，仍然可能需要 LLM 的能力。

第三，某个决策模型在一个战场上的优势，不能直接推广到其他战场。软件操作、企业流程和机器人控制具有不同的输入、输出、错误成本与实时性要求。一种方法在网页按钮选择中表现优秀，并不意味着它就能直接胜任连续运动控制。

此外，还要避免把“结构化决策”与 Jev 绑定过紧。Jev 即便在某个战场有效，也只是执行系统中的一个组件，不能替代权限、审计、安全、验证和人工兜底。

因此，评估 Jev 或其他决策模型，需要针对具体场景建立任务基准，并同时观察一组指标：

从这个角度看，未来值得探索的不是寻找一个模型解决所有执行问题，而是构建能够根据任务特点选择合适模型和执行机制的系统。

八、结语：AI 执行时代，竞争的不只是模型

从软件操作，到 RPA，再到 Agent 工具协作和 VLA，我们看到 AI 正在从数字内容生成走向更广泛的任务执行。

在这个过程中，模型依然重要。更好的理解能力、更强的推理能力和更可靠的动作生成能力，都能够扩大 AI 的应用范围。但模型能力并不是全部。

软件操作需要准确感知界面并验证结果；业务自动化需要规则约束和异常恢复；Agent 需要管理复杂任务状态与工具调用；VLA 则需要将视觉理解和语言目标转化为真实世界中的动作。不同战场面临不同的技术挑战，也需要不同的系统设计。

未来的 AI 执行架构，很可能不是简单地让一个越来越大的模型包办所有事情，而是让通用模型、专门决策机制、执行工具、反馈控制和验证系统协同工作。Jev 更可能扮演的，是执行系统中的专门决策组件，而不是替代通用模型的范式——它是否有价值，取决于能否在具体战场、具体决策点上，用可验证的指标证明自己。

当 AI 从聊天走向执行，我们真正需要回答的问题，已经不只是：

“模型能不能理解这个任务？”

而是：

“它能不能在真实环境中，持续、可靠、可验证地完成这个任务？”

这可能才是 AI 执行能力竞争的核心。

下一篇：

《Jev 会成为下一代 AI 范式吗？LLM 与决策模型如何共存》

我们将回到整个系列最初的问题：Jev 究竟代表一种局部的模型优化，还是更广泛的 AI 系统设计思路？LLM、决策模型与执行系统之间，又可能形成怎样的协作关系？