Loop Engineering 保姆级学习路径讲解

这期视频我们来完整的讲清楚loop engineering那为了准备这期内容我一共写了两万字的告子所以这期视频会特别的长也会特别的干那我知道这一年多里AI coding领域的新名词一个接着一个从最开始的prompt engineering到context engineering后来又出了Harness Engineering现在又来了新的名词Loop Engineering很多名词你可能刚刚记住下一批又来了所以你会本能的觉得这会不会又是一个新的名字或者是概念但这次我觉得可能真的不太一样因为Loop Engineering不是要取代前面的概念而是把Prompt,Context,Agent,Skill,Workflow,还有Harness全部串进同一条反规回路从这个角度来看它可能是前面这些方法的极大成者更重要的是它代表着Webcoding开发范式的一次转变从人推动每一轮走向系统根据结果持续推进比如我们想用Codex开发一款AI视频剪辑应用你把需求发过去Codex独项目携带码跑编译很快告诉你第一版完成了真正把应用跑起来以后问题才开始出现第一次测试生存成功了后台任务也已经完成但前单页面一直停在处理中你打开浏览器接口响应和后台日志把现象、复显步骤和测试结果整理好再发一条prompt让codex继续改这一轮修改页面终于能进入到结果页可你一刷新当前任务又不见了于是你再跑再查再整理再反馈结论以后你会发现codex确实一直在写代码但负责运行应用、应收功能、整理bug决定下一步再按下继续的那个人始终还是你Loop Engineering要解决的就是把原本靠人手动拼接的步骤也设计进系统里做完以后谁检查没通过退回到哪里什么时候继续下一项什么时候应该停止什么时候应该交给人放在Vipe Coding里Loop Engineering就是把Coding Agent的开发过程变成一条根据证据和结果持续推进的闭环做一轮检查一轮再决定下一轮是否继续结束还是反攻并且交还给人为了看清loop engineering到底是怎么形成的我们先把这套结构拆开退回到最简单的起点一条prompt先看它能解决什么又解决不了什么prompt是整套结构的起点说白了就是当前这一次任务的说明要做什么边界在哪里以及怎样才算完成放在刚才我们的应用开发案例里我们最开始可能会这样写这条prompt已经说了大方向但里面还有很多空白一旦交给AI这些没有说清楚的地方就只能由他替你猜上传系统允许多大支持哪些格式任务一共有哪些状态页面刷新以后要不要恢复当前的任务处理失败时怎么提示能不能重视第一版要不要做登录支付多人项目和云端部署那这些问题写不清楚模型就只能自己补它补的再合理可能也未必是你想要的那款产品所以第一步不是把prompt写的更长而是把三件事情说清楚目标是什么边界在哪里什么证据才能证明它完成了把一张任务单写清楚就是最基础的prompt engineeringprompt越明确模型越少替你做产品决定结果通常也会越稳定但prompt解决的只是任务怎么说清楚一份说明不会自己读取项目修改文件运行命令真正接过任务进入到环境并采取行动的是agent在这个例子里codex就是我们的agent它会根据当前看到的信息判断下一步再调运工具把事情做下去拿到这条prompt后,Codex会读取项目,找到相关代码,修改文件,运行终端和浏览器,再根据工具返回结果继续调整所以prompt负责说明这次要做什么,agent负责真正进入项目把任务往前执行Agent 一旦开始行动我们最初给他的那条 prompt 就不再是全部内容了因为他要看代码 日志 日接口响应和测试结果那这些信息会不断地改变他接下来的判断Agent 此时此刻会拿来判断的全部信息合在一起就是 Context 也就是上下文所以 Context 不只是聊天记录它包括最初的prompt也包括项目代码产品需求工具说明接口响应终端日志测试结果以及前面已经做过的所有决定这使真正影响下一步的不只是prompt写了什么而是agent眼前到底摆着什么把该看的信息在合适的时候交给agent把无关重复或者已经过期的内容移开这就是context engineering还是刚才的那个应用后台任务明明已经完成了前端页面却一直停在处理中为了找到原因Codex要同时查看后台的Worker数据库状态接口前端的轮巡页面路由浏览器请求和大段的日志这些信息都可能有用但如果调查开发和测试全部都挤在一个绘画里主线很快就会被过程淹没Context Engineering可以让信息更干净但它决定不了另一个问题调查开发和测试仍然全压在同一个角色身上当一项工作边界足够清楚时我们可以把它单独派出去这个由主agent派出专门负责一项任务的独立角色就是SubagentSub-agent不一定使用更小的模型也不一定更弱它和主agent的核心区别不是模型大小而是任务范围的大小context更聚焦,任务更窄主agent把调查任务状态为什么不一致单独派出去这个Sub-agent只看了和问题有关的代码,接口和日志完成以后不把整个的过程原样倒回回主会化只会返回结论、证据、风险和建议所以它的价值不只是多一个agent干活更重要的是它把任务和context一起拆开了当然派出去之前目标范围可用材料完成标准和返回格式还是要写清楚的否则它只是换了一个窗口继续迷路边界情况写清楚Subagent还有一个额外的好处他们互不依赖可以并行工作比如调查A去查看后台任务怎样写入状态接口怎样返回调查B去检查前端怎样轮选怎样识别完成状态什么时候进入结果页两边互不依赖就可以同时开始但并行并不是越多越好后一项必须依赖前项结果时就应该串行多个subagent如果会修改同一批代码要么隔离工作区要么按顺序来主绘画会保留全局subagent只拿当前任务重要的信息这样既能减轻主绘画的压力也让病情更可控subagent解决了工作怎么拆开也把不同的任务context分开了但不同agent做同一类工作方法可能完全不一样同样是检查状态不一致有的会沿着后台worker接口和前端一路查到底而有的呢看到build通过他就停止了所以要让同一类任务每次都能稳定的按一套方法来执行这个时候我们就需要skillskill不是新的执行角色而是一份可以反复调用的工作手册prompt说的是这一次要做什么skill说的是这一类任务通常应该怎么做放到刚才的应用里假设当前的任务是修改任务状态与结果页当前prompt会告诉agent后台任务完成以后页面要进入结果页前端展示的状态必须和后台一致而Skill记录的是以后做全站功能都能继续复用的方法先梳理用户路径和数据流统一前后端的状态约定博好测试再用浏览器把真实的流程跑一遍一份有用的Skill不能只写认真检查或者保证质量它至少要说清楚什么时候用需要什么具体怎么做怎样验证以及完成后返回什么Skill也不应该一开始就全部塞进Context平时Agent只需要知道有哪些Skill分别解决什么轮到当前任务再加载完整的内容而且Skill本身不会执行任务真正动手的是主Agent或者Sub AgentSkill只是让他们更稳定的工作方法有了Sub Agent和Skill系统已经知道谁来做也知道这类工作应该怎么做但角色和任务一多还是缺一件事谁先开始做完交给谁失败以后退回到哪里那负责安排这条接力关系的就是Workflow也是工作流他不亲自写代码也不替Skill归他不亲自写代码也不T-Skill规定做法他只把角色和任务接成一条有序的协作过程决定工作从哪里开始下一步交给谁遇到不同的结果又走向哪里放到应用开发的安理里workflow可以先把产品需求和开发计划接进来产品需求定义最后要做成什么开发计划把这个终点拆成有先后关系的任务一个定终点一个排步骤后面的角色才知道现在再决定下一站负责看全局分任务收结果的主agent通常叫做Ottestrator也就是总调度这种结构常被称为OttestratorWorker现在任务已经能按顺序传下去了可流程走到最后只能说明步骤执行过并不能证明结果是真的正确所以下一步我们要补的能力就是把结果真正跑出来拿到证据可以检查这就是Wordification也就是验证说白了就是别只听agent说他做完了我们要把功能真正跑一遍Worification还不负责评价结果好不好而是先用编译测试接口数据库和浏览器拿到可以检查的真实数据Type check build和单元测试通过只能说明一部分检查通过了把前端后端和后台worker真正跑起来再走一遍完整的用户流程问题马上露出来后台已经完成接口也返回完成状态页面却始终没有进入接轨页编译结果自动测试接口响应数据库状态浏览器录屏和服务日志都是验证证功能跑完以后我们已经知道实际发生了什么但证据还是需要有人对照验收标准判断这项任务到底能不能通过那这个负责独立判断的角色就是reviewerreviewer不负责替开发者解释自己为什么这样做他只做一件事情拿验收标准对照验证证据判断当前任务通过还是不通过一份有用的审核报告不能只写这里有问题他要说明哪条标准没有满足怎样浮现实际结果是什么证据在哪里以及建议先检查哪一段链路这样失败结果才能直接变成下一轮开发的输入修复以后系统重新跑同一套验证reviewer再检查一次这一次任务状态能从排队处理中一路走到完成页面自动进入结果页结果卡片预览和下载都正常当前任务到这里才算通过Reviewer是做判断的角色ReviewerGate则是一条流程规则没有审核通过就不放行审核还可以分成两层第一层看有没有做对用户流程是否完整接口与页面结果是否满足要求第二层看有没有做好代码质量测试安全性能以及有没有顺手改到无关的范围独立的Reviewer也可能判断失误所以能用type check接口测试 end to end数据库查询和浏览器行为回答的问题优先用硬证据需要综合判断的部分再交给Reviewer现在验证和审核都有了可流程异常最容易出问题的往往并不是不会做而是漏做代码改了主会话却忘了重新送审那把这种不能忘固定下来就需要hooksHook说白了就是某个事件一发生,系统自动做一件事情,他不负责判断功能对不对,而是把那些必须执行的动作钉在某个节点上。代码一改,Hook先把任务标详代审核,这一轮准备结束以前再检查一次,如果审核还没有发生,就提醒或者拦住不让流程悄悄地跳过去。Hook不负责审核,谁来审,没通过退到哪里,通过以后去答案里,仍然由workflow来决定。理解hook只需要抓住两个问题它挂在哪个事件上以及事件发生后做什么记录状态运行固定测试这类动作可以交给脚本需要理解内容时再调用模型或subagenthook是防漏装置不是万能保险它没监听到的改动就看不见审核通过以后代码又变了也必须重新的送审更严格的做法是把审核报告测试结果和当时的代码版本绑定在一起明确证明审的是哪一版到这里结果已经不只是被展示出来而是会决定当前任务通过还是带着证据返回修复这也是一条反馈环真正开始成立的地方这个最小反馈环已经可以在任何一项任务里面开发验证审核和反攻但如果整套流程纸活在当前绘画里绘画一中断循环也就跟着中断了要让它跨角色跨轮次甚至是跨绘画继续至少要保存两类东西现在做到哪里以及以后仍然有效的决定前者是state后者是memorycontext是当前桌面上摊着什么state是任务进度版现在做到哪一项是不是在等审核已经试了几次下一步试什么还剩多少轮述和预算Memory是长期的档案换了绘画甚至换了任务以后仍然有效的项目决定偏好和经验这三者不是按文件类型应分的而是看它们在系统当中起到什么作用比如当前任务审核失败保存在外部时属于state下轮重新读进来以后它又会成为当前context的一部分而数据库是任务状态的唯一数据员这种已经确认的框架决定后面的很多任务都会继续使用更适合进入到Memory每一轮都会产生大量的新信息但不是所有的东西都值得一直带着动态进度写进state跨任务仍然有效的决定经过确认以后进入到Memory下一轮真正需要什么再按虚夹载进context重复日志已经排除的线索和失败的结论就不要再继续占地方如果一直留在原绘画里聊天记录能保留一部分上下文但只要跨绘画继续当前任务进度状态审核状态还有关键证据就必须另外保存并且能够重新加载还要注意State只负责记住做到哪里它不会自己让任务重新开始到这里执行者分工方法流程验证和连续性都有了但这些组件不能悬在空中Agent还需要文件终端浏览器数据库和测试工具也需要权限隔离和保存的状态的地方把这些能力和规则接到同一套工作环境里就是Harness它不是另一个agent也不是一段特别长的prompt而是agent工作的整套的环境模型工具角色方法流程状态和权限都在这里被接到一起你可以把harness理解成agent的整张工作台最里面是codex在往外它能读写的项目文件能运行命令的终端能查看页面的浏览器以及不断返回的测试结果模型负责理解和判断harness负责把工作需要的东西接到他的身边拿刚才的应用开发案例来看产品要求、开发计划、不同角色、skill、workflow、hook、工具、状态、证据和权限全都在这张工作台上接到了一起把这张工作台设计的更稳定更清楚更容易验证和恢复这就是harness engineering所以几个概念可以这样分context是工作台上摆着什么Workflow是工作怎样接力Harness是整张工作台以及上面的工具角色规则状态和全新边界还要分清楚两件事说明里要求Agent怎样做和系统实际上允许他做什么并不是一回事Skill可以写核心链路必须跑until end完成以后必须送审这些是工作说明真正限制它能不能删除文件访问生产环境自动发布的是权限、隔离环境和工具本身的边界说明很重要但它替代不了系统级的限制如果任务还要读取issue PR评论Ci测试素材或者线上警告就要用连接器把外部系统接进来MCP在这里通常提供的就是访问这些系统的工具但接入外部系统只解决Agent能不能拿到信息调用工具还没有解决什么时候应该开始一项新工作并行工作也要有环境支持两个sub-agent如果会改同一批代码最好给它们独立工作区做不到隔离就按顺序执行不要为了追求并行让结果互相覆盖代码库和文档本身也是harness的一部分结构清楚规则一致agent才容易沿用正确的做法环境又乱又旧自动化只会把错误的信息复制的更快Harness本身不能保证结果正确验证权限和状态设计设计的好它会让开发结果更快更稳但如果标准含糊Revere只会点头权限又没有边界它也会让错误跑得更快成本堆得更高所以一套可用的Harness至少要有四件事能执行能验证能受控也能在中断以后恢复到这里我们已经搭出了当前任务没通过就反攻的反馈环但一个目标通常由多项任务组成当前任务通过以后系统怎么知道还缺什么又什么时候可以结束呢这就需要Go把多项任务收进同一个重点Prompt更像当前这一次任务的说明Go则是整个目标的完成清单系统最后要达到什么状态满足哪些条件才算真正结束最里面是agent自己怎样一步步执行再往外是当前任务怎样开发验证审核和反攻但这两层都只管眼前的这项工作前三项任务都通过了最后一项还没做当前任务通过不等于整个的产品完成因此还需要用go把多项任务和整个的产品的完成条件接起来go不能只写一句把应用做好他要把终点拆成可以检查的条件还要写清楚这次不做什么以及系统最多允许尝试到哪里轮数时间预算和风险边界都要提前设定好Agent不会天然知道是多少次算太多也不会自动判断哪里哪些操作必须要让人来批准够写清楚以后系统就知道终点在哪里但终点不会自己让任务跑起来还需要一个信号告诉系统现在开始从中段的位置继续这个信号就是TriggerTrigger只回答一个问题什么时候开始跑它可以启动一次新的运行也可以让中段的任务重新继续拿刚才的Go来看把它交给系统这就是一次Trigger如果任务中途停了之后由人、时间或者是外部事件再次发出信号也可以成为新的Trigger系统收到信号以后再读取State从保存的位置继续但Trigger只负责让运行开始或恢复它不判断整个Go是否已经完成Trigger和Hook我们很容易搞混但是你可以这样记Trigger是让一次运行开始或者恢复Hook是运行到了某个节点自动做一件事情提交Go是Trigger一轮结束前检查有没有漏审是Hook有了trigger运行可以开始有了state中断以后也能接上但每次任务完成一项那系统就会要判断整个go是不是已经满足还是否需要下一项这个判断交给evaluatorevaluator不审核某一项具体实现而是汇总所有任务的证据对照整个go只回答一个问题所有完成条件是不是都已经有证据了evaluator可以是一组自动检查也可以是专门评估结果的模型或者两者结合他不顶某一行代码而是拿全部证据对照整个go前三项都通过但下载失败提示和重视还没有证据他就会返回继续等最后一项也检查并审核成功才宣布目标完成一份当前任务审核通过的报告只能成为go证据包中的一页他证明了这一项完成了但不能替代其他的完成条件Evaluator不会凭空知道某项测试跑没跑也看不到其他stop agent没有返回的结果所以一句应该已经完成不够各项任务状态测试结果接口响应浏览器行为和reviewer报告都要整理成证据包跟着结果一起返回如果最后一项跨绘画之行前面讲过的state在这里会发挥作用把已完成任务当前审核状态证据位置以及剩余预算和轮数接到下一次运行新的trigger读取这些state后继续预算也会夸挥化累计否则每次恢复都要重新计数原本的成本上限就会失效到这里一条完整的go-based开发loop才真正闭合Trigger 启动工作Go 定义终点Workflow 选择任务Agent 执行Verification 拿到结果Reviewer 审核当前任务Evolator 判断整个目标审核失败就带证据反光当前任务通过但目标没有完成就继续下一项全部条件满足就结束碰到上线风险或严重的阻塞就保存状态交给人现在我们终于可以给Loop Engineering一个准确也最简单的判断标准不看用了多少个Agent也不看架构图有多复杂只看这一轮的结果能不能变成下一步把整套系统压缩一下其实就是五个动作确定当前任务完成任务检查结果保存进度再根据结果决定继续反攻结束还是交给人这时我们才真正从Harness Engineering走到Loop Engineering不过反馈回来以后还有一个更难的问题它到底应该写在哪一层有时候只是当前的代码本身没做到有时候是产品要求没有写清楚还有一些问题说明整套开发和审核方法都在反复的漏掉同一件事为了看清楚这三层的区别还是用同一个应用开发力假设回归测试新增了刷新页面和短暂断往后恢复两个场景结果同类问题再次出现后台已经完成页面却还停留在处理中同一条反馈可能要进入三个不同层级判断时先从最里面一层开始如果产品要求已经很清楚只是这次代码把completed映射错了或者轮讯条件没有结束那就把它当成普通bug修掉修改实现跑回归测试送独立审核通过以后结束这就是TaskLoop他只负责把当前的任务修到通过验收但如果问题总是在刷新、重联和失败恢复这些场景里反复出现,就要检查产品标准是不是太模糊。原来的要求只写,页面展示处理进度,却没有定义一共有多少种状态,谁是唯一数据员,完成以后怎样跳转,刷新以后怎样恢复,失败以后怎样处理,这时就应该回到产品要求,把它改成可以实现也可以测试的状态机,再更新受影响的开发和测试任务,这就会更新的状态。就是product iteration loop它不是让某一次测试碰巧通过而是把整个的用户流程的规则补完整让不同场景都能被一致处理如果标准已经写得非常清楚开发和审核却还在连续漏掉比如说漏掉刷新恢复和状态一致性那就不能只盯着产品和代码了这个时候要继续往外看看看Harness有没有问题这时该改的就不是某一项实现而是长期做法系统可以收集几次漏审证据让Subagent找共同原因再提出改进建议比如全站开发Skill里加入状态Skema必须统一让Reviewer必须检查刷新恢复或者把这两个场景写进自动N2N但长期规则不能因为一次失败就自动改写更稳妥的方式是先把建议和证据交给人确认批准以后再更新Harness并在后续的任务里继续观察效果这就是Harness Evolution Loop所以同一句后台已经完成页面还在处理中可能有三个取向修当前实现是Task Loop把模糊的状态规则改清楚是Product Iteration Loop让以后开发和审核不再漏掉状态一致性与恢复场景是Harness Evolution Loop问题越往外走影响范围越大需要的证据和人工判断也就越多前面三层回答的是反馈最后应该改到哪里接下来我们换一个维度这套Loop是谁启动的下一轮又靠什么接上常见的运行方式大致可以分为四种先说另一点它们不是四套完全不同的架构主要区别在于两个问题一次运行怎样启动启动后又靠什么继续那底层的skill workflow验证审核和停止规则完全可以复用第一种是Turn Based Loop也就是人一轮一轮往下推完成以后应该自动跳转还是留在任务列表带有明显的产品取舍Codex先做一版我们实际体验以后再发一条Prompt告诉他下一轮怎么调每一条新的Prompt都是一次新的Trigger这种方式最直接适合方向还在探索产品判断还没稳定或者每一步都需要人拍板的工作它的代价也很明显任务一长,人又会变成负责验收、整理反馈和催下一轮的人第二种是go based loop也就是围绕一个明确的目标持续推进如果开发范围和验收标准已经写清楚就不需要人每一轮都发继续当前任务没通过就返回修复通过但目标还有缺口就进入下一页所有条件和证据都满足才结束这种方式适合终点明确结果可验证失败以后也能安全重视的任务人仍然负责定目标滑边界设限制只是不再亲自推动每一轮前两种的差别我们可以这样记Term Based 是把下一轮做什么交给人那 Go Based 则是在同一个目标里根据证据决定继续还是结束那后面两种主要的改变是系统何时再次启动第三种是Time-based loop时间一到系统自动运行一次比如每天凌晨检查PR CI接口测试和关键的end to end时间只负责启动启动以后检查什么发现问题怎样处理什么时候结束仍然由workflow,go和停止条件决定下一次时间达到会产生新的trigger系统可以开始新轮的检查也可以读取state及其上次没有处理完的任务第四种是Proactive Loop你可以把它理解成给开发流程安排了一个长期值班新的bug、用户反馈、思言失败或者上线警告一出现系统不用等人发prompt就开始调查和处理低风险能复现的问题可以自动修复验证和审核碰到生产权限或者是高风险的操作就要交给人当前问题处理完这次任务结束外层的职守继续等待下一项工作Proactive的重点不是永远有一个模型不停运行而是没人实时发prompt时系统仍然能接收事件并启动或者恢复对应的任务四种方式可以相互牵套收到一条bug可以由Proactive系统启动一个go-based修复修到高风险操作再切回到churn-based让人做决定底层仍然复用同一套skill workflow verification reviewer和停止规则不过定时触发事件监听后台运行和任务的排队都需要额外的基础设施他们不会因为项目里写了几条规则就自动出现系统越能自己往下跑越应该先问一个问题这项工作到底值不值得进入loop能自动启动并不代表着它应该自动循环能够循环也不代表着它完全适合无人指手开发loop的价值是省掉反复跑测试整理bug推动下轮这些机械的工作但loop本身也有成本一条prompt能解决的事情硬要加上多个agent审核状态和调度只会把简单的问题变得更复杂所以搭loop以前我们通常要问六个问题第一,这项工作会不会反复出现,或者本身就包含很多步骤第二,输入和任务来源清不清楚第三,完成结果能不能检查,而不是只靠模型说应该好了第四,失败以后能不能安全重视,还是一次操作就可能造成不可逆的后果第五,它能动到的范围,权限和成本是不是受控第六,遇到高风险或拿不准的问题能不能顺利交给人条件越清楚,越适合进入loop并不是六项都必须完美才能开始但不清楚的地方越多试跑范围就应该越小拿刚才的应用开发力对照一下差别就很明显任务已经完成,但页面仍在处理中,能稳定复现,也能通过接口响应,数据库状态和浏览器图案验证,修改失败还能回轨,很适合做成GoBase的修复。每天检查PR,CI和回归测试本来就是重复的维护工作,也有清楚的输入和结果,很适合按时执行。但要不要把用户原始视频上传到第三方服务器不一样它涉及隐私、成本、合规和架构取舍Coding Agent可以调查方案整理风险但最后怎么选不应该交给无人职守的Loop自己决定至于只改一句按钮文案一条prompt很快就能完成没有必要为了看起来高级额外搭一套复杂的流程这些问题只能判断任务适不适合接入loop但它还不能说明适不适合无人职守要真正让系统跑得更久必须先装上几道刹车先限制最多跑多少轮多久花多少预算在还不知道一轮要消耗多少资源以前不要同时开放大量的sub agent第一次运行先从一个开发任务或者少量的bug开始看看Harness会卡在哪里是否约界一轮修复需要多少时间和成本再决定是否扩大能直接测出来的问题就交给工具http状态码接口字段数据库任务状态页面元素是否出现刷新后能否恢复下载请求是否成功这些都可以直接检测不需要每一轮都让大模型重新理解也没有必要每一步都使用最强最贵的模型简单分类一下格式整理和基础分流可以交给更快更便宜的模型复杂的排账创意取舍和安全的判断在升级模型或者交给人定时任务也不是越频繁越好调度频率应该和外部信息变化的速度匹配代码一天只变化几次那就没有必要每分钟跑一次检查删除仓库文件覆盖固定的素材自动部署修改生产数据或者把用户真实的视频上传到第三方服务器这些不可逆或者是高风险的动作默认应该先从让人确认开始而且这套判断不只适应于写代码研究实验可以根据指标决定保留是否回退运维系统可以处理警告再验证是否恢复数据处理和内容制作也可以检查来源修订结果再跑一轮共同点不是他们都用了codex而是每一轮都能得到反馈结果能够验证失败以后还能安全重视如果这几件事做不到系统越主动风险反而越大任务选对了权限和预算也限制住了最后还差一件事情系统怎么知道继续尝试已经没有意义了什么时候应该停下来停下来以后又怎样把当前的状态完整的交给人一条loop会停会交接才算真正的收控停止条件不能只写一句,做完就停。目标完成当然要停,轮数、时间或预算到上线也要停。连续几轮没有新证据说明系统可能在空转,碰到权限、安全、隐私或不可逆操作要让人接手。工具不可用,产品要求互相冲突,甚至原目标已经失效也应该停下来冲整。停下来不等于任务失败已经没有新信息却还沿着同一个方向机械的重复才是真正的危险比如回归测试发现在当前绘画里任务可以正常完成可以刷新页面任务记录就丢了结果页也无法恢复第一轮修改前端轮巡虽然没有修好但确认后台worker和状态接口一直正常排除了后台处理超时第二轮统一完成映射状态当前页面可以进入结果页却进一步暴露出刷新后JobID和状态无法恢复问题范围缩小了这两轮都失败了却仍然有进展到了第三轮新增本地恢复逻辑没有改变结果服务日制和Ntun与上一轮完全一样没有新证据也没有积蓄缩小范围再用同样的方式去试就开始空转了而我们给这类修复设定的上限正好是三轮所以此时停止应该自动重视不过没有变化不一定代表卡住修bug连续几轮没有新证据可能说明该停下来但每天巡检连续10天都没有新的CI失败反而说明系统运行正常三轮也只是这个例子里的上限并不是固定规则只要还有新线索就可以继续如果第二轮已经原样恢复也不需要为了凑数硬跑第三轮当继续尝试已经没有任何意义下一步不是再赌一次而是把问题完整的交给人这就是hand off交接不能只留一句做不了接手的人应该能在几分钟内看清楚前面发生了什么已经排除了什么现在需要他决定什么所以停下来以后系统应该交出一份真正可以接手的材料当前状态已经试过什么每次尝试对应什么证据以及现在需要人判断什么人把这些材料放到一起以后发现问题并不只是某一个轮循条件写错而是后台Worker API和前端各自定义了一套状态名称同时有一部分任务状态只保存在进程内存里刷新以后自然无法恢复人补充架构决定数据库成为唯一数据员所有层共同用同一层状态schema系统重新整理Go,Context和State再启动一轮修复接口测试和关键的N2N全部跑通Reviewer才返回审核成功这也是Handoff最重要的价值人接手时看到的不是一盏模糊的绿灯而是系统依据了什么证据试过哪些方向为什么积蓄又为什么停下来自动化省掉的是重复操作不是把判断责任隐藏起来现在把前面搭出来的结构收回来再看一遍loop engineering不是先画一张复杂的架构图再往里面塞一串名词它是从最小的任务开始每出现一个新的缺口就补上一种能力prompt把当前任务说清楚agent让任务真正被执行agent做判断需要更多的信息于是有了context一个角色处理不过来就用sub agent拆分任务和上下文不同角色的做法不稳定就用Skill固定方法角色和任务需要接力就用Workflow安排顺序结果不能靠Agent自己宣布就加入WordificationReviewer和ReviewGate关键步骤容易漏掉就用Hook自动检查任务腰胯轮次积蓄就用State保存进度用Memory保留长期信息再用Harness把工具角色规则权限和运行环境接到一起最后Go定义整体终点Trigger负责启动和恢复Evolator根据全部证据决定继续还是结束到这里几种Engineering的关系就清楚了Prompt Engineering把任务和说明设计清楚Context Engineering把信息的分配和流动设计清楚Harness Engineering把工作环境和边界设计清楚而Loop Engineering负责最后一件事情让这一轮的结果或者新的外部反馈真正回到流程里并且改变下一步它们不是谁取代谁而是一层层叠加最后形成完整的反馈闭环而当这条循环接起来我们最大的变化不是以后不再需要人了而是人不必再卡在每一轮中间反复运行应用检查代码跑测试整理bug写附线步骤再催下一句继续开发人的工作会往上移开始定义目标边界在关键的节点检查证据在高风险和不确定的地方负责拍板好了以上就是本期的全部内容同时在废材俱乐部也有非常多的我精心设计编排的实战案例可以直接使用形成生产地也可以去系统的学习他们了解我的设计思路以及方法我的核心理念就是方案就是教程教程就是方案我们应该在干中学所以欢迎加入废材俱乐部我们也可以一起讨论如果你还觉得不错别忘了给我们点赞关注这对我们真的非常重要也是特别大的支持那我们下期见

这一期我把我自己从零开始学习 AI Coding 直到现在，从 Prompt 一直到 Loop Engineering 的完整学习路线分享出来。
在视频当中，我会告诉你Prompt、Agent、Skill、Hook、Harness、Loop 该如何串联。同时，我也会详细拆 Prompt Engineering、Context Engineering、Harness Engineering、Loop Engineering 这四个发展阶段以及设计思路。
总之，看完这期视频，你应该会对学习 AI 有一个非常清晰的学习路线以及进阶过程。这个过程是我自己实操的，也是我这两年亲身经历的学习路线。

00:00 什么是 Loop Engineering
02:16 Prompt Agent 与 Context
05:24 Sub-agent 与 Skill
08:32 Workflow 验证与审核
12:17 Hook State 与 Memory
15:28 Harness 与 Goal
19:38 Trigger Evaluator 与完整 Loop
23:08 反馈层级与四种运行方式
29:14 哪些任务适合进入 Loop
33:07 停止条件与 Handoff
36:25 总结