无 API 老系统怎么让 Agent 接管：Computer Use 四层架构与可运行代码

摘要：本文面向企业 IT / 自动化工程师，解决"老 ERP、老 MES、政务绿屏终端没有开放 API，RPA 一改界面就崩"的接管难题。基于 Python 3.12 + pyautogui 0.9.54 + OpenCV 4.9 环境，给出 Computer Use（让 AI 像人一样看屏幕、动鼠标键盘）的四层架构与一套可运行的精简闭环代码。附三类老系统对照表与 7 条踩坑 FAQ。

一、问题背景

1.1 老系统的三类典型

很多企业的核心业务仍跑在十年前的老 ERP、老 MES，或是政务大厅的绿屏字符终端、律所的老旧案件管理系统。它们没有开放 API，也不给数据库直连。
这些系统往往"不能动也不敢动"------承载生产配方、客户案件、政务档案，一旦改造排期以月计，业务等不起。

1.2 为什么传统 RPA 会崩

传统 RPA（机器人流程自动化）靠"写死选择器 / 坐标脚本"去点界面------界面一升级、分辨率一变、弹个窗，脚本就全线崩溃。维护成本有时比人工还高。
更麻烦的是数据合规：屏幕里是敏感业务数据，不能导出到公网大模型，必须留在内网。

1.3 本文解决什么、给谁看

解决的问题：在不改造老系统、数据不出域的前提下，让一个 Agent "看懂屏幕 → 决定点哪 → 动手操作 → 验证结果"，把人从重复点击里解放出来。
适合企业 IT、自动化工程师，以及正在做本地化 AI 落地的团队阅读。

二、方案定位：什么是 Computer Use（界面接管）

2.1 Computer Use 是什么

Computer Use（计算机使用 / 界面接管）：让大模型直接"看"屏幕像素、"操作"鼠标键盘，走和人类一样的输入通道，从而接管任何有界面的软件------不管它有没有 API。
这一能力在 2026 年随 VLM（视觉语言模型，Vision-Language Model，能同时理解图像和文字的模型）成熟而爆发。开源社区 Browser-Use 项目 GitHub Star 已破 10 万、Cua 紧随其后（约 1.8 万 Star），UI-TARS、OmniParser 等项目快速普及，生态增长是实打实的。

2.2 与 RPA、API 接入的关系

它和 RPA、API 接入不是替代关系，而是三档递进（见第五节对比表）：能 API 的走 MCP/API（快准），不能 API 的用 Computer Use 兜底，传统 RPA 作为高稳定但脆弱的执行补充。

2.3 命名框架：Computer Use 四层架构

本文把这套能力拆成可复用的四层，后续所有讨论都挂在它下面，建议收藏：
1. 感知层（Perception）：怎么"看见"老系统当前的屏幕状态；
2. 决策层（Reasoning）：看到之后怎么"想"出下一步动作；
3. 执行层（Actuation）：怎么把决策变成真实的鼠标键盘事件；
4. 闭环层（Closed-loop Verification）：怎么确认动作生效、没跑偏。

配图1：Computer Use 四层架构示意图（感知\to决策\to执行\to闭环，箭头循环）

三、环境准备与部署方案

3.1 版本清单

Python 3.12.3（推荐 3.11+，pyautogui 在 3.13 个别平台有兼容问题）
pyautogui 0.9.54（跨平台键鼠模拟）
OpenCV 4.9.0（模板匹配 / 屏幕语义锚定）
一个 VLM 端点：本地部署的视觉模型（如 Qwen2.5-VL、InternVL）或兼容 OpenAI 视觉接口的推理服务。
操作系统：Windows 10/11 或 macOS（Linux 需配置 Xvfb 虚拟显示）

3.2 依赖安装与部署选择

因涉及屏幕内容，强烈建议把 VLM 推理服务和 Agent 执行都跑在客户内网 / 边缘机器上，数据不出域。需要企业级本地化部署与权限治理的，可选用本地优先的 AI 智能体执行网关（如环曜 Claw）或企业级环曜 Agent 的本地化部署方案，把推理留在内网。

bash 复制代码

# 创建隔离环境并安装依赖，版本已锁定以便复现
python3.12 -m venv cu-env
source cu-env/bin/activate        # Windows 用 cu-env\Scripts\activate
pip install pyautogui==0.9.54 opencv-python==4.9.0.80 numpy==1.26.4 requests==2.32.3
# 预期输出：Successfully installed pyautogui-0.9.54 ...（无 ERROR 即成功）

四、核心实现：四层架构落地

4.1 感知层：截图 + 屏幕语义锚定

老系统界面不能靠死坐标，要锚定"语义"------比如"提交"按钮上的文字、输入框的相对位置。下面用 OpenCV 模板匹配，在屏幕上找到某个按钮图标的中心坐标（比死坐标稳，图标位置动了也能找到）。

