企业官网建设流程全解析

最近好几个团队过来问我 Computer Use 怎么落地，问题绕来绕去最后都会落在同一个点上：在智能体工作台里明明已经验证过 AI 能看懂屏幕、能点按钮，为什么一接到 LCU 本地控制单元就各种不干活？这个现象我遇见过太多次了。Computer Use 不是简单把模型接到鼠标键盘驱动上，它是一条完整的链路，从界面验证到 LCU 接入之间隔着环境差异、指令协议、权限模型和故障回滚。这篇文章就按我实际跑过的路线，把从工作台验证到 LCU 接入的完整过程拆开讲一遍。

1. 理解 Computer Use：它到底解决什么问题

1.1 所谓“Computer Use”不是远程桌面

很多人第一次听到 Computer Use，以为就是给 AI 装一双眼睛和一只鼠标，让它能远程操作电脑。这么说也不算错，但很容易把实现难度想小。真正的 Computer Use，是让算法模型基于屏幕截图、窗口结构、坐标位置和操作状态，自己推理下一步该做什么，再通过接口执行点击、输入、滚轮、快捷键等操作。它解决的核心问题是：那些没有对外开放 API、只有图形界面的老系统，终于可以交给智能体去操作了。

我在模拟项目 X 里接的是一套业务办理系统，没有任何 API 文档，也不能改数据库表结构，唯一能用的就是浏览器界面。传统做法要么派个人每天重复点鼠标，要么写脚本死磕元素选择器，可界面一改版脚本就全废。Computer Use 的逻辑完全不同：它把屏幕当成“人眼看到的画面”，通过视觉理解和操作反馈循环来做决策，界面布局换个位置也能根据语义重新找到目标按钮。这也是为什么它特别适合对接政务类、财务类、客服工作台这类以 GUI 为主的存量系统。

不过也要说清楚，Computer Use 不是万能的。它能做的事情上限很高，但稳定性下限也低。一个干净的验证环境里能跑通的任务，换到真实业务桌面上可能因为分辨率不同、弹窗遮挡、权限控制、输入法状态、网络延迟等因素直接失败。所以我一直跟团队说，验证通过只是起点，LCU 接入才是真正的考验。

1.2 从界面验证到 LCU 接入，差的是“信任链路”

界面验证阶段的本质是“实验”，LCU 接入阶段的本质是“生产”。实验环境里你只需要证明模型理论上能完成这个任务，生产环境里你需要保证每一次执行都可控、可追踪、可回滚。这两者之间的差距不是代码量的差距，而是信任链路的差距。

什么叫信任链路？就是一条指令从用户意图变成操作系统真实操作的完整通路。在工作台界面里，这条链路由人盯着，AI 每走一步你都能看到，出错了可以随时中断。但接入 LCU 后，AI 的决策会直接落在一台真实运行的业务电脑上，中间可能没有人实时盯屏，那你就必须提前回答几个问题：AI 识别到的元素坐标对不对？点击之后有没有二次确认弹窗？如果任务执行了一半发现目标窗口被别的程序盖住了怎么办？操作日志是否能还原出每一次鼠标动作？

这些问题不是靠模型能力就能解决的，需要在架构上做兜底。我在接入时把链路拆成了四层：指令输入层、决策推理层、执行控制层、环境适配层。界面验证主要验证的是决策推理层的能力，而 LCU 接入要把四层全部串起来，其中执行控制层和环境适配层才是工作量的大头，也是最容易出问题的地方。

1.3 适用场景与实际影响范围

Computer Use 和 LCU 组合在一起，能解决的场景主要集中在四类。

第一类是无法提供 API 的历史遗留系统。这类系统通常是某个机构的核心业务工具，动不了源代码，但操作流程又特别固定，非常适合用 Computer Use 做流程自动化。第二类是跨系统数据搬运。比如从一个后台系统读数据，再填写到另一个报表系统，中间没有消息总线，人工操作慢且容易错，交给 Computer Use 后可以把时间压缩到原来的十分之一。第三类是桌面软件自动化测试。传统 UI 测试脚本维护成本高，而基于视觉理解的 Computer Use 对界面改版的容忍度明显更高。第四类是远程协助和无人值守场景，不过这部分对安全性的要求会更高。

