AICon演讲实录 | 谢皓：AI Agent 在边缘云的探索与实践

在 AICon 全球人工智能开发与应用大会上，火山引擎边缘智能技术负责人谢皓发表了演讲，深入探讨了 AI Agent 在边缘云的探索与实践。他详细阐述了边缘计算的智能化演进之路，针对智能体部署至边缘过程中遭遇的一系列问题及挑战，边缘智能给出了实践经验及解决方案，同时，在介绍智能体在边缘云的应用实践基础上，展望架构范式的未来演进。

演讲内容主要包括了五部分：边缘计算的智能化演进之路；智能体在边缘云落地的问题与挑战；边缘智能助力智能体落地边缘云；智能体在火山引擎边缘云的实践；总结与展望。

以下是演讲实录：
大家好，我是谢皓，来自火山引擎边缘智能团队，我分享的题目是 AI Agent 在边缘云的探索和实践。

1.边缘计算的智能化演进之路

在开始之前，先介绍一下边缘智能。大家应该已经了解了中心和端，中心是数据中心，端是产生数据的地方，在端和中心之间，我们依据数据接入的延时划分成现场边缘、近场边缘、云边缘。边缘又可以分成两个部分，一部分是现场边缘，现场边缘跟端在同一网络内，例如把一辆车的车机看成是现场边缘的话，那么座椅、显示屏等组件就可以看作是端，它们共同处于一个网络环境中，都部署在现场。另一部分是近场边缘和云边缘，其实都可以看成是云边缘，从端侧角度来看，它们与云计算在本质上没有太大差异，都是在远离数据产生现场的地方进行计算，不过，它们的部署位置和规模有所不同。近场边缘通常部署在国内二三线或三四线城市的数据中心，而云边缘则位于区域中心，拥有更强大的计算能力。

这些层次共同形成了一个计算梯度，从端到云的响应时间在用户现场可缩短至 1-5 毫秒，构成现场边缘。在区域城市，延时大致在 5-20 毫秒，形成了近场边缘。而在区域中心，延时进一步增加，形成 20-40 毫秒的云边缘。这一梯度结构确保了数据处理的高效性和灵活性。火山引擎边缘云，服务于字节跳动海量流量场景下的需求，在海内外拥有 2500 多个边缘节点，网络带宽储备资源超过 150 Tbps，火山引擎边缘智能立足于边缘云，协同“端”“云”智能，致力于打造"端-边-云"智能方案。

除了成为大模型时代的基础设施，边缘计算在过去一直是企业智能化的重要基础设施，借此机会回顾一下边缘计算的智能化演进之路，按照智能化发展水平，主要分为三个阶段：AI 史前阶段，AI 1.0 阶段和 AI 2.0 阶段。

1.1 AI 史前的边缘智能——物联网（IoT）

第一个阶段在 2014 年左右，随着以云计算、大数据为代表技术的应用，诞生了万物互联。这时边缘计算的表现形式主要是在设备现场部署物联网网关，它承担着设备数据采集和转发的功能，通常被称为 DTU（data transfer unit）。有些高级的网关具备一定的数据处理和汇聚能力，但整体来看，可以认为是基于规则的伪智能阶段。从算力角度看，网关硬件在边缘 AI 的算力接近于 0，主要面对的场景是连接，也就是万物互联的互联。

1.2 Al 1.0 时代的边缘智能——智慧物联（AloT）

第二个阶段在 2017 年左右，以深度学习，特别是机器视觉为代表的 AI 1.0 阶段到来，智力水平得到真正的发展，可以认为进入到了小场景下的有限智能。设备现场的算力也达到了 1-10 TOPS，考虑当时大部分主流计算单元还是浮点的，更准确地说，算力单位应该是 1-10 TFLOPS。同时 AI 算力也开始蔓延到现场和中心之外更广泛的边缘，提供灵活的资源弹性。这时面向的主要场景可以认为从连接转向计算。

1.3 Al 2.0 时代的边缘智能——智能体（Al Agent）

第三个阶段是近两年，大模型技术有了长足的发展，我们认为进入到 AI 2.0 的时代。虽然业界对 AGI 通用人工智能何时能够到来还有分歧，但普遍认为当前技术已经达到了一定领域内的泛化智能。从现场边缘算力角度看，也突破了 100 TOPS 并将很快突破 1000 TOPS 。

同时，智能体的快速发展，也让边缘计算的演进之路有了更多的可能性。一般认为智能体拥有感知、理解、规划、决策、执行动作和长短期记忆的能力。根据智能感知和行动能力是否涉及物理世界，我们可以简单将智能体划分成面向虚拟世界的 virtual AI Agent 和面向物理世界的 physical AI Agent。在前两个阶段积累的连接能力和计算能力为 AI Agent，特别是 physical AI Agent 的发展奠定了关键基础。

