1. 从三个名字说起这个项目到底在解决什么问题第一次看到 Clawbot、MoltBot、OpenClaw 这三个名字同时出现的时候我第一反应是这大概率是同一个东西在不同阶段的叫法或者是社区分叉出来的几个变体。后来花时间把它的核心逻辑捋了一遍发现确实如此——它们指向的是同一类架构思路只是在命名和实现细节上有差异。为了方便下面我统一用“Clawbot 类系统”来指代这一类项目具体到某个名字时会单独说明。那它到底是干什么的一句话概括它是一个让自动化程序能够像人一样“操作”软件界面的执行框架。注意这里的“操作”是打引号的因为它并不是去调用软件的 API而是模拟人在图形界面上的点击、输入、拖拽、滚动这些动作。你可以把它理解成一个“数字员工”你告诉它要做什么任务它自己去看屏幕、找按钮、填表单、提交结果。这解决了一个非常现实的问题。很多企业内部系统、老旧软件、第三方平台压根不提供 API或者 API 要额外付费、权限申请流程极其漫长。但业务又需要把这些系统串起来做自动化怎么办传统方案是写脚本去模拟 HTTP 请求但一旦页面结构变了、加了验证码、加了动态令牌脚本就废了。Clawbot 类系统的思路是既然人能操作那让程序也像人一样操作就行了界面变了就重新“看”一遍适应性比硬编码请求强得多。适合谁来了解这个内容三类人最值得花时间一是做 RPA机器人流程自动化的从业者这类系统本质上是 RPA 的一种轻量化实现二是需要做跨系统数据搬运的运营或财务人员他们最清楚手动复制粘贴有多痛苦三是对自动化执行框架感兴趣的技术人员想理解“感知-决策-执行”这个闭环在软件层面怎么落地。2. 核心架构拆解它凭什么能“看懂”界面并动手操作2.1 三层结构感知层、决策层、执行层Clawbot 类系统的架构并不复杂拆开来看就是三层我用一个生活化的类比来解释把它想象成一个刚入职的实习生你给他一台电脑让他去某个系统里录数据。感知层就是他的眼睛。他需要先看到屏幕上有什么——有哪些按钮、哪些输入框、哪些文字。技术上这一层通常通过截屏加图像识别或者通过读取界面元素树比如无障碍服务提供的节点信息来实现。截屏方案通用性最强什么软件都能用但识别精度依赖模型能力元素树方案精度高但只对支持无障碍服务的界面有效一些自绘界面或游戏引擎渲染的界面就读不到。决策层是他的大脑。看到界面之后他需要判断当前在哪个页面下一步该点哪里输入什么内容这一层通常是一个任务规划器把用户给的高层指令比如“把订单表里的数据录入系统”拆解成一系列原子动作点击、输入、等待、滚动。有些实现会用大语言模型来做这个规划有些则是基于预定义的流程模板。执行层是他的手。决策层说“点击坐标 (320, 480)”执行层就真的去发一个鼠标点击事件说“在输入框里打‘张三’”执行层就模拟键盘输入。这一层的关键是动作的稳定性和可回放性因为界面可能会有延迟、弹窗、加载动画执行层需要处理这些时序问题。2.2 为什么选择“模拟操作”而不是“调接口”这是很多人会问的问题既然要自动化为什么不直接调 API答案其实很务实。第一API 的覆盖范围远小于界面。一个系统可能有一百个功能但开放的 API 只有十个。你想自动化的那个功能大概率不在 API 列表里。第二API 的准入门槛高。申请 API 权限往往需要走审批流程要说明用途、要签协议、要等排期。而模拟操作不需要对方配合你自己装个程序就能跑。第三API 的稳定性是假象。很多人觉得 API 稳定但实际上 API 也会改版本、改字段、改鉴权方式。一旦变了你的代码直接报错。而界面操作虽然看起来“脆弱”但它有一个天然优势只要人还能用程序就能用。界面改版了人重新学一下就行程序重新“看”一下也行。当然模拟操作也有代价速度慢、资源占用高、容易被检测。所以 Clawbot 类系统通常会用一些优化手段比如缓存界面元素位置、批量执行动作、在关键节点才做完整感知。2.3 三个名字的差异Clawbot、MoltBot、OpenClaw根据我查到的资料和社区讨论这三个名字的差异主要在定位上。Clawbot 是最早的称呼偏向“通用型界面自动化机器人”强调能处理多种软件界面。MoltBot 这个名字里的“Molt”有蜕皮、换壳的意思暗示它支持“换皮”——也就是可以切换不同的界面适配层比如今天操作 Windows 桌面软件明天操作网页后天操作移动端。OpenClaw 则强调开源社区可以自己写适配器、自己训练识别模型。不过在实际使用中这三个名字经常混用很多文档里也不严格区分。我的建议是不要纠结名字看它的适配层和决策层实现那才是决定它能干什么的关键。3. 实操落地从零搭一个能跑的最小系统3.1 环境准备与依赖选择假设你现在要自己搭一个 Clawbot 类系统的最小可用版本我建议从以下技术栈入手。感知层Python 的mss库做截屏速度比 PIL 快很多图像识别用OpenCV做模板匹配简单场景够用如果要识别文字用PaddleOCR或Tesseract前者对中文支持更好。决策层初期不要上大模型用有限状态机就够了。把任务拆成“找按钮-点击-等待-找输入框-输入-等待-找提交按钮-点击”这样的状态序列每个状态用模板匹配或 OCR 来判断是否到达。执行层pyautogui是最简单的选择跨平台API 直观。但它有个缺点执行动作时会占用鼠标你没法同时干别的。如果要后台执行可以用pynput或直接调系统级的事件注入接口。# 一个最简单的感知-执行循环示例 import mss import pyautogui import cv2 import numpy as np def find_button(screen_img, template_path, threshold0.8): template cv2.imread(template_path) result cv2.matchTemplate(screen_img, template, cv2.TM_CCOEFF_NORMED) min_val, max_val, min_loc, max_loc cv2.minMaxLoc(result) if max_val threshold: h, w template.shape[:2] center_x max_loc[0] w // 2 center_y max_loc[1] h // 2 return (center_x, center_y) return None with mss.mss() as sct: monitor sct.monitors[1] while True: screenshot np.array(sct.grab(monitor)) screenshot cv2.cvtColor(screenshot, cv2.COLOR_BGRA2BGR) pos find_button(screenshot, submit_btn.png) if pos: pyautogui.click(pos[0], pos[1]) break这段代码的逻辑很直白截屏、找按钮、找到就点、找不到就继续找。实际项目中你会加超时、加重试、加日志但核心就是这个循环。3.2 界面元素定位的三种策略与选择依据定位界面元素是这类系统最核心的技术点我把它分成三种策略各有适用场景。第一种模板匹配。就是上面代码里用的方法提前截好按钮的图然后在屏幕里找。优点是简单、快、不依赖网络。缺点是分辨率变了、主题换了、按钮状态变了比如从灰色变成蓝色模板就失效了。适合界面稳定、变化少的场景。第二种OCR 加文字定位。不找图找文字。比如你要点“提交”按钮就全屏 OCR找到“提交”这两个字的位置然后点它旁边的区域。优点是适应性比模板匹配强文字不变就能找到。缺点是 OCR 有误差而且速度比模板匹配慢。适合按钮文字固定但样式会变的场景。第三种界面元素树。通过操作系统的无障碍接口读取界面结构直接拿到每个元素的坐标、类型、文字。这是最精确的方案但只对支持无障碍服务的界面有效。Windows 上用UIAutomationmacOS 上用Accessibility API网页上用Selenium或Playwright的元素选择器。适合网页和标准桌面应用。我的经验是优先用元素树不行再退到 OCR最后才用模板匹配。因为元素树是“语义级”的OCR 是“文字级”的模板匹配是“像素级”的。层级越高越稳定。3.3 动作执行的时序控制与异常处理很多人写自动化脚本最头疼的不是“找不到按钮”而是“找到了但点不了”。原因通常是时序问题按钮还没加载出来、页面还在动画中、弹窗挡住了、输入法没切换。Clawbot 类系统在这方面的处理思路是每个动作之后都加一个“确认”步骤。比如点击提交按钮之后不是直接进入下一步而是等待某个预期结果出现比如“提交成功”的提示、页面跳转、列表刷新。如果等不到就重试或者报错。具体实现上我会用“显式等待”而不是“固定睡眠”。固定睡眠就是time.sleep(3)简单但浪费时间和不可靠。显式等待是写一个循环每隔 0.5 秒检查一次目标条件最多等 10 秒。这样既快又稳。def wait_for_text(screen_func, target_text, timeout10, interval0.5): import time start time.time() while time.time() - start timeout: img screen_func() text ocr(img) if target_text in text: return True time.sleep(interval) return False异常处理方面我建议至少覆盖这几种情况元素找不到、点击无效、弹窗干扰、网络超时、验证码出现。验证码是最麻烦的简单的可以接打码服务复杂的只能人工介入。所以设计流程时尽量把需要验证码的环节集中到一次不要每个步骤都触发验证。4. 实际运行中绕不开的坑与排查手册4.1 识别率突然下降的排查顺序用了一段时间之后你可能会发现原本跑得好好的脚本突然开始频繁失败。这时候不要急着改代码按下面的顺序排查。第一步看屏幕分辨率有没有变。这是最常见的原因。换显示器、改缩放比例、远程桌面连接都会导致坐标偏移。模板匹配对分辨率极其敏感1920x1080 下截的图在 2560x1440 下就找不到了。第二步看界面主题有没有变。深色模式切浅色模式、系统更新换了控件样式、网页改了 CSS都会让模板匹配失效。这时候要么重新截图要么切换到 OCR 方案。第三步看有没有新的弹窗或遮挡。有时候不是按钮找不到而是被一个广告弹窗、通知横幅、输入法候选框挡住了。程序看到的是遮挡物不是目标。第四步看目标元素的状态有没有变。按钮从可点击变成禁用、输入框从空变成有内容、列表从有数据变成加载中这些状态变化都会影响识别。我一般会写一个“调试模式”把每次截屏和识别结果都存下来出问题的时候翻看历史截图一眼就能看出是哪一步开始不对的。4.2 速度太慢的优化方向Clawbot 类系统的速度瓶颈通常在两个地方截屏和识别。截屏方面全屏截一张 1920x1080 的图用mss大概 10-20 毫秒用 PIL 可能要 50-100 毫秒。如果每秒要截好几次这个差距就很明显。优化方法是只截感兴趣的区域比如只截按钮所在的右下角而不是全屏。识别方面模板匹配的速度和模板大小、搜索区域大小成正比。优化方法是缩小搜索区域先用低精度快速定位大致范围再在这个范围内做高精度匹配。OCR 的话可以只对特定区域做识别不要全屏 OCR。还有一个容易被忽略的点动作之间的等待时间。很多人为了保险每个动作后面都加 2-3 秒睡眠十个动作就是二三十秒。实际上很多等待是不必要的用显式等待替代固定睡眠整体速度能提升好几倍。4.3 常见问题速查表问题现象可能原因排查方法解决思路找不到按钮分辨率变化对比当前截图和模板重新截图或改用 OCR点击没反应元素被遮挡查看点击位置的截图先关闭弹窗或滚动页面输入内容错乱输入法干扰检查输入法状态切换英文输入法或直接注入文本流程卡在某一步等待条件不满足查看该步骤的日志和截图增加超时重试或调整等待条件运行一段时间后变慢内存泄漏或日志堆积监控内存和磁盘定期重启或清理日志验证码频繁出现操作频率过高查看请求间隔增加随机延迟、降低操作速度提示这张表里的“解决思路”都是方向性的具体怎么改要看你的代码结构。我的习惯是每个问题都写一个对应的修复脚本下次遇到直接跑不用重新想。4.4 几个我踩过的坑第一个坑以为坐标是绝对的。早期我写脚本直接把按钮坐标硬编码成 (500, 300)结果换台电脑就废了。后来改成相对坐标相对于窗口左上角再后来改成模板匹配才彻底解决。第二个坑忽略了 DPI 缩放。Windows 在高分屏上默认 150% 缩放截屏得到的图像尺寸和实际坐标不是 1:1 关系。pyautogui有个FAILSAFE机制但 DPI 问题需要额外处理要么在程序里声明 DPI 感知要么在截屏后做坐标换算。第三个坑没有处理“慢加载”。有些系统点击之后要等好几秒才出结果我一开始用固定睡眠 5 秒结果大部分时候 1 秒就好了白白浪费 4 秒。后来改成轮询检查平均等待时间降到 1.5 秒。第四个坑日志写得太少。出问题的时候没有日志就只能靠猜。后来我强制自己在每个关键步骤都写日志当前在哪个状态、截屏存到哪里、识别结果是什么、执行了什么动作。日志多了之后排查效率提升非常明显。5. 这类系统的边界在哪里能做什么与不能做什么5.1 适合自动化的场景特征不是所有任务都适合用 Clawbot 类系统来做。根据我的经验适合的场景通常有这几个特征。规则明确。任务的每一步都有清晰的判断条件不需要人的主观判断。比如“如果金额大于 1000 就点审批通过否则点驳回”这种规则明确的流程最适合自动化。频率高但变化少。每天都要做、每周都要做但流程本身很少变。这种场景自动化的投入产出比最高。如果一个月才做一次而且每次流程都不一样那手动做反而更快。界面稳定。系统不会频繁改版或者改版周期可预期。如果界面天天变维护自动化脚本的成本可能比手动操作还高。容错空间大。出错了可以重来不会造成不可逆的后果。比如数据录入错了可以删掉重录但如果是转账操作那就要非常谨慎。5.2 不适合自动化的场景与替代方案反过来有些场景我强烈建议不要用这类系统。需要复杂判断的。比如“根据客户邮件内容决定回复什么”这种需要理解自然语言的任务用界面自动化做就很别扭。更好的方案是先用大模型处理文本生成结构化指令再交给自动化执行。涉及敏感操作的。比如支付、删除数据、修改权限。这些操作一旦出错后果严重而且很多系统会对自动化操作做额外风控。这种场景要么走官方 API要么保留人工确认环节。界面频繁变化的。如果目标系统每周都改版维护成本会非常高。这时候可以考虑推动对方开放 API或者用更底层的方案比如直接操作数据库如果有权限的话。对速度要求极高的。界面操作的速度上限就是人的操作速度再快也快不到哪里去。如果每秒要处理几百笔那必须走 API 或消息队列。5.3 与 API 方案的成本对比我做过一个粗略的对比假设一个任务每天执行 100 次每次涉及 20 个界面操作。对比维度界面自动化方案API 方案初期开发成本低不需要对方配合高需要申请、联调单次执行速度慢秒级快毫秒级稳定性中受界面变化影响高接口契约稳定维护成本高界面变了要改低接口不变就不用改适用场景无 API、低频、规则明确有 API、高频、要求稳定我的建议是能用 API 就用 API没有 API 再用界面自动化。界面自动化是“最后的手段”不是“首选方案”。但现实是很多场景确实没有 API这时候 Clawbot 类系统就是唯一的选择。6. 从能跑到好用稳定性与可维护性的进阶思路6.1 把流程拆成可复用的原子动作刚开始写自动化脚本很容易写成一个大函数从头到尾几百行。这种写法能跑但没法维护。我的做法是把每个界面操作封装成独立的原子动作比如click_button(name)、input_text(field, text)、wait_for(text)。每个动作只做一件事内部处理等待、重试、日志。这样做的好处是流程层只需要描述“先做什么、再做什么”不需要关心“怎么点按钮”。界面变了只需要改对应的原子动作流程层不用动。而且原子动作可以跨项目复用下次做另一个自动化任务直接拿过来用。6.2 用配置文件管理界面差异不同环境测试环境、生产环境、不同版本旧版系统、新版系统的界面可能不一样。如果把这些差异硬编码在代码里切换环境就要改代码。更好的做法是把界面元素的定位信息放到配置文件里。# elements.yaml submit_button: type: template path: templates/submit_btn.png threshold: 0.8 username_input: type: ocr text: 用户名 offset: [100, 0] success_message: type: ocr text: 提交成功 timeout: 15代码里只写find_element(submit_button)具体怎么找由配置决定。这样换环境只需要换配置文件代码一行不用改。6.3 监控与告警让系统自己报告问题自动化系统跑起来之后最怕的是“悄悄失败”——你以为它在跑实际上它卡在某一步已经好几个小时了。所以监控和告警是必须的。我的做法是每次任务执行都记录开始时间、结束时间、成功/失败状态、失败原因。如果连续失败超过阈值或者单次执行时间超过预期就发告警。告警渠道可以是邮件、即时通讯工具、或者简单的日志文件加监控脚本。另外我会定期比如每周回顾一次失败日志看看有没有反复出现的问题。如果某个问题反复出现说明当前的方案有缺陷需要从根上解决而不是每次手动重试。6.4 版本管理与回滚策略自动化脚本也是代码也需要版本管理。我见过太多人把脚本放在桌面上改来改去最后不知道哪个版本能用。正确的做法是用 Git 管理脚本和配置文件每次修改都提交出问题了可以回滚。回滚策略也很重要。如果新版本上线后失败率飙升要能快速切回旧版本。我的习惯是保留最近三个可用版本新版本先在小范围跑一天确认稳定再全量切换。7. 我对这类系统未来走向的一些个人判断7.1 大模型带来的变化Clawbot 类系统最早的决策层是规则引擎后来有人尝试用强化学习但效果一般。最近一两年大模型在这类系统里的应用越来越多。大模型擅长的是“理解意图”和“处理模糊情况”比如用户说“把那个重要的订单处理一下”规则引擎没法处理但大模型可以结合上下文判断“那个重要的订单”指的是哪个。不过大模型也有问题慢、贵、不稳定。所以我的判断是大模型适合做高层规划底层执行还是用传统方法。比如大模型负责把“处理重要订单”拆解成“找到订单列表-按金额排序-选第一个-点击审批”然后传统方法负责执行这些具体动作。7.2 多模态感知的融合现在的感知层主要是视觉截屏和结构元素树。未来可能会融合更多模态比如读取系统日志、监听网络请求、甚至读取内存状态。多模态融合的好处是互相校验视觉看到按钮是灰色的但网络请求显示接口返回成功那可能是视觉误判。不过多模态也带来复杂度。我的建议是先从单模态做起跑通了再考虑融合。不要一开始就追求大而全那样很容易卡在细节里出不来。7.3 从“自动化”到“智能化”的距离很多人把自动化和智能化混为一谈。自动化是“按固定规则执行”智能化是“根据情况灵活调整”。Clawbot 类系统目前大部分还停留在自动化阶段离智能化还有距离。智能化的关键难点是异常处理。自动化系统遇到没见过的弹窗就卡住了智能化系统应该能判断“这个弹窗是广告关掉就行”或者“这个弹窗是错误提示需要记录并重试”。这需要系统有一定的世界知识和推理能力目前的大模型在这方面还有限。我的看法是未来三到五年这类系统会从“规则驱动”逐步转向“规则加模型混合驱动”。纯规则的系统会越来越少但纯模型的系统也不现实。混合方案是务实的选择。8. 给想上手的人几条实在建议如果你看完上面的内容想自己动手试试我给你几条建议。第一条从最简单的任务开始。不要一上来就搞复杂的多系统联动先做一个“打开记事本-输入一段文字-保存”的自动化。把感知、决策、执行这个闭环跑通再逐步增加复杂度。第二条先手动做一遍把每一步记下来。自动化本质上就是把手动操作翻译成代码。你手动做的时候每一步在干什么、看什么、判断什么都记下来这就是你的流程设计文档。第三条不要追求 100% 自动化。有些环节人工介入反而更高效比如验证码、异常审批。设计流程时把人工介入点留出来不要硬扛。第四条日志和截图是你的救命稻草。出问题的时候没有日志就只能靠猜。我宁愿多写十行日志也不愿意花一小时排查一个本可以一眼看出的问题。第五条定期回顾和优化。自动化脚本不是写完就完了要定期看失败日志、看执行时间、看资源占用。发现瓶颈就优化发现反复出现的问题就从根上解决。最后再分享一个小技巧给每个自动化任务加一个“干跑模式”。干跑模式下程序只识别和记录不实际执行点击和输入。这样你可以在不影响真实系统的情况下验证识别逻辑是否正确。这个模式在调试新流程时特别有用能避免因为脚本错误导致真实数据被改乱。