单文件AI编码代理：融合GUI操控与MCP的实践解析

说实话市面上的 AI 编码代理我已经用了一圈从闭源的云端 IDE 到开源的终端 Agent结果没有一个能真正解决我手头最烦的问题这些工具只能改代码不能替我去操作界面上那些乱七八糟的老软件。我手上有好几个项目天天要跟带 GUI 的客户端程序打交道——填表单、点菜单、截图复现 bug这些活儿恰恰是终端型 Agent 干不了的。而且我实在受够了装一个工具要先拉一堆 npm 包、配 Python 虚拟环境、再开 Docker 的日子。所以我花了几周时间自己写了一个免费的 AI 编码代理核心思路就三条能操控 GUI、能接 MCP、单文件运行。所谓单文件就是整个代理本体只有一个可执行文件拷贝到任何一台机器上就能跑不用装解释器不用装依赖连 Python 都不需要。模型可以接任意 OpenAI 兼容接口也可以是本地 Ollama。GUI 操控走的是系统级无障碍接口而不是像素点鼠标那种脆弱方案MCP 则让我这个代理能直接调用文件系统、Git、数据库甚至二进制分析工具的能力。这篇文章就完整讲讲它的架构设计、实现细节以及我在实测里踩过的大坑。这篇内容适合哪类人一是跟我一样每天要和桌面 GUI 程序打交道的开发者和测试工程师二是想搞懂 MCP 协议怎么落地、想自己实现一个客户端的人三是准备做轻量 Agent 分发、对单文件部署有执念的折腾型选手。我会把为什么这么设计讲透而不是只贴代码。1. 为什么放弃现成的 Agent转而自己造轮子1.1 现有方案的三个痛点先说结论不是现有工具不好而是它们都默认了一件事——你要操作的目标是代码而不是软件界面。市面上的 AI 编码代理大致分三类。第一类是云端 SaaS比如各种网页版 IDE 助手优点是开箱即用缺点是代码必须放它那儿公司的合规就过不了。第二类是终端型开源 Agent比如基于 CLI 的那些能在命令行里读写文件、跑命令、用 git但它们对图形界面基本是瞎子——你说帮我把这个软件设置里的自动保存打开它只能去翻配置文件如果这个设置只存在于 GUI 菜单里它就彻底没辙。第三类是重型 GUI 自动化框架像 OpenInterpreter 这种能控制桌面但安装成本高依赖一堆部署到客户现场就是噩梦。还有一个很隐蔽的痛点上下文是割裂的。一个 Agent 能改代码但不能同时看见我的测试环境界面能看浏览器但看不了原生桌面应用。你让它复现一个 bug它得先在代码里猜然后让你手动截图再描述信息损耗特别大。我一直在想为什么不让 AI 直接去看那块屏幕、直接去操作那个窗口呢1.2 我的目标形态一个文件三条能力我给自己定的验收标准非常具体免费不搞订阅不锁功能模型部分用户自己带 API Key或者接本地开源模型。单文件一个可执行文件拷贝到 Windows / macOS / Linux 就能跑不依赖 Python、Node、Docker 和任何系统级运行时。能看能点通过无障碍接口读取界面结构把窗口和控件变成文本送给模型模型决定点什么、输入什么。能接 MCPMCP Server 由用户提供代理负责管理生命周期并提供工具给模型。跑通一个闭环回路模型发出动作 → 执行器执行 → 界面变化 → 重新扫描 → 模型再看 → 直到任务完成。最后这条才是 Agent 和普通自动化脚本的本质区别。脚本是写死的流程Agent 是动态感知-决策-执行的循环。我的整个架构就是围绕这个循环展开的。1.3 它适合谁、不适合谁说清楚边界很重要。这个代理适合的场景包括GUI 回归测试的初步试探、老程序表单的批量录入、多步骤向导的自动化、配合 MCP Server 做跨工具的分析流水线。不适合的场景是要求 100% 稳定的生产级自动化GUI 天然有随机性、需要强实时性控制AI 决策有延迟、以及没有模型 API 的纯离线内网环境本地 7B 级别模型能力有限复杂任务效果会打折扣。我自己的使用定位是半自动:它负责把重复的界面操作和代码修改跑通我来兜底审核。这点请务必认清后面讲安全性时还会展开。2. 单文件可执行架构取舍与构建细节2.1 为什么选 Go 做宿主语言单文件这四个字背后是一连串技术选型。我在 Rust 和 Go 之间犹豫过最后选了 Go理由很实际Go 天然编译成静态二进制交叉编译一条命令搞定GOOSwindows GOARCHamd64 go build就能出 Windows 版本不需要在 Windows 上装工具链。代理要同时管理多个 MCP Server 子进程还要做 GUI 事件循环Go 的 goroutine 和 channel 在这种并发模型下写起来很顺手。GUI 自动化这块Windows 上可以直接通过 COM 调用 UI AutomationGo 有go-ole这类库macOS 和 Linux 有对应的cgo桥接方案。虽然跨平台桥接层要各写一份但接口可以抽象得很干净。分发太省心了。一个二进制拷到客户机器上双击就能跑这是任何解释型语言都做不到的。有人会问为什么不用 Python诚实地讲Python 在 GUI 自动化和 AI 生态上确实最强但单文件这个硬约束就直接把它排除了。PyInstaller 虽然能打包但出来的单文件本质是自解压首次运行要解压到临时目录杀毒软件还经常误报跨平台交叉编译更是麻烦。用 Go 是把分发体验放在生态便利之上的取舍。2.2 平台 GUI 桥接层的动态选择GUI 操控是跨平台难点中的难点。我没有试图写一套统一的底层而是抽象了一个GUIAdapter接口针对三个平台各自实现平台底层技术实现方式备注WindowsUI Automation (UIA)COM 调用通过 go-ole控件信息最丰富支持按条件搜索macOSAccessibility APIcgo 桥接需要辅助功能权限授权LinuxAT-SPI D-BusD-Bus 调用依赖桌面环境实现程度GTK 系最好接口也非常简单实际就四个方法type GUIAdapter interface { Snapshot(ctx context.Context, focus string) (*UITree, error) Do(ctx context.Context, action Action) (*ActionResult, error) Wait(ctx context.Context, predicate string, timeout time.Duration) (*UITree, error) Close() error }Snapshot是把当前屏幕里活动的窗口变成一棵控件树Do是执行一次鼠标键盘动作Wait是轮询等待某个界面状态出现。整个 Agent 主循环就是反复调用这几个方法。选 Windows 做第一实现是因为 UIA 的成熟度最高我的主要使用场景也在 Windows 上。2.3 构建、瘦身与跨平台编译单文件的体积我控制在 12MB 左右方法是编译参数加-ldflags -s -w去掉符号表和调试信息能砍掉接近 40% 的体积。不引入重量级 GUI 框架代理本身没有界面只有一个启动窗口加命令行参数解析。内置的提示词模板和默认配置用go:embed直接打进二进制运行时不需要附带任何外部文件。所有平台原生库在 Windows 上是纯 Go COM所以 Windows 版能做到真正的静态链接macOS 和 Linux 版的 cgo 桥接层需要动态链接系统库但在各自系统上仍然是一个文件。这里有个容易误解的点我后来干脆在 README 里写明白了单文件指的是代理本体单文件不等于整个解决方案零依赖。MCP Server 是用户按需提供的独立程序它可以是 npx 包可以是 pip 装的也可以是单独二进制。代理负责以子进程方式拉起它们用自己的生命周期管理来保证用户视角只有一个入口。2.4 配置文件与首次启动体验为了让零基础部署成立我把所有可调项都收敛到了一个 YAML 文件agent.yaml如果文件不存在首次启动时自动生成。内容大致长这样model: provider: openai-compatible base_url: http://127.0.0.1:11434/v1 model: qwen2.5-coder:14b temperature: 0.1 gui: engine: uia # uia | cocoa | atspi depth_limit: 8 # 控件树最大深度 max_nodes: 500 # 控件树最大节点数 action_limit: 30 # 单次任务的动作上限 mcp: servers: fs: command: npx args: [-y, modelcontextprotocol/server-filesystem, C:\\work] transport: stdio git: command: npx args: [-y, modelcontextprotocol/server-git, --repo, .] transport: stdio safety: confirm_gui: true # GUI 动作执行前是否需要人工确认 allow_shell: false # 是否开放 shell 工具 screenshot_diff: true # 动作前后截图对比检测异常首次启动时它会检测架构、加载对应平台的 GUI 适配器、拉起配置里的 MCP Server、然后问你一句话任务描述。整个过程没有任何安装向导这是单文件哲学的一部分。后面 MCP 部分我还会详细讲tools/list和tools/call是怎么接进来的。3. GUI 操控让模型看见并动手的关键链路3.1 像素坐标方案的致命伤以及我的替代路线很多自动化工具走的是截图 坐标点击路线基本原理是截一张图把图片发给模型模型返回点 (320, 180)工具照做。这个方案视觉直观但我在实际试了十几次之后放弃了原因有三个坐标和逻辑脱节。程序窗口一移动、DPI 一缩放上一次的坐标就废了。高分屏 125% / 150% 缩放下截图坐标和实际点击坐标之间的映射关系很容易出幺蛾子。上下文开销大。每轮交互都要传一张大图成本高、延迟高。模型为了找一个按钮得反复截图。模型看图点坐标的正确率不稳定。对于熟悉的现代 UI 还行老式软件那种密集按钮、复杂表格的截图误点率很高。所以我走的是另一条路语义化读取界面。通过系统无障碍接口拿到一棵控件树树上的每个节点有类型、名称、状态、位置矩形。这就像给模型发了一份这个窗口的 DOM而不是一张照片。模型不需要猜坐标只需要说点击名为确定的按钮执行器负责根据控件矩形坐标去点。这套方案在 Windows 的 UIA 下效果尤其好因为 UIA 能拿到非常细的控件属性按钮、编辑框、复选框、菜单项、滑块都有对应的控件类型和状态。老软件只要不是纯自绘界面那种整块窗口只暴露一个 Canvas 的基本都能读出来。纯自绘的界面没办法只能退回截图模式我留了一个pixel_fallback开关给这种场景。3.2 把控件树压缩成模型友好的文本直接序列化整棵 UIA 树是行不通的。我实测过一个中等复杂的配置窗口全量节点能到 1.5 万完整 JSON 序列化后约 20 万字符直接就把上下文窗口打爆了。所以在把树喂给模型之前要做三层压缩裁剪按depth_limit和max_nodes截断太深的树只保留摘要节点。归一化去掉AutomationId、ProcessId这类模型用不上的属性只保留type、name、state、rect四类。扁平化把树转成一个紧凑的文本块每个控件一个编号后续动作直接引用编号。压缩后的效果大概是这样[窗口] 系统设置 (id1) ├─ [标签] 显示设置 (id2) ├─ [下拉框] 分辨率: 1920×1080 (id3) ├─ [复选框] 自动保存 (已勾选) (id4) ├─ [按钮] 应用 (id5) └─ [按钮] 取消 (id6)模型看到的指令是你可以引用界面上控件的名称或编号来执行动作禁止猜测不存在的控件。动作也做了白名单设计一共十个click、double_click、input、key、scroll、select、focus、copy、paste、wait_until。每个动作的参数都必须包含目标控件的id或name其中之一。下面是动作执行器的核心逻辑摘录命令来自模型但落点由控件树的真实元素坐标决定case click: node : tree.Find(action.Target) if node nil { return ActionResult{OK: false, Reason: target control not found}, nil } if err : adapter.BringToFront(node.Window); err ! nil { return nil, err } pt : node.Rect.Center() if err : adapter.MouseClick(pt.X, pt.Y); err ! nil { return nil, err }这里有个关键细节执行任何动作前先BringToFront。GUI 自动化最大的隐形坑就是窗口在后台坐标算得再准也点到别的程序上去了。先用SetForegroundWindow把目标窗口带上来再做点击成功率能提升一大截。3.3 循环主控模型怎么判断任务完成有了看见和动手还需要一个大脑回路。我的循环设计参考了 ReAct 模式每一轮模型输出有两种选择一是调用某个动作工具二是输出task_complete并附带总结。Agent 会在每轮动作后自动重新快照界面把新的控件树作为下一轮的上下文。这里有个很重要的工程决策不要每轮都重扫整棵界面树。界面没变化时重扫纯属浪费。我加了一个简单的判断——动作执行后先做一次局部像素 diff如果目标区域没有变化就沿用上一轮的树如果变了才全量重扫。实测这个优化能把一次 10 步任务的总 token 消耗降掉 40% 左右。安全和稳定性我放在很靠前的位置。设计上默认开启了confirm_gui: true也就是模型决定点击或输入之前控制台会打印将要执行的动作等我按回车确认。这个人机确认模式在调试时救了我很多次等跑熟了再关掉也不迟。另外还有一个action_limit兜底——模型如果陷入反复点同一个按钮的死循环达到上限就强制终止避免车轱辘话烧掉你整月的 API 预算。3.4 DPI、窗口焦点和其他幽灵问题GUI 自动化最大的敌人不是模型而是系统环境。我踩过的坑按杀伤力排序DPI 缩放。UIA 返回的坐标是物理像素还是逻辑像素Windows 上不同进程的 DPI 感知模式不同返回的坐标系统就可能不同。我最后的处理是强制让代理进程声明PerMonitorV2DPI 感知并在读取坐标后统一除以缩放因子。窗口未聚焦时点不准。前面已经说了执行动作前强制BringToFront但这招对很多不响应前台激活的置顶窗口无效需要额外判断窗口是否真的处于激活状态。UIA 树的幽灵节点。有些控件在树里存在但实际不可见比如折叠的 Tab 页点上去毫无反应。我现在会过滤掉IsOffscreen为真的节点宁可少给模型几个控件也不要给它一堆点了没反应的选项。等待策略。弹窗加载是异步的点完按钮立刻查弹窗往往会扑空。我的wait_until工具就是干这个的指定一个控件名轮询最多 N 秒直到该控件出现在树里或者超时。这些听起来都是细节但实际决定了一个自动化的成功率是从 30% 到 90% 的差别。4. MCP 接入一个客户端打通所有工具4.1 MCP 到底是什么三个角色一次说清MCPModel Context Protocol是 Anthropic 在 2024 年底开源的一个协议目的特别朴素给 AI 模型一个标准化的外接工具插口。你可以把 MCP Server 理解成一个工具服务器——它向外暴露三类能力工具Tools、资源Resources和提示Prompts。而模型本身不直接跟具体的文件系统、数据库、调试器对话它只跟 MCP 客户端对话由客户端负责把请求转发给正确的服务器。这套设计最聪明的地方在解耦模型侧只需要理解统一的 JSON-RPC 调用工具侧只需要实现协议双方谁都不需要知道对方的具体实现。我想给代理加一个新能力不需要改模型只需要加一个 MCP Server 配置文件。我实现的是标准的客户端角色。协议的握手过程是客户端启动时对每个配置好的 Server 发起initialize请求交换协议版本和能力声明。客户端发送notifications/initialized通知。客户端调用tools/list拿到该 Server 所有的工具清单。模型在推理时选择某个工具客户端调用tools/call把参数传过去拿到工具执行结果。4.2 我实现的轻量客户端发现、调用、错误处理因为要保持单文件我没有引入现成的 MCP SDK而是自己用 Go 的标准库实现了 JSON-RPC 2.0 通信。stdio 模式下的核心逻辑就是管理子进程的 stdin/stdouttype ServerConn struct { cmd *exec.Cmd session *jsonrpc2.Session tools []Tool } func (s *ServerConn) ListTools(ctx context.Context) ([]Tool, error) { var res struct { Tools []Tool json:tools } err : s.session.Call(ctx, tools/list, map[string]any{}, res) return res.Tools, err } func (s *ServerConn) CallTool(ctx context.Context, name string, args map[string]any) ([]ContentBlock, bool, error) { var res struct { Content []ContentBlock json:content IsError bool json:isError } err : s.session.Call(ctx, tools/call, map[string]any{ name: name, arguments: args, }, res) return res.Content, res.IsError, err }实际代码里还要处理分帧JSON-RPC over stdio 用换行符分隔消息、超时、子进程退出码管理。MCP Server 经常因为配置错误或者路径问题启动失败我加了启动日志缓存——Server 启动后前 5 秒的 stderr 会被记录下来如果握手失败直接把日志打给用户看。这个处理在填坑时特别有用不然用户根本不知道是自己的 npx 命令出错了还是协议出错了。这里我必须强调一个大家容易误解的点MCP 的tools/list返回的是一个符合 JSON Schema 的函数描述格式是这样的{ name: read_file, description: 读取指定路径的文件内容, inputSchema: { type: object, properties: { path: {type: string, description: 文件绝对路径} }, required: [path] } }而主流的 OpenAI 兼容模型接口工具声明格式也差不多是namedescriptionparameters。所以我做了一个很小的转换层把 MCP 的inputSchema映射成模型接口的parameters字段。这样一来模型侧完全不用知道这是 MCP 工具还是这是原生工具我甚至可以把 GUI 动作也伪装成工具声明混在一起。模型只看到一组统一的能力菜单。4.3 我实测过的 MCP Server 组合单文件代理本身是一个工具壳价值全靠接进来的 MCP Server 体现。我在这几套组合上做了实测第一套是文件系统 Git。用官方 reference server 的 filesystem 和 git 两个包代理可以直接读写指定目录、查看 git 状态、执行 commit。配合 GUI 操控我做过一个完整任务打开目标软件把这个 bug 相关的日志文件读一遍对照代码仓库里的提交历史自动生成一个修复 patch。这套组合最稳也是日常开发里使用频率最高的。第二套是浏览器自动化。通过 Playwright 的 MCP Server模型可以直接操作网页打开 URL、点击元素、提取文本。这个其实和 GUI 操控有重叠但浏览器场景下 Playwright 的稳定性远超通用 GUI 方案所以我保留了它。两个通道各有分工通用桌面软件走 GUI网页走 Playwright MCP。第三套是二进制分析工具。这一步戳到很多人的兴趣点了——现在 IDA、x32dbg 这类调试器社区已经有人写了 MCP 插件让模型能直接控制调试会话。我把代理接到 IDA 的 MCP Server 上任务是分析这个函数的调用关系和漏洞嫌疑。实测下来模型确实能自动调用反汇编、查看交叉引用、读取结构体定义像模像样地给出一个分析报告。虽然深度还比不上资深逆向工程师但作为第一轮筛选非常有效率。类似的用法还能延伸到数据库 SQL 查询、容器管理、设计稿转代码比如接 Figma MCP 拿设计规范再写前端代码等场景。有一点值得单独说MCP 生态的杀手级应用不是某一个工具而是任意工具与任意模型组合的可能性。今天社区里冒出个新工具的 MCP Server我不需要改代理代码加一行配置就能用。这才是协议的红利。4.4 工具描述如何影响模型调用成功率在做了几十轮实测之后我得到一个非常强烈的感受模型调用工具的准确率取决于工具描述写得好不好而不是模型本身聪明不聪明。有个案例特别典型。我第一次把 filesystem 的list_directory工具喂给模型时它经常不调用而是在回复里猜测目录内容。后来我改了描述从列出目录内容改成列出目录内容调用前请确认 path 非空且为合法目录路径如果 path 不存在会返回错误请勿猜测文件列表。加了约束和边界说明之后调用准确率立刻上来了幻觉输出几乎消失。这里面的规律可以总结成三条描述里写清楚前置条件和失败模式模型就能少犯错误。参数默认值要显式标注不要留空让模型猜。工具的description要服务于什么时候用而不是怎么实现的。另外上下文管理是另一个大项。MCP 工具返回的内容经常很大比如read_file读一个 2000 行的源码文件全部塞进上下文既浪费又容易把更关键的信息顶掉。我做了两层处理一是结果截断默认每个工具结果最多保留 4000 字符超出部分在末尾标注已截断请用 read_file 的 range 参数分段读取二是摘要提示词对于特别大的返回结果先让模型输出一个摘要再决定是否深入。这两层处理配合上之前 GUI 树压缩让整个对话的 token 消耗始终处于可控范围。5. 落地实测与踩坑复盘5.1 三个真实任务的表现我挑三个典型任务来说不吹效果只说真实数据。任务一GUI 表单批量录入。客户有一套老旧的物资管理系统新增入库记录要在 15 个文本框里填数据每天几十条。我用代理跑了一遍模型先扫描窗口拿到控件树然后我给它一份 CSV 数据它逐条调用input填入表单每填完一条点一次保存再用wait_until等保存成功的提示框出现。10 条数据全部成功实测用时约 12 分钟其中大部分时间花在等待模型推理上。换成人工操作也就是 5 分钟的事——但模型是自动的挂在后台运行就行。这个任务的启示是人工 5 分钟和模型 12 分钟的价值差异不在速度在于人工必须坐在屏幕前模型不用。任务二Bug 复现 修复。测试报了一个问题软件启动后在配置界面切换主题部分界面文字变成不可见。传统流程是我得手动重现一次截图再读代码猜。这次我把代理接上 GUI 操控和文件系统 MCP让它自己打开软件、切换到深色主题、截图、比对控件树的颜色属性变化、然后去源码里找主题样式相关代码。它定位到是一处硬编码的浅色文字颜色没适配深色主题然后给出了修改建议。整个链路跑通了但后半段代码修复部分它改得不够严谨我 review 时发现了边界遗漏。结论是它能做完整的侦察-复现-初步修复流水线但最终拍板还得靠人。任务三MCP 驱动的逆向分析。用 IDA MCP 分析一个可疑的二进制函数。模型自动调用了get_function、list_xrefs、decompile等工具最后生成了包含调用关系分析、可疑模式识别的小报告。这个任务的亮点是模型全程没有接触 GUI纯粹通过 MCP 驱动调试器体现了两条能力通道的互补性。GUI 通道适合看得见的操作MCP 通道适合逻辑化的工具调用两者在同一个 Agent 里共存毫无违和感。5.2 踩坑记录从树遍历超时到上下文爆炸我按踩坑的典型性排个序分享最有价值的几个。坑一UIA 树遍历导致进程卡死。某些软件的 UIA 实现有严重的递归问题访问一个节点的子节点时会触发它内部的延迟加载导致遍历速度极慢整个代理像死了一样。我后来给快照加了两道保险一是深度限制默认只扫 8 层二是节点数上限到 500 个节点就停止遍历。宁可信息不全不能把主进程卡死。信息不够怎么办加了一个expand_node工具让模型按需展开特定控件树分支。坑二模型反复点同一个按钮的循环。有一次让它在旧软件里等一个弹窗弹窗没出来它就一遍遍地点击同一个触发按钮直到我自己看不下去手动终止。后来我给每个动作加了一个动作历史字段模型能看到这个按钮在近 5 轮内已经被点过两次并被告知如果动作重复且界面未变化请换一条路径或者输出 task_complete 并描述阻塞原因。这个约束非常有效明显减少了无效循环。坑三上下文爆炸。最初版本在每轮循环里都会追加完整控件树导致第 8 轮左右上下文就满了。我后来改成滑动窗口策略只保留最近三轮的控件树快照加上全部的历史工具调用摘要。模型依然能理解前因后果成本却降了一个数量级。这个优化的核心思想是历史记录可以被摘要替代但当前的界面状态必须原样保留。坑四npx 拉包导致的 MCP 假死。当我用npx -y启动 MCP Server 时第一次运行会联网下载包可能耗时几十秒。如果代理设置的 Server 启动超时太短就会误判 Server 崩溃。我的处理是把初始化握手超时调到了 120 秒并且在配置里提示用户建议先把 npx 包预下载好或者在离线环境直接用预编译的 Server 二进制。这个坑在趁手工具上不显眼一旦你要做成给别人用的产品就是第一大挫败来源。5.3 性能与成本实测数据我测了一组真实数据供大家参考。环境Windows 11 本地 Ollamaqwen2.5-coder:14b和云端 OpenAI gpt-4o-mini任务是前面提到的GUI 表单批量录入 3 条记录模型GUI 快照压缩前 tokens压缩后 tokens总调用轮次总耗时成功率gpt-4o-mini约 9.8k3.1k214 分 30 秒90%qwen2.5-coder:14b约 9.8k3.1k236 分 12 秒83%可以看到模型本身有差异但压缩带来的收益对所有模型一致——每轮调用省掉约三分之二的面板开销。本地模型虽然便宜但复杂 GUI 任务的推理能力确实差一点主要体现在它对控件名语义的理解不够精准偶尔会把添加按钮点成新增。如果你的场景是生产级建议至少用中等规模以上的云端模型。另一个成本参考完成一个 15 步的 GUI 自动化任务云端模型端到端大约消耗 3-4 万 tokens折合人民币不到一块钱。相比人工盯着屏幕操作这个成本完全可以忽略。5.4 后续扩展方向写完第一版之后我最想加的几个功能按优先级排序一是截图-语义混合模式。纯 UIA 对自绘界面无能为力纯截图又脆弱。最理想的状态是默认用语义树驱动遇到不可解析的画布区域自动截取局部图片让模型以视觉方式理解画布内容再做操作。这实际上是语义树 视觉模型的混合控制也是我认为 GUI 自动化最高性价比的终局方案。二是多任务编排。目前一次只能跑一个任务闭环下一步想做一个任务队列用户给定一串任务代理依次执行遇到失败的重试两到三次并在最终汇总一份报告。三是MCP Server 的插件管理器。虽然单文件本身很轻但管理多台机器的 Server 配置还是麻烦。我设想在配置里增加一个registry字段指向一份 Server 清单 URL机器上的代理拉取后自动生成配置、检查版本、预下载二进制。这样单文件分发的代理 远程管理的工具集部署体验就完整了。这个项目做下来我最深的体会是AI 编码代理的竞争力不在模型本身而在模型与真实世界的接口数量和质量。模型负责思考而 GUI 适配器负责给模型一双能看见桌面软件的眼睛MCP 负责给模型一副能触达所有工程工具的双手。单文件则决定了这套能力能不能被毫无负担地分发到任何一台需要它的机器上——这一点恰恰是很多同类项目最容易忽视的。如果你最近也在做 Agent 相关的项目或者正在被桌面 GUI 自动化折磨可以试试我这个思路。尤其是 MCP 那部分哪怕不用我的代理只把它当作一个参考实现来学习协议细节也完全够用。我后面会继续把截图混合模式做出来到时候再来更新这一篇的使用体验。