Loop Engineering实战：Agent循环系统的刹车与方向盘设计

当我们谈论 Loop Engineering（循环工程）时，往往关注的是一个 Agent 能连续自主运行多久。但一个更本质的问题被忽视了：Agent 自己跑起来之后，谁来让它停下来？

你给它一个目标，它自己拆解步骤、调用工具、根据结果调整方向，整个过程不需要你每一步都盯着。这听起来很美好——直到第一步就走偏了。它可能一直重复同一个操作，任务毫无进展，token 费用却在持续上涨。一觉醒来，任务没完成，余额却归零了。

本文基于一位 B 站 UP 主对 Loop Engineering 系统设计的深度拆解，梳理出一套可靠 Agent 循环系统必须解决的核心问题。

失控的循环：从省心到烧钱

手动使用 Agent 时，它调用错一次工具，你马上就能发现并告诉它怎么改。但一旦放进循环里，如果没有人及时纠正，它就可能沿着错误方向一路狂奔。

我会先看他什么时候停

更麻烦的是，有些错误不只是浪费 token。Agent 可能用了不该调用的工具、访问了没有权限的数据，甚至改动了重要文件。多个 Agent 协作时还会遇到另一类隐患：前一个刚改完文件，后一个又把它的结果覆盖了。你去查日志，两次操作都显示成功，但先前的修改已经消失。

所以，判断一套 Loop Engineering 做得好不好，光看 Agent 能连续干多久远远不够。关键在于：它走偏之后，系统能不能发现，又能不能处理。

停止条件：不能全交给模型决定

第一个要看的，就是 Agent 什么时候停。这个决定绝不能完全交给模型自己。它可能反复尝试同一个失败的操作，也可能事情还没做完就告诉你「任务已完成」。

因此，外部程序必须提前设好硬性限制：

最多执行多少轮
运行多长时间
消耗多少 token
允许多少费用

达到上限就暂停或结束，不能让 Agent 自己决定「再试多久」。

但反过来，没到上限也不意味着就该继续。如果 Agent 连续调用同一个工具、返回结果没有变化，或者跑了好几轮任务仍无进展，系统就应该主动暂停，检查它是不是卡住了。

至于它说「做完了」，也要有对应的验收机制：要修改的文件是否真的改好了？该生成的结果是否存在？必要的检查有没有通过？这些都不能只凭模型一句话。

这里提到的「连续调用同一工具却无进展」，在 Agent 系统中有一个专门的术语叫工具调用循环（Tool Call Loop）或死循环检测。常见的检测策略包括：滑动窗口内相同工具+相同参数的调用次数阈值、连续多轮输出的语义相似度检测，以及任务关键指标（如文件是否写入、测试是否通过）的变化监控。单纯依赖轮次上限虽然简单，但可能在真正卡死很久后才触发，因此更精细的做法是结合进展检测（Progress Detection）——每隔若干轮评估一次任务是否有实质推进，没有则提前介入，而非等到 token 耗尽。

权限与范围：模型提出，程序把关

接下来要看工具怎么执行。当 Agent 提出要删除文件、修改数据时，程序不能收到请求就照做。

涉及重要数据的改动

执行之前，系统至少要检查四件事：工具是否存在、参数是否合法、当前身份有没有权限、这次操作是否超出了任务允许的范围。对于涉及重要数据的改动，可能还需要人来确认。

这里的核心原则是把两件事分开：模型负责提出操作，程序负责按规则检查。 不能因为模型说「这一步有必要」，就跳过权限和范围的限制。

权限这类硬限制

权限这类硬限制，必须由程序强制执行，而不能只靠模型「记住」。这是 Agent 安全运行的底线。

状态记录与上下文管理

系统还得记录 Agent 现在做到哪了：它是在等模型返回，还是等工具执行？是在等待检查，还是已经开始处理错误？遇到错误后，它准备重试还是已经停下？

如果这些状态没有记录，一旦出问题，你只能看到「任务还在运行」，却不知道该继续等待还是介入排查，只能从头翻日志猜它卡在哪一步。

关键约束不能在上下文压缩中丢失

