AI 编码 Agent 写完就说成功？用 Reticle 验证真实运行中的应用
AI 编码 Agent 能快速修改代码，却未必知道修改是否真的生效。它可能看到构建通过就宣布完成，但浏览器里的按钮仍然无响应、请求返回了 500，或页面状态与预期不符。单靠“再检查一下”的提示词，验证责任仍在模型自己身上。
Reticle 的思路是让 Agent 操作正在运行的应用，并从应用内部读取证据。它通过 MCP 向编码 Agent 提供观察、操作和断言工具，能把一次交互关联到网络请求、应用状态、控制台信息及源码位置，最终给出通过、失败或无法判定的结果。它不只是截屏：项目说明还强调，只有明确的通过结果才算成功；无法判定不会悄悄显示为绿色。
不是再造一个截图测试器
Reticle 的验证对象是本地运行中的 Web 或桌面应用。其开发期 SDK 与应用连接后，Agent 可以驱动真实界面，再检查点击引起的请求、状态变化和控制台错误。这样做的重点是把“我改了代码”与“运行时确实呈现预期行为”分开。
举例来说，修复结账按钮后，Agent 不应只检查组件代码或截图，而应触发真实点击，核对是否发出正确请求、订单状态是否变化，并查看控制台有没有异常。Reticle 返回的 verdict 会附带相关证据和可定位的 file:line，让开发者知道失败发生在哪里。
它还支持把验证过的交互保存为 flow。项目文档描述，flow 会以 JSON 文件保存在 .reticle/flows/，按可读语义锚点重放，而不是依赖易变的屏幕坐标。后续重放不需要 AI 模型参与，因此可以把稳定路径纳入回归检查；项目也提供 reticle gate，用于在改动触及已保存 flow 相关代码、但没有新的通过运行时阻止变更。
从安装到第一次验证
项目提供 CLI 与 MCP server。对于已有本地 Web 应用的开发者，快速开始的基本流程是安装并将 Reticle 接入应用，再让编码 Agent 连接正在运行的开发服务器。官方 quickstart 要求 Node.js 20.11 或更高版本；支持 Claude Code、Cursor、Codex、Windsurf、VS Code 等 MCP 客户端。实际适配范围应以框架文档为准，不要仅凭客户端兼容列表假定任意应用都无需配置。
npm install -g @reticlehq/server reticle setup mcp cd path/to/your-app reticle init reticle status
reticle init 会检查项目并写入开发期集成所需配置；如果开发服务器在初始化之前已启动，官方指南提醒重启服务器并重新加载页面。之后通过 MCP 让 Agent 驱动一个明确场景，例如提交表单后检查请求与页面反馈。先从单个关键路径开始，比一开始要求它验证整套应用更容易定位集成问题。
需要保存可重复的用户旅程时，可以让 Agent 记录一次成功流程并保存为 flow，再在代码变更后重放。团队可将 .reticle/ 中的流程作为普通文件评审，检查测试覆盖的意图是否合理；对关键行为还应由开发者确认断言确实对应业务要求，而不是只验证“页面没有报错”。
运行时证据也有边界
Reticle 将 SDK 放在开发构建中，并通过本机回环地址连接；项目声明生产构建不包含该 SDK。仓库许可证按包区分：SDK、核心和引擎为 Apache-2.0，而 @reticlehq/server、@reticlehq/init、@reticlehq/test 包采用 FSL-1.1-ALv2。因此不能笼统地把整个项目称为 Apache-2.0 开源软件；采用前应按实际安装的包阅读其许可证。当前 npm registry 中 server 包版本为 3.7.0，许可证字段同样标注 FSL-1.1-ALv2。
运行时观测也不等于完整的端到端质量保证。Agent 仍可能设计出错误断言，测试数据未必覆盖真实用户差异；支付、权限变更等高风险流程不能只靠自动化 verdict 放行。应把 Reticle 当作帮助 Agent 获取可检查证据的验证层，再结合单元测试、集成测试、人工审批和最小权限策略。
如果团队经常遇到 Agent 改完代码却不启动应用验证，Reticle 值得在一个本地开发流程中试用：先选一个可观测、可重复的用户动作，定义成功条件，再确认 verdict 引用的请求、状态和源码位置确实支持结论。它的价值不在于替人保证正确，而在于让“我测过了”变成可以复核的运行时证据。