从Loop到Graph：AI工程化的演进与实践

很多行业观察者都在讨论AI Agent系统的架构演进：有人认为Loop模式已经过时，Graph将成为下一代Agent的标准范式。但实际上，Loop和Graph并非非此即彼的替代关系，而是可以互补的两种技术路径。Loop聚焦于单个执行单元的持续迭代逻辑，而Graph则负责管理多个执行单元之间的连接、分支、并行与恢复机制。在实际的Agent系统中，单个节点内部可以运行Loop，整张Graph中也可以包含循环边，Graph只是将原本隐藏在单个Agent上下文里的职责、依赖和控制逻辑，升级为一套显式的执行结构，让Agent从完成简单任务，升级到可以处理更复杂的长程任务。

行业内的讨论其实早有苗头，前不久有行业资深从业者在社交平台上发起提问：我们还在讨论Loop，还是已经转向Graph了？这也引发了更多人对两种架构的思考。不过仅仅将多个节点连接成Graph，并不会自动带来系统的长期可靠性，一套能够稳定运行的Agent Graph，还需要解决多个关键的工程问题。

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

首先，一套稳定的Graph系统离不开高质量的底层Loop支撑。很长一段时间里，Loop Engineering很容易被简单理解为基础的循环逻辑，最典型的就是“while循环未完成就继续执行”的模式。

while 未达成目标：
    执行任务逻辑

这种简单的循环模式，对于编译、测试、修复这类能快速获得反馈的任务确实有效，但现实中的多数业务场景并不适合这种连续运行模式。比如日报生成、数据巡检这类任务更适合定时触发，每天固定时间执行一次，没有数据变化时无需让模型重复生成内容；而舆情监控、告警监控则更适合事件触发，由外部事件直接唤醒任务。这些场景都不是简单的while循环可以覆盖的。

我们可以根据不同的任务场景，选择五种不同的驱动方式：

• 连续运行：上一轮任务结束后立即启动下一轮，适合批量迁移、系统性重构或有明确量化指标的持续优化场景。
• 定时触发：每隔固定周期执行一次，适用于日报、周期检查和定期维护类任务。
• 条件轮询：当外部状态发生变化时才继续执行，比如出现新的代码提交、核心指标跌破阈值或数据源完成更新时触发。
• 事件触发：由外部事件直接唤醒任务，比如webhook回调、系统告警、代码提交或新工单生成时启动执行。
• 组合触发：日常按事件驱动运行，同时搭配定时任务检查是否有遗漏的任务，兼顾实时性和完整性。

需要注意的是，这里的Loop并非单纯代码层面的循环，而是为了让任务长期稳定运转而设计的动力机制。我们在实践中总结出的经验是：真正可恢复的Loop，必须将当前目标、任务队列、执行记录、验证证据和待处理问题存储在会话之外。这样即使Agent会话结束、程序重启或执行环境更换，下一次启动时仍然可以清楚知晓：上一轮任务执行到了哪一步、哪些结果已经通过验证、哪些任务仍待处理、哪些方向已经尝试过并被否决，当前应该从何处继续推进。

不过仅仅做好Loop的分类和动力机制就足够了吗？如果使用过纯Loop架构的系统，就会发现这类系统往往可靠性不足，还容易出现目标偏移的问题。因此针对长程任务，我们需要引入Graph理念中的角色分权机制，作为兜底的保障。

Graph的角色分权与小步纠偏

Graph的典型特征之一，就是让不同的Agent负责专一的具体任务，再通过节点和边的关系让多个Agent协作完成复杂工作。我们在内部实践中发现，将一个完整任务拆分为Graph上的三个子任务，分别由三个独立的子Agent按顺序执行，再将这个过程用Loop打包起来持续循环，相比让单个Agent完成全部任务，效果会好很多，长期运行的稳定性也更强。

我们通常会将这三个子Agent设定为三个不同的角色：探索者、执行者和验证者。

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

按照这种角色分权模式，一轮完整的内部循环可以简化为：

读取当前系统状态
↓
探索下一步可行任务
↓
执行边界清晰的具体任务
↓
验证执行结果是否达标
↓
更新系统状态、验证证据与任务队列

