从一句一句问,到让 AI 自己循环:我重新理解了 Human in the Loop

前几天，我在上一篇 ZCode 文章下面看到一条留言。

对方晒出的数据是：

累计使用了 328.6 亿 Token 。

峰值一天用了 35.1 亿。

最长的一次会话，持续了 1 天 22 小时。

当前已经连续使用 31 天。

一个哥们在评论区晒图。累计 Token 、会话时长和连续天数只能说明高频使用，不等于代码质量，也不等于人连续清醒工作的时间。

我盯着这串数字看了很久。

不是因为它足够夸张。

而是因为数字背后的问题，正好戳中了我最近使用 Agent 时最累的地方。

我一直在问 AI 。

每一步都在问。

问完一个问题，等它回答；觉得可以了，再让它做下一步；做完之后，我再打开页面、看结果、判断对错，然后把新的问题发回去。

表面上，我在使用一个很聪明的工具。

实际上，我才是那个不断被唤醒、读取上下文、判断状态、重新调度的循环。

后来，评论区里的兄弟说了一句话：

自己编了个软件，审计、修复、复核，拓展新功能，循环。

评论区留言截图。除了“审计、修复、复核、扩展”的流程，截图里也有人提醒：生产项目没有人管，自动化会直接偏离需求。

那条反问其实很重要。

它把“328.6 亿 Token”背后的另一面说出来了： Agent 能跑多久，和它该跑多远，不是同一个问题。

那一刻，我突然意识到：

我过去可能一直没有真正学会使用 Coding Agent 。

我只是把原来由自己完成的工作，拆成了一句一句更短的命令。

一、过去我不是在驾驭 Agent ，我是在做它的人肉事件循环

一开始使用 Coding Agent ，我的方式很简单。

问一个问题。

等一个答案。

我说“好”，它继续做一点。

如果哪里不对，我再指出来。

这种方式在刚开始很好用。

因为它让我确认 AI 到底能做什么，也让我保有一种很踏实的感觉：每一步我都在场。

但任务一长，问题就出来了。

我明明只是想让 Agent 完成一个功能，最后却变成了我在不同窗口之间来回切换。

它改完之后，我去看页面。

页面不对，我截图发给它。

它修完，我再刷新。

刷新之后，又发现了新的问题。

我再复制报错。

它再改。

我再看。

每一次看起来都只是一步。

可几十步连起来，人的注意力就被切成了几十块。

我并没有因为 AI 写得快而轻松。

我只是从一个亲手写代码的人，变成了一个更忙碌的验收员、传话员和调度员。

后来我开始用 Plan 。

先让 Agent 给我一个完整方案，我再补充约束，修改路线，最后让它按计划执行。

这确实比以前前进了一大步。

至少它不再是一问一答地走路，而是先看地图，再出发。

但 Plan 并没有解决所有问题。

因为计划只能告诉我“准备怎么做”。

执行过程中，它仍然会停下来等我确认，会遇到测试失败，会做出和我想法不一样的取舍，也会在某个局部问题上反反复复。

于是我又回到了那个熟悉的动作：

看结果，判断，补充要求，继续。

Plan 缩短了从想法到方案的距离。

但人的注意力仍然被困在执行过程里。

直到我看见那个读者的循环，我才慢慢想明白：

问题不在于 Agent 够不够聪明。

问题在于，我还没有把一段工作设计成一个可以持续运行、可以验证、可以停下来的闭环。

我一直在优化提示词。

却没有优化工作本身的结构。

二、 Loop Engineering ，不是让 AI 一直说“我还能做”

我现在理解的 Loop Engineering ，不是写一句“继续做，直到完成”。

也不是让 Agent 在一个窗口里不停地写下去。

它更像是在设计一段委托关系：

把一个目标、执行动作、验证证据、修正规则和停止条件，连成一套可以重复运行的工作机制。

一个最小可用的 Loop ，至少要有五个部分。

第一，目标。

这一轮到底要完成什么，完成的标准是什么。

第二，状态。

上一轮做到哪里，下一轮从哪里继续，中间留下了什么。

第三，动作。

