Iris让AI编码代理看见运行中的Web应用

如果你用过 AI 编码助手写前端代码，大概遇到过这样的尴尬：AI 生成的组件看上去没问题，但实际渲染后布局全乱；或是一个 API 调用没生效，AI 却毫不知情。传统思路是让 AI 截图分析，但截图既耗 token 又缺乏结构化信息——它看不懂控制台报错，也抓不住具体的 DOM 节点。

Iris 就是为解决这个问题来的。它是一个开源工具，基于 MCP（Model Context Protocol），可以看作给 AI 编码代理装了一双“眼睛”，让它直接“看”到你的 Web 应用里正在发生什么——API 调用了没有、DOM 变更了什么、控制台有没有报错、路由跳转是否正确。而且它不是用截图，是用确定性的断言（assertions）来验证，有效且高效。

为什么截图不够好？

AI 编码代理（比如 Cursor、GitHub Copilot 的 agent 模式）要理解运行中的应用状态，以往的解决方案是截一张全页面快照，然后把图片喂给模型。但一张截图可能包含大量无关信息，而且视觉模型识别 UI 元素后还需要推理，token 消耗巨大，反馈也慢。Iris 的做法更聪明：它直接暴露应用内部的结构化状态，以文本形式传给模型。根据官方数据，同等场景下 Iris 消耗的 token 只有全页面快照的 1/73 左右。这点对按 token 付费的开发者尤其友好。

Iris 的核心能力

我粗略试用了一下，Iris 主要围绕这几个场景提供能力：

• 验证 API 调用：AI 代理可以断言某个 API 是否被调用、返回了预期状态码或数据体。不需要再等网络面板截图。
• 监控 DOM 变化：组件渲染后，AI 可以检查特定元素是否存在、样式是否正确、文本内容是否匹配。
• 捕获控制台日志和错误：让 AI 直接看到运行时异常和日志输出，定位 bug 更快。
• 路由检测：在 SPA 应用中验证页面跳转是否符合预期路径。

这些能力通过 MCP 服务器暴露给 AI 代理，只要你的代理支持 MCP 协议（目前主流的几个编辑器扩展都逐渐在支持），就能接入 Iris。设置过程不算复杂，克隆仓库后配置一个 JSON 文件，指定要监控的应用 URL，然后启动代理即可。

典型的使用场景

假设你在用 AI 编码代理重构一个 React 页面的状态管理。你让 AI 把 Redux 替换成 Zustand，并期望某些 API 调用不再发生。传统做法是改完后手动刷新页面、打开 DevTools 检查，或者截一张网络请求图给 AI 分析。有了 Iris，你可以直接写一条断言：“在点击按钮后，确保 /api/old-endpoint 没有被调用”。AI 代理会在运行时实时验证，如果断言失败，它会立即知道并尝试修正代码。这种闭环调试对前端开发者来说相当实用，尤其当你的应用涉及多个异步流程时。

“Iris 不是替代 DevTools，而是把 DevTools 里的结构化信息直接喂给 AI，让它自己消化并决策。”

开源的诚意

Iris 的源码托管在 GitHub 上，采用 MIT 许可证，这意味着你可以自由使用、修改或集成到自己的工具链中。目前项目还很早期，文档比较精简，但核心功能已经跑通。对独立开发者或小团队来说，用 Iris 搭建一个 AI 辅助的自动化测试流程，成本极低——除了自己的服务器或本地环境，没有额外付费。

当然，它也有局限性。比如目前只支持基于 Chrome DevTools Protocol 的应用（也就是 Chromium 系浏览器），对 Safari 或 Firefox 的支持还在规划中。另外，断言语法需要学习一下，不过官方提供了一个简单的 DSL。

实用建议

想尝试 Iris 的开发者，可以这样入手：

• 先在一个简单的单页应用上测试，熟悉如何编写断言。官方示例用的是 React，但理论上任何前端框架都可以。
• 结合你常用的 AI 编码代理（比如 Cursor 或 Continue），看它是否支持 MCP 协议。如果不支持，可以给项目提 issue。
• 不要期望一次就跑通，调试过程中 Iris 自己的日志也会输出到终端，帮你排查连接问题。

总的来说，Iris 让 AI 编码代理从“盲写”变成了“有反馈地写”，这对提升 AI 生成代码的可靠性很有价值。如果你已经在用 AI 辅助前端开发，值得花半小时体验一下。