影响范围需要提前界定清楚。我建议在项目启动时就明确哪些电脑可以接入 LCU、哪些不允许；哪些任务可以自动执行、哪些必须人工确认；哪些数据可以被模型看到、哪些要打码处理。这些边界如果不提前划好，后面每走一步都会踩到合规和权限的坑。

2. 在智能体工作台里做第一轮界面验证

2.1 准备一个干净的验证环境

不要拿日常办公电脑直接做验证，也不要直接在业务生产环境里试。我吃过这个亏：第一次测试时随手在常驻桌面开了好几个通讯软件，结果 AI 的鼠标操作总是被弹出的消息提醒打断，一次简单的表单填写跑了三遍都没成功。后来我把验证环境固定为一台专用的虚拟桌面，分辨率固定、壁纸固定、浏览器固定、输入法固定，所有外部通知全部关闭，才勉强有了“可复现”的测试条件。

准备环境时有几个细节值得注意。第一，屏幕分辨率要锁定，因为模型对坐标的敏感度很高，分辨率一变，元素位置就全偏了。第二，系统主题尽量用默认样式，深色模式、缩放比例、自定义字体都会影响视觉识别效果。第三，清理无关桌面图标和任务栏图标，减少干扰项。第四，准备好一套基准测试任务集，建议包含三种典型操作：信息读取类、表单填写类、跨窗口操作类。这套任务集后面会在 LCU 接入后反复使用，所以一开始就要定义得足够稳定。

环境准备好之后，我习惯先做一次“纯人工操作记录”。把目标任务的每一个动作步骤按顺序记下来，包括点击位置、输入内容、等待时间、出现什么弹窗，形成一个标准答案。这个标准答案不是给模型用的，而是用来评估模型执行的结果是否偏航。

2.2 一条任务跑通的完整步骤

以我测试过的“从查询页面下载报表并重命名”为例，完整步骤可以拆成六个环节。

第一步，智能体工作台读取屏幕，建立当前状态认知。这一步会拿到一整张截图的特征信息，包括页面标题、输入框位置、按钮文字等。第二步，把用户指令解析为行动计划。比如指令是“找到今天所有已完成订单并导出”，工作台会在内部生成一个包含多个子步骤的规划：定位筛选区域、设置日期、点击查询、等待列表加载、点击导出、选择保存路径。第三步，逐个子步骤执行操作，每执行一步后重新截图，判断前一步是否生效。这一步特别关键，因为如果点击查询后数据没有加载出来，模型需要能“看到”加载状态并决定是继续等待还是重新点击。第四步是异常处理，比如弹窗出现时识别弹窗文案并决策点击确认或取消。第五步是最终状态校验，比如检查下载目录中是否出现了文件。第六步是生成操作日志并反馈结果。

这六步里最容易出问题的是第三步和第四步。很多模型在“点击”和“反馈”之间的等待时间上把握不好，页面加载超过三秒就开始乱动，或者弹窗迟迟不出现时不知道要等待。我用的办法是在环境里给模型加一个“动作间隙”配置，也就是强制每一步操作后至少等待 800 毫秒，并且只有在截图发生明显变化后才允许执行下一个动作。这个参数对稳定性的提升非常明显。

2.3 判定“验证通过”的标准：不只盯着截图

很多团队验证完就说“效果不错，可以接 LCU 了”，但问他们“通过的标准是什么”，又说不出个明确的量化指标。后来我给自己定了一套标准，至少同时满足四个维度才允许进入接入阶段。

第一个维度是任务完成率。同样的任务集跑二十遍，成功次数不低于十八次，而且失败的原因不能是同一个位置反复失败。如果老是在同一类弹窗上翻车，说明模型的视觉语义理解对这个场景是无效的，光靠重试解决不了。第二个维度是操作准确率。只看最终结果成功还不够，还要看中间过程有没有多余的点击、误触的快捷键、偏离的鼠标轨迹。多余操作在生产环境里可能引发不可逆影响，哪怕最终结果对也不能接受。第三个维度是日志完整性。每一步操作是否有对应的截图、坐标、动作类型、执行时间，这些日志必须能被完整记录下来，否则后续没法做问题复盘。第四个维度是回滚效率。如果任务执行到一半发现错误，从系统层面恢复到操作前状态需要多久。超过一分钟的回滚时间在无人值守场景下是不合格的。

