尧图网站建设 
从柯尼斯堡七桥到多智能体编排图工程的技术原理、收益与代价摘要图工程Graph Engineering“最近被频繁提及被视为智能体工程演进的下一步”。但图本身并不新鲜——它诞生于 1736 年欧拉对柯尼斯堡七桥问题的证明。本文从这条历史线索出发结合 Claude Code 的深度研究工作流系统拆解图工程的形式化定义、多智能体编排的五种模式、节点能力进化史以及它真实的成本代价。结论先行图工程不是更聪明的 AI而是一种用并行上下文和协调开销换取广度与可靠性的工程范式是否采用应由任务结构决定。一、从一个具体场景切入Claude Code 的深度研究工作流先抛开概念看一个真实例子。当你在 Claude Code 中发起一次深度研究Deep Research时背后并非由单个智能体独立完成全部研究而是由系统在运行时动态生成一套工作流——这套工作流本身就是一段可执行的 JavaScript 代码会启动超过 100 个智能体分阶段协作。一个典型的工作流可以被抽象为五个阶段阶段智能体数量职责1. 需求界定1明确研究目标与边界2. 主题拆解 信源搜集5为每个子主题寻找可信网站3. 信息获取25抓取并传递原始信息4. 事实核验 可信度投票75交叉验证、对可信度投票5. 报告生成1汇总产出完整报告几个值得注意的工程细节工作流是动态生成的每次新请求都会产出一套全新的工作流智能体数量也随任务规模变化。阶段间大致并行同一阶段内的智能体可同时工作每个智能体拥有独立的上下文窗口和系统提示词。计划被搬进了代码编排逻辑循环、分支、中间变量由脚本持有主会话只保留最终答案实现上下文隔离。这正是本文要讨论的核心对象当任务的执行结构是一张图时我们用图来表达它、编排它、调度它——这就是图工程。二、图的起源柯尼斯堡七桥与欧拉的证明要理解图工程先从图论的源头说起。1736 年瑞士博学家Leonhard Euler思考了一个看似与生活相关的问题柯尼斯堡城有两块大陆、两座岛屿由七座桥连接。是否存在一条穿过城市的路线恰好各经过每座桥一次通过穷举尝试从大陆出发从岛出发换一种过桥顺序你会发现这是不可能的。Euler 也得出了同样结论但真正有价值的不是无解这个结果而是他如何把问题化简节点Node用圆圈表示代表陆地边Edge用黑线表示代表桥梁图Graph节点与边的集合。中间那座岛有 5 条边5 座桥连接到其他区域。基于这种表示Euler 严格证明了这样的路线不存在。关键启示欧拉的工作把地理/物理问题转换成了结构/拓扑问题。今天的多智能体编排做的事情在方法论上完全一致——我们不再问哪个模型更聪明而是问任务应该如何被拆成节点、节点之间如何连接。2.1 为什么深度研究工作流是一张图把上面五个阶段画出来它显然是一张图[需求界定] → [主题拆解] → [信息获取] → [事实核验] → [报告生成]由于执行只从左向右流动没有任何节点回指前面形成循环这张图有一个专门的名字——DAG有向无环图Directed Acyclic Graph。DAG 是图工程中最常见、也最容易落地的结构有向边有明确方向代表数据/控制的流向无环不存在循环依赖因此可以拓扑排序、可以并行调度、可以安全地失败重试。补充一点并非所有智能体图都是 DAG。以 LangGraph 为代表的编排框架明确支持有环图用于表达重试失败的工具调用“重新审题”迭代优化输出这类需要回到前序节点的行为 [citation:2][citation:7]。DAG 与有环图的区别本质上是一次性流水线与可迭代状态机的区别我们在第四节展开。三、为什么要多智能体——并行与关注点分离从原理上说我们当然可以让单个智能体完成上述所有工作。之所以采用图有两个工程层面的核心理由。3.1 收益一并行节省时间把任务并行拆给目标更小的子智能体可以让多个智能体同时工作。对于广度优先探索类任务多源检索、多维度评审、交叉验证串行单智能体的耗时是各子任务之和而理想并行的耗时趋近于最慢的那个子任务。3.2 收益二关注点分离Separation of Concerns每个智能体拥有自己的上下文窗口可以把上下文专注于自身目标一个智能体只负责搜集可信网站它的 prompt 和上下文都很干净另一个只负责事实核验与投票不需要记得前面怎么搜的。反过来若由单个智能体承担同一个上下文窗口要反复复用一部分保存总体目标、一部分服务当前子任务、还要不断总结压缩。上下文污染Context Pollution和长程遗忘随之而来。3.3 收益的边界何时不该拆“能并行不等于该并行”。业界实践给出的判断标准是——仅当上下文可真正隔离时才拆分。如果把本应连贯的子任务如实现功能与写测试强行分给两个智能体产生的**交接损耗handoff cost**可能高于并行带来的收益 [citation:10]。这是图工程最容易被忽视的反面。四、图也有代价15 倍 Token 背后的成本真相图工程并非免费午餐。Anthropic 在介绍其多智能体研究系统的文章中披露过一组硬数字 [citation:1][citation:6][citation:11]对比对象Token 用量相对普通聊天单智能体Agent约4 倍多智能体系统约15 倍回到我们的例子做一笔直观的账每个智能体运行在 Opus 级别模型上拥有独立系统提示词启动时约消耗 2 万 Token当规模扩展到 108 个智能体时仅输入成本按 Opus 定价计算就接近 10 美元。现实中由于**提示词缓存Prompt Caching**的存在实际成本更接近 1 美元——这也正是从单智能体扩展到并行智能体在经济上变得可行的关键。4.1 成本公式你在为探索的宽度付费更值得深思的是 Anthropic 的归因分析在 BrowseComp 类基准上Token 使用量单独解释了约 80% 的性能方差加上工具调用次数和模型选择两项三者合计解释约 95% [citation:11][citation:16]。换言之多智能体的性能提升很大程度上是拿 Token 堆出来的。你支付的不是智能本身而是更大的推理与检索预算用并行上下文降低单路径的路径依赖用多视角投票对抗不确定性。4.2 适用边界综合收益与代价图工程多智能体的典型适用条件是 [citation:11]✅高价值、可并行、信息规模超出单上下文、需要大量工具调用的任务如复杂研究、跨模块审计❌高度串行、依赖密集、必须共享完整上下文的任务协调开销会拖累收益。一个生产级案例颇具说服力某 SaaS 客服系统在 290 万查询/月的规模下多 Agent 方案比单 AgentGPT-5 RAG准确率高不到 2.1%却让月成本从 $22,700 涨到 $47,000且每次查询多等约 5 秒——规模过了拐点多 Agent 反而亏[citation:16]。五、历史的回摆节点能力 vs. 图的拓扑既然图和编排思想早已有之为什么直到最近才被重新重视核心答案可以用一句话概括这也是 LangChain 在相关讨论中的观点改变的不是图而是节点的能力。5.1 早期节点只是一次 LLM 调用时间线大致如下2023 年Microsoft 开源AutoGen提出以多智能体对话作为编排原语 [citation:3][citation:23]LangChain 等开始探索循环图后发展为LangGraph[citation:2]。当时的节点本质上只是一次 LLM 调用 简单 prompt远不是今天具备完整工具链和运行时环境的智能体。5.2 中期单智能体叙事占据主流随着Cursor、Cline、Roo、Windsurf等编程智能体涌现行业重心转向如何把单个智能体做得更强——从提示词工程Prompt Engineering演进到上下文工程Context Engineering配合更好的运行支撑。图的叙事一度退居幕后。5.3 现在瓶颈从节点回到边当节点本身变得足够可靠、能力足够强拥有大量工具、独立运行时、长上下文瓶颈便从单个节点能做什么转移到了图本身以及连接节点的边如何拆分任务拓扑设计如何路由条件边如何汇合与消解冲突聚合节点这正是历史绕回图的真正原因——节点能力达标后图的拓扑才终于值得被精心设计。六、五种核心编排模式Anthropic 总结Anthropic 在 2024 年底系统梳理的五种工作流模式至今仍是设计图拓扑的主流范式 [citation:5][citation:10][citation:15][citation:20]。它们可以组合使用6.1 Prompt Chaining提示链结构线性 DAG前一步输出作为下一步输入。适用步骤固定、相互依赖提纲 → 审核 → 成文。代价增加延迟。6.2 Routing路由结构分类器 多分支。适用意图明确可分客服分流退款 / 技术支持 / 售前。技巧简单问题路由到低成本小模型复杂问题路由到高性能模型有效控制成本。6.3 Parallelization并行化结构扇出 汇聚。两种变体Sectioning独立子任务并行处理Voting同一任务多次求解后投票/聚合。本质用更多算力换更高置信度。6.4 Orchestrator-Workers编排器-工作者结构中央编排节点 动态派发的 worker。适用无法预先确定子任务的复杂场景代码修改、多源检索——这也是 Claude Code 深度研究所采用的模式。地位被普遍视为多 Agent 系统最合理的起点 [citation:10]。6.5 Evaluator-Optimizer评估者-优化器结构生成器 ↔ 评估器形成循环有环图。适用质量优先于速度、单次执行难保证可靠性写作、代码修复。前提评价标准相对明确且迭代能带来可衡量的提升。七、动手实践用 LangGraph 表达一张 DAG理论落地需要框架。以LangGraph为例它的核心抽象恰好对应图论三要素 [citation:2][citation:7][citation:12][citation:17]Node节点一个 Python 函数接收State执行操作调 LLM / 调工具 / 转换数据返回状态更新Edge边分无条件边固定流转与条件边按State路由State状态全局唯一的类型化数据结构通常用TypedDict或 Pydantic 定义贯穿整个图是唯一可信数据源。下面是一个最小可运行的 DAG 示例模拟检索 → 投票核验 → 生成的三阶段流水线fromtypingimportTypedDict,Annotatedfromlanggraph.graphimportStateGraph,ENDclassAgentState(TypedDict):query:strevidences:list# 各并行 worker 的检索结果votes:list# 核验投票结果answer:strdefretrieve(state:AgentState)-dict:# 实际场景并行调用 3 个子 agent 搜集证据return{evidences:[来源A,来源B,来源C]}defverify(state:AgentState)-dict:# 事实核验 投票简化逻辑return{votes:[1,1,0]}defshould_retry(state:AgentState)-str:# 条件边多数通过则生成否则重试检索returngenerateifsum(state[votes])2elseretrievedefgenerate(state:AgentState)-dict:return{answer:f基于{sum(state[votes])}/{len(state[votes])}票通过的结论}builderStateGraph(AgentState)builder.add_node(retrieve,retrieve)builder.add_node(verify,verify)builder.add_node(generate,generate)builder.set_entry_point(retrieve)builder.add_edge(retrieve,verify)builder.add_conditional_edges(verify,should_retry,{generate:generate,retrieve:retrieve})builder.add_edge(generate,END)graphbuilder.compile()7.1 关键设计要点DAG vs 有环图上例verify的should_retry在不通过时会回到retrieve因此它是有环图若去掉重试分支就是纯 DAG。LangGraph 的编译期会做结构校验如检测孤立节点、循环依赖[citation:2]。状态即真相源所有节点读写同一个State这天然适配 DAG 的拓扑——某节点完成时才解锁下游。Checkpoint检查点机制LangGraph 在每步后持久化状态支持中断/恢复、人工审批HITL这对长周期、需容错的生产级 Agent 至关重要 [citation:7]。可观测性每一步的State快照都可追溯便于调试——这是把编排逻辑显式化的直接红利。八、形式化视角一张图到底定义了什么把前面的例子抽象一个智能体编排图可形式化为G(V,E,S,δ)G (V, E, S, \delta)G(V,E,S,δ)VVV节点集合每个节点 一个智能体 / 一个函数E⊆V×VE \subseteq V \times VE⊆V×V有向边集合控制/数据流向SSS全局状态空间δ:V×S→S\delta: V \times S \to Sδ:V×S→S状态转移函数对应节点执行 边路由。在此基础上可以定义工程属性属性含义工程价值Acyclic无环不存在循环依赖可拓扑排序、可并行调度、易推理Cyclic有环存在回边支持重试、迭代、自我修正Parallel fan-out一度节点发散并行加速Join / Barrier多入边汇聚需同步与冲突消解Conditional edge运行时路由动态拓扑值得注意的是Claude Code 的深度研究工作流是 DAG无环而评估-优化这类需要反复迭代的模式天然要求有环图。用哪一种取决于任务是否需要回到过去。九、横向对比DAG 与有环图的取舍维度DAG有向无环图有环图Cyclic Graph代表场景流水线、并行检索、深度研究工具调用循环、代码修复、迭代优化可预测性高可静态分析、拓扑排序较低循环次数由运行时决定终止性天然终止需显式终止条件最大轮次 / 达标判定实现框架任意工作流引擎LangGraph 等有状态图框架 [citation:12]调试难度低中高需检查点 状态快照实践建议默认从 DAG 起步只有当确实需要重试/迭代时才引入环——环会显著增加调试、成本控制和死循环防护的复杂度。十、总结与思考清单回到开篇的柯尼斯堡问题Euler 的贡献不在于走不通而在于用图的结构揭示了问题的本质。今天的图工程如出一辙——真正的难题不是哪个模型更强而是如何把任务拆成节点、用边设计正确的依赖与反馈。关键结论图工程 用图表达智能体工作流DAG 是最常见、最易落地的形态需要迭代时引入有环图。核心收益是并行 关注点分离代价是 Token、延迟与协调开销的显著上升。成本不是免费的15 倍 Token、80% 性能方差由 Token 解释 [citation:11]采用前必须算清经济账与规模拐点。历史回摆的本质节点能力达标后瓶颈从节点能做什么转移到图的拓扑与边。落地前的 5 个问题Checklist在你决定上多 Agent之前建议逐项回答任务是否真正可并行上下文能否隔离否则交接损耗 并行收益任务是否高价值单次任务价值能否覆盖 15× Token 成本是否需要迭代/重试需要 → 有环图 终止条件不需要 → 优先 DAG。是否存在共享状态如何聚合多智能体的冲突结论投票 / 加权平均 / 编排器裁决是否具备可观测性能否追踪每个节点的 Token、时延、成本、终止原因参考资料Anthropic,How we built our multi-agent research system—— 披露 90.2% 性能提升、15× Token 成本及归因分析 [citation:1][citation:6][citation:11]LangGraph 官方文档 —— 状态图、节点/边/状态、Checkpoint 机制 [citation:2][citation:7][citation:12]Microsoft Research,AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation(2023) [citation:23]Anthropic 工作流模式总结 —— Prompt Chaining / Routing / Parallelization / Orchestrator-Workers / Evaluator-Optimizer [citation:5][citation:10][citation:20]柯尼斯堡七桥问题与欧拉的证明图论起源 从柯尼斯堡七桥到多智能体编排：图工程的技术原理、收益与代价
从柯尼斯堡七桥到多智能体编排图工程的技术原理、收益与代价摘要图工程Graph Engineering“最近被频繁提及被视为智能体工程演进的下一步”。但图本身并不新鲜——它诞生于 1736 年欧拉对柯尼斯堡七桥问题的证明。本文从这条历史线索出发结合 Claude Code 的深度研究工作流系统拆解图工程的形式化定义、多智能体编排的五种模式、节点能力进化史以及它真实的成本代价。结论先行图工程不是更聪明的 AI而是一种用并行上下文和协调开销换取广度与可靠性的工程范式是否采用应由任务结构决定。一、从一个具体场景切入Claude Code 的深度研究工作流先抛开概念看一个真实例子。当你在 Claude Code 中发起一次深度研究Deep Research时背后并非由单个智能体独立完成全部研究而是由系统在运行时动态生成一套工作流——这套工作流本身就是一段可执行的 JavaScript 代码会启动超过 100 个智能体分阶段协作。一个典型的工作流可以被抽象为五个阶段阶段智能体数量职责1. 需求界定1明确研究目标与边界2. 主题拆解 信源搜集5为每个子主题寻找可信网站3. 信息获取25抓取并传递原始信息4. 事实核验 可信度投票75交叉验证、对可信度投票5. 报告生成1汇总产出完整报告几个值得注意的工程细节工作流是动态生成的每次新请求都会产出一套全新的工作流智能体数量也随任务规模变化。阶段间大致并行同一阶段内的智能体可同时工作每个智能体拥有独立的上下文窗口和系统提示词。计划被搬进了代码编排逻辑循环、分支、中间变量由脚本持有主会话只保留最终答案实现上下文隔离。这正是本文要讨论的核心对象当任务的执行结构是一张图时我们用图来表达它、编排它、调度它——这就是图工程。二、图的起源柯尼斯堡七桥与欧拉的证明要理解图工程先从图论的源头说起。1736 年瑞士博学家Leonhard Euler思考了一个看似与生活相关的问题柯尼斯堡城有两块大陆、两座岛屿由七座桥连接。是否存在一条穿过城市的路线恰好各经过每座桥一次通过穷举尝试从大陆出发从岛出发换一种过桥顺序你会发现这是不可能的。Euler 也得出了同样结论但真正有价值的不是无解这个结果而是他如何把问题化简节点Node用圆圈表示代表陆地边Edge用黑线表示代表桥梁图Graph节点与边的集合。中间那座岛有 5 条边5 座桥连接到其他区域。基于这种表示Euler 严格证明了这样的路线不存在。关键启示欧拉的工作把地理/物理问题转换成了结构/拓扑问题。今天的多智能体编排做的事情在方法论上完全一致——我们不再问哪个模型更聪明而是问任务应该如何被拆成节点、节点之间如何连接。2.1 为什么深度研究工作流是一张图把上面五个阶段画出来它显然是一张图[需求界定] → [主题拆解] → [信息获取] → [事实核验] → [报告生成]由于执行只从左向右流动没有任何节点回指前面形成循环这张图有一个专门的名字——DAG有向无环图Directed Acyclic Graph。DAG 是图工程中最常见、也最容易落地的结构有向边有明确方向代表数据/控制的流向无环不存在循环依赖因此可以拓扑排序、可以并行调度、可以安全地失败重试。补充一点并非所有智能体图都是 DAG。以 LangGraph 为代表的编排框架明确支持有环图用于表达重试失败的工具调用“重新审题”迭代优化输出这类需要回到前序节点的行为 [citation:2][citation:7]。DAG 与有环图的区别本质上是一次性流水线与可迭代状态机的区别我们在第四节展开。三、为什么要多智能体——并行与关注点分离从原理上说我们当然可以让单个智能体完成上述所有工作。之所以采用图有两个工程层面的核心理由。3.1 收益一并行节省时间把任务并行拆给目标更小的子智能体可以让多个智能体同时工作。对于广度优先探索类任务多源检索、多维度评审、交叉验证串行单智能体的耗时是各子任务之和而理想并行的耗时趋近于最慢的那个子任务。3.2 收益二关注点分离Separation of Concerns每个智能体拥有自己的上下文窗口可以把上下文专注于自身目标一个智能体只负责搜集可信网站它的 prompt 和上下文都很干净另一个只负责事实核验与投票不需要记得前面怎么搜的。反过来若由单个智能体承担同一个上下文窗口要反复复用一部分保存总体目标、一部分服务当前子任务、还要不断总结压缩。上下文污染Context Pollution和长程遗忘随之而来。3.3 收益的边界何时不该拆“能并行不等于该并行”。业界实践给出的判断标准是——仅当上下文可真正隔离时才拆分。如果把本应连贯的子任务如实现功能与写测试强行分给两个智能体产生的**交接损耗handoff cost**可能高于并行带来的收益 [citation:10]。这是图工程最容易被忽视的反面。四、图也有代价15 倍 Token 背后的成本真相图工程并非免费午餐。Anthropic 在介绍其多智能体研究系统的文章中披露过一组硬数字 [citation:1][citation:6][citation:11]对比对象Token 用量相对普通聊天单智能体Agent约4 倍多智能体系统约15 倍回到我们的例子做一笔直观的账每个智能体运行在 Opus 级别模型上拥有独立系统提示词启动时约消耗 2 万 Token当规模扩展到 108 个智能体时仅输入成本按 Opus 定价计算就接近 10 美元。现实中由于**提示词缓存Prompt Caching**的存在实际成本更接近 1 美元——这也正是从单智能体扩展到并行智能体在经济上变得可行的关键。4.1 成本公式你在为探索的宽度付费更值得深思的是 Anthropic 的归因分析在 BrowseComp 类基准上Token 使用量单独解释了约 80% 的性能方差加上工具调用次数和模型选择两项三者合计解释约 95% [citation:11][citation:16]。换言之多智能体的性能提升很大程度上是拿 Token 堆出来的。你支付的不是智能本身而是更大的推理与检索预算用并行上下文降低单路径的路径依赖用多视角投票对抗不确定性。4.2 适用边界综合收益与代价图工程多智能体的典型适用条件是 [citation:11]✅高价值、可并行、信息规模超出单上下文、需要大量工具调用的任务如复杂研究、跨模块审计❌高度串行、依赖密集、必须共享完整上下文的任务协调开销会拖累收益。一个生产级案例颇具说服力某 SaaS 客服系统在 290 万查询/月的规模下多 Agent 方案比单 AgentGPT-5 RAG准确率高不到 2.1%却让月成本从 $22,700 涨到 $47,000且每次查询多等约 5 秒——规模过了拐点多 Agent 反而亏[citation:16]。五、历史的回摆节点能力 vs. 图的拓扑既然图和编排思想早已有之为什么直到最近才被重新重视核心答案可以用一句话概括这也是 LangChain 在相关讨论中的观点改变的不是图而是节点的能力。5.1 早期节点只是一次 LLM 调用时间线大致如下2023 年Microsoft 开源AutoGen提出以多智能体对话作为编排原语 [citation:3][citation:23]LangChain 等开始探索循环图后发展为LangGraph[citation:2]。当时的节点本质上只是一次 LLM 调用 简单 prompt远不是今天具备完整工具链和运行时环境的智能体。5.2 中期单智能体叙事占据主流随着Cursor、Cline、Roo、Windsurf等编程智能体涌现行业重心转向如何把单个智能体做得更强——从提示词工程Prompt Engineering演进到上下文工程Context Engineering配合更好的运行支撑。图的叙事一度退居幕后。5.3 现在瓶颈从节点回到边当节点本身变得足够可靠、能力足够强拥有大量工具、独立运行时、长上下文瓶颈便从单个节点能做什么转移到了图本身以及连接节点的边如何拆分任务拓扑设计如何路由条件边如何汇合与消解冲突聚合节点这正是历史绕回图的真正原因——节点能力达标后图的拓扑才终于值得被精心设计。六、五种核心编排模式Anthropic 总结Anthropic 在 2024 年底系统梳理的五种工作流模式至今仍是设计图拓扑的主流范式 [citation:5][citation:10][citation:15][citation:20]。它们可以组合使用6.1 Prompt Chaining提示链结构线性 DAG前一步输出作为下一步输入。适用步骤固定、相互依赖提纲 → 审核 → 成文。代价增加延迟。6.2 Routing路由结构分类器 多分支。适用意图明确可分客服分流退款 / 技术支持 / 售前。技巧简单问题路由到低成本小模型复杂问题路由到高性能模型有效控制成本。6.3 Parallelization并行化结构扇出 汇聚。两种变体Sectioning独立子任务并行处理Voting同一任务多次求解后投票/聚合。本质用更多算力换更高置信度。6.4 Orchestrator-Workers编排器-工作者结构中央编排节点 动态派发的 worker。适用无法预先确定子任务的复杂场景代码修改、多源检索——这也是 Claude Code 深度研究所采用的模式。地位被普遍视为多 Agent 系统最合理的起点 [citation:10]。6.5 Evaluator-Optimizer评估者-优化器结构生成器 ↔ 评估器形成循环有环图。适用质量优先于速度、单次执行难保证可靠性写作、代码修复。前提评价标准相对明确且迭代能带来可衡量的提升。七、动手实践用 LangGraph 表达一张 DAG理论落地需要框架。以LangGraph为例它的核心抽象恰好对应图论三要素 [citation:2][citation:7][citation:12][citation:17]Node节点一个 Python 函数接收State执行操作调 LLM / 调工具 / 转换数据返回状态更新Edge边分无条件边固定流转与条件边按State路由State状态全局唯一的类型化数据结构通常用TypedDict或 Pydantic 定义贯穿整个图是唯一可信数据源。下面是一个最小可运行的 DAG 示例模拟检索 → 投票核验 → 生成的三阶段流水线fromtypingimportTypedDict,Annotatedfromlanggraph.graphimportStateGraph,ENDclassAgentState(TypedDict):query:strevidences:list# 各并行 worker 的检索结果votes:list# 核验投票结果answer:strdefretrieve(state:AgentState)-dict:# 实际场景并行调用 3 个子 agent 搜集证据return{evidences:[来源A,来源B,来源C]}defverify(state:AgentState)-dict:# 事实核验 投票简化逻辑return{votes:[1,1,0]}defshould_retry(state:AgentState)-str:# 条件边多数通过则生成否则重试检索returngenerateifsum(state[votes])2elseretrievedefgenerate(state:AgentState)-dict:return{answer:f基于{sum(state[votes])}/{len(state[votes])}票通过的结论}builderStateGraph(AgentState)builder.add_node(retrieve,retrieve)builder.add_node(verify,verify)builder.add_node(generate,generate)builder.set_entry_point(retrieve)builder.add_edge(retrieve,verify)builder.add_conditional_edges(verify,should_retry,{generate:generate,retrieve:retrieve})builder.add_edge(generate,END)graphbuilder.compile()7.1 关键设计要点DAG vs 有环图上例verify的should_retry在不通过时会回到retrieve因此它是有环图若去掉重试分支就是纯 DAG。LangGraph 的编译期会做结构校验如检测孤立节点、循环依赖[citation:2]。状态即真相源所有节点读写同一个State这天然适配 DAG 的拓扑——某节点完成时才解锁下游。Checkpoint检查点机制LangGraph 在每步后持久化状态支持中断/恢复、人工审批HITL这对长周期、需容错的生产级 Agent 至关重要 [citation:7]。可观测性每一步的State快照都可追溯便于调试——这是把编排逻辑显式化的直接红利。八、形式化视角一张图到底定义了什么把前面的例子抽象一个智能体编排图可形式化为G(V,E,S,δ)G (V, E, S, \delta)G(V,E,S,δ)VVV节点集合每个节点 一个智能体 / 一个函数E⊆V×VE \subseteq V \times VE⊆V×V有向边集合控制/数据流向SSS全局状态空间δ:V×S→S\delta: V \times S \to Sδ:V×S→S状态转移函数对应节点执行 边路由。在此基础上可以定义工程属性属性含义工程价值Acyclic无环不存在循环依赖可拓扑排序、可并行调度、易推理Cyclic有环存在回边支持重试、迭代、自我修正Parallel fan-out一度节点发散并行加速Join / Barrier多入边汇聚需同步与冲突消解Conditional edge运行时路由动态拓扑值得注意的是Claude Code 的深度研究工作流是 DAG无环而评估-优化这类需要反复迭代的模式天然要求有环图。用哪一种取决于任务是否需要回到过去。九、横向对比DAG 与有环图的取舍维度DAG有向无环图有环图Cyclic Graph代表场景流水线、并行检索、深度研究工具调用循环、代码修复、迭代优化可预测性高可静态分析、拓扑排序较低循环次数由运行时决定终止性天然终止需显式终止条件最大轮次 / 达标判定实现框架任意工作流引擎LangGraph 等有状态图框架 [citation:12]调试难度低中高需检查点 状态快照实践建议默认从 DAG 起步只有当确实需要重试/迭代时才引入环——环会显著增加调试、成本控制和死循环防护的复杂度。十、总结与思考清单回到开篇的柯尼斯堡问题Euler 的贡献不在于走不通而在于用图的结构揭示了问题的本质。今天的图工程如出一辙——真正的难题不是哪个模型更强而是如何把任务拆成节点、用边设计正确的依赖与反馈。关键结论图工程 用图表达智能体工作流DAG 是最常见、最易落地的形态需要迭代时引入有环图。核心收益是并行 关注点分离代价是 Token、延迟与协调开销的显著上升。成本不是免费的15 倍 Token、80% 性能方差由 Token 解释 [citation:11]采用前必须算清经济账与规模拐点。历史回摆的本质节点能力达标后瓶颈从节点能做什么转移到图的拓扑与边。落地前的 5 个问题Checklist在你决定上多 Agent之前建议逐项回答任务是否真正可并行上下文能否隔离否则交接损耗 并行收益任务是否高价值单次任务价值能否覆盖 15× Token 成本是否需要迭代/重试需要 → 有环图 终止条件不需要 → 优先 DAG。是否存在共享状态如何聚合多智能体的冲突结论投票 / 加权平均 / 编排器裁决是否具备可观测性能否追踪每个节点的 Token、时延、成本、终止原因参考资料Anthropic,How we built our multi-agent research system—— 披露 90.2% 性能提升、15× Token 成本及归因分析 [citation:1][citation:6][citation:11]LangGraph 官方文档 —— 状态图、节点/边/状态、Checkpoint 机制 [citation:2][citation:7][citation:12]Microsoft Research,AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation(2023) [citation:23]Anthropic 工作流模式总结 —— Prompt Chaining / Routing / Parallelization / Orchestrator-Workers / Evaluator-Optimizer [citation:5][citation:10][citation:20]柯尼斯堡七桥问题与欧拉的证明图论起源