企业官网建设流程全解析

上周有个朋友发了一张截图给我：一个只有GUI的老工具，每天固定要手动点几十次。他想让AI帮他把这个流程自动化，结果AI回了一句“这个工具没有API，我只能在终端里写脚本，没法碰那个窗口”。就这么一句话，几乎把我逼疯了——现在的编码代理圈子天天吹得天花乱坠，能写代码、能跑命令、能读文件，怎么一到“操作图形界面”就集体失明？

所以我花了大概两个周末，动手做了一个免费开源的AI编码代理：它支持操控GUI，能按MCP协议接入外部服务，整个程序还打包成单文件运行，下载双击就能跑，不需要装Python，不需要配Node，更不需要折腾一堆依赖。目前项目以MIT协议公开。这篇文章不打算写成什么宣传册，也不准备堆概念，我就按实际开发顺序，把“为什么做”“怎么做”“踩了哪些坑”“实际跑得怎么样”完整写一遍。如果你也被“有界面没接口”的软件折磨过，或者正在纠结自己的工具链怎么接入MCP，这篇应该对你有用。

1. 为什么我要自己造一个能碰屏幕和外部工具的编码代理

1.1 现有编码代理的舒适区很宽，但“看屏幕”这件事基本是空白

现在市面上主流的AI编码代理，划一条线看能力边界其实很清楚：它们擅长处理能文字化、结构化的一切东西，比如写函数、重构代码、改配置、跑测试、查日志。霸道一点说，凡是能进终端、能变成文本流的工作，它们都能干得像模像样。可问题是，现实世界里的活不全是待在IDE里的，还有大量任务长在图形窗口里。

举几个最常见的场景：SAP GUI的日常数据维护、工业组态软件的参数配置、PCB设计工具里批量改网络颜色、CMake GUI里点Configure再点Generate、甚至普通用户电脑上某个老软件的导出向导。这些工具的通病是：官方没有开放API，脚本语言也调不动，只能靠人肉在窗口里点点点。更烦的是，这类软件还往往是正经业务里的关键环节，你不操作它，整个流程就卡死在那里。

我朋友们的抱怨出奇一致：AI写代码再强，也代替不了那只“点鼠标的手”。这让我越来越确定，编码代理缺的不是模型能力，而是“操作GUI的能力”。

1.2 真正卡住用户的不是写代码，而是“只有GUI没有接口”

做这个项目之前，我统计过自己日常工作中遇到的工具形态，大概分三类：

• 有API、有命令行：比如git、Docker、curl，这类是AI编码代理的舒适区。
• 有API但接口混乱：比如某些企业管理软件，每个版本改一次接口，文档还跟不上。
• 只有GUI、没有公开API：比如很多老工业软件、专业配置工具、内网业务系统，它们完全不对外暴露操作接口。

第三类才是大头。你可能听过“cmake gui”“sap gui下载”“stm32 gui框架”“nuclei gui scanner”这类搜索词，热度一直很高，为什么？因为图形界面工具不会消失，它永远是效率工具和业务系统里最容易上手、最难被替代的那一层。对开发者来说，给这类工具做自动化的传统方案只有一个：写鼠标宏。可鼠标宏是最脆弱的自动化方案，分辨率一变、窗口一挪、界面升级一次，整套脚本立刻作废。

我希望这个代理能做到的是“像人一样看屏幕，理解界面，然后操作界面”，而不是“记死一套坐标然后无脑重放”。这也是我整个项目里最核心的取舍。

1.3 MCP生态明明在爆发，接入体验却还是参差不齐

再说MCP。最近一段时间，MCP相关的访问热度高得吓人，比如“IDA MCP”“x32dbg的MCP插件”“dify浏览器MCP”“codex接入Figma/蓝湖MCP怎么授权”“通义灵码怎么用MCP连接Oracle”这些搜索词，几乎覆盖了逆向、前端、低代码、数据库各个圈子。说明什么？说明大家真的想把外部工具统一接到AI上，诉求是实打实的。

