我手头刚好在折腾一个桌面自动化的新方案把 WorkBuddy 容器版和它底层的 Crayfish 运行时摸了一遍。先说结论这套东西和传统 RPA 完全不是一个物种它不是一个“录制回放”的脚本工具而是一个真正能看屏幕、能理解上下文、能自己决定下一步操作的桌面 Agent。如果你正在 RPA 和 Agent 之间纠结选型或者好奇“容器运行时”在里面到底起了什么作用这篇文章应该能帮你把思路捋清楚。1. 整体设计思路拆解为什么桌面 Agent 要跑在容器里1.1 WorkBuddy 容器版到底解决了什么问题先聊背景。WorkBuddy 本质上是一个桌面 Agent 工作台它把人机交互从“命令-执行”变成了“目标-分解-执行-验证”的循环。你告诉它一个目标比如“把钉钉多维表里昨天的数据同步到本地 Excel 并生成汇总”它自己会拆解步骤、调用工具、操作界面、校验结果。但这里有个很现实的痛点桌面 Agent 需要依赖 Python 环境、模型 API、OCR 组件、浏览器驱动、截图工具等一整套东西不同系统的环境差异很容易把新手劝退。WorkBuddy 容器版把整条依赖链全部打包进一个镜像里你不需要在自己机器上折腾 Python 版本、Node 版本、各种 DLL 依赖。这个思路和 Docker 打包 Web 服务如出一辙等于把“环境配置”这件事从用户侧彻底拿掉了。另一个关键点是隔离性。Agent 要操作桌面、读屏幕、访问本地文件如果运行在宿主机上一旦模型被注入恶意指令理论上是能直接读到你的私人文件和浏览器 Cookie 的。容器版通过文件系统隔离、网络策略限制、桌面会话隔离把 Agent 的权限压缩在一个可控的沙箱里。对于金融版用户来说这个安全边界尤其重要。1.2 Crayfish 在整套架构中的角色Crayfish 是 WorkBuddy 容器版底层的运行时组件你可以把它理解为“承载 Agent 的容器基础设施”。它负责三件事拉起容器、管理容器生命周期、把宿主机的图形界面和输入设备安全地映射进容器内。这里有个容易混淆的点Crayfish 不是一个轻量容器运行时比如 containerd 那种级别的东西它更像是一个面向桌面 Agent 场景的容器编排工具。比如它会处理 X11/Wayland 的 socket 转发、剪贴板共享、屏幕录制权限、声音设备映射这些桌面特有的东西。普通 Docker 容器跑数据库没问题但要跑一个“需要看到桌面、点击按钮、读取验证码”的 Agent就必须有 Crayfish 这一层来打通图形会话。我用一个生活化类比Docker 提供的是“集装箱”Crayfish 则是专门设计了“集装箱里的驾驶室”。容器里跑的不是无头服务而是需要眼睛和手的驾驶员Crayfish 就是把方向盘、仪表盘、视野完整接到容器里的那套系统。1.3 与 CodeBuddy、WorkBuddy 的关系澄清很多人把 CodeBuddy 和 WorkBuddy 搞混。我的理解是CodeBuddy 是面向写代码的 IDE Agent 形态WorkBuddy 是面向桌面办公的通用 Agent 工作台。两者的底层模型能力可能有重叠但使用场景完全不同。CodeBuddy 解决“代码怎么写”的问题WorkBuddy 解决“电脑上这一堆重复的事谁来做”的问题。容器版 WorkBuddy 更适合 Linux/Ubuntu 用户、服务器环境、以及需要批量部署多个 Agent 的场景。Windows 用户因为原生桌面集成更顺滑用桌面版就好但如果你想把 Agent 跑在 NAS、内网服务器或者云主机上容器版就是唯一合理的选择。2. 桌面 Agent 相对 RPA 的真实优势不只是“智能”2.1 RPA 和 Agent 的运行模式差异传统 RPA 工具影刀、UiPath 这类的核心思路是“流程编排 选择器定位”。你告诉它打开网页 - 点击 id 为 login-btn 的元素 - 输入账号 - 等待 - 截图。每一步都是确定性的元素定位靠 DOM 属性、图像匹配、坐标。优势是稳定、可控、执行速度快劣势是怕变化——页面一改版选择器失效整个流程就断。桌面 Agent 的核心思路是“目标驱动 多模态感知”。它用一个视觉语言模型直接“看”屏幕通过桌面截图理解当前状态再基于任务目标决定下一步动作。不依赖选择器也不依赖固定的 DOM 结构页面改版了它重新看一眼就知道按钮在哪。我实测下来的感受是RPA 适合流程稳定、执行频率高、价值明确的场景Agent 适合流程易变、需要判断、甚至需要跨应用推理的场景。两者不是替代关系而是互补。很多团队现在是“RPA 做高频稳定的脏活Agent 做需要脑子的协调活”。2.2 Agent 的感知和决策到底强在哪举个例子。传统 RPA 做一个“从小红书采集笔记数据”的流程如果小红书改版导致按钮位置变了它就废了。但 Agent 处理同样任务时它看到新的界面会理解“这里有一个发布按钮虽然样式变了但功能和以前一样”。它能做到这一点是因为底层模型经过了海量 GUI 数据的训练界面对它来说不是一组控件树而是“可以理解的视觉场景”。决策层的优势更明显。RPA 的逻辑是人提前写死的如果 A 出现就执行 B否则执行 C。Agent 的逻辑是“边做边改”任务开始前它先拆解成步骤执行一步后看一眼结果如果发现偏差就调整策略。这种“每走一步都重新评估”的循环让 Agent 能在半路遇到异常时自己绕路而不是报错终止。2.3 落地成本和 ROI 的真实对比RPA 的优势是单条流程的边际成本极低做好了之后就全自动跑一台机器可以挂几十条流程。但前期开发和维护成本不低需要 RPA 工程师写流程、维护选择器、应对页面变更。实际项目里我见过不少 RPA 项目 40% 的时间都在改选择器。Agent 的初期搭建成本其实更低因为它不需要你理解 DOM 结构、CSS 选择器这些东西只要会用自然语言描述任务就行。但它的单次执行成本更高要调模型 API而且速度比 RPA 慢。一个简单的表单填写RPA 可能 3 秒完成Agent 可能需要 10 到 20 秒因为它每一步都要“看一眼再点一下”。所以我的选型建议是高频稳定任务保留 RPA低频复杂任务、需要跨系统推理的任务交给 Agent。如果是要“快速把一个人的活自动化”Agent 的性价比高于 RPA如果是“把一条跑了一年的业务线全自动化追求极致稳定和速度”RPA 更靠谱。3. 容器运行时方案解析Crayfish 的部署与配置要点3.1 安装 Crayfish 与拉取镜像在 Ubuntu 上部署 WorkBuddy 容器版之前先把宿主机环境确认好。以 Ubuntu 22.04 为例你需要先装好 Docker 引擎和 GPU 驱动如果涉及 OCR 或视觉模型推理NVIDIA Container Toolkit 也要装好。# 安装 Docker 引擎 sudo apt update sudo apt install docker.io docker-compose-v2 sudo systemctl enable --now docker # 安装 NVIDIA 容器工具包如果打算用 GPU 跑本地视觉模型 distribution$(. /etc/os-release;echo $ID$VERSION_ID) curl -s -L https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg curl -s -L https://nvidia.github.io/libnvidia-container/$distribution/libnvidia-container.list | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list sudo apt update sudo apt install -y nvidia-container-toolkit sudo nvidia-ctk runtime configure --runtimedocker sudo systemctl restart docker装好基础设施后再用 Crayfish 命令行工具拉取并启动镜像。官方仓库默认镜像名一般是 workbuddy-agent 这样的命名按文档拉取即可crayfish pull workbuddy-agent:latest crayfish run --name agent-01 --workspace ~/agent-data \ --enable-gui --share-clipboard --share-audio这条命令里几个参数值得展开说--workspace指定工作的持久化目录所有 Agent 生成的中间文件、日志、配置都放在这里删容器不影响数据。--enable-gui是关键开关它会把 Agent 的图形输出映射到宿主机否则容器里只有命令行什么都“看”不到。--share-clipboard允许 Agent 读写宿主机剪贴板这个在做跨应用复制粘贴时非常常用。--share-audio让 Agent 可以播报声音适合做语音提醒类任务。如果是在无桌面环境的服务器上跑可以不用--enable-gui改成--headless模式Agent 会以无头方式运行界面交互改为远程 VNC 访问。3.2 容器资源限制与性能调优桌面 Agent 是吃资源的大户尤其是视觉模型部分。我实测下来默认参数启动后内存占用通常在 2GB 到 4GB 之间如果加载本地 OCR 或视觉模型内存会飙到 8GB 以上。建议在crayfish run时明确指定资源上限crayfish run --name agent-01 \ --workspace ~/agent-data \ --enable-gui \ --memory 8g \ --cpus 4 \ --gpus all内存不够的表现是容器被 OOM Killer 杀掉日志里会出现 “Killed” 字样排查时先看docker stats确认实际占用。CPU 核数给太少会导致 Agent 响应很慢尤其是在网页操作场景下浏览器渲染本身就很吃 CPU。还有一个常被忽略的配置临时目录大小。Agent 执行任务时要下载文件、保存截图、渲染页面默认的/tmp如果太小经常出现“磁盘空间不足”的假报错。建议挂载一个 10GB 以上的临时目录crayfish run --name agent-01 \ --workspace ~/agent-data \ --tmpfs-size 10g \ --enable-gui3.3 持久化策略容器删了但数据还在容器最大的坑是“一删全没”。WorkBuddy 的身份信息、模型 API Key、记忆库、历史任务记录如果不做持久化容器一重建就全部丢失。Crayfish 的--workspace参数实际上会把宿主机目录挂载到容器内的/data所有状态默认写入该目录所以只要挂载路径不变数据就跟着宿主机走。我建议的目录规划是~/agent-data/ ├── config/ # Agent 配置文件、API Key ├── logs/ # 运行日志 ├── memory/ # 长期记忆向量库 ├── skills/ # 自定义技能脚本 └── output/ # 任务产出物这样备份就变成了一个tar命令的事。要迁移到另一台机器时打包整个目录在新机器上重新crayfish run并挂载同样的目录数据和技能全部还原不需要重新配置。3.4 网络策略Agent 能不能访问宿主机局域网默认情况下容器是独立的网络命名空间宿主机通过localhost访问的服务在容器里是访问不到的。比如你本地跑了一个 API 服务在 8000 端口Agent 容器里访问localhost:8000会是连接拒绝正确做法是访问host.docker.internal:8000。在 Crayfish 里可以通过--network host让容器直接复用宿主机网络这样localhost完全等价。好处是配置简单、不丢包、本地服务都能直接访问坏处是隔离性变弱Agent 可以直接探测你宿主机上所有暴露的端口。我个人的建议是日常用默认 bridge 模式配合host.docker.internal访问宿主服务只有调试阶段才临时用--network host。4. WorkBuddy 的实操工作台、技能库与自定义指令4.1 首次启动与工作台界面容器启动成功后如果开了--enable-gui宿主机桌面上会弹出一个独立窗口这就是 WorkBuddy 的主工作台。界面布局大概是三栏左侧是任务列表和会话历史中间是 Agent 的“视觉”区域也就是它当前的屏幕画面右侧是 Agent 的“思考过程”日志。第一次启动后WorkBuddy 会引导你配置模型 API。你可以选择云端模型比如各家大模型的官方 API也可以指定本地模型服务地址。如果选择本地模型建议给它单独的 GPU 资源避免和 Agent 抢显存。配置完模型我建议第一件事先跑一个自检任务让它“看看当前桌面告诉我打开了哪些窗口”。这一方面能验证 GUI 映射是否正常另一方面也顺便验证模型 API 是否连通。如果这一步失败了后面所有视觉操作都会依赖不上。4.2 skill 机制比插件轻量比提示词可靠WorkBuddy 的 skill 机制是它最实用的设计之一。简单说skill 就是把一段频繁使用的“指令 脚本 元信息”打包成一个可复用的能力单元。比如我可以写一个“Excel 汇总”的 skill它定义了输入格式一个目录路径、处理逻辑读所有 xlsx 文件并合并、输出规范生成一份汇总报告到指定目录。和传统插件的区别在于skill 不需要编译、不需要复杂的权限声明本质就是“一个 YAML 描述文件 一个 Python 脚本”。但它的价值在于给 Agent 提供了“如何正确完成这件事”的约束框架比你在提示词里写“请你帮我汇总一下”要可靠得多。我这里提供一个自定义 skill 的模板示例name: email_summary description: 汇总指定邮箱文件夹中的邮件生成摘要报告 version: 1.0.0 inputs: - name: folder_path description: 邮件文件所在目录 type: string required: true entrypoint: run.py timeout: 300配套的run.py只需要实现一个主函数读取传入参数并输出结果。写完后放到工作区的skills/email_summary/目录下重新扫描技能库Agent 就会自动发现并启用这个 skill。实际体验中skill 是让 Agent 从“玩具”变成“生产力工具”的关键一步。没有 skill 时每次任务都是临场发挥结果不可控有了 skill等于给 Agent 提供了标准作业程序稳定性和可信度大幅提升。4.3 自定义指令与日常任务编排除了 skillWorkBuddy 还支持自定义指令Custom Instruction。这更像是一个长期有效的“人格设定”或“工作规范”。比如你可以写“在执行任何数据处理任务前先确认数据文件的编码格式如果遇到乱码先尝试 UTF-8 再试 GBK。”这些指令会进入 Agent 的系统提示词影响它后续所有的行为逻辑。和 skill 的组合使用方式是自定义指令定规矩skill 给能力任务编排串流程。我目前用得比较多的一个组合是“定时钉钉多维表数据同步”用一个 cron 任务触发 WorkBuddy让它读取多维表 API 的更新数据调用我写的dingtalk_syncskill 处理格式再写入本地数据库最后发送一条企业微信通知。整套流程在无人干预的情况下已经稳定跑了几周中途页面改版过一次它自己调整策略绕过去了——这是传统 RPA 做不到的。4.4 与影刀 RPA 的混合实战我并不建议把所有 RPA 流程都迁移到 Agent。我自己的实践是影刀负责高频稳定的网页数据采集和系统录入WorkBuddy 负责需要判断的任务比如“根据邮件内容决定走哪条 RPA 流程并触发它”。这里有个现成的整合姿势Agent 通过 HTTP 接口调用 RPA 机器人的 WebhookRPA 执行完通过返回值回调给 Agent。Agent 拿到执行结果后再决定下一步动作。这样等于给 RPA 装了一个“会思考的调度大脑”原来只能按固定表跑的 RPA 变成了可以动态决策的自动化体系。比如我之前接的一个电商订单处理场景WorkBuddy 每小时看一次订单后台发现异常订单金额不符、地址缺失就标记出来正常的订单则触发影刀跑自动发货流程。影刀执行完把结果反馈给 WorkBuddy由它更新记录。整个链路里RPA 干它最擅长的稳定执行Agent 干它擅长的理解和判断各取所长。5. 常见问题与排查技巧实录5.1 启动非常慢很多人在热词里搜“workbuddy启动非常慢”我也踩过这个坑。第一次启动慢是正常的因为要拉取镜像、初始化模型、构建向量索引这个过程持续 5 到 10 分钟都属正常。但如果你已经跑过一次第二次启动还是很慢那就要排查了。我遇到的情况是挂载目录里堆积了大量历史截图和日志Agent 启动时会对这些文件做索引文件一多就把启动拖垮了。解决办法是把output/和logs/定期清理或者挂到一个临时目录。还有个隐蔽原因是“模型 API 连接超时”。如果 Agent 启动过程中要检查云端模型的可用性而网络有延迟界面会一直卡在“初始化模型”的页面。这个可以用crayfish logs agent-01查看日志看到model health check timeout这类关键字基本就能确认。5.2 网络连接失败热词里也有“workbuddy网络连接失败”。这个问题需要区分是宿主机的问题还是容器内的问题。宿主机能上网、容器上不了网通常是 Docker 的 DNS 配置问题。我用一个临时容器测试一下docker run --rm busybox nslookup baidu.com如果解析失败改 Docker 的 DNS 配置编辑/etc/docker/daemon.json加上{ dns: [223.5.5.5, 114.114.114.114] }然后重启 Docker。这个配置对 Windows 上的 Docker Desktop 同样适用只是配置文件路径不同。另一个可能性是 Agent 内部的代理设置。如果宿主机挂了代理容器默认不会继承需要在crayfish run时通过环境变量传进去crayfish run --env HTTP_PROXYhttp://host.docker.internal:7890 \ --env HTTPS_PROXYhttp://host.docker.internal:7890注意这里要用host.docker.internal而不是localhost原因前面说过。5.3 Agent 看不到桌面或无法点击这个问题的表象是容器起来了日志也正常但 Agent 说“我看不到屏幕”。排查思路按顺序来第一步确认--enable-gui真的传了用crayfish inspect agent-01看启动参数。第二步确认宿主机有图形会话纯 SSH 登录的服务器默认没有 X ServerAgent 自然看不到屏幕。第三步确认权限Docker 需要能访问宿主机的 X11 socket通常要加--device /dev/dri和挂载 X11 socket。如果是 Wayland 会话兼容性比 X11 差一些建议在 Ubuntu 上把会话切回 Xorg 再跑容器版 WorkBuddy能省掉很多奇怪的兼容问题。5.4 常见问题速查表现象可能原因解决思路启动卡在初始化历史文件索引过多清理 output/logs 目录Agent 看不到屏幕缺少 GUI 映射参数检查--enable-gui与 X11 权限点击无效分辨率不匹配容器内分辨率改成宿主机相同模型响应超时API Key 失效或网络差检查日志中的 HTTP 状态码容器被 OOM 杀掉内存限制太小--memory调到 8g 以上剪贴板不共享未加--share-clipboard重建容器时加上该参数skill 扫描不到目录结构不对确认skills/技能名/下有 yaml 和脚本钉钉同步失败接口权限过期重新授权并刷新 Token5.5 一条独家避坑建议关于写 skill 的健壮性我给一个个人血泪经验一定要在 skill 里处理“超时”和“重试”。容器版 Agent 一旦某个 skill 运行超过timeout设定值会被强制结束但外部系统比如钉钉可能已经收到了请求。如果不做幂等处理重复执行一次就会产生重复数据。最简单的做法是在每个 skill 的入口处加一个唯一任务 ID写入本地状态文件执行前先检查这个 ID 是否已经处理过。哪怕 Agent 反复重试同一个任务也不会产生副作用。这个习惯救了我无数次。6. 我的个人体会这套容器版方案给了我一个很深的感触容器化的意义不只是“免安装”而是让 Agent 的部署和管理变成了和 Docker 容器一样标准化的操作。我可以在服务器上跑三个不同配置的 Agent 实例各挂不同的技能库通过 Crayfish 统一管理哪个不稳定就单独重启哪个数据互不干扰。另外一点是不要急着把所有自动化全部迁移到 Agent。RPA 发展了这么多年在稳定性、速度、审计合规这些方面依然有不可替代的价值。最好的架构是“Agent 做大脑RPA 做手脚”两者通过接口层打通。WorkBuddy 容器版的存在恰恰让这种混合架构能在一台机器上简单落地——这比争论“谁能取代谁”有意义得多。最后再分享一个小技巧如果你在 Windows 上用桌面版 WorkBuddy 跑得好好的但想给它加一层隔离保护也可以用 Docker Desktop 跑容器版两者可以共存共享同一个技能库目录互不影响。我目前就是这样用的出门在外用容器版远程跑任务回到工位切换到桌面版做精细调试体验非常顺滑。