让电脑自己干活：我用 WorkBuddy 直接驱动 Computer Use，绕开了所有 API 限制

如何才能让电脑自己干活？我想但凡用电脑的人都可能这样想过，特别是在如今AI时代浪潮下

你是否也遇到过这样的困境：公司电脑装不了 RPA，申请 API KEY 要走层层审批还不一定批得下来；可每天又有大量重复的操作要在某个软件里点来点去——打开、搜索、填表、导出…… 这篇文章，记录我如何用 WorkBuddy（一个有命令行、能读文件、能跑 Python 的 AI 助手）作为"操盘手"，直接驱动开源工具 Computer Use 去操作我的电脑软件，并且不依赖任何 MCP、不依赖任何 API KEY、不需要管理员权限。读完你不但能理解原理，还能照着我踩过的坑一步步复现。

一、底层能力：什么是 Pi / pi-computer-use

先讲清楚被操作的"原材料"是什么：

• Pi是一个自主型 AI 智能体，它本身就能"看截图 → 思考 → 点鼠标"地自主循环工作。

• pi-computer-use是 Pi 的一个扩展，专门赋予它"操作 Windows 桌面软件"的能力。

• 它底层靠一个叫 windows-bridge.exe的小程序驱动，封装了 Windows 的 UI 自动化接口。

最关键的一点：它操作软件的方式，和你我一样——看屏幕、找按钮、点鼠标、敲键盘。它不调用软件的接口，也不走任何 API。

这正是它的价值所在：当一款软件没有 API、你又拿不到 KEY 时，Computer Use 就能以"模拟人"的方式，替代那个本该由数据接口完成的事。

但光有这个"原材料"还不够——Pi 是自主智能体，每次都要"看-想-点"，离不开视觉模型，也受模型能力限制。真正把它用活、解决我实际问题的，是下面这位"操盘手"。

二、我的秘密武器：WorkBuddy 到底是什么

这是整篇文章的主角，必须讲清楚它凭什么能行。

WorkBuddy 不是又一个"聊天机器人"。它运行在我的电脑本地，拥有几项普通聊天 AI 没有的硬能力：

• 能执行命令行：在本地真实跑命令、启动进程、管文件； • 能读写文件系统：看得到我的项目目录、能改代码、能存产物； • 能跑 Python 脚本：不只是生成代码文本，而是真的把脚本跑起来、看结果、再迭代； • 能读源码、能调试排错：遇到黑盒，它会去翻底层代码、抓协议、定位根因，而不是瞎猜。

正是这些能力，让 WorkBuddy 能做 Pi 做不到的事——它不只是"用"Computer Use，而是钻到 Computer Use 的底层，把驱动逻辑直接攥在自己手里。后面的转折、加固、复活项目，全都建立在这四项能力之上。

三、它能干什么（能力全景）

我把 Computer Use 的能力拆成三层，方便理解：

1. 看（观察）

• 列出当前所有窗口（find_roots） • 观察某个软件的界面结构 + 截图（observe_ui） • 按文本搜索某个控件（search_ui） • 展开 / 检视某个具体控件（expand_ui / inspect_ui）

2. 做（执行）

• 点击、双击、输入文字、按组合键、滚动、拖拽、移动鼠标 • 既能用"坐标"点（像人看屏幕点），也能用语义引用 ref 点（更稳，不依赖截图）

3. 等（智能等待）

• 等专业等待某个弹窗出现、某个文字出现再继续（wait_for）——比写死的 sleep 精准得多

4. 浏览器自动化（彩蛋级能力）

• 它还能直接驱动浏览器（基于 CDP 协议）：打开网页、导航、在页面里执行 JS。 • 这意味着操作网页系统（如各种 Web 后台、在线知识库）是首选路径，比在桌面上点坐标可靠一个量级。

四、踩坑：装 Pi 这条路有多难（真实 11 坑）

光是把 Pi 装起来能跑，就撞了一鼻子灰。我把真实踩坑全列出来，省你时间——这些坑大多是在 WorkBuddy 协助下逐个定位、逐个解决的。

坑 1：bridge 编译失败 双击启动脚本后报 link.exe 错误——本机没有 MinGW 编译环境。 解决：直接用别人编译好的 windows-bridge.exe，放到指定目录即可，不用自己编。

坑 2 / 3：启动后 "No models available" 原因一：启动脚本依赖系统 PATH，而 PATH 被污染了。原因二（升级后）：新版会异步检测 key 超时。 解决：启动脚本里硬编码 Pi 的绝对路径，并显式传入 --api-key 和 --model 参数。

坑 4：CMD 中文编码炸（报 'Y' 不是命令） 启动脚本里写了中文 + 默认 GBK 编码冲突。 解决：脚本开头加 chcp 65001，并去掉所有中文。

坑 5：402 余额不足 DeepSeek 余额用完了。 解决：充值（或换其他模型）。

