从OpenAI的Operator，看AI与互联网交互的四种技术路线

OpenAI的Operator发布了，再次引发了关于智能体的热议。

关于Operator是什么，已经有很多的文章在介绍了，也可以看下官网的介绍：https://openai.com/index/computer-using-agent/。

简单来说，Operator可以操作你的浏览器或者电脑，帮你完成各种日常任务。它最大的意义，在于我们可以将AI与现在的互联网世界连接起来。

本文主要是对比、总结当前已经出现的AI与互联网交互的四种技术路线。本文核心观点如下：

• 当前已经出现的AI与互联网交互的技术路线包括：Computer Use Agent，Headless Browser（无头浏览器），端侧API，远程API/Protocol。
• Computer Use Agent：可以让AI快速获得访问互联网的能力，原有的应用无需改造即可接入AI，但是这种技术运行成本高，也无法实现任务的异步化。
• Headless Browser：可以异步执行任务，具备更低的运行成本，但是只能够接入web应用，并且维护web的接入需要一定的成本。
• 端侧API：当前AI手机的主流方案，APP在手机端开放API给手机上的AI助手（比如siri），AI助手调用API访问互联网。这种方式能够执行异步任务，体验好。但是只适用于手机和APP场景，并且依赖APP的开放程度。
• 远程API/Protocol：这是AI访问互联网最擅长的方式，能够异步执行任务，运行成本低，并且支持自动身份认证。但是需要应用配合升级，接入成本高。
• 短期来看，Computer Use Agent（CUA）与无头浏览器技术虽然有各种各样的限制，但是只要找到合适的场景，这两种技术是能够快速落地，并且产生商业价值。
• 长期来看，我们坚定看好的是API/Protocol技术路线，它能够提供最优的用户体验，以及最低的运行成本。至于原有系统改造成本问题，我们认为随着AI编程能力的提高，改造成本会逐步降低。而协议标准化的问题，我们认为未来肯定会出现标准协议。
• 另外，我们正在在探索Protocol方案落地的可能，并且取得了一定的进展。

Computer Use Agent（CUA）

CUA技术的基本原理是通过截取屏幕图像，利用模型的视觉能力，识别图形用户界面（GUI）中的按钮、菜单、文本字段等元素，模拟人类对屏幕的视觉理解能力。

然后通过虚拟光标和键盘输入与界面交互，执行点击、输入文本、滚动等操作，实现AI与应用以及互联网的交互。

这种技术有几个优点：

1、最大的优点是， 可以让AI立即具备与互联网的交互能力，AI从此可以完成很多任务。

当前的互联网是为人访问而设计的，让AI模拟人的方式，是AI接入互联网最快的方式。

当AI接入互联网后，就可以解决当前AI工具能力匮乏的问题，可以帮助人们完成很多有价值的任务。商业上也可以因此加快落地。

2、打破数据孤岛

CUA技术也相当于是在人与互联网之间增加了一个个人助手，这个个人助手打破了现有的数据孤岛，能够访问到用户的所有信息。从而帮助用户作出更智能的决策。

3、应用改造成本低

应用基本无需改造，即可让AI使用。

当然，这个技术也有几个明显的缺点：

1、 运行成本高

CUA技术依赖模型的视觉能力，图片的处理会导致运行成本比较高。高价值场景我认为可以跑通的，但是如果要将这个技术推广到普通C端用户场景，我认为挑战还是非常大的。

2、无法实现异步化

CUA技术依赖屏幕截取，需要将计算机控制权交给AI，这个时候人是无法使用计算机的。

最理想的体验是智能体异步执行任务。比如，是我有一个任务，AI助手去后台处理，处理完成，或者需要人类介入的时候，再通知人类介入。

3、需要人进行频繁的登录操作

C端场景下，CUA在进入一个应用时，仍然需要用户进行登录操作，无法自动的完成身份验证。

4、短期需要解决准确率的问题

CUA 在简单网页任务上表现优异（87%），但在复杂本地操作（38.1%和动态网页交互（58.1%）中仍有明显短板。

最后，就应用场景看，我认为CUA最有可能先在B端场景落地，特别是一些高价值、同时又有一定个性化的场景。如果完全是重复性操作，RPA可能更加适合。

