企业官网建设流程全解析

周末想试试让一个 AI Agent 帮我整理电脑上的资料。任务很简单：新建一个文件夹，把下载目录里符合规则的图片移进去，再去浏览器里找一份公开的行业报告，保存成 PDF。结果第一轮就卡住了——Agent 似乎一直在“看”文件列表，但操作目录时反复点错位置，尝试三次后干脆放弃了。

后来我把这个例子塞进一个更大的任务集里跑了一遍，发现类似情况不是个例。这让我重新理解那个英文标题：Can Agents Use a Computer Yet? We've Got the Data——智能体到底能不能用电脑？我们拿到了数据。它的潜台词其实是：这个问题终于不再靠嘴说了，而是可以拿数据量出来看。

先说我的判断：现阶段让 Agent 去“操作电脑”，它能完成的是高度受控环境里的单点动作，而不是真实桌面环境里稳定的完整工作流。至于差距有多大、瓶颈卡在哪、怎么量化地测出来，才是这份数据真正想回答的问题。

1. 从“会说话”到“会动手”：Computer Use 为什么值得单独拿出来评测

过去两年我们聊 Agent，聊的重点大多是“它能不能写出更好的文案”“能不能理解一段复杂指令”“能不能帮我生成代码”。这些能力有一个共同特点：输出边界基本停在文字和代码文件层面。但 Computer Use 类型的 Agent 出现后，事情变了——它要接管的是鼠标、键盘、窗口、菜单、文件夹，是在一个真实运行的操作系统里完成一连串动作。

这不是同一个难度级别。

1.1 “生成”和“执行”之间有一道鸿沟

让模型生成一段“如何新建文件夹并移动文件”的操作说明，今天绝大多数模型都能做到。但让模型真正坐在电脑前，自己打开文件管理器，右键新建文件夹，然后拖拽或剪切粘贴文件，就是另一回事。前者只要求“知道”，后者要求“做到”。

这中间隔着至少三个层面：

• 感知层：它得把屏幕像素转化为界面结构，识别按钮、菜单、输入框、弹窗，而不是只“看到”颜色和形状。
• 规划层：它得把一个自然语言目标拆解成若干步，同时预判每一步之后界面会怎么变化。
• 执行与校验层：它得在物理坐标上点对位置、输入正确内容，并在操作后确认结果是否符合预期。

这也是为什么“会生成代码”不等于“会用电脑”。代码生成失败最多返回一段报错，但一个错误的鼠标点击可能打开错误应用、触发误操作，甚至改了系统配置。代价完全不是一个量级。

1.2 演示不能替代评测：真实环境里的“操作”充满脏数据

Computer Use 类产品火起来之后，演示视频一度非常好看。Agent 流畅地打开日历、创建日程、给联系人发邮件，整个过程像真人操作一样。但这些演示大多是精心挑选的场景：界面干净、路径明确、没有弹窗干扰、网络稳定、每一步的预期结果都提前定义好了。

真实使用不是这样。

以我自己的测试为例，单是“打开文件夹”这个动作就可能遇到十几种变体：默认视图不是列表而是图标、窗口大小被改过、文件管理器里混着大量无关文件、目标目录名和常见路径不一致。这些问题对真人来说只是“多看一眼”，但对 Agent 而言，每一步都是感知和判断的误差来源。

所以我才觉得，Computer Use 这个方向真正需要的不是更多的 Demo，而是一套结构化的评测数据。把任务拆细，把失败归因，把成功率、稳定性、恢复能力量出来，才能回答“到底能不能用”这个问题。这正是标题里那份数据最有价值的地方。

2. Agent 用电脑到底卡在哪：先把六层能力拆开看

要评测一个 Agent 会不会用电脑，首先得知道“用电脑”包含哪些能力。很多人觉得这就是“点鼠标+敲键盘”，但拆开看会发现，每一步背后都是一整套感知和决策链条。

2.1 感知：看见屏幕不等于看懂界面

第一层能力是读屏。

最常见的技术方案是给模型截屏图像，让它从图像里理解当前的界面状态。听起来简单，但实际做起来很容易出问题：

• 图标和文字混排时，模型可能把文字描述和坐标对应错。
• 弹窗、Tooltip、通知中心的状态变化会干扰判断。
• 高分屏、缩放比例、暗色模式会让界面元素的位置和样式完全不同。
• “窗口是否处于前台”这种最基本的状态，很多模型都难以稳定判断。