坑 6：400 image_url 错误 换了个模型后发现：DeepSeek V4 不支持视觉（看不了图）。而 Computer Use 必须能"看屏幕"。 解决：转向支持视觉的模型。

坑 7 / 8：模型连环翻车 • 试了某个 key，发现里面装的其实是 OpenRouter 的 key（命名误导）。顺势用 OpenRouter。 • 又试了某免费模型，结果是纯文本、没有视觉能力，免费档也结束了。 最终解决：筛到一个免费的视觉模型 NVIDIA Nemotron Omni，设为默认，实测可用。

坑 9 / 10 / 11：裸跑报错、PATH 被污染、旧窗口占锁 • 必须从带参数的启动脚本进入，不能从 CMD 裸跑 pi。 • 之前误操作污染了 PATH，备份后重写成干净路径。 • 旧 Pi 窗口没关会占锁，关掉即可。

一句话总结安装要点： 1. 装 Node 22+（Pi 指向它） 2. 用预编译的 windows-bridge.exe，别自己编译 3. 启动脚本硬编码路径 + 显式传 key/模型 + chcp 65001 + 去中文 4. 选一个支持视觉的模型（这点最重要，否则它"瞎"）

五、真正的转折：WorkBuddy 换思路破局

装好 Pi 后我很快发现，单靠 Pi 这个"自主智能体"走不远：它每次都要"看截图→想→点"，离不开视觉模型，模型一弱就会"找不到窗口""点错按钮"，而且每次都耗 KEY、耗联网。

真正的突破是 WorkBuddy 做出来的。它没有继续在"让 Pi 更聪明"上死磕，而是换了个思路——直接钻到 Computer Use 的底层：

1. WorkBuddy 读了 pi-computer-use 的完整源码，摸清了底层 windows-bridge.exe 的通信协议； 2. 它写了一个客户端程序，让 WorkBuddy 自己不通过 Pi、直接 spawn 这个 bridge，按协议发命令去操作软件； 3. 它把"点哪、输什么"固化成固定脚本，运行时根本不再需要 AI 模型、不需要 KEY、不需要联网。

bridge 的协议极简——往它的标准输入写一行 JSON 命令，它回一行 JSON 结果：

{"protocolVersion":4,"id":"uuid-xxx","cmd":"listRoots","args":{}}

就这一行，WorkBuddy 就能列出所有窗口、观察界面、点击、输入。这才是"模拟人操作软件"的真正引擎——而让这台引擎转起来的，是 WorkBuddy。

WorkBuddy 用它实操验证了一把：在公司的 TeamCenter（一款 Java 工业软件，没有 API、普通员工拿不到 KEY）里，自动完成"点搜索框 → 输入 1234 → 点搜索"。结果和人工操作完全一致——连弹出的"找不到可访问的对象"提示都一模一样。这一步，是 WorkBuddy 直接驱动 bridge 完成的，Pi 从头到尾没参与。

六、三方联动：人 + WorkBuddy + Computer Use

单用 Pi（自主智能体）的两个短板，正是 WorkBuddy 补上的：

• 每次都要视觉模型 + KEY + 联网，成本高 → WorkBuddy 把步骤写成脚本后，运行时不再需要 AI • 模型弱会"找不到窗口""点错按钮" → WorkBuddy 用"先探界面、再编程精确驱动"取代"模型自己摸索"

我设计的协作模式是这样的：

你（说人话提需求） ↓ WorkBuddy（读界面 → 把需求翻译成机器语言 → 写成 bridge 命令脚本 → 触发执行） ↓ 机器人脚本（驱动 windows-bridge.exe → 真实鼠标键盘） ↓ 你的电脑软件（被自动操作）

这个模式最妙的地方，也是 WorkBuddy 的独特价值：WorkBuddy 只负责"翻译和编排"这一步。一旦脚本写定，它就"功成身退"——脚本运行时就是一个普通 Python 程序，只依赖 windows-bridge.exe 和 Python 标准库，根本不需要 WorkBuddy 在线、不需要 KEY、不需要联网。

甚至可以把它编译成一个独立的 .exe 文件，拷贝给任何同事，双击就跑——零安装、零 KEY、零管理员、零联网。这正是"给非 IT 同事一个不需要 KEY 的自动化工具"的落地形态，而这整套产物，是 WorkBuddy 一行行写出来的。

七、它解决的是什么问题（企业场景的甜区）

回头看我公司的真实环境：

• 权限限制：装 RPA 要管理员、要采购审批；接 API 要申请 KEY、走安全评审。 • 人不是 IT：使用者是业务同事，既改不了配置，也拿不到密钥。

而这套"WorkBuddy + Computer Use"走 GUI 模拟，天然绕开这两堵墙：

