用 agent-browser 打通 Slate v2 iOS 模拟器 Safari 证明链：一次诚实的移动端 IME 验证 Spike 记录-平芜编程栈

用 agent-browser 打通 Slate v2 iOS 模拟器 Safari 证明链：一次诚实的移动端 IME 验证 Spike 记录

【免费下载链接】plateRich-text editor with AI and shadcn/ui项目地址: https://gitcode.com/GitHub_Trending/pl/plate

导读

本文围绕docs/plans/2026-04-11-slate-browser-agent-browser-ios-setup-proof.md记录的一次最小化、可复现的 iOS Simulator Safari 自动化证明实验展开：在本地运行 Slate v2 示例页的前提下，使用agent-browser打开 iOS 模拟器中的 Safari、解析路由、抓取可交互控件快照，以此验证"移动端浏览器传输层"是否真实可用。读完本文，你将掌握这套pnpm proof:agent-browser:ios:*证明命令的用途与手动执行流程，理解为什么本次 spike 结论是"传输真实、行为仍红"，以及为什么最终证明路线要从agent-browser转向直接 Appium iOS Safari。

为什么把 iOS Simulator Safari 放在最前面

该证明文档开篇就明确了选题优先级（对应原文档Why This First一节），核心理由有三条：

agent-browser已经能在本地打开 iOS 模拟器里的 Safari，说明存在一条可走的自动化入口，不必从零搭建；
iOS Simulator Safari 比桌面端模拟更接近移动 Web 的真实环境，尤其是对 IME（输入法）行为验证而言，桌面 Chromium 的自动化结果不能替代真实移动浏览器的组合输入语义；
它是比agent-device更合适的当下移动浏览器 spike 对象——agent-device面向 App/设备级自动化，而当前阶段只需要先证明"浏览器传输"这一步。

需要说明的是：本次实验发生在独立的slate-v2仓库中（该证明文档 frontmatter 的source_repos记录了plate-2、slate-v2、agent-browser三个仓库），而当前 plate 仓库中的 docs/plans/2026-04-11-slate-v2-ime-mobile-browser-file-ledger.md 等计划文档完整记录了这批证明行的演进过程，可作为本实验的横向佐证。

这次 spike 证明了什么

实验以本地运行的 Slate v2 示例页http://localhost:3100为目标，具体验证动作与结果如下（对应原文档What Was Proved）：

步骤	动作	结果
1	`agent-browser`打开 iOS Simulator Safari，访问本地 placeholder IME 示例（带`?debug=1`）	成功打开
2	`agent-browser`返回解析后的 URL	成功返回
3	`agent-browser snapshot -i`抓取交互控件	返回了可操作的控件列表：`Undo`、`Redo`、`Copy JSON`、`Copy Artifact`以及文本框（textbox）

围绕这三步，可以得出两个阶段性的、诚实的结论：

iOS Simulator Safari 传输层是真实的——agent-browser确实能够驱动模拟器浏览器访问本地 Slate 示例；
当前 IME 调试面在该传输上可达——snapshot -i能枚举出 placeholder 示例暴露的调试控件（撤销/重做/复制 JSON/复制产物），说明?debug=1调试面已经在移动浏览器里渲染出来了；
这个 spike 值得被正式化——它不是偶然的手工操作，而是可以被命令化的证明路径。

关于?debug=1调试面，docs/plans/2026-04-11-slate-v2-ime-mobile-browser-file-ledger.md 中有更详细的描述：IME 调试覆盖层（debug overlay）会通过?debug=1输出 Slate selection、DOM selection、placeholder shape、事件流和 HTML 快照，这正是snapshot -i能抓到丰富控件信息的基础。

现在能干净地断言什么

原文档What Is Proved Cleanly Now一节给出了明确的证据边界：

历史性的 setup/open 证明已经存在，入口是pnpm proof:agent-browser:ios:local这条打包命令；
iOS provider 在原理上是一个真实可用的传输层。

但同一节也给出了一个必须记住的反向结论：在当前 plate 仓库对应的本地 Slate 示例路由上，不要依赖现有的agent-browseriOS provider 做选择器级证明。原因很具体：