这四个维度里，我想特别强调操作准确率。我见过有团队报告完成率 95%，看起来很漂亮，但查看日志发现 AI 在桌面上来回乱晃，偶尔还打开了无关应用，只是因为最后误打误撞完成了任务。这种“运气型成功”是绝对不能放进生产链路的。

2.4 界面验证阶段最容易被忽略的参数

界面验证阶段有三个参数经常被忽略，但对接 LCU 后都会变成大问题。

第一个是动作超时时间。工作台环境通常响应很快，但真实 LCU 控制的电脑可能卡顿、可能等待外部系统响应，所以验证环境里就要把超时时间设置到最大预期时间的三倍以上。第二个是操作坐标系。工作台截图可能是按浏览器窗口截的，而 LCU 接的是整个桌面屏幕，坐标系范围完全不同。验证阶段如果只记录浏览器内相对坐标，接入时就还得再做一次坐标转换。第三个是重试策略。界面验证时很多人喜欢把重试次数设得很高，比如点一次没反应就点十次。这在验证环境里没事，但接到 LCU 后可能造成重复提交、重复扣款等严重后果。所以验证阶段就要把重试策略调成“有条件的重试”：只有当截图确认按钮仍在原位且操作无任何副作用时才允许重试。

3. 从工作台到 LCU：接入实施全流程

3.1 LCU 的角色定位与接入前置条件

LCU 就是你放在业务电脑上的那个“本地执行代理”。我用的是 Local Control Unit 的缩写，它的功能是在电脑本地接收上层智能体下发的操作意图，解析成当前系统可执行的指令，并负责收集执行环境的状态反馈给上层。你可以把它理解成一份常驻在电脑上的调度服务，负责连接智能决策和操作系统之间的缺口。

LCU 不能只是一个裸的鼠标键盘驱动，它至少需要包含四个模块：指令接收模块、屏幕采集模块、动作执行模块、状态上报模块。指令接收模块负责从消息通道拿到任务指令，屏幕采集模块负责按需截图或录屏，动作执行模块负责把标准动作翻译成系统级的点击、输入、滚轮等操作，状态上报模块负责把执行结果和当前界面状态回传给上层。

接入前的前置条件我列了一个清单，每一条都对应一个容易踩的坑。第一，电脑必须使用固定账号登录，且该账号要有目标系统的操作权限，不能使用临时共享账号，否则会互相踢下线。第二，桌面主题、分辨率、缩放比例必须固定，不能允许用户随意调整。第三，目标系统所在机器的屏幕不能休眠，电源计划要设为“从不关闭屏幕”。第四，目标系统必须安装指定版本的截图与输入驱动，这里建议使用较稳定的版本，不要频繁升级。第五，网络策略要允许 LCU 访问消息通道，并且提前配置好白名单域名和端口。第六，如果目标电脑有定时重启或系统更新任务，需要提前排除维护窗口。

3.2 指令协议设计：自然语言任务怎么变成控制指令

工作台验证阶段，人跟 AI 的交互是自然语言；LCU 接入阶段，上层系统跟 LCU 之间的交互必须是结构化指令，因为 LCU 本身不具备大模型推理能力（一般也不应该在本地跑大模型）。所以你要设计一套中间协议，把自然语言任务转换成 LCU 可执行的动作序列。

我用的协议格式是一个 JSON 结构，包含任务编号、动作类型、目标描述、坐标信息、输入内容、等待条件和超时上限。一个典型的指令片段是这样的：

{ "task_id": "TASK-20240115-001", "action": "click", "target": { "type": "text", "value": "查询", "confidence": 0.85 }, "fallback": { "type": "position", "value": [960, 420] }, "wait_for": "element_appear", "wait_timeout": 30000, "log_level": "all" }

这段指令的意思是：在屏幕上找到文字为“查询”的元素，置信度不低于 0.85，点击它；如果通过文本没找到，则直接点击坐标为 (960, 420) 的位置；等待出现新元素，最长等 30 秒；全程记录日志。这种设计的好处是，LCU 不需要理解语义，只需要按照描述执行即可，而具体“去哪个界面找什么按钮”的决策由上层智能体负责。