• 它只是个普通桌面程序在操作鼠标键盘 → 不需要管理员、不需要 KEY、不需要 IT 开白名单。 • 业务同事只要会"描述要做什么"（由 WorkBuddy 帮他写成一键脚本）→ 工具替他点。

所以最适合它的，是这种场景： 公司电脑上，因为权限限制、因为用户非 IT 人员拿不到 API KEY，但日常工作中又有很多频繁重复性的操作软件来处理事务——这时就需要一款"模拟人操作软件"的工具，自动完成这些重复工作。

这正是它的价值爆发点。

八、一个诚实的边界（别神话它）

它很强大，但不是银弹：

• 能替代：软件没 API、拿不到 KEY 但能登录、低频/一次性/探索性操作、当黑盒用。这覆盖了前面说的多数痛点。 • 替代不了：批量抽数据（UI 逐屏识别慢又易错，API 一次返回万条）、高频流水线、要可靠结构化输出、无头服务器环境、界面频繁大改。 • 后台运行的现实：WorkBuddy 实测发现，普通软件可以用"程序化调用控件"的方式后台运行（不碰你的真实鼠标）；但像 TeamCenter 这种 Java 软件，控件暴露不全，被迫用坐标+真实输入，会被前台弹窗干扰。针对这类，WorkBuddy 专门写了"动态定位 + 弹窗自动关闭 + 离开电脑时再跑"的加固库（模板匹配定位、自动关报错窗、空闲检测）。要彻底隔离，需要一次性管理员开个独立会话——这比申请 API KEY 轻得多。

九、照着做：最小复现路径

如果你也想试，这是我能给的最实用步骤：

第 1 步：准备环境

• 安装 Node.js 22 或以上 • 确认有 Python（只要标准库，不用装第三方包）

第 2 步：拿到 Pi 和扩展

• 安装 Pi（@earendil-works/pi-coding-agent） • 安装 computer-use 扩展（@injaneity/pi-computer-use） • 把预编译的 windows-bridge.exe 放到扩展要求的 helpers 目录

第 3 步：准备一个支持视觉的模型

• 这是最容易翻车的地方。务必选支持图像输入（vision）的模型。 • 我最终用的是免费的 NVIDIA Nemotron Omni 视觉模型（通过 OpenRouter 接入），零成本可用。

第 4 步：写启动脚本（bat）

要点（都是踩坑换来的）： chcp 65001 设置你的 KEY 环境变量 用绝对路径启动 pi，并显式传 --api-key 和 --model 不要写中文、不要依赖系统 PATH。

第 5 步：用 WorkBuddy 直驱（进阶，也是我推荐的方式）

如果你像我一样，有一个能跑命令、能读源码、能写脚本的 AI 助手（比如 WorkBuddy），可以让它直接 spawn windows-bridge.exe，按 JSON 行协议发命令。一行 listRoots 就能列出所有窗口，一行 act 就能点击。这样你就能用"说人话"的方式指挥电脑干活，而不必每次都让自主智能体自己摸索——而且脚本一旦写好，后续运行根本不需要 AI、不需要 KEY。

十、最后：WorkBuddy 帮我复活了一个暂停的项目

写这篇文章时，WorkBuddy 刚好用这套能力复活了一个之前卡住的项目。

之前有个"行业知识库标签系统"项目：自动打标引擎全写好了（文档提取、受控词表、700 多篇标注结果都生成了），但因为知识库平台没有打标的 API/MCP，只能手动一篇篇点，项目被迫暂停。

WorkBuddy 去看了这个网页版知识库的真实界面，确认它是网页形态（DOM 元素有真实引用、可后台驱动、抗弹窗、零 KEY），判断出"用浏览器自动化去模拟人工打标"是可行路径。于是，这个被 API 限制逼停的项目，又有了自动化出路——而从读界面、判断形态、到准备写打标脚本，每一步都是 WorkBuddy 在实操。

这大概就是这类工具最迷人的地方：它把"每个软件单独接 API/KEY"的难题，换成"一台通用桥 + 一次登录"。对十个没有 API 的桌面/网页软件，是净赚；对一个已经上好 API 的系统，反而退步。

写在最后

Computer Use 不是要取代 API，而是去填 API 填不到的坑——那些没接口、没权限、却天天要人手动点的重复工作。而真正把它用活、把"想法"变成"能双击运行的机器人"的，是像 WorkBuddy 这样能读源码、能写脚本、能直接驱动底层的 AI 助手。

如果你也在公司电脑上被"重复操作软件"折磨，又拿不到 KEY、装不了 RPA，不妨试试这条路。

让电脑自己干活，从绕开那堵权限墙开始。

（本文所有结论均来自真实环境实测：Windows + Pi 0.80.10 + pi-computer-use 0.4.3 + 免费视觉模型 + WorkBuddy 本地驱动。安装脚本、bridge 客户端、TeamCenter 加固库、IMA 界面验证均已由 WorkBuddy 跑通验证。）