learn-harness-engineering 实战：Project 07 构建你的第一个自动化 Loop（Goal-Loop / Timer-Loop / Maker-Checker-Loop）

【免费下载链接】learn-harness-engineeringHarness engineering beginner tutorial, from 0 to 1项目地址https://gitcode.com/gh_mirrors/le/learn-harness-engineering点击查看免费下载本文是 learn-harness-engineering 教程中 Project 07 的完整实践指南。Project 07 是整个课程从 Harness单次可靠的运行环境走向 Loop无人值守的自动化循环的过渡项目你已经会用AGENTS.md、feature_list.json、init.sh、session-handoff.md、clean-state-checklist.md搭好一个完整的 Harness现在要把它改造成一个能自己运转、不需要你坐在键盘前逐条发指令的 Loop。读完本文并完成三个递进实验后你将亲手掌握三种最基础的 Loop 形态目标型、定时型、Maker-Checker 型并能用一套可度量的指标判断哪些任务值得被 Loop 化。项目定位从 Harness 到 Loop 的那一步在前 12 讲中你搭建的一切——Lecture 01–04 的项目规则、Lecture 05–06 的状态管理、Lecture 07–08 的范围约束、Lecture 09–12 的干净交接与可观测性——都建立在一个共同假设上你坐在键盘前一条一条地输入指令。Agent 从不自己决定何时开始工作因为没有人按下开始。Project 07 要做的就是把开始按钮交给系统。配套课程 Lecture 13从手动 Prompt 到自主 Loop 给出了 Loop Engineering 的经典定义用系统代替你来给 Agent 发指令人从循环内部走到循环外部。本项目的三个实验正是这条路径的最小可行版本Goal-Loop把一项任务从手工驱动变成/goal自动驱动Timer-Loop把一项监控任务变成/loop定时心跳Maker-Checker-Loop构建一个完整闭环体验你完全不在场时系统如何自我迭代。项目文件与工具准备原文档将项目划分为starter/P06 的结束状态一个带完整 Harness 的小型知识库项目与solution/三种 Loop 的完整实现、Loop 状态文件与验证脚本。需要说明的是当前镜像仓库的 projects/ 目录实际同步到 project-06project-07的 starter/solution 尚未出现在本仓库中因此本文以文档描述的实验步骤为骨架以仓库中已存在的 Lecture 13 模板文件 作为可落地的样例资产。作为对照projects/project-06/solution/ 中真实存在一个完整的 Harness 实例AGENTS.md、CLAUDE.md、feature_list.json、init.sh、session-handoff.md、clean-state-checklist.md、claude-progress.md一应俱全——这正是原文档所描述的 P06 结束状态也就是你实验的起点模板。开工前需要准备的工具工具用途Claude Code 或 Codex执行/goal、/loop等循环命令Git为三个实验建立独立分支P06 的完整 Harness实验的初始状态含状态文件、feature 列表、handoff 文档tmux 或 screen终端多路复用器观察长时间运行的 LoopGitHub Actions 或 cron可选进阶实验事件驱动 / 定时调度准备步骤起点从你完成 P06 时的同一个 commit 开始确保实验环境完全一致。建三个分支p07-goal-loop、p07-timer-loop、p07-maker-checker让三个实验互不污染。确认 Harness 可用运行init.sh核对状态文件如claude-progress.md、feature_list.json、handoff 文档是否全部就位——这是 Lecture 06初始化需要独立阶段 强调的前提也是 Loop 每轮迭代的环境保障。选定目标任务选一个中等规模、有清晰完成标准的任务作为 Loop 反复工作的对象例如为所有模块补充单元测试并达到 80% 覆盖率或为所有 API 端点补充输入校验。实验 1Goal-Loop——从手工运行到自动运行切换到分支p07-goal-loop。这个实验的目标是体验/goal与传统 Prompt 的本质差异。第 1 步把任务写成goal.md不要直接把任务口头丢给 Agent而是写成一份包含四个要素的文档仓库中已有可直接套用的 goal-template.md 模板清晰目标什么算完成一句话描述期望的终态验证方法如何确认完成跑测试跑 lint查覆盖率——必须机器可验证停止条件何时该停下最大轮数、时间限制、预算限制、连续无进展判定约束什么不能碰生产配置、数据库 schema、CI/CD 配置等。模板中给出的一份可运行示例节选自 goal-template## Goal Implement the XX feature with complete unit test coverage. ## Acceptance Criteria - [ ] npm test passes fully - [ ] Coverage report shows XX module coverage ≥ 80% - [ ] npm run lint has zero errors - [ ] TypeScript type check passes (npx tsc --noEmit) ## Scope ### Fair game - All files under src/xx/ - Test files under tests/ ### Hands off - src/main.ts entry file - Database schema migrations - Dependency versions in package.json (unless explicitly needed) ## Stop Conditions - All acceptance criteria pass ✅ - Max turns reached: 20 - No progress for 3 consecutive rounds (same error keeps appearing)注意模板的用意验收标准全部是可执行的命令没有任何一条是感觉差不多了。这对应 Lecture 13 的四项静默成本 中的第一条——验证债务Verification Debt快速循环最容易跳过验证而看起来没问题不等于已确认正确所以停止条件必须机器可检查。第 2 步先做一次手工基线运行在进入/goal之前先以传统方式手工把同一任务交给 Agent 跑一遍记录消耗了多少轮turns你干预了多少次结果质量用同一套验证标准衡量。这是你后续对比的基线值baseline。第 3 步用/goal运行把同一份goal.md作为输入以/goal模式运行/goal All tests pass, zero lint warnings, merge to mainAgent 会自行循环直到目标达成或停止条件触发。从 Lecture 13 可以知道/goal与传统 Prompt 的本质差异传统 Prompt/goal你提供什么下一步要做什么终态是什么样Agent 做什么执行一次循环直到达成谁判定完成你可验证的停止条件你何时能离开不能输入/goal的那一刻/goal本质上就是一个 Loop只有三个部分目标、验证方法、停止条件。正是这三个东西把你从循环内部挪到了外部。第 4 步对比结果并迭代用同一标准对比手工与/goal两种方式的四项指标轮数差异、你的干预次数差异、结果质量差异、你投入的时间差异。如果自动运行结果不佳就回头修订goal.md再跑直到满意——或者直到你确认了 Goal-Loop 在该任务上的能力边界。这正是目标描述goal description本身是需要迭代的工程产物这一课。实验 2Timer-Loop——把监控变成心跳切换到分支p07-timer-loop。这个实验解决的是没有终点的重复性任务。先记住 Lecture 13 提供的一句话判据这件事有没有终点有终点 →/goal没有终点、只需要持续盯着 →/loop。把本该是/goal的任务塞进/loop是常见错误——/loop每次独立执行同一条指令不记得上次停在哪只会让你反复得到同一个起点。第 1 步选一个监控任务找一个你平时手工重复做的检查例如每小时跑一次测试套件并修复失败每天早上检查依赖的安全更新每次 commit 后检查代码风格违规周期性扫描 TODO 注释识别哪些已过期。第 2 步写出监控 Prompt / 脚本把监控步骤写清楚——检查什么、发现问题时做什么、什么时候必须呼叫人类。不要留模糊地带否则 Loop 遇到异常时会随机发挥。第 3 步用/loop运行# Claude Code: 每 30 分钟跑一次测试并修复失败当前会话内 /loop 30m Run the test suite and fix any failing tests # Claude Code: 每 15 分钟检查一次部署状态 /loop 15m Check if the production deploy succeeded and report status间隔建议10–30 分钟太短你会被频繁打扰太长又看不到效果至少让它跑2 小时或者干脆去忙别的稍后再回来看——用 tmux/screen 托管终端观察长期运行的 Loop。第 4 步记录结果并反思统计发现了多少问题自行修复了多少多少是误报多少被它改坏了你花了多少时间追查它的结果然后诚实地回答这项监控值得自动化吗把省下的时间与追查结果花掉的时间对比。如果不值得是选错了任务还是 Loop 设计得不好这个反思本身就是在校准你对什么适合 Loop 化的判断。实验 3Maker-Checker-Loop——把自己从 Loop 里拿出去切换到分支p07-maker-checker。这是三个实验里最重要的一个你要构建一个不需要你在场的完整闭环。第 1 步设计 Loop 结构Maker Agent负责实现——写代码、改文件Checker Agent负责验证——跑测试、做代码评审、判定通过/失败状态文件loop-state.md记录当前轮次、本轮做了什么、验证结果、下一步是什么停止条件连续 N 轮通过或达到最大轮数。这里的设计要点来自 Lecture 13 的 Generator/Evaluator Separation写代码的人和检查代码的人必须分离。让生成代码的模型给自己的作业打分它几乎总会给高分——不是因为不诚实而是因为它是作者在生成过程中已经说服了自己这条路是对的。这是所有生成式模型的共性一个模型是自己输出最好的辩护律师。所以循环里必须有人不相信你。第 2 步写三个 Prompt仓库中提供了两个可直接参考的角色 PromptMaker Agent Prompt聚焦把它做出来——理解需求、设计方案、写代码、跑基础验证build/lint/单测、把结果交给 Checker并在交付时列出改动文件、实现摘要、基础验证结果和自己不确定的区域Checker Agent Prompt聚焦找出问题——逐项核对功能正确性、代码质量、测试有效性、验证命令、安全与影响面每个问题必须附带位置文件:行号、证据和严重级别最后给出整体裁决通过/失败/有小问题可接受。第三个是Loop 控制逻辑谁先开始、如何交接、如何启动下一轮。仓库还提供了 loop-state-template.md 状态模板它把每轮记录规范化为本轮开始时间、Maker 做了什么、验证结果通过/失败/部分、发现的问题、下轮计划、是否需要人工干预以及累计统计完成轮数、通过/失败轮数、发现问题总数、人工干预次数、改动文件数和阻塞清单。Maker 与 Checker 的典型交接格式如下来自 maker-prompt / checker-prompt 的输出要求## Implementation Summary ... ## Modified Files - ... ## Basic Verification - Build: pass / fail - Lint: pass / fail - Unit tests: X passed, Y failed ## Known Issues and Risks - ...Checker 的裁决格式## Overall Verdict ✅ Pass / ❌ Fail / ⚠️ Minor issues, acceptable ## Issues Found ### 1. [Critical] Issue title - Location: file:line - Description: ... - Evidence: ... - Suggestion: ...第 3 步至少跑 5 轮第 1 轮Maker 实现 → Checker 验证 → 失败 → 把反馈交回 Maker第 2 轮Maker 根据反馈修订 → Checker 再验证 → ……直到连续通过或你主动叫停。第 4 步记录每轮状态每轮至少记录五件事轮次编号、Maker 做了什么、Checker 发现了什么问题、通过/失败、你是否干预了如果干预了为什么。模板见 loop-state-template.md。第 5 步最终 Retro你干预了几次为什么如果不干预会发生什么Checker 有没有漏掉问题Maker 是否反复犯同一个错误这个 Loop 的质量天花板在哪——是 Maker 的能力还是 Checker 的能力最后一个问题直指 Loop 工程的核心认知循环会放大输出也会放大风险。把 Maker 和 Checker 分开必要时用不同模型是 Lecture 13 反复强调的任何 Loop 可靠性的底线保证。如何度量结果原文档给出了一张贯穿三个实验的统一度量表建议你在实验期间持续填写指标实验 1Goal实验 2Timer实验 3Maker-Checker任务完成率目标达成了吗跑了多少个监控周期多少轮才通过人工干预你干预了几次你花了多少时间追查结果你干预了几次结果质量与手工相比如何误报率漏报问题Checker 发现了多少你自己发现不了的问题节省时间省了多少时间自动化值得吗设计 Loop 的时间 vs 省下的时间可靠性停止条件可信吗它有没有失控跑飞Loop 会不会卡在同一个地方出不来配合 Lecture 13 的成熟度阶梯你可以给自己定位实验 1 对应 Level 1Goal Runner实验 2 对应 Level 2Scheduled Single-Task实验 3 则开始触及 Level 3Multi-Agent Loop的核心——Maker/Checker 拆分。需要提交的成果goal.md实验 1 的目标描述至少迭代两个版本实验 1 的对比笔记手工 vs Goal-Loop实验 2 的监控 Prompt 2 小时运行日志实验 3 的三个 PromptMaker / Checker / Loop 控制实验 3 的loop-state.md至少记录 5 轮最终 Retro三个实验的收获、你对 Loop Engineering 理解的转变、哪些事情适合 Loop 化、哪些不适合。关键提示与常见误区不要混淆/goal与/loop一个是跑到终点线的马拉松一个是按点响的闹钟。用一句话测试判断——有终点用/goal没终点只要持续盯用/loop。状态文件是 Loop 的记忆模型每次运行之间会忘掉一切记忆必须活在磁盘上。每轮结束更新loop-state.md下一轮开始时先读它——这正对应 Lecture 05状态文件是连续性的脊梁 和 Lecture 12每个会话都要留下干净状态。让 Loop 可观测Loop 跑得越快你越需要看清内部发生了什么否则出了问题也无从下手——这是 Lecture 11可观测性属于 Harness 的核心教训监控实验 2 尤其依赖它。从小处开始不需要一上来就搭多 Agent 编排。一个/goal、一个 cron、一个 markdown 状态文件先看到回报再往上叠加。相关课程Lecture 13 — 为什么你应该停止给 Agent 发 Prompt本项目的核心理论课含/goal演进史、四种 Loop 分类、六原语与模板文件Lecture 12 — 为什么每个会话都要留下干净状态Loop 的每一轮都需要干净状态Lecture 11 — 为什么可观测性要内建于 Harness你必须能看到 Loop 内部发生了什么Lecture 05 — 为什么状态文件是连续性的脊梁Loop 状态文件是状态文件的延伸赞分享【免费下载链接】learn-harness-engineeringHarness engineering beginner tutorial, from 0 to 1项目地址https://gitcode.com/gh_mirrors/le/learn-harness-engineering点击查看免费下载相关推荐用 goal-template.md 构建可验证的目标循环learn-harness-engineering 的 Goal Loop 工程实践用 goal template.md 构建可验证的目标循环learn harness engineering 的 Goal Loop 工程实践 目标模板golearn-harness-engineering 实战编写 Checker 验证 Agent Prompt为自动化 Loop 守住质量关口learn harness engineering 实战编写 Checker 验证 Agent Prompt为自动化 Loop 守住质量关口 本篇技术指南围用 learn-harness-engineering 项目把 Agent 工作流画成图从 Maker-Checker Loop 到 Graph Engineering 的三步实战用 learn harness engineering 项目把 Agent 工作流画成图从 Maker Checker Loop 到 Graph Engine创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考