企业官网建设流程全解析

最近在排查 Agent 自动化点击、填表、跨应用操作这类需求时，经常遇到同一个问题：模型在对话里说“我可以帮你操作电脑”，但真正让它点击一个按钮、拖拽一个文件、读一段屏幕内容，效果却很不稳定。这篇文章想围绕一个核心问题展开：当我们在讨论 AI Agents 的 Computer Use 能力时，我们到底在讨论什么？以及支撑判断的“数据”从何而来、如何构建、如何评估。

文章会先讲清楚 Computer Use 涉及的关键技术链路，再重点拆解数据在 Agent 能力评估中的作用，最后给出一个可运行的最小评估脚本，并附上高频踩坑记录。无论是刚开始接触 Agent 开发的初学者，还是在设计 Agent 评估体系的后端工程师，都可以从中找到可落地的思路。

1. AI Agents 的 Computer Use 究竟是什么

1.1 从“对话助手”到“操作电脑的 Agent”

传统意义上的聊天机器人，做的事情可以概括为：接收文本输入，生成文本输出。它的能力边界在语言空间内。但 Computer Use 类型的 Agent 不同，它的目标是直接操作图形界面完成真实任务。

比如下面这些场景：

• 自动打开浏览器，进入某个后台系统，导出报表。
• 在桌面应用中自动填写表单，点击提交按钮。
• 读取屏幕上的数据区域，判断内容是否正常，然后执行下一步操作。
• 跨应用协同，例如从邮箱中提取附件，保存到本地，再上传到另一个系统。

这些任务的特点是：输入不一定只有文本，输出也不一定只是文本。Agent 需要“看”屏幕（视觉感知），需要“决定”下一步做什么（决策规划），需要“执行”点击、输入、滚动等操作（动作执行），还需要“验证”操作是否生效（结果反馈）。

从工程角度理解，Computer Use Agent 本质上是一个闭环控制系统：

屏幕感知 -> 状态理解 -> 目标规划 -> 动作执行 -> 再次感知 -> 判断是否完成

每一步都可能引入误差，而数据在其中扮演的角色，就是用来衡量这些误差到底有多大、出现在哪个环节。

1.2 Computer Use 的技术链路拆解

为了方便后面讨论数据和评估，这里把 Computer Use 的核心链路拆成四层。

第一层：感知层

Agent 需要感知当前计算机状态。常见方式有两种：

• 截屏图片 + 视觉模型（Vision Language Model），让模型理解屏幕上有什么。
• 可访问性树（Accessibility Tree）+ 结构化数据，从系统层面拿到界面元素列表。

两者的区别在于：屏幕截图更接近人类观察方式，但受分辨率、遮挡、缩放影响；可访问性树信息更结构化和精确，但依赖系统和应用是否暴露了这些接口。实际工程中经常两者结合，先用截图做整体理解，再用可访问性数据定位精确坐标。

第二层：决策层

拿到感知结果后，Agent 需要决定“下一步做什么”。决策层通常构建在 LLM 之上，模型会接收到当前任务描述、历史操作记录、当前界面状态，然后输出下一个动作。动作通常是结构化的，例如：

{ "action": "click", "target": { "element_id": "submit-btn", "coordinates": [860, 540] } }

第三层：执行层

执行层负责把决策转成真实的系统操作。桌面端常见的是通过操作系统辅助功能接口模拟鼠标键盘事件；浏览器端可以通过 DevTools Protocol 注入 JavaScript 执行 DOM 操作；移动端则需要借助 ADB 等桥接工具。

第四层：验证层

验证层常被忽略，但非常重要。Agent 执行动作后，需要再次感知屏幕，判断“按钮是否真的被点击了”“页面是否跳转了”“错误提示是否出现”。如果缺少验证层，Agent 很容易陷入“自我感觉完成任务，实际上根本没成功”的状态。

而这四层能力到底行不行，不能靠感觉，必须靠数据。

2. 为什么说“数据”是评估 Computer Use 的关键

2.1 没有数据，就无法衡量“能用”还是“不能用”

“Can Agents Use a Computer Yet?” 这个问题，如果只靠人工观察几个案例，很容易得出截然不同的结论。有人试了一个任务发现很顺畅，就说 Agent 已经能操作电脑了；有人试了一个复杂任务发现频繁失败，就说 Agent 完全不行。

这两种结论都存在问题，因为它们依赖的样本量太小、任务覆盖面太窄。要客观回答这个问题，需要一套数据驱动的评估体系，用一批经过设计的任务、统一的判定标准、可重复的评估流程，来量化 Agent 的成功率、耗时、错误类型和成本。