这里需要特别注意：验证者和执行者不能共用同一个执行上下文，必须将完成任务和证明任务完成作为两个独立的步骤。这样可以保证验证失败的结果不会直接进入主分支，由下一轮的探索过程决定是修复任务、重新执行，还是调整原本的任务方向。

通过这种方式，每一轮循环都只前进一小步，但每一步都有明确的输入、输出和可追溯的记录，同时每一个小步骤都在独立的模型上下文中执行，既能保证执行过程的稳定性，又能让Agent自主把控任务方向，真正实现任务的长期稳定运行。

人类反馈的异步化机制

从Loop演进到Graph，很多人都会忽略一个关键因素：人的参与。我们常说要采用“human in loop”的模式，在必要时对Agent的运行进行人工干预，但这和“让Agent长期自主运行”的目标天然存在矛盾，后者希望尽可能减少人类的介入。

在实践中我们找到了一种折中方案：将人类反馈异步化。当Agent遇到需要人类决断的任务时，比如执行删除信息、权限修改这类不可逆操作，可以暂时挂起当前的执行分支，继续处理其他任务。人类可以异步处理需要决断的任务清单，当人类给出对应的答案后，被暂停的Agent分支可以无缝接回之前的执行进度。而对于其他由Agent自主驱动的任务，只要保证每一步都有可追溯的记录，即使后续发现任务方向选错，也可以顺着历史记录回退并修正。

只有Graph就够了吗？

Graph的能力很强，但到底哪些工作适合采用Graph Engineering？我们又该如何将日常工作转化为Graph化的流程？要回答这个问题，关键并不在于Graph的结构如何设计，而在于我们的思考模式：如何为Graph工程设计合理的目标约束和上下文管理机制。

首先是目标约束的问题。像“修复Bug”这类任务目标明确，AI可以很好地完成，但像“提升代码可读性”或“优化产品设计”这类难以用一句话描述清楚的任务，我们需要两个技巧来让模型准确理解需求：

• 寻找参照物：审美和体验很难直接量化，但可以通过具体的历史案例来明确标准。比如要求Agent撰写文章时，可以将目标设定为“文风无限逼近某位作者过往的作品”；在产品设计、代码审美这类场景中，也可以将参照物替换为相关人员过往的项目记录、设计决策和文档，让模型有明确的参考依据。
• 建立打分机制：理性判断加上感性直觉很难用固定公式来定义，这种场景下，直接让大语言模型担任裁判，或者让多个大语言模型通过辩论PK选出最优解，是更可行的方案。

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

• 多源上下文收集：很多日常工作并没有统一的标准答案，比如如何回复合作消息、某个需求应该优先解决到什么程度、一项设计应该追求一致性还是局部效率，这些决策通常依赖使用者的过往习惯和项目所处的具体环境。我们可以使用相关工具记录和检索长期记忆，让不同的Agent可以直接访问过往的工作信息。对于稳定、重复出现的做法，还可以进一步蒸馏为技能，变成Agent可以直接执行的规则。需要注意的是，上下文记忆并不是将所有过往内容一次性塞进prompt，有效的做法是根据当前问题检索相关的片段，并保留来源和时间信息，让Agent清楚知晓这些信息是在什么场景下形成的。
• 更高效的上下文检索：Agent的上下文信息可能分散在代码仓库、文档、数据库、工单系统、云盘和各种SaaS工具中，如果缺少这些现场信息，即使Agent很了解使用者的偏好，也可能基于过时或不完整的事实做出决策。我们可以通过统一映射工具，将分散的数据源整合为一个可搜索、可浏览的文件式命名空间，让Agent可以通过简单的文件操作逐步找到需要的信息。

尾声

前不久我们读到OpenAI研究员在博客中提到的观点：“模型外围的工程外壳的重要性，已经几乎与模型本身相当”。这已经成为当前行业的共识，而当下无论是上下文管理、Loop机制还是Graph架构，都只是在AI Agent工程化的道路上走出了一小步，未来还有更多的探索空间等待我们去挖掘。