它能打开 URL，但经常只暴露 Next 的 shell/文档脚手架，而不是真正挂载好的示例编辑器；
这导致在这些路由上做基于选择器（selector）的断言不可信；
对于这些本地路由，直接 Appium iOS Safari 反而是更合适的 setup 传输层。

换句话说：这个文档记录的不只是"成功"，而是"成功打开 + 断言不可信"的混合状态，这是证明程序中非常重要的诚实边界。

新增的操作面：四条 proof 命令

在slate-v2仓库中，本次 spike 新增了四条打包证明命令（对应原文档Added Operator Surface）：

pnpm proof:agent-browser:ios:local
pnpm proof:agent-browser:ios:placeholder-input:local
pnpm proof:agent-browser:ios:inline-edge-input:local
pnpm proof:agent-browser:ios:void-edge-input:local

这些命令假设本地服务器已经在运行，其执行流程固定为四步：

在 iOS Simulator Safari 中打开指定的示例；
打印解析后的 URL；
打印一份初始的交互式快照（interactive snapshot）；
如有需要，交给人工进行手动交互。

默认目标路由是placeholder?debug=1。从 docs/plans/2026-04-11-slate-v2-ime-mobile-browser-file-ledger.md 可以看到，这四条命令分别对应 placeholder IME、inline-edge IME、void-edge IME 三个核心场景行，属于整个 IME/mobile/browser 证明矩阵在 iOS 方向的打包入口。

手动复现步骤与可选覆盖参数

原文档Manual Setup给出了完整的两步复现流程。

第一步：先启动本地站点（在slate-v2仓库目录下）：

cd /Users/zbeyens/git/slate-v2 PORT=3100 pnpm serve

第二步：另开一个终端执行证明命令：

cd /Users/zbeyens/git/slate-v2 pnpm proof:agent-browser:ios:local

可选覆盖参数

原文档还提供了三个可覆盖的环境变量与直接调用底层脚本的示例：

AGENT_BROWSER_IOS_DEVICE="iPhone 17 Pro" \ AGENT_BROWSER_DEBUG_QUERY="debug=1" \ bash ./scripts/proof-agent-browser-ios-local.sh 3100 placeholder

参数说明：

参数	含义	示例值
`AGENT_BROWSER_IOS_DEVICE`	指定 iOS 模拟器设备型号	`"iPhone 17 Pro"`
`AGENT_BROWSER_DEBUG_QUERY`	附加到路由上的调试查询串	`"debug=1"`
脚本位置参数`3100`	本地服务端口	`3100`
脚本位置参数`placeholder`	目标示例名	`placeholder`/`inline-edge`/`void-edge`等

这种方式把"设备型号、调试参数、端口、示例路由"解耦成可配置项，便于在同一套脚本下快速切换不同示例做横向验证。

诚实的当前结论：够用，但不够宣称

原文档Current Take对本次 spike 给出了精确的边界判断：

足够支撑的：本次结果足以作为下一步传输架构工作的依据。

不能宣称的（三个明确红线）：

不能宣称已有稳定的 iOS 自动化证明通道；
不能宣称已有稳定的输入后产物捕获（post-input artifact capture）；
不能宣称iOS 上 IME 完全对齐（full IME parity）。

这三点红线与 docs/plans/2026-04-11-slate-v2-ime-mobile-browser-file-ledger.md 中记录的 iOS 行状态完全一致：在文件台账里，placeholder 与 no-FEFF placeholder 两行被标记为"setup-green / behavior-red"（即能打开页面、但输入行为断言仍红），而 inline-edge 与 void-edge 行则是直接绿色。这说明本次 spike 的"打开成功"与"输入行为证明成功"是两个必须严格区分的事实。

后续发现：问题在工具侧，不在页面侧

原文档Follow-On Finding给出了本次 spike 最重要的诊断结论：当前本地问题大概率是工具侧（tool-side）问题，而不是页面侧（page-side）问题。

证据链非常清晰：

