1. 为什么我会盯上 ARTEMIS 这个项目第一次看到 ARTEMIS 这个名字的时候我脑子里蹦出来的其实是那个希腊神话里的狩猎女神跟移动端自动化八竿子打不着。但仔细看完谷歌开源的这套东西之后我发现这个命名还挺贴切——它确实像一个精准的猎手能代替人的手指在手机屏幕上完成一系列操作。先说清楚它到底是什么。ARTEMIS 是谷歌开源的一个移动端 AI 自动化框架核心能力是让 AI 助手像真人一样去操作 Android 手机。注意这里的措辞不是简单的脚本录制回放也不是基于坐标的点击模拟而是让 AI 去“理解”屏幕上的内容然后决定下一步该点哪里、输入什么、滑动到什么位置。这个区别非常关键后面我会展开讲。它能解决的问题其实很具体。做过移动端测试或者自动化的人都清楚传统的方案无非几种一是基于 UI Automator 或者 Appium 这类框架靠控件 ID、XPath 或者坐标来定位元素二是录制回放工具把人的操作录下来再重放。这两种方案在稳定环境里还行一旦页面结构变了、弹窗出现了、加载慢了脚本就崩了。ARTEMIS 想做的事情是让 AI 来看屏幕截图像人一样判断“现在这个界面上我要完成登录应该点哪个位置”从而绕开对固定控件路径的依赖。适合谁来参考呢我梳理了一下大概三类人收益最大。第一类是做移动端自动化测试的工程师尤其是被 UI 频繁变更折磨过的第二类是在做 AI Agent 相关产品的开发者想找一个移动端落地的参考实现第三类是对多模态大模型应用感兴趣的技术爱好者想看看视觉语言模型怎么跟真实设备交互。如果你只是想做简单的批量点击脚本那用不着上这套框架杀鸡用牛刀了。我之所以花时间研究它是因为过去两年我在几个项目里尝试过把大模型接入移动端操作流程踩了不少坑。ARTEMIS 的出现让我看到了一种更系统的解法所以这篇就当作是我自己的一次完整梳理把框架的设计思路、核心机制、实操要点和我踩过的坑都摊开来讲。2. 框架整体设计与思路拆解2.1 传统移动端自动化的死穴在哪要理解 ARTEMIS 为什么这么设计得先搞清楚传统方案到底卡在什么地方。我用一个真实的例子来说明。之前我做过一个电商 App 的自动化流程任务是每天定时去签到领积分。用 Appium 写脚本的话大概是这样找到“我的”这个 tab点击等待页面加载找到“签到”按钮点击处理可能出现的弹窗确认签到成功。听起来简单但实际跑起来问题一堆。App 版本一更新“签到”按钮的 resource-id 变了脚本直接找不到元素。网络慢的时候页面还没加载完脚本就开始找元素报超时。偶尔弹出一个活动推广弹窗把签到按钮挡住了脚本点到了弹窗上。这些问题的本质是什么是传统自动化依赖的是“结构化的定位信息”也就是控件的属性、层级、坐标。但真实的使用场景是动态的、不确定的页面结构会变弹窗会随机出现加载时间会波动。人为什么能应对因为人是看着屏幕理解屏幕上有什么然后决定怎么做。人不需要知道按钮的 resource-id 是什么人只需要看到“签到”两个字就知道该点那里。ARTEMIS 的核心思路就是把这个“人看屏幕做决策”的过程用 AI 复现出来。它不依赖控件树而是依赖屏幕的视觉信息和语义理解。2.2 视觉感知加语义决策的双层架构ARTEMIS 的架构我拆成了两层来理解这样比较清晰。第一层是视觉感知层。它负责把手机屏幕的当前状态“看懂”。具体来说它会截取当前屏幕的画面然后通过多模态模型能同时理解图像和文字的模型来解析这个画面里有什么。比如画面上有一个登录表单有两个输入框一个写着“手机号”一个写着“密码”还有一个蓝色的“登录”按钮。这些信息不是从控件树里读出来的而是模型从像素里“看”出来的。第二层是语义决策层。它负责根据当前的任务目标决定下一步动作。比如任务是“登录账号”当前画面是登录页那模型就会判断需要先在手机号输入框里输入号码然后在密码框输入密码最后点击登录按钮。这个决策过程是基于对任务的理解和对当前画面的理解共同得出的。这两层之间还有一个动作执行层负责把决策转化成真实的触摸、输入、滑动等操作。这一层相对传统就是调用 Android 的输入注入能力把点击坐标、输入文本这些指令发出去。我之所以强调这个双层架构是因为它决定了 ARTEMIS 的能力边界。它的优势在于泛化能力强页面变了、弹窗来了只要模型能看懂就能应对。但它的劣势也很明显就是速度和成本。每次决策都要截屏、调模型、等返回这个链路比直接查控件树慢得多。所以它适合的场景是那些对稳定性要求高、对速度要求不那么极致的任务比如自动化测试、辅助操作、流程验证而不是高频的批量操作。2.3 为什么选择“像人一样操作”而不是“像程序一样调用”这个问题我琢磨了很久。从工程效率的角度看直接调用系统 API 或者走控件树肯定更快更准。但 ARTEMIS 偏偏选择了最“笨”的方式——模拟人的操作。我理解这背后有几个考量。第一是通用性。控件树的信息在不同 App、不同版本、不同系统上差异很大要写一套通用的解析逻辑非常困难。但“看屏幕”这件事是通用的不管什么 App屏幕上的内容对人来说都是一样的。用视觉方案理论上可以跨 App、跨版本工作不需要为每个目标单独适配。第二是鲁棒性。真实环境里充满了不确定性弹窗、广告、加载延迟、权限请求这些用固定脚本很难穷举。但人面对这些情况能灵活应对因为人能理解“现在弹出了一个更新提示我需要先关掉它”。视觉加语义的方案天然具备这种应对能力。第三是降低门槛。写传统自动化脚本需要懂控件定位、需要会写代码、需要调试选择器。但如果用自然语言描述任务比如“帮我打开设置把亮度调到最低”AI 就能自己去操作那使用门槛就大大降低了。这对非技术用户来说意义很大。当然这个选择也带来了代价。我在实际测试中发现同样的任务ARTEMIS 的耗时大概是传统脚本的三到五倍。所以它不是要取代传统方案而是开辟了一个新的适用场景。2.4 与同类方案的横向对比为了把 ARTEMIS 的定位说清楚我把它和几个常见的方案做了个对比。方案类型代表工具定位方式泛化能力执行速度适用场景控件树自动化Appium、UI Automator控件属性、层级弱页面变更即失效快稳定环境的回归测试坐标录制回放各类录制工具固定坐标极弱分辨率变化即失效极快单一设备的固定流程图像模板匹配Airtest 等图像特征匹配中等受分辨率和主题影响中等游戏、固定界面视觉语言模型驱动ARTEMIS屏幕语义理解强能应对变化慢复杂流程、跨版本测试、AI Agent从这个表能看出来ARTEMIS 的差异化在于泛化能力。它牺牲了速度换取了适应变化的能力。这个取舍在什么情况下划算我的经验是当维护脚本的成本高于执行脚本的成本时就划算。比如一个流程每周都要因为 UI 变更而修改脚本那用 ARTEMIS 虽然每次跑得慢但省下了大量维护时间总体是赚的。3. 核心细节解析与实操要点3.1 环境搭建的关键步骤与坑点ARTEMIS 的运行环境搭建我踩了不少坑这里把关键步骤和容易出问题的地方都列出来。首先是Android 设备或模拟器的准备。你需要一台 Android 手机或者一个模拟器开启开发者模式和 USB 调试。这里有个细节模拟器的选择很重要。我一开始用的是默认的 AVD 模拟器发现截屏速度很慢而且偶尔会黑屏。后来换成了带硬件加速的模拟器情况好了很多。如果你用真机建议用数据线连接而不是无线调试因为截屏传输的数据量不小无线会有延迟。然后是Python 环境。ARTEMIS 是基于 Python 的建议用 3.10 以上的版本。我试过 3.8有些依赖装不上。虚拟环境一定要建因为它的依赖里有一些对版本比较敏感的包跟系统环境混在一起容易冲突。python -m venv artemis_env source artemis_env/bin/activate # Linux/Mac # 或者 Windows 下 artemis_env\Scripts\activate接着是ADB 工具的配置。ARTEMIS 通过 ADB 跟设备通信所以 ADB 必须在 PATH 里能直接调用。验证方法是运行adb devices能看到设备列表就说明通了。这里有个常见问题Windows 上 ADB 驱动有时候装不上设备管理器里会显示一个带感叹号的未知设备。解决办法是去设备厂商官网下载对应的 USB 驱动或者用通用的 Google USB Driver。最后是模型接口的配置。ARTEMIS 需要调用多模态模型来做视觉理解所以你需要配置模型服务的访问方式。这部分我建议先用官方推荐的默认配置跑通再根据自己的需求调整。配置项一般包括服务地址、认证信息、模型名称这些。注意环境搭建阶段最容易出问题的是 ADB 连接和模型接口配置这两块。建议先用一个最简单的任务比如打开设置来验证整条链路是否通畅再去跑复杂流程。3.2 屏幕理解机制到底是怎么工作的这是 ARTEMIS 最核心的部分我尽量用大白话讲清楚。当你给 ARTEMIS 一个任务比如“打开微信给文件传输助手发一条消息说你好”它会经历这样一个循环。第一步截屏。通过 ADB 抓取当前屏幕的截图得到一个图像文件。第二步画面解析。把截图和当前的任务目标一起送给多模态模型。模型会输出对当前画面的理解比如“当前是微信的聊天列表页面顶部有搜索框中间是聊天记录列表底部有四个 tab微信、通讯录、发现、我”。第三步动作决策。模型根据任务目标和画面理解决定下一步动作。比如“任务是要给文件传输助手发消息当前在聊天列表需要先找到文件传输助手这个聊天项并点击”。模型会输出一个结构化的动作指令包括动作类型点击、目标描述文件传输助手聊天项、以及可能的坐标估计。第四步动作执行。ARTEMIS 把动作指令转化成 ADB 命令比如adb shell input tap x y在设备上执行。第五步结果验证。执行完动作后再次截屏让模型判断动作是否成功任务是否完成。如果没完成继续循环。这个循环听起来简单但实际运行中有很多细节会影响效果。我举几个我遇到的情况。一个是坐标估计的精度问题。模型输出的是对目标位置的估计有时候会有偏差。比如它说点击“文件传输助手”但给出的坐标偏了一点点到了旁边的聊天项。ARTEMIS 的处理方式是在动作指令里不仅包含坐标还包含目标的语义描述。执行时会结合两者如果坐标位置的内容跟描述不符会尝试修正。另一个是多步任务的上下文保持。有些任务需要多步操作比如“打开设置找到显示把亮度调到最低”。这中间涉及多次页面跳转模型需要记住之前做了什么、当前在哪一步。ARTEMIS 通过维护一个任务执行历史来解决这个问题每次决策时都会把历史一起送给模型参考。还有一个是异常情况的处理。比如操作过程中突然来了一个电话、弹出了一个系统更新提示、或者网络断了导致页面加载失败。这些情况模型需要能识别并做出合理应对比如先关掉弹窗、等待加载完成再继续。这部分能力很大程度上取决于模型本身的泛化能力ARTEMIS 框架层面提供的是把异常情况暴露给模型、让模型决策的机制。3.3 任务描述怎么写才能让 AI 听懂这是实操中非常关键的一点任务描述的质量直接决定了执行效果。我总结了几条经验。第一目标要明确不要模糊。比如“帮我处理一下消息”这种描述AI 不知道你要处理什么消息、怎么处理。改成“打开微信找到文件传输助手发送一条内容为‘测试消息’的文字”就清晰多了。第二步骤要合理拆分。虽然 ARTEMIS 支持多步任务但一次给太复杂的任务模型容易在中途迷失。我的做法是把大任务拆成几个子任务分步执行。比如“登录账号并签到”可以拆成“登录账号”和“执行签到”两步。第三对关键界面状态要有预期描述。比如你知道登录后会弹出一个广告弹窗可以在任务描述里加一句“如果出现广告弹窗先关闭它”。这样模型在遇到这个情况时就有明确的处理指引。第四善用条件描述。ARTEMIS 支持在任务里写条件逻辑比如“如果当前页面有‘跳过’按钮点击它否则继续下一步”。这种描述能显著提升流程的鲁棒性。我整理了一个任务描述的对比表方便理解。描述质量示例问题差帮我签到不知道在哪个 App 签到、签到入口在哪中打开某 App找到签到按钮并点击没说遇到弹窗怎么办、签到成功怎么判断好打开某 App进入“我的”页面找到“每日签到”按钮并点击如果出现弹窗先关闭弹窗再继续签到后确认页面显示“已签到”目标明确、异常有预案、完成有验证3.4 动作执行层的几个实操细节动作执行层看起来简单就是发 ADB 命令但实际用起来有几个细节值得注意。点击操作。ARTEMIS 支持点击、长按、双击等。点击的坐标是模型估计的但框架会做一个校验在点击之前先确认目标坐标附近的内容跟预期描述是否匹配。这个校验能过滤掉一部分坐标偏差导致的问题。文本输入。输入文本比点击复杂因为涉及中文输入、特殊字符、输入法状态等。ARTEMIS 的处理方式是先点击输入框获取焦点然后通过 ADB 的输入命令发送文本。这里有个坑ADB 的input text命令对中文支持不好直接发中文可能会乱码。解决办法是先把中文转成 Unicode 编码再发送或者用剪贴板的方式粘贴。我在实操中用的是剪贴板方案更稳定。滑动操作。滑动用于滚动列表、切换页面等。ARTEMIS 支持指定方向和距离的滑动也支持滑动到某个元素出现为止。后者的实现方式是循环滑动加截屏检测直到目标出现或达到最大次数。等待与超时。每个动作执行后ARTEMIS 会等待一段时间再截屏验证。这个等待时间需要根据实际情况调整。太短了页面还没加载完太长了整体效率低。我的经验是设置一个基础等待时间比如 1 秒然后根据页面加载情况动态调整。提示文本输入是实操中最容易出问题的环节。建议在正式跑流程之前先单独测试一下中文输入是否正常避免跑到一半卡在输入环节。4. 实操过程与核心环节实现4.1 从零跑通第一个自动化任务这一节我完整记录一下从零开始跑通一个任务的过程包括每一步的命令和实际效果。假设我们的任务是打开 Android 设置进入显示设置把亮度调到最低。第一步确认设备连接。adb devices输出应该类似List of devices attached emulator-5554 device如果显示unauthorized需要在手机上确认 USB 调试授权。如果列表为空检查数据线连接和驱动。第二步安装 ARTEMIS。pip install artemis-automation具体的包名以官方仓库为准我这里用的是示意。安装完成后验证一下python -c import artemis; print(artemis.__version__)第三步配置模型接口。在项目目录下创建一个配置文件填入模型服务的地址和认证信息。具体格式参考官方文档一般是一个 YAML 或 JSON 文件。第四步编写任务脚本。from artemis import ArtemisAgent agent ArtemisAgent( device_idemulator-5554, model_configconfig.yaml ) task 打开设置应用进入显示设置页面 找到亮度调节滑块将其拖动到最左侧最低亮度。 完成后确认亮度已经是最低状态。 result agent.run(task) print(result)第五步运行并观察。python run_task.py运行过程中你会看到 ARTEMIS 不断地截屏、分析、执行动作。终端会输出每一步的决策日志比如“当前页面设置首页决策点击‘显示’选项”。我第一次跑的时候在“找到亮度调节滑块”这一步卡住了。原因是设置应用里的亮度调节是一个滑块控件模型能识别出它的位置但拖动操作需要指定起点和终点坐标。ARTEMIS 对滑块类控件的处理是先点击滑块然后用方向键调整。这个逻辑在框架里是内置的但需要模型正确识别出这是一个可调节的滑块。4.2 参数选择与性能调优跑通基本流程之后下一步就是调优。ARTEMIS 有几个关键参数会显著影响执行效果和速度。截屏间隔。每次动作执行后到下一次截屏之间的等待时间。默认值可能偏保守导致整体速度慢。我的做法是根据页面类型设置不同的间隔静态页面设短一点0.5 秒有网络加载的页面设长一点2 秒。最大重试次数。当一个动作执行后没有达到预期效果时ARTEMIS 会重试。重试次数设太少遇到偶发问题就失败了设太多遇到死循环会卡很久。我一般设 3 次配合超时机制使用。模型温度参数。这个参数影响模型输出的随机性。做自动化任务时我希望模型输出稳定、可预测所以温度设得比较低0.1 左右。温度太高会导致同样的画面每次决策不一样流程不稳定。动作执行超时。单个动作执行的超时时间。比如点击操作如果 5 秒内没有完成就判定为失败。这个值需要根据设备性能调整老设备要设长一点。我整理了一个参数调优的参考表。参数默认值建议值影响截屏间隔1.0s0.5-2.0s按页面类型影响速度和稳定性最大重试次数53影响容错和耗时模型温度0.70.1影响决策稳定性动作超时10s5-15s按设备影响失败判定最大步数50按任务复杂度防止无限循环4.3 一个完整的多步任务实战记录为了展示 ARTEMIS 在复杂场景下的表现我记录了一个多步任务的完整执行过程。任务是打开微信搜索一个联系人发送一条消息然后返回聊天列表。任务描述打开微信应用。 如果出现登录页面说明账号未登录任务终止并报告。 进入微信后点击顶部的搜索框。 在搜索框中输入联系人名称“张三”。 在搜索结果中点击对应的联系人进入聊天页面。 在聊天输入框中输入“你好这是一条测试消息”。 点击发送按钮。 发送成功后返回聊天列表页面。 确认消息已发送聊天列表中该联系人显示最新消息。执行过程记录第一步ARTEMIS 截屏识别出当前是手机桌面。模型决策需要找到微信图标并点击。执行点击微信启动。第二步截屏识别出微信启动页。模型决策等待加载。ARTEMIS 等待 2 秒后再次截屏。第三步截屏识别出微信聊天列表页面。模型决策点击顶部搜索框。执行点击。第四步截屏识别出搜索页面光标已在搜索框内。模型决策输入“张三”。执行文本输入。第五步截屏识别出搜索结果列表第一个结果是“张三”。模型决策点击第一个搜索结果。执行点击。第六步截屏识别出聊天页面顶部显示联系人名称“张三”。模型决策点击输入框。执行点击。第七步截屏识别出输入框已激活键盘弹出。模型决策输入消息内容。执行文本输入。第八步截屏识别出输入框中有文字发送按钮可用。模型决策点击发送按钮。执行点击。第九步截屏识别出消息已出现在聊天记录中。模型决策点击返回按钮。执行点击。第十步截屏识别出已回到聊天列表该联系人显示最新消息。模型决策任务完成。整个流程跑了大概 40 秒其中大部分时间花在截屏和模型推理上。如果换成传统脚本可能 10 秒就跑完了。但传统脚本需要精确的控件定位微信版本一更新就可能失效。ARTEMIS 的方案虽然慢但胜在稳定。4.4 把 ARTEMIS 接入现有测试流程如果你已经有了一套自动化测试流程想把 ARTEMIS 集成进去有几个接入点可以考虑。作为补充测试手段。在传统脚本覆盖不到的场景比如跨 App 流程、异常弹窗处理用 ARTEMIS 来补充。两者可以共存各取所长。作为脚本生成器。用 ARTEMIS 跑一遍流程记录下每一步的决策和动作然后人工整理成传统脚本。这样可以利用 ARTEMIS 的泛化能力来发现流程中的关键步骤再用传统脚本实现高效执行。作为监控和修复工具。当传统脚本失败时触发 ARTEMIS 去分析失败原因甚至自动修复。比如脚本找不到某个按钮ARTEMIS 可以截屏分析当前页面判断按钮是否被弹窗遮挡、是否改名了、是否位置变了然后给出修复建议。我在一个项目里尝试过第三种方式效果还不错。传统脚本每天跑回归测试失败的时候自动触发 ARTEMIS 去复现问题并截屏记录大大减少了排查时间。5. 常见问题与排查技巧实录5.1 设备连接类问题速查设备连接是最高频的问题来源我整理了一个速查表。现象可能原因排查方法解决方案adb devices 列表为空数据线问题、驱动未装换线、检查设备管理器安装对应 USB 驱动显示 unauthorized未授权调试手机上看是否有授权弹窗重新插拔、确认授权显示 offlineADB 服务异常重启 ADB 服务adb kill-server adb start-server连接不稳定无线调试、USB 口供电不足换有线、换 USB 口用带供电的 USB Hub截屏黑屏模拟器渲染问题换模拟器或真机开启硬件加速5.2 模型决策类问题排查模型决策出问题的时候排查起来比较麻烦因为涉及模型的黑盒。我总结了几种典型情况和应对方法。决策循环。模型反复执行同一个动作比如一直点击同一个位置。这通常是因为动作执行后页面没有变化模型以为没成功就重试。解决办法是检查动作是否真的生效了如果生效了但页面没变需要在任务描述里说明这种情况。决策偏离。模型执行了跟任务无关的动作。比如任务是发消息它却去点了朋友圈。这通常是任务描述不够清晰或者当前页面有干扰元素。解决办法是细化任务描述明确当前应该做什么。识别错误。模型把 A 元素识别成了 B 元素。比如把“取消”按钮识别成了“确认”。这跟模型能力有关可以通过提高截屏质量、调整模型参数来改善。如果某个界面特别容易识别错可以在任务描述里加一些辅助描述比如“确认按钮在右下角蓝色背景”。动作失败。模型决策正确但执行失败。比如要点击一个元素但坐标偏了。ARTEMIS 有坐标校验机制但有时候还是会失败。解决办法是增加重试次数或者在任务描述里描述得更精确。5.3 性能优化实战技巧ARTEMIS 跑得慢是公认的但通过一些技巧可以显著提速。减少不必要的截屏。不是每一步都需要截屏验证。比如连续输入多个字段可以在全部输入完成后再截屏验证一次而不是每输入一个就截屏。缓存页面理解结果。如果连续几步都在同一个页面操作页面理解结果可以复用不需要每次都重新分析。并行处理。截屏和模型推理可以并行。在等待模型返回结果的时候可以预先截取下一张屏幕。当然这需要框架支持ARTEMIS 的部分版本有这个优化。选择合适的模型。多模态模型有大有小大模型准确但慢小模型快但可能不准。根据任务复杂度选择合适的模型。简单任务用小模型复杂任务用大模型。优化任务描述。描述越清晰模型决策越快越准。模糊的描述会导致模型反复尝试浪费时间。5.4 我踩过的几个印象深刻的坑第一个坑是中文输入乱码。前面提过ADB 的 input text 对中文支持不好。我一开始没注意跑任务的时候发现输入的中文全变成了问号。后来改用剪贴板方案先adb shell am broadcast把文本放到剪贴板再模拟粘贴操作才解决。第二个坑是模拟器时间不同步。我用模拟器跑一个跟时间相关的任务发现模拟器的时间跟宿主机不一致导致任务逻辑出错。解决办法是在模拟器设置里开启时间同步或者定期手动同步。第三个坑是权限弹窗。Android 首次使用某些功能会弹权限请求比如存储权限、通知权限。这些弹窗会打断自动化流程。我的做法是在任务开始前先用 ADB 命令预先授予所需权限避免运行中弹窗。第四个坑是输入法状态。如果设备上装了多个输入法输入框激活时弹出的键盘可能不一样导致输入行为不一致。解决办法是固定使用系统默认输入法或者在任务开始前切换到指定输入法。第五个坑是屏幕常亮。自动化跑久了手机自动锁屏流程就断了。解决办法是在开发者选项里开启“充电时不锁屏”或者用 ADB 命令保持屏幕常亮。提示这些坑看起来都是小问题但每一个都能让整个流程跑不下去。建议在正式使用前把这些环境问题都排查一遍能省下大量调试时间。6. 这套框架适合什么场景不适合什么场景用了这段时间我对 ARTEMIS 的适用边界有了比较清晰的认识。适合的场景我列几个。一是跨版本的回归测试尤其是 UI 频繁变更的 App传统脚本维护成本太高用 ARTEMIS 虽然慢但省心。二是复杂流程的验证比如涉及多个 App 跳转、多种异常处理的流程。三是 AI Agent 的产品原型想快速验证“AI 操作手机”这个概念的可行性。四是非技术人员的自动化需求用自然语言描述任务就能跑不需要学编程。不适合的场景也要说清楚。一是高频批量操作比如批量点赞、批量发消息ARTEMIS 的速度撑不住。二是对精度要求极高的操作比如金融类 App 的精确输入模型估计的坐标可能不够准。三是长时间运行的任务模型调用有成本跑几个小时成本不低。四是完全固定的流程如果页面从来不变用传统脚本更高效。我个人的判断是ARTEMIS 代表了一个方向就是让自动化从“精确编程”走向“语义驱动”。这个方向的价值在于降低门槛、提升泛化能力。虽然现在还有速度和成本的限制但随着模型能力提升和推理成本下降这类方案的应用空间会越来越大。最后分享一个我在实操中总结的小技巧。如果你要跑一个比较长的任务建议在中间设置几个检查点每个检查点验证一下当前状态是否符合预期。这样一旦出问题能快速定位是哪一步开始偏的而不是跑完整条流程再回头排查。这个习惯帮我省了很多时间。