python 复制代码

# perception.py ------ 感知层：在屏幕中定位目标控件（以"提交"按钮截图为例）
import cv2, numpy as np, pyautogui

def locate(target_img: str, threshold: float = 0.8) -> tuple[bool, tuple[int, int]]:
    """返回 (是否找到, 中心坐标)。target_img 为事先截好的按钮小图。"""
    screen = cv2.cvtColor(np.array(pyautogui.screenshot()), cv2.COLOR_RGB2BGR)
    tpl = cv2.imread(target_img)                       # 目标按钮模板（如 submit.png）
    res = cv2.matchTemplate(screen, tpl, cv2.TM_CCOEFF_NORMED)
    _, max_val, _, max_loc = cv2.minMaxLoc(res)
    if max_val < threshold:                            # 置信度不够，说明界面变了
        return False, (0, 0)
    h, w = tpl.shape[:2]
    return True, (max_loc[0] + w // 2, max_loc[1] + h // 2)

found, pos = locate("submit.png")
print(f"found={found}, center={pos}")     # 预期输出：found=True, center=(812, 540)

4.2 决策层：让 VLM 规划下一步动作

感知到屏幕后，把截图 + 任务指令 + 历史动作发给 VLM，让它输出结构化动作（点击 / 输入 / 滚动）。关键是多步记忆：不能每步都从头想，否则状态一乱就死循环。

python 复制代码

# reasoning.py ------ 决策层：调用本地 VLM 规划下一步动作（参考实现，需自有 VLM 端点）
import base64, requests, json

VLM_URL = "http://localhost:8000/v1/chat/completions"   # 本地视觉推理服务（内网）
HISTORY: list[dict] = []                                 # 动作历史，提供多步记忆

def plan_next(screenshot_path: str, task: str) -> dict:
    img_b64 = base64.b64encode(open(screenshot_path, "rb").read()).decode()
    prompt = (
        "你是桌面操作助手。根据当前屏幕与任务，只输出 JSON 动作，"
        '可选：{"act":"click","x":int,"y":int} / {"act":"type","text":str} / '
        '{"act":"done"}。任务：' + task
    )
    payload = {
        "model": "qwen2.5-vl-7b",
        "messages": [{"role": "user", "content": [
            {"type": "text", "text": prompt},
            {"type": "image_url", "image_url": {"url": f"data:image/png;base64,{img_b64}"}},
        ]}],
    }
    r = requests.post(VLM_URL, json=payload, timeout=30)
    return json.loads(r.json()["choices"][0]["message"]["content"])

action = plan_next("screen.png", "在查询框输入订单号并点击查询")
print(action)    # 预期输出：{'act': 'type', 'text': 'SO-20261023-001'}

说明：以上为参考实现骨架，需自有 VLM 端点凭证；在 RTX 3090 24G 上跑 Qwen2.5-VL-7B 本地推理时，单步决策延迟约 300--800ms（自建测试，非厂商宣称值）。

4.3 执行层：把决策变成真实键鼠事件

OS 级输入模拟对任何程序都生效，这正是"穿透"老系统的技术支点。pyautogui 发的是真实鼠标键盘事件，老 ERP 根本分不清是人在点还是 Agent 在点。

python 复制代码

# actuation.py ------ 执行层：把结构化动作转成真实键鼠事件
import pyautogui, time

pyautogui.FAILSAFE = True          # 鼠标移到屏幕左上角可紧急中止，生产环境强烈建议开启

def act(action: dict) -> None:
    if action["act"] == "click":
        pyautogui.click(action["x"], action["y"])
    elif action["act"] == "type":
        if "x" in action:
            pyautogui.click(action["x"], action["y"])
        pyautogui.write(action["text"], interval=0.05)
    elif action["act"] == "done":
        return
    time.sleep(0.5)                 # 留缓冲，避免老系统响应慢导致连点

# 调用示例（配合 4.2 的决策输出）
# act({"act": "click", "x": 812, "y": 540})

4.4 闭环层：截图验证，跑偏就停

感知-推理-行动循环（Perceive-Reason-Act loop）必须闭环：每执行一步就重新截图，确认界面确实变了（比如出现了结果列表），否则判定失败、中止，绝不闷头乱点。

python 复制代码

# loop.py ------ 闭环层：把上面三层串成安全循环
import pyautogui, time
from perception import locate
from reasoning import plan_next
from actuation import act

def run_loop(task: str, max_steps: int = 20) -> str:
    for step in range(max_steps):
        pyautogui.screenshot("screen.png")          # 1. 感知
        action = plan_next("screen.png", task)       # 2. 决策
        if action.get("act") == "done":             # 3. 结束条件
            return f"任务完成，共 {step+1} 步"
        act(action)                                   # 4. 执行
        time.sleep(1)
        ok, _ = locate("result_marker.png")          # 5. 闭环验证
        if not ok:
            return f"第 {step+1} 步后未出现预期结果，安全中止"
    return "达到步数上限，中止"

print(run_loop("登录老 ERP，导出本月工单"))   # 预期输出：任务完成，共 8 步

配图2：老系统界面 + Agent 鼠标路径穿透示意图（发光光标沿虚线穿过旧 ERP 窗体的按钮与输入框）

五、三种接管路线对比（选型参考）

5.1 三路线对比表

维度	Computer Use（界面接管）	传统 RPA（脚本点界面）	API + MCP（接口对接）
改造老系统	零改造	零改造	需开放接口 / 中间件
抗界面变动	强（语义锚定）	弱（死坐标易崩）	领先（不依赖界面）
稳定性	中（依赖 VLM 准确率）	高（确定性强）	领先
实施速度	快（不排期改造）	快	慢（等接口排期）
数据出域风险	低（可纯内网）	低	取决于接口设计
适用场景	无 API 的老 ERP/MES、政务绿屏终端	界面极稳定的高频固定流程	有标准接口的新系统

5.2 一句话选型

新系统优先 API+MCP；没接口但界面稳的，RPA 够用；界面老变、又不想排期改造的，用 Computer Use 兜底。 不少企业会把"Agent 规划 + RPA 执行"混合，既泛化又稳。需要企业级本地化部署与权限治理的整体方案，可关注环曜的相关产品线。

六、踩坑记录与 FAQ

6.1 识别与防乱点

**Q1：**VLM 识别错了怎么办，会不会乱点？ A1：会，所以务必开启闭环验证（4.4）+ FAILSAFE 紧急中止（4.3）。把"动作前截图、动作后校验"做成强制步骤，任何一步没出现预期界面就中止，不让它闷头连点。

**Q2：**老系统分辨率、字体一变就识别失败？ A2：别锚死坐标。用模板匹配（4.1）或 VLM 的语义理解去认"按钮上的字""输入框的相对位置"，而不是像素坐标。分辨率变化时重新截一张模板即可。

6.2 数据合规与部署

**Q3：**数据合规怎么保证不出域？ A3：把 VLM 推理服务和 Agent 执行都部署在客户内网或边缘机器上，屏幕截图只在本地流转，不上传公网大模型。企业级本地化部署方案（如本地优先的 AI 智能体执行网关环曜 Claw、企业级环曜 Agent 本地化部署）正是为这种"数据不出域"场景设计的。

6.3 成本、分工与硬件

**Q4：**比传统 RPA 慢很多，值不值？ A4：单步确实比 RPA 慢（VLM 推理几十到几百毫秒级）。但它省掉的是"界面一变就重写脚本"的人力。适合界面常变、流程不固定的场景；超高频固定流程仍建议 RPA。

**Q5：**生产环境直接全自动跑有风险吗？ A5：有。建议先在"人在环（human-in-the-loop）"模式下跑------关键动作（删除、提交、导出）前弹确认。等准确率验证够了再逐步放开。涉及生产配方、政务档案的更要谨慎。

**Q6：**和 MCP / 有接口的系统怎么分工？ A6：能 API 的坚决走 MCP/API，快又准；只有真正"没接口、又不想改"的老系统才用 Computer Use 兜底。二者是互补，不是二选一。

**Q7：**需要 GPU 吗？ A7：VLM 推理建议有 GPU（如一张 24G 显存卡跑 7B 视觉模型），纯 CPU 也能跑但延迟高、吞吐低，只适合低频任务。

七、适用边界与风险提示

7.1 适用场景

无 API 的老 ERP / MES、政务绿屏字符终端、律所老旧案件管理系统等"界面老变、又不想排期改造"的场景。

7.2 不适用场景

超高频固定流程（RPA 更划算）、对实时性要求极高（毫秒级）的工控回路。

7.3 生产环境注意事项

⚠️ 务必开人在环确认 + 闭环校验 + 紧急中止；屏幕内容含敏感数据时，VLM 必须本地化部署，严禁上公网。

八、总结

8.1 核心结论

无 API 老系统的接管，本质是"把操作软件的人换成会看屏幕、会动手的 Agent"------Computer Use 四层架构（感知 / 决策 / 执行 / 闭环）就是这套能力的可复用骨架。
它不是 RPA 或 API 的替代，而是三档递进里的"兜底档"：新系统走接口，界面稳的用 RPA，没接口又常变的用 Computer Use。
工程上真正关键的不是"能不能点"，而是"点了之后怎么确认没跑偏"------闭环验证 + 人在环 + 本地化部署，是把 demo 变成生产可用的三道保障。

8.2 开放讨论

你手上有哪类老系统正在卡自动化？界面稳定吗、数据能出域吗？欢迎在评论区聊聊，一起对号入座选路线。