企业官网建设流程全解析

做了三年影刀RPA，接过电商订单、走过Excel报表自动化、也写过一堆网页数据采集流程。说实话，这套东西在固定规则下非常能打。但今年上半年开始，客户那边需求变了——不再是要"严格按步骤执行"的规则脚本，而是希望机器人拿到任务后能自己判断"这个字段该填哪里""这封邮件该怎么回"。这让我不得不重新审视Agent类工具的定位。正好最近把WorkBuddy容器版和桌面Agent执行层Crayfish完整跑了一遍，体验之后最大的感受是：它们和RPA压根不是一类东西，硬要对比，格局就小了。这篇文章不打算做产品宣传，只以一个实践者的视角拆解三件事：WorkBuddy容器版到底解决了什么问题、Crayfish在桌面Agent体系里扮演什么角色、以及容器化给自动化带来的那些RPA给不了的真实优势。

1. 从影刀迁移到 WorkBuddy 容器版：先说清楚我在对比什么

1.1 我原本的 RPA 工作方式

之前做电商场景，影刀用得最多。典型任务长这样：定时从商家后台导出订单Excel，按店铺拆分，再逐条填写到ERP系统。这套流程在影刀里是这样实现的：写一个流程块，用元素选择器绑定网页按钮位置，用循环读取Excel每一行，最后通过"填写输入框"指令把数据填进去。流程稳定，运行效率高，出问题也有明确的日志可以追踪。但最大的痛点在于：任何一次页面改版，任何一次字段增加，都需要人工重新标注元素定位。这还只是维护成本，真正让我头疼的是，客户偶尔会提出一些"看着流程，自己临场变通一下"的需求，这在传统RPA里根本写不出来。

1.2 WorkBuddy 容器版是什么

WorkBuddy 这个名字在Agent工具圈已经不算陌生。简单说，它是一个以大语言模型为核心驱动的桌面Agent应用框架，你不需要写死每一步操作，而是用自然语言描述目标，WorkBuddy负责把目标拆解成可执行步骤，并调用相应的工具/Skill去完成。所谓"容器版"，就是把这套Agent核心跑在Docker等容器运行时里，不再依赖本机图形界面。它和你直接安装一个WorkBuddy桌面客户端有本质区别：桌面客户端偏向单机交互，像个能用对话控制电脑的助手；容器版则强调的是服务化能力——通过API通信、支持多实例编排、可以嵌入到企业系统里当"数字员工"的后端大脑。

1.3 Crayfish 在体系里的位置

标题里提到了Crayfish，这名字初看容易让人以为又是一个独立Agent，实际跑下来我倒觉得它更像Agent体系里的"手"——一个桌面执行运行时。它独立运行在宿主机或者有桌面环境的容器里，负责屏幕识别、窗口管理、鼠标键盘模拟、剪贴板读写、文件系统操作这些接地气的命令。

这里有个关键设计值得展开：WorkBuddy容器版做决策，Crayfish做动作。决策层不关心"按钮在屏幕哪个坐标"，它只需要说"点击确定按钮"，Crayfish负责在桌面环境中找到并执行这个动作。两层通过本地HTTP或WebSocket通信，任务队列在中间调度。这样设计带来的好处非常明显：Agent核心可以跑在无头服务器上，而执行层可以分布在多台桌面机器上，二者各自独立扩展。这套架构，和传统RPA那种"脚本+录制器+中央调度平台"的思路，已经完全不是一个维度。

2. Crayfish 与 WorkBuddy 的两层分工：Agent 大脑为什么必须和桌面操作解耦

2.1 大模型不应该直接握鼠标

一开始我也困惑：既然大模型啥都能干，为什么不让WorkBuddy直接操作界面，非要中间隔一层Crayfish？在跑通一个填表任务后我就明白了。让大模型直接输出鼠标坐标，等于让一个读了很多书但没练过手的实习生直接做外科手术——逻辑上能推理出"应该点哪里"，但手会抖，点不准，而且每次点击的像素坐标根本不可控。Crayfish这层解决的就是这个落差：模型只输出语义化指令（比如"element:text=提交按钮 => click"），Crayfish通过视觉识别和目标检测定位真实坐标，再模拟鼠标完成操作。

2.2 两层协作的具体流程

我这里用实际跑过的"把Excel里的数据填到ERP表单"拆解一下：