Agent 被允许改什么、读什么、运行什么，不能碰什么。

第四，证据。

怎么证明它做了，怎么证明它做对了。

第五，退出和升级。

什么时候算结束，什么时候必须暂停，什么情况下要叫人。

把这几件事连起来，才是一个真正的循环：

目标 → 执行 → 证据 → 验证 → 修正           ↑               ↓           └──── 再循环 ────┘ 

这里最重要的一环，不是执行。

是证据。

没有测试、日志、差异、截图、真实运行结果，所谓的循环就只是让模型继续生成文字。

它可能会很勤奋。

也可能会很自信地跑偏。

所以，“继续”不是 Loop 。

“继续”只是让会话别停。

真正的 Loop ，必须能判断这一轮到底有没有产生有效变化，还要在连续失败时主动刹车。

这也是为什么 Coding Agent 是最适合先做 Loop 的场景。

代码有测试、编译、日志、 Git diff （代码差异）、 CI （持续集成）、分支和回滚。

它比写文章、做研究、做决策更容易获得机器可读的证据。

同样一套思路不是不能迁移到其他工作，但验证器会完全不同，不能简单照搬。

三、真正跑起来的 Loop ，长什么样

那个读者说的流程，看起来很简单：

建立基线   ↓ 审计现状 → 修复问题 → 复核证据   ↓                         ↑ 扩展一个小功能 ─────────────┘ 

但它比我一开始理解的“让 AI 修 bug”要成熟得多。

先审计，是让 Agent 知道当前系统有哪些问题，而不是一上来就写代码。

再修复，是每次只处理一个可以验证的问题。

然后复核，是用测试、日志或实际运行结果确认修复真的成立。

最后扩展功能，是在相对干净的基线上继续往前走。

这个顺序解决了一个非常实际的问题：

Agent 最擅长的不是一次写出完美代码。

它擅长的是在一个边界清楚、反馈及时、可以重复修正的系统里，持续推进。

当然，关于这位读者的数据，我也想主动把口径说清楚。

328.6 亿 Token ，不等于产出了同样多的有效代码。

1 天 22 小时的会话时长，也不等于一个人连续清醒工作了 22 小时。

连续使用 31 天，更不等于 31 天没有睡觉。

这些数字证明的是一件比较朴素的事：

他长期把 Agent 留在真实任务里，而且很可能已经形成了比较稳定的循环方式。

这比单纯讨论“用了多少 Token”更有价值。

我最近还看了 Lauren Tan 的公开分享。

她在 Cursor （现 SpaceX AI ）工作。她讲自己如何使用 Agent 、如何建立验证工具，以及如何从“人盯着一个 Agent”慢慢走向多个 Agent 一起工作。

Lauren Tan 在公开分享中谈 Agent 验证与信任阶梯。

网上很容易把注意力放在一个数字上：她公开分享里出现过一个月提交或合并的 PR （代码合并请求）达到四位数的说法。

但我觉得数字不是重点。

真正值得看的是，她不是靠一句“帮我写完这个功能”就得到这个结果。

她花了很长时间做验证工具，让 Agent 可以自己运行应用、读取运行轨迹和性能记录、看页面、操作真实的开发流程。

然后才把这些工具、规则和验证方式交给 Agent 。

她把这个过程叫做“信任阶梯”。

这个说法很准确。

信任不是从“我愿意相信 AI”开始的。

信任是从“我能看到它做对了，而且它也能自己看到自己做对了”开始的。

所以， PR 数量只是结果。

验证能力、规则约束、可重复的循环，才是原因。

同样的逻辑，也出现在 Manus 的公开分享里。

Manus 联合创始人张涛在一篇公开文章里提到，公司内部有工程师可以同时推进十几、二十个需求。

在他的描述里， AI 已经不只是帮忙补几行代码，而是会读需求、找代码、修改、在本地验证、走测试流程，然后提交上线申请。

一个需求大致走七步。

AI 接走其中五步。

人守住提出需求和上线审批两道关。

根据 Manus 联合创始人张涛公开文章整理。图里是 Manus 的内部实践，不是行业统计。

他把这种变化称为：

