一个循环将一个决策隐藏在黑盒之中：接下来运行什么。
每次代理循环决定是重试、升级还是继续，这个决策都发生在模型自身的推理过程中，对你不可见，事后无法审计，并且除非重新阅读模型的原始输出并希望它诚实地解释自己，否则根本无法检查。而图结构则让这个决策变得明确、可记录、在运行开始前就可以检查。
这并非一个微小的区别。它正是 2026 年 4 月发表的一篇真实 arXiv 论文背后的实际论点，该论文重新定义了代理系统应该如何构建。在课程继续深入之前，有必要坦诚地说明一点：该论文的作者本人包含了一个公平性免责声明，明确指出这是一个尚未实现的方案，其能否在实践中带来承诺的好处，仍然是一个有待验证的实证问题。本课程诚实地教授这个框架，包括这个保留意见，因为理解一个真实、严谨论证但尚未大规模验证的提案，比假装它已是定论更有用。
通过本课程，你将理解图工程到底是什么，它为何作为循环之上的一个层次而存在，本框架中每个图所依赖的三个承诺，以及如何构建你的第一个图，同时会诚实地说明当前证据支撑和未支撑的地方。
为什么循环有天花板
要理解图为什么存在，你需要精确地理解循环在什么时候不再足够。
循环，在此处相关的代理意义上，是一个周期：代理尝试一个任务，观察结果，然后决定下一步做什么，重复直到满足某个条件。这对于大量任务来说效果非常好。然而，它在结构上，恰恰在最关键的时刻是一个黑盒：下一步做什么的决策。
当循环中的代理决定重试一个失败的步骤时，这个决策来自于模型对其自身上下文进行推理并产生一个选择。你无法在决策发生前检查它。你只能在事后观察结果。如果代理连续五次重试同一失败方法，每次都消耗成本，循环的结构中没有任何东西阻止了这一点，因为重试的决策完全存在于模型自身的判断中，而不是任何外部可检查的规则。
这对于低风险、低成本的任务来说没问题，偶尔浪费一次重试并无大碍。但对于长期、昂贵或高风险的工作来说，这成为一个真正的隐患，而这类任务正是代理系统日益被托付的。论文的核心论点是：随着代理系统承担更多重要工作，“接下来运行什么”的不透明性不再是一个可接受的黑盒，而开始成为值得直接进行工程解决的真正故障点。
图到底是什么
在这个框架中，图用运行开始前定义的显式结构，取代了模型隐式的下一步决策。
代理不再在一个不透明的上下文窗口中推理出“我应该重试”或“我应该升级”，而是图预先精确地定义了哪些状态存在，哪些状态之间的转换是有效的，以及哪些具体条件触发每个转换。代理仍然在每个状态内部做实际工作。但它不再无形地决定整个过程的走向。
描述通过这样一个图的任何单次轮次的五步结构是：规划、执行、恢复、升级、重复。规划是任务被分解为定义序列的地方。执行是代理实际为当前步骤工作的地方。恢复是当执行失败时发生的情况，遵循定义的协议而不是即兴重试。升级是显式定义的点，图将控制权交给人类，而不是继续尝试自动恢复。重复关闭循环，进入计划中的下一步。
注意与循环相比发生了什么变化。这五个步骤中的每一个现在都是图中一个命名、可检查的状态，具有定义好的转换，而不是在一个单一的模型调用中默默发生的决策。
三个承诺
本框架中的每个图都依赖于三个具体承诺。深入理解这三个承诺实际上是图工程作为一门学科的核心，比任何具体实现细节都更重要。
承诺一：不可变计划
执行计划不能在运行过程中改变。一旦计划生成并锁定，它在该次运行的持续时间内作为一个固定版本存在。代理不能默默地根据自己注意到的东西在运行过程中修改自己的计划，而循环中的代理经常这样做，且没有任何外部记录。
这听起来很严格，而且它本意就是如此。这种限制正是关键所在。一个可以自由修改自己运行中计划的代理，正是其行为变得事后无法审计的代理，因为你事后会审查的计划并不是实际遵循的计划，而是计划最终漂移成的东西。锁定计划以真正的灵活性换取了真正的可检查性。这种权衡并非免费，值得诚实地对待，而不是将其视为在所有情况下都严格的改进。一个真正新颖的情况，原始计划没有预料到，用不可变计划处理起来会比一个可以自由适应的循环更差。这个承诺是一个刻意的赌注，即对于本框架目标的任务类别，可预测和可审计优于最大程度适应。
承诺二：分离的层次
规划、执行和恢复存在于三个独立的层次中，而不是一个所有事情都发生在同一连续推理过程中的混乱循环。
规划层产生承诺一的不可变计划，并且不做其他任何事情——它不执行步骤，也不处理失败。执行层运行定义的步骤并报告结果——它不决定失败时发生什么，只报告发生了什么。恢复层接收失败报告并应用一个定义的协议——它不直接执行新工作，只决定如何响应已经发生的事情。
这种分离，刻意地，镜像了在验证循环中将 Builder 与 Judge 分离的相同原则：产生工作的角色不应该同时是评估或决定该工作的角色，因为合并两者会削弱使检查有意义的独立性。这里的分离是三重而不是两重，但底层推理是相同的：一个在一个未区分的过程中同时进行规划、执行和恢复的系统，无法有意义地独立审计其中任何一个功能，因为它们在你事后审查的轨迹中从来不是真正不同的。
承诺三：严格升级
恢复遵循一个固定的协议，而不是无限期地重试并希望最终能行得通。
这个承诺最直接地解决了困扰循环而没有真正停止条件的令牌暴增故障模式。一个严格的升级协议预先定义了允许多少次恢复尝试，什么算作恢复尝试成功或失败，以及一旦达到定义的限制会发生什么——将控制权交给人类，而不是在相同的失败方法上再尝试一次创造性的变体。
论文对 70 个真实系统的分析发现，很大一部分代理循环实现根本没有对恢复尝试的正式限制，这意味着当出现问题时，实际行为由模型当时恰好决定的内容决定，而不是由任何人类事先审查和批准的规则决定。严格升级直接填补了这一特定空白。
构建你的第一个图
以下是实际构建一个这样的图的实践路径，将三个承诺转化为你可以实现而非仅仅概念理解的内容。
首先，在编写任何代码或提示词之前，在纸上显式地定义你的状态。对于一个典型任务，这通常至少包括：规划、执行步骤 N、从失败中恢复、已升级、完成。对于每个状态，写下系统处于该状态时具体发生什么，以及导致离开该状态的具体条件。
编写规划生成步骤，使其输出是一个固定的、版本化的工件，而不是一个系统的其余部分可以默默编辑的活文档。一个简单实用的版本是：将计划生成为一个编号的离散步骤列表，每个步骤都有明确的成功标准，并在运行期间将该列表视为只读。任何真正需要偏离它的情况，都应该触发显式升级给人类，而不是默默的内部修订。
构建执行层，使其只报告结果——通过、失败，并附带具体细节——永远不自行决定下一步做什么。这正好镜像了验证循环中的 Builder 角色：产生工作并诚实地报告，但不同时也是决定是否重试的角色。
使用一个显式的、编号的协议构建恢复层。尝试一个特定的替代方法。如果失败，尝试第二个不同的特定方法。如果失败，升级。协议应该足够具体，以至于人类事先阅读它能准确预测系统在每个阶段会做什么，而不是像“尝试合理次数来修复它”这样模糊的指令。
连接升级状态，使得达到它是一个真实、可见的事件，而不是默默记录然后被遗忘。应该通知人类，附带尝试了什么以及每次尝试为何失败的完整历史——与验证循环中通常建议的停止条件相同的纪律。
这个框架真正有帮助的地方，以及没有帮助的地方
诚实地对待图工程的局限性，比将其视为在所有情况下都能替代循环的通用升级更有用，而论文本身也支持这种更适度的表述。
图在以下任务中真正有帮助： 可能出现问题的空间在事先相当了解、审计性比最大适应性更重要、以及失控的无界重试循环的成本确实很高（无论是在计算成本还是不良结果到达真实用户或真实系统的后果）。
图在以下任务中不太适合： 真正开放式的探索性任务，你无法事先有意义地预测失败的形式，并且系统的价值恰恰来自于其即兴应对无人预料到的响应的能力。对于一个本质上需要随着新信息出现而适应性重新规划的任务，将计划锁定为不可变，恰恰放弃了使该任务值得用代理自动化的核心能力。
诚实、可辩护的立场（也是论文作者本人采取的立场）是：这是一个值得深入理解的真正权衡，而不是在所有情况下都严格优于循环的替代方案。在适应性比审计性更重要时使用循环。在相反情况下使用图。大多数真实系统受益于同时拥有两种模式，并根据任务有意识地选择，而不是将任何一种作为永久默认。
一个工作示例：图结构化的代码迁移
为了使五步结构和三个承诺具体化，以下是如何将它们应用于一个真实、常见的任务：将遗留模块迁移到代码库中的新框架版本。
规划状态在开始时运行一次。它分析模块，识别每个需要更改的文件，并产生一个固定的、编号的迁移步骤列表，每个步骤都有一个明确的成功标准——例如，步骤 4 在更新后的文件编译通过且该文件的现有测试套件无需修改即可通过时成功。这个计划被锁定。这是承诺一，不可变，在实践中。
执行状态按顺序处理计划中的步骤。对于每个步骤，它应用计划中定义的特定更改，并报告结果——通过或失败——并附上实际的编译器输出或测试结果作为证据，而不是自我评估的“看起来正确”。这是承诺二中的执行层，严格与失败时做什么的决定分离。
当一个步骤失败时，图转换到恢复状态，它遵循一个定义的协议而不是即兴重试。尝试一：以更窄的范围重新应用相同的更改，隔离出文件中导致编译失败的具体部分。尝试二（如果第一次失败）：回退到针对这种特定失败的文档化替代迁移模式，从一个小的已知修复库中提取，而不是每次都重新发明。如果两个定义的尝试都失败，图转换到升级状态——这是承诺三，严格升级，而不是第三次即兴尝试。
升级状态直接通知人类，附带完整历史：哪个步骤失败，两次恢复尝试都尝试了什么，以及每次的具体错误输出。人类在完整上下文中审查这个具体失败，而不是几天后才发现一个代理一直在循环中默默重试相同的错误方法，消耗成本且没有记录原因。
重复关闭成功步骤的循环，将图移动到锁定计划中的下一个项目，直到列表耗尽，此时运行达到完成。
注意这相比于作为非结构化循环运行的等效任务给你带来了什么。每一个决策——是否重试、如何重试、何时放弃——在运行开始前就已经在图的定义结构中可见，而不仅仅是通过事后阅读记录并推断模型当时在想什么才能发现。一个代码审查者或合规审计者可以查看图的定义本身，就知道系统在每个失败场景中能够做什么，而无需观看它运行。
图工程与循环工程：何时选择哪种
鉴于两种模式都是真实的、有文档记录的，并且各有真正的优势，以下是一个实用的决策框架，用于为特定任务在两者之间选择，而不是将任何一种视为永久默认。
当任务是真正探索性的、无法预测可能出错的形式、并且模型即兴应对意外情况的能力正是你依赖的能力时，选择循环。 研究任务、根因真正未知的开放式调试、以及僵硬结构会主动损害输出的创造性工作，都更倾向于循环的适应性而不是图的可审计性。
当任务事先足够了解、可以实际枚举可能的失败模式、无界且未审计的重试循环的成本确实很高、并且人类审查者（无论是合规团队、安全审计员，还是仅仅是你自己未来调试生产事故的你自己）需要检查系统能够做什么而无需重新阅读完整执行记录时，选择图。 迁移、金融交易、任何涉及受监管数据的事情、以及长时间无人值守的代理工作（其中静默失败可能持续数小时才被发现），都更倾向于图的结构而不是循环的灵活性。
这两种模式在一个更大的系统中也并非互斥。一个常见的实用设计是在外层使用图，用于整体任务结构及其停止条件，同时允许在单个执行状态内部运行一个循环，用于真正需要探索性的子任务——找出如何实现一个具体步骤。这让你在最重要的层次（系统能够做什么的整体形状）获得图的可审计性，同时在一个真正有价值的即兴发挥层次（一个有限工作片段的细节）保留循环的适应性。
在信任图之前先测试它
在将图结构化系统用于任何真实任务之前，用专门针对三个承诺设计的压力测试来运行它，因为每个承诺如果实现草率，都有其静默失败的方式。
测试不可变计划承诺： 故意在运行中途构建一个场景，其中“明显正确的”下一步（如果系统自由推理）会偏离锁定计划。确认系统实际上升级给人类，而不是默默自行适应计划。如果它默默适应，那么计划在实践中从未真正不可变，无论代码如何组织。
测试分离层次承诺： 检查执行层的失败报告是否包含任何关于下一步应该做什么的决策痕迹——比如嵌入在应该是中性的通过/失败报告中的“这可能需要不同的方法”之类的短语。如果执行层已经在形成关于恢复的意见，那么与恢复层的分离就不是真实的，只是被重新标记了。
测试严格升级： 故意向系统提供一个两个定义的恢复尝试都无法修复的失败，并确认它在定义的极限处干净地升级，而不是尝试未定义的第三种方法。这是图工程中测试循环停止条件以应对真正无法解决的任务的等价物，它捕获了完全相同的静默昂贵故障类别。
除了这三个针对性测试，还要跟踪一个在循环替代方案中通常无法干净得到的指标：运行达到升级状态的比率，按每次失败的具体恢复尝试细分。如果一个图在同一个具体的恢复步骤上不断升级，那说明该步骤定义的协议校准不当，而不是底层任务普遍困难——这与跟踪循环停止条件触发器的诊断价值相同，只是在这里粒度更细，因为故障点是一个命名、可检查的状态，而不是一个不透明记录中的推断时刻。
首次构建图时的常见错误
对于首次构建图结构化系统的人，少数几个特定错误会反复出现，提前了解它们可以节省大量调试时间。
将计划视为名义上的不可变。 在纸上锁定计划，同时允许执行层在实践中默默偏离它，会产生最坏的情况：没有真正的适应性，也没有真正的可审计性，因为轨迹不再与你将审查的锁定计划匹配。
将三个层次合并回一个，因为感觉构建更快。 让执行层也决定是否恢复，跳过承诺二的分离，破坏了框架的实际目的。如果规划、执行和恢复不是真正独立的，你就构建了一个穿着图词汇的循环，而不是一个真正的图。
编写一个模糊到根本不是协议的恢复协议。 “尝试合理次数的替代方法”不是一个严格的升级协议，而是一个软指令，具有与无界循环相同的故障模式，只是用图工程的语言描述。一个真正的协议会命名具体的尝试次数和每次的具体条件。
跳过对适用性的诚实评估。 因为图工程是更新、听起来更严谨的框架，就为一个真正开放式的探索性任务构建图，而不是因为该任务实际上受益于这种权衡，结果会产生一个比循环更难构建、在实际工作中比循环更差的系统。
证据的诚实状态
以本课程开头时提到的保留意见作为结尾，因为在这里它比大多数技术文章更重要。上述三个承诺是一个真实、仔细推理的提案，针对 70 个真实系统进行了分析，以确定循环在何处静默失败。根据作者自己的明确声明，它们尚未被验证能在生产规模上带来承诺的好处。
这并不意味着框架毫无价值。它意味着它是一个真正有前途的设计，值得有意识地理解和实验，诚实地跟踪自己的结果，而不是假设理论论证会自动转化为实践。如果你使用本课程构建了一个图结构化系统，你能做的最有价值的事情是衡量它是否实际减少了其目标的具体故障模式——无界重试、未检测到的运行时计划漂移、未审计的恢复决策——针对你自己的真实使用情况，而不是因为论证在纸上令人信服就假设有改进。
这种纪律——将一个经过充分推理的框架视为一个待测试的假设，而不是一个不加批判地采纳的定论——本身就是本课程中所有内容的元技能。图工程、循环工程，这个快速发展的领域中任何命名实践，都值得正确学习，并诚实地针对自己的结果进行测试，而不是仅仅因为它有一个名字和一篇论文就采纳。
关注 @cyrilXBT 以获取关于此框架的更新，随着真实世界的实现和结果开始出现。