1. WorkBuddy容器版收到任务描述："把 orders.xlsx 里的前10行数据填入ERP采购单页面"。
2. WorkBuddy调用模型进行任务分解，得到子步骤清单：读取Excel->打开ERP页面->定位采购单控件->填数据->核对->保存。
3. 每个子步骤再映射到对应的Skill。读取Excel有现成的pandas技能包；打开页面由Crayfish执行浏览器窗口唤起；定位控件这一步，Crayfish截取屏幕图片，经过OCR把界面元素转成带坐标的文本树，Agent根据语义判断哪个是"供应商编号"输入框。
4. Crayfish执行填入动作，完成后截屏回传，WorkBuddy再次调模型判断是否填写正确。

2.3 为什么说这是"语义化界面"

传统RPA靠的是DOM选择器、窗口句柄、坐标偏移，本质上是个"物理定位器"；Crayfish这一层做的事情更高级——它把屏幕信息先转成"人话"，变成Agent能理解的结构化数据，再让模型基于语义去决定动作。说得夸张一点，RPA看到的是像素，Agent理解的是含义。这正好是桌面Agent相对RPA鲁棒性大幅提升的核心原因：页面布局调整了，选择器失效，RPA脚本直接崩溃；而Agent看到"一个写着'提交'的按钮"，不管它在页面顶部还是底部，都能正常点击。

两层协作的架构也带来了一个隐性好处：Agent策略层可以升级迭代，而执行层保持稳定。今天我接的是DeepSeek，明天想换别的模型，只需要改WorkBuddy侧的模型配置，Crayfish毫无感知。相对RPA那种"流程和界面强绑定"的模式，这种解耦让整体系统在技术演进面前更有韧性。

3. 容器运行时到底解决了什么：环境隔离、模型接入、并发编排与最容易被忽略的隐患

3.1 为什么非要在容器里跑

作为一个常年被Windows环境折腾的RPA开发者，我第一次看到WorkBuddy容器版时的第一反应是：这不就是脱裤子放屁吗？直接在服务器上装个程序跑不就行了？直到自己部署过一遍，才理解容器化不是形式主义，而是切切实实解决了几类具体问题。

首先是环境隔离。WorkBuddy容器版要跑Python依赖、OCR模型、浏览器内核、向量数据库，还有各种Skill相关的第三方库。这些组件放在一起来安装，版本冲突能让人崩溃——一个Skill要Python3.10，另一个要3.8，pip依赖直接打架。容器化之后，每个实例内部的环境是自包含的，互不干扰，想换版本直接重新build镜像就行。

其次是模型接入的灵活性。以我接DeepSeek为例，只需要在容器启动时通过环境变量配置API Key、Base URL、模型名称，WorkBuddy容器版的模型网关会统一转发请求。因为Agent调用模型是走标准OpenAI兼容协议，所以换模型就像换个环境变量一样简单。这比起RPA工具商绑定自家AI能力，开放度完全不是一个级别。

3.2 多实例编排：数字员工可以横向扩展

RPA时代做并发有个很现实的问题：一个机器人实例需要一整个Windows虚拟机资源，License费用还不便宜。WorkBuddy容器版在这方面有明显优势——既然Agent核心是无状态的，那就可以通过Docker Compose或者Kubernetes同时拉起多个容器实例，每个实例对接不同的Skill配置，处理不同业务线。

我在测试环境用一台4核8G的Linux服务器跑了两套WorkBuddy容器实例：一套对接电商订单处理，一套对接财务对账任务。两个实例互不相干，各自独立扩缩容。API层再挂一个简单的负载均衡，基本就能当一个小型自动化平台用。这种感觉，确实是传统RPA体系给不了的。

3.3 部署踩坑：容器没有显示服务器，Crayfish按不下去按钮

不过这段标题里提到的"容器运行时"真的不是开水一冲就能喝。我把WorkBuddy容器版跑起来后，第一次让Agent执行打开浏览器的操作，日志里直接报错：无法找到DISPLAY环境变量。这是Linux容器最常见的坑——容器默认是没有X11图形显示能力的，而Crayfish要操作GUI应用必须依赖一个显示服务器。

我的解决方案比较直接：如果WorkBuddy和Crayfish都跑在宿主机上，就把宿主机的 /tmp/.X11-unix 目录挂载进容器，并设置 DISPLAY 环境变量指向宿主机当前显示会话。但需要注意，这种方案只适合单机测试。如果是纯服务器环境，就干脆让Crayfish独立部署在一台带桌面环境的机器上，WorkBuddy容器版通过API远程下发指令。这两种模式的取舍后面细说。