2.智能体在边缘云落地的问题与挑战

随着智能体的快速发展，智能体怎么在边缘云上落地呢？落地过程中又会面临哪些问题和挑战？

2.1 问题一：如何泛化智能体对设备能力的理解

第一个挑战就是如何泛化智能体对设备能力的理解。在 AI 史前阶段，物联网平台接入了海量设备，那是不是操作 API 就可以操作设备了？再设计一个合适的 prompt 就可以告知大模型当前设备的能力？在交互过程中，只要大模型理解了意图，就可以通过 function call 来操作设备，但这个时候存在两个问题，一是无法泛化智能体对设备的理解，因为平台接入的设备量太大了，如果每一种设备都构造提示词的话，工程量会非常大；第二是无法动态地感知设备，设备可能会升级，升级以后的属性、状态不一样，过去的提示词就会失效。

2.2 问题二：如何形成 AI 1.0 与 Al 2.0 的能力互补

前面提到在 AI 1.0 阶段，边缘智能构造了完整的从设备接入、数据采集、数据处理、 AI 推理以及数据聚合、数据上云的全套链路。因为边缘算力紧张，边缘智能基于 GPU、NPU 等硬件做了编解码的处理和推理的操作，所以在边缘推理和音视频、时序数据的处理能力上，具备一定优势。AI 2.0 阶段虽然有很多的优势，但延时、成本都不如 AI 1.0 阶段的传统模型，同时，在针对一些小场景的准确性上，也不一定比 AI 1.0 阶段经过数据训练出来的小模型更好，怎么融合两者的优势也是值得思考的问题。

2.3 挑战一：软件生态的丰富度低

讲完了存在的问题，下面来看一看落地过程中的挑战。边缘存在低延时、低带宽成本的优点，但同时它也存在缺点。一个智能体的软件栈包含中间件、系统组件、需要调用的工具以及各类生态应用，从这方面来看，边缘的生态落后于中心，这也是在边缘部署智能体面临的挑战之一。

2.4 挑战二："大"模型与"小"算力

由于功耗、成本的原因，边缘算力相对来说比较受限，通过图片上 Nvidia 典型边缘设备的算力与内存的发展趋势，可以看到增长非常快，但跟中心比较，总体算力偏小，以 7B 模型为例，假设是 FP16 或是 FP8 的算力，基本上需要 100TOPS/32G 的算力才能满足模型运行的要求，按照这个标准的话，其实能满足这一条件的芯片并不多。那能不能把模型小型化呢？行业上通常会采用模型剪枝、蒸馏和量化等技术来缩小模型尺寸，并部署在小算力平台上。但是小尺寸的模型也意味着模型泛化和通用性减弱，怎么权衡大小模型的使用也是一个重要挑战。

2.5 挑战三：分散算力的综合利用

边缘计算具备低延时、高隐私的优势，但由于部署环境，功耗等因素限制，导致算力呈现出小型化和分散化的特征，怎么应对这类分散的算力？或者怎样把分散算力利用好？在过去一段时间的交流中，不少客户希望更好地利用闲置的边缘算力，其中将算力用于推理是较为普遍的想法。为此学术和工业界都有相关研究，如通过综合考虑可用算力、网络情况，将模型网络拆分至不同边缘算力实现边-边协同推理。以 lama2-70B 在 jetson orin 的测试为例，当带宽低于 20Mbps 时，将严重影响推理的 throughput 和 latency ，所以网络传输效率将成为边-边协同推理的关键因素之一。

2.6 挑战四：智能体连接物理世界放大安全风险

最后一个挑战是安全，作为一种应用和服务，智能体除了会面临传统安全威胁之外，还将面临新的安全攻击和威胁，如幻觉、对抗性攻击、病毒和后门攻击等，同时智能体连接物理世界后，将放大安全威胁，可能发生针对人、设备的物理攻击。

3.边缘智能助力智能体落地边缘云

针对以上提到的问题，边缘智能在实践中给出了自己的思考和解决方案。

3.1 "物模型"构建智能体对设备能力理解

针对设备的泛化理解问题，先和大家讲讲物模型的概念。在万物互联时代，设备的能力被概括为设备属性、设备事件和设备服务，同时，通过位置和其他描述性信息，可以具体化单个设备实例的详细情况，这就是“物模型”。在大模型时代，火山引擎边缘智能将这些信息作为提示语（prompt）注入到大模型中，智能体就能够动态地理解和适应设备的能力。

3.2 简化低代码编辑成本

