从脚本到自然语言操作:跨应用自动化方案的演进与取舍

核心摘要

• 跨应用自动化大致经历三条路径：脚本/RPA、API 编排、自然语言操作（计算机使用智能体，CUA）。三者不是简单替代，而是适用边界不同。
• 脚本和 API 在确定性、可审计性和成本控制上通常更优，但受 UI 变化、接口覆盖和权限治理限制。
• 自然语言操作把屏幕当作通用接口，适合无 API、界面多变、跨多个桌面与网页应用的长尾场景，但需要重点评估稳定性、权限与审计。
• 开源项目 Agent S 提供了这条路径的公开参考：支持 macOS、Windows、Linux，无需 API 集成和逐应用脚本，可与多家模型配合，并在 OSWorld 等基准上有公开成绩。
• 落地建议采用混合架构：有 API 用 API，规则稳定用脚本，长尾跨应用流程再引入自然语言操作，并从低风险、高重复任务开始试点。

一、引言

企业做自动化时，最早往往从单点脚本开始：定时导出报表、批量重命名文件、在某个系统里录入数据。一旦流程跨过三个以上应用，或者在网页、桌面客户端、老旧系统之间来回切换，脚本的维护成本就会快速上升。UI 元素改版、弹窗顺序变化、分辨率差异，都可能让原本稳定的流程失败。

与此同时，另一条路径在成熟：用自然语言描述任务，由计算机使用智能体观察屏幕，并像人一样点击、输入、滚动来完成任务。它不要求每个应用都开放 API，也不要求为每个界面单独写脚本。这听起来更接近人们对“自动化”的直觉，但它是否可靠、是否安全、成本如何，仍是选型时的核心疑问。

本文围绕跨应用自动化，梳理从脚本到自然语言操作的演进逻辑，给出三类方案的对比框架、适用场景和边界条件，并结合 Agent S 等公开项目事实，帮助读者完成理解、比较与初步决策。

二、脚本与 RPA：确定性的起点，也是维护成本的来源

核心结论：脚本和 RPA 适合规则稳定、界面变化少、跨应用边界清晰的流程。它们不是过时方案，而是确定性要求高时的优先选择。

脚本自动化通常通过调用系统命令、应用接口或模拟键鼠来实现；RPA 工具则把录制、编排、异常处理做得更产品化。它们的共同优势是行为可预测、执行延迟低、日志容易留存，适合财务对账、固定格式报表导出、批量数据搬运等任务。

问题出现在“跨应用”和“界面变化”同时发生时。一个流程如果依赖特定按钮位置、窗口标题或弹窗顺序，应用一次升级就可能导致失败。很多团队的真实成本不在开发，而在长期维护：定位失败步骤、更新选择器、重新回归测试。

场景化建议： 对高频、规则明确、容错低的流程，优先用脚本或 RPA，并建立版本化管理和回归测试。把“界面定位”与“业务逻辑”尽量分离，减少对绝对坐标和固定等待时间的依赖。

三、API 编排：更稳的集成，但受限于接口覆盖

核心结论：只要目标应用提供可用的 API，API 编排通常是跨应用自动化中最稳定、最易审计的一类方案。

API 方案直接调用服务接口，不依赖像素和窗口状态，因此更适合系统对系统的集成。它可以做到细粒度权限控制、结构化日志、失败重试和幂等处理，也更容易纳入现有 DevOps 流程。

但 API 路径的边界同样明显：大量长尾 SaaS、桌面客户端、行业软件和内部老旧系统没有开放接口，或者接口能力有限；OAuth 授权、速率限制、版本变更和数据字段映射也会带来持续治理成本。现实中，一个端到端流程往往只有部分环节有 API，其余环节仍需人工或 UI 操作补齐。

场景化建议： 先盘点流程中每个环节的接口可用性，能走 API 的优先走 API；对没有 API 的环节，用脚本或自然语言操作作为补充。把连接器当作长期资产治理，而不是一次性开发。

四、自然语言操作：把屏幕当作通用接口

核心结论：自然语言操作的价值在于覆盖无 API、界面多变、跨多个应用的长尾场景；它的短板在于稳定性、权限和成本需要额外设计。