agent-browser -p ios能够打开本地路由；
但批量执行click #placeholder-ime/type #placeholder-ime ...可能失败，因为挂载后的编辑器节点从未出现在 DOM 中（它只渲染出了 Next 的 shell 文档）；
在同一台机器上，直接使用 Appium iOS Safari 加载完全相同的路由，可以读到真实的编辑器 HTML。

也就是说，两条工具链面对同一路由时行为不一致：agent-browser看不到挂载的编辑器节点，Appium 能看到。文档还记录了该问题的上游跟踪项：vercel-labs/agent-browser仓库的 issue #1221（本文按规范不展开外部链接，读者可在该仓库中检索该编号）。该问题的完整影响面在 docs/plans/2026-04-11-slate-v2-ime-mobile-browser-file-ledger.md 的 iOS Safari 行有补充描述：agent-browseriOS provider 在这些路由上"经常只暴露 Next shell 而没有编辑器节点"，因此不应被当作行为证据。

定位与分类

结合文件台账中的证据分级，可以把这个发现归类为：

传输真实：agent-browser能打开 iOS Simulator Safari 并访问本地路由（setup-green）；
行为不可信：在挂载节点缺失的前提下，任何基于选择器的点击/输入断言都不可信（behavior-red / 工具侧阻塞）；
已知阻塞：在vercel-labs/agent-browser#1221修复之前，该传输对本地 Slate 路由应视为已知工具侧阻塞，不应再作为本证明程序的默认 iOS setup 通道。

下一个诚实步骤：转向直接 Appium iOS Safari

原文档Next Honest Step给出了明确的后续路线：

在本地路由的 setup 真实性上，改用直接 Appium iOS Safari。

agent-browseriOS 通道降级为上游 bug 参考，保留到以下两个条件满足为止：

路由打开后，挂载的编辑器节点稳定出现；
选择器动作能作用于真实页面而不是 shell 文档。

这条转向路线不是凭空拍板，而是有同级证据支撑的。参见同目录下的 docs/plans/2026-04-11-appium-android-setup-proof.md：在 Android 侧，Appium +uiautomator2驱动已经证明能够创建真实的 Chrome 会话、导航到本地 Slate 示例（http://10.0.2.2:3100/examples/placeholder?debug=1）并读回页面内容，且通过"先点击编辑器根节点 → 把 DOM 选择折叠到前导零宽文本叶 → 再发送文本输入并读回调试覆盖层"这套可复用原语，解锁了 placeholder / inline-edge / void-edge 三行的直接证明。同样的"直接 Appium 作为 setup 真相源"思路正在被复制到 iOS 方向。

从整体架构看，这次 spike 的结论也直接喂给了 docs/plans/2026-04-11-slate-browser-transport-architecture-plan.md：该计划明确将浏览器移动端传输层排序为Playwright 桌面/浏览器 → Appium Android Chrome →agent-browseriOS Simulator Safari，并且强调"不要试图让各传输层看起来对称"——本次 iOS spike 恰恰证明了这一点：agent-browser与 Appium 在同一路由上表现不同，强行对称抽象只会污染证明核心。

从本次 spike 中可以沉淀的方法论

把这份证明文档放在整个浏览器移动端证明体系里看，可以沉淀出几条对测试工程有普适价值的经验：

"能打开页面"和"能断言行为"是两件事。本次 spike 中agent-browser打开成功但选择器断言失败，说明 setup 证明与行为证明必须分开分级（对应文件台账里的setup-green / behavior-red分级法）。
工具链差异必须在同一路由上直接对比。agent-browser与 Appium 在同一台机器、同一路由上结果不同，这种对比才是定位"工具侧 vs 页面侧"问题的正确姿势。
证明程序要保留"反向结论"。文档没有只写成功，而是把"哪些结论现在还不能宣称"明确列为红线，避免后续程序被过度的乐观预期带偏。
已知阻塞要显式标记并给出上游跟踪项。将vercel-labs/agent-browser#1221作为已知工具侧阻塞记录在案，而不是默默绕过，保证了证明链的可追溯性。