在 AI 1.0 阶段，为了帮助业务更好地突破碎片化场景，边缘智能提供了低代码平台，让用户可以通过拖拽算子（数据加工、推理）的方式，根据场景灵活设计数据流。随着场景的丰富，算子逐渐变多，拽选算子也越来越考验用户对平台的理解。AI 2.0 阶段，智能体通过调用平台 API，获取算子能力和设备能力，能根据用户场景需求，辅助自动生成数据流，可以帮助实现传统机器视觉和大模型的有效结合。

3.3 加速端侧智能体开发的 OneSDK

短期内让整个边缘生态发展起来不太现实，所以我们提供了 OneSDK 方案，这个方案解决的问题总体来看是四个“多”。

• 第一个“多”是“多个平台”的集成，一个较为完整的端智能应用涉及调用物联网平台、视频云平台、智能体平台等多个平台的调用和融合，这将导致开发者的入门、学习、落地的门槛变得更高，同时也将衍生出另外两个多。
• 衍生出的一个多是“多个 SDK ”的适配，每个平台都有自己的独立 SDK，且 SDK 支持的开发语言，适配的操作系统参差不齐。同时端侧有限资源的 SDK 迁移也具备一定的技术挑战，进一步增加了端侧落地的成本。
• 衍生出的另一个多是“多重设备身份的管理”，每个平台都有自己的独立身份和证书，这将导致端侧存储资源的浪费，及重复证书成本的增加。同时多次鉴权也将增加系统延时，降低用户体验。
• 最后一个“多”是“多种模型的协同”，端侧人机交互模式有限，目前比较常见的以语音为主，所以 ASR 到大模型再到 TTS 基本成为必备的模型调用链路。在实时流式交互模式下，如何做好多个模型的协同也增加了开发的复杂性。

针对端智能面临的四个“多”问题，边缘智能推出了三个“一”的解决方案：端侧 OneSDK、OneCredential 和 OneStop 一站式服务。

• OneSDK，即端侧仅需集成一个SDK，即可一站式解决在线升级（OTA）、日志记录、远程登入、设备管理等设备运维需求，以及设备密钥、设备证书等设备安全需求，还能满足多模型和多智能体调用的设备智能需求。同时，提供硬件抽象层（HAL）接口，以便在 RTOS、其他嵌入式操作系统，甚至是无操作系统的设备上轻松迁移 SDK。
• OneCredential，支持云上多平台间的身份互认和权限穿透，使得设备端可以共享一套密钥和证书，在确保安全性的同时，降低了成本并提升了性能。
• OneStop，通过深度融合端云技术打造一站式端智能体方案，大幅降低端侧智能体的开发与接入门槛。

3.4 智能决策器协同边缘大脑与云上超脑

为了应对小型化模型会导致泛化和通用性下降的挑战，边缘智能开发了智能决策器，它能够根据输入提示语并结合其他相关因素，智能地决定是在本地完成推理还是将推理请求智能路由至边或云的算力中。

这个方案在 AI 1.0 阶段已经存在，不过当时推理任务相对来说比较容易分类，根据推理任务可以快速判断是图像检测任务、图像分类任务，还是语音识别任务。根据任务的复杂性，以及设备现在的状态，包括机型、功耗、温度等偏静态的指标，就可以判断出是要在端侧做计算，还是要调度到边缘或云上做计算。但 AI 2.0时代，推理请求的复杂性被隐藏在提示词中，这时我们就需要引入一个模型对提示词进行判断，选择合适的路由结果，这里我们将充分考虑提示词的隐私程度，和任务的复杂程度进行判断。对于隐私类问题，将倾向于本地对推理，对于复杂任务则倾向于调度到边缘或云上大脑。如果判断的结果面临矛盾时，我们遵循安全隐私为一等公民的原则，让推理过程仅调用本地模型。

3.5 边缘大模型网关加速云边大脑访问

当推理请求转发至设备之外时，边缘大模型网关提供四大核心能力，以助力提升云边大脑的访问效率：

• 标准接口：边缘大模型网关已适配约 20 种主流大模型厂商及多个智能体提供商，提供与 OpenAI 完全一致的标准接口。简化开发者在不同模型间的迁移过程，提升开发效率。
• 就近访问：边缘大模型网关依托分布广泛的边缘节点及智能流量调度策略，确保端侧设备能够实现就近快速接入，降低延时。
• 推理加速：边缘大模型网关运用多种缓存技术和边缘推理方法，有效加快查询速度，提升整体性能。
• 高鲁棒性：在稳定性方面，边缘大模型网关通过跨模型厂商的故障迁移机制和错误重试策略，增强了请求处理的鲁棒性，确保服务的连续性和可靠性。