从 Human in the Loop ，走向 Human on the Loop 。

这句话很关键。

因为它把问题从“人要不要使用 AI”，推进到了“人应该站在哪一层”。

四、 Human 到底要不要 in the loop ？

我以前对这句话有一种很朴素的理解：

只要人还在检查，就是安全。

现在我不这么看了。

Human in the loop 本身不是安全证书。

它只是一种控制方式。

如果一件事需要人每一步都点确认，但人已经因为上下文太长、任务太多、反馈太密而失去判断力，那这种“in the loop”可能只是盖章。

看起来有人负责。

实际上没有人真正看清。

所以我不再问“人到底要不要 in the loop”。

我会先问三个问题：

这件事的风险有多大？

它可不可以撤销？

我有没有足够的证据判断结果？

答案不同， Human 的位置也应该不同。

我现在更愿意把它分成三层。

Human in the loop

人直接参与关键步骤，查看过程，做决定，按确认。

适合高风险、不可逆、目标还不清楚的工作。

比如动生产环境、改支付链路、处理客户数据、使用高权限凭证。

这类事情不能因为 Agent 跑得快，就把人的判断提前外包。

但要注意， in the loop 的前提是人真的看得懂、来得及看、并且拥有否决权。

没有上下文的确认，不是监督。

Human on the loop

人不站在每一次动作里面，而是站在循环外面设计规则、观察指标、抽查结果、处理异常。

适合任务边界清楚、可以反复验证、错误成本相对可控的工作。

比如代码重构、测试补齐、静态检查、文档更新、局部性能优化、在隔离环境里修复 bug 。

这也是我现在最想练习的位置。

它不是“人不管了”。

它要求人做更难的事：

定义目标。

设计验收标准。

建立证据链。

设置停止条件。

在异常发生时及时接管。

如果没有日志、测试、成本和权限边界，所谓的 on the loop 只是自我安慰。

因为你看不见它，也就谈不上监督它。

Human out of execution

人完全不参与具体执行，只保留边界、审计权和最终责任。

适合沙盒、低风险、可回滚、可验证的任务。

比如只读审计、生成候选方案、在独立分支里改代码、在测试环境反复跑用例。

这里的 out ，是 out of execution 。

不是 out of responsibility 。

责任依然在人这里。

只是人不必再站在每一个操作前面。

三层不是固定等级，而是根据风险、可逆性和可观测性选择的位置。

这三个位置没有高低。

只是适用的风险不同。

对于不可逆的事， Human 应该 in the loop 。

对于重复、可验证的事， Human 可以 on the loop 。

对于低风险、可回滚、隔离环境里的执行， Human 可以暂时 out of execution 。

但无论在哪一层，责任都不能消失。

这也是为什么我看到 Manus 那个“AI 自己跑了一个周末，回来留下 200 多个决策”的细节时，印象特别深。

执行可以被自动化。

判断不会自动完成。

你让 Agent 多跑一天，可能不是少了一天的工作。

只是把一天里的很多执行，变成了第二天需要人集中处理的决策。

这不是效率的全部。

它只是把工作从“动手”转移到了“拍板”。

如果人没有能力消化这些决策， Loop 越多，积压越多。

五、 Loop 会把效率放大，也会把错误放大

我现在不会一上来就追求长循环。

因为长循环有两个非常现实的问题。

第一个问题是目标漂移。

目标写得越模糊， Agent 越容易用很多轮努力，去证明一个错误方向是“合理”的。

你看到的是一堆代码、一堆日志、一堆修改。

但它可能离真正重要的事情越来越远。

第二个问题是自我验证偏误。

Agent 自己写测试，自己运行测试，自己判断通过。

从流程上看，它闭环了。

从结果上看，它可能只是用自己生成的标准，证明自己生成的答案。

如果没有独立的检查器，它很有可能会把这种“看起来完成”误认为“真的完成”。

除此之外，还有上下文污染、 Token 失控、 PR 洪水、权限风险和不可逆操作。

一个循环开得越久，错误被重复、放大和隐藏的机会也越多。

所以我现在更愿意把 Loop 的护栏和 Loop 本身放在一起设计。

