【免费下载链接】learn-harness-engineeringHarness engineering beginner tutorial, from 0 to 1项目地址https://gitcode.com/gh_mirrors/le/learn-harness-engineering点击查看免费下载本篇技术指南围绕开源仓库 learn-harness-engineering 中 docs/ja/resources/openai-advanced/sops/chrome-devtools-validation-loop.md 这份标准操作流程SOP展开。它解决的是 Harness智能体工作框架工程中一个高频痛点当 UI 功能是否正确的判断依据不在静态代码里而在真实运行时的截图、DOM 状态与控制台输出中时如何让 Agent 不再靠猜或看代码下结论而是通过一个可复现的操作循环反复验证直到目标旅程收敛为干净状态。读完本文你将掌握这套 8 步核心循环、7 步执行 SOP、4 条干净判定标准以及如何把验证结论落回仓库成果物并结合本仓库的真实脚本Playwright 截图、可复现检查脚本看到该模式的实际落地形态。一、这套 SOP 解决什么问题何时该用它Chrome DevTools 验证循环Chrome DevTools Validation Loop是一份面向UI 工作的标准操作流程。原文明确了它的适用前提当 UI 工作依赖实际运行时runtime中的操作且截图、DOM 状态、控制台输出比单纯检查代码更重要时使用本 SOP。这句话划出了它与其他 SOP 的边界它不适用于看代码就能判定对错的后端逻辑调整而是适用于一切可观察结果位于浏览器运行时的任务。典型的信号包括某个按钮点击后页面是否进入预期状态只能靠 DOM 或截图确认控制台是否出现报错或噪音只能靠浏览器运行时输出确认同一条用户操作路径journey是否稳定复现只能靠反复执行确认。它的目标原文目標可以浓缩为一句话把 UI 验证转化为可复现的操作循环operation loop让 Agent 一直运行这个循环直到旅程journey变干净为止。也就是说验证不是一个一次性检查动作而是一个循环到收敛的过程。本仓库中该 SOP 所属的体系位于 docs/ja/resources/openai-advanced/sops/index.md其中将本文档定位为使用浏览器自动化与快照直到 UI 行为变干净为止的验证型 SOP与可观测性反馈环observability-feedback-loop.md互为表里一个负责在运行时收集证据一个负责把 UI 验证组织成可重复的循环。二、核心循环8 步闭环总览原文档给出了整个方法的骨架——一个 8 步循环。这 8 步构成了任何一次 UI 验证迭代的完整回合选择目标页面或应用实例Select the target page or app instance——确定要验证的载体明确在哪个实例上跑。清除旧的控制台噪音Clear old console noise——清空历史日志避免上一次运行残留的报错污染本次判定。捕获 BEFORE 状态Capture the BEFORE state——记录操作前的基线DOM 结构、控制台内容、截图。触发 UI 路径Trigger the UI path——执行目标旅程且一次只触发一条。观察操作中的运行时事件Observe runtime events during the operation——监控网络请求、控制台输出、DOM 变化等实时信号。捕获 AFTER 状态Capture the AFTER state——记录操作后的结果快照。必要时应用修复并重启应用Apply fixes if needed, restart the app——发现问题后修复并让应用以干净状态重启。重新运行验证直到旅程干净Re-run validation until the journey is clean——回到步骤 1形成循环。这个循环的关键设计在于BEFORE/AFTER 成对取证 单路径触发 干净状态重启。第 2 步清噪音和第 7 步重启保证了每一次迭代都从一个干净基线开始使前后两次运行的结果具备可比性第 4 步一次一条路径保证了证据与因果一一对应不会因为多条路径叠加而无法归因。仓库佐证快照能力在本仓库中的真实实现获取 DOM / 控制台 / 截图快照是这个循环的第 3、6 步也是整个 SOP 的物质基础。本仓库的 scripts/capture-readme-screenshots.ts 提供了一个可直接对照的 Playwright 实现const browser await chromium.launch({ headless: true }) const context await browser.newContext(devices[Desktop Chrome]) // ... await page.goto(toAbsoluteSiteUrl(server.origin, target.routePath), { waitUntil: networkidle }) await page.screenshot({ path: ..., fullPage: false })从这段源码可以看出三个与本 SOP 直接对应的工程要点headless: true的 Chromium 实例正是选择一个应用实例的落地方式——验证循环完全可以在无头浏览器中自动执行不依赖人工开窗waitUntil: networkidle相当于观察操作中的运行时事件——它等网络请求全部空闲后才截图确保 BEFORE/AFTER 快照捕获的是稳定状态而非加载中间态page.screenshot(...)即 BEFORE/AFTER 证据的产出物配合fullPage: false控制截图尺度避免超长截图带来的噪声。这证明本仓库已将用浏览器自动化获取快照作为基础设施使用SOP 中所要求的获取快照的方法在工程上是完全可落地的。三、前置输入跑这个循环前必须备齐的 4 样东西原文档必要な入力一节列了四项前置条件缺一不可前置输入含义缺失时的后果稳定的启动命令stable startup command能可重复地把应用或指定页面/实例拉起来的命令每次启动状态不一致BEFORE/AFTER 无从比较可复现的 UI 旅程reproducible UI journey一条能被反复执行、行为确定的用户操作路径无法触发验证或每次触发路径漂移获取 DOM、控制台或截图快照的方法能机械化地记录运行时状态的手段工具或脚本无法取证Agent 只能声称成功而拿不出证据判定干净的规则明确什么算通过、什么算失败的标准循环没有终止条件收敛无从谈起这四项本质上回答了验证循环的四个元问题在哪跑、跑什么、拿什么证据、怎么算过。其中第 4 项干净的规则最为关键它将在后面第五节展开为四条可操作的判定标准。四、执行 SOP7 步标准操作流程在核心循环之上原文档给出了一份更细粒度的 7 步执行 SOP把每一次迭代拆解为可照做的动作序列在活动计划中描述目标旅程——先在计划层面明确今天要验证哪条路径让验证目标对 Agent 和人都可见。对应到本仓库活动执行计划的载体可见 repo-template 的 exec-plans 目录其中active/存放进行中的计划。用可观察条件定义成功——成功必须能被观测原文给出了五类典型条件文本的存在text presence按钮的启用button enabled错误的消失error absence控制台的干净clean console请求的成功request success操作前获取初始状态快照——即核心循环的 BEFORE 步骤记录基线。一次只精确触发一条路径——保持因果单一性避免证据混淆。记录运行时事件、DOM 变化、可见输出——把观察到的现象全部记下来作为后续归因的素材。若旅程失败修复责任最大的最小层然后重启——这是本 SOP 最重要的归因原则最小责任层smallest layer most responsible。即先定位最该为失败负责的那一层如组件、样式、请求处理、状态管理只修这一层不要顺手改动无关代码然后以干净状态重启应用。重跑同一条路径比较 BEFORE/AFTER 证据——验证修复是否真的改变了结果而不是碰巧这次过了。把第 2 步与第 5 步结合看这套 SOP 的方法论本质是成功条件必须可观察化证据必须成对化修复必须最小化重跑必须同路径化。这四条纪律直接对抗 Agent 最常见的两种失范——没有证据就宣布胜利和一次改一堆东西导致无法归因。五、干净的判定标准循环何时终止循环不能无限跑下去必须有一个明确、可判定的终止条件。原文档クリーンの基準给出了四条同时满足的标准预期的可见状态存在intended visible state exists——目标 UI 状态确实出现在页面上不存在意外错误no unexpected errors——没有计划之外的报错控制台噪音已被理解或清除console noise is understood or cleared——残留的日志要么被解释清楚理解其无害要么被清掉重跑同一条路径得到相同结果same path re-run yields the same result——结果可复现这是最硬的一条一次通过不算数两次同路径结果一致才算稳定。第 4 条尤为关键它把验证从单次抽检提升为稳定性检验——这正呼应了本 SOP 的直到旅程干净为止的目标定义。同时它也把判定权交还给证据如果重跑结果不一致说明前面 8 步循环中某一步的基线或触发不够稳定需要回头排查而非宣布完成。六、验证结论要落回仓库3 类成果物SOP 的最后一部分规定验证结束不是终点结论必须写回仓库否则下次会话又要重新踩坑。原文档更新すべきリポジトリ成果物指定了三类成果物活动执行计划active execution plan——记录本次验证的目标旅程、结果与下一步保持计划与事实同步当旅程成为黄金路径golden path时更新docs/RELIABILITY.md——一条路径一旦被反复验证为干净、稳定就应升级为黄金路径并固化到可靠性文档中。本仓库的模板中对应文件为 repo-template/docs/RELIABILITY.md当可见行为发生变化时更新产品规格product spec——如果验证中发现实际可见行为与预期规格不符那说明规格本身需要修订例如 repo-template/docs/product-specs/ 下的产品规格文档。这一节体现了整个 SOP 家族共同的原则可复现的验证知识必须编码进仓库而不是留在聊天记录或 Agent 的临时记忆里——这与姊妹 SOP encode-knowledge-into-repo.md 的把不可见知识编码进仓库的目标完全一致。七、配套 SOP 与仓库中的可复现验证实践与可观测性反馈环的关系observability-feedback-loop.md 与本 SOP 构成互补可观测性 SOP 解决Agent 如何拿到日志、指标、追踪的信号供给问题而 Chrome DevTools 验证循环解决拿到信号后如何组织成收敛的验证闭环的流程问题。前者的调试会话检查清单什么失败了哪个信号证明了失败哪个层负责修正后改了什么应用是否干净重启同负载重跑是否成功几乎可以逐条映射到本 SOP 的 8 步循环中。仓库中的可复现验证脚本范例本仓库 project-06 的解决方案目录提供了两个把验证规则机械化的真实脚本可作为把干净标准变成可执行检查的参考projects/project-06/solution/scripts/cleanup-scanner.sh一个数据一致性扫描器依次检查孤儿内容文件、悬空分块、缺失内容、不一致元数据、过期的 QA 引用最终输出Result: CLEAN (0 issues found)或列出问题与建议动作。它演示了如何把干净定义为一组可脚本化的检查项——这与本 SOP 第 5 步记录可观察条件的工程化方向一致。projects/project-06/solution/scripts/check-architecture.sh一个分层边界检查脚本用grep规则机械化地检查渲染层不得导入 Node 核心模块、服务层不得使用 Electron IPC、后端不得导入 React全部通过时退出码为 0。它展示了把一次一次的人工评审结论固化为可重跑的检查脚本的完整思路——正是本 SOP更新成果物章节所倡导的让规则可执行让验证可重跑。这两个脚本的共性在于它们都以退出码 明确输出作为判定接口可以被 Agent 在循环中反复调用、反复比对——这正是把BEFORE/AFTER 证据对比自动化的雏形。需要说明的是它们是仓库中针对各自项目场景的验证实现与本 SOP 的 DevTools 快照循环在工具层面不同一个面向数据目录、一个面向源码边界但在方法论上同属把验证变成可重跑循环的范畴。八、快速上手把本 SOP 接入你的 Harness结合原文与仓库实践落地这套 SOP 的最小动作清单如下准备启动命令确保应用可用一条命令稳定启动如仓库中 projects/project-06/solution/scripts/dev.js 这类开发启动脚本并记录到活动执行计划中。写一条旅程在活动计划中描述一条可复现的 UI 路径并用可观察条件定义成功文本出现 / 按钮可用 / 无报错 / 请求成功。备好快照手段基于 Playwright/Puppeteer 的 headless Chromium 脚本参考 scripts/capture-readme-screenshots.ts获取截图与 DOM配合page.on(console)捕获控制台。跑 8 步循环选实例 → 清噪音 → BEFORE → 触发单路径 → 观察 → AFTER → 必要时最小修复并重启 → 重跑直到满足第五节四条干净标准。落回仓库更新活动执行计划旅程稳定后把结论写入 repo-template/docs/RELIABILITY.md可见行为变化则更新产品规格文档。整套流程的设计哲学可以概括为一句在 UI 验证这件事上让 Agent 用运行时证据说话用循环收敛代替一次断言用仓库固化代替口头总结。这也是本 SOP 作为 OpenAI 高级 SOP 家族一员服务于让 Harness 更可读、更可强制、更可复现这一总体目标的具体体现参见 sops/index.md 的用法说明先按瓶颈选 SOP再用清单补齐缺失产物最后把规则编码进仓库。赞分享【免费下载链接】learn-harness-engineeringHarness engineering beginner tutorial, from 0 to 1项目地址https://gitcode.com/gh_mirrors/le/learn-harness-engineering点击查看免费下载相关推荐用 Chrome DevTools 验证循环把 UI 验证变成可重复的 Agent 闭环learn-harness-engineering 实战 SOP用 Chrome DevTools 验证循环把 UI 验证变成可重复的 Agent 闭环learn harness engineering 实战 SOP 导learn-harness-engineering 实战用 Chrome DevTools 验证循环把 UI 调试变成可重复的 Agent 工作流learn harness engineering 实战用 Chrome DevTools 验证循环把 UI 调试变成可重复的 Agent 工作流 在 AgeChrome DevTools 验证闭环Validation LoopSOP让 Agent 以运行时证据验收 UIChrome DevTools 验证闭环Validation LoopSOP让 Agent 以运行时证据验收 UI 本篇技术指南围绕 learn harn上一篇如何快速从Google Drive下载共享文件Python下载器的完整指南下一篇oh-my-hermes 配置迁移指南用 Setup Profile Pack 快速把配置带到新机器创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考