小模型越强，云端越像「军师」？清华等团队系统研究 Agent 端云协同
当 AI Agent 在本地处理邮件、整理文件、安排日程，到底该让本地小模型自己干，还是交给云端大模型？东北大学、清华大学等机构的研究者推出 EC²-Bench，基于 128 个可执行长程 Agent 任务，系统比较四种端云协同策略在任务表现、计算成本与隐私暴露之间的权衡：9B 端侧模型仅用纯云端约 15% 的调用费用，就能达到纯云端约 73% 的任务完成得分；端侧越强，性能差距不断收敛，隐私暴露差距却依然巨大；最有效的协作方式，也从「云端代打」反转为「云端当军师」。
本文由东北大学、清华大学等机构的研究者合作完成。
当 AI Agent 开始在本地处理邮件、整理文件、安排日程，一个问题也随之而来：到底该让本地小模型自己干，还是把任务交给云端大模型？
直觉上，云端模型能力更强，让它多参与执行，任务应该完成得更好。但一项最新研究发现，事情并没有这么简单。
对于能力较弱的模型，由外部 Router 决定何时让云端接管困难步骤，效果最好；而当端侧模型变强，最有效的协作方式却发生了反转——云端不再负责「代打」，而是提供建议，让端侧 Agent 自己执行。
更有意思的是，随着端侧能力增强，不同协同策略的性能差距越来越小，隐私暴露差距却依然巨大：任务完成得分最大仅差 3.67 分，敏感信息暴露比例却相差高达 66.23 个百分点。
为了系统性研究这些现象，研究团队推出了 EC²-Bench，基于 128 个可执行长程 Agent 任务，探索不同端云协同策略在任务表现、计算成本与隐私暴露之间的权衡。
🎯 核心发现：端云协同可以「四两拨千斤」——9B 端侧模型仅使用纯云端约 15% 的云端调用费用，就能达到纯云端约 73% 的任务完成得分，显著超越端侧独立执行。
🤔 意外发现：性能差距收敛，隐私差距依然显著——随着端侧能力增强，不同协同策略的任务表现越来越接近，敏感信息暴露却仍可能相差数十个百分点。
💡 关键启示：从「云端代打」到「云端当军师」——弱 Agent 更需要云端直接帮忙执行，强 Agent 则更适合自主决定何时求助、如何利用云端建议。
Long-Horizon Edge-Cloud Agent Collaboration：以「安排项目会议」为例的协作轨迹、Workspace 环境、四种协同策略与三个研究问题（RQ1 协同有效性 / RQ2 端侧能力影响 / RQ3 协同模式演变）
➤ 论文链接
🔗 https://arxiv.org/abs/2610.17816
➤ 项目主页
🔗 https://passionate11.github.io/ec2-bench-project-page/
➤ 开源代码
🔗 https://github.com/OpenBMB/EC2-Bench
背景：Agent 的端云协同，不再是简单的「大模型还是小模型」
过去讨论端云协同，问题通常比较简单：用户输入一个 Query，系统判断应该交给本地小模型，还是云端大模型。
本地处理成本低、数据更可控，但能力有限；云端模型能力更强，却伴随着额外的调用费用和隐私暴露风险。只要设计一个足够聪明的 Router，决定每个请求交给谁，似乎就能解决问题。
但 Agent 和普通问答有一个根本区别：Agent 不是回答一次就结束，而是要持续与环境交互，把任务一步步做完。
以安排会议为例，Agent 可能需要读取邮件、查询多人日历、寻找空闲时间、协调冲突，最后创建会议并发送邀请。
在这个过程中，有些步骤本地模型可以轻松完成，有些却需要更强的规划和推理能力。云端可能在执行中途多次加入，而每一次参与，都可能影响后续的任务执行。
更麻烦的是，Agent 可能在前几步就读取了客户资料、邮件内容或内部文档。当它向云端求助时，这些信息也可能随着执行上下文一起被发送出去。
因此，真正的问题不只是「该不该调用云端」，还有「什么时候调用、让云端做什么，以及要为此付出多少成本和隐私代价」。
这些新的复杂性，让端云协同在长程 Agent 场景下的表现变得难以预料，而我们对其背后的规律仍缺乏系统性的理解。为此，研究团队围绕三个核心问题展开研究，尝试从 协同有效性、端侧能力影响和协同模式演变 三个方面，建立对 Agent 端云协同的系统性认识：
RQ1：端云协同在长程 Agent 任务中是否依然有效？
RQ2：端侧能力增强，会如何影响协同效果？
RQ3：最有效的协同方式，会不会随着端侧能力提升而改变？
怎么研究：让四种端云协作方式，在同一批 Agent 任务上较量
研究团队首先设置了两种单端执行基线，并进一步比较了四种代表性的端云协同策略。
第一种，Query Routing：任务开始前就选好执行者。
Router 只做一次决定，整个任务要么交给本地，要么交给云端。简单直接，但无法在执行过程中动态调整。
第二种，Per-step Routing：每走一步，都重新决定谁来执行。
Router 在每一步判断由本地还是云端执行。本地能处理的步骤留在本地，困难步骤则交给云端，比一次性路由更加灵活。
第三种，Edge-Controlled Delegation：本地 Agent 自己决定什么时候叫云端「代打」。
不再由外部 Router 发号施令，而是让 Agent 主动求助。云端接手当前步骤，完成后再把控制权交回本地。
第四种，Edge-Controlled Advisory：本地 Agent 自己干，云端负责出主意。
Agent 始终掌握执行权，遇到难题时向云端咨询规划、建议或纠错信息，再由自己完成实际操作。
这四种方式的核心区别，其实就是两个问题：谁决定什么时候求助？云端是亲自上场「代打」，还是退居幕后当「军师」？
两种单端执行基线（Edge-only / Cloud-only）与四种协同策略：Query Routing、Per-step Routing 由外部 Router 决定；Edge-Ctrl. Cloud Delegation、Edge-Ctrl. Cloud Advisory 由端侧 Agent 自己决定
有了不同的协同策略，接下来就需要一个能够公平比较它们的评测环境。为此，研究团队基于 OpenClaw 构建了统一的执行与评测环境，整理了 128 个可执行 Agent 任务，覆盖日常办公、信息检索、安全隐私、开发运维、数据分析和自动化等六类场景。这些任务不是简单的问答题。Agent 需要真正调用工具、操作文件、修改环境，并根据最终执行结果判断任务是否完成。
而 EC²-Bench 的评测，也不只关注任务能否完成，还同时考察三个维度：
任务表现：Agent 最终把事情做成了多少？
资源消耗：云端调用花了多少钱，本地消耗了多少计算？
隐私暴露：整个执行过程中，有多少敏感信息被发送给云端？
为了量化隐私暴露，研究团队还为其中 100 个任务进行了细粒度敏感信息标注，包含 3,385 个敏感信息单元，涉及个人信息、组织机密等 12 类敏感数据。
换句话说，EC²-Bench 不仅要看谁干活更好，还要追踪：为了把活干完，Agent 究竟花了多少钱，又向云端透露了多少信息。
EC²-Bench 主结果（云端模型为 GLM-5.3）
结果一：端云协同「四两拨千斤」，15% 的云端费用撬动 73% 的纯云端性能
首先要回答的问题是：在复杂的长程 Agent 任务中，端云协同真的有效吗？
以 Qwen3.5-9B 为端侧模型、GLM-5.3 为云端模型，纯端侧执行的任务完成得分仅为 39.12；而采用合理的端云协同策略后，得分提升至 60.46，相对提升约 55%，达到纯云端方案的 73%。
更重要的是，这一表现仅需 8.73 美元的云端调用费用，约为纯云端执行（56.42 美元）的 15%。
这正体现了端云协同「四两拨千斤」的潜力：不必让云端包办整个任务，只需在关键时刻借助云端能力，就能显著提升端侧 Agent 的任务表现。进一步分析发现，部分协同策略在性能与成本、性能与隐私的权衡上，还能够超越纯端侧与纯云端方案的线性插值参考线。
端云协同的价值，不只是减少大模型调用，更在于让大小模型优势互补，以更小的云端投入撬动更强的任务执行能力。
端云执行方式的权衡。(a) 云端费用–任务完成度；(b) 隐私暴露–任务完成度。绿色为 Qwen3.5-2B，蓝色为 Qwen3.5-9B；虚线为端侧与云端的线性插值，左上方更优
结果二：端侧越强，性能差距越小，隐私差距却没有消失
随着模型智能密度不断提升，同等能力所需的模型规模正在持续缩小。今天需要大模型才能完成的任务，未来可能由更轻量的端侧模型胜任。那么，当未来的端侧小模型逐渐具备今天大模型的能力时，端云协同是否仍然重要？
为了模拟未来端侧能力持续增强的趋势，研究团队进一步测试了从 Qwen3.5-2B、9B 到更高能力模型的多种配置。
首先，随着端侧能力增强，端云协同的任务表现逐渐接近纯云端执行。在高能力模型 Qwen3.7-Plus 上，最佳协同方案的任务完成得分达到 76.84，已经接近纯云端方案的 82.70。
更有意思的是，不同协同策略之间的性能差距也在显著缩小。在能力较弱的 2B 模型上，四种策略的表现差异还十分明显；而到了 Qwen3.7-Plus，任务完成得分最大仅相差 3.67 分。
如果只看任务表现，随着端侧模型越来越强，不同协同策略似乎已经越来越难分出高下。
但当研究团队把目光转向隐私时，却发现了截然不同的结果。
在 Qwen3.7-Plus 的实验中，四种策略的任务表现已经十分接近，敏感信息暴露比例却相差高达 66.23 个百分点！
更值得注意的是，任务表现最好的策略，恰恰也是隐私暴露最多的策略。 云端提供建议虽然能帮助端侧 Agent 更好地完成任务，但频繁咨询、传递执行上下文，也可能让更多敏感信息暴露在云端。
性能更好，不代表隐私一定更好。
这一发现表明，随着端侧能力持续提升，端云协同的研究重点可能逐渐从单纯追求任务表现，转向如何在相近的性能水平下，更好地控制成本与隐私暴露。
不同端侧模型下各协同策略的 (a) 任务完成度与 (b) 隐私暴露。圆点为均值，竖条为策略间范围，红色虚线为纯云端 GLM-5.3
结果三：从「云端代打」，到「云端当军师」
前面的实验发现，随着端侧能力增强，不同协同策略的任务表现逐渐接近。但这也带来了一个更深层的问题：不同能力的端侧 Agent，究竟适合怎样的协同方式？
研究团队对比了不同端侧能力下四种协同策略的表现，发现了一个有意思的现象：最有效的协同模式，会随着端侧能力提升而发生转变。
对于能力较弱的 2B 模型，由外部 Router 决定何时调用云端、让云端直接执行的 Per-step Routing 表现最好，任务完成得分达到 39.97；而由端侧 Agent 自主决定何时委托云端执行，得分只有 15.86。
原因并不难理解：当小模型自身能力有限时，判断什么时候需要帮助，本身就是一件困难的事。此时，由外部 Router 帮它做决定，再让云端接手困难步骤，往往更加有效。
但随着端侧模型变强，这种协作关系开始反转。
从 9B 模型开始，由端侧 Agent 自主决定何时求助、云端只提供建议的 Cloud Advisory 成为表现最好的策略，任务完成得分达到 60.46，超过其他三种协同方案。这一趋势在更强的端侧模型上依然成立。
这说明，随着端侧执行能力增强，云端不一定需要直接接手困难步骤，适时提供指导反而可能更加有效。弱 Agent 更需要云端「代打」，强 Agent 则更适合让云端当「军师」。
但为什么端侧模型变强后，会更擅长这种自主协作？它究竟需要具备哪些能力，才能真正用好云端这个「军师」？
协同模式随端侧能力变化——从外部路由，到端侧控制委托，再到端侧主导的云端建议
为什么会反转？关键是学会「求助」和「听劝」
为什么端侧模型变强后，反而更适合让云端提供建议，而不是直接接手任务？
研究团队进一步从两个方面展开分析。
第一，知道什么时候该找云端帮忙。
研究团队设计了随机调用对照实验：在保持云端调用比例相同的情况下，比较 Agent 自主求助与随机调用云端的效果。
结果发现，端侧模型越强，自主选择求助时机带来的优势越明显。这说明，强模型不仅更擅长独立执行任务，也更懂得在关键时刻寻求帮助。
第二，云端给了建议，能不能真正用起来。
云端提供好的规划，并不意味着端侧 Agent 一定能正确执行。尤其对于弱模型来说，理解建议并将其转化为实际行动，本身就是一道门槛。
为此，研究团队对 2B 模型进行了指令遵循训练。结果发现，随着模型理解和遵循指令的能力增强，它利用云端建议完成任务的表现也得到明显改善。
两组实验共同揭示了自主协作背后的两项关键能力：知道什么时候该求助，以及得到建议后能不能真正用好。
(a) 端侧自主调用与随机调用云端的任务完成度对比；(b) Qwen3.5-2B 经指令遵循训练（横轴为 GRPO 训练步数）后，在云端建议设置下的任务完成度
写在最后：端云协同，拓展端侧 Agent 的能力边界
EC²-Bench 的研究表明，合理的端云协同不仅能够以较小的云端投入实现「四两拨千斤」，其最有效的协作方式也会随着端侧模型能力增强而不断演变。
这些发现也为未来端侧 Agent 的发展提供了新的思路：提升端侧能力，不必局限于增强模型自身的推理与执行能力，还可以将端云协同作为一项核心能力来建设。
让 Agent 学会判断何时需要帮助、如何向云端寻求支持，以及怎样将云端建议转化为实际行动，从而在兼顾成本与隐私的同时，更有效地利用云端大模型的能力。
未来端侧 Agent 的能力边界，不应只由模型自身的能力决定，更可以通过高效的端云协同不断拓展。
目前，EC²-Bench 的论文、代码与评测资源已公开，欢迎大家阅读与交流！
更多实验细节请参阅原论文与项目主页。
🛰 EC²-Bench：让云端从「代打」变成「军师」
一句话总结这项工作：
我们提出 EC²-Bench，基于 128 个可执行长程 Agent 任务，同时考察任务表现、云端成本与隐私暴露，系统比较四种端云协同策略；9B 端侧仅用纯云端约 15% 的费用达到 73% 的纯云端得分，并发现最有效的协作随端侧能力增强从「云端代打」反转为「云端当军师」。
最终得到的是：
四两拨千斤：15% 的云端调用费用，撬动约 73% 的纯云端任务完成得分
性能收敛、隐私分化：端侧越强，策略间得分差距收敛到 3.67 分，隐私暴露差距仍达 66.23 个百分点
协作模式反转：弱 Agent 需要云端「代打」，强 Agent 更适合让云端当「军师」
两项关键能力：知道什么时候该求助，以及得到建议后能不能真正用好
➤ Paper
🔗 https://arxiv.org/abs/2610.17816
➤ Project Page
🔗 https://passionate11.github.io/ec2-bench-project-page/
➤ Code
🔗 https://github.com/OpenBMB/EC2-Bench
如果你也在关注 Edge-Cloud Agent Collaboration / On-device Agent / Agent Benchmark，欢迎关注我们的工作，也欢迎尝试 EC²-Bench。
As the edge agent grows stronger, the cloud shifts from doing the task for it to advising on how to do it itself.