上周，龙虾之父Peter Steinberger 发了一条推文：我们还在讨论 Loop，还是已经转向 Graph 了？很多人会把它解读成技术范式更替：Loop 已经过时，Graph 将成为下一阶段 Agent 系统的标准架构。但问题在于，Loop 解决的是一个执行单元如何持续迭代的问题。Graph 解决的是多个执行单元如何连接、分支、并行、等待和恢复的问题。两者其实并不冲突。一个节点内部可以运行 Loop，一张 Graph 里也可以存在循环边。Graph 并没有消灭 Loop，而是把原本隐藏在单个 Agent 上下文里的职责、依赖和控制逻辑，提升成一套显式的执行结构。然后引入条件路由、并行任务、失败分支和人工审批，让Agent 从完成一个简单任务，升级为可以完成更复杂的长程任务。但仅仅把几个节点连成一张图，并不会自动带来可靠性。一套能够长期运行的 Agent Graph，至少还要解决四个工程问题。01 驱动循环持续运转的动力机制
一个可以良好运转的 Graph 系统里，离不开高质量的底层 loop 存在。只不过，很长一段时间里，Loop Engineering 很容易被理解成：在实践当中，这种简单的while循环，对于编译、测试、修复这类能够快速得到反馈的任务很有效。但现实中的任务并不都适合做连续运行。日报和数据巡检更适合定时触发：每天早上执行一次，没有变化就不要让模型去硬编内容。舆情监控、告警监控等更加适合事件触发。这些都是一个简单的while循环解决不了的。总的来说，我们可以根据不同任务，在以下五种驱动方式做自由选择：连续运行：上一轮结束后立即进入下一轮，适合批量迁移、系统性重构或有明确指标的持续优化。定时触发：每隔一段时间运行一次，适合日报、周期检查和定期维护。条件轮询：外部状态发生变化后再继续，例如出现新的 PR、指标跌破阈值或数据源完成更新。事件触发：由 webhook、告警、代码提交或新工单直接唤醒任务。组合触发：平时按事件运行，同时用定时任务检查是否有遗漏。说白了，这里的Loop并不是一个代码意义上的纯循环，而是指为了让任务长久运转起来，而设计的不同动力机制。我们实践中的一个小经验是：真正可恢复的 Loop，必须把当前目标、任务队列、执行记录、验证证据和待处理问题存放在会话之外。这样，即使 Agent session 结束、程序重启或执行环境更换，下一次启动仍然能知道：上一轮做到了哪里、哪些结果已经通过验证、哪些任务仍然待处理、哪些方向已经尝试过并被否决、当前应该从哪里继续。但只做好 loop的分类 就够了吗？如果你用过纯Loop系统，比如Ralph Loop，应该不难发现：它其实并不可靠，而且总是容易把目标做得越做越漂移。也是因此，针对长程任务，我们需要引入Graph 理念里的角色分权，来作为机制兜底。02 Graph 的探索者、执行者、验证者角色分权与小步纠偏
Graph的一个典型特征是，能让具体的Agent负责具体的专一的任务，然后把Agent 按照节点和边的关系进行合作分工。在内部的实践当中，我们发现，如果把一个任务拆成Graph上的三个子任务，给三个独立的不同的子Agent来按顺序依次完成，然后再将这个过程再用Loop打包起来，继续后续的循环。这套玩法比只用一个Agent去做这个任务，产生的效果更好，长期运行的动力也更稳健。具体来说，我们会把这个三个子Agent设定为三个不同的角色：探索者（explore）负责重新读取目标、项目状态、历史记录和已有结果，然后回答三个问题：当前最值得解决的问题是什么？哪一步足够具体，可以在一轮内完成？完成之后，应该用什么证据判断它是否有效？探索者不直接完成大量工作。它的主要产出是下一批候选任务、优先级和验收条件，以及不断校验执行过程中暴露的新问题、发现的新方向和需要补充的验证，让它们回到任务队列中。执行者（execute）负责按照明确方案完成操作。它不需要重新发明目标，而应该专注于小范围、可回滚的改动。它可以运行在一个全新的 Agent session 中，不需要背负整个项目的历史。缩小上下文空间不仅可以让 Agent 更容易集中注意力，不会被大量历史信息干扰。也可以让某一轮失败的影响范围也被限制在一个可回退的小步骤内。执行完成后，它需要留下可检查的产物，例如代码 diff、测试结果、实验日志、引用来源或结构化报告。验证者（judge）负责检查结果。它不接受执行者感觉已经完成这种证据，需要直接查看测试结果、运行日志、页面截图、数据变化或用户反馈，检查执行结果是否满足验收条件，是否遗漏边界情况，以及执行者提供的证据能否支持它的结论。通常来说，能通过自动化方式验证的内容，应该优先交给测试、静态检查、数据校验或确定性规则。只有无法完全形式化的问题，才交给 LLM 进行语义判断。读取状态↓探索下一步↓执行一个有边界的任务↓验证结果↓更新状态、证据和任务队列
这里要注意，验证者需要与执行者不能共用同一个大脑。必须让完成任务和证明任务已经完成成为两个独立步骤。保证验证失败的结果不会直接进入主分支，然后由下一轮探索决定是修复、重做，还是调整原来的方向。保证每一轮只前进一小步，但每一步都有明确的输入、输出和git commit。并且每一小步，在单独的模型上下文里执行，这不仅可以保证执行的过程中更加的稳定，又能够让Agent进行自主的方向的把控，真正地让任务长期，稳定地运行下去。03 人类反馈的异步化机制
从Loop到Graph。很多人会忽略里面还有一个很重要的因素，就是人。我们也常说要「human in loop」去盯着这个Agent的运行，必要时进行干预。但是这天然和所谓的长期自主跑起来的Agent概念相背，因为后者的目标是尽量人类少干预。在实践当中，有一个折中方法，将人类反馈异步化：Agent 遇到需要人类来决断的事（比如删除信息、权限修改等不可逆操作），可以暂置当前分支，继续去干别的工作。然后人类异步处理需要决断的清单，当人类给出相关问题的答案后，被暂停的Agent分支再无缝接上之前的进度。而其他由Agent 驱动的任务，在保证每一步都有 git commit 留底的情况下，即使后面发现方向选错了，也能顺着历史回退和修正。以上三点，是我自己在Loop/Graph Engineering过程当中总结出来的总结和发现。我平时的工作当中也一直在使用其中的方法和思想，而且我这边也把它做成了一个开源Skill项目：https://github.com/zc277584121/perpetuum 有需要可以参考。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，其实都只走出了其中的一小步。
立即咨询 JOTO
JOTO 提供覆盖企业智能体规划与搭建、AI 平台私有化部署、RAG 知识工程、AI 安全治理、FDE 驻场共创及持续运营优化的全周期 AI 落地服务，帮助企业把验证中的 AI 能力转化为安全、可控、可持续迭代的生产力。 联系 JOTO 获取 AI 落地咨询