设计协议时有几个原则很重要。第一，每个动作都必须有 fallback 策略，不能只给一种定位方式。第二，所有动作都必须有超时，绝对不能无限等待。第三，每个动作都要显式声明是否允许执行，包括敏感动作和非敏感动作。第四，指令中要携带签名或校验信息，防止消息通道上的伪造指令直接控制电脑。

3.3 权限隔离和操作边界

LCU 接入最大的风险不是技术，而是权限失控。一旦 LCU 能操作电脑，就等于给了上层智能体一双“真实的手”，它不只是点目标系统的按钮，它还能打开浏览器、访问文件、执行系统命令。所以权限隔离必须放在接入流程的第一优先级。

我采取的办法是三层权限控制。

第一层是账号权限。LCU 运行在一个专用系统账号下，这个账号只允许访问目标系统和必要的下载目录，不能访问其他敏感盘符和系统目录。第二层是操作白名单。在 LCU 配置里定义允许的动作集合，比如只允许鼠标左键单击、键盘输入、滚动，不允许右键、不允许 Ctrl+Alt+Delete、不允许打开命令行终端。超出白名单的动作直接拒绝并向上层告警。第三层是目录白名单。LCU 只能读写指定目录，比如下载目录、临时数据目录，其他路径的写操作一律拦截。

三层权限之外，我还加了一个“执行前快照”机制。每次任务开始前，LCU 自动记录桌面初始状态、剪切板内容、当前前台窗口、关键文件目录的哈希值。任务结束后对比这些快照，发现异常变化就能立即定位是哪一步操作导致的。这个机制帮我们抓到了很多次因为误操作导致的配置文件被改动问题。

3.4 一个最小可用的配置样例

下面给出我实际用过一个最小配置，适合单台电脑接入 LCU 测试。你可以直接把这段 JSON 存成配置，再根据实际情况调整。

{ "lcu": { "device_id": "LCU-TEST-001", "account": "lcu_service", "screen": { "resolution": "1920x1080", "scale_factor": 100, "sleep_never": true }, "channel": { "type": "mqtt", "endpoint": "ssl://example-mqtt.local:8883", "topic_prefix": "lcu/command" }, "allowed_actions": ["click", "type", "scroll", "wait", "screenshot"], "denied_actions": ["hotkey", "open_shell", "right_click"], "allowed_directories": ["C:/work/downloads", "D:/lcu_temp"], "snapshot_enabled": true, "log_retention_days": 90 } }

需要注意，这里的 MQTT 地址是示例，真实环境里要用自己的消息服务，而且必须走加密通道，不能裸连。topic_prefix 建议按设备维度拆分，每一台 LCU 单独订阅一个指令主题，避免误下发到其他设备。allowed_actions 列表要尽量精简，只保留任务确实需要的动作类型，多一个动作就多一重风险。

配置文件下发之后，第一步不是跑业务任务，而是先跑“自检程序”。我先让 LCU 执行三个简单动作：截一张当前屏幕、找到桌面上的“此电脑”图标、双击打开再关闭。自检全部通过，才说明 LCU 的基础通道是通的。很多团队跳过这一步直接跑业务任务，结果基础环境没就绪，业务任务失败了一下午才查到是设备标识配置错了，很浪费时间。

3.5 灰度发布：先接一台，再复制到批量设备

LCU 接入不能一口气全量铺开，哪怕你在工作台界面验证了一百遍也不行。生产环境的不确定性太大了：不同电脑的显卡驱动不同、杀毒软件不同、办公软件版本不同，都会影响 Computer Use 的执行稳定性。

我建议分四步走。

第一步，单台灰度。挑一台配置最接近验证环境的电脑，接上 LCU，用小批量的只读类任务跑两天。所谓只读任务就是不产生关键业务变更的任务，比如查询、导出、截图、整理数据。第二步，功能灰度。在单台验证稳定后，增加表单填写类任务，但只跑真实业务里的“测试单据”，并且每次执行前都备份数据。第三步，小范围灰度。扩大到三五台电脑，覆盖不同硬件和软件环境，跑混合任务。第四步，全量发布。只有前三步的数据都达标了，才允许全量接入。