在实际评测里，这层能力最容易被低估。因为截图看起来“信息都在”，但模型是否能准确地把“我看到一个‘确定’按钮”变成“它在这些像素坐标之间”，完全是两码事。

2.2 规划：多步任务最怕中间状态变化

第二层是规划。

“帮我把下载目录里 5 张图片移到新文件夹”听起来是三步：打开下载目录、新建文件夹、移动文件。但真实执行时，每一步都可能改变界面状态，而规划层必须基于“改变后的状态”生成下一步。

这里最容易出问题的地方是，模型规划时往往按“理想状态”假设中间结果，而不是按“实际界面反馈”调整动作。比如它计划“打开文件管理器”，但文件管理器可能启动到了最近文件页而不是固定目录；它计划右键一个文件，但右键菜单的选项顺序和它理解的略有不同，后续动作就全偏了。

我发现实践经验里，规划层的关键不是“一开始想得多周全”，而是“每一步之后能不能根据实际反馈修正”。这和人类用户的操作习惯很相似：我们不是每一步都靠预演，而是边看边调整。

2.3 行动：点击输入看似简单，位置偏差就是零分

第三层是执行。

很多评测框架把执行简化为“输出坐标”或“输出动作”，但真实环境里的执行有大量隐藏变量。例如：

• “点击右上角关闭按钮”，“右上角”在界面上可能是多个按钮叠加的区域。
• “输入一段文字”，输入框可能没有自动聚焦，需要先点击再输入；也可能输入框有格式校验，直接粘贴会失败。
• 系统窗口的 z-order 变化、动画过渡、按钮的 hover 与 pressed 状态差异，都会导致点击动作和目标预期不一致。

这层动作执行即使成功率做到 90%，只要一个长任务里有 20 个动作，整体成功率也会迅速衰减。这也是 Computer Use 评测里“任务级成功率”往往远低于“动作级成功率”的核心原因。

2.4 验证与恢复：真正的分水岭

第四层和第五层是验证与恢复。它决定了 Agent 是“完成任务”还是“执行完动作”。

一个很典型的失败模式是：Agent 认为弹窗已经关闭，但弹窗其实还挂在窗口中间；它认为文件已经移动成功，但目标文件夹里根本没有那个文件。行动和结果之间缺少验证环节，导致任务“执行完成”但“实际未完成”。

比验证更进阶的是失败恢复。当 Agent 发现自己点错了、弹窗不符合预期、文件不存在时，它能不能停下来重新读取界面，而不是继续沿着错误方向执行下去，是区分“能演示”和“能干活”的重要指标。我在实际测试中观察到的常见情况是：小部分 Agent 能在报错后调整策略，大部分会反复尝试同一个动作，直到达到最大步数。

3. 拿数据说话：如何搭建一份 Agent 的“会用电脑”评测方案

聊完能力分层，真正的问题来了：怎么量化地测出来？

很多人以为评测就是准备一堆任务让 Agent 跑一遍，再看看成功几个。理论上没错，但实操时有很多容易忽略的设计细节。

3.1 先定义任务类型，再谈评测

第一个要做的，是把任务按类型分开。不同任务对 Agent 的能力要求完全不同，混在一起评测会让结果没法归因。

我建议至少分成这几类：

设计任务集时，不要只挑“看起来很炫”的任务。更合理的方式是：20% 简单任务用于测基础动作能力，50% 中等任务用于测规划稳定性，30% 复杂任务用于测长链路执行和恢复能力。

3.2 核心指标别只盯着成功率

单一的成功率远远不够。同样一个任务，跑 3 步就成功和跑 40 步勉强成功，含金量完全不同。

我常用的一组指标包括：

• 任务级成功率：整个任务是否完整达成预期结果。
• 动作级成功率：单个点击、输入操作是否正确。
• 最小步数达成率：是否能在接近人类操作的步数内完成，而不是靠大量试错堆出结果。
• 无人工干预率：整个流程是否不需要人为修正。
• 恢复成功率：第一次失败后，Agent 能否自主调整并完成。
• 稳定性：同一任务跑 10 次，成功次数的波动幅度。

这组指标不需要全部用在每一次评测里，但建议至少保留任务级成功率、无人工干预率和恢复成功率这三个，比较能反映真实使用体验。

