澄清Loop与Graph的技术关系，详解Agent系统长期可靠运行的四大工程问题，实战解析技术方案。

核心内容：

1. Loop与Graph的技术关系及互补价值

2. 驱动循环持续运转的动力机制（五种驱动方式+会话外存储）

3. 长程任务的可靠性保障机制（角色分权等）

上周，龙虾之父Peter Steinberger发布了一条推文，大意是：我们目前是在讨论 Loop，还是已经转向了 Graph？

不少人将这句话视为技术范式的更替信号——Loop 即将过时，Graph 才是 Agent 系统的未来方向。但问题在于，这两者根本不在同一个维度上。Loop 解决的是一个执行单元如何持续迭代的问题。Graph 解决的是多个执行单元如何连接、分支、并行、等待和恢复的问题。两者并不冲突。一个节点内部可以运行 Loop，一张 Graph 里也能存在循环边。Graph 并没有消灭 Loop，而是将原本隐藏在单个 Agent 上下文中的职责、依赖和控制逻辑，转化为一套显式的执行结构。然后，通过引入条件路由、并行任务、失败分支和人工审批，让 Agent 从完成一个简单任务，升级为能够处理更复杂的长程任务。

但话说回来，仅仅将几个节点连成一张图，并不能自动带来可靠性。一套能够长期稳定运行的 Agent Graph，至少需要解决四个工程问题。

驱动循环持续运转的动力机制详解

一个运转良好的 Graph 系统，底层离不开高质量的 loop。只不过，在很长一段时间里，Loop Engineering 很容易被简化成一条逻辑：

while 没完成：
    继续干

在实践中，这种简单的 while 循环，对于编译、测试、修复这类能快速获得反馈的任务确实很管用。但现实中的任务并不都适合连续运行。日报和数据巡检更适合定时触发——每天早上执行一次，没变化就别让模型去硬编内容。舆情监控、告警监控这类则更适合事件触发。这些都不是一个简单的 while 循环能解决的。

总的来说，我们可以根据不同的任务，在以下五种驱动方式里自由选择：

• 连续运行：上一轮结束后立即进入下一轮，适合批量迁移、系统性重构或有明确指标的持续优化。
• 定时触发：每隔一段时间运行一次，适合日报、周期检查和定期维护。
• 条件轮询：外部状态发生变化后再继续，比如出现新的 PR、指标跌破阈值或数据源完成更新。
• 事件触发：由 webhook、告警、代码提交或新工单直接唤醒任务。
• 组合触发：平时按事件运行，同时用定时任务检查是否有遗漏。

说白了，这里的 Loop 并不是代码意义上的纯循环，而是指为了让任务长久运转起来，而设计的不同动力机制。实践中的一个小经验是：真正可恢复的 Loop，必须把当前目标、任务队列、执行记录、验证证据和待处理问题存放在会话之外。这样一来，即使 Agent session 结束、程序重启或执行环境更换，下一次启动时它仍然知道：上一轮做到了哪里、哪些结果已经通过验证、哪些任务仍需处理、哪些方向已经尝试过并被否决、当前应该从哪里继续。

但只做好 Loop 的分类就够了吗？如果你用过纯 Loop 系统，比如 Ralph Loop，应该不难发现：它其实并不可靠，而且目标很容易越跑越偏。也是因此，针对长程任务，我们需要引入 Graph 理念里的角色分权，来作为机制兜底。

Graph 的探索者、执行者、验证者角色分权与小步纠偏策略

Graph 的一个典型特征，是能让具体的 Agent 负责具体的专一任务，然后按照节点和边的关系进行合作分工。在内部实践中，我们发现，如果把一个任务拆成 Graph 上的三个子任务，交给三个独立的、不同的子 Agent 来按顺序依次完成，然后再把这个过程用 Loop 打包起来，继续后续循环，这套玩法比只用一个 Agent 去做这个任务，效果更好，长期运行的动力也更稳健。

具体来说，我们会把这三个子 Agent 设定为三个不同的角色：探索者、执行者、验证者。

• 探索者（Explore）：负责重新读取目标、项目状态、历史记录和已有结果，然后回答三个问题：当前最值得解决的问题是什么？哪一步足够具体，可以在一轮内完成？完成之后，应该用什么证据判断它是否有效？探索者不直接完成大量工作，它的主要产出是下一批候选任务、优先级和验收条件，以及不断校验执行过程中暴露的新问题、发现的新方向，并让它们回到任务队列中。
• 执行者（Execute）：负责按照明确方案完成操作。它不需要重新发明目标，而应该专注于小范围、可回滚的改动。它可以运行在一个全新的 Agent session 中，不需要背负整个项目的历史。缩小上下文空间不仅能让 Agent 更容易集中注意力，不会被大量历史信息干扰，还能让某一轮失败的影响范围也被限制在一个可回退的小步骤内。执行完成后，它需要留下可检查的产物，比如代码 diff、测试结果、实验日志、引用来源或结构化报告。
• 验证者（Judge）：负责检查结果。它不接受“执行者感觉已经完成”这种证据，需要直接查看测试结果、运行日志、页面截图、数据变化或用户反馈，检查执行结果是否满足验收条件，是否遗漏边界情况，以及执行者提供的证据能否支持它的结论。通常来说，能通过自动化方式验证的内容，应该优先交给测试、静态检查、数据校验或确定性规则。只有无法完全形式化的问题，才交给 LLM 进行语义判断。