灰度期间每个任务都要设置人工审批节点。审批不是走形式，而是让人能随时中止一条正在执行的操作链。我在灰度阶段设计了一个“一键熔断”机制，只要人在监控后台按一下停用，LCU 就会在完成当前动作后立即暂停，不再执行后续指令，并且自动回滚到任务开始前的快照。

4. 接入过程中我实际踩过的坑

4.1 界面验证一切正常，LCU 端就是不执行

这是最经典的问题：同一个任务集，工作台里跑得好好的，接到 LCU 后第一步就卡住。我排查下来，八成以上的原因是环境差异。

有一次模拟项目里，LCU 控制的电脑开启了 150% 的缩放显示，界面验证工作台则是 100% 缩放，结果模型看到截图里按钮文字很大，但 LCU 按坐标换算后点击的位置偏到了按钮外面。解决方式很简单，把 LCU 所在设备的显示缩放固定为 100%，分辨率也固定成和验证环境一致。还有一个案例是系统字体不同，原工作台用的是默认雅黑字体，LCU 电脑上安装了别的字体，按钮文字的形状发生了变化，导致视觉识别置信度降低。这种问题不是算法的问题，是环境一致性的问题，需要靠设备基线管理来规避。

另外，还要检查 LCU 的消息通道是否真的收到了指令。我通常会开一个调试模式，让 LCU 每收到一条 JSON 指令都在本地写一条原始消息日志，然后对比上层发送记录。很多次排查到最后发现是消息服务里的订阅关系配置错了，LCU 根本没收到指令，自然也就没有任何操作记录，跟 Computer Use 模型一点关系都没有。

4.2 目标窗口偏移导致点击错位

LCU 接入后，目标窗口不可能每次都出现在同一位置，最大化时没问题，但非最大化时窗口位置就可能偏移。模型基于整个桌面截图找目标按钮，找到之后需要计算出准确的点击坐标。问题在于，如果按钮在窗口内，而窗口本身被拖动过，模型上一次记录的坐标就失效了。

我当时的解决方案是：每次执行点击前，强制 LCU 先把目标窗口激活并置顶，然后再重新截图一次，在最新截图里重新定位按钮坐标。换句话说，不允许模型使用上一次运行的旧截图缓存。有些实现为了减少截图次数，会缓存屏幕状态，但一旦窗口移动，缓存就变成了毒药。宁可增加一点截图开销，也要保证每一步都基于最新画面做决策。

如果目标窗口内部有滚动区域，还需要注意“先滚动到可见区域，再点击”的流程。模型很容易只看到一个按钮的影子就点击，结果点击被滚动画布挡住。我测试过几次之后，把滚动等待时间统一设置为两步：先滚动，再等待 500 毫秒，再截图确认元素完全可见，然后才执行点击。

4.3 登录态和会话缓存把任务带偏

Computer Use 操作的是真实业务系统，那么业务系统本身的登录状态就会直接影响执行结果。最典型的问题就是：验证环境里模型登录过一次，后续测试都不用重新登录；但 LCU 设备如果在任务开始前已退出登录，模型截图后找不到预想的功能菜单，就开始瞎猜，结果点进了一些奇怪页面。

我遇到的更隐蔽问题是浏览器多标签页缓存。LCU 控制的电脑上，目标系统可能在多个标签页里打开过不同账号的会话，模型切换标签页时取到的却是另一个账号的数据，导致导出的报表内容完全错误。这个问题的隐蔽性在于日志看起来一切正常，每一步都点击到位了，就是数据不对。

解决办法是在任务开始时强制规定浏览器状态：关闭多余标签页，只保留目标系统一个标签页，并且清空无关的会话缓存。如果业务系统支持，最好让 LCU 在每次任务开始前明确重新登录。有些人担心登录动作会中断自动化流程，其实恰恰相反，明确、干净的初始状态才能保证后续流程可控。登录态不确定的状态才是最大的不确定性来源，一定要在任务编排里显式处理。

4.4 审核与回滚机制怎么设计才不废

回滚机制听起来简单，就是让系统恢复到操作前状态。但实际做的时候会发现，很多操作是不可逆的。比如一封邮件已经发送到外部，一个流程单据已经提交给了下游，凭本地快照根本回不滚。所以回滚机制必须在任务设计阶段就考虑，而不是运行阶段。

