# 热门搜索 #
大模型
人工智能
openai
融资
chatGPT
上周，龙虾之父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的一个典型特征是，能让具体的Agent负责具体的专一的任务，然后把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 留底的情况下，即使后面发现方向选错了，也能顺着历史回退和修正。
以上三点，是我自己在Loop/Graph Engineering过程当中总结出来的总结和发现。我平时的工作当中也一直在使用其中的方法和思想，而且我这边也把它做成了一个开源Skill项目：
https://github.com/zc277584121/perpetuum
有需要可以参考。
Graph很强，但是到底哪些工作适合做Graph Engineering？以及，我们有没有办法将我们平时的工作Graph化？
要回答这个问题，关键不在Graph结构如何设计，而在于我们的思考模式：对于一个Graph工程，要怎样去设计它的目标约束和上下文管理。
先看目标约束问题。
像“修 Bug”这类任务，目标明确（ loss 趋近于 0），AI可以很好的完成。但像“提升代码可读性”或“优化产品设计”这类很难一句话描述清楚任务，你需要两个技巧才能让机器听懂：
设定了目标之后，关于上下文，除了更精巧的上下文结构设计之外，我们还需要多源的信息与高效的上下文检索机制。
前不久，读到OpenAI 的 Lilian Weng 在其博客Harness Engineering for Self-Improvement中写的一句话，非常有感触：模型外围的 Harness（脚手架/工程外壳）的重要性，已经几乎与模型本身相当。
现如今，这已经成为了如今的行业共识，而当下，无论是 context还是 loop 或者 graph，其实都只走出了其中的一小步。
文章来自于"Zilliz"，作者 "张晨"。