先用只读模式审计。

再让 Agent 生成修改建议。

然后才允许它在分支里小范围修改。

修改之后必须有测试、日志、代码差异和真实运行结果。

关键操作保留人工审批。

长任务设置最大轮数、 Token 预算和停机条件。

一旦连续几轮没有进展，就停下来，不要让它用更多轮次掩盖卡住的事实。

最后，涉及生产环境、客户数据、资金和不可逆动作时，人必须回到 Loop 里。

这不是对 Agent 不信任。

这是对后果负责。

六、我后来发现，真正被释放的不是手，是注意力

我最近听「人民公园说 AI 」的一期节目，里面反复提到一个观点：

AI 最贵的不是 Token ，是人的注意力。

这句话我一开始没有太深的感受。

毕竟额度、账单、调用次数都是看得见的。

注意力没有账单。

它藏在一次次切换窗口、重新读上下文、判断结果、补充要求的动作里。

你没觉得自己在忙。

但到了晚上，你会突然发现，自己一天只在做一件事：

不停地把自己重新塞回工作现场。

而 Loop Engineering 真正改变的地方，就是把这部分反复发生的“重新进入现场”交给系统。

Agent 可以并行。

人可以同时盯三四个有上下文的窗口，但再往上，判断质量会快速下降。

这不是一个精确的科学结论。

只是我最近越来越强烈的体感。

当我把注意力从每一个执行步骤上撤出来，放到目标、验收和异常上时，我反而能看到更多。

我开始关注：

这一轮到底有没有产生有效变化？

这个验证器是不是真的能发现问题？

哪些动作可以自动做，哪些动作必须停下来？

我是不是在用更多的 Agent ，掩盖自己不敢做判断？

这些问题没有一个能靠“再开一个窗口”解决。

但它们比不断复制报错、刷新页面、催 Agent 继续，更接近真正的工作。

所以，人的认知突破有时候确实像一种涌现。

不是因为你突然掌握了某个神秘提示词。

而是因为你把注意力从一个太低的层里抽出来，第一次看见了更高一层的结构。

过去，我把自己放在循环里面。

现在，我开始尝试站在循环外面。

我还是会下去看，还是会抽查，还是会在关键节点接管。

但我不再默认自己必须参与每一次重复执行。

七、从会提问，到会调用

我现在不会把所有任务都改成 Loop 。

一次性的灵感、模糊的问题、没有验证器的高风险决定，仍然适合一句一句问，或者先坐下来和 AI 讨论清楚。

有些任务本来就是线性的，不需要循环。

有些任务连目标都没想明白，强行让它循环，只会更快地制造噪音。

但那些重复、可验证、边界清楚、可以从错误里恢复的任务，确实适合被设计成 Loop 。

我也越来越觉得，未来评价一个人会不会用 AI ，可能不再只看他会不会提问。

提问仍然重要。

但下一步更重要的是：

你能不能把一段真实工作，拆成可委托、可验证、能停下来的循环？

你能不能判断哪些事情可以交出去，哪些事情必须留在人手里？

你能不能在外面看着它运行，而不是被它拖着不停切换？

所谓调用智能的边界，可能不只是你能调用多强的模型。

而是你知道：

什么可以交给它。

交给它之后，怎么证明做对了。

做错之后，能不能停下来。

以及，当它替你做执行时，你愿不愿意继续为结果负责。

所以， Human 到底要不要 in the loop ？

我的答案是：

不是永远要。

也不是永远不要。

而是要知道自己应该站在哪一层。

低风险、可回滚、可验证的执行，人可以从执行里退出来。

高风险、不可逆、目标不清的决定，人必须回到关键节点。

重复、稳定、需要规模的工作，人更适合站在 loop 上方，设计规则，观察证据，处理例外。

Human 不必一直在 loop 里。

但 Human 不能从责任里消失。

从一句一句问，到让 AI 自己循环，我重新理解了 Human in the Loop 。

它不是让人更忙地监督 AI 。

也不是让人彻底离开。

而是把人从循环里的 CPU ，变成循环外的设计者和责任人。

这大概才是 AI 真正开始改变工作方式的地方。