我的原则是：对任何任务，先判断“是否可逆”。可逆的任务，比如修改本地文件、填写草稿，可以允许自动执行并在出错后恢复。不可逆的任务，比如发送、提交、删除，必须强制经过人工审批，并且执行前自动保存一份操作内容摘要，发给审批人去确认。没有经过审批的不可逆动作，LCU 禁止执行。

这需要 LCU 具备动作级别的敏感度分类。我在协议里给每个 action 加了一个字段 impact_level，取值为 low、medium、high。low 是只读操作，medium 是有副作用但可恢复的操作，high 是不可逆操作。LCU 收到 high 级别指令时，如果本地没有关联的人工审批 token，直接拒绝执行并上报。当时为了测试这个机制，我故意下发了 20 条 high 级别指令，LCU 全部拦截，没有一条漏掉。

4.5 问题排查速查表

我把接入期的高频问题整理成一个表格，方便团队一遇到问题先按表排查。

这个表格不复杂，但能节省很多时间。团队里的同学经常遇到问题先怀疑模型能力，其实大量问题出在环境、网络和配置上。表格放在运维手册第一页，谁排查问题都先对一遍。

5. 长期维护与一些经验

5.1 操作日志比正确率更重要

接入稳定后，团队容易把注意力放在任务完成率上，觉得只要任务成功率高就行。但长期维护下来我发现，操作日志的价值远高于正确率统计。正确率只是一个结果数字，而日志能还原出每一次点击、每一步截图、每一个异常分支，是改进优化的唯一依据。

我要求 LCU 除了记录动作本身，还必须同步记录五类内容：触发指令的原文、执行前的截图、执行后的截图、动作结果状态码、当时的系统基本状态（前台窗口、鼠标位置、网络连通性）。截图不一定要全量保存，可以做成前后对比的差异截图，只保留有变化的部分，大幅降低存储成本。日志保留周期我设为 90 天，既能覆盖问题回溯窗口，又不会让磁盘爆炸。

有了这些日志，后期很多问题都可以直接通过日志回放定位，不需要去业务电脑上复现现场。效率非常高。有一次任务偶发失败，我们回放日志发现失败前几秒有一条系统弹窗从右下角出现，恰好挡住了目标按钮，模型点击到了弹窗上然后弹窗关闭，目标系统没有任何响应。如果没有日志，这个偶发性问题可能要花团队好几天去猜。

5.2 定期重放验证集

界面验证阶段准备的那套基准任务集，不要用完就扔。我建议把它变成长期回归测试集，每周在 LCU 上自动跑一遍。周更或月更的界面改版、操作系统补丁、软件更新都可能影响 Computer Use 的稳定性。只有定期重放，才能在问题影响真实业务之前暴露出来。

重放验证集的时候要注意：不要只看最终能否成功，还要对比操作路径是否有漂移。模型为了实现同一个目标，可能本周的点击路径和上周不同。短期看没问题，但操作路径漂移说明界面的视觉语义发生了变化，后续出错概率会迅速上升。这时候就该去检查是不是目标系统改了界面文案，或者某个控件的位置布局发生了变化。

5.3 给团队的几点建议

最后分享几点我个人的体会，不算什么方法论，就是碰壁碰出来的。

第一，Computer Use 项目一定要让懂业务的人和懂技术的人一起参与验收，光靠技术人员看日志判断不了“任务是否真正有效完成”，业务人员才能看出结果是否符合规范。第二，不要追求每一步都由模型自主决策，能封闭的环节尽量封闭，比如日期选择器、下拉菜单，可以先用结构化参数传入 LCU，减少自由发挥空间。第三，接入阶段宁可多设置几个人工审批点，也不要为了“完全自动化”强行取消。自动化程度可以随着日志数据的积累逐步提高，但信任是攒出来的，不是设计出来的。

这些经验都是我踩过坑之后慢慢总结出来的。你要是正在从界面验证往 LCU 接入走，别急着把流程铺满，先跑通一条最小业务线，把日志、回滚、审批机制都验证扎实，再逐步扩大范围。Computer Use 这条链路跑顺之后，确实能省下大量重复劳动，但前提是每一步操作都可控、可追踪、可解释。