3.6 面向 AI 2.0 的边缘安全

针对安全问题，边缘智能在传统的安全防护措施，如 DDoS 防护、WAF 和频次控制的基础上，增添了针对 AI 2.0 时代的边缘安全防护功能。具体来说，在输入层对输入的提示词进行安全性检测，拒绝任何不安全或不合规的提示词请求，同时，通过提示词扰动，降低提示词的安全风险。另外，通过在系统提示词中有针对地添加防御性的描述，增强大模型对提示词攻击的防范能力。在输出层，对智能体的输出结果进行深入分析和检测，以提高结果的安全性和合规性。

4.智能体在火山引擎边缘云的实践

接下来讲讲智能体在边缘云的实践。

4.1 协同扣子实现工厂自动巡检

第一个案例是跟扣子协作，实现了工厂的自动巡检。扣子是开发新一代 AI 智能体的应用开发平台，有一系列灵活好用的组件和工具，我们联动扣子通过定制插件和工作量让智能体具备了感知，操作设备的能力，实现了工厂的自动巡检，通过前面讲的联动大小模型可以发现是否存在火灾隐患，本质是利用在边缘侧处理视频的结果，基于结果进行分析、总结、上报。

4.2 让座舱更安全更聪明

第二个案例和座舱有关，跟传统座舱不一样，它支持通过非提示词、非唤醒词进行交互表达。过去，我们在跟座舱交互的时候，一般有类似“hi xx”的唤醒词，这个时候机器知道你要开始对话了，但用户希望更自然，机器保持在线，在它觉得需要对话的时候开启对话。这跟原来不一样的关键点在于涉及隐私安全的不确定性，我们希望在边缘或者说在车上进行处理和判断，根据当前视频场景和对话内容判断是在边缘侧执行，还是调用云上模型，前面提到智能决策器起到了关键的作用，通过智能决策器，保证信息安全的情况下，也可以用上云上大模型，帮助座舱变得更聪明。

4.3 端侧玩具一站式接入

第三个案例是关于端侧接入。我们尝试跟外部的端侧客户进行对接，比如说像玩具。传统的玩具厂商需要更完善的解决方案，通过边缘智能 OneSDK 解决方案，我们可以帮助打通从语音的 ASR、TTS、智能体的编排能力到上云的全流程，帮助用户进行快速接入。

4.4 融入生态，结合机器人 ROS2

最后一个案例是尝试融入生态，以机器人开发者生态为例。ROS 是常见的机器人操作系统，从图片展示出来的 ROS 架构图可以看出，自上而下分为三层，应用层、中间件层与操作系统硬件层。ROS 应用层中，用 node 表示单个应用，ROS 生态中已经内置了非常丰富的 node 应用用于机器人的数据采集、运动控制、仿真系统的连接。在中间件层，ROS系统提供了高效的通信机制，保障 node 各应用件间实现高带宽，低延时的通信。

为了让大模型自然地融入 ROS 系统，边缘智能和合作伙伴地瓜机器人把边缘大模型网关和 ROS 进行了更好的融合，融合包括两部分：

• 地瓜机器人将火山引擎边缘大模型网关进行二次封装，形成 node 应用融入到 ROS 生态中，整个 ROS 生态可以利用原来的方式与大语言模型进行通信；
• 火山引擎边缘智能通过对容器网络的完善，解决的 node 间的广播通信，帮助 ROS 生态更好的构建在火山引擎边缘云操作系统之上。

5.总结与展望

最后是总结和展望。综合来看，当前智能体在边缘云上的部署，可以分成两大类：一种是智能体部署在云上，大模型也在云上。也就是左侧两张图，这两张图之间的差别在于，第一种直接调物联网平台，通过物联网平台直接操作端侧的设备；第二种会更加智能，通过利用边缘算力，可以做简单的 CV、视频处理，实现更多安防类或是音频相关的能力。一种是智能体位于端侧，调用本地或云上的大模型，这种方式可以较好的平衡安全和性能。综合来看还是单一智能体的不同服务在端-边-云的部署和通信。

面向未来，我们将尝试将智能体作为整体在端-边-云架构上部署，将智能体间多服务的通信，变成智能体间的沟通与通信，我们认为这种架构会存在以下三个优势：

• 一是智能体的自治能力会变强，不会因为网络原因导致智能体无法使用
• 二是这样的设计更符合开闭原则，对单一智能体的迭代也可以变得更加敏捷
• 三是还具备多智能体的其他优势，如共享知识、多智能体决策、监督等，智能体也可以根据角色分工选择在云上、边上或端侧部署

以上为演讲实录全部内容。