我把这套数据体系称为“Computer Use 评估数据集”。它不只是给模型训练用的，更是给 Agent 系统做能力体检用的。

2.2 Computer Use 评估数据的五个维度

构建 Computer Use 评估数据集，需要考虑以下五个维度。

维度一：任务类型覆盖度

不能只测“点击按钮”这种单一动作，要覆盖日常操作中的常见类型。我把任务粗略分成几类：

维度二：界面多样性

同一个任务在不同应用、不同页面布局下的执行难度差异很大。评估数据中要包含不同的界面风格、不同的数据密度、不同的按钮位置。否则 Agent 可能只是“背下了测试页面的布局”，而不是真正学会了操作计算机。

维度三：环境干扰项

真实使用场景中存在大量干扰：弹窗广告、系统通知、加载动画、权限申请弹窗。评估数据里需要加入这些干扰项，观察 Agent 是否能排除干扰、坚持原定任务。

维度四：判定标准

任务完成后如何判定成功？常见判定方式包括：

• 最终界面状态是否符合预期（例如特定元素出现）。
• 操作路径是否合理（是否存在大量无效点击）。
• 是否在限定步骤内完成。
• 是否产生负面影响（例如误删了文件）。

单点成功的判定方式不够全面，建议结合界面状态和操作过程一起评估。

维度五：成本指标

除了把任务做完，还要考虑效率。评估数据应该记录：

• 完成一个任务消耗了多少轮感知-决策-执行循环。
• 消耗了多少 Token。
• 耗时的瓶颈在模型推理、界面响应还是执行层。

这些数据对于优化 Agent 架构非常关键。

3. 环境准备与工具选型

3.1 运行环境

评估一个 Computer Use Agent，并不一定需要完整的线上系统。最小环境可以这样搭建：

• 操作系统：建议使用 Windows 或 macOS，便于模拟桌面操作。如果使用 Linux，可以通过浏览器自动化方案来完成部分评估。
• Python 版本：3.10 或 3.11 都可以，核心依赖是 openai、pyautogui、Pillow。
• 浏览器：Chrome 或 Edge，使用浏览器自动化协议控制。
• 屏幕环境：建议固定分辨率，保证截图的尺寸一致性。

版本需要根据你的项目实际情况调整，本文示例以常见环境为例，重点演示评估思路。

3.2 常见的 Agent 框架与工具

目前实现 Computer Use Agent 的常用工具链包括：

如果你只做评估实验，最轻量的组合是：Python + 多模态模型接口 + PyAutoGUI + Playwright。不需要一开始就上重型 Agent 框架，先跑通闭环，再逐步加复杂逻辑。

4. 评估体系设计：数据怎么构建

4.1 任务集设计

一个可落地的 Computer Use 评估任务集，建议使用 JSON 或 YAML 格式来定义。每个任务至少包含以下字段：

• id：任务唯一标识。
• name：任务名称。
• description：给 Agent 的自然语言指令。
• type：任务类型。
• start_url / start_state：初始状态。
• success_criteria：成功判定条件。
• max_steps：最大操作步数。

下面是一个最简单的任务定义示例：

{ "tasks": [ { "id": "nav-001", "name": "打开指定网址", "description": "打开浏览器，访问 https://example.com，并确认页面标题中包含 Example", "type": "navigation", "start_url": "about:blank", "success_criteria": { "url_contains": "example.com", "title_contains": "Example" }, "max_steps": 5 }, { "id": "form-001", "name": "填写搜索框并提交", "description": "在搜索框中输入 computer use data，然后点击搜索按钮", "type": "form_filling", "start_url": "https://www.bing.com", "success_criteria": { "url_contains": "search?q=computer+use+data" }, "max_steps": 8 } ] }

4.2 成功判定有两种思路

一种是指令式判定。评估脚本通过接口查询浏览器状态，检查 URL、标题、DOM 元素是否存在。这种判定方式稳定、客观、适合自动跑量。

另一种是视觉式判定。给评测模型一张目标界面截图，让模型判断“当前状态是否达到任务目标”。这种方式更接近人的判断，但在复杂界面上稳定性会差一些。

生产级评估系统建议两种思路结合：先用指令式判定做自动化和批量检查，再用视觉式判定处理无法通过 DOM 结构判断的场景。

4.3 评估执行流程

完整的评估流程可以拆成下面几个步骤：

