让 AI Agent 自己跑网页验收还不够：Kery 如何把测试结论变成可复查的浏览器证据
前端改动交给 AI 编程 Agent 后，最难确认的往往不是代码有没有生成，而是页面是否真的仍能完成业务流程。单元测试能覆盖函数，端到端脚本能覆盖预先写好的选择器；可一旦需求是“下单页应清楚展示价格”“登录后的导出入口可用”“移动端没有遮住提交按钮”，团队仍会回到人工打开预览环境、点击、截图、在 PR 里解释。
Kery 是一个 Apache-2.0 开源的浏览器测试项目，试图把这段人工验收链路做成由 Agent 执行、但能够回看证据的流程。它并不把模型的文字回答当作通过条件：测试会驱动真实的 Playwright 浏览器，最后把断言标记为 verified、contradicted 或 not testable，并为可确认或失败的结论保存带标注的截图。对已经大量使用 Claude Code、Cursor 或 Codex 改页面的团队，这个区别很重要：报告不应只有“我检查过了”，还应能指出页面上哪个元素支持或推翻了这一判断。
问题不在于“会不会点”，而在于“结论能否复审”
传统 E2E 自动化强调确定性：工程师写好路径、选择器和断言，CI 重放同一套步骤。它适合稳定且高价值的核心路径，但维护成本会随 UI 重构积累。让 Agent 参与浏览器测试的好处，是可以用自然语言描述意图，并结合页面可访问性树和截图理解变化；风险也同样明显：模型可能把导航过程中的猜测当成事实，或者只因页面没有报错就宣布功能完成。
Kery 的 README 把一次运行拆为五段：先以 BFS 方式扫描应用、建立路由和交互地图；再针对路由或已保存的测试意图生成步骤；随后由 Navigator 在真实浏览器中执行，Review Agent 与 Filmstrip Reviewer 并行观察视觉和 UX 回归；验证阶段再以录制的 trace 判断每条主张。最后，Triage Agent 汇总问题、用历史记录帮助过滤已知误报，并按 visual、functional、UX 等类型输出结果。
关键限制是验证语义。verified 需要看到可观察的页面效果，单靠 Navigator 的自述不算；contradicted 则需要屏幕上的失败证据。截图会标出证据元素，并附上期望与观察结果的说明；项目也会为单次运行保留视频、为单个发现提供片段。这样，评审者可以先看结论，再沿证据回到具体 UI，而不是重新从头复现全部流程。
先在隔离环境试用，而不是直接授权生产站
开源自托管路径的最快入口是 npm 提供的安装向导。向导会询问 LLM 提供商和密钥，生成 docker-compose.yml 并启动服务。仓库文档列出的本地 Dashboard 地址是 http://localhost:11111。若选择不经 Docker 的本地开发方式，README 才明确要求 Node 20+、PostgreSQL 16+ 和 Redis。
npx keryai
若团队更需要检查生成的配置，也可走手动 Docker 路径：复制 .env.example，按实际使用的模型提供商填入至少一个密钥，再启动 Compose。README 明确列出 Anthropic、OpenRouter、OpenAI、Google Gemini，以及自定义 OpenAI 兼容端点；本地模型或网关场景应使用 CUSTOM_LLM_BASE_URL 和对应的模型标识，而不是假定任意供应商参数都通用。
cp .env.example .env docker compose up -d
这里有两个工程边界。第一，浏览器 Agent 能执行登录、OAuth、API token 等认证流程，并不意味着应把生产管理员凭据交给它。先为预览环境准备权限最小化的测试账户，并限制可扫描域名和测试范围。第二，Kery 的结果是对一次浏览器运行和当时环境的证据，不是安全审计或发布批准的替代品。付款、删除、权限变更等高风险动作仍应保留人工批准和独立的服务端检查。
把“验收意图”接到编码 Agent，而非再开一个孤岛
从宽泛需求收敛为可判定的检查
自然语言测试并不等于可以省掉规格。一个可交给浏览器 Agent 的意图至少应明确四件事：谁在操作、从哪个入口开始、执行什么动作、最后在页面上应看到什么。比如“验证优惠券功能”太宽；“以已登录测试用户进入购物车，输入有效优惠码并提交，订单摘要中的折扣行出现且总价减少”才给出了可观察的终态。若流程依赖邮件验证码、第三方支付或异步任务，也要在测试环境提供替身、固定测试数据或明确等待条件，否则 Agent 只能把基础设施的偶发失败误判为产品问题。
对视觉目标尤其要避免只写“看起来正常”。可以将它拆成可讨论的观察项，例如：窄屏宽度下结算按钮仍在首屏可点击；错误提示与输入框同时出现；价格摘要没有被侧栏遮挡。Kery 的截图证据适合帮助人工判断这些目标是否成立，却不应被拿来替代像素级视觉回归基线。涉及品牌排版、复杂动画和跨浏览器兼容性时，仍需搭配固定视口、传统截图对比或人工设计验收。
Kery 提供 MCP 服务端，因此可以从兼容 MCP 的编辑器或 Agent 中触发扫描、运行测试和读取问题。自托管模式下，官方 @keryai/mcp README 给出的配置通过 stdio 启动包，并把 API 与 Dashboard 指向本机服务：
{
"mcpServers": {
"kery": {
"command": "npx",
"args": ["-y", "@keryai/mcp"],
"env": {
"KERY_API_URL": "http://localhost:11111",
"KERY_WEB_URL": "http://localhost:11111"
}
}
}
}
配置完成后，Agent 可使用的并不只是“运行一次测试”。官方工具表把能力分为生命周期、项目、环境、发现、测试、运行、缺陷、覆盖率、记忆和设置等区域。例如，先调用 kery_scan 建立页面与路由视图，再用 kery_list_routes 选择目标；运行后通过 kery_get_bugs 读取证据化的发现，或用 kery_get_coverage 看哪些区域尚未被覆盖。实际集成时应让编码 Agent 把验收意图写得具体：不要说“检查页面正常”，而是说明角色、入口、动作和可见结果。
一个适合 PR 的循环可以是：Agent 实现“购物车数量不能降到 1 以下”后，先针对预览地址扫描；再要求浏览器进入购物车、重复点击减号；最后只在报告中出现可见数量低于 1、错误提示缺失，或有截图证明边界被守住时，才将该项记为已验证。若结果为 not testable，应把它当成待补的测试前置条件——也许缺少测试数据、登录态或稳定的预览服务——而非悄悄当作通过。
成本、波动与测试策略：哪些地方不要过度自动化
Kery 的浏览器导航、路径规划和截图评审都会消耗模型调用；项目支持每次运行的 token 与成本跟踪，也允许为不同角色配置模型。更稳妥的做法不是把每次小改动都交给完整自主探索，而是分层使用：核心付款、登录和权限路径保留传统确定性 E2E；页面视觉、文案反馈和跨页面的新功能路径交给 Kery 做探索性补充；合并前由人复查 contradicted 的截图证据和高严重度问题。
还要防止“测试会学习”被误解为永久正确。项目的 Agent Memory 会记录成功导航路径、已知误报、忽略区域和缺陷模式，并使用衰减式置信度避免记忆无限累积。这能减少重复劳动，但 UI 大改、权限模型调整或测试环境换数据后，都应重新扫描并审视旧记忆是否仍适用。
如果你的团队正陷入“Agent 改得很快、验收仍靠人工”的瓶颈，Kery 值得在预览环境里作为证据层试跑。它的价值不只是再加一个会点网页的模型，而是要求自动化结论留下可定位、可回放、可讨论的浏览器记录。把这一层接入 PR 后，测试输出才更有可能成为工程决策的输入，而不是另一段难以验证的 AI 叙述。
落地时可以从一个风险可控的功能开始：为 PR 准备独立预览地址、固定数据集与最小权限账号；将两三条原本依赖人工点击的验收条件写成明确意图；要求提交者在评审中附上 Kery 的结论和证据链接；连续观察数周后，再决定哪些路径值得沉淀为传统 E2E，哪些仍保留为 Agent 探索。这样的分工能把模型的长处放在理解新页面、发现意外交互和整理证据上，同时避免把不稳定的自然语言判断扩张成不可逆的发布门禁。
当报告与人工观察冲突时，也不要急着把任意一方视为错误。优先检查运行时的代码版本、测试账户角色、缓存与功能开关、网络返回和浏览器录制；再确认测试意图是否足够精确。证据层的作用正是让这种排查有据可循：团队能讨论的是一段具体 trace 和一张截图，而不是“模型似乎说过它已经测完”。