既然网页结构老变，我就用视觉 Agent 做了个“看一眼就修好”的系统。今天对着屏幕模拟了一个滑动的物理动作，不是用手，是用代码。这套东西跑起来的时候，我盯着屏幕，感觉就像在指挥一个看不见的幽灵，它盯着 DOM 树，也盯着像素。
十年前我写爬虫，那叫一个苦。XPath 写得再精妙，人家前端框架一升级，整个 div 结构全变，selector 全废。半夜三点被报警短信吵醒，爬起来改代码，那种感觉就像在跟一个看不见的对手打游击。后来学聪明了，用多线程、用代理池、甚至模拟浏览器渲染，但核心问题没变：你的逻辑是建立在对方代码结构上的，人家一变，你就得跪。API 频率限制、验证码、人机检测，每一关都是成本。那时候觉得，技术栈就是护城河，会 selenium 和 puppeteer 就是人上人。
现在回头看，全是体力活。ChatGPT 出来那阵子，我恐慌了整整三个月。我引以为傲的那些“自动化脚本”、“智能解析”，在大模型面前像纸糊的一样。不是它们不能用了，是性价比被彻底打穿了。你吭哧吭哧写两百行正则和异常处理，GPT-4 用几行提示词可能就解决了八成问题。这种降维打击，逼着你必须换赛道。
所以去年我死磕视觉这一块。传统 RPA 还是太“硬”了，它记录的是坐标、是控件 ID。网页稍微改个布局，按钮位置挪动几个像素，整个流程就崩了。我要的是“软”的，是让 AI 像人一样“看”屏幕，然后自己决定要做什么。这套自愈系统的核心就两点：第一，用多模态模型（我主要用 GPT-4V 的 API）实时截图，理解屏幕上的元素和它们的语义关系，比如“那个蓝色的、写着‘提交’的按钮在登录框下面”。第二，用一套决策逻辑，把这种视觉描述翻译成自动化操作指令，比如 `click_element(description=“蓝色提交按钮”)`，或者 `scroll_until_visible(description=“查看更多评论”)`。
最难的不是调用 API，是设计那个“决策逻辑”。你不能每步都让大模型看图说话，那太慢太贵了。我的做法是分层：常规操作，用固化脚本；一旦脚本执行失败（比如找不到元素），立刻触发“视觉救援模式”。系统会截取当前屏幕和错误区域的局部放大图，喂给视觉 Agent，问它：“目标按钮可能变成了什么样子？或者在哪里？” Agent 返回它的“理解”，比如“按钮颜色变成了绿色，文字改成了‘确认提交’，位于屏幕右侧栏”。然后，系统会用这个新的描述去尝试操作，同时自动把这条新描述和对应的成功操作，作为一个“补丁”记录到知识库里。下次再遇到同类页面，优先匹配知识库里的补丁。
这就实现了“看一眼就修好”。网页结构变了，我不需要去分析它的新 DOM，不需要重新写 XPath。我的系统会自己发现不对劲，自己“看”一眼，自己找到新路，并且记住这条路。这感觉，就像给爬虫或者自动化脚本装上了眼睛和一个小脑。
搞这套东西，我封装了一个本地服务，用 n8n 做流程调度和异常处理的中枢。n8n 那个可视化界面，连异常分支都画得清清楚楚，哪里触发了视觉救援，救援结果是什么，一目了然。这比当年在命令行看日志，或者自己写简陋的监控后台，不知道高到哪里去了。
视觉理解，真的成了我这个个体开发者的终极外挂。它把我和那些永远在变的前端代码解耦了。我不再关心你是 React 还是 Vue，是 SSR 还是 CSR。我只关心屏幕这个最终的“像素平面”上呈现了什么。这是一种思维的转变：从“逆向工程你的代码结构”，到“直接理解你的输出结果”。技术为了达成目标，正在变得越来越“直接”，越来越像人的本能。这很可怕，也很迷人。
下一步，我打算让这个视觉 Agent 更“贪心”一点。不仅修复，还能主动发现新的、可自动化的流程点。比如它浏览一个后台，可能会自己识别出“哦，这里每天都要重复导出报表，我可以帮你做掉”。那时候，我就从修理工，变成挖掘工了。焦虑永远在，但方向终于清晰了。