另外，评测时必须记录过程数据。比如每次操作的坐标、实际截图、模型的中间输出、每一步的耗时。没有这些过程数据，任务失败后你很难判断是感知错、规划错还是执行错。

3.3 最小可运行的评测流程

如果只是想快速验证一个 Computer Use Agent 的能力，不用一开始就搭一套完整平台。可以用一个简单的流程跑起来：

# 示例结构：运行评测任务，记录日志和截图 python run_eval.py \ --task "将下载目录中的 test.png 移动到桌面/eval_output" \ --output-dir ./logs/run_001 \ --max-steps 30 \ --record-screen true

这个脚本的核心职责不是执行 Agent 动作，而是：

1. 启动 Agent 并传入任务描述。
2. 记录每一步的输入输出、耗时、截图。
3. 检查最终结果是否符合预期。
4. 如果失败，把失败环节标记到对应的能力层。

跑完一个任务后，不要急着下结论。至少重复 5 到 10 次，因为 Agent 的失败可能是随机性的，可能是某个弹窗出现的时间不同导致的。

注意：第一次评测的目标不是拿高分，而是拿到一份能定位问题的日志。成功与否反而不重要，重要的是你知道它卡在哪一步。

4. 数据背后：高频失败模式说明 Agent 还缺什么

搭建评测框架的目的，是为了把模糊的“能不能用”变成清晰的“哪一步不行”。从我自己观察到的典型失败模式来看，Computer Use 类 Agent 的缺陷主要集中在三个地方。

4.1 界面感知错位：它在“看”，却不一定“看清”

最常见的失败是感知层面的错位。截图传到模型之后，模型确实看到了图像，但它的“视觉锚定”不一定准确。比如屏幕上有一个对话框，模型识别出“取消”和“确定”两个按钮，但它返回的坐标可能偏移了二三十像素。在小按钮密集的界面上，这种偏移足以点错。

另一个感知问题是“过度关注中间区域”。模型倾向于识别屏幕中央的大元素，但工具栏、状态栏、右键菜单这些密集交互区集中在边缘，错误率显著更高。

这类问题靠调提示词很难解决，它本质上和模型的视觉定位能力、训练数据里的界面样本覆盖度有关。在评测任务设计里，应该专门设计一组“小控件操作”任务，把这类问题暴露出来。

4.2 上下文丢失：历史信息没有真正进入决策

第二种失败模式是上下文丢失。长任务执行到中后段，Agent 经常忘记最初的指令细节，或者把之前步骤的信息记错。

举个例子：任务要求“把文件名中的‘draft’改为‘final’，然后移动到 final_reports 文件夹”。Agent 前半段做对了，但中途遇到一个弹窗干扰，处理完弹窗后，它移动的是一个改名前的文件。这说明上下文信息没有形成稳定的状态记录，只是松散地停留在模型对话历史里。

在实际工程里，这类问题通常需要靠“外部状态记忆”来弥补——通过脚本或工具维护一个任务执行清单，而不是完全依赖模型内部记忆。评测数据如果显示大量失败发生在任务后半段，大概率就是上下文维护出了问题。

4.3 只执行不验证：做了不等于做成

第三种失败模式在评测数据里非常典型：Agent 的动作日志显示它执行了大量操作，但终端状态检查发现预期结果根本没有达成。

比如它以为“右键文件后选择移动”已经完成，实际上右键菜单虽然弹出，但因为菜单项识别错误，选中的是“复制”；它以为“浏览器下载完成”，实际上下载按钮只是进入了下载中状态，文件还没保存完成。

这类失败的根因是缺少“验证节点”。Agent 没有在关键步骤后去检查界面状态，也没有核对文件是否真实存在。评测框架里如果能在每个关键动作后加入一个“状态断言”，就能很清楚地暴露这种“动作完成但任务未完成”的问题。

5. 自己动手测：从单条任务到可复用的回归集

前面讲的都是评测设计的思路，这一节给出可以直接参考的操作路径。不需要昂贵的设备，一台普通的电脑、一个开源或商业的 Computer Use Agent、一组自己定义的任务集，就能跑起来。

5.1 准备环境：建议用虚拟机或独立用户

第一件事是隔离环境。

不要让 Agent 直接操作你的主力电脑。原因很实际：Agent 在测试中可能产生误操作，比如移动文件到错误位置、修改系统设置、删除无法恢复的数据。用虚拟机，或者至少创建一个独立的测试用户，能把这些风险控制在最小范围。

