TLDR智能体「下一步做什么」的决定不该埋在模型推理的黑箱里——对于高成本、需审计、失败模式能提前枚举的任务代码迁移、金融交易、受监管数据应把它显式建成图计划一旦锁定就不可变、规划/执行/恢复三层分离、恢复走固定次数上限后强制升级给人而真正探索性、需要临场重规划的任务仍该用循环两者按任务有意识地切换而非把某一种设成默认。关键前提是这套框架目前只是论证严谨但尚未大规模验证的假设正确姿势是自己按「是否真的减少了失控重试、运行中途计划漂移、无审计恢复」去实测而不是因为它有论文和名字就照单全收。循环把一个决定即接下来运行什么藏进了黑箱。每当智能体循环决定是重试、升级处理还是继续下一步时这个决定都发生在模型自身的推理过程中——你看不见它事后也无法审计除非重新阅读模型的原始输出并寄希望于它如实解释了自己的决定否则根本无从检查。图则让同一个决定变得明确白纸黑字地写下来甚至在运行开始之前就可以检查。这绝非无关紧要的区别它正是2026年4月发表的一篇真实 arXiv 论文背后的核心论点这篇论文重新定义了我们应当如何构建智能体系统。在课程继续之前有一点值得开诚布公地说明论文作者本人也加入了公允性声明明确表示这是一项尚未实现的设计它能否在实践中兑现承诺的收益仍是一个有待实证研究的问题。本课程会如实讲解这一框架包括这项重要的保留意见因为理解一个真实存在、论证严谨但尚未得到大规模验证的提案比假装它已经是定论更有价值。学完本课程你将理解图工程究竟是什么、为什么它会作为循环之上的一层而存在、这一框架中的每个图都建立在哪三项承诺之上以及如何构建你的第一个图同时你也会如实了解目前的证据能够证明什么又不能证明什么。为什么循环存在上限要理解图为何存在你需要准确理解循环从哪里开始变得不再够用。在本文所讨论的智能体语境中循环是这样一个周期智能体尝试执行任务、观察结果、决定接下来做什么并不断重复直到满足某个条件。这种方式对极其广泛的任务都卓有成效但从结构上看它恰恰在最关键的时刻成为了黑箱——也就是决定接下来会发生什么的时刻。当循环中的智能体决定重试一个失败的步骤时这个决定来自模型根据自身上下文进行推理后生成的选择。你无法在决定发生之前检查它只能在事后观察结果。如果智能体连续5次重试同一种注定失败的方法每次都在消耗成本那么循环的结构本身并不会阻止这种行为因为重试的决定完全存在于模型自身的判断之中而不是由任何外部、可检查的规则作出。对于风险低、成本低的任务来说这并无大碍因为偶尔浪费一次重试不会造成实质损失但对于周期长、成本高或风险高的工作它会成为真正的隐患而这些恰恰是人们越来越愿意交给智能体系统处理的任务。论文的核心论点是随着智能体系统承担越来越重要的工作“接下来运行什么”这一问题的不透明性就不再是一个可以接受的黑箱而会成为真正值得直接通过工程手段解决的故障点。图究竟是什么在这一框架中图会用运行前定义好的明确结构取代模型对下一步的隐式决定。智能体不再在不透明的上下文窗口中自行推理出“我应该重试”或“我应该升级处理”而是由图提前准确定义存在哪些状态、状态之间允许进行哪些转换以及哪些具体条件会触发每一种转换。智能体仍然会在每个状态中完成真正的工作但它不再一边运行一边悄无声息地决定整个流程的形态。任何一次通过此类图的运行都可以用一个包含五个动作的结构来描述规划、执行、恢复、升级、重复。规划是将任务拆解成明确步骤序列的阶段执行是智能体实际完成当前步骤工作的阶段恢复是执行失败后按照既定协议采取行动而不是临时决定如何重试升级是图将控制权交给人类而不是继续尝试自动恢复的明确节点重复则闭合整个周期让系统进入计划中的下一个步骤。请注意它与循环相比发生了什么变化。这五个动作如今都是图中有名称、可检查的状态状态之间也存在明确定义的转换而不再是一次模型调用内部悄无声息作出的决定。三项承诺这一框架中的每个图都建立在三项具体承诺之上。深入理解这三项承诺才是图工程作为一门学科的真正核心其重要性超过任何具体的实现细节。承诺一不可变计划执行计划不能在运行途中发生变化。一旦计划生成并锁定在本次运行期间它就会始终保持为同一个固定版本。智能体不能因为执行到一半时发现了某些情况就悄无声息地修改自己的计划——而循环中的智能体往往会这样做并且外部不会留下任何计划已被修改的记录。这听起来很有约束性而它本来就是有意如此设计的。约束本身就是全部要义。一个可以在运行途中随意修改自身计划的智能体恰恰会让自己的行为变得无法事后审计因为你事后查看的计划并不是它真正遵循的计划而只是计划在不断漂移之后最终变成的样子。锁定计划是用真正的灵活性换取真正的可检查性。这种取舍并非没有代价我们应当诚实地正视它而不是把它当作在所有情况下都绝对更优的改进。如果出现原计划未曾预见的全新情况不可变计划的应对效果会逊于能够自由适应的循环。这项承诺是一次有意识的押注对于该框架所针对的任务类型可预测、可审计比最大程度的适应能力更重要。承诺二层级分离规划、执行和恢复分别存在于三个相互独立的层级中而不是纠缠在同一个循环里、在一段连续的推理过程中同时完成。规划层负责生成承诺一中的不可变计划除此之外什么也不做——它不执行步骤也不处理失败。执行层运行已经定义的步骤并报告结果——它不决定失败后应当发生什么只报告实际发生了什么。恢复层接收失败报告并应用既定协议——它不直接执行新的工作只决定如何应对已经发生的情况。这种分离是对验证循环中“构建者”与“裁判者”相互分离这一原则的刻意复刻产出工作的角色不应同时负责评估这项工作或决定如何处置它因为将两者合并会破坏让检查本身具有意义的独立性。在这里分离的不是两个角色而是三个层级但底层逻辑完全相同——如果一个系统在同一段不加区分的流程中完成规划、执行和恢复那么它就无法真正独立审计其中任何一项职能因为在事后可供审查的轨迹中这些职能从未真正彼此分开。承诺三严格升级恢复过程遵循固定协议而不是无限重试并期待某种方法最终能够奏效。这项承诺最直接地解决了困扰那些缺乏真正停止条件的循环的 token 失控消耗问题。严格升级协议会事先明确定义允许进行多少次恢复尝试、怎样才算恢复成功或失败以及达到既定上限的那一刻究竟会发生什么——把控制权交给人类而不是针对同一种失败的方法再尝试一个更有创意的变体。论文对70个真实世界系统的分析发现相当大一部分智能体循环实现完全没有为恢复尝试设定正式上限。这意味着一旦出现问题系统的实际行为取决于模型当时碰巧作出的决定而不是任何经过人类提前审查和批准的规则。严格升级直接弥补了这一具体缺口。构建你的第一个图下面是一条真正构建此类图的实践路径它会把三项承诺转化为可以实际实现的内容而不只是停留在概念理解层面。在编写任何代码或提示词之前先在纸面上明确定义所有状态。对于一个典型任务通常至少包括规划、执行步骤 N、从失败中恢复、已升级、已完成。针对每个状态都要准确写下系统处于该状态时会发生什么以及哪些条件会触发系统离开该状态。编写计划生成步骤时应让它输出一个固定、有版本记录的制品而不是一份系统其他部分可以悄无声息修改的动态文档。一种简单实用的实现方式是将计划生成为由离散步骤组成的编号列表为每个步骤设置明确的成功标准并在剩余运行期间将该列表视为只读内容。任何真正需要偏离计划的情况都应触发明确的人工升级而不是悄无声息地在内部修改计划。构建执行层时应让它只负责报告结果——通过或失败并附带具体细节——绝不自行决定接下来会发生什么。这与验证循环中的“构建者”角色完全一致负责产出工作并如实报告但不同时充当决定是否重试的角色。为恢复层建立一套明确、带编号的协议。先尝试一种具体的替代方法如果失败再尝试第2种不同的具体方法如果仍然失败就升级处理。协议应当具体到让人类提前阅读后能够准确预测系统在每个阶段会做什么而不是只给出“尝试修复合理的次数”之类的模糊指令。设置升级状态时要确保进入该状态是一个真实、可见的事件而不是被悄悄记进日志后无人理会。系统应当通知人类并附上所有尝试的完整历史记录以及每次尝试失败的原因。这与验证循环通常建议为停止条件采用的原则相同。这一框架真正有用和无用的场景诚实看待图工程的局限比把它视为在所有情况下都优于循环的通用升级更有价值论文自身也支持这种更为审慎的表述。如果任务中可能出错的情况可以提前得到较充分的理解、可审计性比最大程度的适应能力更重要而且失控、无上限的重试周期会造成真正高昂的代价——无论是计算成本还是错误结果抵达真实用户或真实系统后造成的后果——那么图确实能够发挥作用。对于真正开放、探索性的任务图的适用性则较差因为你无法提前有效预测失败会以何种形式出现而系统的价值恰恰来自它能够临场应对无人预见的情况。对于一个从根本上要求系统随着新信息出现而自适应地重新规划的任务如果将计划锁定为不可变就等于舍弃了最初让这个任务值得用智能体自动化的那项核心能力。诚实且站得住脚的立场——也是论文作者本人所采取的立场——是这是一项值得深入理解的真实取舍而不是在所有情况下都严格优于循环的替代方案。当适应能力比可审计性更重要时使用循环反之则使用图。大多数真实系统都会受益于同时具备这两种模式并根据具体任务有意识地作出选择而不是将其中任何一种永久设为默认方案。完整示例图结构化代码迁移为了具体说明五动作结构和三项承诺下面展示它们如何应用于一个真实而常见的任务在整个代码库中将一个遗留模块迁移到新的框架版本。规划状态只在开始时运行一次。它会分析模块找出所有需要修改的文件并生成一份固定的迁移步骤编号列表每个步骤都有明确的成功标准。例如当更新后的文件能够通过编译并且该文件现有的测试套件无需修改即可通过时步骤4就算成功。随后这份计划会被锁定。这就是承诺一——不可变——在实践中的体现。执行状态按照顺序逐一处理计划中的步骤。对于每个步骤它会应用计划中定义的具体修改并报告结果是通过还是失败同时附上实际的编译器输出或测试结果作为证据绝不依赖自我评估式的“看起来没问题”。这就是承诺二中的执行层它与失败后应当做什么的决定严格分离。当某个步骤失败时图会转换到恢复状态按照既定协议处理而不是临时决定如何重试。尝试一缩小范围后重新应用同一项修改准确隔离文件中导致编译失败的部分。尝试二——如果第一次失败退回到针对这类特定故障、已有文档记录的备用迁移模式该模式来自一个包含已知修复方法的小型库而不是每次临时编造。如果两次既定尝试都失败图就会转换到已升级状态。这就是承诺三——严格升级——而不是再进行第3次临时尝试。已升级状态会直接通知人类并附上完整历史记录哪个步骤失败、两次恢复尝试分别做了什么以及每次尝试产生的具体错误输出。人类可以在掌握完整上下文的情况下审查这次具体失败而不是几天后才发现智能体一直在循环中悄无声息地重试同一种无效方法不断消耗成本却没有留下任何解释原因的记录。对于成功的步骤重复动作会闭合整个周期使图进入已锁定计划中的下一个项目直到列表中的项目全部处理完毕此时本次运行将进入已完成状态。请注意与采用非结构化循环运行同一个任务相比这种方式带来了什么。每一个决定——是否重试、如何重试以及何时放弃——都在运行开始前就呈现在图的既定结构中而不是只能在事后阅读执行记录并推测模型当时可能在想什么。代码审查者或合规审计人员只需查看图的定义就能准确知道系统在每一种失败场景中可以采取哪些行为完全不必亲眼观察它的运行过程。图工程与循环工程何时该用哪一种既然这两种模式都真实存在、有文档记录而且各自具备真正的优势下面给出一个实用的决策框架帮助你针对具体任务作出选择而不是把其中任何一种永久设为默认方案。如果任务确实具有探索性你无法提前预测可能出现的问题会是什么形态而且你所依赖的能力恰恰是模型能够临场应对未曾预料的情况那么就选择循环。研究任务、起初确实不知道根本原因的开放式调试以及僵硬结构会主动损害产出质量的创意工作都更适合循环的适应能力而不是图的可审计性。如果你事先已经充分理解任务可以实际列举可能的失败模式无上限、未经审计的重试周期会造成真正高昂的代价而且人类审查者——无论是合规团队、安全审计人员还是未来调试生产事故时的你自己——需要在不重新阅读完整执行记录的情况下准确检查系统能够采取哪些行为那么就选择图。迁移、金融交易、任何涉及受监管数据的任务以及长时间无人值守的智能体工作——其中一次无声的失败可能在数小时内不断恶化直到有人发现——都更适合图的结构而不是循环的灵活性。在同一个大型系统中这两种模式也并不互斥。一种常见而务实的设计是在外层使用图来规定整体任务结构及其停止条件同时允许循环在单个执行状态内部运行用于完成真正具有探索性的子任务也就是找出如何实现某一个具体步骤。这样一来在最重要的层面——系统整体能够做什么——你可以获得图的可审计性而在真正需要临场发挥的层面——某一项有边界工作的具体细节——你仍然保留了循环的适应能力。信任一个图之前先测试它在将图结构化系统用于任何真实任务之前应围绕三项承诺专门对它进行压力测试因为如果实现得不够严谨每一项承诺都有自己悄然失效的方式。要测试不可变计划这项承诺可以有意在运行中途构造一个场景如果系统能够自由推理那么“显然正确”的下一步会偏离已锁定的计划。确认系统确实会升级给人类处理而不是自行悄无声息地调整计划。如果它在没有说明的情况下自行适应那么无论代码采用了什么结构这份计划在实践中都从未真正不可变。要测试层级分离这项承诺应检查执行层的失败报告中是否包含任何关于接下来应当做什么的决定痕迹例如在本应保持中立的通过或失败报告中夹带“这可能需要换一种方法”之类的表述。如果执行层已经在对恢复方式发表意见那么它与恢复层并未真正分离只是换了一个标签而已。要测试严格升级可以有意向系统提供一种两次既定恢复尝试都无法修复的故障并确认它会在达到既定上限时顺利升级处理而不是尝试未定义的第3种方法。这相当于图工程中针对真正无解的任务测试循环的停止条件能够捕捉完全相同的那类悄无声息却代价高昂的故障。除了这三项针对性测试还应在真实使用中持续跟踪一个循环式替代方案通常无法清晰提供的具体指标运行进入已升级状态的比例并按照每次具体是哪一次恢复尝试失败进行细分。如果一个图总是在同一个具体恢复步骤升级就说明该步骤的既定协议设置不当而不是底层任务全都同样困难。这与跟踪循环的停止条件触发情况具有相同的诊断价值只不过在这里信息粒度更加精细因为故障点是一个有名称、可检查的状态而不是从不透明的执行记录中推断出的某个时刻。初次构建图时的常见错误人们第一次构建图结构化系统时经常会反复犯几种具体错误。提前了解这些错误可以在之后节省大量实际调试时间。计划只在名义上不可变。只在纸面上锁定计划却仍允许执行层在实践中悄无声息地偏离计划会让系统同时失去两方面的优势既没有真正的适应能力也没有真正的可审计性因为执行轨迹已经不再与供你审查的锁定计划相符。因为觉得构建起来更快就把三个层级重新合并成一个。让执行层同时决定如何恢复、跳过承诺二要求的分离确实很有诱惑力但这会破坏该框架的真正目的。如果规划、执行和恢复并非真正相互独立那么你构建的只是一个套用了图术语的循环而不是真正的图。编写的恢复协议过于模糊以至于根本算不上协议。“尝试合理数量的替代方法”并不是严格升级协议而是一条软性指令它与无上限循环具有相同的故障模式只是换成了图工程的语言来描述。真正的协议会明确指出具体的尝试次数以及每次尝试所适用的具体条件。跳过对适用性的诚实评估。仅仅因为图工程更新、听起来更严谨就为真正开放、探索性的任务构建图而不是因为该任务确实能从这种取舍中受益最终得到的系统会比循环更难构建完成实际工作的效果也比原本采用循环更差。证据的真实现状最后让我们回到本课程开篇时提出的保留意见因为它在这里比在大多数技术文章中都更加重要。上述三项承诺是一个真实存在、经过缜密推理的提案论文通过分析70个真实系统准确找出了循环会在何处悄然失效。但正如作者本人明确声明的那样它们是否能在大规模生产环境中兑现所承诺的收益目前尚未得到验证。这并不意味着这一框架毫无价值它意味着这是一个真正有前景、值得理解并有意识地开展实验的设计你应当如实跟踪自己的结果而不是假设理论论证会自动转化为实践成果。如果你根据本课程构建了一个图结构化系统最有价值的一件事就是衡量它是否真的减少了其所针对的具体故障模式——无上限重试、未被发现的运行中途计划漂移以及未经审计的恢复决定——并结合你自己的真实使用情况进行比较而不是仅仅因为纸面论证很有说服力就默认它必然带来了改进。这种原则本身——把一个论证充分的框架视为有待检验的假设而不是不加批判地采用的既定事实——才是本课程所有内容背后真正的元技能。图工程、循环工程以及这个快速发展领域中的任何一种命名实践都值得认真学习也值得结合你自己的结果进行诚实检验而不是仅仅因为它拥有一个名字和一篇论文就直接采用。以上为译文以下为AI反思这篇文章包装成「2026年4月的新论文」但它描述的东西在软件工程里已经存在几十年只是换了套 AI 词汇。「不可变计划」就是编译器的执行计划、就是提交给调度器的 DAG「图取代循环」就是有限状态机取代自由控制流「规划/执行/恢复三层分离」就是编排层与执行层分离。Airflow 的 DAG 调度、Temporal 和 AWS Step Functions 的持久化执行、分布式事务里的 Saga 补偿模式早就在做「把下一步决定写死在运行前、失败按既定协议恢复」这件事。真正的深层真相是智能体领域在反复地把成熟的编排与控制流概念重新命名、当成新发现来卖。主流叙事——「自主性越高越好、让智能体自己决定一切」——是谁在推是 agent 框架厂商LangChain/LangGraph、各类 AutoGPT 后继项目、估值建立在「智能体自己会搞定」这个魔法上的风投驱动创业公司以及只演成功路径、从不触发失控分支的 demo 文化。反对的是谁是被 token 账单炸过的运维/SRE、需要事后审计的合规与安全团队、以及任何要为线上事故负责的人。文章引用的「70个真实系统里相当大一部分连恢复尝试上限都没有」之所以很少被公开谈论正是因为它拆穿了正在卖给企业的「自主智能体」——它们很多根本没有停止条件而这对自主叙事和演示效果都是坏消息。还有一层被淡化的商业事实「用图罩住循环」并不是尚待实现的设想LangGraph 这类产品早已把它商品化。把它重新叙述成一篇「有待验证的 arXiv 提案」客观上模糊了「这已经是一个成熟产品品类」的现实。与此同时文章罕见地反复强调「尚未验证」——这种坦诚既是它的优点也是一种更高级的说服术越是承认局限读者越倾向于信任并采纳它。这类作者看一个系统第一秒盯住的不是「它能不能完成任务」而是「关键决定发生在哪里我能不能在它运行之前就检查到」。他们把可审计性、可观测性当成系统的一等属性而不是事后补的功能。对应到经典工程语言就是本能地把「控制平面」和「数据平面」分开谁在决定流程走向和谁在干活必须是两拨能分别检查的东西。他们切片问题的方式是「先枚举失败模式再设计正常路径」——正常流程往往很短真正的设计量全在「出错了怎么办、试几次、什么时候放弃、交给谁」。他们抛弃了一个常人默认保留的假设「模型足够聪明让它自己判断就好」。在他们眼里 LLM 是一个不可靠的组件要被约束、被夹在固定协议中间而不是被信任去做流程控制。最后一个思维特征是拒绝「银弹叙事」。他们不说「图严格优于循环」而是把它讲成一次有代价的取舍——用灵活性换可审计性并且主动去想每一项承诺会怎样「悄无声息地失效」计划名义上锁定但执行层偷偷偏离、三层换了标签其实还纠缠在一起、恢复协议模糊到根本不算协议。他们对自己提出的框架也保持对抗性测试的态度把论文结论当成待检验的假设而不是既定事实。今天花 30 分钟挑一个你手上真实的智能体或自动化脚本在纸上先别碰代码把它的所有状态、状态间的转换、以及每个「离开该状态」的触发条件全写下来。写完后问自己给定任意一种失败我能不能只看这张纸就准确预测系统会做什么如果不能你的系统现在还是个黑箱。找一处「同一段代码既干活、又自己决定要不要重试」的地方把它拆成两个函数一个只产出结果并如实报告通过或失败另一个只根据报告决定下一步。这是把「构建者」和「裁判者」分开的最小练习。做完再写一个「注定修不好」的测试用例喂给系统确认它会在到达上限时干净地升级而不是发明第三种没定义过的新尝试。给你的智能体加一个此前循环给不了你的指标「进入升级状态的比例」并按「具体是哪一次恢复尝试失败」做细分。跑一周后看如果几乎总是卡在同一个恢复步骤升级那说明是这一步的协议写坏了而不是任务本身都一样难——这条信息只有在故障点是个有名字的状态时才拿得到。友情提醒先看动机这篇东西标题叫「完整课程」结构是层层递进的教学 每节末尾的可执行清单 「构建你的第一个图」这是典型的内容营销/教育漏斗形态背后大概率挂着课程、付费订阅或某个咨询、产品。而「图成熟、可审计、企业级」这套定位最直接受益的是编排框架和持久化执行平台的厂商——它把企业买家从「自己写循环」推向「采购编排平台」。 再看它没告诉你的缺陷。第一图的建设与维护成本被轻描淡写谁来写、谁来更新这一大堆状态定义任务一演进图就会腐烂而「每次意外都升级给人」恰恰吃掉了当初自动化的 ROI——文章承认了这点但把它埋在「不适用场景」里一笔带过。第二「外层图套内层循环」的混合架构被说得很轻松但真正难的地方边界怎么划、内层那个循环照样能烧爆你的预算几乎没讲。 第三「70个系统」这个数字被当成论据反复使用但我们不知道它的抽样方式和代表性它更多是修辞而非可复现的证据。需要公允地说这篇文章比绝大多数技术软文都诚实它反复声明「尚未验证」、明确讲取舍——但也正因如此要提醒一句「我们很坦诚」本身就是最有效的信任构建手段越是承认局限越容易让你放下戒心去采纳。真正独立的判断应该建立在你自己那份「它到底减没减少失控重试」的实测数据上。