1. 加载任务集。
2. 重置环境到初始状态。
3. 将任务描述发给 Agent。
4. Agent 进入感知-决策-执行循环。
5. 每执行一个动作，检查是否达到成功条件。
6. 如果达到，记录成功，记录步数和耗时。
7. 如果达到最大步数仍未成功，标记失败；如果出现严重异常，标记错误。
8. 汇总所有任务的执行结果，计算成功率、平均步数、平均耗时。

上面的流程中，Reset 是最容易被忽略的步骤。如果上一个任务在浏览器里留下了状态，后一个任务的执行结果就会失真。在设计评估平台时，必须确保每个任务运行前环境是干净的。

5. 实战：写一个最小的 Computer Use 能力评估脚本

接下来用一个极简示例演示如何评估一个 Agent 的 Computer Use 能力。这个示例的重点是让读者理解评估闭环，而不是实现一个生产级平台。

5.1 项目结构

先创建一个项目目录：

computer-use-eval/ ├── tasks/ │ └── demo_tasks.json ├── agent/ │ └── simple_agent.py ├── evaluator.py └── requirements.txt

requirements.txt内容如下：

openai>=1.0.0 pyautogui>=0.9.54 Pillow>=10.0.0 playwright>=1.40.0

5.2 编写任务定义文件

在tasks/demo_tasks.json中加入两个简单任务：

{ "tasks": [ { "id": "nav-001", "name": "打开指定网址并检查标题", "description": "打开浏览器，访问 https://example.com，检查当前页面标题是否包含 Example", "type": "navigation", "start_url": "about:blank", "success_criteria": { "title_contains": "Example" }, "max_steps": 5 }, { "id": "type-001", "name": "在搜索框输入关键词", "description": "打开必应首页，在搜索框中输入 computer use data，然后按下回车键", "type": "form_filling", "start_url": "https://www.bing.com", "success_criteria": { "url_contains": "search?q=computer+use+data" }, "max_steps": 10 } ] }

5.3 编写一个简单 Agent 核心逻辑

这里不调用真实付费模型，而是模拟一个“如果识别到输入框就输入关键词并回车”的简单策略，用来演示评估闭环。真实项目中，这里的逻辑应替换为多模态模型的决策输出。

# agent/simple_agent.py import time class SimpleAgent: """ 一个极简的 Computer Use Agent 示例。 真正的生产系统这里会调用多模态大模型， 将屏幕截图 + 任务描述发送给模型，由模型决策下一步动作。 """ def __init__(self, page, task_description: str): self.page = page self.task_description = task_description def get_screenshot(self, path: str = "screenshot.png"): """截取当前页面，保存为图片，用于后续视觉分析。""" self.page.screenshot(path=path) return path def execute_action(self, action: dict): """ 执行一个动作。 这里仅做演示，支持 goto、fill、press、click 四种基本动作。 """ action_type = action.get("action") if action_type == "goto": self.page.goto(action["url"], wait_until="networkidle") elif action_type == "fill": locator = self.page.locator(action["selector"]) locator.fill(action["value"]) elif action_type == "press": self.page.keyboard.press(action["key"]) elif action_type == "click": locator = self.page.locator(action["selector"]) locator.click() else: raise ValueError(f"Unknown action: {action_type}") time.sleep(1) def run(self, start_url: str): """执行任务起始动作。""" self.page.goto(start_url, wait_until="networkidle")

5.4 编写评估器

evaluator.py是整个评估流程的核心，负责加载任务、调用 Agent、判断成功条件、汇总结果。

