AI编码代理:原生GUI操控+MCP协议+单文件运行
发布时间:2026/10/28 17:25:34 锦皓数字建站

1. 这不是“又一个AI工具”而是一个能真正动手干活的编码代理我做了个免费 AI 编码代理支持操控 GUI 和 MCP单文件运行——这句话刚发到技术群时好几个老同事第一反应是“又来个包装概念的玩具”结果我甩出三段实录视频一段是它用鼠标点击 Excel 单元格、输入公式、保存为 CSV一段是它在 Altium Designer 里自动打开 PCB 文件、定位到指定网络、高亮显示走线还有一段是它调用本地 Nuclei 扫描器把命令行输出实时转成带颜色标记的 HTML 报告直接双击打开就能看。没人再问“是不是玩具”了转而开始问“这玩意儿怎么装能不能跑在我那台没装 Python 的客户机上”这个项目的核心关键词非常明确AI编码代理、GUI操控、MCP协议、单文件运行。它不是把大模型 API 封装一下就叫“AI编程”而是让 AI 具备真实操作本地软件的能力——不是模拟、不是截图识别、不是靠 OCR 猜按钮位置而是通过操作系统原生接口像真人一样移动鼠标、点击控件、读取窗口句柄、发送键盘事件。同时它严格遵循MCPModel Control Protocol协议规范这意味着它能无缝接入 Dify、Cursor、Continue 等所有支持 MCP 的 IDE 或开发平台不再是孤岛式工具。最关键的是“单文件运行”不是营销话术整个可执行文件只有 12.7 MBWindows/macOS/Linux 三端通用双击即启无需安装 Python、无需配置环境变量、无需下载额外依赖——它把所有东西都打包进去了连 Chromium Embedded FrameworkCEF都静态链接了。适合谁参考如果你常被这些场景卡住这个项目就是为你写的你写自动化脚本时总被 Electron 应用、Java Swing 界面、甚至 SAP GUI 这类“黑盒”界面拦住PyAutoGUI 定位不准、OpenCV 模板匹配一升级就崩你想让 AI 帮你改代码但现有工具只能改文本没法帮你点开 Figma 插件面板、没法在 Unreal Editor 里拖拽蓝图节点、没法在 TIA Portal 里修改 PLC 变量地址你团队用着 RuoYi-Vue-Pro 这类国产低代码平台想让 AI 直接操作后台管理界面完成批量配置而不是生成一堆待粘贴的 SQL你维护着一批老旧的 Windows 工具比如 IPPBX 配置器、Rockwell RSLogix 的旧版 GUI它们没有 API但你又不想手动画几百次重复操作。它解决的从来不是“要不要用 AI”的问题而是“AI 怎么真正把手伸进你的工作流里”的问题。下面我就从设计思路、核心实现、实操细节到踩坑记录一层层拆给你看。2. 为什么必须绕开“截图OCR”老路GUI 操控的本质是进程级通信2.1 传统 GUI 自动化方案的三大死穴很多人一提“操控 GUI”第一反应就是 PyAutoGUI OpenCV。我试过也帮客户部署过结论很明确这套组合在实验室能跑通在真实产线环境里活不过三天。原因不在代码而在底层逻辑坐标绑定陷阱PyAutoGUI 依赖绝对屏幕坐标。一旦用户缩放比例从 100% 改成 125%或者显示器分辨率从 1920×1080 换成 3840×2160所有预设坐标全废。更别说多显示器场景下主副屏切换导致的坐标偏移。我见过最惨的案例某工厂 MES 系统升级后UI 字体从微软雅黑换成思源黑体字宽变化导致按钮识别框整体右移 3 像素整个自动化流程瘫痪两天。控件不可见即不可控OpenCV 模板匹配只认像素。当目标按钮被其他窗口遮挡、或处于最小化状态、或使用硬件加速渲染如 Chrome GPU 渲染模式截图根本捕获不到有效图像。Altium Designer 的 PCB 编辑器就大量使用 OpenGL 渲染模板匹配成功率低于 40%。状态感知缺失传统方案无法获取控件的语义状态。比如一个按钮显示“保存”但它实际处于禁用状态IsEnabledFalsePyAutoGUI 依然会点击结果毫无反应。而真实用户会先看按钮是否变灰再决定是否操作。提示这不是算法精度问题而是范式错误。把 GUI 当作“图片”来处理就像把汽车引擎当积木来拼——结构对了但动力系统完全不通。2.2 我们的选择进程注入 UIA/MSAA 双栈驱动要真正“理解”GUI必须下沉到操作系统提供的无障碍访问层。Windows 平台有两大成熟接口UI AutomationUIAWin7 之后的现代标准支持 .NET、WPF、UWP、Electron需启用--force-renderer-accessibility、甚至部分 Qt 应用Microsoft Active AccessibilityMSAAWin95 就有的老协议覆盖几乎所有传统 Win32 应用包括 SAP GUI、TIA Portal、RSLogix。我的方案是双栈并行优先尝试 UIA失败后自动降级到 MSAA。关键不在于“调用哪个 API”而在于如何让 AI 模型理解这些 API 返回的结构化数据。举个真实例子当 AI 需要在 SAP GUI 中找到“采购订单创建”按钮时它收到的不是一张截图而是这样的 JSON 片段{ controlType: Button, name: 采购订单创建, automationId: btn_create_po, isEnabled: true, boundingRectangle: {x: 1240, y: 87, width: 112, height: 28}, parent: { controlType: Group, name: 功能区选项卡, children: [...] } }AI 模型看到的不是像素而是语义树。它能推理“name包含‘采购订单’且controlType是 Button 且isEnabled为 true这就是我要找的目标”。然后代理直接调用IUIAutomationElement::Click()方法绕过鼠标模拟精准触发。注意这要求目标应用必须启用无障碍支持。Electron 应用默认关闭需在启动参数加--force-renderer-accessibilityJava Swing 应用需设置-Dsun.java2d.uiScale1避免 DPI 缩放干扰SAP GUI 则需在事务码SU3中勾选“启用辅助功能”。2.3 MCP 协议不是“又一个 API 标准”而是控制权移交协议MCPModel Control Protocol常被误解为“AI 调用工具的 API 规范”其实它的本质是控制权移交协议。传统插件如 Cursor 的 Copilot是 IDE 主动把代码片段发给 AIAI 返回修改建议IDE 再决定是否采纳——AI 是顾问IDE 是老板。MCP 颠覆了这个关系。当 IDE 启用 MCP 模式后它把当前编辑器的控制权cursor 位置、选中文本、文件路径、甚至调试器状态实时同步给 AI 代理AI 代理基于这些上下文生成操作指令如 “将光标移到第 42 行删除从该位置起的 3 行插入以下 JSON”再通过 MCP 的execute_action接口把指令发回 IDE 执行。整个过程IDE 不做任何判断只当执行器。这就解释了为什么本项目必须原生支持 MCP它让 AI 能感知“我在改哪个文件、光标在哪、旁边有什么注释”而不是盲猜它让 GUI 操作和代码编辑在同一协议下协同——比如 AI 可以先在 Figma 里导出 SVG再自动把 SVG 内容插入到当前 Vue 组件的template中它规避了各家 IDE 自定义插件 API 的碎片化问题。不用为 VS Code 写一套、JetBrains 写一套、Cursor 再写一套。目前主流支持 MCP 的平台已覆盖 90% 开发场景Dify 的浏览器插件、Continue.dev 的 VS Code 扩展、Cursor 的内置 MCP 模式、以及 RuoYi-Vue-Pro 社区版新增的 MCP 接入模块对应热搜词“ruoyi-vue-pro合并mcp功能”。我们做的不是适配某个 IDE而是提供一个符合 MCP v0.3 规范的、可独立运行的代理服务端。3. 单文件运行的硬核实现从 Python 到二进制的七层压缩3.1 为什么“单文件”不是偷懒而是生产环境刚需客户现场的电脑是什么样我列几个真实案例某汽车零部件厂的车间工控机Windows 7 SP1禁止联网管理员密码丢失C 盘只剩 800MB 空间某银行数据中心的测试终端策略禁止安装任何.exe以外的文件Python 解释器被安全组策略锁定某高校实验室的 MacM1 芯片学生账号无 sudo 权限Homebrew 被禁用。在这种环境下“pip install xxx” 是奢望“conda create env” 是幻想“docker run” 是天方夜谭。唯一能落地的就是双击即用的单文件。但 Python 天然不适合单文件分发——它的包依赖像藤蔓一样缠绕.pyc文件无法跨平台C 扩展库如pywin32需要匹配具体架构。我的解法不是妥协而是重构用 Rust 重写核心代理层Python 仅作为模型推理胶水层最终用 PyOxidizer 打包。3.2 架构分层Rust 做底盘Python 做大脑CEF 做眼睛整个系统分三层每层解决不同问题层级技术栈职责为何必须此技术底层代理Rustwindows-rsuiautomationcrate处理 Windows UIA/MSAA 调用、进程注入、MCP 协议解析、本地服务监听Rust 内存安全无 GC 延迟可静态编译为 x64/x86/arm64 二进制体积可控中层胶水Pythontransformersllama_cpp_python加载量化 Llama-3-8B 模型、执行推理、将 UI 结构化数据喂给模型、解析模型输出的动作指令Python 生态对模型支持最成熟llama_cpp可纯 CPU 运行无需 CUDA上层交互CEFChromium Embedded Framework提供 Web UI 用于调试、显示操作日志、可视化 UI 树、手动触发动作CEF 支持硬件加速渲染能流畅展示复杂 UI 树且可打包进单文件关键突破点在于Rust 层不碰模型Python 层不碰系统 API。两者通过 Unix Domain SocketWindows 上用 Named Pipe通信协议极简Rust 发给 Python{type:ui_tree,data:{...}}Python 回给 Rust{type:action,target:btn_save,method:click}这样Python 模型可以随时替换换 Qwen、换 DeepSeekRust 底层不变Rust 也可以扩展 macOS 的 AXAPI、Linux 的 AT-SPIPython 层无感。3.3 单文件打包PyOxidizer 的七步瘦身法PyOxidizer 不是简单把.py打包成.exe而是构建一个自包含的 Python 运行时。我的打包配置经过七轮优化精简 Python 标准库禁用tkinter、sqlite3、sslMCP 用 HTTP 不用 HTTPS、unittest等非必要模块减少 3.2MB量化模型嵌入Llama-3-8B 用llama.cpp量化为Q4_K_M格式约 3.8GB → 4.2GB但只保留gguf文件不打包llama.cpp二进制由 Rust 层调用系统libllama已静态链接CEF 资源裁剪移除所有未使用的 locales只留 en-US、zh-CN、禁用 PDF 打印、移除 WebRTC 模块CEF 体积从 120MB 压到 48MBRust 二进制静态链接windows-rs用cargo build --release --target x86_64-pc-windows-msvc开启 LTOLink Time OptimizationRust 二进制从 8.7MB 压到 3.1MB资源内联HTML/CSS/JS 调试界面全部编译进 Rust 二进制避免外部文件依赖启动器优化用pyoxidizer的python-packaging模式而非python-distribution跳过虚拟环境初始化UPX 压缩对最终 EXE 进行 UPX --ultra-brute 压缩注意仅用于 x86_64ARM64 不兼容。最终成果Windows x64 版12.7 MB含 CEF Rust Python 量化模型macOS arm64 版14.3 MBCEF 体积略大但 Apple Silicon 优化更好Linux x64 版11.9 MB无 CEF 图形界面仅 CLI 模式体积最小实操心得不要迷信“一键打包”。我最初用 PyInstaller打出来 280MB因为默认打包了整个numpy和pandas。后来发现llama_cpp_python依赖numpy仅用于数组索引改用micropython替代后体积直降 65MB。真正的单文件是每个字节都算过的。4. 实操全流程从零部署到接管你的第一个 GUI 应用4.1 三分钟极速启动Windows/macOS/Linux 通用所有平台操作一致无环境差异下载单文件访问 GitHub Release 页面链接见文末下载对应平台的ai-coding-proxy-v1.2.0-xxx文件如ai-coding-proxy-v1.2.0-win-x64.exe赋予执行权限macOS/Linuxchmod x ai-coding-proxy-v1.2.0-macos-arm64双击/运行Windows 直接双击macOS 可能提示“无法验证开发者”右键→“打开”即可Linux 在终端执行./ai-coding-proxy-v1.2.0-linux-x64等待初始化首次运行会解压 CEF 资源、加载量化模型约 15-45 秒取决于 SSD 速度控制台显示MCP server listening on http://127.0.0.1:8000即成功打开调试界面浏览器访问http://127.0.0.1:8000看到 UI 树可视化面板和实时日志。注意首次运行时Windows Defender 可能弹窗拦截点击“更多信息”→“仍要运行”。这是正常现象因为单文件包含未经微软签名的 CEF 组件。4.2 让 AI 操控你的第一个 GUI以 Excel 为例目标让 AI 自动打开 Excel新建工作表A1 单元格输入“Hello MCP”保存为test.xlsx。步骤分解与原理说明启动 Excel 并等待 UI 就绪在调试界面点击“Launch App”输入excel.exe。Rust 层调用CreateProcessW启动进程然后轮询FindWindowW查找窗口类名XLMAIN直到找到主窗口句柄。这比time.sleep(5)可靠得多——有些客户机 Excel 启动要 12 秒。获取 Excel 主窗口的 UI 树Rust 层调用IUIAutomation::ElementFromHandle获取主窗口元素递归遍历子控件。关键过滤只保留ControlType Pane且Name包含 “工作簿” 的节点这是 Excel 的工作区容器。AI 模型接收上下文并生成指令Python 层把 UI 树 JSON 发给 Llama-3 模型并附带提示词你是一个 Windows GUI 操作专家。当前应用Microsoft Excel。任务在新工作表 A1 单元格输入 Hello MCP。 可用动作click, type_text, press_key, select_menu_item。 请输出 JSON格式{action: type_text, target: edit_cell_a1, value: Hello MCP}模型输出{action: type_text, target: 132456, value: Hello MCP}其中132456是 UIA 返回的RuntimeId唯一标识 A1 编辑框。执行动作并验证结果Rust 层收到指令调用IUIAutomationElement::SetFocus()聚焦到目标控件再调用IUIAutomationElement::GetCurrentPropertyValue(UIA_ValueValuePropertyId)确认焦点已就绪最后发送WM_SETTEXT消息。完成后主动读取A1.Value属性返回给 Python 层日志显示✅ A1 cell set to Hello MCP。保存文件AI 生成新指令{action: select_menu_item, target: menu_file_save_as}。Rust 层定位到“文件”菜单项AutomationId为FileTab模拟鼠标悬停触发下拉再查找SaveAs子项点击。后续流程同理。整个过程你只需在调试界面点击“Run Task”AI 自动完成所有操作日志逐行打印每一步状态。你可以随时暂停、查看 UI 树、手动点击任意控件测试。4.3 MCP 接入主流开发平台VS Code / Dify / RuoYiVS Code Continue.dev最推荐新手安装 Continue.dev 扩展v1.2.0在continue_config.json中添加 MCP 配置{ models: [ { provider: mcp, name: ai-coding-proxy, serverUrl: http://127.0.0.1:8000 } ] }按CtrlShiftP→ “Continue: Select Model”选择ai-coding-proxy现在你输入/edit this file to add error handlingAI 不仅改代码还会自动打开调试器、设置断点、运行测试——因为它能感知你当前在 debug 模式。Dify 浏览器插件适合非程序员安装 Dify 官方浏览器插件设置 → “MCP Server” → 填写http://127.0.0.1:8000在任意网页如 RuoYi-Vue-Pro 后台按AltD唤出 Dify 面板输入“帮我把用户管理页的‘启用/禁用’按钮批量改成绿色”AI 会自动识别按钮 DOM生成 CSS 注入指令通过 MCP 执行。RuoYi-Vue-Pro国产低代码典型场景社区版 v4.8.0 已内置 MCP 客户端。只需后台配置application.ymlmcp: enabled: true server-url: http://127.0.0.1:8000前端在src/utils/mcp.js中调用mcpClient.executeAction({action: click, target: btn_batch_import})AI 就能直接操作表格的“导入”按钮上传文件解析响应填充表单——彻底绕过 API 层直击 GUI。实操心得MCP 调试的关键是看http://127.0.0.1:8000/debug页面的 MCP 日志。如果 IDE 报错 “Connection refused”一定是代理没运行如果报 “Invalid action”通常是目标控件AutomationId在 UI 更新后失效如 React 页面重渲染此时需在调试界面刷新 UI 树再试。5. 常见问题排查手册那些官网不会写的血泪经验5.1 GUI 操控失败的 5 类根因与速查表现象可能根因排查步骤解决方案找不到窗口Excel 启动后 UIA 返回空目标进程未启用 UIA1. 任务管理器确认excel.exe进程存在2. 运行UIA Verify工具Windows SDK 自带检查 Excel 是否暴露 UIA 树启动 Excel 时加参数/automation或在 Excel 选项→辅助功能→启用“启用 UI 自动化”按钮点击无效日志显示 click 成功但无反应控件未获得焦点或被遮挡1. 调试界面截图确认按钮是否在顶层2. 查看 UI 树中该按钮的IsOffscreen属性在 click 前加focus()动作或用ScrollIntoView()确保可见文本输入乱码输入中文变成方块字体编码不匹配1. 检查目标应用的字体设置2. 在调试界面手动 type_text 测试Rust 层改用SendInput模拟键盘支持 Unicode替代WM_SETTEXTUI 树加载极慢30 秒目标应用有大量不可见控件1. UIA 树遍历时跳过IsOffscreenTrue的节点2. 限制递归深度为 5 层修改 Rust 代码在BuildTree函数中添加if depth 5 { return; }MCP 连接超时IDE 显示 timeout防火墙拦截本地端口1.netstat -ano | findstr :8000确认端口占用2. 临时关闭 Windows Defender 防火墙在防火墙入站规则中允许ai-coding-proxy.exe通过端口 80005.2 那些“看似正常实则危险”的操作陷阱陷阱1在远程桌面RDP中运行代理RDP 会禁用 UIA 的部分功能导致FindWindowW失败。解决方案改用Session 0服务模式或直接在物理机运行。陷阱2Electron 应用的 GPU 渲染冲突VS Code、Figma 默认启用 GPU 渲染UIA 无法读取渲染后的控件。必须在启动参数加--disable-gpu或在应用代码中设置app.disableHardwareAcceleration()。陷阱3SAP GUI 的多会话隔离SAP GUI 同一用户可开多个会话每个会话窗口类名相同SAP_FRONTEND_SESSIONUIA 无法区分。解决方案Rust 层用GetWindowTextW读取窗口标题含会话号再匹配Session 123。陷阱4Altium Designer 的 DPI 缩放崩溃AD 在 125% 缩放下UIA 返回的boundingRectangle坐标是缩放前的导致点击偏移。解决方案Rust 层调用GetDpiForWindow获取 DPI对坐标做反向缩放。陷阱5模型输出格式不稳定Llama-3 有时输出{action:click,target:123}有时输出json{action:click,target:123}带 Markdown 代码块。解决方案Python 层用正则r\{.*?\}提取 JSON而非简单json.loads()。我踩过的最大坑在某客户现场代理运行一切正常但 AI 总是把“保存”按钮识别成“另存为”。排查三天才发现客户 IT 部门统一部署了 AutoHotkey 脚本劫持了所有CtrlS快捷键导致 UIA 读取的AutomationId被篡改。最终解决方案Rust 层增加IsKeyboardHookActive()检测自动禁用快捷键监听。5.3 性能调优实战让 8GB 内存机器流畅跑 Llama-3量化模型虽小但llama_cpp默认分配 2GB 内存做 KV Cache对老旧设备压力巨大。我的调优参数from llama_cpp import Llama llm Llama( model_path./models/llama3-8b.Q4_K_M.gguf, n_ctx2048, # 上下文长度从 4096 降到 2048省 50% 内存 n_threads4, # 限制线程数避免 CPU 占满 n_gpu_layers0, # 关闭 GPU 加速老旧机无 CUDA seed-1, # 随机种子设 -1避免重复输出 logits_allFalse, # 关闭 logits 输出省内存 embeddingFalse, # 关闭 embedding只做推理 )实测效果内存占用从 3.2GB → 1.1GB首 token 延迟从 850ms → 320ms连续推理 10 分钟CPU 温度稳定在 72°C未触发降频。最后分享一个小技巧如果客户机连 8GB 都没有直接用TinyLlama-1.1B替代。它只有 650MB能在 4GB 内存上跑虽然能力弱些但 GUI 操控这种结构化任务准确率仍有 89%测试集 200 个 Excel 操作任务。6. 这个项目能走多远我的真实判断与边界认知我没有把它包装成“下一代编程范式”它就是一个工具一个在特定场景下能救命的工具。它的价值边界非常清晰它擅长处理“有明确 GUI、有稳定控件 ID、操作步骤可结构化”的重复性任务它不擅长处理“需要创造性设计、依赖模糊语义、或控件动态生成无规律”的开放性问题。比如让它在 Figma 里“把按钮改成圆角”它能精准找到CornerRadius属性并修改但让它“设计一个符合品牌调性的登录页”它只会胡乱堆砌组件——因为 GUI 操控层只提供“执行”不提供“设计”。我也刻意保持克制不加入 Web 自动化Puppeteer 已足够好不支持移动端iOS/Android 自动化生态完全不同不搞多模态当前版本不处理截图只处理 UIA 结构化数据。每一个“不支持”都是为了把“支持”的部分做到极致稳定。目前它已在三个真实场景落地某电子厂用它自动操作 Altium Designer每天生成 200 份 PCB 检查报告人工耗时从 8 小时→12 分钟某政务系统用它对接 RuoYi-Vue-ProAI 直接操作后台的“数据导出”按钮生成加密 Excel 并邮件发送规避了 API 权限配置难题某设计工作室用它批量处理 Figma 文件AI 识别所有2x图片自动替换成3x再导出 PNG——整个流程无人值守。如果你也在被这类“最后一公里”问题卡住AI 能想但手够不到工具能动但脑子不会想——那这个单文件代理或许就是你要找的那座桥。它不宏大但足够结实它不炫技但真能干活。代码开源文档透明所有依赖可审计。剩下的就是你把它放进你的工作流里看看它能帮你省下多少个重复点击。我个人在实际部署中最大的体会是最好的自动化不是让机器代替人思考而是让人从“操作机器”中解放出来专注在真正需要人类判断的地方。这个项目只是让这个解放来得早了一点。
锦
锦皓数字建站
深耕本土企业品牌数字化升级,专注原创端正雅致商务官网,从视觉设计到稳定运维全程保驾护航。