但深入用过的人都会发现，现阶段MCP有两道坎：第一，很多MCP Server装好了，客户端却不支持，或者要折腾半天授权才能“发现”它；第二，同一个MCP Server在A工具里能用，在B工具里就找不到，协议虽然标准化了，客户端对协议的处理却天差地别。所以我在设计这个代理时，直接把MCP客户端内置进去，做成“即插即用”的形态：已知的MCP服务器配置内置好，新服务器只要给出启动命令就能识别。

一句话概括我做这个项目的原因：我想让AI编码代理不再只会输出代码，而是成为能坐在电脑前干活、能调用外部工具链的“数字实习生”。

2. 拆解GUI操控：看懂界面只是开始，点得准才叫可用

GUI操作是整个项目里最容易低估、也最容易翻车的部分。我从方案选型到实际编码踩了不少坑，下面把这部分完整拆开。

2.1 先排除一条错误路线：坐标宏靠不住

最早我想偷懒，方案很简单：截屏、OCR识别文字位置、移动鼠标点击。后来我发现，这条路做Demo可以，做产品就是灾难。

原因有三：第一，不同分辨率、不同DPI缩放下，同一个按钮的绝对坐标完全不一样，Windows笔记本125%缩放在台式机100%缩放下，点出来的位置差几十个像素；第二，窗口可以移动、可以最小化、可以被遮挡，坐标宏完全无法感知这些状态；第三，大多数软件的界面不是静态图，按钮在未被激活时是灰色，激活后会变成高亮，还有各种Tooltip弹窗和右键菜单，坐标宏根本不知道当前界面是什么状态。

所以我很快放弃了“纯坐标驱动”的思路，转向“控件识别”。

2.2 主力方案：可访问性接口把GUI变成“DOM树”

Windows、macOS、Linux其实都内置了“可访问性”接口，它们原本是给读屏软件用的，但对开发者来说，这就是一套能把GUI变成结构化数据的免费API。

以Windows为例，UI Automation（UIA）可以枚举出当前窗口下的全部控件树，每个按钮、输入框、下拉列表都有名字、类型、AutomationId、屏幕坐标、可用状态。macOS对应的是AX API，Linux桌面环境则是AT-SPI，原理类似。用一句大白话解释：这就像给GUI做了一次“爬虫抓DOM”，AI拿到手的不是一张截图，而是一棵带语义的控件树。

我在代理里封装了这三套接口，暴露给AI的视图大概是这样的：

Window: "系统设置 - 显示器" ├── Button "应用" (disabled, rect=(1245, 780, 1320, 810)) ├── Button "取消" (enabled, rect=(1150, 780, 1225, 810)) └── ComboBox "缩放比例" (value="100%", options=["100%","125%","150%"])

AI看到这个结构之后，再结合用户的一句自然语言指令，比如“把缩放调成125%然后点应用”，整个操作路径就非常清晰：先找ComboBox控件，设置值，再找Button控件，点击。这种操作比坐标宏稳定太多，因为即使窗口移动了，控件树里的相对结构也不会变。

2.3 兜底方案：截屏、OCR和视觉定位

不是所有软件都提供可访问性接口，尤其是老掉牙的MFC程序、某些自绘界面的工业软件、还有游戏引擎的视口，控件树里往往全是空的。这类软件怎么办？我的兜底方案是三层递进：

第一层，截屏后用本地OCR识别文字位置，再换算成点击坐标。比如窗口上有个按钮写着“导出”，OCR拿到它的包围框，点中心就行。这里我推荐内置Tesseract或者Windows自带的OCR引擎，Tesseract的好处是离线可用，坏处是中文识别率不稳定；Windows自带OCR的好处是识别率高，坏处是接口调用略麻烦。

第二层，模板匹配。有些按钮没有文字，只有图标，那就预先存几张模板图，在截屏里做缩放的模板匹配。这个方案对小范围固定界面很好用。

第三层，接入视觉模型做语义定位。比如AI看到一个复杂的仪表盘界面，可以直接问视觉模型“仪表盘上的保存按钮在哪里”，模型返回坐标。这个方案最聪明但最慢，我一般只在OCR和模板匹配都失效时才启用。