# evaluator.py import json from playwright.sync_api import sync_playwright from agent.simple_agent import SimpleAgent def check_success(page, criteria: dict) -> bool: """ 根据 success_criteria 检查任务是否成功。 支持 title_contains、url_contains 两种判定方式。 """ current_title = page.title() current_url = page.url if "title_contains" in criteria: expected = criteria["title_contains"].lower() if expected not in current_title.lower(): return False if "url_contains" in criteria: expected = criteria["url_contains"].lower() if expected not in current_url.lower(): return False return True def run_task(task: dict): """运行单个任务，返回执行结果。""" result = { "task_id": task["id"], "success": False, "steps": 0, "max_steps": task.get("max_steps", 10), "error": None, } with sync_playwright() as p: browser = p.chromium.launch(headless=True) page = browser.new_page(viewport={"width": 1280, "height": 800}) agent = SimpleAgent(page, task["description"]) agent.run(task["start_url"]) # 模拟 Agent 决策循环 # 这里在最简单场景下，通过判断当前页面状态来选择动作 current_step = 0 while current_step < result["max_steps"]: current_step += 1 result["steps"] = current_step # 检查任务是否已经成功 if check_success(page, task["success_criteria"]): result["success"] = True break # 极简策略：判断 URL 特征，直接执行固定动作 # 真实场景应在这里调用多模态模型做决策 if task["id"] == "type-001" and "bing.com" in page.url: agent.execute_action({ "action": "fill", "selector": "#sb_form_q", "value": "computer use data" }) agent.execute_action({ "action": "press", "key": "Enter" }) elif task["id"] == "nav-001": agent.execute_action({ "action": "goto", "url": "https://example.com" }) browser.close() return result def main(): with open("tasks/demo_tasks.json", "r", encoding="utf-8") as f: task_data = json.load(f) results = [] for task in task_data["tasks"]: print(f"正在运行任务: {task['id']}") result = run_task(task) results.append(result) print(f"任务 {task['id']} 结果: {'成功' if result['success'] else '失败'}") # 汇总统计 success_count = sum(1 for r in results if r["success"]) total_steps = sum(r["steps"] for r in results) success_rate = success_count / len(results) * 100 print("\n===== 评估汇总 =====") print(f"任务总数: {len(results)}") print(f"成功数: {success_count}") print(f"成功率: {success_rate:.1f}%") print(f"平均步数: {total_steps / len(results):.1f}") if __name__ == "__main__": main()

5.5 运行与验证

安装依赖：

pip install -r requirements.txt playwright install chromium

运行评估：

python evaluator.py

预期输出类似：

正在运行任务: nav-001 任务 nav-001 结果: 成功 正在运行任务: type-001 任务 type-001 结果: 成功 ===== 评估汇总 ===== 任务总数: 2 成功数: 2 成功率: 100.0% 平均步数: 2.0

5.6 结果说明

上面这个示例中，Agent 的成功率是 100%，因为任务非常简单，而且评估脚本中写死了固定策略。真实场景不会这么顺利，模型可能在执行过程中出现以下情况：

• 定位不到输入框，一直停留在首页。
• 点击了错误的按钮，跳转到了不相关页面。
• 在弹窗出现后停止了动作。

所以要评估一个真实 Agent 的能力，需要：

1. 把任务集的规模和多样性提上来。
2. 把固定动作策略替换成真实的多模态模型。
3. 引入屏幕截图，在每轮循环时把图片传给模型做决策。

替换为多模态模型时，核心代码看起来会是这样：

def get_model_action(screenshot_path: str, task_description: str) -> dict: """ 将截图转换为 Base64，调用多模态模型返回结构化动作。 注意：这里的 client 需要根据你实际使用的模型服务来配置。 """ import base64 from openai import OpenAI client = OpenAI() # 请替换为实际配置 with open(screenshot_path, "rb") as f: image_base64 = base64.b64encode(f.read()).decode("utf-8") response = client.chat.completions.create( model="gpt-4o", messages=[ { "role": "system", "content": "你是一个计算机操作助手。根据截图和任务描述，输出下一个动作。" }, { "role": "user", "content": [ {"type": "text", "text": task_description}, { "type": "image_url", "image_url": {"url": f"data:image/png;base64,{image_base64}"} } ] } ], response_format={"type": "json_object"} ) content = response.choices[0].message.content return json.loads(content)

接入后，run_task中每轮循环的逻辑就变成：

1. 截屏。
2. 调用get_model_action。
3. 解析模型输出的动作。
4. 执行动作。
5. 检查成功条件。

6. 常见问题与排查思路

如果系统经常出现“步骤数很少但任务失败”的情况，优先检查成功判定条件是不是写得太苛刻；如果步骤数很多但任务还是失败，优先排查 Agent 是否一直在做无效操作，决策层是否缺少“放弃”机制。

在排查过程中，日志非常关键。建议给每个动作记录下面这些信息：

{ "step": 3, "action": "click", "target": "submit_button", "screenshot": "20250214_153002_step3.png", "model_response": "{\"action\":\"click\", \"target\":\"submit\"}", "page_url_after": "https://example.com/success", "timestamp": "2025-02-14T15:30:03.000Z" }

有了这类日志，才能回溯失败原因。没有日志的评估系统，基本等于没有。

7. 最佳实践与工程建议

7.1 从“小闭环”开始，再扩展