而在C端场景，专业用户（比如视频剪辑员）也许是一个不错的落地场景。

普通的C端用户场景，受限于运行成本和使用体验，以及其他技术路线的竞争，CUA可能没有太多的竞争力。

Headless Browser（无头浏览器）

无头浏览器（Headless Browser）是一种没有图形用户界面（GUI）的浏览器，它通过命令行或编程接口在后台运行，能够执行与传统浏览器相同的操作（如加载网页、执行 JavaScript、渲染页面等），但无需可视化界面。

无头浏览器如何帮助AI连接互联网？

• 可以使用无头浏览器的框架如Puppeteer，获取web应用完整页面数据（只获取数据内容，而不渲染）
• 然后使用AI处理页面数据，找到完成指定操作所需要的页面元素
• 使用AI或人工编写代码，调用无头浏览器框架API操作页面元素，实现自动化操作
• 将上面的代码作为AI的工具，让AI调用，从而让AI接入互联网

无头浏览器方案的优点是：

1、可以实现任务处理的异步化

由于无头浏览器在后台运行，无需要抢占用户计算机的控制权，可以让任务在后台异步执行，只有需要人介入的时候，再通知人。

2、对web应用友好，不需要应用修改

可以让AI快速的接入互联网的web应用。

3、运行成本较CUA技术更低

通过处理文本、预先编写代码，让无头浏览器的方案在运行成本上低于依赖视觉能力的CUA技术。

无头浏览器方案的缺点是：

1、仅限于web应用

所有无法在web中运行的应用，无头浏览器方案是无法接入的。比如计算机上的本地应用。而CUA是没有这个限制的。

2、页面适配成本高

需要为页面适配生成大量的代码，同时，页面的升级、修改可能会导致原有的代码不生效，需要重新生成、测试、部署，整体的维护成本高。

3、需要人进行频繁的登录操作

和CUA的限制一样，仍然需要用户进行登录操作，无法自动的完成身份验证。

无头浏览器还有一种方法是每次都将全量的页面数据输入到LLM中，让LLM来进行处理，不过这种方法太低效，成本也高。如果能够专门针对这个场景训练一个垂直模型，也许是一个不错的选择。

小程序平台也许是无头浏览器落地的不错场景。小程序本质上可以看做是一个web应用。如果小程序平台能够解决账号互通的问题，那平台就可以构建一个AI助手，这个助手直接用用户的账户，通过无头浏览器直接和小程序进行交互，不需要人类介入。

端侧API

端侧API技术通过操作系统开放标准化的设备能力接口，允许AI直接调用传感器、应用程序数据和硬件功能。其核心原理是建立系统级的意图交互协议，使AI无需模拟人类操作即可精准控的与应用进行交互，从而实现AI与互联网的交互。

技术实现原理

1、意图注册机制

应用程序向操作系统声明可被调用的"技能意图"（如"发送消息"、"创建日程"），定义参数格式和权限范围，形成全局能力目录。iOS 18的App Intents框架已支持200+核心功能接口注册。

2、语义映射引擎

系统内置的自然语言理解（NLU）模块将用户指令（"把刚拍的照片发到工作群"）转换为结构化API调用链，自动关联相册API、通讯录API和即时通讯API。

3、安全沙箱机制

通过可信执行环境（TEE）实现跨应用数据流转，AI在获得用户单次授权后，可组合调用多个API（如同时访问位置服务和备忘录），但原始数据不离开设备。

方案优势

1、零界面改造成本

应用只需注册并实现标准接口，无需修改现有UI，更多的修改是内部的功能。

2、真异步任务处理

AI可在后台组合调用多个API（如同时预订机票、酒店、租车），用户可随时中断。

3、运行成本比Computer Use Agent方案低

不用AI视觉能力，比Computer Use Agent方案有更低的运行成本

方案缺点

1、生态碎片化严重

各平台、各厂家接口标准不统一（Android vs iOS App Intents vs 鸿蒙原子服务）。

2、应用的开放性问题

应用与手机厂商有一定的竞争关系，应用很难开放核心的数据给手机平台。