2.4 异步等待：GUI自动化的头号翻车点

GUI自动化听上去就是“找控件+点击”，实际写起来80%的工作量在“等”。点击一个按钮之后，界面是异步加载的，按钮可能在0.5秒后才会亮起，弹窗可能1秒后才出现，数据列表可能3秒后才刷新。如果你写死sleep(2)，今天能用，明天网络慢一点就翻车。

正确做法是轮询等待：每隔200毫秒查一次目标控件的状态，直到它满足条件或超时。举一个我踩过的真实案例：操作CMake GUI自动配置项目，点“Configure”之后，编译器检测可能要跑十几秒，期间“Generate”按钮一直是灰色的。如果脚本不等按钮变亮就直接点，CMake会直接报错，整套自动化流程当场断掉。后来我把按钮状态的等待逻辑改成“被禁用时轮询，直到启用或60秒超时”，成功率才拉上去。

还有一个更隐蔽的坑：某些界面点击后没有任何视觉反馈，但已经触发了后台任务，这种时候不能只看按钮状态，还得盯日志文件或界面上的状态文本。我的原则是：GUI操作必须基于“状态机”去写，不是基于“时间表”去写。

提示：你在实现自己的GUI自动化时，永远先问一句“这个动作发生的判定条件是什么”，而不是“这个动作要等多久”。把后者写进代码，基本等于替未来埋雷。

3. 接MCP服务的那点事：协议基础、连接管理和踩坑经验

MCP这块我一开始想得挺简单，以为就是从标准输入输出里收JSON，实际接起来发现坑全在细节里。

3.1 MCP不是玄学，是一套带描述的远程函数

先给新朋友补个基础：MCP的全称是Model Context Protocol，本质上是一套基于JSON-RPC 2.0的通信协议。MCP Server会暴露一组“工具”，每个工具都有名字、描述、参数Schema，AI拿到这组列表后，根据自己的判断决定调用哪个工具。

这套设计有点像什么？像给AI准备的“USB接口”或者“工具超市”。你不用为每个工具单独写一套集成代码，只要MCP Server把工具描述按标准格式暴露出来，任何支持MCP的客户端都能直接调用。这也是为什么现在连IDA、x32dbg这类逆向工具，还有Figma、蓝湖这类设计协作工具都开始做MCP插件——生态一起来，价值就大了。

MCP最核心的三组方法是：

• initialize：客户端和服务端握手，交换协议版本和能力。
• tools/list：列出当前服务端支持的全部工具。
• tools/call：带参数调用某个工具，结果是结构化内容。

另外还有resources/list和prompts/list，分别用于暴露数据资源和提示模板，但日常用得最多的还是tools这组。

3.2 单文件环境里内置MCP客户端的关键代码

因为我的交付形态是单文件可执行程序，目标机器上没有Node也没有Python，MCP客户端必须自己实现，而且必须处理各种异常。核心代码其实不长，我给你贴一个最简实现：

import json, subprocess class MCPClient: def __init__(self, cmd): self.proc = subprocess.Popen( cmd, stdin=subprocess.PIPE, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True, encoding="utf-8" ) self._next_id = 1 def _request(self, method, params): payload = { "jsonrpc": "2.0", "id": self._next_id, "method": method, "params": params } self._next_id += 1 self.proc.stdin.write(json.dumps(payload) + "\n") self.proc.stdin.flush() while True: line = self.proc.stdout.readline() if not line: raise RuntimeError("MCP server closed unexpectedly") msg = json.loads(line) if msg.get("id") == payload["id"]: return msg def list_tools(self): return self._request("tools/list", {})["result"]["tools"] def call_tool(self, name, arguments): return self._request("tools/call", { "name": name, "arguments": arguments })

这段代码只处理了串行请求，但日常调用足够了。真正要小心的是：MCP Server的日志绝不允许写到stdout，必须重定向到stderr，否则一行日志混进来，整条stdout通道就废了，JSON解析立刻报错。这个问题我遇到不下三次，每次都是因为某个子进程库偷偷往标准输出打了调试信息。

