企业官网建设流程全解析

这次我们来看一个从年初一直吵到现在的技术问题：LLM Agent 到底能不能像人一样使用电脑？与其继续停留在概念讨论，不如直接看数据。最近一批公开的 Computer Use 评测数据，把 Agent 的点击、输入、滚屏、截图、页面跳转和完成状态都记录了下来，可以比较清楚地看到它在真实任务上能做到什么程度，又会在哪些环节频繁翻车。

这类数据的价值在于，它把“Agent 能操作电脑”从演示视频变成了可量化指标。任务成功率、平均步骤数、Token 成本、失败原因分布，都能直接指导我们判断方案是否可用。本文会先拆解这份评测的数据维度和任务设计，再给出一套在本机快速搭建 Browser Agent 验证环境的方法，最后补充批量任务、接口封装、资源占用和常见问题排查。如果你想跑通一个真实的“Agent 操作浏览器”实验，这篇文章可以直接收藏。

如果你正在做 RPA 替代方案选型、Agent 应用开发，或者只是关心 Computer Use 类型方案的实际门槛，下面这些内容应该能帮你省掉不少检索时间。

1. 核心能力速览

先把这份评测数据涉及的核心能力按表格整理出来，方便快速判断它与你的场景是否匹配。

从这张表能看出，Agent 是否真的“会用电脑”，本质上是一个数据问题：它能不能稳定地分解任务、定位元素、执行动作并从错误中恢复。下面逐步展开。

2. 评测数据在回答什么问题

2.1 任务设计

Computer Use 类型的评测，核心是让 Agent 面对一个真实或高仿真的操作系统环境，完成用户下达的目标。常见任务包括：

• 打开浏览器，根据关键词搜索并返回第一个有效结果的标题。
• 进入某个页面后，按条件筛选列表，读取指定条目的详情。
• 在表单中填写内容、选择下拉项、点击提交。
• 下载文件、读取文件内容、把结果写回另一个文件。
• 操作桌面应用，例如打开编辑器、修改配置、执行脚本并检查输出。

这些任务和普通 RPA 脚本的区别在于：Agent 没有预先写死的元素路径，它只能依靠截图、DOM 信息或辅助能力动态决策。评测记录的数据，就是这一整套动态决策过程的“黑匣子”。

2.2 关键数据维度与读法

看这类评测数据，建议关注五个维度。

第一是任务成功率。任务成功率直接反映 Agent 在多大比例上能完整走完流程。仅看单一成功率不够，还要看它是在简单任务还是长链路任务上达成的。第二是平均步骤数。步骤数越少，通常意味着 Agent 的规划能力越强，Token 消耗和失败概率也会更低。第三是动作准确率，也就是点击、输入、滚屏等动作是否命中了真实目标。动态加载的页面经常会出现“看见了元素，但点击下去却不是那个按钮”的情况，这类错误在数据里通常占比不低。第四是失败原因分布。页面加载超时、选择器失效、登录弹窗、人机验证、多步操作后页面状态刷新，都是常见失败点。第五是资源消耗，包括 Token 数、调用延迟和单任务执行时长。对一个目标是批量任务处理的 Agent 服务来说，这些指标决定了成本上限。

从数据读法来看，当一份评测报告说“Agent 能使用电脑”时，要追问的是：它指的是在固定域名下的受限操作，还是面对互联网任意页面的开放操作？这两者难度差距很大。

2.3 适用场景与使用边界

Computer Use Agent 适合做这些事：一是自动化回归测试，像 UI 测试那样让 Agent 走一遍关键路径；二是 RPA 场景的前期探索，先验证哪些流程可以交给 Agent 自主完成；三是内容采集与整理，在获得授权的前提下，让 Agent 从多个页面提取并汇总信息；四是 Agent 能力研究，用统一数据评估不同模型和提示词策略的差别。

不适合刻意用它去做的事情也很多。高权限账户操作、支付流程、涉及真实用户隐私数据的批量处理，都不建议直接交给 Agent 自主跑。另一个边界是自动化行为本身。Agent 操作浏览器的频率、行为模式可能被人机验证机制识别，正确做法是在合规目标站点上做实验，或者预留人工确认节点，而不是想方设法绕过验证机制。涉及数据采集和爬取场景时，必须遵守目标网站的条款、robots 协议和相关法律法规。评测数据只能反映技术能力上限，不能成为突破合规边界的理由。

