让 AI Agent 不再‘自称完成’：用 Reticle 验证真实运行中的应用
AI 编码 Agent 写完代码后，常见的“完成”依据是测试通过、编译成功，或者 Agent 自己说任务已完成。但这些信号未必代表用户真正使用的流程正常：按钮可能没有触发请求，登录后页面状态可能不对，浏览器控制台也可能藏着错误。Reticle 的思路是把验证对象从代码差异转向正在运行的应用：让 Agent 驱动真实页面、观察发生的行为，再给出带证据的判断。
它验证的是什么
Reticle 将自己接入本地开发应用，并通过 MCP 向编码 Agent 提供工具。Agent 可以操作应用、读取 DOM、网络请求、控制台和应用状态，再根据任务描述判断预期是否成立。结果不是简单的“成功/失败”：项目 README 描述了 pass、fail 和 cannot tell 三种 verdict，并附上证据以及可定位的 file:line。cannot tell 很重要——证据不足时不应伪装成通过。
这与单元测试并不冲突。单测适合验证纯函数和边界条件；端到端测试适合固定、可重复的用户路径；Reticle 更适合在 Agent 改动后用自然语言检查真实运行时行为，并把观察结果反馈给 Agent继续修复。它也不是安全扫描器或完整无障碍审计的替代品，官方 README 明确建议与专门工具配合使用。
从安装到验证
项目要求 Node.js 20.11 或更新版本。Claude Code 用户可按仓库 README 使用插件安装；其他支持 MCP 的 Agent 可通过官方安装脚本，或使用 npm 全局安装并登记 MCP：
npm install -g @reticlehq/server reticle setup mcp
随后在应用目录初始化项目集成：
cd path/to/your-app reticle init
初始化会检测框架并配置开发环境所需的连接组件。它会修改项目配置，因此应先查看变更，并在已有开发服务器的情况下重启服务。项目还提供预览选项：
reticle init --dry-run
完成集成后，启动本地应用，在 Agent 对话中描述要验证的行为，例如：“验证登录后是否进入仪表盘；如果失败，指出证据和需要修复的文件行。”按官方示例，也可以用 CLI 对本地页面执行结构化断言：
reticle verify http://localhost:5173 --expect '{"kind":"element","query":{"role":"heading","name":"Welcome"},"state":"visible"}'
这里的端口和断言应替换为应用实际地址及目标状态。返回 verified: "yes"、"no" 或 "unknown" 时，应同时检查证据；unknown 表示无法判断，不是通过。具体支持的框架和安装细节应以官方文档的 proven 状态为准。
适合的工作流与边界
比较实用的方式是把验证放在实现之后、提交之前：先要求 Agent 完成功能，再让它用 Reticle 重放关键场景；失败时让它依据网络响应、页面状态和定位信息修复，然后对同一场景复验。对登录、结账、表单提交等用户路径，保存可重复运行的流程还可帮助发现后续改动引入的回归。
但验证质量仍取决于目标描述。诸如“页面看起来正常”难以形成可证伪的条件；“提交有效邮箱后，页面显示欢迎标题且网络请求返回成功”更容易检查。也要区分开发与生产环境：README 说明连接组件面向开发构建，生产构建会移除相关能力，并带有运行时保护。初始化前应审查项目变更，避免把开发辅助集成误当作部署配置。
Reticle 的价值不在于让 Agent 获得绝对正确性，而是缩短“代码改了—真实应用表现如何—该改哪一行”的反馈链路。若团队已经有成熟的浏览器测试，它可以作为 Agent 协作层的补充；若目前只依赖模型口头确认或编译结果，它则提供了更接近用户实际体验的一道验证门。