OpenClaw 创建者 Peter Steinberger 在网上发了一句Are we still talking loops, or did we shift to graphs yet?大家还在聊 Loop还是已经转向 Graph 了一句话戳中了很多人的焦虑Agent 领域新词来得太快前一个还没用踏实后一个已经成了新热点。但真把 Agent 放进研发流程事情反而没有那么玄。Prompt 管什么、Context 管什么、Harness 管什么、Loop 管什么、Graph 管什么 —— 它们各管一段边界不是越外层越高级也不是谁替代谁。一、先回顾Agent 工程的五层进化先把之前的脉络拉通看看 Graph 处在什么位置。关键认知外层建立在内层之上但不能互相顶替。Prompt 写得再细也解决不了旧事实的问题模型再聪明也替代不了幂等键、检查点和发布审批。系统不稳时别急着换模型也别急着上 Graph。先按症状往回找 ——总是误解目标 → 查 Prompt引用旧版本 → 查 Context权限失控 → 查 Harness反复绕路 → 查 Loop一协作就乱 → 查 Graph很多被归为 模型能力不行 的问题最后都是某个具体的工程缺口。一句话理解进化逻辑Prompt 解决一次调用怎么说清楚Loop 解决一个 Agent 怎么持续干Graph 解决多个 Agent 怎么配合干Loop 是一个人埋头苦干Graph 是一个团队分工协作。二、Loop vs Graph本质区别是什么很多人以为 Graph 就是更复杂的 Loop其实完全不是一个维度的东西。真实运行时五层是反复嵌套的Graph整张工作流图 └── 节点 A修复 bug └── Loop修→测→再修的循环 ├── Context当前代码、报错日志 ├── Harness读文件、跑测试的权限 └── Prompt每一轮的具体指令Loop单线程循环一条路走到黑Loop 的结构很简单一个 Agent一个循环从头干到尾。目标 → 规划 → 执行 → 检查 → 修复 → 再执行 → ... → 完成就像一个全能型选手什么都自己来遇到问题自己改干成了为止。优点简单、直接、上手快缺点任务复杂了容易迷路上下文越跑越脏没法并行再急的活也得一步步来出了问题得从头排查不知道哪步跑偏的Graph图状结构分而治之Graph 的核心是节点 边节点Node每个节点只干一件明确的事一进一出边Edge节点之间的依赖关系规定谁先谁后、谁依赖谁┌─ 代码编写 ─┐ 需求拆解 ─┼─ 测试编写 ─┼─ 代码审查 ── 交付 └─ 文档编写 ─┘看到没中间三个节点是并行的写完需求拆解后写代码、写测试、写文档可以同时开工最后汇总到审查节点。Graph 的三大核心能力能力说明Loop 能做到吗分支Branching根据条件走不同路径❌ 只能线性循环并行Parallelism多个节点同时干活❌ 只能串行聚合Aggregation多个节点结果合并❌ 单一输出用团队来类比最形象Loop 一个独立开发者需求、开发、测试、上线全自己干Graph 一个项目组有产品、开发、测试、运维分工明确并行推进三、Graph 的核心三要素节点、边、状态所有 Graph 框架LangGraph、Dify 工作流等底层都是这三个概念。1. 节点Node只做一件事每个节点是一个独立的执行单元职责单一。常见节点类型Agent 节点某个专业角色的 AI比如 前端开发 Agent、测试 Agent工具节点执行特定操作比如 查数据库、调 API人工节点需要人确认的卡点比如 发布审批条件节点做判断路由比如 测试通过了吗通过→下一步不通过→回退设计原则一个节点只干一件事。不要搞万能节点那不叫 Graph叫大号 Loop。2. 边Edge定义流转关系边决定了数据怎么在节点之间流。三种常见的边类型说明示例顺序边干完 A 干 B最简单需求 → 开发条件边根据状态决定去哪测试通过→ 交付 / 不通过 → 修复扇入 / 扇出一个拆多个多个汇一个需求拆解 → 三个开发并行 → 汇总审查3. 状态State全局共享记忆整个图运行过程中所有节点共享一个状态对象。State 就是整个团队的共享白板每个人干完自己的活就往上写别人接着用。四、双图架构生产级多 Agent 系统的标准姿势真正企业级用的 Graph不是一张图而是两张图配合。第一张组织图Organization Graph长期稳定存在相当于公司的组织架构。# 典型的 State 结构 class ProjectState(TypedDict): requirement: str # 原始需求 design_doc: str # 设计文档 code: dict # 各模块代码 test_result: dict # 测试结果 review_comments: list # 审查意见 status: str # 当前状态CEO Agent ├── 产品部 Agent ├── 技术部 Agent │ ├── 前端组 Agent │ ├── 后端组 Agent │ └── 测试组 Agent └── 运维部 Agent每个节点对应一个固定角色/部门有自己的专属上下文、权限、工具集相对稳定不会天天变第二张工作图Workflow Graph每次任务动态生成相当于临时项目组。比如接到一个新需求临时拉一张图需求分析产品 → 技术方案架构师 → 并行开发前端后端 → 联调测试测试 → 上线运维任务开始时生成任务结束就销毁从组织图里借人组成临时团队根据任务复杂度动态调整结构为什么要两张图一张管人一张管事。组织图解决谁有什么能力、什么权限的问题工作图解决这个任务怎么分工、怎么流转的问题就像真实的公司部门是固定的项目组是临时的项目从各部门抽人组成。五、上手实战LangGraph 搭一个简单的多 Agent 系统说太多概念不如看代码。以 LangGraph 为例搭一个最简单的需求→开发→测试三节点工作流。第一步定义状态from typing import TypedDict, Annotated from langgraph.graph import StateGraph, END # 定义共享状态 class DevState(TypedDict): requirement: str code: str test_result: str passed: bool第二步定义节点def developer_node(state: DevState): ”””开发节点根据需求写代码””” requirement state[”requirement”] # 调用大模型生成代码 code generate_code(requirement) return {”code”: code} def tester_node(state: DevState): ”””测试节点写测试并运行””” code state[”code”] # 生成测试用例并运行 test_result, passed run_tests(code) return {”test_result”: test_result, ”passed”: passed} def fix_node(state: DevState): ”””修复节点测试不通过就修””” code state[”code”] test_result state[”test_result”] # 根据报错修复代码 fixed_code fix_bug(code, test_result) return {”code”: fixed_code}第三步定义路由逻辑def test_router(state: DevState): ”””条件路由测试通过就结束不通过就去修复””” if state[”passed”]: return END else: return ”fix”第四步建图并运行# 构建图 workflow StateGraph(DevState) # 添加节点 workflow.add_node(”developer”, developer_node) workflow.add_node(”tester”, tester_node) workflow.add_node(”fix”, fix_node) # 设置入口 workflow.set_entry_point(”developer”) # 连边 workflow.add_edge(”developer”, ”tester”) workflow.add_conditional_edges(”tester”, test_router) workflow.add_edge(”fix”, ”tester”) # 修完回去再测 # 编译运行 app workflow.compile() result app.invoke({”requirement”: ”写一个用户登录接口”})执行路径developer → tester → 检查不通过 → fix → tester → 检查通过 → 结束二十几行代码一个带自动修复循环的开发工作流就搭好了。这就是 Graph 的威力结构清晰可观测可控制。一个完整例子import os from dotenv import load_dotenv from typing import TypedDict, Literal import dashscope from dashscope import Generation from langgraph.graph import StateGraph, END from langgraph.checkpoint.memory import MemorySaver # 加载阿里云密钥环境变量 load_dotenv() dashscope.api_key os.getenv(DASHSCOPE_API_KEY) # 第二层 Context全局统一上下文状态存储 class BugFixState(TypedDict): user_requirement: str prompt_rules: str source_code: str error_log: str fixed_code: str test_result: str current_stage: Literal[code_write, test_check, bug_fix] loop_retry_count: int max_retry: int # 通用调用千问封装函数 def call_qwen(prompt: str) - str: response Generation.call( modelqwen-turbo, promptprompt, result_formattext, temperature0.2, max_tokens1800, timeout35 ) if response.status_code 200: return response.output.text.strip() else: raise Exception(f大模型调用失败{response.code} {response.message}) # 节点1编写初始业务代码第一层 Prompt 约束落地 def code_write_node(state: BugFixState) - dict: prompt_content ( 【强制编写规则】\n f{state[prompt_rules]}\n\n 开发需求\n f{state[user_requirement]}\n\n 硬性要求只输出完整Python代码不要任何解释、开场白、多余话术。 ) code_result call_qwen(prompt_content) return { source_code: code_result, current_stage: test_check, loop_retry_count: 0 } # 节点2代码测试校验 def test_check_node(state: BugFixState) - dict: test_prompt ( f参照编码规则{state[prompt_rules]}\n 待检测Python代码\npython\n f{state[source_code]}\n \n 校验要求仅核查核心3项功能\n 1. user_id 参数非空 长度合法性校验\n 2. 全局异常捕获 try-except\n 3. 返回标准化JSON格式结果\n 冗余内部校验、细微逻辑瑕疵无需挑错。\n 输出格式严格遵守\n 1. 核心功能缺失开头固定写【FAIL】 简短问题描述\n 2. 全部核心需求满足只输出大写【PASS】三个字符 ) test_res call_qwen(test_prompt) return { test_result: test_res, error_log: test_res, current_stage: bug_fix } # 节点3Bug修复节点第四层 Loop 循环载体 def bug_fix_loop_node(state: BugFixState) - dict: new_retry_num state[loop_retry_count] 1 fix_prompt ( f编码约束{state[prompt_rules]}\n 原有错误代码\npython\n f{state[source_code]}\n \n f缺陷详情{state[error_log]}\n 重要要求一次性修复全部列出问题不要遗留任何缺陷输出完整最终Python代码无多余文字说明。 ) fixed_code call_qwen(fix_prompt) return { fixed_code: fixed_code, source_code: fixed_code, loop_retry_count: new_retry_num, current_stage: test_check } # 路由控制器控制Loop启停、分支流转 def route_control(state: BugFixState) - Literal[bug_fix_loop_node, END]: test_text state[test_result] current_retry state[loop_retry_count] max_limit state[max_retry] if PASS in test_text: print(✅ 校验全部通过代码修复完成Graph流程结束) return END elif current_retry max_limit: print(f❌ 已到达最大循环次数{max_limit}多次修复未能达标任务终止) return END else: print(f 检测存在功能缺陷开启第 {current_retry1} 轮修复循环) return bug_fix_loop_node # 第五层 Graph搭建整体有向工作流图 def build_graph_workflow(): graph StateGraph(BugFixState) # 注册所有业务节点 graph.add_node(code_write_node, code_write_node) graph.add_node(test_check_node, test_check_node) graph.add_node(bug_fix_loop_node, bug_fix_loop_node) # 设置流程入口 graph.set_entry_point(code_write_node) # 顺序流转写代码 → 测试校验 graph.add_edge(code_write_node, test_check_node) # 条件分支测试结果决定继续修复还是结束 graph.add_conditional_edges( sourcetest_check_node, pathroute_control, path_map{ bug_fix_loop_node: bug_fix_loop_node, END: END } ) # 修复完毕回流测试节点形成闭环循环 graph.add_edge(bug_fix_loop_node, test_check_node) # 编译流程图开启断点记忆流程中断可恢复 compiled_graph graph.compile(checkpointerMemorySaver()) return compiled_graph # 程序入口执行 if __name__ __main__: workflow build_graph_workflow() # 初始化入参配置 initial_input { user_requirement: 编写用户余额查询函数接收user_id参数校验用户ID合法性捕获所有运行异常返回标准化提示, prompt_rules: ( Prompt约束规范\n 1. 必须校验user_id非空、字符长度1~32位\n 2. 所有运行异常统一用try except捕获\n 3. 返回codemsg结构化字典数据\n 4. 代码简洁禁止多余注释 ), max_retry: 5, # 最大循环修复5次 loop_retry_count: 0 } # 会话ID用于断点续跑同一个任务 session_config {configurable: {thread_id: qwen_bugfix_final_demo}} final_output workflow.invoke(initial_input, configsession_config) # 打印最终汇总结果 print(\n 最终运行结果汇总 ) print(f最终成品代码\n{final_output[source_code]}) print(f\n最终测试结论{final_output[test_result]}) print(f累计循环修复次数{final_output[loop_retry_count]})安装依赖pip install langgraph python-dotenv dashscope六、什么时候该上 Graph很多人一上来就想搞多 Agent 协作平台结果搞了半年发现还不如一个 Loop 好用。我的建议先判断你的任务类型再选架构。适合用 Loop 的场景80% 的日常任务✅ 单一角色就能搞定的事✅ 流程线性不需要并行✅ 任务复杂度中等上下文不会爆✅ 快速验证、个人提效比如写个功能、修个 bug、整理份文档必须上 Graph 的场景✅ 需要多个专业角色配合✅ 有并行环节能显著提速✅ 流程复杂需要清晰的节点和卡点✅ 企业级生产环境要求可观测、可追溯比如完整的需求交付、复杂故障排查、跨部门业务流程选型判断表维度选 Loop选 Graph参与角色1 个3 个以上任务时长几分钟到几小时几小时到几天并行需求不需要有明显可并行环节可观测性要求低高需要知道每步状态团队规模个人 / 小团队企业级上手成本低高原则能 Loop 解决的就别上 Graph。Graph 不是高级版 Loop它是另一个维度的复杂度带来能力的同时也带来维护成本。七、避坑指南Graph 不是银弹最后泼点冷水Graph 很好但不是万能的。坑一为了 Graph 而 Graph很多团队任务明明一个 Loop 就能搞定非要拆成七八个节点美其名曰模块化结果效率反而更低排查问题更麻烦。记住架构是为业务服务的不是反过来。坑二节点拆得太碎每个节点只干一丢丢事一张图画了几十个节点看着很专业实际全是 overhead。经验法则一个节点至少要能独立交付一个小成果别搞第一步读文件、第二步解析内容这种粒度。坑三状态设计混乱State 什么都往里塞最后变成大杂烩每个节点都改出了问题根本不知道谁改坏的。建议状态分层设计每个节点只写自己负责的字段加权限标注。坑四忽略人工节点很多人设计 Graph 全是自动节点想着全自动化。实际生产环境里关键卡点必须有人工审核。高风险操作删数据、上线、发钱必须有人工确认节点这是底线。从 Prompt 到 Loop 到 Graph你会发现一条很有意思的线Prompt 时代我们研究怎么跟一个 AI 说话Loop 时代我们研究怎么让一个 AI 持续干活Graph 时代我们研究怎么让一群 AI 配合干活AI Agent 的进化本质上是在复刻人类社会组织的进化路径。从个体劳动到流水线作业到团队协作到组织化生产。未来还会有什么可能是 Graph of Graphs——大图套小图子图递归调用就像公司里有总公司、分公司、部门、小组。但不管架构怎么变有一点不会变人永远是最终的决策者和责任人。AI 的组织再复杂它也只是工具。定义目标、设计流程、把控质量、承担后果——这些事最终还是人的。喜欢动手的朋友赶紧试试吧高国生成式 —— 用 AI 兜底做人游刃有余。
OpenClaw 创建者 Peter Steinberger 在网上发了一句Are we still talking loops, or did we shift to graphs yet?大家还在聊 Loop还是已经转向 Graph 了一句话戳中了很多人的焦虑Agent 领域新词来得太快前一个还没用踏实后一个已经成了新热点。但真把 Agent 放进研发流程事情反而没有那么玄。Prompt 管什么、Context 管什么、Harness 管什么、Loop 管什么、Graph 管什么 —— 它们各管一段边界不是越外层越高级也不是谁替代谁。一、先回顾Agent 工程的五层进化先把之前的脉络拉通看看 Graph 处在什么位置。关键认知外层建立在内层之上但不能互相顶替。Prompt 写得再细也解决不了旧事实的问题模型再聪明也替代不了幂等键、检查点和发布审批。系统不稳时别急着换模型也别急着上 Graph。先按症状往回找 ——总是误解目标 → 查 Prompt引用旧版本 → 查 Context权限失控 → 查 Harness反复绕路 → 查 Loop一协作就乱 → 查 Graph很多被归为 模型能力不行 的问题最后都是某个具体的工程缺口。一句话理解进化逻辑Prompt 解决一次调用怎么说清楚Loop 解决一个 Agent 怎么持续干Graph 解决多个 Agent 怎么配合干Loop 是一个人埋头苦干Graph 是一个团队分工协作。二、Loop vs Graph本质区别是什么很多人以为 Graph 就是更复杂的 Loop其实完全不是一个维度的东西。真实运行时五层是反复嵌套的Graph整张工作流图 └── 节点 A修复 bug └── Loop修→测→再修的循环 ├── Context当前代码、报错日志 ├── Harness读文件、跑测试的权限 └── Prompt每一轮的具体指令Loop单线程循环一条路走到黑Loop 的结构很简单一个 Agent一个循环从头干到尾。目标 → 规划 → 执行 → 检查 → 修复 → 再执行 → ... → 完成就像一个全能型选手什么都自己来遇到问题自己改干成了为止。优点简单、直接、上手快缺点任务复杂了容易迷路上下文越跑越脏没法并行再急的活也得一步步来出了问题得从头排查不知道哪步跑偏的Graph图状结构分而治之Graph 的核心是节点 边节点Node每个节点只干一件明确的事一进一出边Edge节点之间的依赖关系规定谁先谁后、谁依赖谁┌─ 代码编写 ─┐ 需求拆解 ─┼─ 测试编写 ─┼─ 代码审查 ── 交付 └─ 文档编写 ─┘看到没中间三个节点是并行的写完需求拆解后写代码、写测试、写文档可以同时开工最后汇总到审查节点。Graph 的三大核心能力能力说明Loop 能做到吗分支Branching根据条件走不同路径❌ 只能线性循环并行Parallelism多个节点同时干活❌ 只能串行聚合Aggregation多个节点结果合并❌ 单一输出用团队来类比最形象Loop 一个独立开发者需求、开发、测试、上线全自己干Graph 一个项目组有产品、开发、测试、运维分工明确并行推进三、Graph 的核心三要素节点、边、状态所有 Graph 框架LangGraph、Dify 工作流等底层都是这三个概念。1. 节点Node只做一件事每个节点是一个独立的执行单元职责单一。常见节点类型Agent 节点某个专业角色的 AI比如 前端开发 Agent、测试 Agent工具节点执行特定操作比如 查数据库、调 API人工节点需要人确认的卡点比如 发布审批条件节点做判断路由比如 测试通过了吗通过→下一步不通过→回退设计原则一个节点只干一件事。不要搞万能节点那不叫 Graph叫大号 Loop。2. 边Edge定义流转关系边决定了数据怎么在节点之间流。三种常见的边类型说明示例顺序边干完 A 干 B最简单需求 → 开发条件边根据状态决定去哪测试通过→ 交付 / 不通过 → 修复扇入 / 扇出一个拆多个多个汇一个需求拆解 → 三个开发并行 → 汇总审查3. 状态State全局共享记忆整个图运行过程中所有节点共享一个状态对象。State 就是整个团队的共享白板每个人干完自己的活就往上写别人接着用。四、双图架构生产级多 Agent 系统的标准姿势真正企业级用的 Graph不是一张图而是两张图配合。第一张组织图Organization Graph长期稳定存在相当于公司的组织架构。# 典型的 State 结构 class ProjectState(TypedDict): requirement: str # 原始需求 design_doc: str # 设计文档 code: dict # 各模块代码 test_result: dict # 测试结果 review_comments: list # 审查意见 status: str # 当前状态CEO Agent ├── 产品部 Agent ├── 技术部 Agent │ ├── 前端组 Agent │ ├── 后端组 Agent │ └── 测试组 Agent └── 运维部 Agent每个节点对应一个固定角色/部门有自己的专属上下文、权限、工具集相对稳定不会天天变第二张工作图Workflow Graph每次任务动态生成相当于临时项目组。比如接到一个新需求临时拉一张图需求分析产品 → 技术方案架构师 → 并行开发前端后端 → 联调测试测试 → 上线运维任务开始时生成任务结束就销毁从组织图里借人组成临时团队根据任务复杂度动态调整结构为什么要两张图一张管人一张管事。组织图解决谁有什么能力、什么权限的问题工作图解决这个任务怎么分工、怎么流转的问题就像真实的公司部门是固定的项目组是临时的项目从各部门抽人组成。五、上手实战LangGraph 搭一个简单的多 Agent 系统说太多概念不如看代码。以 LangGraph 为例搭一个最简单的需求→开发→测试三节点工作流。第一步定义状态from typing import TypedDict, Annotated from langgraph.graph import StateGraph, END # 定义共享状态 class DevState(TypedDict): requirement: str code: str test_result: str passed: bool第二步定义节点def developer_node(state: DevState): ”””开发节点根据需求写代码””” requirement state[”requirement”] # 调用大模型生成代码 code generate_code(requirement) return {”code”: code} def tester_node(state: DevState): ”””测试节点写测试并运行””” code state[”code”] # 生成测试用例并运行 test_result, passed run_tests(code) return {”test_result”: test_result, ”passed”: passed} def fix_node(state: DevState): ”””修复节点测试不通过就修””” code state[”code”] test_result state[”test_result”] # 根据报错修复代码 fixed_code fix_bug(code, test_result) return {”code”: fixed_code}第三步定义路由逻辑def test_router(state: DevState): ”””条件路由测试通过就结束不通过就去修复””” if state[”passed”]: return END else: return ”fix”第四步建图并运行# 构建图 workflow StateGraph(DevState) # 添加节点 workflow.add_node(”developer”, developer_node) workflow.add_node(”tester”, tester_node) workflow.add_node(”fix”, fix_node) # 设置入口 workflow.set_entry_point(”developer”) # 连边 workflow.add_edge(”developer”, ”tester”) workflow.add_conditional_edges(”tester”, test_router) workflow.add_edge(”fix”, ”tester”) # 修完回去再测 # 编译运行 app workflow.compile() result app.invoke({”requirement”: ”写一个用户登录接口”})执行路径developer → tester → 检查不通过 → fix → tester → 检查通过 → 结束二十几行代码一个带自动修复循环的开发工作流就搭好了。这就是 Graph 的威力结构清晰可观测可控制。一个完整例子import os from dotenv import load_dotenv from typing import TypedDict, Literal import dashscope from dashscope import Generation from langgraph.graph import StateGraph, END from langgraph.checkpoint.memory import MemorySaver # 加载阿里云密钥环境变量 load_dotenv() dashscope.api_key os.getenv(DASHSCOPE_API_KEY) # 第二层 Context全局统一上下文状态存储 class BugFixState(TypedDict): user_requirement: str prompt_rules: str source_code: str error_log: str fixed_code: str test_result: str current_stage: Literal[code_write, test_check, bug_fix] loop_retry_count: int max_retry: int # 通用调用千问封装函数 def call_qwen(prompt: str) - str: response Generation.call( modelqwen-turbo, promptprompt, result_formattext, temperature0.2, max_tokens1800, timeout35 ) if response.status_code 200: return response.output.text.strip() else: raise Exception(f大模型调用失败{response.code} {response.message}) # 节点1编写初始业务代码第一层 Prompt 约束落地 def code_write_node(state: BugFixState) - dict: prompt_content ( 【强制编写规则】\n f{state[prompt_rules]}\n\n 开发需求\n f{state[user_requirement]}\n\n 硬性要求只输出完整Python代码不要任何解释、开场白、多余话术。 ) code_result call_qwen(prompt_content) return { source_code: code_result, current_stage: test_check, loop_retry_count: 0 } # 节点2代码测试校验 def test_check_node(state: BugFixState) - dict: test_prompt ( f参照编码规则{state[prompt_rules]}\n 待检测Python代码\npython\n f{state[source_code]}\n \n 校验要求仅核查核心3项功能\n 1. user_id 参数非空 长度合法性校验\n 2. 全局异常捕获 try-except\n 3. 返回标准化JSON格式结果\n 冗余内部校验、细微逻辑瑕疵无需挑错。\n 输出格式严格遵守\n 1. 核心功能缺失开头固定写【FAIL】 简短问题描述\n 2. 全部核心需求满足只输出大写【PASS】三个字符 ) test_res call_qwen(test_prompt) return { test_result: test_res, error_log: test_res, current_stage: bug_fix } # 节点3Bug修复节点第四层 Loop 循环载体 def bug_fix_loop_node(state: BugFixState) - dict: new_retry_num state[loop_retry_count] 1 fix_prompt ( f编码约束{state[prompt_rules]}\n 原有错误代码\npython\n f{state[source_code]}\n \n f缺陷详情{state[error_log]}\n 重要要求一次性修复全部列出问题不要遗留任何缺陷输出完整最终Python代码无多余文字说明。 ) fixed_code call_qwen(fix_prompt) return { fixed_code: fixed_code, source_code: fixed_code, loop_retry_count: new_retry_num, current_stage: test_check } # 路由控制器控制Loop启停、分支流转 def route_control(state: BugFixState) - Literal[bug_fix_loop_node, END]: test_text state[test_result] current_retry state[loop_retry_count] max_limit state[max_retry] if PASS in test_text: print(✅ 校验全部通过代码修复完成Graph流程结束) return END elif current_retry max_limit: print(f❌ 已到达最大循环次数{max_limit}多次修复未能达标任务终止) return END else: print(f 检测存在功能缺陷开启第 {current_retry1} 轮修复循环) return bug_fix_loop_node # 第五层 Graph搭建整体有向工作流图 def build_graph_workflow(): graph StateGraph(BugFixState) # 注册所有业务节点 graph.add_node(code_write_node, code_write_node) graph.add_node(test_check_node, test_check_node) graph.add_node(bug_fix_loop_node, bug_fix_loop_node) # 设置流程入口 graph.set_entry_point(code_write_node) # 顺序流转写代码 → 测试校验 graph.add_edge(code_write_node, test_check_node) # 条件分支测试结果决定继续修复还是结束 graph.add_conditional_edges( sourcetest_check_node, pathroute_control, path_map{ bug_fix_loop_node: bug_fix_loop_node, END: END } ) # 修复完毕回流测试节点形成闭环循环 graph.add_edge(bug_fix_loop_node, test_check_node) # 编译流程图开启断点记忆流程中断可恢复 compiled_graph graph.compile(checkpointerMemorySaver()) return compiled_graph # 程序入口执行 if __name__ __main__: workflow build_graph_workflow() # 初始化入参配置 initial_input { user_requirement: 编写用户余额查询函数接收user_id参数校验用户ID合法性捕获所有运行异常返回标准化提示, prompt_rules: ( Prompt约束规范\n 1. 必须校验user_id非空、字符长度1~32位\n 2. 所有运行异常统一用try except捕获\n 3. 返回codemsg结构化字典数据\n 4. 代码简洁禁止多余注释 ), max_retry: 5, # 最大循环修复5次 loop_retry_count: 0 } # 会话ID用于断点续跑同一个任务 session_config {configurable: {thread_id: qwen_bugfix_final_demo}} final_output workflow.invoke(initial_input, configsession_config) # 打印最终汇总结果 print(\n 最终运行结果汇总 ) print(f最终成品代码\n{final_output[source_code]}) print(f\n最终测试结论{final_output[test_result]}) print(f累计循环修复次数{final_output[loop_retry_count]})安装依赖pip install langgraph python-dotenv dashscope六、什么时候该上 Graph很多人一上来就想搞多 Agent 协作平台结果搞了半年发现还不如一个 Loop 好用。我的建议先判断你的任务类型再选架构。适合用 Loop 的场景80% 的日常任务✅ 单一角色就能搞定的事✅ 流程线性不需要并行✅ 任务复杂度中等上下文不会爆✅ 快速验证、个人提效比如写个功能、修个 bug、整理份文档必须上 Graph 的场景✅ 需要多个专业角色配合✅ 有并行环节能显著提速✅ 流程复杂需要清晰的节点和卡点✅ 企业级生产环境要求可观测、可追溯比如完整的需求交付、复杂故障排查、跨部门业务流程选型判断表维度选 Loop选 Graph参与角色1 个3 个以上任务时长几分钟到几小时几小时到几天并行需求不需要有明显可并行环节可观测性要求低高需要知道每步状态团队规模个人 / 小团队企业级上手成本低高原则能 Loop 解决的就别上 Graph。Graph 不是高级版 Loop它是另一个维度的复杂度带来能力的同时也带来维护成本。七、避坑指南Graph 不是银弹最后泼点冷水Graph 很好但不是万能的。坑一为了 Graph 而 Graph很多团队任务明明一个 Loop 就能搞定非要拆成七八个节点美其名曰模块化结果效率反而更低排查问题更麻烦。记住架构是为业务服务的不是反过来。坑二节点拆得太碎每个节点只干一丢丢事一张图画了几十个节点看着很专业实际全是 overhead。经验法则一个节点至少要能独立交付一个小成果别搞第一步读文件、第二步解析内容这种粒度。坑三状态设计混乱State 什么都往里塞最后变成大杂烩每个节点都改出了问题根本不知道谁改坏的。建议状态分层设计每个节点只写自己负责的字段加权限标注。坑四忽略人工节点很多人设计 Graph 全是自动节点想着全自动化。实际生产环境里关键卡点必须有人工审核。高风险操作删数据、上线、发钱必须有人工确认节点这是底线。从 Prompt 到 Loop 到 Graph你会发现一条很有意思的线Prompt 时代我们研究怎么跟一个 AI 说话Loop 时代我们研究怎么让一个 AI 持续干活Graph 时代我们研究怎么让一群 AI 配合干活AI Agent 的进化本质上是在复刻人类社会组织的进化路径。从个体劳动到流水线作业到团队协作到组织化生产。未来还会有什么可能是 Graph of Graphs——大图套小图子图递归调用就像公司里有总公司、分公司、部门、小组。但不管架构怎么变有一点不会变人永远是最终的决策者和责任人。AI 的组织再复杂它也只是工具。定义目标、设计流程、把控质量、承担后果——这些事最终还是人的。喜欢动手的朋友赶紧试试吧高国生成式 —— 用 AI 兜底做人游刃有余。
