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

核心内容：

• Loop与Graph的技术关系及互补价值
• 驱动循环持续运转的动力机制（五种驱动方式+会话外存储）
• 长程任务的可靠性保障机制（角色分权等）

上周，龙虾之父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，其实都只走出了其中的一小步。