我自己的习惯是：

• 使用虚拟机快照功能，在每次评测前恢复到初始状态。
• 准备一组固定的测试文件，放在固定路径。
• 关闭可能弹出干扰通知的应用，比如聊天软件、自动更新提示。
• 记录系统分辨率和缩放比例，保证每次评测的界面环境一致。

5.2 任务清单怎么设计

任务清单不需要一开始就做得很复杂。可以从 5 个任务起步，覆盖不同能力维度。

一个最小可用的任务集可以这样定义：

• 任务一（感知）：打开系统设置，把文本缩放从 100% 改成 125%。测的是界面定位和系统控件操作。
• 任务二（规划）：在桌面新建一个名为 eval_a 的文件夹，把“下载目录/测试材料”里的两个文件移动到里面。测的是多步规划和文件操作。
• 任务三（上下文）：打开一个文本文件，把其中两行文字替换后另存为新文件。测的是长上下文的保持。
• 任务四（验证）：在浏览器搜索一个指定的公开关键词，把第一条结果的标题复制到文本文件里。测的是跨应用协作和结果验证。
• 任务五（恢复）：删除一个任务需要的目标文件，看 Agent 能否发现缺失并改变策略。测的是异常恢复能力。

每个任务执行 5 次，记录成功率和失败原因。

5.3 记录和归因失败：不要只写“失败”

评测最重要的是失败归因。当任务失败时，不要只记录“失败”两个字，建议按下面的顺序排查：

1. 看最终状态：目标文件在哪里？目标状态是否达成？
2. 看动作日志：最后几步操作是什么？哪一步开始偏离预期？
3. 看截图：在那一步里，Agent 看到的界面和它理解的界面是否一致？
4. 看模型中间输出：它的思考过程中，对界面元素的描述是否准确？

按优先级，我一般把失败归因分为四类：

• 感知类失败：截图里信息充足，但模型识别或定位错误。
• 规划类失败：每一步动作本身正确，但整体步骤顺序不合理。
• 执行类失败：模型判断正确，但输入输出动作未正确执行，比如坐标偏移。
• 环境类失败：外部环境变化导致任务不可能完成，比如网络断开、文件不存在、弹窗覆盖。

区分这四类，才能决定下一步是换模型、改提示词、加状态断言，还是调整环境设计。

5.4 从单任务到批量：先建立一个小型回归集

当你的任务集从 5 个扩展到 20 个左右时，就有必要把它变成回归集了。所谓回归集，就是一组固定不变的评测任务，每次模型升级、提示词改动或工具版本更新后，都完整跑一遍。

回归集的价值在于可比性。如果你每次都换任务，你就无法判断这次的结果变好是因为你的改动生效了，还是因为任务变简单了。保持任务固定，才能看到能力曲线的真实走向。

运行回归集时，可以用一个简单的管理脚本：

# 示例结构：按顺序运行回归集，并汇总结果 for task in tasks/*.json; do python run_eval.py --config "$task" done python summarize_results.py --log-dir ./logs

脚本本身不复杂，关键是跑完之后要形成一张表格，把每个任务每次的成功率、耗时、失败类型汇总起来。数据积累几轮之后，你就能看到哪些能力在进步、哪些能力始终是短板。

注意：回归集的维护成本比搭建成本更高。每次环境变化、任务调整都可能影响结果对比，所以任务描述和判定标准要尽量写清楚，最好固化在配置里。

6. 工程化落地前，必须想清楚的边界问题

评测数据再好，最终还是要回答一个问题：现在能不能用它干活？

我的判断是：在受控范围内可以，在完全开放的真实工作流里很难。而且就算能用，也不是拿来直接跑，必须先补上工程化拼图。

6.1 当前适合什么场景、不适合什么场景

从常见实践来看，以下场景可以尝试：

• 固定流程的桌面自动化，比如每日定时把某个目录的文件归档。
• 结构化程度高的网页操作，比如在管理后台录入信息。
• 辅助用户操作，Agent 负责推荐下一步，人类确认后执行。

以下场景短期内还不太适合：

• 涉及敏感数据的操作，比如网银、账单、内部系统。
• 需要高度判断力的任务，比如邮件内容里的意图揣摩和回复策略。
• 长链路高风险的流程，比如生产环境部署、核心数据迁移。

