发布时间：2026 年 6 月 22 日
P2ER 是一家数字解决方案机构，它使用 Chrome DevTools for agents 来确保只有经过验证的正常运行的软件才会传递给人工 进行最终审核。通过将其工作流转换为智能体基础架构，他们让 AI 智能体能够执行实证界面验证，从而将部署频率从每周一次提高到每天多次。
挑战：在现有应用中扩大质量
P2ER 为全球品牌（包括汽车制造商、手表品牌和酒店公司）提供高端数字体验。与许多公司一样，他们的主要挑战是在复杂的现有应用中工作。 作为采用智能体编码的团队，他们面临着三大障碍：
- 界面测试脆弱。标准测试套件难以处理动态数据，例如 P2ER 某些项目中的酒店价格波动或季节性优惠。模拟数据通常会隐藏人工测试人员会立即发现的集成缺陷。
- 智能体可靠性问题。如果没有明确的说明，AI 智能体有时会声称任务已完成，但实际上并未验证。
- 丢失上下文。宽泛的任务和模型超时导致智能体无法跟踪会话目标。这使得开发者难以跟踪和继续智能体已开始的工作。
解决方案：打造精益求精的基础架构
P2ER 构建了一个基础架构，将 AI 视为“陪练伙伴”，它还可以处理开发中的重复性方面。这种方法让团队能够专注于架构和创造性问题解决，从而扩大精益求精的规模。
使用 DevTools for agents 的 MCP 服务器强制执行实证验证
为了确保可靠性，P2ER 制定了强制性实证验证规则。
这项工程要求已编入项目的 AGENTS.md 文件中，其中规定：
All claims regarding service availability and component rendering
MUST be empirically verified (log output, dev compiler, browser/devtools inspection)
before asserting to the user.
团队不相信智能体的话，而是使用 Chrome 开发者工具 为智能体提供一个安全的环境，以便以直观且互动的方式浏览应用。
这些“测试智能体”执行了标准静态测试遗漏的几项关键任务：
- 动态数据测试： 即使在预演环境中，智能体也会针对真实、波动的数据（例如不同季节的酒店价格变化）进行测试，以完全像用户一样体验应用。这是通过 DevTools for agents 的互动工具（例如
new_page、navigate_page、fill、click和hover）实现的，这些工具在其github-issue-test技能中调用，让智能体能够动态进行身份验证并模拟真实的用户点击路径。 - 视觉审核： 智能体可以识别 Figma 布局与实际实现之间的视觉差异。通过使用 DevTools for agents 中的
take_screenshot工具，其figma-validate技能可以捕获 Storybook 实时渲染的高分辨率屏幕截图，以便与 Figma 导出进行对照比较。 - 可用性检查： 智能体可以发现自动化脚本经常忽略的缺失的翻译或可用性错误。通过直接与无障碍功能树互动并查看通过
take_snapshot和take_screenshot检索到的视觉快照，智能体会主动扫描界面异常情况（例如 MISSING_MESSAGE 字符串），正如其自动化验证工作流中明确指示的那样。
分解并保留子任务
为了应对会话超时和上下文丢失问题，P2ER 通过子智能体严格划分工作。然后，他们指示智能体充当编排器，如下所示：
Rather than executing everything in the main thread, you must decompose large
or complex objectives into modular subtasks that can be delegated
to specialized subagents.
为了让人工产品负责人了解此过程，团队集成了一项自定义技能，让智能体能够跟踪 GitHub 问题中的工作。这可确保每个子智能体任务及其结果都使用 GitHub API 作为子问题保留和记录，从而创建清晰的审核跟踪记录和持久的上下文，供其他开发者使用。
隔离环境以实现并行执行
为了扩大开发流程，让多个智能体并行运行代码，P2ER 要求智能体为每个任务隔离环境。这可以防止界面验证期间出现状态冲突和网络问题。
此隔离的技术设置包括：
- 隔离的 Git 工作树： 为了防止多个智能体并行操作时发生文件冲突和工作区污染，任务在隔离的 Git 工作树中执行。每个智能体都会获得专用的文件系统空间，其中复制了环境变量并符号链接了依赖项，确保文件更改永远不会相互覆盖。
- 唯一环境： 每个智能体和任务都在唯一的隔离端口上运行其 Next.js 开发服务器。根据其项目规则，服务器
使用
npx next dev -p <custom_port> --turbopack动态启动，以 确保并行执行，而不会发生网络冲突。 - 数据库克隆： 为了防止并行测试期间发生数据冲突，P2ER 在智能体启动时以编程方式将主数据库复制到特定于任务的架构中。智能体完成验证并批准任务后，自动化清理流程会删除隔离的数据库。 此生命周期可确保每个智能体都在原始工作区中运行，并且不会留下任何悬空数据。
- 有针对性的测试： 通过 Chrome 开发者工具 for agents 进行的所有浏览器测试都必须以分配给该特定智能体实例的确切自定义端口为目标。他们的测试要求禁止对默认端口进行硬编码，需要使用测试
目标网址，例如
http://localhost:<custom_port>。
影响：在保持质量的同时，开发速度提高了 10 倍
转向采用高信任防护栏的智能体编码改变了 P2ER 的输出。这些更改最初是为了确保智能体可靠运行，但它们也使整个开发生命周期受益：
- 工作周期加快了 10 倍： 现在，大多数问题都可以在一天内解决，而之前平均需要 1-3 天。部署频率从每周一次跃升至每天多次。
- 质量保证团队的战略重点：由于智能体现在可以发现基本回归 和“唾手可得”的问题，因此人工测试团队可以专注于更深入、 更复杂的测试场景。
- 为利益相关者提供可靠的实现 ：由于测试超出了程序员的标准“快乐路径”，因此实现现在更具弹性。
- 更清晰的沟通和可追溯性： 通过强制执行“人工问题到实现子问题”规则，利益相关者可以清楚地了解所做的逻辑改进，而无需阅读充斥着技术实现细节及其测试方法的工单。
举例来说，P2ER 在六个月内构建了一个新平台，如果使用他们既定的方法，则需要花费数年时间。人工仍然是最终的质量关口，负责审核已由智能体验证的拉取请求。
面向团队的技术见解
在构建此工作流时，P2ER 确定了几项策略，帮助他们从实验阶段过渡到成熟的智能体辅助开发模型。
这些策略可以帮助其他团队改进自己的智能体实现：
通过脚本注入和 CLI 批处理优化令牌使用情况
如果智能体仅依赖于逐步导航（例如拍摄快照、查找 ID、填写输入和等待），则 MCP 服务器在长时间的开发会话期间可能会消耗大量令牌。为了最大限度地减少此开销，P2ER 采用了双管齐下的方法：
- 内联脚本注入： 对于有针对性的互动（例如通过复杂的 React 表单进行身份验证），智能体使用
evaluate_script工具将 Vanilla JavaScript 直接注入到浏览器中。这会绕过内置的 setter 替换并一次执行多个操作，从而节省大量对话轮次。 - CLI 脚本批处理： 当智能体遇到“障碍”或遇到极其冗长、重复的浏览器流程时，它们会切换到 CLI 批处理回退。P2ER 不会花费令牌来重复使用单个 MCP 工具或从头开始编写自定义自动化脚本，而是提示 Chrome DevTools CLI 保留和批处理浏览器操作。这让智能体能够一次以编程方式执行整个多步骤流程，从而大幅减少不断进行模型到工具通信的开销。
使用跟踪分析自动执行效果跟踪
P2ER 没有完全依赖于人工感知，而是创建了一个
review-performance 技能，该技能使用 DevTools for agents 运行 自动 Lighthouse 审核
和性能跟踪。
智能体使用 performance_start_trace 和 performance_analyze_insight 工具捕获和调查 Core Web Vitals（LCP、INP、CLS），并识别主线程瓶颈或布局偏移。为了完善质量关口，智能体可以运行完整的 lighthouse_audit，专门防范无障碍功能 (a11y)、SEO 和一般 Web 最佳实践方面的回归，确保仅提交高质量的代码以供拉取请求。
使用 Chrome DevTools for agents 增强验证
除了自定义技能外，P2ER 还使用 Chrome 开发者工具 for agents MCP 服务器的核心功能来执行功能验证。这包括使用服务器模拟不同的设备并测试响应能力，确保用户界面在不同的屏幕尺寸和设备上都能正常运行。
通过使用 MCP 服务器浏览应用，智能体可以识别布局与实际实现之间的视觉差异，从而发现静态测试经常忽略的错误。
资源
如需进一步了解 P2ER 的用例，请浏览其 相关 GitHub 代码库中提及的所有技能。
如需自行开始并详细了解如何使用 DevTools for agents 实现类似的工作流，请浏览以下资源：