还有两个细节也特别容易掉坑。一是容器里默认没有中文字体，OCR识别中文界面直接乱码，后来在宿主机安装了fonts-noto-cjk再挂载进容器，才把识别准确率提上来。二是时区和locale问题，容器默认是UTC，生成的日志时间和我本机差8小时，排查问题的时候非常迷惑，必须在Dockerfile里提前设置TZ=Asia/Shanghai。

3.4 WorkBuddy 启动慢的排查

网上很多人反馈WorkBuddy启动非常慢，我一开始也遇到了。分析日志后发现，慢的核心原因是容器启动时要做模型预热、加载向量索引、初始化OCR模型，这些加起来可能占用二三十秒。解决方案分两头：第一是在镜像里预下载模型文件，不要等运行时再拉取；第二是把健康检查的超时时间调大，别让编排平台在容器还没就绪时就判定失败重启。

这里分享一个最典型的docker-compose配置片段，跑的是WorkBuddy核心服务加Crayfish执行器：

services: workbuddy: image: workbuddy-container:latest container_name: workbuddy-brain environment: - DISPLAY=:0 - TZ=Asia/Shanghai - LLM_API_KEY=${DEEPSEEK_API_KEY} - LLM_BASE_URL=https://api.deepseek.com/v1 - LLM_MODEL=deepseek-chat volumes: - /tmp/.X11-unix:/tmp/.X11-unix - /workspace/skills:/app/skills - /workspace/models:/app/models ports: - "8080:8080" healthcheck: test: ["CMD", "curl", "-f", "http://localhost:8080/healthz"] interval: 15s timeout: 10s retries: 20 start_period: 60s crayfish: image: crayfish-desktop-runtime:latest container_name: crayfish-hands environment: - TZ=Asia/Shanghai - WORKBUDDY_ENDPOINT=http://workbuddy:8080 volumes: - /tmp/.X11-unix:/tmp/.X11-unix - /dev/shm:/dev/shm depends_on: workbuddy: condition: service_healthy

注意里面/dev/shm的挂载也不能省，Chromium之类的浏览器内核在容器里对共享内存大小极其敏感，不挂载大一点的/dev/shm，页面截图功能会随机失败。

4. 桌面 Agent 相对 RPA 的真实优势：从"录脚本"到"理解任务"

4.1 需求描述成本大幅下降

做RPA项目，最痛苦的阶段不是开发，而是前期沟通。业务部门说"帮我自动整理报表"，你得追着问几十个问题：什么格式的报表？来源系统是哪个？字段对应关系是什么样的？异常怎么处理？这套需求澄清流程周期长，而且业务人员的描述和开发人员的理解之间经常有偏差。

桌面Agent把这道鸿沟填平了。同样是"帮我整理报表"，你可以直接告诉WorkBuddy"每周五下午5点把运营后台的销售数据整理成Excel，按地区和产品线分别汇总，发到指定邮箱"。Agent会把这句话解析成任务清单，执行过程中遇到歧义还会主动提问，或者按最合理的常识默认处理。Agent不是让你写需求，而是让你说需求。对非技术背景的业务用户来说，这几乎是降维打击。

4.2 鲁棒性的底层逻辑不同

传统RPA处理页面变化的第一道防线是元素选择器，页面结构一变，脚本立刻失灵。有经验的开发者会写一堆异常处理逻辑，比如元素不存在时尝试备用定位器，再不行就截图报警。但这都是事前防御，永远有覆盖不到的情况。

桌面Agent的思路完全不同。它不关心元素在DOM树里的绝对位置，它靠"语义理解"工作。表单提交按钮位置变了？没关系，Agent通过Crayfish截图，看到页面有一个包含"提交"语义的按钮，依然能正常点击。下拉框选项被重构了？只要文本语义还在，Agent就能重新匹配。这种鲁棒性不是靠代码堆出来的，而是靠语言模型的理解能力天然带来的。我在迁移一个旧的影刀脚本时，旧脚本动不动就因页面更新而失败，而WorkBuddy跑类似任务时，即使页面有轻微改版也能继续推进。

4.3 Skill 机制让经验变成可复用的资产

用过影刀的人都知道，影刀有"应用市场"和"组件库"，可以下载别人封装好的流程模块。但RPA组件的复用粒度太重，经常要跟着具体业务场景走，换一个系统就废了。Skill机制不一样，它的定位是"一项独立能力"。我写好一个"PDF转Excel"的Skill，它就是一个能处理任意PDF文件的原子能力；我写好一个"网页内容摘要"的Skill，它就能被所有需要摘要的任务引用。

