悄然扼杀提示工程的四个循环

每晚提升1%，一年后就是37倍。1.01^365 = 37.8。

LangChain刚刚发布了这套四循环打法，让你在睡梦中就能实现这个目标。

大多数人还在手动输入提示词，一个代理、一次请求地操作。

把这四个循环叠在一起，你的代理就能自己评分、修复、重写。你入睡时和醒来时，它已经变得更强了。

我本人几乎一整年都卡在第二级。我认识的每个做这类东西的人几乎也都是如此。循环工程那个话题同一周内播放量达到650万，而LangChain也在那周发布了这套打法，我觉得没有一个人注意到它们其实是同一回事。

模型早已不是瓶颈。剩下的就是围绕它的“缰绳“，而这条缰绳本质上就是循环套循环。

整套理念归结为一个转变：你不再是那个给代理输入提示的人，而是去构建那个替你给代理输入提示的系统。

四个阶梯。大多数人在第二级就不声不响地掉队了。

循环1——代理循环

模型调用一个工具，读取返回结果，再调用另一个，一直进行直到任务完成。你已经有这个了。

/ 给它上下文

/ 给它工具

/ 让它一直运行直到“完成“

LangChain原语：create_agent。

这是地板，不是天花板。停在这里，你实际上只是得到了一个花哨的自动补全。

循环2——验证循环

代理完成输出后，不再由你来检查结果，而是由一个评分器根据标准对其进行打分。如果低于阈值，反馈直接传回，让它再试一次。不需要人工站在旁边点击重试。

/ 针对枯燥内容做确定性检查（链接能解析、CI通过、范围与需求匹配）

/ 针对模糊内容用LLM-as-Judge（它是否真正回答了问题）

LangChain原语：RubricMiddleware。

没错，每个任务大约会多消耗2-3倍的token。但你花的只是几分钱，而代理就不会把错误答案交给客户了——生产环境中一个错误答案的代价，远超一千次重试。

这就是90%的人停下的地方。也恰恰是，一直藏在眼皮底下的价值所在。

循环3——事件驱动循环

到了这个循环，它就不再等着你打开终端了。

#docs-plz 频道里的一条消息就能触发它。一个Webhook就能触发它。一个我半忘记设置的凌晨3点cron任务也能触发它。没人去手动调用它。它就在你整天使用的工具内部自动运行，规模不限。

/ 无需人工发起

/ 就在你工作的地方运行

LangChain原语：带cron/Webhook的LangSmith部署，或Fleet channels。

到了这一步，它就不再是你去访问的某个应用了。它变成了一个永远在线、从不开发票的同事。

循环4——爬山循环

这个循环我花了好一阵子才真正相信。

每次运行都会留下一条轨迹。这些轨迹会进入一个分析代理，由它来读取、识别那些反复出现的失败点，然后重写循环1中的提示词和工具配置。

因此，返回箭头并不是回到最顶端。它直接深入内部，修改了代理本身。

/ 系统自己注意到它哪总出错

/ 然后自我修补配置

/ 你合上笔记本，醒来时得到一个更强的代理

LangChain原语：LangSmith Engine。

[插入截图：嵌套循环图——loop-engineering-diagrams.html]

LangChain广告意外说对的那部分

有趣的是，这是一篇LangSmith的广告，但它说的完全正确。

循环1和2是所有人都在挤的地方。更好的提示词、更好的模型、更好的评分器。人满为患。

循环3和4基本是空的。这就是整片蓝海，摆在你面前。

明年胜出的公司，不会是拥有最好模型的那家。大家都租用同样的模型，同样的权重，同样的价格。胜出的是那些能让自己的代理每晚自动进步1%、持续一年、而竞争对手还在手动输入提示词的公司。37倍，如果你相信这个数学的话。

提示工程曾有过好日子。但它已经被构建替你提示的循环这一看似枯燥的技能所取代。

至于最后一个循环？没人需要给它提示。它自我提示了。