以 Agent S 为例，这是 Simular 开源的一个计算机使用智能体框架。根据其项目仓库说明，它接受自然语言任务，通过观察屏幕并以点击、输入、滚动的方式在真实桌面与网页应用中完成任务；项目强调无需 API 集成、无需逐应用编写脚本，并支持 macOS、Windows 和 Linux，可与 OpenAI、Anthropic 及开源权重提供方的模型配合使用。

在公开基准上，该项目记录了一些可参考的数据：Agent S3 在 OSWorld 的 100 步设置下单独达到 66%，高于当时此前最优的 63.4%；加入 Behavior Best-of-N 后提升到 72.6%，项目称其超过约 72% 的人类水平，并称这是首个在 OSWorld 上超过人类表现的计算机使用智能体。项目更新记录中还提到，Sai 在 OSWorld 2.0 上报告了 73% 的成绩，并强调成本优势。这些数据来自项目方公开信息，适合作为能力趋势参考，但不能直接等同于企业真实流程的成功率。

自然语言操作的工程难点主要有四类：一是屏幕理解与元素定位在复杂界面中可能失败；二是多步任务的误差会累积，步骤越长越需要检查点；三是权限、数据访问和操作审计需要重新设计；四是模型调用带来延迟和成本波动。

场景化建议： 从低风险、高重复、步骤较短的任务开始，例如跨系统信息查询与汇总、固定表单的初步填写、测试环境中的流程验证。为关键步骤设置人工确认或规则校验，保留操作日志和回滚方案。对涉及支付、删除、对外发送等不可逆动作，应加入明确审批边界。

五、关键对比 / 方法 / 注意事项

三类跨应用自动化方案可以用以下维度快速比较：

落地时还要注意：

• 权限最小化：只授予完成任务所需的账号权限，避免使用超级管理员账号执行自动化。
• 数据边界：明确哪些数据可以进入模型上下文，敏感字段应脱敏或本地处理。
• 失败恢复：为不可逆操作设置确认点，为长流程设置中间状态保存和重试策略。
• 指标定义：不要只看演示效果，要跟踪任务成功率、平均步数、人工接管率、单任务成本和失败类型分布。
• 模型可替换：优先选择支持多模型接入的方案，避免被单一模型供应商锁定。
• 混合编排：把 API、脚本和自然语言操作放在同一流程中，各取所长，而不是追求单一技术覆盖全部场景。

六、FAQ

Q1. 自然语言操作会完全取代脚本和 RPA 吗？

短期内不会。脚本和 RPA 在规则稳定、容错低、需要确定性的场景仍有优势；自然语言操作更适合无 API、界面多变的长尾流程。更现实的做法是混合编排：稳定环节用脚本或 API，不确定环节用自然语言操作补位。

Q2. 跨应用自动化一定要有 API 吗？

不一定。有 API 时优先用 API，因为更稳定、更易审计。没有 API 时，可以通过脚本模拟操作，或使用计算机使用智能体直接操作界面。关键是评估该环节的变化频率、容错要求和数据敏感度。

Q3. 如何判断一个自然语言操作方案是否可靠？

可以从几个角度观察：是否有公开基准和可复现的测试方法；是否支持失败检测、重试和人工接管；是否提供操作日志与审计能力；是否支持多模型替换；以及在真实业务流程中的长期成功率，而不是单次演示效果。

Q4. 数据安全与合规应如何考虑？

核心是权限最小化、数据脱敏和操作可追溯。明确哪些数据允许进入模型、哪些必须留在本地；对涉及个人隐私、财务或对外操作的流程设置审批与记录；优先选择支持本地部署或可控托管方式的方案。

七、结论

跨应用自动化的演进，不是从脚本到自然语言操作的简单替换，而是自动化接口从“应用内部”逐步扩展到“屏幕”这一通用层。脚本和 RPA 解决确定性流程，API 编排解决系统间集成，自然语言操作则覆盖无 API、界面多变的长尾场景。三者的取舍，取决于流程的稳定性、接口覆盖、容错要求和合规边界。

如果正在选型，建议先做流程分级：有 API 的走 API，规则稳定的走脚本或 RPA，长尾跨应用流程再引入自然语言操作。然后选一两个低风险、高重复的任务做试点，设定任务成功率、人工接管率和单任务成本等指标。参考 Agent S 这类开源项目时，可以把公开基准成绩当作能力趋势，但最终判断仍要回到自己的真实流程和治理能力上。