终端智能体对比为何总矛盾？一份可复现评测基线指南

最近在整理终端智能体的技术选型资料时我遇到一个很典型的现象同样一个任务两份不同的智能体对比报告给出了完全相反的结论。一份说某方案在系统设置类任务上成功率能到 90% 以上另一份却把它排到末尾理由是“频繁卡在权限弹窗”。两边都做了真实验证跑的都是公开任务集最后结论却不一致。这不是偶然的测评误差。过去一年终端智能体端侧 Agent从概念验证快速走向工程化大量团队开始对比不同方案但“对比矛盾”几乎成了普遍现象。原因不是某个方案造假而是对比本身的坐标系不统一任务定义、成功标准、设备环境、模型版本、工具权限、上下文策略这些变量只要有一个不同结果就无法互相印证。这篇文章先把终端智能体到底解决什么问题讲清楚再拆解核心组件和主流方案差异然后重点分析“对比为什么矛盾”这个工程问题最后给出一套可复现的评测基线设计。如果你正在做 Agent 选型、自研终端智能体或者只是被各种跑分报告绕晕了这篇应该能帮你在对比时少踩几个坑。1. 终端智能体到底是什么终端智能体英文常写为 On-Device Agent 或 Edge Agent是指运行在用户侧设备上的智能体系统。设备可以是手机、PC、平板、车机也可以是智能家居终端。智能体在设备本地感知当前环境、理解用户意图、调用系统能力最终完成一个真实操作任务。它与传统 App 自动化最大的区别是“意图驱动”。传统安卓无障碍自动化脚本由开发者写死操作步骤比如“先点设置再点显示与亮度再点深色模式”。终端智能体不一样用户只需要说一句“帮我打开深色模式”智能体自己规划步骤、执行点击、处理异常。它不再依赖预先写好的脚本而是依赖模型对 UI 界面的理解能力和对工具调用的决策能力。把终端智能体和云端 Agent 放在一起看差别更明显对比维度云端 Agent终端智能体运行位置服务器或云端容器用户设备本地感知数据用户上传文本、文件屏幕截图、UI 层级、应用状态环境权限云端 API 权限设备系统权限、无障碍服务权限典型任务订票、查档、生成报表打开应用、设置系统、跨 App 操作延迟要求容忍网络往返对交互响应敏感需要低延迟隐私边界数据上传云端数据和上下文尽量留在端侧终端智能体火起来核心推动力有三个一是端侧大模型推理能力增强很多设备已经能在本地跑得动轻量模型二是 UI 界面理解技术成熟模型可以“看懂”截图和控件树三是用户对跨 App 自动化操作的需求明确传统自动化脚本又跟不上界面变化速度。不过这里要泼一盆冷水终端智能体不是简单把大模型塞进手机。真正复杂的是系统的可靠性设计、权限控制、异常恢复和状态管理。模型只负责决策能不能稳定落地取决于工程框架。1.1 终端智能体与“自动化脚本”不是一回事很多开发者一想到终端智能体第一反应是这不过就是带 AI 的 RPA机器人流程自动化。这个理解有一定道理但不够准确。自动化脚本依赖的是确定性的控件定位和固定操作序列界面一变脚本就失效。终端智能体面对的是不确定环境页面加载快慢、弹窗时机、网络状态、应用版本都不可预知。这意味着终端智能体必须有一个“感知-决策-执行-确认”的闭环而不是简单的 if-else 步骤序列。感知层读取截屏、UI 层级和系统状态决策层根据当前状态判断下一步动作执行层调用系统能力完成动作确认层检查动作是否生效。这个闭环每轮都要执行直到任务完成或达到上限。理解这个闭环是读懂后面所有对比和评测的前提。因为不同方案在这四个环节的取舍不同直接决定了它们在真实任务中的表现差异。2. 终端智能体的核心组件拆解要理解终端智能体不能停留在“一个 Agent 调一个模型”的粗粒度认知上。一个可用的终端智能体工程系统至少包含六个核心组件。2.1 感知与状态抽取感知层负责把设备当前状态转换成模型能理解的统一格式。常见做法有两类一类是纯视觉方案截屏后把图片直接交给多模态模型另一类是结构化方案读取 Android 的无障碍节点树或 iOS 的辅助功能接口生成页面控件列表。更成熟的系统会两种结合先读控件树定位可交互元素再结合截图判断布局和视觉状态。感知层最容易被低估但它往往是任务成败的分水岭。同样的截屏OCR 质量不同、控件结构解析深度不同、去噪策略不同模型拿到的输入差异极大。很多对比矛盾就发生在这一层不是模型决策能力不行而是页面信息抽取阶段就产生了偏差。2.2 上下文管理与记忆终端智能体的一次任务通常包含多轮交互。比如用户说“帮我订一张明天去上海的高铁票”智能体需要打开购票应用、选择日期、选择车次、填写乘客、确认支付中间可能穿插弹窗和二次确认。每个步骤依赖前面的结果如果上下文管理不当很容易出现“点击了但没有生效”或“点错了页面”的情况。上下文管理要解决两个问题短期会话窗口内如何保存关键状态长期任务如何压缩历史信息。现在主流方案是给每一轮动作记录结构化日志包括当前任务编号、最近 N 步的行为摘要、任务状态中间量。当上下文超出模型窗口限制时不是简单截断而是把早期步骤压缩成摘要继续携带。2.3 任务规划与工具调用任务规划组件接收用户意图和当前状态输出下一步行动计划。这里的规划粒度很关键有些系统直接把用户目标传给模型让模型输出完整的自然语言指令再解析成系统动作有些系统走更工程化的路线内置预定义动作集模型的任务是选动作和填参数而不是自由生成指令。工具调用是终端智能体的执行入口。工具列表通常包括点击、长按、滑动、输入文本、返回、打开应用、启动系统设置等。规范的工具定义需要声明参数类型、可使用的应用范围、执行超时时间和失败返回值。模型如果拿到一份设计糟糕的工具文档再强的推理能力也发挥不出来。2.4 执行器与沙箱执行器是真正触碰设备系统的部分。在 Android 上它可能依赖无障碍服务或系统辅助接口在 PC 上它可能模拟鼠标键盘事件。执行器设计最关键的是可回滚和安全边界哪些操作被允许、哪些应用在操作范围内、哪些操作需要用户二次确认。一个成熟的智能体系统不会让模型直接触碰所有系统 API而是把操作封装成语义明确的高层工具再把工具的权限边界限定好。2.5 验证与异常恢复执行完一个动作后系统需要验证动作是否真实生效。比如模型认为“点击了搜索按钮”但页面没有跳转这时候就需要重新感知页面状态判断是点击位置偏移、网络延迟、还是应用无响应。验证失败后智能体要能重试、换路径或请求用户协助。这个组件是终端智能体和普通聊天机器人的本质区别。聊天机器人只要生成回复就结束了终端智能体必须对现实世界的状态负责。2.6 安全权限与隐私边界最后是安全权限层。终端智能体如果拥有对整个设备的控制能力就等同于一个高权限自动化系统。它必须遵守最小权限原则只申请当前任务需要的权限授权过程要向用户明示关键操作前要弹窗确认。涉及账号密码类输入场景更推荐由用户在系统原生界面中完成而不是让智能体代理输入。敏感环境如支付、删除文件、发送消息需要单独的策略审批。安全权限设计不仅影响合规性也会直接影响用户体验和任务成功率。权限弹窗处理不好正是前面提到的“同一方案被不同报告给出完全相反评价”的常见原因。3. 主流方案对比的三个层次市面上的终端智能体方案看起来很多但按对比层次划分只有三个层面的差异模型层、框架层、产品层。大多数“对比矛盾”的根源是没有区分清楚自己在对比哪一层。3.1 模型层对比看推理和多模态能力模型层对比的是同一种任务上的智能体大脑能力比如从截图中定位元素的能力、遵循多步指令的能力、处理长 Horizon 任务的能力。这类对比需要严格控制输入条件和工具集最好是同一个框架、同样工具定义、同一份任务只替换模型。模型层对比的坑在于模型能力对环境非常敏感。一个在云端 API 上表现强大的模型部署到端侧后可能因为量化、内存限制出现明显性能下降而一个专门针对设备场景蒸馏出来的小模型在固定工具集下可能反而稳定。所以模型层对比的结论只对这个特定运行环境成立不能外推。3.2 框架层对比看工程能力和稳定性框架层对比的核心是“同一个模型在不同 Agent 框架下的表现差异”。这部分更接近工程问题工具定义设计是否合理上下文管理策略是否有效动作失败重试机制是否完善异常恢复是否及时。同一个模型用朴素 ReAct 模式包装和用一套具备自动重试、验证、摘要记忆的框架包装任务成功率可能相差一倍。框架层能力越强对模型的依赖就越低。这个观察对选型非常重要如果团队模型能力有限优先优化框架的工程可靠性收益往往比换模型更直接。3.3 产品层对比看用户体验和交付完整度产品层对比看到的是一个完整可交付的终端智能体。这里除了模型和框架还包括多语言支持、权限引导、设备兼容性、日志分析后台、账号系统、灰度发布机制等。产品层体验很难用单一的成功率数字衡量但恰恰是决定用户是否愿意长期使用的关键。三层差异导致了一个结果两个产品可能用同一个基础模型但最终用户体验完全不同两个模型能力差距明显但用不同框架包装后最终成功率反而相近。这就是终端智能体对比矛盾的深层原因——很多对比不是在同一个维度上说话。4. 为什么终端智能体的对比结果总是矛盾前面铺垫了组件和层次现在回到标题的核心问题终端智能体的对比为什么总显得自相矛盾。我把原因归结为六点每一点都能制造一倍的性能波动。4.1 评测任务定义不统一大部分公开任务集把“操作任务”定义成自然语言描述比如“打开深色模式”。这看起来清楚实际上执行路径不止一条有人从快捷开关面板进入有人从设置页进入有人用语音命令触发。如果评测时没有把“可接受的执行方式”限定清楚不同方案就会采用不同路径成功率从统计口径上就已经不一致了。更麻烦的是成功标准。有的评测把“打开深色模式设置页”也算成功有的要求“深色模式开关的确被打开”还有的进一步要求“页面要显示切换成功的回执”。标准宽松与否能直接让最终分数差出一大截。4.2 设备环境和系统状态不可控终端智能体运行在真实设备上而真实设备的状态千差万别。同一台手机清空后台应用和满载后台应用点击响应时间完全不同同一个设置页第一次进入有引导浮层第二次进入没有这会影响视觉识别还有系统主题、字体大小、屏幕分辨率都会改变截图输入的内容。很多对比没有固定这些变量得出的结果自然无法复现。如果要复现一条测试结果应该固定设备型号、系统版本、分辨率、字体大小、系统主题最好连当前打开的 App 栈和弹窗状态都做成预设快照。做不到严格快照的评测只能算“样例演示”不能算严谨对比。4.3 模型版本和部署方式不一致很多团队在写对比报告时并没有明确标注模型版本和部署方式。有的用云端旗舰模型有的用端侧量化模型有的模型已经更新了版本但报告中没有同步。模型能力每更新一次同一任务的推理链可能完全改变最终表现呈现“跳变式”波动。正确的做法是对比时记录模型唯一标识包括版本号、权重来源、量化级别、输入分辨率限制。部署方式也要写清楚是纯端侧推理、端云混合、还是走云端代理。这些信息不记录分数单看就没有意义。4.4 界面差异和动态变化因素评测的界面如果是固定 web 页面相对可控。一旦进入真实应用动态变化因素显著增加广告弹窗、热更新引导、推荐流内容变化、网络图片加载速度不统一。智能体为了处理这些动态因素通常会加入等待策略和重试策略但策略参数不同在高动态界面上得分方差极大。这也是为什么同一方案在一台清静的设备上表现惊艳在另一台装有大量预装应用的设备上突然“脑子失灵”。不是模型变笨了而是测试环境里噪声太多了。4.5 评测数据集污染过拟合现在公开的终端智能体任务集比较有限高频出现在论文和报告里。某些方案的训练阶段可能已经见过这些任务样本准确说叫“测试集泄露”或“任务集过拟合”。这种情况下方案的分数反映的不是通用能力而是对固定任务集的记忆能力。识别这种问题比较难比较保守的做法是选择评测集之外的新任务做盲测观察成功率是否明显下降。如果只靠公开任务集给出一个漂亮分数选型时要谨慎。4.6 权限弹窗与交互确认机制的影响最后是权限机制。不同方案处理权限弹窗的策略差异极大有的方案每次弹窗前先暂停等待用户处理有的方案尝试自动点击允许有的方案把需要授权的能力直接列入不可用。这些设计选择直接影响任务成功率。评测时如果没有把“用户是否预授权”“授权方式是什么”写明数字对比就失真了。综合上面六点可以得出一个结论终端智能体对比出现矛盾不一定是数据造假更大概率是变量没有控制。任何没有说明评测变量控制的成绩单都只能作为参考信号不能当作选型终判。5. 设计一个可复现的终端智能体评测基线既然对比矛盾的原因是坐标系不统一那解决思路也很直接先建立一个各方认可的评测基线把变量和口径固定下来再谈成绩差异。这里给出一套可以落地的评测基线设计思路。5.1 第一步定义评测任务集任务集设计不能只写任务名。每条评测用例至少要包含场景描述、入口状态、执行方式约束、成功标准、禁止行为。下面是一个示例 JSON 配置{ task_id: phone_settings_001, task_name: 在设置中打开深色模式, description: 用户希望将系统设置为深色模式, start_state: { app: 系统设置, screen: 设置首页, preload_apps: [phone, message] }, accepted_path: [设置-显示与亮度-深色模式, 下拉快捷面板-深色模式开关], success_criteria: 系统深色模式开关的状态被切换为开启且界面出现深色主题, forbidden_action: 清理系统数据、修改开发者选项、使用root权限, allowed_tools: [click, swipe, back, home, text_input, open_app], max_steps: 10, timeout_seconds: 60 }评测执行时这个 JSON 就是执行器的输入。评测人员不需要人工判断“这次算不算成功”只需要把最终状态交给脚本自动校验。执行方式约束和禁止行为两条字段是避免不同方案各走各路的关键。5.2 第二步固定设备与环境变量评测前把所有非任务变量固定下来并以清单形式记录。建议至少包括以下字段环境维度需要固定或记录的参数设备型号具体品牌型号、内存版本系统版本OS 大版本号、补丁号显示设置分辨率、字体大小、深色/浅色模式应用状态是否登录、是否完成新手引导、后台应用列表网络环境是否连接 Wi-Fi、是否有代理权限状态摄像头、存储、网络等权限的初始状态模型配置模型唯一标识、推理框架、量化级别框架配置Agent 版本、工具集版本、超时阈值环境清单不是给人看的而是评测执行脚本的一部分。每跑完一轮脚本自动把环境参数写入结果文件后续核对时可以直接对比。5.3 第三步执行评测并记录结构化日志评测执行不能只看最终成功率。系统应该为每个任务记录完整的交互轨迹包括每一轮感知截图、状态树摘要、模型输出、动作调用的函数名、参数、返回值、耗时。记录这些日志一方面是为了失败定位另一方面也是为了让不同团队之间可以复盘“同一任务不同结论”到底发生在哪一步。一个最小化的评测执行脚本可以这样做import json import time def load_tasks(task_file): with open(task_file, r, encodingutf-8) as f: return json.load(f) def run_one_task(agent, task): # 重置设备到预设状态 agent.reset(task[start_state]) start_time time.time() steps 0 while not agent.is_task_finished(): if steps task[max_steps]: return {task_id: task[task_id], result: fail, reason: max_steps_exceeded} action agent.next_action() if action not in task[allowed_tools]: return {task_id: task[task_id], result: fail, reason: forbidden_tool} observation agent.execute(action) agent.update_context(observation) steps 1 return { task_id: task[task_id], result: success, steps: steps, elapsed: round(time.time() - start_time, 3), } def run_suite(agent, task_file): tasks load_tasks(task_file) results [run_one_task(agent, t) for t in tasks] success_count sum(1 for r in results if r[result] success) return { total: len(results), success: success_count, success_rate: round(success_count / len(results), 4), details: results, } if __name__ __main__: import sys # 这里 agent 需要替换成你的终端智能体执行器实例 agent sys.argv[1] result run_suite(agent, task_suite.json) print(json.dumps(result, ensure_asciiFalse, indent2))运行命令大概是python eval_agent.py --agent MyAgent --task-file task_suite.json --device-device-id 123456 --output result.json实际项目中agent 参数应该传入一个加载了模型、工具集、上下文策略的执行器对象。这个脚本的价值不在代码本身而在于把评测规则固化成了可执行文件。只要两份报告使用的 task_suite.json 相同设备快照相同跑出来的数字才有可比性。5.4 第四步结果分析要区分错误类型评测结果不能只统计成功率。同一个失败可能来自不同阶段建议把失败归类为感知失败控件树被破坏或截图不完整模型没有拿到真实状态。规划失败感知正确但模型选择了错误动作路径。执行失败动作发出但系统没有响应或权限不足。验证失败动作已生效但系统没有正确确认导致重复操作。只有把失败点定位到具体组件才能准确回答“这个方案到底哪里不行”也才能避免后续对比陷入无意义的整体分数比较。6. 从评测到工程落地接入终端智能体时的配置与验证评测基线解决的是“怎么比”工程落地解决的是“怎么稳”。不管你自研还是集成现成方案接进真实产品时都有几个关键点需要重点控制。6.1 最小可运行集成路径先把链路跑通再加优化。最小集成路径包括四步申请并配置设备权限、加载端侧模型或接入云端接口、注册工具集、启动任务循环。权限配置要按最小权限来比如先只授权自动化点击和读取 UI 节点不开放截图保存和文件读取模型加载先用小参数配置验证吞吐量满足交互要求工具集先注册 5 到 8 个核心动作跑通后再扩展。6.2 上下文与超时配置示例工程实现中最影响真实用户体验的是超时和重试参数。下面是一份配置示例重点关注超时阈值的设定{ agent: { max_turns: 10, page_load_timeout_ms: 3000, action_timeout_ms: 2000, retry_times: 2, enable_verification: true, memory: { mode: summary, max_history_turns: 20, summary_model: local-small } }, privacy: { sensitive_fields: [password, verification_code], confirm_actions: [pay, delete, send_message] } }这里的retry_times不宜设置过大否则会出现一个错误操作反复执行三次的情况。实际项目更推荐“Retry-Change-Path”策略第一次失败重试第二次失败换一条操作路径第三次失败转向用户确认。固定重试次数虽然实现简单但很容易在动态页面中放大错误。6.3 工具调用的行为日志接入终端智能体后一定要输出结构化行为日志。一条典型日志应该包含动作事件 ID、当前任务 ID、动作名称、输入参数、返回值、耗时、页面状态标识。不要只记录模型文本。没有结构化日志后续排错和用户问题回溯都会非常痛苦。建议日志格式{ event_id: a1f8d0e2, task_id: phone_settings_001, action: click, params: {target: 深色模式}, result: ok, elapsed_ms: 320, screen_hash: 6f4b2d91 }加了 screen_hash 之后即使后续没有保存截图也可以通过哈希定位到“当时屏幕状态是否一致”对复现问题帮助很大。6.4 回滚与降级策略生产环境里的终端智能体不能只考虑“正常运行”。当任务执行到一半出现未知状态时系统应当具备两条逃生通道一是任务级回滚把系统状态恢复到操作前二是能力降级智能体把控制权交还给用户并把当前步骤的说明显示给用户。降级不是失败而是一个负责任的设计。7. 常见问题与排查方法终端智能体运行过程中问题现象往往不直接指向根因。下面整理一些高频问题按“现象、原因、排查、解决”来拆解。问题现象可能原因排查方式解决方案同一任务多次执行结果波动明显页面动态加载过快导致感知到中间状态查看感知日志中的截图和控件树时间戳增加 page_load_timeout等待控件树稳定后再决策Agent 点击了正确控件但界面没有反应控件层级过深或点击坐标偏移检查执行器返回值和点击坐标离控件中心距离修正无障碍节点点击逻辑或改用点击控件中心点任务执行到一半突然中断上下文超出模型窗口导致关键状态被截断查看模型请求的 token 占用和截断位置启用摘要记忆对早期步骤做压缩权限弹窗后任务卡住权限策略未允许智能体自动处理弹窗检查工具调用日志和权限状态在授权策略中增加弹窗检测规则或明确交给用户确认两个方案对比分数相差大但无法复现测试设备或系统版本不一致查看运行环境清单是否完整记录所有评测执行固定环境快照模型频繁重复执行同一个错误动作验证机制缺失或 retry_times 过大观察行为日志中的重复动作序列引入执行验证和动态路径切换应用版本更新后成功率骤降控件树结构和文字标签变化对比更新前后界面结构差异建立控件识别语义匹配避免只依赖固定资源 ID端侧推理速度过慢模型量化级别不足或设备算力受限统计每轮推理耗时切换更小参数量模型或改用端云混合策略排查时最先看的是行为日志和感知日志而不是直接看模型推理的 prompt。多数问题发生在执行层和感知层模型往往只是忠实执行了它看到的错误环境。8. 最佳实践与选型建议结合前面的分析这里给出一套关于终端智能体工程落地与选型的建议。8.1 选型时先问三个问题你的任务集是偏系统设置类还是偏第三方 App 操作类前者权限可控、界面稳定后者动态变化大、失败率高。你的运行场景允许端云混合吗对于延迟不敏感、隐私要求不极端的任务端云混合方案往往比纯端侧方案稳定性高。你的团队具备模型调优能力还是只做集成只做集成就要重点考察框架的工程稳定性而不是只看模型跑分。这三个问题的答案比任何一份对比报告都更能帮助选型。8.2 评测不要只跑公共任务集公共任务集的目的是横向对照不是能力上限。任何方案在公共任务集上表现好都要考虑过拟合风险。选型阶段应该额外设计一批私有业务任务覆盖自己真实产品中最常见的高频场景比如“修改收货地址”“切换消息免打扰”“查看某 App 的实时数据”。私有任务集第一次跑出来的成功率往往低于公共任务集这很正常。一个方案如果私有任务集的表现也能稳定在可用线以上才值得进入深一步测试。8.3 安全边界与用户确认策略终端智能体在生产环境中的权限边界建议采用三层策略默认拒未明确授权的能力默认不可用。受限执行可以执行但执行前需要弹窗确认。完全授权高频且低风险的操作可以静默执行。按这个策略支付、删除数据、发送对外消息需要弹窗打开应用、切换设置、查询信息可以授权执行。敏感信息输入由用户自己在系统原生文本框中完成。这样既保证效率也守住安全底线。8.4 团队协作中的基线冻结如果团队需要长期维护终端智能体的评测指标一定要做好基线冻结。把模型权重、Agent 框架版本、工具集版本、评测任务集版本四个维度的组合统一记录每次发布新版本时重新跑一轮完整评测。不要只更新其中的模型版本而忽略其他部分否则历史指标会失真。9. 总结与后续学习方向回到文章标题提的问题。终端智能体的对比之所以矛盾本质上不是某一方错了而是对比中的变量没有被控制。没有统一任务定义、没有固定设备环境、没有记录模型版本、没有说明权限策略任何分数都只是特定条件下的一种表现不能当作通用能力。理解了这一点以后再看任何一份终端智能体对比报告你都会先问三个问题用什么任务测的环境基线是什么成功标准如何判断这三个问题没有答案报告就等于没写。如果你想继续深入建议从三个方向展开一是熟悉主流终端智能体框架的工具定义和上下文管理实现这是工程绕不开的二是设计一套自己的私有任务评测集并跑通结构化评测流程三是关注端侧模型量化与推理加速这决定了终端智能体在低算力设备上的可用性。终端智能体还处在快速迭代阶段方案间的差异远没有收敛。保持怀疑、控制变量、以工程结果为准是现阶段最实用的态度也可以直接用于你自己的选型过程。