这种方式天然适合团队积累内部知识库。RPA时代团队沉淀的是"某张表的填法"，Agent时代沉淀的是"某项能力的用法"，后者的可迁移性强太多。

4.4 人机协作模式更透明

还有一点，Agent在执行过程中会生成自然语言解释："我正在打开销售报表页面""检测到表格数据共120行""Excel文件已生成"。你随时可以打断它、纠正它、补充新要求。传统RPA跑起来就是个黑盒，中途想改条件只能停了改脚本再重跑，代价极大。这种透明性带来的不仅是效率，更是信任感，尤其是面对非技术管理者时，"看得懂的Agent"远比"神秘的自动化脚本"更容易在组织里推广。

4.5 代价也要讲清楚

但必须泼一盆冷水：桌面Agent并不是免费的午餐。模型调用有延迟、有成本，每一步决策都伴随着不确定性，需要完善的验证机制。不稳定的网络可能导致模型调用失败，OCR识别错误可能导致点错位置，这些都需要额外的重试策略和人工兜底设计。相较之下，RPA脚本一旦调试通过，执行效率极高，性能稳定，适合大规模、高频、固定规则的重复操作。

所以我的结论是：桌面Agent不是来取代RPA的，它和RPA解决的是不同层面的问题。RPA解决"怎么稳定地做"，桌面Agent解决"怎么做才聪明"。两者在未来会被整合进同一个自动化平台里，各司其职。

5. 实操：WorkBuddy 容器版跑通第一个 Skill（接入 DeepSeek）

5.1 环境准备与架构选型

实操部分，我以一台Ubuntu 22.04服务器为例，环境要求如下：

• Docker Engine 20.10+
• CPU 4核以上、内存8G以上（跑Agent核心需要，如果有GPU更好）
• 宿主机或同网络内一台带桌面环境的机器（用于部署Crayfish执行桌面操作）

部署模式我选用"容器里跑WorkBuddy核心 + 宿主机跑Crayfish"的混合方案。原因是纯容器模式下Crayfish需要额外配置VNC虚拟显示，运维复杂度高，而混合模式既保留了容器化的模型调度优势，又避免图形环境折磨。

5.2 配置模型接入

WorkBuddy容器版通过标准OpenAI兼容协议访问模型服务，所以DeepSeek的接入非常直接：

export DEEPSEEK_API_KEY="sk-你的key" export LLM_BASE_URL="https://api.deepseek.com/v1" export LLM_MODEL="deepseek-chat"

这段配置加在docker-compose环境变量里即可。接入后，WorkBuddy会自动把任务拆解、工具调用、结果校验这些环节的模型请求统一转发到DeepSeek。这一步是整个体系中技术含量最低但最容易出错的环节——很多人的API Key配置完不生效，往往是没注意Base URL末尾的/v1路径，DeepSeek兼容OpenAI协议对这个路径有要求。

5.3 注册第一个 Skill：从PDF提取表格并输出Excel

Skill本质上是一段带有输入输出定义的代码片段，WorkBuddy会在任务需要时按描述自动匹配调用。这里写一个示例，将PDF里的表格提取后转成Excel：

from pathlib import Path import pdfplumber import pandas as pd def run(input_path: str, output_path: str = "output.xlsx"): tables = [] with pdfplumber.open(input_path) as pdf: for page in pdf.pages: for table in page.extract_tables(): if table: tables.append(table) if not tables: return {"status": "no_table_found"} # 取表头+数据 header = tables[0][0] rows = [] for t in tables: rows.extend(t[1:]) df = pd.DataFrame(rows, columns=header) df.to_excel(output_path, index=False) return {"status": "ok", "output": str(Path(output_path).resolve())}

把这个文件放到容器挂载的/workspace/skills/pdf_to_excel.py目录，再配一个Skill描述文件，声明技能名称、功能描述、输入参数格式即可。WorkBuddy会在Agent规划任务时，根据"提取PDF表格"这个语义描述，自动关联到这个Skill。

5.4 通过API触发任务

容器版的价值就在API交互上。任务触发接口很简单，一行curl就能搞定：

curl -X POST http://localhost:8080/api/v1/tasks \ -H "Content-Type: application/json" \ -d '{ "task": "读取 /data/订货单.pdf 中的表格，整理成Excel后保存到 /data/result.xlsx", "skills": ["pdf_to_excel"] }'

返回任务ID，然后轮询任务状态接口即可。跑完去目录里确认输出文件，整个过程没有打开任何界面，纯服务端执行——这对需要嵌入到现有业务系统的场景来说，是非常关键的能力。

