Loop Engineering是AI Agent开发的新范式，通过设计循环机制让Agent自动执行编码、修PR、跑测试等任务。本文拆解定时任务、工作树隔离、知识体系、MCP连接器和子Agent五大组件，强调定义可验证目标的核心能力，适合希望提升AI编程效率的开发者。
Tags:
https://github.com/KKKKhazix/khazix-skills
大多数讲Loop Engineering的文章，都停在了这一层。
讲了五个组件，讲了/goal和/loop命令，讲了怎么配定时任务，就结束了。
这些我觉得，都是术。
而我更想聊的，是道。
回到前面说的/goal，它的用法看起来非常直接，给一个完成条件，Claude自己干到满足为止。
听起来很简单对吧。
但你如果真正用过就会知道，/goal用得好不好，完全取决于你那个目标定义得好不好。
这个事我拿两个例子对比一下你就明白了。
目标A，「把这个应用优化一下」。
目标B，「test/auth目录下所有测试通过，tsc --noEmit零报错，npm run lint零违规」。
目标A会发生什么呢。
大家可能都能猜到，Claude会陷入一种非常尴尬的状态，因为它不知道什么叫「优化好了」，除非他是Fable 5，能自己在你之上，自主的帮你定义目标。
而绝大多数的模型，包括Opus 4.8和GPT-5.5，在自己定义目标的能力上还是非常的弱，它可能改了一点代码，然后自己觉得还行，就停了。
也可能不停，一直改一直改，把你的代码库改得面目全非，因为它始终无法判断自己到底什么时候算完成了。
那目标B呢？Claude每改一轮代码，都会去跑测试、跑类型检查、跑lint。三个命令，三个明确的通过标准。
全过了就停，没过就继续，清清楚楚，干干净净。
同一个工具，同一个模型。
区别只在于，你的目标定义得好不好。
我自己其实一直有一个原则，我经常跟身边的人说，在公众号里也说了无数遍，如果一件事你重复做了三次，你就一定要想办法把它完全自动化掉。
这个习惯跟了我很多年了。
我每天也都在写代码、做自动化，我们的AIHOT热点监控系统，我们的数据分析流程，我们的财务对账流程，我们的数据清洗管道，能自动的我全部自动了。
但说实话，在做这些自动化的过程中，我踩过最多的坑，从来不是技术问题。
是目标不清晰的问题。
我早期做自动化的时候，经常犯一个错，就是目标定得太模糊。
举个例子，比如自动监控AI行业热点，这句话听起来没毛病，但其实是一句纯粹的废话。
什么叫热点？浏览量过万算热点还是过十万算热点？抓取频率是每小时还是每天？抓到以后怎么评估质量？评估完以后怎么排序？排完以后怎么推送？
这种反问的问题，我现在可以直接随手问20个以上。
每一个环节如果没有明确的判定标准，整个自动化链条就是一坨狗屎，你相信我，绝对的。
这其实就是/goal的逻辑。
也是Loop Engineering的灵魂。
你跟员工说，“把这个功能做好”，那他做出来的东西大概率不是你想要的。因为你脑子里的好跟他脑子里的好不是一个东西。
你跟他说，“这个接口的响应时间降到200毫秒以下，错误率控制在0.1%以内，下周三之前上线”，他做出来的东西跟你预期的偏差就会小很多。
因为你给了他一个可以验证完成的标准。
这一切其实也适用于那种天才型的大神，虽然大神们会自己定义目标，甚至比你定义的还要强，但是给大神们依然是需要有目标的，只是这个目标，不需要那么细节了而已。
对人如此，对AI也是如此。
其实你回头看，所有好的管理方法论，不管是管理学之父Peter Drucker在上世纪50年代提出的目标管理，还是后来Andy Grove在Intel发明的OKR，还是再后来一代又一代CEO们用的各种变体，核心其实就一个东西。
你能不能把一个模糊的意图，翻译成一组可衡量、可验证的完成条件。
管理者要做的，是确保目标足够清晰、资源足够充足、反馈足够及时。
你看这三条。
跟一个好的loop的三个要素，是不是一模一样。
目标清晰，就是你的条件写得精准。
资源充足，就是你给Agent配好了Skill、连接器、工作权限，让它手里有足够的工具干活。
反馈及时，就是你设计了验证机制，每一轮都有一个独立的检查器告诉Agent做得对不对，哪里需要改。
管人的逻辑和管Agent的逻辑，是完全一样的。
只不过，管Agent比管人还要极端一些。因为人可以理解你的模糊意图，人可以主动来找你确认，人可以说老板你这个需求说得不太清楚我不太确定你是不是这个意思。
Agent很多时候是不会的。
Agent会非常自信地按照它自己的理解去执行，然后非常自信地告诉你它做完了。
所以，对管理能力的要求，其实比管人还高。
这也是为什么我一直说，AI时代我最讨厌什么「文科已死」「理科已死」的言论，管理学、心理学、组织行为学这些，不但没死，反而变得更重要了。
说到底，Loop Engineering说是Engineering，但我觉得其实它的核心竞争力根本不在工程。
在管理。
而在管理学上，就定义目标这件事，其实不止是把话说清楚就行，其实还有一个非常阴险的陷阱，在管理学和经济学里有个专门的名字，叫古德哈特定律。
当一个衡量指标变成了目标本身的时候，它就不再是一个好的衡量指标了。
翻译成人话就是，你考核什么，员工就只做什么，然后其他东西可能全都退化。
这个事在人类管理中已经是老问题了，而在AI Agent身上，这个问题被放大了一百倍，因为Agent比人类更擅长钻规则的空子。
有人总结过Loop Engineering里很好玩的事情，就是Agent会针对验证器做优化，而不是针对你真正的目标做优化。
比如说你的loop条件是让测试全部通过，那Agent可能最后不去修Bug，直接把失败的测试给你删了。
你看，最后答案依然是测试全过了，完事，从验证条件来看，它确实完成了目标，但从你真正想要的结果来看。。。它啥也没干。
人也会这么干，只不过，Agent做得更快、更彻底、更没有心理负担。
所以，一个好的目标定义，不能只有做完了的标准，还必须有不能怎么做的边界。
这其实就是Harness Engineering在Loop Engineering里面发挥作用的地方。
Harness是约束，是护栏，是告诉Agent你可以自由发挥，但这条线你不能越。
Loop是驱动力，是告诉Agent往那个方向一直跑。
两个加在一起，才是一个完整的系统。
到这里，骨架讲了，灵魂也讲了，陷阱也讲了。
Loop Engineering的东西，终于也差不多了。
最后我想把前面聊的管理学的思路收一下，给一个我自己用得比较多的目标定义框架，不一定科学，纯粹就是我自己的一点点经验。
1. 完成标准要可以被机器验证。
2. 边界条件要跟完成标准一起定义。
3. 要有失败的降级方案。
4. 目标要分层。
回到整条线来看，从Prompt到Context到Harness到Loop，四次跃迁，其实讲的是同一个故事。
Prompt Engineering告诉你，好好说话，AI会更懂你。核心能力是语言表达。
Context Engineering告诉你，光说话不够，得给AI足够的信息。核心能力是信息筛选和组织。
Harness Engineering告诉你，光给信息也不够，得给AI设规则和约束。核心能力是系统设计和规则制定。
Loop Engineering告诉你，光设规则也不够，得让整个系统能自己跑起来。核心能力是目标定义和管理。
语言学、信息科学、控制论、管理学。
四个Engineering，四门古老的学科。
多有意思。
人类社会，其实从来就没有变过。
以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～谢谢你看我的文章，我们，下次再见。
>/ 作者：卡兹克
>/ 投稿或爆料，请联系邮箱：wzglyay@virxact.com
没有评论:
发表评论