最近好几个朋友都在问同一个事我到底该学 Agent 开发还是继续把 RPA 玩精有人把 Crayfish 这类桌面 Agent 装在自己电脑上跑流程有人把 WorkBuddy 容器版扔到服务器上当自动化服务还有一批人守着传统的 RPA 组件在客户现场做交付。三拨人做着看起来都叫“自动化”的事实际踩坑的方向完全不一样。这篇文章我就把 Crayfish、WorkBuddy 容器版和传统 RPA 放在一张桌上拆开讲重点聊聊桌面 Agent、容器运行时到底改变了什么以及 Agent 相对 RPA 的真实优势有多少是营销话术、多少是能落地的能力。适合正在选型自动化技术栈、想从 RPA 转 Agent或者准备用 WorkBuddy 做本地部署的人参考。1. 先认清三个东西各管一段不是同一层的东西1.1 Crayfish 这类桌面 Agent核心不是“自动化”而是“会看会想”先说 Crayfish。我知道这个名字在不同语境下可能指代不同项目这很正常我按社区里最常见的桌面 Agent 形态来讲它是一个跑在你本机、能读屏幕、能操作鼠标键盘、能调用本地工具和文件系统的智能体程序。你可以把它理解成给电脑请了一个“会看屏幕的实习生”你告诉它目标它自己拆解步骤然后一步步把界面操作做完。这种桌面 Agent 和传统脚本最大的区别在于它不再依赖写死的坐标和控件路径。传统自动化脚本需要你告诉它“第几步做什么”而 Crayfish 这类 Agent 是通过视觉模型理解屏幕内容再通过大模型做任务规划。页面布局稍微一变脚本可能直接崩但 Agent 能根据当前截图重新判断按钮在哪、表单要填什么。这就把“自动化”从固定流程推进到了“意图驱动”的阶段。我实际测试的感受是Crayfish 这类工具在流程清晰、操作范围有限的场景下表现很稳比如打开某个软件、读取表格、填几个字段、点保存。但别指望它像人一样面面俱到。它依然会看错、会点偏尤其是面对不标准的中文软件界面、自绘控件、弹窗遮挡时照样会翻车。所以它更像是“半自主操作员”而不是全自动外挂。1.2 WorkBuddy 容器版把 Agent 从“个人玩具”变成“团队服务”WorkBuddy 是一个偏 Agent 工作台形态的产品如果你想把它做得更工程化容器版几乎是绕不开的选择。所谓容器版就是把 WorkBuddy 的整个运行环境、依赖、配置、运行逻辑一起打包成镜像通过 Docker 这类容器运行时来启动和管理。好处非常直接你不需要在自己的电脑上装一堆 Python 环境、Node 环境、浏览器驱动一条docker run就能拉起一个干净的服务。WorkBuddy 里经常提到的“自定义指令”和“Skill”本质上就是在给 Agent 沉淀可复用的能力。自定义指令是告诉 Agent“遇到某类任务时按什么规则处理”Skill 则更像一个封装好的函数带输入、输出、执行逻辑Agent 在规划时按需调用。容器版的意义在于当这些指令和 Skill 要供团队多人使用、要接入现有系统、要定时批量执行时你不可能每次都打开个人电脑去操作必须有一个常驻的服务进程这就是 WorkBuddy 容器版能站稳的原因。我自己的经验是本地桌面版适合“人机协作式”使用也就是你坐在电脑前看它操作随时打断修正。容器版适合“无人值守式”使用流程确定后把它挂在服务器上通过 API 或消息队列触发任务。两种形态不是取代关系而是不同阶段的不同选择。1.3 传统 RPA 不是没用而是它和 Agent 的抽象层级不一样聊到这里必须给传统 RPA 一个公道话。RPA 这么多年在企业里能活下来是因为它解决了一个非常真实的问题把大量重复、规则明确、流程稳定的操作变成自动执行。像财务对账、订单录入、报表下载这类任务流程常年不变用 RPA 实施成本低、稳定性高、审计也方便这是 Agent 短期很难完全替代的。RPA 和 Agent 的差别我一句话总结RPA 讲“步骤”Agent 讲“目标”。RPA 的工作方式是录制或编排一套固定步骤每一步操作什么控件、填什么值、等多久全是预设好的。Agent 的工作方式是接收一个目标然后自己判断当前应该做什么、用什么工具、如何验证是否成功。这个差别决定了它们在页面变更、异常处理、流程探索上的能力上限完全不同。但注意RPA 的优势也不是假的。RPA 在处理海量结构化数据、并发执行、连接企业老系统时非常可靠而且有成熟的审计机制。你让 Agent 去连一个只有客户端没有 API 的旧系统它也能做但出错率和不可控性要高得多。真实项目里我更推荐把两者当成互补工具而不是非要分个高下。2. 容器运行时Agent 工程化绕不开的一层2.1 一句话讲清容器运行时很多人一上来就docker run其实不太清楚背后发生了什么。容器运行时就是真正负责把镜像变成容器进程、管理容器生命周期的那一层软件。你可以理解成镜像是“安装包”容器是“运行中的程序”容器运行时则是“操作系统里负责加载和隔离程序的那套机制”。Docker 命令本身只是客户端真正干活的是 Docker 内置的 containerd、runc 这些组件。这个概念对 Agent 开发很重要。因为 Agent 应用往往牵扯大量依赖模型 SDK、浏览器内核、OCR 模型、各种 Python 库。如果直接装在宿主机上版本冲突、残留文件、权限问题会把你折磨到崩溃。容器运行时把整个依赖环境一起打包启动一个新 Agent 就是一秒的事坏了直接删掉重建不用手工清理。这种体验和“在一台长期使用的电脑上搭建环境”完全是两个世界。2.2 容器给 Agent 带来的四个实际好处第一个好处是环境隔离。不同 Agent 可以跑不同 Python 版本、不同浏览器版本互不干扰。第二个好处是快速回滚。Agent 任务如果写坏了或者执行到一半污染了状态直接把容器删掉从干净镜像重新起一个就行。第三个好处是并发调度。你可以同时拉起 10 个 WorkBuddy 容器每个处理不同业务相当于用便宜的隔离手段实现了并行。第四个好处是权限收敛。容器里可以限制网络、文件系统、运行用户即使 Agent 被恶意提示词攻击或者模型产生了危险操作破坏范围也被限制在一个容器内部。在桌面 Agent 场景下容器也能用但要注意特殊性。桌面 Agent 需要访问图形界面、鼠标键盘事件、可能还需要 GPU 加速这些东西默认在容器里是不可用的。需要把宿主机的 X11 或 Wayland 显示服务、输入设备、声音设备映射进容器还要处理好权限。会折腾但好处是同样的桌面 Agent 可以被复制成多个实验环境随便测试不会搞乱主力电脑。2.3 哪些场景必须用容器版哪些场景反而别硬上根据我自己的项目经验这三种场景强烈建议使用容器版一是需要 7x24 小时无人值守运行二是团队多人共享同一套 Agent 服务三是需要按业务量水平扩张。比如你做了 20 条自动化流程每条都要定时跑用容器可以很方便地分配资源、监控状态、分别升级。反过来如果只是个人电脑上偶尔用 Agent 处理几个文件或者任务需要你频繁介入确认那容器版反而容易变成负担。容器隔离环境固然干净但每次要映射目录、配网络、看日志交互效率远不如桌面版直接。所以不要觉得容器版听起来更高级就无脑选适合自己的运行方式才是对的。3. Crayfish、WorkBuddy 容器版和传统 RPA 的真实差异3.1 处理逻辑RPA 像照着菜谱做菜Agent 像听需求自由发挥我用一个具体例子来说明。假设业务是“把 Excel 里的报销单数据填进网页系统”。传统 RPA 的做法是先打开 Excel定位到某个单元格读值再打开浏览器等待页面加载点击“新建报销单”按钮在表单控件里填入对应字段最后点提交。每一步的操作对象、等待时间、失败重试逻辑都要提前写成流程图。好处是可控坏处是只要网页结构改一点点选择器失效整个流程就断了。换成 Crayfish 这类桌面 Agent 来做你只需要告诉它“把这个 Excel 里的报销单都提交到系统里遇到填不进去的记下来。”它会自己打开 Excel、读取内容、打开浏览器、识别页面元素、逐条填写提交失败时还会尝试另一种方式甚至截图回来问你怎么办。这个对比不是要证明 Agent 完胜而是帮你理解两者的调试思路完全不同。RPA 调试是检查步骤流程图和选择器Agent 调试是检查提示词、模型选型和校验机制。习惯了 RPA 思维的人转 Agent 第一个坎就是得接受“结果不那么确定”必须自己设计一层校验和兜底逻辑。3.2 稳定性维护一个修选择器一个修指令和校验RPA 项目的维护成本很大比例花在修选择器上。页面按钮 class 变了、弹窗多了一层、表格结构换了一下都要跟着改。这是 RPA 的老大难问题也是很多企业觉得 RPA 脆弱的直接原因。Agent 的维护重点则完全不同。WorkBuddy 容器版这类方案维护工作主要集中在这几块一是自定义指令要跟着业务规则更新比如报销标准变了Agent 的约束条件要同步改二是 Skill 的输入输出要稳定最好做到“输入一个结构输出一个结构”方便后续流程消费三是校验机制要兜底Agent 执行完一个动作后必须要验证结果验证失败要触发修正或人工审批。这些工作搞扎实了Agent 的维护体验不比 RPA 差甚至因为不再依赖具体控件细节抗界面变更能力会强很多。但要提醒的是Agent 也有自己的不确定性来源。模型可能产生幻觉导致它以为自己提交成功了其实没有。所以在生产环境里我会给 Agent 加一个“人工确认”开关涉及资金、审批、删除类操作时宁可慢一点也要让人确认。这个原则在 RPA 里反而不太需要因为 RPA 是确定性的点了就是点了。3.3 部署形态与成本从“单机工具”到“弹性服务”我整理了一个对比表方便你看使用场景。对比维度Crayfish 桌面 AgentWorkBuddy 容器版传统 RPA运行环境个人桌面系统容器运行时Docker 等Windows 服务器/虚拟机交互方式实时看屏幕、可人工介入API/消息触发、无人值守编排流程图、定时触发对页面变化的适应力较高依靠视觉和模型理解较高但需要流程级校验较低依赖选择器可扩展性单机受限高可多容器并发中需要购买并发许可或额外部署实施成本低适合个人和小团队中需要容器运维能力高商业授权和实施成本明显稳定性中等依赖模型质量中高需完整校验链路高流程确定后非常稳定最佳场景本地办公辅助、临时任务服务化、批量化、团队共享稳定高频的核心业务流程这个表能解释为什么我开头说“各管一段”。如果你是要给客户交付一套长期稳定的财务自动化流程传统 RPA 依然是性价比很高的选择。如果你的需求是“做一个能应对各种临场变化的智能助手”那桌面 Agent 或容器版 Agent 明显更合适。最怕的是用一种工具去做另一种工具擅长的事两头不讨好。4. 实操把 WorkBuddy 容器版和 Crayfish 串成一条自动化链路4.1 WorkBuddy 容器版快速部署的五个步骤先说清楚不同团队拿到的 WorkBuddy 镜像版本、来源、名称都可能不一样我这里用的是通用思路你部署时一定以自己的镜像文档为准。第一步准备数据目录。WorkBuddy 的配置、日志、技能文件最好都挂载到宿主机目录避免容器销毁后数据丢失。我一般这样建目录mkdir -p /opt/workbuddy/{config,logs,skills,data}第二步准备环境变量。容器版最烦的就是漏配环境变量。模型 API Key、模型接口地址、服务端口、数据库连接等全部通过环境变量或配置文件传入。这一步不要省写进一个.env文件方便重复使用。# .env 示例字段名以真实镜像文档为准 WORKBUDDY_MODEL_APIhttp://your-model-endpoint/v1 WORKBUDDY_MODEL_KEYsk-xxx WORKBUDDY_PORT8080第三步启动容器。下面是一个最小示例。docker run -d \ --name workbuddy \ --env-file .env \ -p 8080:8080 \ -v /opt/workbuddy/config:/app/config \ -v /opt/workbuddy/logs:/app/logs \ -v /opt/workbuddy/skills:/app/skills \ -v /opt/workbuddy/data:/app/data \ --restart unless-stopped \ workbuddy:latest第四步检查健康状态。启动后别急着用先看日志有没有报错。docker logs -f workbuddy如果容器正常等日志出现类似“服务已就绪”的信息再打开http://localhost:8080验证。第五步接入业务。容器起来之后WorkBuddy 就变成了一个服务。你可以通过它的界面建立自定义指令也可以通过 API 把任务推给它。我建议先从一条最简单的流程开始跑通再逐步增加复杂度。4.2 自定义指令和 Skill把业务经验沉淀成 Agent 能用的东西很多新手用 WorkBuddy 只会发自然语言指令这样能用但不可控。更稳的姿势是把经常使用的流程沉淀成 Skill让 Agent 像调用函数一样调用它。Skill 通常包含三个部分输入参数、执行步骤、输出格式。拿一个“订单状态同步”的场景来说我会先定一个 JSON Schema 描述输入{ order_id: 字符串订单号, target_status: 字符串目标状态, remark: 字符串备注 }然后在 Skill 里写清楚执行步骤查订单、比对当前状态、更新状态、返回结果。输出统一成 JSON{ success: true, order_id: A12345, old_status: pending, new_status: shipped, message: 订单状态已更新 }这样做的价值在于不管 Agent 怎么规划最终落到业务系统上的数据是标准化的后续的报表、审计、再处理都方便。自定义指令则用来约束 Agent 的“行为准则”比如“更新状态前必须确认该订单属于当前操作员”“删除操作必须请求人工确认”。这些规则写得越细Agent 在生产环境里的可靠性就越高这比一味追求“让模型自由发挥”重要得多。4.3 让 Crayfish 接管桌面WorkBuddy 负责大脑和流程现在我讲一个我实际搭过的组合方式。Crayfish 这类桌面 Agent 负责真正的 UI 操作WorkBuddy 容器版负责流程决策和业务逻辑。整体链路是这样的WorkBuddy 收到一个任务比如“把桌面客服软件里所有未处理的咨询标记为已回复”。WorkBuddy 先拆解任务决定需要打开客服软件、筛选未处理会话、逐条标记、最后导出结果。然后它把每个“原子操作”下发给 CrayfishCrayfish 在桌面上执行具体的点击和输入执行完毕后返回“成功/失败/截图”。WorkBuddy 判断结果再决定下一步。这里的关键是两者之间的接口要认真设计。最简单的方式是 Crayfish 暴露一个本地 HTTP 接口WorkBuddy 容器通过访问宿主机地址来调用。伪代码大概是这样import requests # Crayfish 本地服务地址 crayfish_url http://host.docker.internal:9001/execute # WorkBuddy 下发一个桌面操作任务 resp requests.post(crayfish_url, json{ action: click_and_input, target_desc: 搜索框, text: 未处理 }) result resp.json() if result[success]: # 继续下一个动作 pass else: # 记录截图等待人工处理 save_trace(result[screenshot])这段代码不是让你们直接抄而是要理解它的逻辑桌面操作返回结果AI 决策层校验结果然后继续推进。每一步都要留下可追踪的记录截图和日志就是 Agent 世界的“审计底稿”。4.4 组合链路中最容易忽略的四个点第一个点是超时控制。桌面操作可能会卡住比如软件卡在某个弹窗所以每次调 Crayfish 都要设置超时超时后自动截图并上报。第二个点是重试策略。重试要有上限比如同一个动作最多重试三次三次都失败就转人工否则 Agent 会陷入死循环。第三个点是状态冲突。容器里的 WorkBuddy 和桌面上的 Crayfish 都要有“当前任务是否在进行中”的状态防止两个任务同时操作一个界面。第四个点是权限控制。容器在服务器上桌面在本地电脑上两者通信要考虑网络边界不要让任何能访问 WorkBuddy 服务的人都随意控制桌面。5. 常见问题与排查技巧实录5.1 遇到“Agent execution terminated due to error”怎么办这个报错很典型字面意思是 Agent 在某个执行器里运行到一半被终止了。真实原因五花八门我一般按下面这个顺序排查。先看 WorkBuddy 容器日志搞清楚终止发生在哪个环节再把它拆成小步骤单独跑一遍定位是规划阶段的问题还是工具调用阶段的问题然后检查权限尤其是 Agent 有没有权限读文件、执行命令、写入目录接着检查网络特别是容器是否能访问模型接口、是否能访问宿主机上的 Crayfish 服务最后检查界面识别桌面截图是否清楚、目标控件是否存在。很多“执行被终止”的情况其实是 Agent 执行到某一步时返回了异常但中间校验逻辑没接住导致整体流程崩溃。解决思路是在关键节点加异常处理和日志输出而不是从头到尾一个大任务直接跑。5.2 容器里的 WorkBuddy 连不上宿主机上的 Crayfish这是容器网络最容易踩的坑。容器内部的localhost是容器自己不是宿主机。要访问宿主机上的服务大多数 Docker 环境下可以用host.docker.internal这个特殊域名Linux 上可能需要加--add-hosthost.docker.internal:host-gateway。如果你给宿主机上的 Crayfish 服务设了端口还要注意防火墙和监听地址别只监听127.0.0.1否则宿主机之外的容器访问不到。另外如果宿主机上的 Crayfish 服务需要访问容器里的 WorkBuddy 接口反过来还要把容器端口映射到宿主机。网络链路看似简单实际操作里很容易因为地址、端口、防火墙三层问题导致通信失败。我的习惯是先写一个小脚本在两边分别测试 http 连通性通了再接业务。5.3 中文界面识别不准点击老是点偏中文界面识别真的是桌面 Agent 的老大难。常见原因有三个分辨率和缩放比例让截图坐标和实际点击坐标发生偏移字体渲染导致 OCR 识别出的文字位置不准自绘控件让目标区域和视觉特征不明显。我踩过几次坑之后的经验是把电脑的显示缩放固定为 100% 或某个固定值不要用 125% 这种比例截图后先让人看一眼识别结果对不对再决定是否全自动点击动作不要依赖单一坐标最好通过“文字区域父容器”多重条件定位。另外生产环境建议使用分辨率固定的虚拟机或物理机跑桌面 Agent并且每次启动前检查分辨率。这听起来土但对准确率提升非常明显。真正核心的流程我会在 Agent 执行后加一个校验动作截图确认目标界面已经切换成功不成功就重新规划路径。5.4 从 RPA 平滑迁移到 Agent 的路径很多团队不是从零开始而是已经有了一套 RPA 流程想逐步引入 Agent。我的建议是别搞“一刀切”。把现有 RPA 流程拆成一个一个独立任务节点找出其中最容易变化的那些环节比如页面频繁改版、异常处理复杂、需要人为判断的部分先用 Agent 替换这部分剩下的稳定节点继续保留 RPA 执行。这样两边都有兜底风险最小。拆解完之后再把 Agent 负责的节点逐步沉淀成 WorkBuddy 里的自定义指令和 Skill。这个过程不用急跑熟一条再增加一条。我在实际项目里这样做的体验是一个月左右能把 70% 的 RPA 流程平稳切到 Agent 架构而且页面改版时不再需要连夜修选择器维护压力轻了一大截。最后再分享一个我自己的习惯所有 Agent 的关键操作无论成功失败都要求它留一份“截图日志”的痕迹。排查问题的时候这份痕迹比任何模型解释都管用。Crayfish 这类桌面 Agent 也好WorkBuddy 容器版也好工具形态会持续变但“可观测、可回滚、可人工兜底”这三个原则做 Agent 工程化时永远用得上。