【免费下载链接】learn-harness-engineeringHarness engineering beginner tutorial, from 0 to 1项目地址https://gitcode.com/gh_mirrors/le/learn-harness-engineering点击查看免费下载本篇技术指南以 docs/ru/resources/openai-advanced/sops/index.md 为核心骨架系统讲解该 SOP 库的用法与四份标准操作规程层式领域架构、知识入库、可观测性反馈回路、Chrome DevTools 验证回路并结合 repo-template 模板与 AGENTS.md 等仓库文件说明如何把 OpenAI「Harness engineering」一文中的运维模式落成可执行、可检查、可复现的 Agent 工作流。读完你可以在自己的仓库中直接套用这四份 SOP 建立多会话稳定运行的 coding-agent 工程。为什么需要把运维模式转成 SOPOpenAI Advanced Pack见 docs/ru/resources/openai-advanced/index.md将「Harness engineering: leveraging Codex in an agent-first world」中描述的、更严格形态的仓库封装为可复制的起始文件。而 sops/index.md 进一步把这些模式翻译成“具体可执行的 playbook”显式分层与跨层边界layered-domain-architecture把不可见知识从聊天、文档、人脑中迁入仓库文件encode-knowledge-into-repo为 Agent 提供日志、指标、追踪与可重复调试回路observability-feedback-loop用浏览器自动化与快照验证 UI 行为直至结果干净chrome-devtools-validation-loop这份 SOP 库的设计哲学在文档中写得很明确它不是用来盲目照抄的而是让 harness 更可读readable、更可验证verifiable、更可复现repeatable。对应到模板仓库里就是 repo-template/AGENTS.md 开头强调的“保持短小把它当作路由到更深文档的层而不是巨型指令倾倒”以及 repo-template/ARCHITECTURE.md 中“用固定有向分层模型避免 Agent 即兴发明 ad hoc 架构”的表述。使用 SOP 的四步流程sops/index.md 给出的标准用法只有四步但每一步都对应着仓库中可落地的具体动作选 SOP针对当前最痛的点选择对应规程边界混乱 → 架构 SOP知识散落 → 知识入库 SOP调试慢/假成功 → 可观测性 SOPUI 靠肉眼 → DevTools SOP。用清单补件利用各 SOP 的 checklist 补齐缺失的制品或工具链如 ARCHITECTURE.md 的域地图、跨切面接口表、热点清单。把规则固化进模板将形成的规则写回复制来的repo-template/文档副本。把重复的评审意见变成检查将反复出现的 review feedback 转成检查、脚本或约束器guard-rail而不是每次在聊天里重新解释——这正是 repo-template/AGENTS.md 中“如果看到重复的评审反馈就把它变成机械规则/检查/linter”的工作合约。SOP 一层式领域架构layered-domain-architecture适用信号Agent 不断破坏边界、在层间复制逻辑、产出几轮会话后难以评审的代码。目标与目标模型让领域边界足够显式使 Agent 能快速推进而不悄然破坏结构。业务领域内优先采用有向依赖流Types - Config - Repo - Service - Runtime - UI跨切面实体必须经过显式 provider 或 adapter 进入公共工具类留在领域之外不得累积领域逻辑。这一模型与 repo-template/ARCHITECTURE.md 的“层级模型”一节完全一致模板还给出了五条硬性依赖规则底层不得依赖上层、UI 不得绕过 runtime/service 契约、数据访问必须经过 repository 或等价 adapter、公共工具必须保持通用、新依赖必须在对应 plan 或设计文档中给出理由。配置清单Checklist在ARCHITECTURE.md中界定当前领域在ARCHITECTURE.md中写下允许的依赖方向固定跨切面接口认证、遥测、外部 API模板中还有 feature flags见下表记录当前最严重的边界违规点决定哪些规则应由 linter、测试或脚本机械校验。执行 SOP在动实现风格之前先按领域给代码库分区为每个领域定义允许的层序列识别全部跨切面实体统一经由 provider/adapter 通过把含糊的公共逻辑归入所属领域或真正的通用工具把规则写进ARCHITECTURE.md为代价最高的违规加一个可执行的约束器改动后更新质量评分。完成定义Definition of Done新会话的 Agent 能说出某改动属于哪个层UI 代码不再直接触达 repository 或外部副作用跨切面实体拥有命名的入口点至少一条关键边界被机械地强制。需更新的仓库制品ARCHITECTURE.md、docs/QUALITY_SCORE.md、docs/design-docs/当论证逻辑变化时、docs/PLANS.md或当前活跃的 exec plan。模板中 ARCHITECTURE.md 的跨切面接口表值得直接套用实体已批准的边界备注日志与追踪[provider / 工具路径][仅结构化禁用 ad hoc console]认证[provider 路径][token/会话规则]外部 API[client/provider 路径][限速 / 重试规则]Feature flags[flag 边界][所有权]配合docs/FRONTEND.mdUI 约束、设计系统规则、无障碍检查与docs/SECURITY.mdsecret、sandbox、数据、外部行为规则跨切面规则就能形成完整闭环。SOP 二把不可见知识编码进仓库encode-knowledge-into-repo适用信号关键上下文仍活在 Google Docs、聊天串、ticket 或人脑中。目标让 Agent 不可见的知识在代码库中可被发现使全新会话无需依赖上一次对话就能行动。触发信号Agent 反复询问系统如何工作有人说“这个我们在 Slack 里定过”或“按 X 上周说的做”评审引用仓库中不存在的产品规则或安全规则新会话重复做本该已经完成的发现工作。执行 SOP枚举不可见知识的来源文档、聊天、不成文的团队规则、口头决定对每个来源分类是架构、产品行为、安全策略、可靠性预期、计划上下文还是参考资料编码进对应制品架构 →ARCHITECTURE.md产品行为 →docs/product-specs/设计论证 →docs/design-docs/执行状态 →docs/exec-plans/重复出现的外部链接 →docs/references/质量/可靠性预期 →docs/QUALITY_SCORE.md或docs/RELIABILITY.md把模糊措辞替换为操作上有用的表述删除或标记过期的重复副本保持“单一可发现真相”。模板仓库为第 3 步提供了现成落点repo-template 的布局中docs/design-docs/含core-beliefs.md、docs/exec-plans/active/completed 与tech-debt-tracker.md、docs/product-specs/含new-user-onboarding.md、docs/generated/db-schema.md、docs/references/存放design-system-reference-llms.txt、nixpacks-llms.txt、uv-llms.txt等模型友好引用均为编码知识的既定位置。编码规则为可发现性而写而不是为文学完整性偏好文件名清晰、内容简短的文档把相关制品互相链接存长期有效的规则而不是会议纪要转录在做出决定的同一会话内更新仓库。完成定义新会话的 Agent 无需问人即可发现所需规则同一事实不散落在多个互相矛盾的文件里新制品与其所约束的代码/流程同处一处。这正是 repo-template/AGENTS.md 路由图中每个文档的职责ARCHITECTURE.md提供域地图与依赖规则docs/design-docs/index.md保存设计决策与核心信念docs/product-specs/index.md保存当前产品行为与验收标准docs/QUALITY_SCORE.md反映域/层健康度docs/RELIABILITY.md记录运行时信号与重启预期。SOP 三可观测性反馈回路observability-feedback-loop适用信号调试缓慢、Agent 总是不带证据就宣称成功、运行时行为比代码本身更难检查。目标为 Agent 提供基于日志、指标、追踪与可重放负载的本地反馈回路使其能基于执行结果推理而非仅靠代码审查。最小技术栈应用输出结构化日志尽可能输出指标与追踪本地 fan-out 或采集层日志/指标/追踪的查询接口可在每次改动后重跑的可重放负载或用户场景。执行 SOP定义最重要的 golden 运行时场景在启动与关键路径加结构化日志在有用处加延迟、失败数或队列深度等指标为慢速/多步流程加追踪或时间标记让信号可从本地 dev 环境查询给 Agent 一个可重跑的负载或场景强制闭环查询 → 关联 → 推理 → 实现 → 重启 → 重复 → 验证。调试会话清单什么挂了哪个信号证明了故障故障属于哪一层修复后什么变了应用是否干净重启同一负载重跑是否通过完成定义Agent 能凭运行时证据解释故障模式同一负载可在每次改动后重跑重启与重跑成为任务的常规部分可靠性信号写入docs/RELIABILITY.md。在仓库中可靠性信号与重启预期正是由 repo-template/ARCHITECTURE.md 的跨切面接口表日志/追踪、认证、外部 API、feature flags 的批准边界和 repo-template/AGENTS.md 的完成定义“目标行为已实现、所需验证确实通过、证据附在对应 plan/质量文档中、受影响文档保持最新、仓库能从标准启动路径干净重启”共同约束的。SOP 四Chrome DevTools 验证回路chrome-devtools-validation-loop适用信号UI 工作依赖真实运行时交互截图、DOM 状态与控制台输出比单纯代码审查更重要。目标把 UI 验证变成可重跑的交互回路Agent 可以反复运行直到场景干净。主循环选择目标页面或应用实例清掉控制台里的过期噪音记录“之前”状态触发 UI 路径在交互期间观察运行时事件记录“之后”状态应用修复并在必要时重启应用反复验证直到场景干净。必要输入稳定的启动命令可复现的 UI 场景抓取 DOM、控制台或截图的手段定义何为“干净”的规则。执行 SOP把目标场景写进当前活跃 plan用可观察的措辞定义成功文本存在、按钮激活、错误消失、控制台干净、请求成功交互前抓初始状态快照一次只触发一条路径记录运行时事件、DOM 变化与可见输出场景失败时修最小的责任层并重启重跑同一路径并对比“之前/之后”证据。干净clean标准预期的可见状态存在无意外错误控制台噪音已理解或已清理同一路径重跑得到相同结果。需更新的仓库制品当前活跃的 exec plan若该场景成为 golden path更新docs/RELIABILITY.md若可见行为变化更新产品规格。该 SOP 与 repo-template/AGENTS.md 的工作契约“不要仅凭代码检查就把工作标记为完成需要可运行的证据”以及其完成定义中的“仓库能从标准启动路径干净重启”完全同构——即每次验证都必须以“可重跑、可对比前后证据”为标准。四份 SOP 的落地清单与 repo-template 的组合使用把四份 SOP 与 repo-template 的起始布局AGENTS.md、ARCHITECTURE.md、docs/下 design-docs/exec-plans/generated/product-specs/references 与 DESIGN/FRONTEND/PLANS/PRODUCT_SENSE/QUALITY_SCORE/RELIABILITY/SECURITY组合时可按以下顺序落地从最小包起步AGENTS.md或CLAUDE.md、feature_list.json、claude-progress.md、init.sh参考 docs/ru/resources/index.md 的推荐最小包。仓库变大、出现多领域与长期存活时复制repo-template/文件启用更严格结构。保持AGENTS.md短小作为路由层而非百科全书sops/index.md 第 3 步。在日常工作中持续更新质量、可靠性与计划文档而非设一个“打扫日”。让生成物与外部引用显式化使 Agent 无需依赖聊天历史即可找到它们。把反复出现的评审意见固化为检查/脚本/约束器。综合自检标准docs/ru/resources/index.md 同样强调这四个文件足以明显稳定大多数 Agent 工作流当仓库成长为多领域、多活跃计划的长期系统时应切换到 advanced 包而不是把最小包无限拉长。常见误区与使用边界sops/index.md 明确声明“这不是为了盲目遵循”。结合模板文档几个高频误区值得注意把 AGENTS.md 写成百科全书模板刻意保持它短小膨胀会破坏路由语义口头规则取代机械校验跨切面边界、依赖方向若只靠“记得”Agent 会在数轮会话后悄然破坏架构 SOP 第 6 步强制至少一条机械约束知识留在聊天记录里凡在 Slack/评审/口头中重复出现的规则都应走知识入库 SOP 迁进仓库并在同一会话更新只凭代码审查判定完成observability 与 DevTools 两套 SOP 的完成定义都要求可运行证据与可重跑验证不做状态清理AGENTS.md 的“会话结束”流程更新 exec plan、更新 QUALITY_SCORE、记录 tech-debt、归档 completed plans、留下可重启状态保证每次会话交接都从干净状态继续。赞分享【免费下载链接】learn-harness-engineeringHarness engineering beginner tutorial, from 0 to 1项目地址https://gitcode.com/gh_mirrors/le/learn-harness-engineering点击查看免费下载相关推荐OpenAI 高级 SOP 实战手册用可执行 Playbook 把 Agent Harness 工程化OpenAI 高级 SOP 实战手册用可执行 Playbook 把 Agent Harness 工程化 本文是 learn harness engineeriAgent-First 仓库的四大标准操作流程SOPlearn-harness-engineering 中的 OpenAI Advanced SOP 实战手册Agent First 仓库的四大标准操作流程SOPlearn harness engineering 中的 OpenAI Advanced SOP 实战Learn Harness Engineering 的 OpenAI 高级 SOP 实践指南从 Playbook 到可执行的知识仓库Learn Harness Engineering 的 OpenAI 高级 SOP 实践指南从 Playbook 到可执行的知识仓库 本指南围绕 Learn上一篇零基础看懂 Playnite 插件安装自动校验、版本匹配、排队落盘一文讲清下一篇Quicklink动态链接处理SPA路由变化时的预加载更新创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