3. 本地搭建最小 Browser Agent 验证环境

如果想要亲自验证“Agent 到底能不能用电脑”，不需要等商业平台开放内测权限，可以自己组装一个最小闭环。整体思路是：用 Playwright 控制浏览器，把当前页面截图发给一个多模态 LLM，让模型输出下一步动作，再回到浏览器执行，循环直到任务完成。

这个方案适合开发调试，也适合对比不同模型的 computer use 能力。

3.1 环境准备

建议使用 Python 3.10 以上版本，安装 Playwright、OpenAI 客户端库和一个浏览器内核。

# 创建虚拟环境 python -m venv venv # Windows 下激活 venv\Scripts\activate # Linux/macOS 下激活 source venv/bin/activate # 安装依赖 pip install playwright openai playwright install chromium

如果后续要接 FastAPI 暴露接口，可以再安装 uvicorn 和 fastapi：

pip install fastapi uvicorn

需要准备一个支持视觉输入的模型 API。如果本地有 GPU，也可以用 vLLM 或 Ollama 启动一个视觉语言模型，比如 7B 或 13B 量级的多模态模型。没有 GPU 时，建议直接用云端 API 先做功能验证。

3.2 最小 Agent 执行闭环

下面是一个最小可跑的动作循环示例。代码中的LLM_BASE_URL、LLM_API_KEY、LLM_MODEL都通过环境变量传入，方便切换不同的模型服务。

import asyncio import base64 import json import os from playwright.async_api import async_playwright from openai import AsyncOpenAI client = AsyncOpenAI( base_url=os.getenv("LLM_BASE_URL", "https://api.openai.com/v1"), api_key=os.getenv("LLM_API_KEY"), ) async def screenshot_to_base64(page) -> str: png = await page.screenshot() return base64.b64encode(png).decode("utf-8") async def agent_step(page, task: str) -> str: image_b64 = await screenshot_to_base64(page) messages = [ { "role": "system", "content": ( "你是一个 Browser Agent。根据用户的最终任务和当前截图，" "输出下一步动作。动作必须是严格 JSON，可选类型如下：\n" '{"type": "click", "selector": "CSS选择器"}\n' '{"type": "type", "selector": "CSS选择器", "text": "输入文本"}\n' '{"type": "scroll", "direction": "down|up"}\n' '{"type": "done", "result": "最终回答"}' ), }, { "role": "user", "content": [ {"type": "text", "text": f"最终任务：{task}"}, { "type": "image_url", "image_url": {"url": f"data:image/png;base64,{image_b64}"}, }, ], }, ] resp = await client.chat.completions.create( model=os.getenv("LLM_MODEL", "gpt-4o"), messages=messages, temperature=0, ) return resp.choices[0].message.content async def run_task(url: str, task: str, max_steps: int = 10) -> None: async with async_playwright() as p: browser = await p.chromium.launch(headless=False) page = await browser.new_page() await page.goto(url, wait_until="domcontentloaded") for step in range(max_steps): print(f"Step {step + 1}") action_text = await agent_step(page, task) print("Action:", action_text) action = json.loads(action_text) if action["type"] == "done": print("Agent 完成:", action.get("result", "")) break elif action["type"] == "click": await page.click(action["selector"]) elif action["type"] == "type": await page.fill(action["selector"], action["text"]) elif action["type"] == "scroll": if action["direction"] == "down": await page.mouse.wheel(0, 800) else: await page.mouse.wheel(0, -800) await page.wait_for_timeout(1000) await browser.close() if __name__ == "__main__": asyncio.run( run_task( "https://example.com", "找到页面上关于 Agent 的介绍，并复制第一段标题", max_steps=10, ) )

这个示例的重点是打通“截图 -> 模型决策 -> 执行动作”的闭环，实际使用时长任务需要补充错误捕获、重试和安全限制。模型输出的 JSON 不一定是合法 JSON，建议用容错解析；点击失败时要给模型返回错误信息，让它能自纠正。

