同一个任务，有的系统反复死磕直到成功，有的系统遇墙就拐弯换路，这两种设计哲学背后藏着对“时间”和“空间”的完全不同态度！
Loop Engineering和Graph Engineering，在智能体架构设计里分别回答了“要不要再试一次”和“下一步去哪儿”这两个底层问题。读懂这两种工程模式的分野，就看懂了生产级智能体如何避免变成玩具。
一种状态反复撞击直到满意为止
循环工程的核心假设很简单：任务的结果存在一个可验证的合格线，但到达这条线的路径需要反复试探。每一次迭代都产生一个结果，然后停下来问一句“够不够好”，答案如果是否定的，就再来一轮。
这种结构最擅长处理那些成功标准明确但达成手段不确定的任务。比如检索增强生成里的查询改写，第一次搜索可能返回无关内容，系统根据反馈调整查询词再搜一次，直到命中相关文档为止。整个过程就像用钥匙开一把锁，拧不动就换个角度再拧，但始终在开同一把锁。
循环工程的内在逻辑把执行过程压缩成一个紧致的闭环：发现缺口、规划动作、执行操作、验证结果、决定是否继续。这个闭环每转一圈，系统就积累一次经验数据，下一次迭代可以利用上次失败的反馈来调整策略。
关键的决策节点只有一个——继续还是停止。
不少架构师把循环当作简单的“重试机制”来理解，但两者有本质区别：重试机制只是在同样的输入上重复同样的操作，期望偶然避开故障；而循环工程允许每次迭代改变策略，因为上一次的输出变成了下一次的输入。循环内的状态是流动的，每一次尝试都基于前一次的残余信息做修正。
一个被忽视的认知成本在于：循环工程要求系统具备自我判断能力。系统不仅要执行任务，还要在每次迭代后评估自己的执行结果。这种自指结构把验证器变成了系统的核心组件，而验证器的设计难度往往被严重低估。什么算“足够好”，这个标准在不同任务、不同阶段、不同上下文里可能完全不一样。
循环工程最适合的场景存在一个共同特征：失败不是终点，而是提供了修正方向的信息。当系统能够从每次失败的输出中提取出用于调整下一次输入的信号时，循环就有了收敛的可能。如果失败只是简单地返回一个错误码而不携带任何结构性反馈，循环就退化成了盲目的随机尝试。
很多生产级智能体在单个节点内部嵌入了循环结构：检索不到足够证据就继续搜，生成的文案逻辑不通就重写，验证不通过就打回修改。循环在这里扮演的是质量守门人的角色，用时间换取可靠性。
状态之间跳转比死磕一个点更关键
图工程处理的是一组完全不同的决策问题：当系统完成了当前状态的工作后，下一步应该激活哪个状态。答案不是一个布尔值，而是一个从状态集合中选出的目标节点。
把任务拆成多个阶段，每个阶段对应图中的一个节点，节点之间的边定义了合法的转移路径。一次完整的执行就是从入口节点出发，沿着边一步步推进到某个终端节点的过程。每一步的选择可能取决于当前节点的输出结果、外部输入的条件，甚至是随机策略。
在智能体架构中，图工程最常见的体现是工作流编排。
一个典型的写作智能体图可能包含：研究节点收集素材，验证节点检查素材可靠性，写作节点生成初稿，润色节点优化表达，审核节点做终审。每个节点的输出决定了下一步进入哪个节点——素材不足可能回退到研究，审核不通过可能跳转到修改节点而不是直接重新写作。
图工程的价值在于两点：一是把复杂任务拆解成可独立管理的子任务，每个节点只关心自己负责的那一小块工作；二是显式地表达了状态转移的条件和路径，让整个系统的行为模式变得可追溯、可调试、可干预。当一个智能体出现预期外的行为时，检查它在图中的移动轨迹就能定位问题出在哪个节点。
图工程的设计决策主要围绕状态划分和转移规则展开。状态划分决定了哪些功能应该聚合成一个节点，哪些功能应该拆开；转移规则决定了什么条件下走哪条边。粗糙的状态划分会让单个节点承担过重的逻辑，精细的划分则带来管理成本和路径爆炸的风险。
系统复杂到一定程度之后，图结构提供的可观测性优势就变得不可替代。循环的累计效应很难追踪——一个循环跑了十次，中间的状态变化像黑箱一样被折叠了；而图的每一次状态转移都是显式的节点跳转，每个节点进入和退出时都可以留下日志痕迹。这种透明性在大规模生产环境中直接决定了系统是否可维护。
图工程把“转向”的成本显式化了。
在循环结构里，改变策略几乎不需要额外设计，因为每次迭代本身就是一次调整机会；在图结构里，从当前节点跳转到另一个节点意味着状态的切换，这种切换往往伴随着上下文的重置、中间产物的传递和初始条件的重新设定。把这些成本摆到台面上，反而让架构师能够精确评估不同路径的经济性。
循环和图回答的问题在逻辑层级上完全不同
循环工程和图工程最容易被混淆的地方在于：两者都涉及“重复”和“路径”的概念，但它们的控制对象和决策尺度根本不在一个维度上。
循环工作在同一个节点的内部，它关心的是“在当前这个状态里，产出是否达到了阈值”。图工作在不同节点之间，它关心的是“当前节点的产出应该被送到哪个状态去处理”。循环是纵向的时间维度控制——同一件事情反复做直到满足条件；图是横向的空间维度控制——不同的事情按顺序或条件依次执行。
用具体的任务来验证这个区别会更清晰：
假设一个智能体被要求写一份市场分析报告，图层面的设计可能是：市场调研→数据清洗→趋势分析→报告撰写→质量审核。在“趋势分析”这个节点内部，如果算法发现数据噪声太大导致趋势线不显著，可能会循环执行多次平滑处理，每次调整参数，直到趋势线的置信区间收窄到可接受范围。
图决定的是“现在应该做趋势分析”；循环决定的是“趋势分析这一轮的结果要不要再来一次”。
把循环设计成图中的一个独立节点是一种常见的架构错误。比如把“验证-重试-再验证”设计成三个节点形成的反馈环，表面上看是显式化了验证逻辑，实际上是在图层面模拟了一个循环结构。这样做带来的直接后果是状态空间的膨胀，每次重试都会产生一条新的状态转移记录，让执行轨迹变得臃肿且难以解读。
真正的边界在于决策的性质：如果问题是“这个结果通过没有”，答案属于循环层；如果问题是“通过之后去哪”，答案属于图层。通过之后去哪，不是循环能回答的，因为循环只知道继续或停止，不知道停止之后的新起点在哪里。
同样，把图决策嵌套进循环内部也是危险的。一个循环的每次迭代都重新决定下一步去哪个状态，这种设计相当于在循环体内嵌入了完整的图路由逻辑，结果就是循环失去了“反复做同一件事”的语义，变成了一个包裹着复杂路由的壳。系统行为变得难以预测，因为循环的迭代次数和执行轨迹耦合在了一起。
两种决策压力在同一套系统里同时存在
生产级智能体不会只用循环或只用图，因为真实任务的复杂性恰恰来自两类决策的混合。一个任务的完成往往需要多次尝试某些子目标，同时在这些子目标之间有序推进。
检索增强生成系统是两者的经典结合。从图的角度看，流程可能是查询理解→多路检索→结果融合→生成回答→质量检查。在“多路检索”节点内部，每一路检索都可能因为召回不足而循环多次，每次调整检索参数或改写查询词。在“质量检查”节点，如果检测到回答存在事实性错误，循环会触发重新生成，但图层面不会从“生成回答”跳回“多路检索”，因为错误发生在生成阶段而非检索阶段。
这种嵌套关系形成了清晰的职责分层。图负责路由和编排，回答“接下来做什么”；循环负责收敛和迭代，回答“当前这件事做够没有”；模型负责具体执行，完成节点定义的子任务；验证器负责评估，给循环提供停止或继续的判断依据。
把模型当作整个智能体的全部能力是一种常见的认知偏误。实际上，模型只是执行层的一个组件，它的输出质量由验证器判断，验证器的判断结果由循环决定如何处理，循环的策略由图来设定边界。把决策权逐层上移，每层都只做自己擅长的那一类判断。
这种架构设计把工程师的注意力从“选哪个模型”转移到了“如何组织模型的使用方式”。同样的模型，在精心设计的图+循环结构里，可以完成远超其单次调用能力上限的复杂任务。因为循环负责用多次调用换取质量稳定，图负责用状态转移换取路径灵活。
一个生产级智能体的执行骨架
当一个智能体同时包含循环和图两种结构时，它的执行流程看起来大概是这样的。
图定义了所有可能的状态节点和合法边。入口节点接收原始任务，根据任务类型分发给不同的处理链。每条处理链上的节点按预设顺序激活，节点间的边可能带有条件标签——满足条件A走边A，满足条件B走边B。
每个节点内部封装了一个循环。节点被激活后，循环开始运行。每一次循环迭代都调用模型执行节点对应的子任务，然后调用验证器检查结果。如果验证通过，循环停止，节点输出结果，图根据这个结果决定下一个激活的节点。如果验证不通过，循环继续，下一次迭代可以调整策略重新尝试。节点可以设置最大迭代次数防止死循环。
验证器的设计直接决定了循环的效率。过于宽松的验证标准会让低质量的结果流入下游节点，污染后续所有处理；过于严格的标准会让循环反复迭代，消耗时间和计算资源，甚至永远达不到退出条件。验证器的阈值通常需要针对每个节点单独调参，因为不同子任务的质量标准天然不同。
图的转移逻辑和循环的停止逻辑在运行时互不干扰，但共享同一个状态上下文。图决策时能看到当前节点的循环迭代次数、验证历史、中间产出等数据，这些信息可以作为条件分支的依据。比如，如果“研究”节点循环了十次还没能收集到足够证据，图可以选择跳转到“补充查询”节点而不是继续困在研究节点里。
这种分层架构把系统行为的复杂度降到了可控范围。调试时，先在图层检查状态转移是否符合预期，再深入到问题节点的循环内部查看迭代过程。两层之间用标准化的输入输出接口隔离，修改某一层的逻辑不会波及另一层。
把“继续”和“转向”拆开之后一切都清晰了
循环和图经常被混为一谈，根源在于两者都涉及“走回头路”和“换方向”这类空间隐喻。但语言层面的相似掩盖了决策逻辑的根本差异。
循环内部的每一次迭代并不改变状态的身份——系统始终处在“研究”这个状态里，只是研究内容在迭代中逐渐完善。而图的每一次状态转移都改变了系统的身份——从“研究”变成了“写作”，任务的性质发生了切换。循环在同一个身份内部做量变积累，图在不同身份之间做质变切换。
用时间维度来理解会更直观。循环是时间维度上的纵向延伸，把同一个决策点拉长成一段时间内的连续决策；图是空间维度上的横向移动，把不同决策点组织成一个网络结构。循环消耗的是时间，图消耗的是状态空间。
很多智能体系统的失控案例都可以归结为两种工程模式的错配。该用循环的地方用了图——把一次简单的重试设计成了状态机，导致执行轨迹无谓地复杂化。该用图的地方用了循环——把需要分阶段处理的任务压缩进一个节点的循环里，导致单次迭代承担了过多责任，验证器根本没法给出清晰的通过条件。
正确的做法是在系统设计初期就明确区分两类决策。先画图，定义所有状态节点和转移规则，确保每个节点的职责单一且边界清晰。然后为每个节点独立设计循环逻辑，定义验证条件和最大迭代次数。最后把两者组装起来，图负责调度节点激活，节点内部的循环负责保证输出质量。
区分清楚“继续还是停止”和“下一步去哪”之后，剩下的就是执行层面的细节了。模型该用哪个、验证器怎么实现、循环超时怎么处理——这些问题都有了明确的上下文和调用边界，决策变得局部化，每个局部问题都有对应的局部最优解。
循环工程和图工程不是非此即彼的选择题，而是回答两个不同问题的独立答案。循环说“再做一次”，图说“换个地方”，两者各有各的使用场景，也各有各的滥用风险。真正难的不是选择哪一种，而是看清眼前的问题到底属于“继续”还是“转向”。