原创 张晨 2026-07-24 18:31 上海

好的，没问题。作为一位在AI工程化领域摸爬滚打多年的老兵，我仔细读了一遍你给的这篇文章。

坦率说，它里面提到的很多概念和痛点，恰恰是我们团队在过去一年里踩过无数坑之后才真正领悟到的。

下面，我把我对这个问题的理解和实践经验，重新梳理成文，希望能对你有帮助。

关于Loop和Graph的讨论，其实没必要把它们放在对立面。它们更像是解决不同层面问题的两种工具，而非你死我活的范式更替。

上周，龙虾之父Peter Steinberger 的一条推文又把话题点燃了：我们还在讨论 Loop，还是已经转向 Graph 了？

很多人会解读成技术风向标，觉得Loop已经过时，Graph将成为下一阶段Agent系统的标准架构。

但仔细想想，Loop解决的是“单个执行单元如何持续迭代”的问题，而Graph解决的是“多个执行单元如何连接、分支、并行、等待和恢复”的问题。两者压根儿就不在一个层面上。

一个节点内部可以运行Loop，一张Graph里也可以存在循环边。Graph并没有“消灭”Loop，它只是把原本隐藏在单个Agent上下文里的职责、依赖和控制逻辑，全部显式地端到了台面上，形成一套可编排的执行结构。

然后，条件路由、并行任务、失败分支、人工审批这些机制才有了用武之地，让Agent从完成一个简单任务，升级到可以完成复杂的、需要多步骤协调的长程任务。

不过，把几个节点连成一张图，并不等于系统就自动变得可靠了。一套能长期稳定运行的Agent Graph，至少还得解决四个关键的工程问题。

01

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

一个运转良好的Graph系统，底层离不开高质量的Loop。只不过，很长一段时间里，大家对“Loop Engineering”的理解太过简单粗暴了，往往就等价于一个while循环：

while 没完成：
    继续干

在实践中，这种简单的while循环对于编译、测试、修复这类能快速获得反馈的任务确实很有效。但现实世界里的任务，并不都适合这种“连续运行”模式。

比如，日报生成和数据巡检，更适合“定时触发”，每天早上跑一次就行，没变化时别让模型硬编。再比如，舆情监控和告警响应，则更需要“事件触发”。这些都是一个简单的while循环解决不了的。

所以，针对不同任务，我们至少可以在以下五种驱动方式中自由选择：

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

说白了，这里的“Loop”并不是一个纯粹的代码意义上的循环，而是指为了让任务长久运转下去而设计的“动力机制”。

这里有一个小经验：真正可恢复的Loop，必须把当前目标、任务队列、执行记录、验证证据和待处理问题，都存放在会话之外。这样，即使Agent session结束、程序重启，下一次启动时，它依然能知道：上一轮做到了哪里、哪些结果已通过验证、哪些任务仍待处理、哪些方向已被否决，以及当前应该从哪继续。

不过，把Loop分类做好就够了吗？如果你用过纯Loop系统，比如Ralph Loop，应该会发现，它其实并不可靠，而且很容易出现目标漂移。针对长程任务，我们还需要引入Graph理念里的“角色分权”，来作为机制兜底。

02

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

Graph的一个典型特征，就是能让具体的Agent负责具体的、专一的任务，然后通过节点和边的关系，把它们组合起来分工合作。

内部实践发现，如果把一个任务拆成Graph上的三个子任务，交给三个独立的不同子Agent按顺序依次完成，然后再把这个过程用Loop打包起来，继续后续循环。这套玩法，效果比只用一个Agent去做这个任务要好得多，长期运行的稳定性也更佳。

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

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

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

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

这里必须注意，验证者与执行者不能共用同一个“大脑”，必须让“完成任务”和“证明任务已完成”成为两个独立步骤。保证验证失败的结果不会直接进入主分支，而是由下一轮探索决定是修复、重做，还是调整方向。

保证每一轮只前进一小步，但每一步都有明确的输入、输出和git commit。并且每一小步都在独立的模型上下文里执行，这不仅能保证执行过程更稳定，又能让Agent自主把控方向，真正让任务长期、稳定地运行下去。

03

人类反馈的异步化机制

从Loop到Graph，很多人会忽略一个很重要的因素：人。我们常说“Human in the loop”，要盯着Agent运行，必要时进行干预。但这天然和“长期自主运行”的Agent理念相悖，因为后者的目标是尽量减少人类干预。

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

04

只有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，其实都只走出了其中的一小步。