上个月我把跑了快一年的影刀RPA流程全部停了。没错就是那种“业务部门觉得省了人力、运维同学一听到告警就想摔键盘”的流程。替换方案也早就不是秘密Crayfish 桌面 Agent 配合 WorkBuddy 容器版把过去靠录制选择器、死守流程图的自动化方式换成了“告诉 Agent 要什么结果它自己规划怎么干”的新模式。这篇文章我不打算做概念科普就把 Crayfish 和 WorkBuddy 容器版这套东西拆开讲清楚它是什么、强在哪、怎么落地、哪些场景千万别硬上以及相对传统 RPA 的真实优势到底成立不成立。如果你也在做 RPA 项目、AI Agent 开发或者正纠结“要不要从 RPA 迁到 Agent”这篇应该能帮你少走不少弯路。1. 为什么我把目光从传统 RPA 转向桌面 Agent1.1 传统 RPA 的日常不是脚本在跑是人在救火我做过的 RPA 项目不算少影刀、UiPath 这类工具都用过。头几个项目确实爽把录入、对账、报表导出这类固定流程录一遍机器人就能 7×24 小时干活。但爽过一个月之后问题就开始冒头了。最典型的就是“选择器失效”。业务系统的页面只要改一个按钮的 class、调一下弹窗结构凌晨跑批的机器人就卡死在那儿第二天早上看日志才知道又中断了。这时候所谓的高效自动化实际变成了“人工盯着流程、随时准备修脚本”。页面越是迭代频繁维护成本越接近重写一遍流程。还有环境问题。传统 RPA 机器人通常要装独立的客户端依赖 .NET 环境、浏览器驱动、各种 Office 组件。换一台机器部署等于把所有依赖重新踩一遍雷。业务部门要的多环境、多租户隔离在传统 RPA 里实现起来更是痛苦要么复制一堆 Agent 实例要么在同一个实例里加各种互斥锁。我记得去年最崩溃的一次是客户那边把业务系统从内网换到云上页面从 Silverlight 迁移成了 H5。整个项目十几个流程全部要重新录。那种无力感不是脚本能解决的是这套工具本身的理念决定了它的天花板——它只认“录下来这一步怎么做”从来不问“这一步是为什么”。1.2 桌面 Agent 的范式切换从“录流程”到“派任务”后来我开始把注意力放到 AI Agent 上尤其是桌面 Agent。核心转变就这么一句传统 RPA 让我描述“怎么点、怎么填、怎么跳转”桌面 Agent 让我描述“要完成什么任务”剩下的是它自己去拆解。Crayfish 就是我在这个阶段碰到的桌面 Agent 方案。它不是那种只能在网页端调 API 的 Agent而是真正跑在桌面环境里能看屏幕、能操作应用、能读文件目录的智能体。配合 WorkBuddy 容器版整个 Agent 又跑在容器运行时里天然拥有了环境隔离、快照回滚、权限沙箱这些能力。为什么这个组合值得关注因为它碰巧把 Agent 开发里最麻烦的三件事都解决了桌面环境的接入方式、Agent 运行时的依赖管理、以及执行过程的可控性。我自己的体会是传统 RPA 适合的是一成不变的世界桌面 Agent 适合的是真实世界。真实世界的业务系统不会停下来等你更新脚本它每天都在改版、在加字段、在不同页面上用不同的说法表达同一个意思。这时候能理解界面语义的 Agent 和死啃选择器的 RPA差距就不是一点半点了。2. Crayfish 桌面 Agent 的核心能力拆解2.1 看得懂屏幕才叫适合桌面的 AgentCrayfish 底层最关键的模块是视觉理解层。它做桌面自动化不依赖元素选择器而是通过截图 多模态模型来理解当前屏幕上的内容。比如它看到一个页面能认出“这个区域是客户列表”“这个按钮是导出 Excel”这跟人去操作软件的思路几乎一样。这套机制带来的最直接好处就是抗改版。只要页面上的按钮文字还是“导出”不管它的 class、id、坐标怎么变Crayfish 都能找到它。哪怕按钮从左上角挪到了右上角从扁平按钮变成了下拉菜单只要语义没变它照样能完成操作。我在测试时故意把测试系统的按钮样式换了两版脚本类 RPA 全部挂掉Crayfish 从头到尾没需要改代码。当然视觉理解不是万能的。如果界面按钮没有任何文字、图标含义又模糊多模态模型也会犯迷糊。所以 Crayfish 实际还保留了一套辅助定位机制可以给特定元素打语义锚点也可以手动指定坐标区域。视觉理解为主、锚点兜底这比纯选择器方案灵活得多。2.2 Skill 技能系统把复杂操作封装成积木视觉理解解决的是“怎么找到目标”Skill 系统解决的是“怎么做这一步”。Crayfish 的每个 Skill 就是一个可复用的操作单元。比如我写了一个excel_merge技能功能是把指定目录下的所有表格合并成一个工作簿再比如invoice_ocr技能负责读取发票图片并提取关键字段。每个 Skill 都有一个声明文件描述它的名称、输入参数、依赖环境、执行逻辑类似于声明一个接口。Skill 的好处是让 Agent 的任务规划有了可组合的原子能力。Agent 接收到一个目标之后planner 会把目标拆成多步先找文件、再做 OCR、再汇总数据、再发邮件。每一步对应的 Skill 如果已经存在Agent 直接调用如果不存在它会尝试用基础工具写 Python、操作命令行、调用浏览器临时组装一个方案。我在 WorkBuddy 的热搜词里看到不少人在搜 “workbuddy skill”这确实是这套体系里最值得花时间研究的模块。因为 Agent 通用能力再强最终能不能解决你的业务问题取决于你有没有为你的场景准备好对应的技能库。技能库越厚Agent 规划得越游刃有余。2.3 规划-执行-验证的闭环跟纯脚本自动化最大的不同是 Crayfish 有反馈闭环。一次任务并不是“拆完步骤就一股脑执行到底”而是每执行完一个阶段都会停下来验证结果再决定下一步。实例如下我让它“把下载目录里所有 6 月份的报销单整理成 Excel按日期排序然后发给我”。整个链路大致是规划阶段planner 把目标拆成 5 个子任务列出候选 Skill文件扫描、表格解析、Excel 合并、邮件发送。执行阶段逐个调用 Skill。扫描文件时发现有两个 PDF 不是报销单它会基于文件名和内容初步过滤。验证阶段每个关键节点执行完Agent 会自己截图或检查产物。比如合并 Excel 后它会打开文件确认有几行、日期字段有没有格式错乱。修正阶段如果发现数据缺失它会回溯到上一个 Skill调整参数重新执行。这一步价值极大。传统 RPA 脚本跑到中途数据对不上只能靠工程师看日志定位再调脚本重跑。Agent 呢它自己在执行过程中就把错误发现并消化掉了不需要人工介入。当然代价也有多模态模型的每次读取、验证都要消耗 token成本和延迟都比纯脚本高。这个问题后面我会专门讲。3. WorkBuddy 容器版桌面 Agent 为什么必须有一个容器运行时3.1 裸跑 Agent 的三大隐患很多人在服务器上直接pip install几个依赖、拉一个 OpenAI 的 API Key 就开始跑 Agent。个人玩玩没问题一旦到真实桌面自动化场景我的建议是别裸跑。第一个隐患是环境污染。Agent 在执行任务时会装软件、写临时文件、改系统配置。跑一个整理文件的 Agent它可能就给你装上几个 Python 包跑一个浏览器自动化的 Agent它可能把 Chrome 插件、用户配置全改了。跑几天之后宿主机环境烂到你自己都不认识而且无法追溯是哪次任务搞坏的。第二个隐患是安全边界模糊。桌面 Agent 要操作文件、要访问网络、要模拟键鼠输入。如果跟宿主机完全共享权限一条 prompt 注入攻击就可能让它把不该删的文件删了或者把内部数据发到不该发的地址。没有沙箱你根本不敢让 Agent 接触生产系统。第三个隐患是回滚难。脚本出了问题重新跑一遍往往就好了Agent 出了事你可能得重装系统、还原数据。真正稳定的自动化必须支持“出问题一键回到之前的某个状态”这只有容器化环境能做到。3.2 WorkBuddy 容器版的架构逻辑WorkBuddy 容器版解决的就是上面三个问题。它本质上是一个面向 Agent 场景的容器运行时管理工具负责 Agent 镜像的拉取、容器的创建与调度、桌面环境的挂载、权限策略的注入以及容器快照的生命周期管理。它的架构大致分四层镜像层每个 Agent 运行环境都是一份镜像。镜像里预置了 Python 运行时、浏览器、桌面自动化组件、Crayfish 运行时和常用 Skill 库。你在镜像里定义环境就像定义一台永远不会乱掉的机器。容器层一个容器对应一个 Agent 实例。容器之间完全隔离同一个宿主机可以跑多个 Agent 容器分别负责财务、客服、运维等不同任务互不干扰。桌面接入层容器内部有一个完整桌面会话或者通过远程桌面方式挂载宿主机桌面Crayfish 在这个会话里看到屏幕、操作应用。这是桌面 Agent 跟普通 API Agent 最大的差异。策略层定义容器能访问哪些宿主机目录、能连哪些网络地址、是否需要 GPU、能执行哪些高权限操作。策略是白名单思路没放行的默认拒绝。有了这四层Agent 跑在哪里、能做什么、出问题怎么办都有了明确答案。3.3 权限沙箱与快照回滚设计权限这块是 WorkBuddy 容器版比较打动我的一点。它支持细粒度的目录挂载和网络策略而不是让你在“全权限”和“完全隔离”之间二选一。举个例子我给财务 Agent 创建容器时做了这些限制只挂载/data/finance目录业务系统其他目录一律不可见允许访问公司内网的财务系统域名禁止访问外网禁用 GPU因为用不上禁止 Agent 以 root 身份在宿主机执行命令所有操作都限制在容器内。这样即便 Agent 被恶意 prompt 引导它能造成的影响也会被锁死在沙箱里。快照回滚更实用。我在跑月度对账任务之前会先给 Agent 容器打一个快照。任务执行完之后不管成功还是失败只要发现问题一条命令就能回滚到任务开始前的状态。Agent 自己把环境搞乱了回滚。数据写错了回滚。连大模型决策抽风搞出来的垃圾文件也能一句命令还原干净。我踩过一个坑多说一句一开始我图省事Agent 容器跟宿主机共享了家目录结果跑了三天之后整个家目录布满了 Agent 生成的零碎文件。后来我强制改成白名单挂载世界清净了。做桌面 Agent 一定别怕麻烦目录权限越严后面的运维越轻松。4. 本地落地Crayfish WorkBuddy 容器版部署实操4.1 环境准备一台带桌面会话的宿主机Crayfish 是桌面 Agent所以宿主机必须有一个可用的图形桌面环境。我的测试环境是一台 Ubuntu 22.04装了 XFCE 桌面平时通过 VNC 远程访问。WorkBuddy 容器版官方常见的安装目标是 Linux 服务器但在有图形界面的 Linux 上做 Agent 桌面自动化是最顺的。Windows 宿主机也能跑但我建议不要一上来就尝试原因后面说。另外Crayfish 的视觉理解依赖大模型 API所以需要准备一个可用的模型服务地址和 API Key。如果公司有内网部署的多模态模型优先用内网的延迟和成本都更可控。这一步类似 Agent 开发的基础配置没有模型服务整个 Agent 就是无源之水。4.2 安装 WorkBuddy 并初始化运行时WorkBuddy 的安装比我预想中轻量本质是一个命令行工具。安装完成后先初始化运行时# 安装 WorkBuddy CLI具体地址以你下载到的发行版为准 wget https://your-registry/workbuddy/latest/wbctl.tar.gz tar xzf wbctl.tar.gz sudo install wbctl /usr/local/bin/ # 初始化容器运行时 wbctl runtime init --engine containerd初始化的时候它会检测当前机器的容器引擎。我用的是 containerdDocker 也兼容看你现有基础设施。WorkBuddy 官方也支持类似 kubesphere 这类家企业级容器管理平台作为上层调度入口不过单机测试阶段用 CLI 就够了没必要一上来就上集群。初始化完成后可以看一眼运行时状态wbctl runtime status正常情况下应该能看到容器引擎、存储驱动、网络插件都处于 Ready 状态。4.3 创建并启动第一个 Agent 容器接下来拉取 Crayfish 的 Agent 镜像。镜像内预装了 Crayfish 运行时、浏览器、桌面自动化依赖和一批常用 Skill。# 拉取桌面 Agent 镜像 wbctl image pull crayfish/desktop-agent:ubuntu-22.04-lts # 创建 Agent 容器 wbctl container create finance-agent \ --image crayfish/desktop-agent:ubuntu-22.04-lts \ --desktop attach \ --mount /data/finance:/workspace/data:rw \ --network policy/default-internal \ --snapshot hourly \ --timeout 3600参数解释一下--desktop attach让容器内的 Agent 能看到宿主机桌面会话或容器自带桌面Crayfish 在这个会话里执行视觉定位和键鼠操作。--mount /data/finance:/workspace/data:rw只把财务数据目录挂进容器而且是可读写。其他目录不可见。--network policy/default-internal应用预先配置好的网络策略限制只允许访问内网白名单地址。--snapshot hourly每个小时自动打一个快照出问题随时回滚。--timeout 3600单次任务最长执行 3600 秒超时自动终止避免 Agent 陷入死循环。启动容器wbctl container start finance-agent启动之后可以进入容器确认桌面环境和 Crayfish 状态wbctl exec finance-agent -- crayfish --status如果看到desktop session: ready和vision model: connected说明环境已经就绪。4.4 给 Agent 装技能、跑首个任务Crayfish 的技能安装同样通过 WorkBuddy 完成。我从技能仓库里装了一个文件整理和一个表格合并的技能wbctl exec finance-agent -- wb skill install file-organizer wbctl exec finance-agent -- wb skill install excel-merge然后执行第一个真实任务。我跟 Agent 说“把/workspace/data/approvals里七月份的审批单据找出来合并成一个 Excel按审批人分组输出到/workspace/data/output。”wbctl exec finance-agent -- crayfish run \ 把 /workspace/data/approvals 里七月份的审批单据找出来合并成一个 Excel按审批人分组输出到 /workspace/data/output第一次跑的时候我盯着日志看了好一阵。它先扫描目录识别出 200 多个文件然后判断哪些是审批单哪些是无关附件接着调 excel-merge 技能合并最后还自己打开输出文件确认了一遍行数和分组。整个过程大概 6 分钟中间有一次它对一个 PDF 格式判断不确定竟然自己尝试了两种解析方式选了结果更合理的一种。这个体验跟 RPA 非常不同。RPA 也会“跑完”但不会“确认结果”。Crayfish 的自我验证让任务完成的可信度高很多。4.5 容器内发生了什么一次执行的观察记录我习惯在执行任务时开一个窗口观察容器内部状态。跑任务时用wbctl logs finance-agent --follow日志里能看到 Agent 的思考摘要、Skill 调用记录、每个阶段的执行时间和验证结果。这些日志在排查问题的时候价值很高。RPA 日志大多是“点了一下按钮”“输入了文本”这种机械记录Agent 日志会告诉你“我为什么选这个方案”“我发现了什么异常”排查效率完全不同。任务结束后再查看快照列表wbctl snapshot list finance-agent会发现任务开始前自动打了一个基线快照任务结束后又有一个新快照。一旦后续发现输出数据有问题直接回滚到基线快照重跑一遍即可。5. 同场对比五个真实场景里Agent 和 RPA 的差距5.1 固定录入流程RPA 不输但 Agent 没差多少先说传统 RPA 最擅长的场景每天固定从某个系统导出数据填到另一个系统。这种流程稳定、页面内容几乎不变、操作路径明确。在这个场景里RPA 的执行效率确实高毕竟脚本直接操作 DOM 或 UI 控件毫秒级完成Crayfish 要走视觉理解 规划 验证流畅但明显多花时间。不过差距没有很多人想象的大。我测过一个约 3 分钟的录入流程RPA 耗时 45 秒Crayfish 跑了约 2 分钟。考虑到 Agent 不需要维护选择器这点性能差异完全可以接受。我的判断如果流程永久不变RPA 依然是合理选择但现实中“永久不变”这四个字基本不成立。5.2 页面改版的瞬间谁更抗揍这个对比我专门做过一次压力测试。把测试系统的“报销单列表”页面改了三种样式按钮换了颜色和位置、表格加了列、弹窗确认框改成了侧滑抽屉。影刀脚本三个场景全挂有的挂在元素找不到有的挂在弹窗类型变了。Crayfish 呢第一次改版它全通过了因为它依据的是按钮文字“提交审批”而不是 DOM 结构第二次加列也没问题第三次弹窗改成侧滑抽屉时它一开始犹豫了一下后来通过识别抽屉里的“确认”按钮完成了操作。这个结果基本验证了桌面 Agent 最核心的价值流程可以变界面可以变只要业务语义不变Agent 就能跟上。而业务语义恰恰是 RPA 完全不理解的东西。5.3 流程需求变更改配置还是重新规划业务需求变更是自动化的常态关键是变更成本。传统 RPA 项目里一次流程变更往往意味着改流程图、改选择器、联调测试、灰度发布整套流程走下来一两天是常事。Crayfish 这边我遇到一个需求变更原来只要合并 Excel后来要求合并之前先做去重并且把重复项单独列一个 sheet 标红。我没有改任何 Skill 代码只跟 Agent 说清楚了新需求它在规划时自动加了一步去重并且调用了表格样式相关的工具函数。这确实是范式差异。RPA 是人写好流程交给机器执行Agent 是你说目标它来组织技能组合。技能库不变的情况下Agent 能覆盖的需求范围会比 RPA 大得多。当然复杂技能本身还是需要开发但那是建设技能库的一次性投入不是每个流程都重写一遍。5.4 异常恢复与无人值守无人值守是 RPA 工程的终极目标但传统 RPA 的无人值守比较虚。脚本报错后能做的很有限要么重启流程要么等人工处理。凌晨三点流程卡住了机器人就是在那边干等天亮。Crayfish 的自我验证和修正能力让我第一次感受到了“无人值守”的可行性。我观察到它遇到“文件不存在”时会先检查是不是路径变了然后尝试在相邻目录里搜索遇到“点击无效”时会刷新界面重新截图判断按钮是否真的点了。有一次模型传回的坐标点歪了它点了旁边的空白区域随后通过截图发现“没有预期弹窗”于是重新定位按钮再点一次。这种“做错了自己能发现、能纠正”的能力是 Agent 相对 RPA 最实在的优势。它不一定每次都成功但能把需要人工介入的故障率降一个数量级。5.5 多环境交付镜像分发 vs 重复安装最后对比一下交付环节。传统 RPA 项目交付到新环境要装机器人客户端、配权限、装浏览器驱动、导流程包一整套搞下来少说半天。版本升级更痛苦每台机器要重新弄一遍。用 WorkBuddy 容器版之后交付单元就是一个镜像。wbctl image export finance-agent:v1.2 -o finance-agent.tar # 拷贝到目标机器 wbctl image import finance-agent.tar wbctl container create finance-agent --image finance-agent:v1.2 ...环境一致性由镜像保证宿主机上只需要有一个容器运行时。多环境隔离也简单比如财务和人事各给一个容器镜像可以从同一套基础镜像派生灵活性很高。这套流程跟应用容器化最佳实践完全一致只是把场景从微服务换成了桌面 Agent。6. 结论之前Crayfish WorkBuddy 的边界与避坑6.1 我踩过的坑桌面会话、权限报错、模型成本先说桌面会话。WorkBuddy 容器版跑 Agent 最容易出问题的地方就是桌面会话连不上。容器起来了Crayfish 却报desktop session: unavailable。我的排查经验是先确认宿主机有没有活动的桌面会话再确认容器是否被允许 attach 到桌面最后看 VNC/RDP 服务是否有认证阻塞。千万别用 headless 模式跑需要看屏幕的 Agent我看过不少人栽在这。然后是 Windows 宿主机上的容器权限坑。有段时间我在 Windows Server 上测试 WorkBuddyAgent 容器启动时反复报类似“应用程序特定权限设置并未向在应用程序容器中运行的地址授予访问权限”的错误。这其实是容器进程在非隔离模式下运行时SID 映射没对上应用权限设置无法匹配到容器内用户导致的。解决思路是放弃直接在 Windows 容器里跑桌面 Agent改成在 Linux 虚拟机/容器里干活Windows 只作为远程桌面客户端。桌面 Agent 场景Linux 容器要省心得多。最后是模型成本。Crayfish 的视觉理解每做一个决策都要调用模型token 消耗比纯文本 Agent 高不少。我的控制办法有三个优先部署公司内的开源多模态模型成本几乎为零在 Skill 里尽量用确定性代码处理已知流程只把“看不懂的部分”交给模型快照和日志里做 token 用量统计超过阈值就告警。Agent 不是不用钱是要把钱花在真正需要语义理解的地方。6.2 哪些场景还是老老实实回 RPA尽管我说了这么多 Agent 的好处也不是所有场景都适合 All in Agent。超高频率、超大吞吐的自动化任务比如每秒要处理几千条消息的接口调用RPA 都不太行这种应该走 API 服务而不是 UI 机器人。Agent 也不适合。还有强合规审计场景。Agent 每次执行的具体路径带有一定随机性如果企业要求每一步操作都必须百分之百可预期、可重复那 RPA 或传统工作流引擎依然是更稳的选择。另外成本和延迟敏感的场景也要慎重。比如一个每天跑几十万次的短流程就算 Crayfish 能跑模型 API 的费用也会高到让你怀疑人生。Agent 适合的是“复杂、多变、低频”的任务简单机械的任务交给脚本或 RPA 就好。6.3 我的选型建议回过头来整理一下这一个月折腾下来的判断如果你的自动化流程页面稳定、逻辑一成不变RPA 没有问题不必跟风换 Agent如果你的流程一直在变、维护成本已经高过收益或者你有很多半结构化、需要“看懂内容才能做决策”的环节那 Crayfish WorkBuddy 容器版这条路值得认真走一遍。我自己现在的落地方式是混合形态稳定流程保留原有 RPA 或脚本不放新增的复杂流程全部走桌面 Agent容器环境统一由 WorkBuddy 管理镜像、快照、网络策略全走容器化。这样的架构不再害怕页面改版也不用担心 Agent 把环境搞脏更不用每次交付新环境都从头部署一遍。最后再给一个小技巧刚开始试 Crayfish 的时候别急着让它干生产任务。先挑一个你最头疼的、页面总变的流程让它在 WorkBuddy 容器里跑通同时把 Skill 拆细。等你说“这种以前要耗一天修脚本的活儿现在一句话就跑了”的时候你就知道这套东西值不值了。