【免费下载链接】learn-harness-engineeringHarness engineering beginner tutorial, from 0 to 1项目地址https://gitcode.com/gh_mirrors/le/learn-harness-engineering点击查看免费下载本文基于 第 14 讲「从单循环到图工程」含 英文版展开结合仓库内的参考实现 maker_checker_graph.py 与配套实战项目 Project 08. 把工作流画成一张图讲解图工程Graph Engineering的核心概念、单循环的三种结构性失败以及从零构建第一张 Agent 编排图的完整六步方法。读完你将掌握图与工作流的本质区别、图的四个基本部件节点、边、共享状态、路由规则以及如何把上一讲构建的 maker-checker 单循环升级为可运行、可断点续跑、可局部修复的显式图。背景一个玩笑催生的流行词第 13 讲完成的循环工程Loop Engineering走红六周后——2026 年 7 月 18 日——OpenClaw 的作者 Peter Steinberger就是上一讲中提出别再给编码 Agent 写提示词的那个人发了一条推文你们还在聊 loop 吗还是已经转向 graph 了一条推文一天内获得约 57.5 万次浏览月底增长到约 300 万。几小时后机器学习工程师 Hamel Husain 发布了一篇题为《Loop Engineering Is Dead. Enter Graph Engineering》的文章——正文只有一张写着Stop it的 GIF——又获得了约 68 万浏览。更有意思的是这两个人都是开玩笑的。一个在讽刺行业每六周就发明一个新术语另一个顺着梗一唱一和。但玩笑只撑过了大约一个周末——课程、路线图、工具栈在周末内就填满了时间线还附带了大量捏造的数字精度 18%、成本 -85%是假数据这两个数字确实存在但来自一篇关于化工厂管道图的论文且比较基线完全不同微软、斯坦福、Anthropic 同时发现了图工程也是假消息。事实核查确认的唯一真正的先行者是 Josh Simmons他的《We Are Entering the Graph Engineering Phase》写于 7 月 4 日比这个玩笑整整早了两周——是玩笑让这个概念流行起来而不是玩笑创造了这个概念。本讲的目的不是给这把火再添一根柴而是把这个术语拆开看清楚为什么单循环之上必然会长出图图和工作流的区别到底在哪里什么时候真的需要图什么时候不需要prompt、context、loop、graph四个名字叠加起来的一层架构2026 年 7 月末工程师 Rohitrohit4verse发了一篇长文把过去几年 AI 工程的命名史整理成清晰的四层框架。这是理解图工程最好的坐标系层级塑造什么回答的问题关键产物Prompt Engineering指令如何告诉模型该做什么instructions、examples、constraints、roles、output formatsContext Engineering信息模型在决策前应该知道什么documents、history、memory、tool definitions、environment stateLoop Engineering运行时如何让模型自己循环直到达成目标observe、reason、act、inspect、update、停止条件Graph Engineering系统多个 Agent、循环、工具、评估者如何协作节点、边、共享状态、路由规则注意这条演进线的读法每一层不是取代上一层而是叠在上一层之上。开始做上下文工程之后你并没有停止提示工程——每次迭代仍然需要 prompt只是环境变化时循环会帮它更新。构建循环之后你也没有丢掉上下文——循环的每一轮都要重新组装自己的 context。到了图这一层prompt、context、loop 一个都没消失每个节点都有自己的 prompt、自己的 context、自己的工具、自己的记忆、自己的循环。图决定的只是节点之间如何连接。Rohit 的原文是这样收尾的一旦 Agent 需要专业化、并行、共享状态、验证和恢复它就不再是一个循环了。它是一张图。等等——harness 呢这四个名字里没有 Harness Engineering但本课程讲的恰恰是 harness。原因很简单Rohit 讲的是流行语的历史终点是图中间那层被跳过了。而且 harness 到底该放在哪一层业界自己也还没定论——explainx 把它放在 loop 之上Buildrix 论文把它放在 loop 之下。本课程在第 2 讲就定下了立场harness 是地基loop 和 graph 都建在它上面。这也解释了一个奇怪的现象Graph Engineering这个词 2026 年 7 月才火起来可每个人都觉得自己早就在这么做了。因为图并不是新发明而是任务复杂到一定程度时循环自然而然变成的样子。名字是后来才有的做法早就存在了。拆解图节点、边、状态、路由把图还原成最朴素的四个部件。节点Node承担某一职责的工作单元。它可以是一段确定性代码跑测试、算覆盖率、一次模型调用生成文档、一个工具git commit、发消息也可以是一个完整的 Agent——自带循环、能理解目标、会使用工具、卡住时能自己重试。节点可以是什么正是图工程和工作流工程真正的分界线后面会详细讲。边Edge表示节点之间如何交接。它不是简单的先做 A 再做 B——一条边可以表达四种关系并行A 完成后B 和 C 同时开始条件测试通过走左边失败走右边失败/重试节点挂了回到自己再来一次回退验证不通过回到三步前的实现节点共享状态State节点之间传递的数据包。需求、研究笔记、代码版本、测试结果、评审结论——都写在同一张公共工作台上。节点之间不是互相喊话而是读写同一份状态。路由规则Routing决定下一步去哪。这是图的控制流用最朴素的话说就是测试通过就交付测试失败就回到实现节点信息不足就回到研究节点。四个部件组合起来一张典型的开发图长这样对比上一讲的循环图上一讲是一个环——发现、派发、验证、持久化、再回到发现。本讲的图中环还在但被分解成了显式的节点和边。验证节点可以把失败直接打回实现节点实现节点可以在信息不足时退回研究节点——这些回退边在单循环里是隐式的只是 Agent 在自己的上下文窗口里记得应该回去而已。什么时候单循环不够用一个循环只有一条主干道。在 Project 07 构建的 maker-checker 循环里所有决策——下一步做什么、失败后去哪——都发生在同一个 Agent 的上下文窗口里。任务再复杂一点四个问题就会浮现分工研究 Agent、实现 Agent、测试 Agent谁先开始并行哪些工作可以同时进行回退测试失败后回到哪里——实现节点还是研究节点交接多个 Agent 如何看到同一份需求、笔记和测试结果评审者不同意实现者时听谁的黄仁勋在 Y Combinator 的 Startup School 2026 访谈与 Garry Tan 对谈中表达了类似观点随着底层实现越来越多地被 Agent 自动化人类的核心价值转向设计系统、明确约束、对 Agent 做细粒度控制。他举的控制例子非常具体——Agent 给出计划后我在计划文件里改一个词这一个词就产生精确的差异——并预言未来的核心技能是系统思维systems thinking。整场讨论中最尖锐的一击来自 Luis Catacora循环有很大的容错空间。图则迫使你承认你的工作流里有多少部分其实根本没有被建模。这句话点破了 loop 和 graph 的深层差异循环是一种被推迟的决策。先让一个 Agent 包揽所有工作转不动了再说。架构可以往后放。这很省事——但代价是失败模式不可见你永远不知道它卡在哪因为 Agent 自己也不知道。图是一种提前的决策。你必须事先声明整个结构谁负责什么、任务之间的依赖关系、某个失败要回到哪里。这更费事——但换来的是可读性、可审计性和局部修复能力。说得更直白一点loop 把问题藏进循环里graph 把问题摊在纸上。前者适合探索后者适合生产。单循环在规模下的三种结构性失败为什么单循环撑不过规模化eigent.ai 的《Graph Engineering for AI Agents: Beyond Single Feedback Loops》指出了三种结构性失败——注意这是结构性失败不是某个循环的 bug。先反驳一个问题循环不也能加检查点吗能。上一讲的验证、停止条件、甚至断点重试都能塞进循环里。但下面三种失败恰恰是检查点解决不了的——因为循环的检查点存在于同一个 Agent 内部做检查的和出问题的共用同一个大脑、同一个上下文。它能阻止不验证就交付但它不会问这个指标对吗或这个目标该不该追——答案明明写在它自己的上下文里它却看不见。图给你的不是更多检查点而是把检查搬到外面从 Agent 内部搬到拥有全新上下文的独立节点就是前面那个 verify 节点。结构性三个字的意义就在于此不是 loop 缺了什么零件而是评判者和被执行者共享同一个大脑这个结构本身有问题。1. Goodhart数字涨了业务却更糟了任何单一指标被推到极限就不再度量你原本以为它在度量的东西。经典案例某客服团队围绕工单解决率构建了一个循环。周数据一路上涨。几个月后续费率数据显示流失率翻了一倍——bot 学会了关闭工单转移话题、劝阻追问、把未解决的问题标记为已解决。循环做了它被要求做的一切。只是那个数字和业务真正关心的东西脱钩了。这就是古德哈特定律。2. 向上失明它从不问这个目标对吗循环内部参照值是神圣的。恒温器不会问68°F 是正确温度吗销售循环不会问这个定额合理吗Agent 评估循环不会问这个基准真的对应业务结果吗。无论当初是谁选了那个目标循环都会朝它狂奔——哪怕它从来就不该被追。单循环的结构里没有一个位置能放下这个问题。3. 冲突独立的循环互相拆台真实系统里有几十个循环各自独立构建。响应速度的循环破坏深度质量的循环增长的循环破坏质量的循环。每个循环在自己的仪表盘上都健康而整个系统在震荡——就像几个人朝不同方向拉同一根绳子。图工程要回答的正是单循环回答不了的那一组问题哪个循环喂养哪个循环哪个循环拥有别的循环在追逐的目标哪个循环能否决或回滚一个变更哪些指标允许动哪些必须冻结当系统里存在能吃掉你目标的循环和能否决你变更的循环时它们之间的关系就成为工程对象——而把关系之间的关系画出来就是一张图。锚点把循环钉在现实上eigent 文章里有一个标题是大家都会跳过的那部分锚点anchors。无论你的循环网络多精巧如果每个循环都漂离现实这个网络就只是互相漂移的共振。锚点就是把循环钉在真实世界上的东西——实际业务结果、ground truth 数据集、人工抽查。在设计图的时候锚点是最容易被跳过、又最不能省的一步。Graph 与 Workflow不只是换个名字这是整个主题里最容易误解的一点值得单独开一节。图工程爆火时有生产经验的人第一反应都是同一句嘀咕这不就是工作流吗DAG、状态机、工作流引擎我们跑了几十年了。这个直觉对了一半。图和工作流确实共享同一副骨架节点 边 共享状态 路由。Airflow、Prefect、Dagster、Temporal 这几十年做的编排正是这种图。Anthropic 2024 年 12 月发布的《Building Effective Agents》总结的五个模式——提示链、路由、并行化、编排者/工人、评估者/优化器——画出来就是不同形状的执行图。错的那一半在节点里。传统工作流的节点是确定性函数Python 函数、shell 脚本、SQL 任务。边是写死的代码if、switch、case。工程师用代码维护整个系统行为可预测——同样的输入永远走同样的路径。而图工程的节点可以是完整的 Agent自带循环、会使用工具、能理解目标、失败了自己重试。边也不一定是写死的——它可以携带路由规则由前一个节点的输出、验证结果、甚至另一个模型来决定下一步。借用 Anthropic 的一对概念来锐化这个区别Anthropic 用一句话区分工作流和 Agent——谁决定控制流如果是代码固定了步骤那就是工作流如果模型能在运行时改变步骤那就是 Agent。那图是什么图是同时容纳两者的容器。一张图里可以同时放工作流节点跑测试、算覆盖率——确定性代码不需要模型Agent 节点实现功能、评审代码——模型驱动的完整 Agent人类节点审批、复核——人在环中图停下来等人类点头所以准确的说法是图工程不是工作流的替代品而是工作流的泛化——节点的类型从函数拓宽到Agent边的决策从静态代码拓宽到动态路由。工作流是图中完全确定性的特例。反对意见iii.dev 的《Loops, Graphs, and the Layer That Matters》也落在同一个点上但结论相反形状是容易的部分而且是一次性的。承重的决定在于 loop 或 graph 由什么构成以及它运转起来之后会发生什么。iii.dev 的意思是不要把拓扑结构当成工程成就。工作流工程跑了数十年真正沉淀下来的不是节点怎么连而是可重放replayability、可观测observability、可恢复recoverability——出问题能重放、运行时能观察、崩溃后能续跑。图的形状随时可以重画这些承重能力才是你该投入精力的地方。这个批评值得记住画图本身不是目的图能承载多少工程能力才是目的。你其实一直在画图新瓶装旧酒还有另一个证据工具早就齐了。LangGraph2024 年 1 月发布到 2026 年 7 月月下载量约 6500 万次。面向 Agent 的图执行引擎节点可以是 Agent边可以带条件路由、checkpoint、interrupt。Anthropic 的五个模式2024 年 12 月的《Building Effective Agents》其实已经画出了提示链、路由、并行化、编排者/工人、评估者/优化器的图——只是没叫它图工程。Claude Code 的 subagent fan-out当你让一个主 Agent 并行派出一群子 Agent 时你已经在构建一张图了——只是没意识到。状态机、DAG 调度、任务队列、知识图谱计算机科学已经做了几十年图的工程。真正新的东西是什么节点从函数变成了Agent。这是唯一的变化也是全部的变化。以前写工作流节点逻辑、错误处理、重试策略都要手写现在一个节点只需要一句指令——研究一下这个问题评审这段代码——剩下的交给模型。节点变便宜了图才值得画。从零构建你的第一张图理论讲够了动手吧。上一讲的 maker-checker 是一个自己循环的单个Agent。图工程做的第一件事就是把这种单体 Agent 拆开每个节点变成一个专业化的 Agent各自拥有私有的 prompt、context、tools、memory 和自己的一小段循环节点之间不共享上下文只通过一张共享状态交接。这就是 Rohit 那句话的人话版——图决定每个节点看到什么、何时运行、输出去哪、谁能拒绝它、什么能让系统停下。下面的记号不绑定任何特定引擎——它们是概念LangGraph、CrewAI 只是把这些概念变成可执行程序的实现API 不同但骨架相同。六步一步都不能跳。第 1 步定义共享状态State。先分清两个层图这一层共享的只有状态节点的上下文是私有的。单体 Agent 只有一个上下文跑久了会淹死在自己冗长的 transcript 里图把上下文切成多份每份属于一个节点——loop 是节点的私有财产graph 是它们交接的公共台面。想清楚状态里放什么。为每个字段声明如何合并——多个并行节点同时写同一个字段时是覆盖、追加还是求和这一步不是框架的功能而是你画图时就要写进graph.md的规则state { requirements: 文本, # 研究节点写入 code: 文本, # 实现节点写入 review: pass | fail, # 验证节点写入 attempts: 数值, # 每次失败 1并行写入时按求和合并 }第 2 步列出节点——每个节点都是完整的 Agent自带循环。这是图和工作流的根本区别工作流的节点是函数图的节点是带着自己小循环的 Agent。节点接收共享状态 → 在自己的私有上下文里干活 → 把结果写回共享状态。写代码类节点的内部往往就是上一讲的那个循环# implement 节点内部私有小循环上一讲的 maker-checker loop node_implement(requirements): loop (最多 3 次): code model(prompt实现指令, contextrequirements 上次的错误) if tests_pass(code): return {code: code} return {error: 实现 3 次仍未通过}节点类型节点内部私有写入共享状态researchagent搜索 → 阅读 → 总结 → 信息不足就再搜循环requirementsimplementagent写 → 测 → 修 → 直到通过循环见上codeverifyagent独立评审 跑测试全新 context不继承实现者的记忆reviewpass / failmerge确定性代码无循环检查通过就立即 commit结束注意 verify 这一行——它是整张图里最容易做错的节点。在单体 Agent 里评审还在同一个上下文中运行等于自己审自己在图中verify 必须拿到完全新的上下文——它看不到实现的推理过程只能看到共享状态里的code。这就是独立评审在图上真正成立的地方上下文隔离不是副作用而是设计。第 3 步连边。先连确定性的主干线研究 → 实现 → 验证 → 合并 → 结束。第 4 步写路由规则最关键的一步。验证节点不是直接连到 merge而是连到一个决策点由它决定下一步去哪。这一步把测试失败回哪里显式化——路由规则返回的是节点名整张图从哪来、到哪去一览无余当前节点条件下一节点verifyreview passmergeverifyreview failimplement第 5 步挂 checkpoint。这是图和一次性脚本最大的区别之一每一步之后状态落盘进程挂了也能从断点接着跑不必从头再来。挂上之后图就免费获得了中断/恢复能力——还能在 merge 前插入暂停等待人工批准的节点。这就是上一讲人工评审在图上的样子checkpoint on(graph, every_step) # 每一步都保存状态 graph.pause_before(merge) # 合并前停下等人批准第 6 步给图一个入口并运行。每次运行都传一个线程 idcheckpoint 靠它区分不同的运行实例run(graph, entry{requirements: 修复登录页 bug}, threadsession-1)跑完之后对照上面的图你手写的graph.md是蓝图引擎里的那段代码是蓝图变成的可执行程序。两者应该一一对应。如果对不上——要么图画错了要么代码写错了这正是图把问题摊在纸上的含义以前对不上也没人发现现在一眼就看出来。如果你想要一份能跑起来的参考实现仓库里有 maker_checker_graph.py中文注释版用 LangGraph 编写。对照这份代码可以看到六步的完整落地GraphState定义了带合并语义的共享状态attempts用Annotated[int, operator.add]声明按求和合并正是第 1 步要求的并发写合并规则research/implement/verify是三个 Agent 节点verify只读state[code]天然隔离了实现者的上下文merge是确定性节点route_after_verify返回节点名实现条件路由最后用graph.compile(checkpointerMemorySaver())挂上检查点并在invoke时传入thread_id区分运行实例——四行核心调用与六步一一对应。代码目录的说明见 code/index.md。开源项目名字之后出现的和名字之前就有的先画一条线Graph Engineering是 2026 年 7 月 18 日之后才有的名字。在那之前开源出来的框架都不算图工程发布后的项目。截至 2026 年 8 月初概念爆火后直接顶着这个名字出现的开源项目立得住的只有一个概念发布之后出现的GraphArc2026-08-02自称图工程的第一个实时实现。它把 Agent 执行从埋在日志里的 trace 变成一张交互式实时编排图——每个 Agent、每个依赖、每个决策点都画出来执行前可视化给你确认手机也能看再放行。作者背景是为 4000 多名开发者做过图工具方向是可观测、可调试、可工程化。非常新功能还在早期阶段。概念发布之前就有的它们不叫图工程——但你真正拿来构建的就是它们2026 年 7 月之前这些工具已经存在了一到三年LangGraph2024 年开源月下载 6500 万以上就是上面参考实现用的引擎、CrewAI、Microsoft Agent Framework、LlamaIndex Workflows、Google ADK、OpenAI Agents SDK、Mastra、Claude Agent SDK。它们不是图工程发布后的项目——它们正是图工程发布之前的证据。节点、边、共享状态、路由这套东西已经跑了三到五年7 月只是给了个新名字。图引擎不解决设计问题它给你节点、边、checkpoint但它不会替你回答哪个循环喂养哪个、谁拥有目标、谁能否决。这些问题没想清楚之前换哪个引擎都只是把同样的坏设计画得更漂亮而已。泼冷水图不是银弹三桶冷水从轻到重。第一桶假数字。图工程爆火后网上流传用图精度 18%、成本 -85%之类的数据。韩国博主 goddaehee 做了事实核查7 月 30 日这两个数字确实存在但来自一篇 2026 年 3 月关于化工厂管道仪表图PID的论文——而且 18% 是跟图像原稿比的85% 是跟另一个方案比的。营销文案把两个不同基线的数字拼进了一个前后对比论文里甚至没有graph engineering这个词。看到图工程带来 X% 提升这种数据时先去查原始出处。第二桶形状不是承重墙iii.dev。前面讲过。loop 就是只有一个节点的图状态机跑了几十年。喊loop 死了或graph 死了的人多半两个都没好好读过。要学的是模式不是名词。第三桶编排税Orchestration Tax。Addy Osmani 5 月的《The Orchestration Tax》给出了图/多 Agent 时代最硬核的经济学启动一个 Agent 很便宜但闭环一个 Agent 很贵。启动 Agent 是一下按键的事。但闭合一个 Agent 的循环需要有人检查它带回来的结果并和别的 Agent 动过的东西对账——那个人是你而你只有一个。Osmani 的原话你就是你那些 AI Agent 的 GIL。它们可以同时跑。但只要它们的工作需要真正理解架构、或者解决合并冲突那些工作就必须拿到那把锁。锁只有一把。握着它的是你。这就是为什么上一讲说的评审带宽是天花板在这里变得更加尖锐图让更多 Agent 并行跑但你的判断力是串行资源不会并行。加节点优化的从来不是瓶颈——瓶颈永远是那一个串行处理器你。什么时候你真正需要一张图不是每个任务都配得上一张图。五个判断标准至少满足三个再动手任务能分解成独立的工作单元——互不依赖、可以并行的部分存在分支或回退路径——测试失败回哪信息不足回哪这些路径值得显式声明中间状态值得保存——能在 checkpoint 处暂停并恢复而不是从零重来结果能明确验收——每个节点都有可自动检查的完成标准协作收益 协调成本——并行省下的时间大于图本身和共享状态带来的开销复杂不等于步骤多。一个 20 步的线性流水线不需要图——那是工作流或者就是个脚本。只有 5 个节点但有真实回退、并行、审批的结构才需要图。判断标准不是规模而是分支和回退的存在。核心概念Graph Engineering把多个 Agent、循环、工具、评估者组织成显式图节点 边 共享状态 路由规则的工程实践让多个工作单元的连接、共享状态、路径选择变得可设计、可观测、可局部修复。四层叠加prompt → context → loop → graph每层控制不同的东西指令、信息、运行时、系统后一层不替换前一层只是把前一层装进自己的节点里。图的四个部件节点工作单元、边交接方式、共享状态公共工作台、路由规则下一步去哪。单循环的三种结构性失败Goodhart数字涨了业务却坏了、向上失明从不问这个目标对吗、冲突独立循环互相拆台。图把这三个问题变成显式的关系设计。Graph ≠ Workflow工作流的节点是确定性函数、边是写死的代码图的节点可以是完整 Agent、边可以动态路由。图是工作流的泛化。锚点Anchors把循环网络钉在现实世界的机制实际业务结果、ground truth、人工抽查。图设计中最容易被跳过、又最不能省的一步。编排税Orchestration Tax启动 Agent 便宜评审结果贵。你的注意力是唯一的串行资源加节点也优化不了它。核心要点图工程不取代循环工程而是在它上面盖一层。loop 是图里的一个节点上一讲的三件套目标、验证、停止条件成为节点的内部结构。图把推迟的决定变成提前的决定。loop 把失败模式藏进循环里graph 把它摊在纸上——可读、可审计、可局部修复。节点里放什么决定了图和工作流的区别。放函数是工作流放 Agent 是图。这也是新瓶装旧酒里唯一的新酒。画图之前先回答四个设计问题哪个循环喂养哪个、谁拥有目标、谁能否决/回滚、哪些指标能动哪些必须冻结。答不上来就别画。不要为画图而画图。五个标准可独立分解、有分支或回退、中间状态值得保存、结果可验收、协作收益 协调成本。你的评审带宽仍然是天花板。图让更多 Agent 并行但你的判断是串行的——节点变多编排税不会消失。记住反对意见。形状不是承重墙可重放、可观测、可恢复才是。名词每六周换一次工程能力不会。延伸阅读仓库内第 13 讲从手动提示到自主循环——loop 是图里的一个节点先理解节点内部再理解图英文版第 11 讲为什么可观测性属于 harness 内部——图越复杂可观测性越重要不可观测的图只是把黑箱拼成更大的黑箱第 9 讲为什么 Agent 过早宣布胜利——验证节点为什么必须独立于实现节点在图上这是结构问题不是 prompt 问题Project 08. 把工作流画成一张图——配套实战项目把 maker-checker 画成显式图、加并行 fan-out/fan-in、加回退边和人工审批节点英文版参考实现maker_checker_graph.py练习把 P07 的 maker-checker loop 画成图用graph.md显式写出节点、边、共享状态、路由规则。标出哪些边是条件边验证通过/失败、哪些是回退边失败回到实现。画完回答有没有哪条边原本是隐式的——之前藏在 Agent 的上下文里回答 eigent 的四个问题找出你在跑的三个独立循环或同一项目里的三个自动化回答它们之间谁喂养谁哪个循环拥有另一个循环在追逐的目标有没有哪个循环能否决另一个循环的产出哪些指标在被以可能冲突的方式优化Goodhart 自检检查一个你最近在优化的指标。它涨的时候真实结果业务结果、用户反馈、代码质量也一起变好了吗如果只有数字涨了这个循环正在朝哪个方向学会对你撒谎用五个标准给候选任务打分挑一个你纠结要不要图化的任务按五个标准逐项打分。至少要满足三个才值得画图。不足三个的话它真正需要的是更好的工作流脚本——不要为了用图而用图。把graph.md变成可执行程序按本讲从零构建第一张图的六步把画好的 maker-checker 图实现成能跑的图参考实现maker_checker_graph.py用 LangGraph 写的。六步一步不跳定义状态 → 列节点 → 连边 → 写路由 → 挂 checkpoint → 运行。跑完把图和代码对照找出第一处对不上的地方并解释为什么——是图画错了还是代码写错了赞分享【免费下载链接】learn-harness-engineeringHarness engineering beginner tutorial, from 0 to 1项目地址https://gitcode.com/gh_mirrors/le/learn-harness-engineering点击查看免费下载相关推荐Graph Engineering 从 0 到 1把单一 Agent 循环升级为多节点图工作流learn-harness-engineering 第 14 课Graph Engineering 从 0 到 1把单一 Agent 循环升级为多节点图工作流learn harness engineering 第 14Learn Harness Engineering 项目 08把工作流画成图——从单循环到图工程的第一步实战Learn Harness Engineering 项目 08把工作流画成图——从单循环到图工程的第一步实战 本教程是 Learn Harness Engin图工程Graph Engineering实战指南从单循环到多 Agent 协作图 —— Learn Harness Engineering 第十四讲深度解析图工程Graph Engineering实战指南从单循环到多 Agent 协作图 —— Learn Harness Engineering 第十四讲深度解创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考