3.3 stdio通道的三个坑：日志混流、进程崩溃和超时误判

结合我实际使用MCP的经验，最大的坑有三个：

第一个就是刚说的日志混流。解决方法是启动子进程时统一把stdout留给协议，想打印日志就写stderr，而且要是外部MCP Server不听劝，你就用shell重定向再包一层，比如cmd 2>debug.log，把日志强制导到文件。

第二个是进程崩溃。MCP Server也是普通程序，也会段错误、会被OOM杀掉。客户端必须实现重连逻辑，不能一崩就整个代理罢工。我的做法是“连续失败三次才报告用户，否则自动拉起新进程”，实测下来大部分崩溃都能快速恢复。

第三个是超时误判。有些工具调用执行要几分钟，比如编译代码、跑测试，如果统一设30秒超时，必然频繁误杀。我最终把超时策略改成了按工具类型区分：搜索、读取类的短超时给10秒，执行、修改类的长超时给120秒，再长就让用户手动确认是否继续等。

3.4 实际接入过的服务图谱：从代码检索到数据库

这个代理目前已经跑通了几大类MCP服务，覆盖的核心场景我列一下：

这五类是我自己用得最多的，也基本踩遍了“服务发现失败”“授权流程不一致”“工具返回结构不统一”这类问题。比如有那么几次，客户端已经拉起MCP Server，但tools/list一直返回空，查了半天才发现是服务端要求先走OAuth授权，没授权就不愿意暴露工具列表。这个在本地stdin模式里不存在，但远程HTTP模式几乎绕不开。所以我的建议是：本地工具优先用stdio模式，远程工具才考虑HTTP+S S E，授权链路能延迟就延迟，免得一上来就卡住。

4. 单文件交付：把解释器、依赖和工具链塞进一个二进制的代价

“单文件运行”这个特性听起来轻松，做过打包的人都知道，这里面的坑全是隐性成本。

4.1 用户的真实底线：不装环境、不配路径、不折腾依赖

我最早做出来的是一个需要pip install才能跑的版本，发给朋友试用，结果有一半人卡在环境配置上：有人公司电脑没有外网权限，pip装不了包；有人机器上Python版本对不上，一堆兼容问题；还有人压根不熟命令行，让他激活虚拟环境就像让他开飞机。搜索“rembg gui alexdemir windows便携版”这类词热度一直高，已经说明一切了——大家要的就是那种下载下来双击就能用的绿色版本，别的都是废话。

所以“单文件”不是炫技需求，是真实用户底线。我后来把所有依赖、内置OCR资源、MCP客户端代码全部打进一个可执行文件，目标就一个：用户在任意一台Windows机器上拿到文件，双击，等两秒，直接开始干活。

4.2 打包选型对比：为什么还是选了PyInstaller

实现单文件的方式有好几种，我做选型时列过一张对比表：

最后我选了PyInstaller，原因很简单：MCP客户端、UIA控件封装、OCR工具链在Python生态里都是现成的，Rust和Go的自动化生态差太远，要重新造轮子的话项目根本做不完。代价就是冷启动慢，PyInstaller的onefile模式启动时要先把整个依赖树解压到临时目录，实测冷启动大约2.5秒。这个对日常使用可以接受，但在用户耐心阈值只有3秒的情况下，2.5秒已经是红线了。

4.3 单文件模式的经典痛点与对策

单文件打包最难受的有三件事：

第一是杀毒软件误报。PyInstaller打包出来的exe因为要自解压，天然带着“加密壳”的味道，Windows Defender和各类杀软很容易报毒。我的缓解办法有两个：一是尽量不用UPX压缩，压缩虽然能瘦身，但误报率直线上升；二是坚持代码签名，哪怕是自签名的证书也能显著降低误报率。