4. 功能测试与效果验证

下面用三类典型任务验证 Agent 是否真的具备“使用电脑”的基础能力。每项都给出输入、操作步骤和判断标准。

4.1 页面信息提取

测试目的是验证 Agent 能否理解页面结构并提取指定内容。输入任务为“打开 example.com，提取页面主标题”。运行环境为前面搭好的脚本。

预期结果是 Agent 在几步内定位到标题元素，输出done并返回标题文本。判断成功标准是返回内容与页面实际标题一致。如果 Agent 一直滚动而不是读取文字，说明它的视觉理解或提示词引导有问题。如果点击时选择器失效，通常是页面没有完全渲染，可以在动作前增加wait_for_load_state或 2 秒延时。

4.2 搜索并进入结果页

测试目的是验证多步骤操作能力。输入为“打开 bing.com，搜索 Computer Use Agent，返回第一条结果链接”。这个任务涉及输入框定位、输入文字、回车、等待结果列表渲染、提取链接，是典型的四步链。

判断标准是 Agent 能返回一个真实存在的链接，并且该链接与关键词相关。这个任务里最常见的问题是模型生成的 CSS 选择器不准确。建议切换到更稳定的定位方式，比如placeholder属性、aria-label或文本定位。在提示词中明确“如果直接选择器失败，先截图观察页面结构再修正”能明显提升成功率。

4.3 表单填写与提交

测试目的是验证 Agent 对交互元素的理解。选择一个无风险、可控的表单页面，任务为“输入用户名test_user，密码123456，点击登录按钮，判断是否会显示错误提示”。

这个任务验证的不只是点击能力，还有 Agent 是否能区分登录按钮和注册按钮、是否会把密码错误地显示在用户名框里。判断标准是 Agent 执行完成后，页面出现了预期的错误提示，并且 Agent 能正确读取提示内容。如果 Agent 提交后没有读取结果，说明它缺少“执行后观察反馈”的循环设计。可以在每次动作后把page的新截图和page.text_content('body')摘要一起丢给模型，增强反馈质量。

5. 接口 API 与批量任务

当单个 Agent 任务跑通后，下一步就是把它封装成服务，接进自己的工具链。

5.1 HTTP 接口封装

用 FastAPI 把上面的异步逻辑包一层即可。需要传入url、task、max_steps三个参数，返回执行结果。

from fastapi import FastAPI from pydantic import BaseModel app = FastAPI() class TaskRequest(BaseModel): url: str task: str max_steps: int = 10 @app.post("/agent/run") async def agent_run(req: TaskRequest): # 注意：run_task 内部会创建浏览器并关闭，真实场景建议复用浏览器实例 result = await run_task(req.url, req.task, req.max_steps) return {"status": "ok", "result": result}

启动服务的命令：

uvicorn agent_server:app --host 127.0.0.1 --port 8000

调用示例：

curl -X POST "http://127.0.0.1:8000/agent/run" \ -H "Content-Type: application/json" \ -d '{"url": "https://example.com", "task": "获取页面标题", "max_steps": 5}'

这里展示的是通用模板，真实项目需要调整请求体字段和返回结构。如果有多用户并发，要考虑为每个请求分配独立浏览器上下文，避免登录态和缓存互相污染。

5.2 批量任务建议

批量任务和单个接口调用的关注点不同。建议先把任务写入 JSON 行文件或数据库表，每个任务包含task_id、url、task、status、result、error字段。执行器从队列中取出任务，逐条执行并回写状态，失败的任务进入重试队列。

一个批量任务文件的示例：

{ "tasks": [ { "task_id": "001", "url": "https://example.com/a", "task": "提取页面主标题" }, { "task_id": "002", "url": "https://example.com/b", "task": "查找价格超过 100 的商品", "max_steps": 15 } ] }

批量执行时一定要加超时控制和并发限制。并发过高容易触发目标站点的人机验证，也会让本地浏览器实例的内存占用迅速增长。建议先从单并发开始，观察稳定后再逐步上调到 2 到 4 个并发。如果某个任务连续重试两次仍失败，直接标记为失败并记录截图，不要无限重试。

