图解工程清晰解读

循环工程在聚光灯下闪耀了大约六周，然后话题就切换了。

7月18日，OpenClaw背后的彼得·施泰因贝格尔发了一个九个字的问题。“我们还在讨论循环，还是已经转向图了？”

几小时后，哈梅尔·侯赛因发表了一篇文章，标题是“循环工程已死，图解工程登场“。

两人至少有一半是在开玩笑。这个领域自我更名的速度如此之快，以至于嘲讽改名本身都成了一门艺术。

但这个玩笑触及了真实问题。一旦你拥有需要协同工作的多个循环，你就会遇到协调问题，而图正是工程师们一直以来描述协调的方式。

这就是图解工程背后的核心思想。现在，让我们把实质内容与梗文化分开。

首先，图本身

一个图由三部分组成。

• 节点 是工作单元，可以是一个智能体、一个单纯的模型调用、一个确定性函数、一个工具，或者是需要人工审批的环节。

• 边 决定下一步运行什么，可以是按顺序、并行，或基于上一个节点的输出进行条件判断。

• 状态 是一个沿着边流动的共享对象。每个节点都从中读取数据并向其写入数据。

graph.add_node("research", research_agent)
graph.add_node("write", writer_agent)
graph.add_node("review", reviewer_agent)

graph.add_edge("research", "write")
graph.add_edge("write", "review")
graph.add_conditional_edge("review",
    lambda state: "done" if state.approved else "write")

这是几乎每个示例都会使用的入门级图。研究员收集资料，写作者起草，评审员评判。如果评审通过，运行结束。如果未通过，一条边会将草稿送回写作者。

三个节点，四条边，其中一条边是一个循环。

这里有一个能重构一切认知的点。一个单一的智能体循环就是一个只有一个节点、且边指向自身的图。图并没有取代循环，而是连接和治理它们。

技术栈不断增长

AI的重心一直在远离模型本身，而每一次转移都获得了一个新名称。

• 提示工程。 你发送的文字。
• 上下文工程。 模型看到的一切，不仅仅是你的指令。
• 框架工程。 围绕模型的代码，负责运行工具、追踪状态和处理错误。
• 循环工程。 驱动单个智能体走向目标的自主循环。
• 图解工程。 跨多个循环的协调层，涵盖何时运行什么、以什么顺序运行、谁检查谁。

每一层都包裹着前一层。一个图由多个循环组成，每个循环需要一个好的框架，每次框架调用都是一个上下文问题，而每个上下文都包含提示。跳过较低层，图只会以更复杂的方式失败。

还有一件事需要坦诚说明。这些都不是新技术。LangGraph早在2024年1月就推出了这种精确的模型——在共享状态上的节点和边。微软的AutoGen拥有GraphFlow，谷歌在其ADK 2.0的整个工作流运行时中也是基于同样的理念。名称是新的，实践却不是。因此，哈梅尔帖子下方最热门的回复之一就是简单的“欢迎回来，langchain“。

所以，这个学科并非发明图，而是知道何时使用图，以及如何防止它腐烂。这部分有四个难题。

难题一：知道一个节点何时值得存在

最常见的失败是将“总结这个PDF“变成一个有五个节点的图：获取器、分块器、总结器、评审器和格式化器。

一个节点只有在代表真正专长时才值得存在——即不同的模型、不同的工具集，或一个真正独立的角色（如只读评审员）。那些可以内联到现有循环中的步骤不是节点。

从业者在这个问题上的看法提供了一个有用的过滤器。如果你不能在餐巾纸上画出图，那它就太复杂了。如果合并两个节点没有损失任何东西，那它们从来就不是两个节点。

难题二：保持共享状态整洁

在一个循环中，失败模式是上下文腐化。在图里，同样的问题转移到了共享状态中。

每个节点都向状态对象写入，所以节点二中的草率写入会成为节点五的自信输入。没人会注意到，直到输出出错，而那时错误数据已经流经了半个系统。

解决方案简单而乏味，却很有效。给状态一个类型化的模式。明确决定哪些节点可以向哪些字段写入。在节点之间设置检查点状态，以便你可以重放一次运行，并准确找出出错位置。

重放有一个注意事项。检查点之后的节点会再次执行，因此任何有外部副作用的节点（如发送电子邮件或创建记录）必须保证运行两次是安全的。

难题三：值得信赖的路由

一条边是一个决策，问题是决策由谁来做。

如果模型决定路由，你会同时获得灵活性和不稳定性。同样的状态在不同运行中可能走不同路径，这使得调试非常痛苦。

谷歌ADK 2.0的设计规则是这方面最清晰的立场。确定性代码应控制可预测的路由，模型只应处理需要实际判断的步骤。

凡是条件可检查的地方，都用代码路由；只有真正需要解读的地方，才消耗模型调用。

难题四：智能体之间相互认可

循环工程最严格的规则是绝不让智能体给自己的作业打分。

图则提高了风险。多个基于同一基础模型构建的智能体，读取同样有缺陷的上下文，会愉快地互相认可，而模型明显更偏好自己的输出。

结果感觉像是工业规模的“组织化废话“——完美结构包裹着一个错误答案。

解决方案是一个有牙齿的评审节点。用不同的模型运行，给它提供全新的上下文而不是完整对话，并将其裁决锚定在图无法伪造的证据上——比如实际运行的测试或实际编译通过的代码。

Cognition在运行其编程智能体Devin一年后也得出了相同结论。他们的工作设置允许多个智能体阅读工作并发表意见，但只允许一个智能体做出更改。

这个区分是有用的部分。阅读可以安全地并行进行，因为一个坏的意见在你按它行动之前没有任何成本。书写才是造成损害的地方，所以你要把它放在一个你能看到的地方。

图何时是多余的

诚实的答案是：大多数时候。

Anthropic公布的数字让成本变得具体。一个单一智能体大约消耗聊天交互的4倍令牌，多智能体系统大约消耗15倍。每增加一个节点，这个倍数就会增加。

当任务真正可以并行化时，天花板是真实存在的。Anthropic的多智能体研究系统在其内部研究评估中比单个Opus智能体高出90.2%，因为研究自然会分散成独立的搜索。但他们《构建有效智能体》的长期建议没有改变。找到最简单的解决方案，只有当任务需要时才增加复杂性。

即使是LangGraph自己的指南也说出了潜台词。如果你的智能体是一个带有工具的简单循环，那么LangGraph就是大材小用。

决策规则相当直接：当工作分裂成真正的专长、需要并行扇出和汇聚、需要在不同步骤使用不同模型、或者需要故障隔离和可审计路由时，才使用图。否则，留在循环中。

从何开始

你不需要在第一天就有一个智能体的组织架构图。逐步构建。

• 首先掌握一个单一的循环，带有刹车、真正的完成检查和一个批评者。由弱循环组成的图只是分布式的失败。

• 在写代码之前在纸上画出图，并质疑每个节点的存在理由。

• 提前定义状态模式并明确写入权限。状态漂移是图腐败的主要方式。

• 让评审节点使用不同的模型和全新的上下文，并将其锚定到外部证据。

• 在每个节点上设置预算上限。一个图是多个循环并行消耗令牌，而弱的验证器此时会同时烧钱。

关键要点

图解工程并不是取代循环工程的新学科。它是每个智能体构建者最终都会面临的一个决策所固定下来的名称。当一个循环不再足够时，协调就成了工程问题。

这个词可能撑不过今年。但设计问题会。

以下是图解工程关键要点总结。

感谢阅读！

干杯 :)

阿克沙伊。