很多 AI 代理项目最后都会退化成一个不断调用模型的 while 循环：上下文越来越长，职责越来越混，直到结果开始失真。
它们不进行路由。它们不进行分支。它们不进行并行化。它们运行一个循环，希望它能工作，当它不起作用时调试几周。
下面用 11 个阶段，把单一循环改成能够分支、自检并汇聚到明确输出的任务图。
先从一条真实流程开始画。每条边都要能说明传递了什么数据，以及失败时回到哪里。
循环工程是真正的进步。你不是只让Claude执行一次并复制输出，而是建立了一个系统，每次迭代都会重试、验证和改进。这就是第三时代。
但循环仍然是一个代理执行一个任务。当任务变得复杂时，一个循环会淹没在上下文中，混合关注点，并试图同时做所有事情。图工程是下一个层次：你设计流程。
图工程要把四件事写清楚：哪个代理正在运行，失败后发生什么，结果流向哪里，以及什么时候必须由人介入。
一个循环是一个代理变得更智能。一个图是多个代理协调工作。
01 为什么一个循环是不够的
一个循环赋予一个代理自主性。它会重试，从失败中学习，并在每次执行中改进。对于单一目的的任务——修复这个错误、总结这份文档、清理这个数据集——一个循环就足够了。你定义目标，附加验证器，设置停止条件，然后让它运行。
问题开始于任务涉及多重关注点的情况。研究 + 分析 + 编码 + 审查。一个智能体试图完成所有四项任务，会把上下文窗口填满混合信息，丢失对早期步骤的跟踪，并产生看似完整但检查后会崩溃的工作成果。
研究渗入了分析。代码忽略了审查。代理正在做四项工作，却只有一份上下文预算。
这不是模型的限制。Sonnet 和 Opus 对于每一个单独的任务都绰绰有余。限制在于架构。你要求一个工作者在同一次对话中同时扮演研究员、分析员、建设者和审阅者的角色。
解决方案不是更大的上下文窗口。解决方案是将工作分配给各个擅长做一件事的代理，并将它们连接起来，使一个的输出成为下一个的输入。
从循环到图的转变，就像一个独立开发者加入团队时所做的转变。一个人做所有事情在项目不复杂时很快。但当项目复杂时，你就需要角色分工、交接和审查。
02 。四个构建模块
每个图表，无论多么复杂，都是由四个基本要素组成的。你不需要框架。你需要函数、字典和if语句。
-
节点。一个只做一件事的函数。一次Claude调用、一次工具执行、一次数据库查询、一次文件写入。它接收输入状态并返回输出状态。节点不知道它之前发生了什么，也不知道之后会发生什么。它只知道自己的工作。
-
边。连接两个节点的连接。「研究之后，运行分析。」边可以是无条件的（总是）或有条件的（只有当 state["status"] == "needs_more_data" 时）。有条件的边是图形进行决策的方式。
-
路由器。一个特殊的节点，它会检查当前状态并选择要走的路径。它本身不执行工作。它对输入进行分类并将其发送给正确的专家。可以把它看作是一个调度员，而不是工人。
-
状态。一个贯穿整个图的字典。每个节点都会从中读取并写入它。状态是图的记忆。没有它，每个节点都会从零开始，图无法知道已经发生了什么。
03 . 四个时代
每一代人工智能工程都吸收了前一代的成果。提示工程教会了我们如何编写良好的指令。上下文工程教会了我们如何提供正确的数据。循环工程教会了我们如何构建一个自主代理。
图工程教会我们将许多代理连接成一个协调的系统。
大多数人仍处于第一或第二阶段。他们写一个提示，可能附上一些上下文，并期望一次Claude调用就能完成整个工作。而那些现在正在发布真正产品的开发者处于第三或第四阶段。他们不是在写更好的提示，而是在设计更好的流程。
04 . 模式：顺序链
最简单的图。节点 A 运行，将其输出传递给节点 B，然后节点 B 再传递给节点 C。没有分支，没有路由。大多数「人工智能管道」都是这样的。
顺序执行在每一步总是成功且顺序从不改变时有效。数据提取、格式转换、先翻译再总结。一旦任何一步可能失败或路径可能变化，你就需要使用其他四种模式中的一种。
顺序链的最大风险是错误传播。如果节点A产生了错误的输出，节点B会在该错误输出的基础上继续处理，节点C又在其基础上处理。到收尾时，错误已经在三层间累积了。
这就是为什么即使是简单的顺序图，在末尾也会从验证节点中受益。
05 . 模式：路由器
路由器会检查输入并选择几条路径中的一条。并不是每个节点都会运行。路由器会为任务选择合适的专家。这就是构建一个可以处理多种类型任务而无需将每个工具都加载到一个代理中的系统的方法。
关键见解：路由是一个分类任务，而不是推理任务。你不需要 Sonnet 来判断一张工单是关于账单还是错误。Haiku 可以在毫秒内处理，而且成本仅为一小部分。将昂贵的模型留给专家内部的实际工作。
每个专家应该有自己的系统提示和自己的工具集。代码代理需要 run_tests 和 write_file。研究代理需要 web_search 和 read_doc。给每个代理所有工具意味着错误的工具调用、浪费的令牌和混乱的输出。
对于细微差别：如果你的路由器做出了错误的调用，通常的解决方法是更好的系统提示，而不是更大的模型。
写 5 将每个类别的6个真实示例输入到路由器的提示中。在路由任务上，对 Haiku 进行少量示例分类的表现优于对 Sonnet 的零样本分类。
06 . 模式：并行分流
多个节点在相同的输入上同时运行。收集器会等待它们全部完成并合并结果。三个代理并行运行意味着你的总时间取决于最慢的代理，而不是三个代理时间的总和。
约束条件是独立性。如果Agent B需要Agent A的输出，就不能将它们并行处理。如果两者处理相同的输入并生成独立的输出，则可以。竞赛分析是一个清晰的例子：每个竞争者一个代理，全部同时运行，结果在最后合并。
合并节点是大多数人投资不足的地方。合并三个 JSON 数据块很容易。将三份研究报告合并成一个连贯的综合报告则需要专门的提示和独立的质量标准。把合并节点当作真正的智能体，而不是字符串连接处理。
07 模式：带有门控的循环
构建者代理完成工作。一个单独的审查者代理进行检查。如果审查失败，构建者将重新尝试，并将失败原因附加到状态中。这是每个自我纠正代理系统背后的模式。
关键规则：构建者和审查者必须是不同的主体。通常使用不同的系统提示，有时使用不同级别的模型。构建者的工作是生成内容。审查者的工作是拒绝。如果同一个主体审查自己的工作，它就会批准自己的错误，因为产生缺陷的推理与评估它的推理是相同的。
评论者的提示应该是对抗性的。不是「这好吗？」，而是「找出所有缺陷、不一致和遗漏的边缘情况。如果没有发现问题，则回复 {passed: true}。如果不确定，则判定失败。」严格的评论者会发现真正的错误。礼貌的评论者会对所有内容都放行。
08 . 模式：人类参与循环
图表在特定节点暂停，等待人类批准后继续。智能体负责研究并起草行动方案。人类审核关键决策。批准后，智能体执行。
这种模式是针对任何昂贵的、不可逆的或高风险的事情是强制性的。发送电子邮件给客户、部署到生产环境、执行金融交易、删除数据。图表处理工作。人类做出判断决定。
审批节点应准确向人展示将会发生什么以及成本是多少。不是「您批准吗？」，而是「此操作将发送 2,400 封电子邮件到账单部门，标题为此，内容为此。预计费用： $12 。批准吗？」
具体到人类可以在 5 秒内做出真正决定。
09 。状态流和模型分层
State 是一个扁平字典，每个节点都从中读取和写入。保持明确：每个节点都应声明它读取哪些键和写入哪些键。当图表出错时，你检查的第一件事就是 state。如果你无法追踪哪个节点写入了哪个键，你就无法调试任何东西。
模型分层是第二个生产关注点。并非每个节点都需要相同的模型。路由器进行分类：俳句。构建器进行推理：十四行诗。对高风险输出的最终质量门控：史诗。使用十四行诗进行路由就像雇用一位高级工程师来分拣邮件。它可行，但你在错误的任务上浪费了预算。
10 . 回退路径和错误处理
正常流程可以正常运行。任何意外错误都会导致整个图崩溃。生产环境中的图需要为每个可能失败的节点设置回退边。
回退并不是「忽略错误」。它是在图中处理失败的独立路径。如果研究代理超时，返回部分结果并标记它。如果审核者崩溃，跳过自动审核并转到人工审核。如果整个图在最大重试次数后失败，将状态保存到磁盘并发送警报。用户获得的将是有用的东西，而不是堆栈跟踪。
11 . 完整的工作示例
这是一个完整的图表，用于处理客户支持工单。它使用 Haiku 对工单进行分类，使用 Sonnet 将其分配给专业人员，专业人员起草回复，审阅者进行检查，如果通过审核，回复将发送。
如果被拒绝，专家会根据审阅者的反馈重试。所有五种模式在同一图表中。
分类（俳句）-> 路由 -> 草稿（十四行诗）-> 审阅（十四行诗）-> 发布或重试。达到最大重试次数后回退到人工处理。 在 60 行以内。无框架。
6 本周与Claude构建的图表
-
工单分类：Claude根据类别和紧急程度对收到的工单进行分类。将每个工单分配给具有特定领域指令的专业代理。发送前由审阅者检查。
-
竞争分析：Claude 为每个竞争对手生成一个子代理。所有代理并行进行研究。一个合并节点将研究结果综合成一份报告。
-
PR 审查流程：Claude 阅读差异，运行测试，撰写审查评论。第二个代理会在发布前审核这些评论，以检查是否有误报。
-
博客文章流程：研究代理收集资料。撰写代理起草文章。编辑代理检查事实和语气。循环重试直到编辑通过。
-
带验证的 ETL：Claude 从 PDF 中提取数据，转换架构，加载到数据库。验证代理会抽样行并在提交前标记异常。
-
事件响应：警报触发图表。Claude 阅读日志，识别根本原因，起草修复方案和事故总结。在部署前，由人工批准修复。
人们破坏他们第一个图表的五种方式
-
× 巨型整体节点。一个节点承担所有功能。如果它失败了，所有都失败。将其拆分为具有单一职责的更小节点。
-
× 节点之间没有状态。每个节点从头开始。没有共享字典，没有传递上下文。图形忘记了前一个节点学到的内容。
-
× 没有后备路径。正常路径可以工作。任何错误都会导致整个图形崩溃。始终构建一个后备边。
-
× 用十四行诗进行路由。路由是分类。俳句更快更便宜。在重要的地方使用十四行诗：构建和审查。
-
× 跳过关卡。没有审核节点。第一次错误答案发送给客户，就是大家最后一次信任系统的时间。
结论：
循环是一个智能体。图是一个团队。
循环工程是将提示变为构建的突破。你学会了制造一个会重试、验证和改进的智能体。这是一项真正的技能。现在仍然如此。
但一旦工作变得复杂，每个团队都会胜过每个单独操作员。图表是你构建智能体团队的方式：一个研究者负责收集，一个分析师负责推理，一个写手负责起草，一个审阅者负责拒绝。每个智能体都很简单。图表使它们变得强大。
这里的核心代码不依赖特定框架。函数、字典和 if 语句就能表达一个最小图；LangGraph 或 CrewAI 只是实现选择，先理解五种结构模式，再决定是否引入框架。
两种类型的构建者在 2026 。有些人仍然为所有事情运行一个循环。有些人在设计流程。模型是相同的。架构则不同。
把路线图落到一个最小可验证图
先不要搭一个「全能多代理平台」。挑一项存在真实分支的工作：研究可以并行，写作要等待资料，事实核查失败后需要返回修订，最终发布前必须人工确认。
路由工作流适合先分类输入，再把任务发送给对应处理路径。 独立子任务可以并行，同一输出也可以交给不同检查器从多个角度复核。 当子任务无法预先枚举时，再考虑 orchestrator-worker，让编排器动态拆解并汇总结果。
无论采用哪一种结构，节点都要有明确输入、输出和失败状态。Claude Code 的代理循环本身仍是收集上下文、采取行动、验证结果；图只是把多个这样的循环按依赖关系组织起来。 给每个节点配置测试、截图或期望输出，并在复杂任务中先探索、计划，再实现和验证。
最小验收清单：
- 每条边都能解释为什么存在；
- 并行节点之间没有隐藏的写入冲突；
- 重试有预算和停止条件；
- 状态可以持久化并支持从检查点恢复；
- 高风险动作前保留人工批准；
- 失败时能指出具体节点和证据，而不是只返回「代理失败」。