第二是资源释放路径。OCR引擎、浏览器模板等内置二进制不能直接运行在临时解压目录里，因为有些软件的相对路径特别敏感。我统一把它们在运行时释放到用户缓存目录下的独立文件夹，用完不清空，下次启动可以跳过释放直接复用，这个优化也能顺带把冷启动时间砍掉大概20%。

第三是体积膨胀。一次性把OCR、MCP客户端、GUI自动化框架全打进去，exe体积直接到了40MB开外。我通过裁剪掉用不到的库（比如Chrome驱动、其他语言模型包）把体积控制在35MB左右，这个尺寸在现在的下载环境下已经不算离谱。

4.4 单文件与可维护性的拉扯

最后说句大实话：--onefile模式对开发者并不友好，每次构建都要重新打包，调试周期长，适合发布给外部用户；而--onedir模式适合开发者自己用和快速调试。所以我现在的做法是发布两种形态：正式版用单文件，开发版用目录模式。两套构建脚本同一份源码，只在PyInstaller参数上做区分。

如果你也在做同类工具，我的建议是：不要死磕“绝对单文件”，把单文件作为发布形态而不是开发形态，你才能真正兼顾用户体验和开发效率。

5. 实测记录：三类真实任务的表现和翻车现场

工具不能自说自话。以下是我拿这个代理实际跑过的三类任务，每类都有完整流程和数据，也都有翻车现场。

5.1 场景一：给一个只有GUI的老工具做批量操作

任务：软件A是一个只有GUI的老式配置工具，需要每天从一份Excel里读取50条配置，逐条录入界面、勾选开关、保存导出。整个流程人肉做大概一小时，而且极度枯燥。

代理的实际表现：启动后，它先抓取窗口控件树，定位到“导入”按钮，用OCR识别Excel内容（最初我尝试用第三方MCP读取Excel，后面发现直接用本地库更快），然后循环执行“填入字段-勾选选项-点击保存-确认弹窗”。实测50条数据总耗时约6分半，成功率92%。失败的4条里，有2条是界面弹出了一个罕见警告弹窗，代理没识别到；另外2条是某条数据里包含特殊字符，输入时触发了一个隐藏校验，字段变红但没有文字提示。

这个测试给我最重要的认知是：94%和100%的差距不在自动化能力，而在异常分支的覆盖密度。后来我给它加了一个策略：任何弹窗出现都先截图、OCR、再判断是“确认还是取消”，失败率才降下来。

5.2 场景二：一句指令完成代码库搜索、修改和测试

任务：在一个中等规模的项目里，我直接说“帮我找出所有调用旧配置读取接口的地方，把它们改成新接口，然后跑一遍相关的单元测试”。

代理的处理链路是：通过MCP连接代码索引服务，执行搜索，返回了一共17处调用点；然后它逐个打开文件，通过编码能力完成修改；最后调用测试MCP服务，跑完相关单测。全程大约2分30秒，人肉做大概要小半天。

这里有个值得说的细节：第一次跑的时候，MCP返回的搜索结果里有3个文件路径是旧的，因为索引服务有几分钟延迟，导致代理改了两个已不存在的文件，直接报错。后来我在客户端加了一步“打开文件前先校验路径是否存在，不存在就忽略”，这个问题就消失了。延迟同步是MCP工具链里最常见的隐形坑，尤其是索引类、缓存类服务，一定要在调用前做一次“新鲜度确认”。

5.3 场景三：浏览器报错、IDE修复、再回浏览器验证

任务：网站的某页面在固定操作下报了一个JS错误。代理要做的是：打开浏览器操作页面，读取控制台报错信息，到IDE里定位对应组件代码，修复后重新启动本地服务，再回浏览器验证。

这个任务能同时检验GUI操作、MCP调用、代码修改三项能力。代理实际跑下来，链路是这样的：浏览器控制MCP启动一个无头Chrome，点击相关组件，控制台捕获到“TypeError: xxx is not a function”的堆栈；接着通过代码搜索MCP定位到对应文件，读取文件内容和相邻依赖，分析了大约20秒后，给出了“这个函数是从老版本工具链引入的，新版本没有导出”的判断，然后修改了导入语句；最后刷新浏览器验证，报错消失。