核心原因不是 Agent “聪明与否”，而是它目前缺少对后果的认知能力。它能完成“动作”，但不能完整评估“动作带来的后果”。“把文件移动到另一个目录”和“把文件移动到错误目录后再覆盖同名文件”，在动作日志里只是坐标差异，但在真实后果上可能有天壤之别。

6.2 权限、日志和人工介入是底线

如果决定在部分场景里落地，有几件事必须先做。

第一，权限隔离。给 Agent 一个独立的操作账号，限制它只能访问指定目录、指定应用和指定网站，不允许它修改系统级配置。

第二，全量日志。每次操作都要记录动作、截图、输入输出和耗时。这不仅是排查问题的依据，也是审计和追溯的底线。

第三，人工审批节点。在关键步骤前设置暂停点，让真人确认后再继续。比如“即将执行删除动作”“即将发送邮件”“即将修改系统配置”。没有这些控制点，任何评测里“看起来不错”的成功率都不能代表真实风险。

6.3 别忽视数据语义层：Agent 与数据系统之间还差一层“翻译”

热搜词里有一个“data agent 的语义层构建”，我觉得这个方向在 Computer Use 落地时尤其重要。

这里的“语义层”可以理解为一个中间层，把底层数据结构翻译成 Agent 能理解、能操作的对象。举个例子：如果 Agent 要操作数据库，直接让它面对 SQL 表和字段名会很脆弱，因为物理表结构变了，它可能就懵了。但如果有一个语义层告诉它“这是客户列表”“这是订单金额”“这是删除操作对应的业务含义”，Agent 就能以更稳定的方式完成任务。

同样，在桌面操作场景里，这种语义层可以表现为“界面语义描述”——不是把整个屏幕图像丢给模型，而是提取出按钮、输入框、菜单项和它们的层级关系，再让模型基于结构化语义做决策。这会比纯截图更稳定，也更容易定位问题。

这也是我觉得 Computer Use 类 Agent 未来的一个关键走向：不是越来越像人一样“看像素”，而是背后有一套环境感知系统，把原始界面翻译成 Agent 更容易理解和操作的结构化信息。

6.4 从“单次跑通”到“长期稳定”，还差三块拼图

即使评测结果不错，从实验到常态使用也还差几步具体工作：

• 任务配置化：每个自动化任务都要有明确输入、操作步骤和结束条件，而不是每次给 Agent 一段自然语言描述让它自由发挥。
• 失败重试策略：定义什么情况该重试、重试几次、什么情况该停机等人工处理。
• 阈值告警：任务耗时超过预期、关键步骤失败率上升、输出异常时，需要能自动通知到责任人。

没有这三块拼图，评测里再好看的 Agent，放到生产环境都会变成一台不可控的“自动化机器”。它能做事，但你不能确定它做对的事占比多少。

7. 当我们在看“可用性数据”时，真正看的是什么

回到标题里的那份数据：Can Agents Use a Computer Yet? We've Got the Data。

我不认为这份数据的意义在于给出一个“能”或“不能”的二元结论。它更像是一张地图，标明当前 Agent 在电脑使用这件事上，已经走到哪、卡在哪、哪个短板最影响体验。

从更长期的角度看，“用电脑”本身是人类数字化能力的重要入口。如果一个 Agent 真的能在真实电脑环境中稳定操作，那它就能间接使用整个数字世界的工具链——文件、浏览器、办公软件、开发环境、业务系统。这也是为什么大家在评测数据里关注每一个点、每一个失败案例，而不是满足于几个成功 Demo。

如果你也想验证一下当前某个 Agent 的成色，我建议从最不起眼的小任务开始：新建文件夹、移动一个文件、在浏览器里搜索一个词并把结果存下来。单次跑通只是起点，多跑几遍，看看它的稳定性；故意制造一点干扰，看看它的恢复能力。这些数据比任何宣传话术都更能说明问题。

至少从目前的普遍情况看，Agent 离“像人一样用电脑”还有明显距离。但只要评测数据能持续暴露具体短板，这个距离就是可以被量化和缩短的。回到我自己的测试：第一次卡住的 Agent，在换了一套带环境感知和状态校验的方案之后，同样任务的完成度已经明显提升。数据不一定总是告诉你“已经准备好了”，但它至少会告诉你——离准备好还差多远。