按照以上角色分权，一轮完整的内部循环可以变成这样：

读取状态
↓
探索下一步
↓
执行一个有边界的任务
↓
验证结果
↓
更新状态、证据和任务队列

这里要注意，验证者与执行者不能共用同一个大脑。必须让“完成任务”和“证明任务已经完成”成为两个独立的步骤。保证验证失败的结果不会直接进入主分支，而是由下一轮探索决定是修复、重做，还是调整原来的方向。保证每一轮只前进一小步，但每一步都有明确的输入、输出和 git commit。并且每一小步，都在单独的模型上下文里执行，这不仅能保证执行过程更加稳定，又能让 Agent 自主把控方向，真正让任务长期、稳定地运行下去。

人类反馈的异步化机制设计

从 Loop 到 Graph，很多人会忽略里面还有一个很重要的因素——人。我们也常说要“human in loop”，让人类去盯着 Agent 的运行，必要时进行干预。但这天然和“长期自主跑起来的 Agent”这个概念相背，后者的目标是尽量让人类少干预。

在实践中，有一个折中方法：将人类反馈异步化。Agent 遇到需要人类决断的事（比如删除信息、权限修改等不可逆操作），可以暂置当前分支，继续去干别的工作。然后人类异步处理需要决断的清单。当人类给出相关问题的答案后，被暂停的 Agent 分支再无缝接上之前的进度。而其他由 Agent 驱动的任务，在保证每一步都有 git commit 留底的情况下，即使后面发现方向选错了，也能顺着历史回退和修正。

只有 Graph 就够了吗？目标约束与上下文管理技巧

Graph 很强，但到底哪些工作适合做 Graph Engineering？以及，我们有没有办法将平时的工作 Graph 化？要回答这个问题，关键不在 Graph 结构如何设计，而在于我们的思考模式：对于一个 Graph 工程，要怎样去设计它的目标约束和上下文管理。

先看目标约束问题。像“修 Bug”这类任务，目标明确（loss 趋近于 0），AI 可以很好地完成。但像“提升代码可读性”或“优化产品设计”这类很难一句话描述清楚的任务，你需要两个技巧才能让机器听懂：

• 寻找参照物：审美和体验很难量化，但可以提供具体的历史案例。比如，要求 Agent 写文章时，目标可以设定为“文风无限逼近某位作者过去的作品”。产品设计、代码审美这类事也是同样的思路，参照物换成这个人过去的项目记录、设计决策、文档，一样能用。
• 建立打分机制：理性判断加上感性直觉很难用公式写死。这种场景下，直接让 LLM 当裁判，或者让多个 LLM 辩论 PK 选出最优解，是更可行的方案。

设定了目标之后，关于上下文，除了更精巧的上下文结构设计之外，我们还需要多源的信息与高效的上下文检索机制。

• 多源上下文收集：很多日常工作没有统一的正确答案。如何回复一条合作消息，某个需求应该优先解决到什么程度，一项设计应该追求一致性还是局部效率，这些决策通常依赖使用者过去的习惯和项目所处的具体环境。可以使用 MemSearch 记录和检索这些长期记忆，让不同 Agent 可以直接访问过去的工作信息。其中稳定、重复出现的做法还可以进一步蒸馏成 skill，变成 Agent 可以直接执行的规则。需要注意，记忆不是把过去的所有内容一次性塞进 prompt。有效的做法是根据当前问题检索相关片段，并保留来源和时间，让 Agent 知道这些信息是在什么场景下形成的。

• 更高效的上下文检索：有时候，Agent 的上下文可能分散在代码仓库、文档、数据库、工单系统、云盘和各种 SaaS 工具中。缺少这些现场信息，即使 Agent 很了解使用者的偏好，也可能基于过时或不完整的事实做决定。MFS 可以把分散的数据源统一映射为一个可搜索、可浏览的文件式命名空间，让 Agent 可以通过 search、grep、ls、cat 等简单操作逐步找到需要的信息。

尾声

前不久，读到 OpenAI 的 Lilian Weng 在其博客《Harness Engineering for Self-Improvement》中写的一句话，非常有感触：模型外围的 Harness（脚手架/工程外壳）的重要性，已经几乎与模型本身相当。

这已经成为如今的行业共识。而当下，无论是 context、loop 还是 graph，其实都只走出了其中的一小步。