6. 资源占用与性能观察

资源占用是本地部署时最需要关注的部分。

使用云端 API 时，本地主要消耗是浏览器进程和内存。每个 Playwright Chromium 实例大约占用几百 MB 内存，并发任务数乘以浏览实例数就是峰值内存需求。这个阶段压力不大。

使用本地模型时，显存占用才是瓶颈。以常见的 7B 多模态模型为例，半精度推理需要 12GB 到 16GB 显存，量化到 4bit 之后可以降到 8GB 以下。具体数字取决于模型结构和量化方式，建议用nvidia-smi实时观察。如果显存不足，可以把--max_model_len调小、关闭并发、或者换到参数更小的模型。

CPU 推理也是可行的，但每一步“截图 -> 推理 -> 执行”的延迟会从 GPU 的 2 到 4 秒拉长到 20 秒以上。对于长链路任务，累积延迟会非常夸张，不适合批量生产，但可以用来做功能调试和提示词验证。

性能优化的优先级是：先减少步骤数，再减少每次推理的输入大小。比如只裁剪截图中的关键区域，或把页面 DOM 摘要交给模型而不是纯粹依赖截图。限制max_steps是保护成本最直接的手段。很多任务如果 10 步没完成，50 步大概率也完成不了，及时终止反而能省下大量 Token。

7. 常见问题与排查方法

下面的表格覆盖了本地搭建和运行 Computer Use Agent 时最容易遇到的问题。

这里有一个需要强调的原则：当自动化行为引发人机验证时，正确做法是中止任务并报告，而不是通过修改指纹、绕过验证码或模拟人类行为来继续执行。这类尝试既不稳定，也可能违反目标网站的使用条款。合规优先，技术测试要在受控和授权的环境中进行。

8. 工程化落地与合规建议

把 Computer Use Agent 从演示推进到工程化，下面几件事值得提前做。

第一，沙箱隔离。浏览器运行在 Docker 容器里，限制它可以访问的域名白名单。容器内不挂载真实用户目录，不读取本机敏感文件。Agent 能操作的边界越小，误操作的风险越低。

第二，权限分级。把动作分为低风险（读取页面、滚动、搜索）、中风险（填写表单、提交数据）、高风险（登录、支付、删除文件）。高风险动作默认由人工二次确认。评测数据中 Agent 的成功率再高，也不应该在真实支付环境里直接放行。

第三，全程审计。记录 Agent 的每一步截图、动作、模型输出、执行结果和耗时。这不仅能帮助回放问题，也是评估数据本身的来源。当任务失败时，有截图和动作序列才能判断是规划问题、执行问题还是页面问题。

第四，任务状态持久化。批量任务的服务要能暂停、恢复和重跑。推荐把任务状态写入数据库，至少也要写入日志文件。Agent 长任务经常因网络波动或页面异常中断，没有持久化就只能从头再来。

第五，合规前置。使用 Agent 抓取和处理数据时，要确认目标站点允许自动化访问，涉及用户个人信息时做脱敏处理，必要时进行数据来源合规评审。评测数据说明技术能做什么，合规决定业务能不能用它做。

9. 总结与下一步

从数据来看，Computer Use Agent 已经能完成不少结构清晰的多步骤浏览器任务，但在动态页面、异常状态恢复和高风险操作上还有明显短板。最值得你先验证的功能是：一个需要三步以上的网页操作任务，看它是否能独立完成，并且失败后能否自纠正。最容易踩的坑是选择器定位不稳定和触发人机验证。

如果这个最小实验跑通了，下一步可以往三个方向扩展：一是在动作循环中加入 DOM 摘要和元素定位辅助，减少对纯视觉截图依赖；二是把历史动作和结果反馈压缩进上下文，让 Agent 具备短期记忆和自我纠错能力；三是接入 MCP 协议，把浏览器之外的文件系统、数据库和内部工具统一暴露给 Agent，逐步逼近真正的“Agent 使用电脑”。

无论评测数据展示的效果多好，落地阶段始终要记得：Agent 是执行者，不是决策者。小流量验证、高权限拦截、全程审计，这三件事做到位，Computer Use 方案才能真正从实验变成生产力工具。