全程看起来行云流水，实际上中间翻了一次车：无头Chrome跑起来后，页面里的一个第三方字体加载超时导致渲染阻塞，代理等了30秒没等到目标元素，直接超时终止。后来我把浏览器MCP的超时策略调成“等待DOM元素状态轮询而不是固定等待”，这个问题才解决。这又一次印证了我在第二章说的观点：凡是异步加载的地方，都得用状态轮询，而不是写死等待时间。

5.4 实测数据汇总：成功率、耗时和典型失败原因

我把最近一周的实测记录简单汇总了一下：

整体看下来，纯MCP场景最稳，GUI场景受外部环境影响最大，三端协同最考验异常恢复能力。这个数据也帮我明确了后续优化点：异常分支覆盖和自动化超时策略才是这类工具的生死线。

6. 边界与下一步：哪些场景我还不敢放开手

做了这么久项目，最想说的其实是边界，因为我知道一个能碰GUI、能调MCP的代理，一旦越界，破坏力比写错代码大得多。

6.1 安全确认机制：再强也不能替用户签“生死状”

我在代理里做了三层安全约束：

• 白名单模式：GUI操作默认只在用户明确指定的窗口内进行，不碰未授权应用。
• 高危动作确认：删除文件、覆盖配置、执行系统级命令，全部要求用户在弹窗里手动确认。
• 禁止无人值守的破坏性操作：所有操作日志落盘，用户可以随时回看。

这三点挡掉了很多麻烦。实际操作中，我还见过代理因为误判控件类型，把一个“删除”按钮当成“编辑”按钮的情况，如果没有二次确认机制，后果不堪设想。所以无论你的自动化能力多强，安全边界永远要靠机制兜底，不能靠模型自觉。

6.2 已知技术边界：3D视口、加密控件和高延迟远程桌面

目前这个代理还有三块硬伤：

一是游戏引擎视口和CAD类软件的3D画布，控件树里通常只能拿到菜单和工具栏，画布里的模型是拿不到的。Unreal编辑器里操作视口旋转、缩放这种事，目前只能靠视觉模型加坐标模拟，效果还不稳定。

二是加密控件。某些网银插件、自绘安全控件为了防自动化，故意不暴露可访问性信息，OCR也识别不出来。这类场景我选择直接放弃，不提倡也不支持绕过安全边界。

三是高延迟远程桌面。当代理跑在云端、操作目标是远程桌面里的GUI时，截图和控件的延迟会放大异步等待问题，我目前的策略是强制拉长轮询间隔，但体验确实不如本地流畅。

这些技术边界短期内不好完全解决，但至少要让用户知道“什么能做、什么不能做”，别一上来就整不可行的需求。

6.3 下一步计划：组件市场、专业领域MCP和插件化

接下来我有三个方向：

第一，组件市场。把常用的GUI操作套路封装成语义化动作包，比如“自动登录”“批量导出”“截图对比”，用户能直接下载复用，不用自己写脚本。

第二，专业领域MCP接入。现在业内已经有人在做Unreal 5.8 MCP、Altium Designer的AI接口MCP、TIA的交付包这类针对专业软件的MCP服务端，我会在代理里把它们的接入做成配置化的，让用户不用再为“怎么连”发愁。

第三，插件化。把GUI识别引擎、OCR引擎、MCP客户端全部拆成可替换的插件接口，社区里有人想换成更好的视觉模型，或者更好的OCR引擎，直接写一个插件就行，不用改主程序。

做这个项目的感受很直接：以前总觉得编码代理的天花板是“代码理解能力”，做完才发现，真正的天花板是“和现实世界打交道的能力”。模型再强，也得有手有脚才能干活。如果你手上也有那种“只有GUI没有接口”的老工具，或者正在给某个专业软件写MCP服务端，欢迎来仓库里聊聊思路，提交PR也行。我自己的体会是，这类工具最值钱的部分永远不是某个单点技术，而是你愿意为那些“又偏又麻烦”的真实场景多花的那点心思。