边缘智能体如何与云端协作：从一次调用走向全程调度

导语

过去讨论端云协同，常把问题简化为：某个请求究竟交给本地模型，还是发送到云端模型。但对需要连续规划、操作工具并根据中间结果不断调整策略的 LLM 智能体而言，云端参与并不是一次性的路由选择，而可能穿插在整个执行轨迹中。每次调用都会影响成本、数据暴露范围以及后续决策，因此，单看最终答案已经不足以衡量系统质量。

研究做了什么

论文提出 EC2-Bench，用于系统评估长时程智能体中的边云协作。基准包含 128 项可执行的数字工作空间任务，并以统一框架观察三类指标：

• 任务表现：智能体能否完成目标，以及完成质量如何；
• 资源使用：边缘推理与云端 API 调用带来的成本和开销；
• 隐私暴露：执行过程中有多少信息需要离开本地环境。

研究比较了边缘独立执行、云端独立执行，以及多种协作方式。这里的“协作”并非单一架构，既包括由外部路由器决定何时调用云端，也包括边缘模型自行判断、让云端提供建议或承担部分执行。

核心发现

第一，协作在三项指标之间提供了相对有吸引力的折中。云端模型通常拥有更强的任务能力，但会带来更高的调用成本和更大的数据外发范围；纯边缘执行则更有利于本地化和资源控制，却可能受到模型能力限制。素材显示，在一组实验中，9B 边缘模型配合协作可达到约为全云端执行 73% 的表现，同时云端 API 成本约为其 15%。这一结果说明，合理的调用策略可能比简单地选择“全本地”或“全云端”更实用。

第二，边缘模型能力提升后，协作效果会逐渐接近云端独立执行，不同策略之间的性能差距也会缩小。但隐私暴露并不会因此自动趋同，仍然明显取决于云端参与方式。也就是说，模型变强解决的是能力问题，却不会自动解决数据治理问题。

第三，最佳协作形态会随边缘能力变化。较弱的边缘模型更依赖外部控制的云端参与，甚至直接把执行交给云端；当边缘模型更强时，系统更适合由边缘侧掌握决策权，让云端扮演顾问，而不是主要执行者。

意义与影响

这项工作把边云协同从静态的模型路由问题，推进到面向完整执行轨迹的系统设计问题。对于个人设备、企业工作站和需要处理敏感数据的智能体，未来的关键不只是“本地模型有多大”，还包括智能体能否判断何时求助云端、发送哪些最小必要信息，以及如何在获得建议后继续由本地完成执行。

EC2-Bench 的价值也在于提供了统一的评估视角：一个策略即使任务成功率较高，如果依赖频繁云调用或暴露过多上下文，也未必适合真实部署。后续系统设计可能会更多采用“边缘负责状态与决策、云端负责补充能力”的分工，但这一方向仍需要在更多任务类型、设备约束和隐私场景中验证。

来源：Hugging Face Daily Papers