最近主流的agent框架都引用一个human-in-the-loop(HITL)的概念。 在我的使用经验中，最先给我HILT概念的产品就是像cursor一样的agent+ide. 我们先回顾一下大模型应用的历史，在gpt横空出世的时候，人们接触到的就是一个Agent结构：
用户提问->大模型回答->用户再问->大模型拿到上文和当前问题，再回答... 【举例】
对吧？当大模型没有准确理解问题，或者因为缺少用户信息而无法给出准确回答时，用户会补充这部分信息。 在这之后，不论是加上什么形式的tool use，这个大的框架都是没有发生改变的。Thinking和React是值得一提的结构改动，它发生在大模型回答的内部，我们在使用agent的过程中会看到ai会先做一些陈述，再组织一次网络搜索，根据搜索结果调整查询的关键词。
大模型思考/规划->大模型使用工具->大模型查看结果后再次使用工具->...->大模型回答 【举例】
乍一看似乎现在已经有human-in-the-loop的概念在了：用户第二次追问和补充的过程某种程度上就是人在和agent协作过程中的纠偏。但是在这个纠偏的表现上，二者却有很大的不同。 我们来举个例子。
我们让AI来规划从A到B的路线。 Agent不论有多少tool可以用，react了几次，用户和agent的交互过程是这样的： 用户描述A到B的路线->Agent给出回复->用户不满意补充描述->...->用户满意Agent的回复。 每一次提问后Agent都会给出一个完整的路线规划。
而在HITL的概念中： 用户描述A到B的路线->Agent给出了一段分析，询问用户是否符合用户的理解->用户纠正了Agent描述不正确的地方->Agent开始生成路线->用户认为有一些地方不对，纠正了Agent->Agent调整->遇到可选岔路，Agent询问->用户选择->...->Agent给出路线
看到这里的区别了吗？就像在自动驾驶的时候，人类驾驶员的主要职责不是在汽车快要撞墙的时候踩刹车（当然这也很重要），而是在任何有危险倾向的时候提前调整方向盘和速度，对吧？HITL就是在这样的假设中诞生的，因为我们发现一切对于one shot的期望都是不切实际的。 站在产品设计的角度，我们也需要考虑这件事情：Agent经常没办法把事情做好，而用户每次在等待了两分钟（甚至更久）之后得到了错误的答案，这是很有挫败感的——甚至这个错误的答案源于Agent自己输出的第十个token。 我们把Agent在用户完成一项任务的过程中，全自动驾驶的时间给划线。
Agent： --------------- human check ---------------- HITL： -- human ---- human - human ----- human -----
有一个很有意思的产品对比是claude code 和 cursor。 这两个产品有相同的部分：对项目的查询、操作、在命令行界面里的运行、联网搜索、对长任务的planning和执行。
【配图】
这两个产品也有原生体验上非常不一致的部分。 我们常常把检查claude code上运行结束的任务叫作“收菜”，很形象吧？布置任务则是“播种”。很多人会在睡前“种菜”，然后在claude code运行一个晚上之后，起床检查claude code的运行结果，再次布置任务。尽管听起来挺方便，但就像真正的播种之前需要开垦、施肥、除杂一样，claude code想要运行一个晚上，也需要做大量的准备工作，包括但不限于各种项目组件的文档和操作指南。这些文档通常也需要一些架构经验和数小时的写作，当然，这一步本身也可以和AI写作完成。这样的做法优点显而易见——简直就像你雇了一个7-24响应的员工，对吧？这个员工还可以在几分钟内一口气输出几千行代码，并且自己测试、迭代。 这听起来不错吧？AI取代程序员的说法正是源自于此，毕竟token比人便宜多了，而Anthropic还提供过二百刀每月的畅吃套餐，这笔钱或许只够请一个不错的程序员一天。
【配图】
但是你同样会遇到（大量）这样的问题：一个晚上过去，你发现Claude Code写出来的东西完全没法用。 当然这可以被解释成项目结构和文档定义不清晰，或者AI偶然在一个错误的认知上坚持到底了。 咋办？回退了改改再跑一次呗。
对于Cursor来说，事情会有一些不同，但这些不同不全是往好的方向变化的。 Cursor是从VS Code上再次开发的，我会说这是伟大的想法，因为它在最开始就满足human-in-the-loop的设计逻辑。 对于Cursor来说，它主要的Agent功能执行时长大概在1-5分钟，并且你可以随时打断（主要原因是你会经常看进行到什么部分了）。
【配图】，