5.5 常见错误排查清单

把部署过程中踩过的坑整理成一张表，后面看到类似的直接对号入座：

这五条基本覆盖了从零到第一个任务跑通的全过程。如果一次性全对上，剩下的就是业务逻辑层面的打磨了。

6. 三类自动化场景，三种不同的选型答案

6.1 场景一：财务对账、人事自动处理这类固定流程

这类任务特征是流程严格固定、涉及时序审计、不允许自由发挥。比如财务每月的银行对账，每一笔勾稽逻辑都有明确规则，做错一笔要出大问题。这种场景我会明确推荐继续用影刀、UiPath这类成熟RPA产品。理由很直接：规则明确、重复度高、审计要求严格，RPA的确定性就是它最大的优势。脚本一旦调试通过，每一次执行都可以预测，出现问题可以复现，不会出现"模型今天状态不好所以跑偏了"这种玄学问题。

在影刀里做一个对账Agent，流程是死的：下载银行流水->读取系统订单->逐笔匹配->输出差异Excel。用RPA写得清清楚楚，运行又快又稳，完全没必要上Agent。

6.2 场景二：跨系统数据搬运、重组、轻度判断

这类任务在电商运营、销售支持、市场分析里面特别常见。比如从CRM导出客户数据，结合社交媒体信息做客户画像分类，再推送个性化跟进话术。这里面有"分类""判断""生成内容"的成分，传统RPA写起来痛苦，Agent做起来顺理成章。

我实际测过一个场景：每天早上从三个业务后台抓数据，合并去重后，按客户类别生成针对性通知文案。RPA要写判断逻辑和文案模板，工作量巨大；WorkBuddy只需要一个自然语言任务描述，Agent自动调用数据读取Skill，用模型生成文案，再由Crayfish打开IM工具发送。这种"数据+判断+生成"的复合任务，就是桌面Agent的主场。

6.3 场景三：混合模式——RPA做动作，Agent做决策

我个人最看好的形态是混合架构：RPA引擎负责稳定、高频、精确的原子操作，Agent负责任务理解、规划、异常处理和自然语言交互。比如一个电商订单处理系统：Agent接收订单消息，理解业务语义，判断是否属于异常订单；正常订单调用RPA流程完成标准处理流程；遇到异常情况，Agent不依赖固定分支，而是根据当前数据自己决定是用备用流程还是转人工。

这种架构下，RPA保证了下限（稳定），Agent拉高了上限（智能）。两个系统通过API桥接，Agent发指令给RPA执行，RPA把结果回传给Agent判断。成本可控、风险可控、性能也可控。

6.4 你的团队应该怎么选

选型时我建议你用下面这个清单快速判断：

• 任务规则是否频繁变更？如果每月都有逻辑调整，Agent的语义处理优势更明显。
• 是否需要自然语言输出？要写回复、写摘要、写报告，直接锁定Agent。
• 是否有严格的执行审计要求？票证、金融、医疗类场景，RPA更稳妥。
• 团队技术栈如何？如果以Python为主，Agent生态上手更快；如果以低代码拖拽为主，RPA更友好。
• 成本敏感度如何？高频高并发固定任务用RPA成本更低，低频灵活任务用Agent的边际成本几乎为零。

单个任务里如果混合了多种特征，就按6.3的思路做混合架构，不要在单一平台里硬塞所有需求。

7. 最后关于容器化这件事，再多说几句

从影刀到WorkBuddy容器版这一路折腾下来，我最大的收获不是某个工具好不好用，而是意识到自动化行业的底层逻辑正在换：以前我们写的是"怎么做的说明书"，现在只需要表达"要什么结果"。容器化让Agent可以像微服务一样被编排、调度、观测，这让"数字员工"这个概念第一次真正变得可落地、可量化和可横向扩展。

如果你现在正打算从零接触桌面Agent，我的建议是：先别急着上容器版，花两天时间在桌面客户端把Skill机制和任务拆解逻辑跑通，理解Agent是怎么思考的；再迁移到容器版，把API接好，把环境变量管好，把模型接对。等到容器版运行稳定了，你才会真正体会到那套"决策与执行分离"架构的妙处。

踩过几次坑之后回过头来看，RPA和桌面Agent之间的关系，更像是算盘和计算器——算盘在特定场景下依然精准可靠，但计算器能做的事情，早已超出了"算数"本身。把两者都握在手里，才是当下自动化从业者比较务实的姿势。