1. 项目概述当大语言模型学会“看”与“动”最近在探索多模态大语言模型MLLM的应用边界时一个项目引起了我的注意SeeAct。这个名字很有意思直译过来就是“看”与“动”。它不是一个简单的视觉问答工具而是一个旨在让大语言模型LLM真正理解视觉世界并基于此理解生成可执行动作指令的框架。简单来说它的目标是赋予LLM“眼睛”和“手”——让模型不仅能“看到”屏幕或环境中的内容还能“思考”并“操作”它。这听起来像是科幻电影里的场景但实际上它解决的是一个非常实际且核心的问题如何将强大的语言理解和推理能力与具体的、物理的或数字的交互任务结合起来。传统的自动化脚本或机器人流程自动化RPA工具需要人类预先编写极其详细的规则和步骤换个界面或流程稍有变动就可能失效。而SeeAct这类框架的愿景是让AI能够像人一样通过观察See来理解当前状态通过规划Plan来拆解任务最终通过执行动作Act来完成目标。这对于自动化测试、智能助手操作软件、甚至是家庭服务机器人等领域都有着颠覆性的潜力。我花了些时间深入研究其架构和论文并尝试在本地复现其核心流程。本文将从一个实践者的角度拆解SeeAct的核心思想、技术实现路径、实操中的关键细节并分享在搭建和测试过程中遇到的那些“坑”与应对技巧。无论你是对多模态AI感兴趣的研究者还是正在寻找下一代智能自动化解决方案的工程师相信都能从中获得启发。2. 核心架构与设计哲学拆解SeeAct的核心理念可以概括为“感知-规划-执行”的闭环。它并不是训练一个全新的、巨型的端到端模型而是巧妙地利用现有成熟的组件进行组合这体现了当前AI工程化的一种务实思路站在巨人肩膀上通过系统设计解决复杂问题。2.1 核心组件与工作流整个框架通常包含以下几个关键模块它们像流水线一样协同工作视觉感知模块See负责“看”。它通常是一个视觉编码器如CLIP的ViT或一个现成的视觉理解模型如GPT-4V的API。其任务是将屏幕截图、摄像头画面或环境图像转换成富含语义的表示可以是文本描述Caption、物体检测框Bounding Box及其标签甚至是更结构化的场景图Scene Graph。这一步的目的是将像素信息“翻译”成LLM能够理解的“语言”。大语言模型核心LLM负责“想”。这是系统的大脑例如GPT-4、Claude或开源的Llama系列。LLM接收来自视觉模块的文本化场景描述以及用户用自然语言下达的指令例如“帮我把这个文档里的所有数字加粗”。LLM需要结合这两部分信息理解当前状态和用户意图然后规划出一系列具体的、可执行的动作步骤。动作解析与执行模块Act负责“做”。LLM规划出的动作通常是高级的、抽象的自然语言指令例如“点击‘文件’菜单选择‘另存为’在文件名输入框键入‘report_final.docx’…”。这个模块需要将这些指令解析成操作系统或特定应用能够识别的底层操作命令。在桌面自动化场景这可能对应着pyautogui的坐标点击、键盘输入在机器人场景则可能是ROS中的控制指令。一个关键的子模块是动作空间定义它明确告诉LLM可以执行哪些类型的原子操作如click(x, y),type(text),scroll(delta)这是连接抽象规划与具体执行的桥梁。整个工作流是迭代的执行一个动作后环境状态发生变化视觉模块再次捕获新状态反馈给LLMLLM据此判断任务是否完成或规划下一步。这就形成了一个观察-思考-行动-再观察的闭环。2.2 为什么是“组装”而非“重训”这种设计有显著的优点降低门槛无需从头训练耗费巨资的多模态模型利用现有顶尖的LLM和视觉模型即可快速搭建原型。可解释性强每一步的规划LLM的思考过程和感知结果图像描述都是可读的文本便于调试和追溯错误根源。模块化与可升级视觉模块或LLM核心可以单独升级。今天用GPT-4的API明天可以换成更强大的版本或成本更低的开源模型系统其他部分无需大改。然而这种组装也带来了核心挑战模块间的“对齐”问题。视觉描述是否足够精准和全面LLM对动作空间的理解是否到位动作解析是否鲁棒这些接口处的缝隙正是实践中需要精心打磨的地方。注意SeeAct这类框架的成功极度依赖于其提示词Prompt工程的质量。如何向LLM清晰描述动作空间、格式化历史观察和动作序列、设定规划规则是项目成败的关键这远不是简单拼接API就能解决的。3. 关键实现细节与实操要点理解了宏观架构后我们深入到实现层面。以下是我在复现类似系统时认为必须关注的几个核心环节。3.1 视觉感知从“看到什么”到“看到哪里”视觉模块的输出质量直接决定了LLM的“信息质量”。你至少有两种选择方案A通用图像描述模型。直接使用BLIP、LLaVA等模型生成一段自然语言描述。例如“屏幕上有一个文本编辑器窗口光标在开头菜单栏有‘文件’、‘编辑’等选项。” 这种方式简单但缺点是不够结构化对于需要精确定位如点击某个按钮的任务信息可能模糊。方案B目标检测关系描述。使用如Grounded-SAM、DETR等模型先检测出所有感兴趣的物体按钮、图标、输入框并输出其类别和像素坐标再结合一个关系理解模型或直接用LLM分析这些物体间的关系。输出可能是结构化的JSON{ objects: [ {label: save_button, bbox: [x1, y1, x2, y2], confidence: 0.98}, {label: file_name_input, bbox: [x3, y3, x4, y4], confidence: 0.95} ], scene_description: 保存按钮位于文件名输入框的右侧。 }方案B为LLM提供了更精确的空间信息是完成复杂操作任务的更优选择。实操心得在桌面自动化中单纯依赖像素坐标bbox非常脆弱因为窗口位置、屏幕分辨率一变就失效。一个更鲁棒的做法是结合可访问性树Accessibility Tree。工具如pywinauto或axe-core可以获取UI元素的唯一ID、角色、名称等属性。将视觉检测结果与可访问性树信息进行匹配用click(element_id)代替click(x, y)能极大提升系统的健壮性。3.2 动作空间定义给LLM的“操作手册”这是提示词工程的核心。你必须清晰、无歧义地定义LLM可以发出的所有动作指令及其格式。一个定义良好的动作空间示例可执行动作 1. click(element_description): 点击某个UI元素。element_description应基于当前视觉观察进行描述如 click(蓝色的‘提交’按钮) 或 click(ID为‘username’的输入框)。 2. type(text, element_description): 在指定元素中输入文本。如 type(Hello World, 聊天输入框)。 3. press(key_combination): 按下键盘快捷键如 press(CtrlS)。 4. scroll(direction, element_description): 滚动页面或列表如 scroll(down, 文档区域)。 5. wait(seconds): 等待一段时间如 wait(2)。 6. finish(): 任务完成时调用。你需要将这份“操作手册”、当前的视觉观察、历史动作序列以及用户指令一起构造给LLM的提示词Prompt。LLM的任务就是根据这个上下文输出下一个合法的动作指令。3.3 提示词工程引导LLM成为“规划大师”提示词的设计决定了LLM的规划能力。一个有效的提示词模板通常包含以下部分系统角色设定明确告诉LLM它现在是一个能够观察屏幕并操作软件的智能体。动作空间定义如上所述清晰列出规则。任务目标用户的原始指令。当前观察视觉模块输出的场景描述。历史记录之前已经执行过的动作序列及其结果如果有。这有助于LLM维持任务状态避免重复或无效操作。输出格式要求严格规定LLM必须以何种格式如JSON回复且只能从动作空间中选择。一个简化的Prompt示例你是一个桌面软件自动化助手。你可以通过观察屏幕和操作鼠标键盘来完成任务。 你可以执行以下动作 - click(description) - type(text, description) - press(key) - finish() 当前任务在记事本中输入“Hello SeeAct”并保存。 当前屏幕观察[视觉模块的输出一个打开的记事本窗口标题为“无标题 - 记事本”菜单栏可见编辑区域空白。] 历史动作无。 请根据当前观察规划下一步动作。只输出一个JSON对象格式如 {action: action_name, params: {...}}。注意事项LLM有时会“幻想”出屏幕上不存在的元素或执行不可能的动作。需要在后续的验证模块中增加检查例如在执行click前验证描述的元素是否真的存在于当前的视觉观察列表中。4. 搭建与测试从零到一的实践记录理论说再多不如动手做一遍。我选择了一个相对简单的场景进行复现在Windows计算器上完成一个算术运算。这个场景UI元素规整易于检测适合验证核心流程。4.1 环境与工具选型视觉模块我选用Grounded-SAM。因为它能提供像素级的分割掩码和类别标签定位精准。你也可以用YOLO做快速检测但分割掩码对于不规则图标可能更准。LLM核心出于成本和可控性考虑我使用Qwen-7B-Chat的本地部署版本。虽然能力不如GPT-4但在定义清晰的任务上表现尚可。使用vLLM进行部署以提高推理速度。动作执行使用pyautogui和pywinauto的组合。pyautogui负责模拟全局鼠标键盘pywinauto用于获取计算器控件的精准属性实现基于属性的操作降低对坐标的依赖。开发语言Python 3.10。4.2 分步实现流程步骤1环境搭建与窗口聚焦首先确保计算器程序启动并使用pywinauto连接到其窗口。一个稳定的窗口句柄是后续所有操作的基础。from pywinauto import Application app Application(backenduia).connect(title_re.*计算器.*) calc_window app.window() calc_window.set_focus() # 确保窗口在前台步骤2屏幕截图与视觉解析对计算器窗口进行截图送入Grounded-SAM模型。这里需要一个提示词告诉模型关注什么例如“button, number, display, equals”。模型会返回一系列检测框、掩码和标签。import cv2 # 截取计算器窗口区域 screenshot calc_window.capture_as_image() screenshot_np cv2.cvtColor(np.array(screenshot), cv2.COLOR_RGB2BGR) # 调用Grounded-SAM推理获取带标签的检测结果 detections grounded_sam_predict(screenshot_np, text_promptbutton, display)得到的detections是一个列表包含每个UI元素的标签和其包围框的中心坐标。我们需要将这些坐标从窗口坐标系转换到全局屏幕坐标系。步骤3构造LLM提示词并获取动作规划将视觉解析结果如“屏幕中央有一个显示区域显示为‘0’。下方有数字按钮‘1’‘2’‘3’…以及‘加号’、‘等号’按钮…”、动作空间定义和用户指令“计算125加上37的结果”组合成Prompt发送给本地部署的Qwen模型。prompt build_prompt(user_task, current_observation, action_space) llm_response query_llm(prompt) # 期望得到 {action: click, params: {description: 数字按钮 1}}关键点在Prompt中我会将视觉元素按网格位置简单描述帮助LLM建立空间关系例如“第一行按钮百分比、清除…”。步骤4动作解析与执行解析LLM返回的JSON将描述性的params[description]如“数字按钮 1”映射到具体的UI元素。这里我建立了一个简单的映射逻辑遍历detections找到标签匹配且置信度最高的元素获取其屏幕坐标然后调用pyautogui.click()。target_element find_element_by_description(detections, llm_response[params][description]) if target_element: screen_x, screen_y convert_to_screen_coordinates(target_element.center, calc_window.rectangle()) pyautogui.click(screen_x, screen_y) else: # 映射失败将错误信息作为观察反馈给LLM让其重新规划 current_observation \n[系统提示]未找到‘数字按钮 1’请重新描述。执行后等待一个短暂时间如0.5秒让UI状态更新然后跳回步骤2开始下一轮“观察-规划-执行”循环直到LLM输出finish()动作。4.3 测试结果与观察在一个受控的测试中计算器窗口位置固定系统成功完成了“12537”的任务。LLM规划出的动作序列基本符合逻辑依次点击1、2、5、、3、7、。然而整个过程比编写硬编码脚本慢得多主要耗时在视觉推理和LLM调用上。更重要的发现是失败案例歧义描述LLM曾输出click(加号)但视觉检测结果中同时有“”按钮和“加号”文本标签用于辅助功能导致映射错误。这要求视觉标签必须非常精确或者需要在Prompt中强制LLM使用更唯一的标识如“标有‘’的按钮”。状态误判计算器在点击数字后显示屏内容会变化。但我的简单实现中“当前观察”没有及时更新显示屏的文本内容仅更新了“显示区域”这个位置没更新其内容导致LLM有时会重复输入数字。这凸显了动态视觉信息更新的重要性。模型幻觉有一次LLM试图点击一个名为“后退”的按钮在标准Windows计算器界面中不存在可能是因为在训练数据中见过类似界面。这需要通过更严格的动作验证来规避。5. 常见问题、挑战与优化方向实录在实际搭建和测试中会遇到一系列典型问题。下面我将它们整理成表并分享我的排查思路和潜在的优化方案。问题现象可能原因排查与解决思路LLM输出的动作格式错误无法解析。1. Prompt中对输出格式的约束不够强。2. LLM能力不足或产生了幻觉。1.强化格式指令在Prompt中使用“你必须严格输出JSON且只包含action和params字段”等强约束语句甚至提供多个正确示例Few-shot。2.后处理与重试设计一个解析器尝试从LLM的非标准输出中提取关键信息。若失败则将解析错误信息作为新的系统观察反馈给LLM要求其重试。动作执行后系统状态未按预期变化陷入循环。1. 视觉反馈延迟或未更新。2. 动作执行失败如点击位置不准。3. LLM规划逻辑有误。1.增加显式等待在执行关键动作如点击后应弹出新窗口后插入wait动作并确保视觉模块在等待后捕获新截图。2.动作执行验证点击后可以检查目标元素的“被点击”状态是否改变如果UI框架支持或通过视觉变化检测来判断动作是否生效。3.引入反思机制让LLM对比“执行动作前的观察”和“执行动作后的观察”判断动作是否达到预期效果若未达到则分析原因并重新规划。视觉模块检测不到关键UI元素。1. 检测模型泛化能力不足。2. 截图区域或时机不对。3. UI元素状态变化如禁用、隐藏。1.微调或更换模型针对特定应用界面收集少量数据对检测模型进行微调。2.多模态融合结合屏幕像素信息和可访问性树信息。当视觉检测失败时尝试从可访问性树中获取元素信息作为补充。3.主动探索对于找不到的元素可以规划“滚动”、“切换标签页”等探索性动作来寻找。任务成功率低且过程冗长。1. LLM的规划能力有限步骤冗余。2. 动作空间定义过于原子化。1.任务分解CoT在Prompt中引导LLM先进行任务分解“请先列出完成此任务需要的大致步骤”再进行逐步规划。2.宏动作Macro-Action将常用操作序列封装成高级动作。例如将click(“文件”)-click(“打开”)-type(path, “文件名”)-click(“确定”)封装为一个open_file(path)动作。这降低了LLM的规划负担提高了效率。系统运行速度慢无法实时交互。视觉模型和LLM推理耗时过长。1.模型轻量化使用更小的视觉编码器和LLM如Qwen-1.8B。2.缓存与异步对于静态UI元素检测结果可以缓存。视觉推理和LLM推理可以尝试异步流水线。3.边缘计算对于机器人等场景考虑在边缘设备部署优化后的模型。我的核心体会是构建一个稳定可靠的SeeAct系统20%的功夫在模型调用80%的功夫在系统工程和容错设计上。你需要处理模块间的异步、状态同步、错误恢复、意外弹窗等无数细节。它更像是在开发一个具有“感知-决策”能力的软件而不仅仅是调几个AI模型。6. 进阶思考与应用场景展望虽然我的实验是在简单的计算器上完成的但SeeAct框架的想象力远不止于此。它的范式可以迁移到许多领域软件测试自动化让AI自动探索App执行测试用例并报告Bug。它能处理那些因UI频繁变动而令传统脚本维护成本极高的场景。无障碍辅助为视障用户提供更智能的屏幕阅读和操作代理不仅能读出来还能帮用户点击。业务流程自动化超自动化处理需要跨多个软件、基于非结构化文档判断的复杂流程例如从邮件中提取发票信息登录财务系统进行填报。游戏AI与模拟环境在游戏或虚拟环境中让智能体通过视觉输入学习操作策略。家庭服务机器人让机器人通过摄像头观察家庭环境理解“把桌子上的杯子拿过来”这样的指令。未来的关键突破点可能在于更高效的多模态表示如何用更紧凑、信息量更大的方式表示视觉场景减少传递给LLM的令牌数从而降低成本和延迟。LLM的规划可靠性如何通过更好的提示工程、微调或模型架构改进让LLM的规划更少犯错、更符合物理常识。端到端学习虽然当前组装式方案实用但长期看能直接从像素和指令映射到动作的端到端模型或许能更好地处理模块间的对齐问题只是这需要海量的像素动作结果三元组数据。搭建SeeAct的过程让我深刻感受到当前AI的前沿正从单纯的模型创新快速转向基于强大基础模型的系统创新。我们不再只是等待一个万能模型的出现而是可以像搭积木一样将视觉、语言、规划、控制模块组合起来去解决真实世界中的复杂任务。这个过程充满挑战但也乐趣无穷每解决一个诡异的Bug都像是教会了AI一点点关于这个世界的常识。如果你也对人机交互的未来感兴趣不妨从复现一个简单的“自动计算器”开始亲自体验一下这种“赋予机器眼睛和手”的工程艺术。