本文首发于 note.sichenai.cc，原文链接：https://note.sichenai.cc/articles/ai-browser-two-channels，作者：斯晨

---

概览

先交代任务：我想给自己的网站加一条全自动数据管线，需要在网页上完成四件事，建一个 GitHub 私有仓库、在 Cloudflare 创建一个 API 令牌、把三个密钥填进仓库设置、点一下流水线的运行按钮。这些平台的接口权限我没开，所以决定让 AI 直接替我操作网页。

这件事最终办成了，全程大约半小时。但中间的过程值得全说：AI 换过两条浏览器通道，第一条通道三次把任务推进到九成后原地清零，第二条通道一把跑通。把两条通道的表现摊开对比，比任何「浏览器自动化入门教程」都更能说明这类任务的坑在哪。

此前写过两篇：一篇摸清了工具的模式边界（headless 与 headed），一篇解决了登录态复用。这一篇回答的是再往下的问题：有多条通道可选时选哪条、故障发生在哪一层、哪些环节留给人。

通道一：内嵌浏览器，三次推进到九成然后清零

第一条通道是 Zcode 内置的应用内浏览器。它的优点很真实：和助手会话绑定、即开即用、和我的日常浏览完全隔离。前几步它走得也很顺，登录态正常、页面能读、按钮能点，GitHub 的仓库创建成功，Cloudflare 的登录也一次通过。

然后开始出事。同一类怪象反复出现：任务推进到八九成时，标签页会静默变成空白页，或者冒出一个早先访问过的「幽灵标签」，刚才操作的页面内容凭空消失。最诡异的两次，页面内容读得好好的，一轮操作之后地址栏还在原页，内容却换成了几十分钟前的旧页面。

三次都是同一个模式：走到九成，清零，从头再来。

这里要先诚实地标注：「为什么会清零」是推断，不是实证。我能实证的只有现象（标签静默重置、内容回退、截图通道超时，全程无任何报错提示）；归因到「重交互页面把内嵌浏览器渲染进程压崩」是我的推测，样本只有 Cloudflare 控制台和 GitHub Actions 两个页面，不排除设备内存压力等其他因素。但对使用者来说，归因不重要，处置才重要：这类故障出在渲染层，修不了，只能换通道。

通道二：真机浏览器加无障碍点击，全程零失败

第二条通道是真机 Chrome。AI 不靠屏幕截图认按钮，而是读页面的无障碍树，直接对「创建令牌」这样的语义元素发起点击。

效果差异一眼可见：之前在通道一反复失败的页面上，这条路的每次点击都精准命中，包括那些折叠面板、标签页切换、下拉展开。整个过程里它还不需要把浏览器抢到前台，我在旁边干别的事不受影响。

真机通道的代价也要说清楚。第一，它和我的日常浏览共用一个浏览器，AI 切标签页会动我的工作现场，需要事先约定「用完还原」；第二，它操作的是登录态齐全的真实环境，权限边界必须在任务里写死，比如「这几个标签不许碰」。隔离性上，内嵌浏览器反而更好。两条通道的对照大致是：

维度	内嵌浏览器	真机浏览器 + 无障碍点击
稳定性	重交互页面上反复静默重置（实证现象，归因推断）	全程零失败
点击方式	语义点击可用，但受渲染层崩溃拖累	语义点击全程无失误
隔离性	与个人浏览完全隔离	与日常浏览共用，需约定边界
适用任务	轻量页面、独立验证	一切正经任务

最硬的一根骨头：反自动化的下拉框

两条通道都卡过同一处：Cloudflare 建令牌页的账户选择下拉框。

这个下拉框不是网页原生的控件，是自绘组件。AI 用语义点击点它，菜单纹丝不动；普通程序点击又会被页面的遮挡判定拦下来。最后解法是把一个「人手点击」拆开模拟：真实的手指按下一个键，物理上会依次产生按下、抬起等一整套指针事件，模拟环境默认只发最后一个「点击」事件，自绘组件恰恰只认前面那几步。把整串事件按顺序补齐，菜单就开了。

这个案例的价值在于归因清楚：困难出在交互层（组件作者只为真人的手指设计），和通道无关、和网络无关。同一套补法，两条通道通用。

顺带一提同类问题的另一个层面：还有一次失败发生在网络层，脚本身份被镜像服务的风控识别，请求被甩回无法访问的源站，换成命令行下载工具就通了。风控认的是请求特征，这属于另一个话题，本文只记现象和归因，不展开细节。

三层失败模型：AI 点网页的故障都逃不出这张表

把当天所有卡壳归拢，我会用这张表做故障定位：

层	典型现象	当天实例	处置
传输层	请求超时、被风控分流、访问被拒	镜像下载被甩回源站；接口无权限返回 401	换工具或换通道；有 API 就绝不上浏览器
渲染层	页面静默重置、内容回退、截图通道失灵	内嵌浏览器三次清零	换通道，不要试图修通道
交互层	按钮点不动、菜单打不开、元素找不到	自绘下拉对普通点击免疫	模拟完整指针事件序列；再不行人上

对应的通道选择顺序也从中长出来：有 API 先用 API；没 API 才开浏览器；开浏览器先走语义点击；自绘组件上事件序列；都不行，人接手。

哪些活交给 AI，哪些留给人

这次任务最省时间的决定，是我中途接管了那个下拉框，10 秒点完，把其余十几个标准表单和按钮全部留给 AI。事后看，分工边界很清楚：

交给 AI 的：标准表单、批量重复操作、有明确成功判据的流程（比如「提交后列表里出现这一条」）、不需要现场判断的流水线。

留给人的：反自动化设计的控件、涉及钱和权限的最终确认、验证码，以及所有「点错代价高」的按钮。

AI 操作网页这件事，当下的最优解不是全自动，是「AI 跑流水线 + 人守关键闸口」。我用十分钟配置的这套分工，让后续每周的数据更新完全无人值守，而人只在最初那一次碰了两个反自动化的控件。

诚实的边界

三条：样本只有一天、两个平台、一条任务流，结论的置信度建立在「现象全部留有原文记录」上，不建立在样本量上；内嵌浏览器的崩溃归因是推测，已在上文标注；工具迭代很快，文中通道能力对照的是 2026-09-14 的状态，读到这里时的最新版本可能已经修复了其中一些问题。

数据来源与视角标注

• 实测环境：macOS + 大陆网络；智能体为 Zcode 桌面端（内置应用内浏览器通道 + 真机 Chrome 无障碍通道）；任务为真实部署流程非演示
• 全程操作记录、报错原文（含静默重置前后的页面状态）留档于项目 git 提交链，本文现象描述均可回溯
• 视角与边界：本文是单用户单日任务的通道对比，不构成对任何浏览器产品的评测；涉及的平台风控仅记录归因观察，不含也不需要任何绕过手段