不要一上来就构建覆盖几十个复杂任务的评估平台。先搭一个 5 到 10 个任务的闭环，验证截图、推理、执行、判定这条链路能跑通，再逐步加入跨应用任务、干扰弹窗和异常恢复场景。小闭环的好处是问题容易定位，因为你很清楚每个环节的代码是怎么写的。

7.2 数据管理要分版本

Computer Use 评估数据本身需要版本管理。任务定义、界面截图、评估结果、模型版本、Agent 代码版本，这些要素要对应起来。否则，当评估结果波动时，你无法判断是模型变差了、还是任务集被改过了、还是环境变了。

建议在评估结果中记录：

• 评估数据集版本。
• 模型名称和版本。
• Agent 框架代码版本。
• 操作系统和浏览器版本。
• 运行时间。

7.3 成功判定要“双重验证”

在真实项目中，只靠 URL 判断成功往往不够。例如表单虽然提交了，但页面弹出“提交失败”的提示，此时 URL 可能已经变化。更稳的方式是同时检查 URL、页面标题、关键 DOM 元素或错误提示元素是否存在。

def check_success_strict(page, criteria: dict) -> bool: if "url_contains" in criteria: if criteria["url_contains"] not in page.url: return False if "title_contains" in criteria: if criteria["title_contains"] not in page.title(): return False if "error_selector" in criteria: error_count = page.locator(criteria["error_selector"]).count() if error_count > 0: return False if "success_selector" in criteria: success_count = page.locator(criteria["success_selector"]).count() if success_count == 0: return False return True

7.4 安全边界必须提前设计

Computer Use Agent 拥有操作系统级的操作权限，这在带来便利的同时也引入了风险。在评估和生产环境中，必须考虑以下安全措施：

• 使用独立虚拟机或容器运行 Agent，避免直接操作生产环境的桌面。
• 配置网页操作白名单，默认禁止访问内网或敏感系统。
• 设置动作频控，避免 Agent 在异常循环中产生大量无效操作。
• 对文件删除、数据提交等高风险动作增加二次确认机制。
• 完整记录所有操作日志，方便审计和回滚。
• 在评估和测试环境中，使用测试账号和测试数据，绝对不能使用线上真实数据。

7.5 定期回归评估

Agent 系统会随着模型升级、依赖更新、界面改版而发生变化。上个月表现良好的 Agent，这个月可能因为某个网站的 DOM 结构调整而失效。

建议设置定期回归评估，例如每周或每两周运行一次完整任务集。当评估结果出现明显波动时，及时回溯模型版本和依赖变更记录。这不仅适用于 Computer Use Agent，也是所有数据驱动评估系统的通用工程规范。

7.6 性能开销要记录

Computer Use Agent 的成本通常比普通聊天应用高很多，因为每轮循环都要传递截图，而截图带来的 Token 消耗远高于文本。评估时要记录每任务平均 Token 消耗、推理耗时、截图次数。这些数据能帮助你判断是否值得在感知环节引入图像压缩、是否应该用可访问性树替代部分截图。

如果发现模型在每一步都传递整张 1280x800 截图，但真正影响决策的区域只占画面的十分之一，就要考虑加入目标区域裁剪功能，这对降本增效帮助很大。

8. 总结与下一步学习方向

回到标题提出的问题：Can Agents Use a Computer Yet? 能给出的可靠回答是：部分可以，但稳定性取决于任务类型、界面复杂度和评估数据的覆盖率。这不是一个可以用“能”或“不能”简单回答的问题，而是一个需要通过数据持续度量、持续优化的工程问题。

本文从 Computer Use Agent 的技术链路出发，梳理了感知、决策、执行、验证四个环节，重点介绍了评估数据的五个构建维度，并给出了一个最小可运行的评估脚本。你可以把这份脚本作为起点，逐步替换成真实的多模态模型、引入更多复杂任务、加入视觉判定逻辑，慢慢搭建属于自己的 Agent 评估体系。

下一步，可以沿着这几个方向继续深入：

• 研究可访问性树（Accessibility Tree）与截图结合的双通道感知方案。
• 尝试在决策循环中加入短期记忆，记录历史操作，减少重复动作。
• 探索更细粒度的成功判定方式，例如对页面 diff 进行视觉比对。
• 学习和使用成熟的 Agent 编排框架，在框架基础上做评估插件的二次开发。

如果这篇内容对你有帮助，可以收藏备用。后续我还会继续更新 Computer Use 相关的实战记录，包括跨应用任务、弹窗干扰处理和评估平台搭建等内容。