除了运行状态，Agent 每一轮能看到什么信息也要精心安排。运行时间越长，工具结果和历史记录就越多。如果一股脑往上下文里塞，最初的任务要求和操作限制就可能在截断、压缩时丢失。

比如用户一开始说过「只分析，不要修改文件」，后面执行了很多轮之后，这条限制仍然必须有效。关键要求需要在每一轮运行时都能被读取——而权限这类硬限制，更要由程序执行，不能只靠模型记忆。

中途出错：保存进度而非盲目重试

网络断开、工具服务暂时不可用、程序意外退出，都可能打断一场长任务。如果重启后只能从头再来，除了多花时间和 token，还可能把已经完成的操作再做一遍。

所以系统需要保存进度：哪些步骤已经完成、当前执行到哪里、工具返回了什么、还有哪些问题没处理。

但保存进度不等于直接重试就行。比如程序发出了修改数据的请求，却在收到结果之前断开——这时操作可能已经成功，只是结果没传回来。恢复以后，应该先核对实际状态，或者通过**操作标识（幂等性）**避免重复执行。否则，原本只是一次网络故障，重试后反而多出一次错误操作。

**幂等性（Idempotency）**是指同一操作执行一次与执行多次，产生的最终结果完全相同。在分布式系统和 Agent 工程中，这是处理网络中断与重试场景的核心设计原则。实现幂等性的常见做法是为每次操作生成唯一的操作标识符（Idempotency Key），服务端收到请求时先查询该 ID 是否已被处理，若已完成则直接返回原先的结果，而不重新执行。例如，一次数据库写入附带 op_id=abc123，即使客户端因网络问题重发了三次，服务端也只会真正写入一次。对于 Agent 系统而言，文件修改、数据库更新、外部 API 调用等具有副作用的工具，都应优先设计为幂等操作，或在调用层包裹幂等性检查逻辑，以防恢复重试时造成数据重复或状态错误。

多Agent协作：并行与冲突合并

多个 Agent 协作时，要分清哪些事情能同时做。查不同的资料、分析不同的文件，通常可以并行。但如果几个 Agent 都要修改同一个文件，就必须协调执行顺序，或者让它们先在独立空间里修改，最后再检查并合并。

独立工作也不是万事大吉

然而独立工作也不是万事大吉。两份修改单独看都可能没问题，合到一起却可能冲突。所以合并后的结果仍然要验收。这就像几个人同时编辑一份文档，每个人都完成了自己那部分，不代表最后拼起来的内容就一定正确。

多 Agent 并行写同一资源时面临的是经典的写-写冲突（Write-Write Conflict）问题，解决思路借鉴自版本控制与数据库并发控制领域。常见方案有两类：一是悲观锁（Pessimistic Locking），Agent 在修改前先获取资源的独占锁，其他 Agent 排队等待；二是乐观并发控制（Optimistic Concurrency Control），各 Agent 在独立副本上操作，合并时检测冲突并由协调者（Orchestrator）或人工裁决。对于文本类内容（如代码文件），还可以借鉴 Git 的三路合并（3-way merge）策略，以共同祖先版本为基准自动合并，只在真正冲突的行才请求人工介入。选择哪种方案取决于任务对实时性和一致性的要求权衡。

一套可靠Loop Engineering系统的自检清单

回过头看，一套 Loop Engineering 系统是否可靠，可以用几个具体问题来检查：

Agent 一直重复、没有进展时，系统能不能让它停下来？
它提出越权或超范围的操作时，程序能不能拦住它？
它现在做到哪一步、卡在哪里，能不能查清楚？
程序中途退出后，能不能恢复进度并避免重复执行？
多个 Agent 一起修改内容时，会不会覆盖彼此的结果？
Agent 完成任务后，有没有办法验证结果？

这些问题直接决定了你能不能放心离开一会儿，让 Agent 自己继续工作。

用汽车来打个比方：模型提供动力，外面的程序要管好刹车和方向盘，还得让你看得见车开到了哪里。 落实到系统里，就是停止条件、权限检查、状态记录、进度恢复和协作规则——每一项都对应着运行过程中可能发生的具体问题。