3、场景限制

当前更多的应用在手机上，没有手机平台的Chatbot无法使用这个方案。

远程API/Protocol

让AI直接通过API或者Protocol与互联网进行交互。比如一个系统有对外提供的API，AI可以使用函数调用或tools能力，调用API来完成信息的获取或交互操作。

原有系统的API不是专门为AI设计，调用过程中可能需要人编写代码、提前配置keys等，以完成身份验证、权限控制等操作。

现在也有一些专门为AI或智能体设计的协议，比如Anthropic的MCP、以及我们设计的ANP。他们共同的目标就是为了让AI用它最擅长的方式来访问互联网。

MCP的全称是Model Context Protocol（模型上下文协议）。旨在标准化大型语言模型（LLMs）与外部数据源和工具之间的通信方式，帮助 AI 系统更高效地访问和利用上下文信息，从而提升模型的响应质量和实用性。

ANP的全称是Agent Network Protocol，https://github.com/agent-network-protocol/AgentNetworkProtocol，是行业首个开源的智能体通信协议。ANP与MCP的区别是，ANP以智能体为中心，每个智能体都具有同等地位，目标构建一个高效的智能体协作网络。

这种方案的优点：

1、让AI用它最擅长的方式访问互联网

无论是CUA技术，还是无头浏览器，都是让AI模拟人类上网，这不是AI访问互联网最擅长、最高效的方式。AI直接处理底层数据才是其最擅长的方式。

2、可以实现任务的异步化

AI收到一个任务后，可以在在后台通过API或协议进行处理，不用占用计算器控制权。

3、运行成本低

相比CUA和无头浏览器，API/Protocol的运行成本低，它既不需要处理截屏数据，也不需要维护页面数据代码。

4、自动化身份认证

通过使用去中心的身份认证技术，比如DID，可以实现跨平台、自动化的身份认证，用户只需要在关键环节（付款等）介入。目前我们设计的ANP已经支持DID方案，MCP暂时还没有支持。

这种方案的缺点：

1、改造成本高

需要对原有的系统进行改造，以支持相关协议，这是这个方案最大的缺点。不过随着AI编程技术的进步，改造成本会逐步降低。

2、领域处于早期，标准不明朗

智能体通信协议这个细分领域还处于非常早期阶段，行业中已有的方案不多，且并没有形成标准。目前在这个领域研究比较多的，主要是Anthropic 的MCP和我们设计的ANP。

不过国内外的标准化组织也在投入相关的研究，比如W3C、国内的IIFAA等。

总结

让我们整体来分析下三种技术路线。

短期来看，Computer Use Agent（CUA）、无头浏览器技术、端侧API虽然有各种各样的限制，但是只要找到合适的场景，这两种技术是能够快速落地，并且产生商业价值。

长期来看，我们坚定看好的是API/Protocol技术路线，它能够提供最优的用户体验，以及最低的运行成本。至于原有系统改造成本问题，我们认为随着AI编程能力的提高，改造成本会逐步降低。而协议标准化的问题，我们认为未来肯定会出现标准协议，我们的目标是成为协议标准化的重要参与者。

另外，我们正在在探索Protocol方案落地的可能，并且取得了一定的进展。

关于我们

我们正在开发一个开源的智能体通信协议：AgentNetworkProtocol(ANP)，项目地址：https://github.com/agent-network-protocol/AgentNetworkProtocol。

AgentNetworkProtocol的目标是成为智能体互联网时代的HTTP。我们的愿景是定义智能体之间的连接方式，为数十亿智能体构建一个开放、安全、高效的协作网络。

同时我们也在开发智能体连接的基础设施，让智能体相互之间能够进行去中心化的身份认证、高效的数据通信与协作。

如果你也对智能体通信协议感兴趣，或者有类似的需求，欢迎联系我们：

• 微信：flow10240
• 邮箱：chgaowei@gmail.com

也欢迎加入智能体通信协议讨论群，这可能是全网第一个专门面向智能体通信协议的讨论群：

版权声明

Copyright (c) 2024 GaoWei Chang
本文件依据 MIT 许可证 发布，您可以自由使用和修改，但必须保留本版权声明。