这几天Graph Engineering 突然成了 Agent 圈的新词。更离谱的是Loop Engineering 才火了40 天左右。一个月前还在学怎么设计 Loop一个月后讨论中心已经换成 Graph。真是应了 AI 圈那句玩笑这周不学下周就不用学了。OpenClaw 创建者 Peter Steinberger 也问了一句“我们还在聊 Loop还是已经切到 Graph 了”于是有人把 Graph 解释成“多个 Agent 组队”还有一句更狠的Loop 已死Graph 永生。可我把几篇讨论和官方文档放在一起看后发现这根本不是一场淘汰赛。从 Prompt、Context、Harness、Loop 到 Graph真正发生的变化是 Agent 工程的控制边界一直在向外扩这不是五代技术的升级表也不是一套公认的行业标准。它更像五个逐渐扩大的工程边界从优化一次模型调用一直扩展到治理一整套有状态的执行系统。这篇文章只回答两个问题• 五个 Engineering 分别在工程什么• 什么任务值得用 Graph什么任务继续保留 Loop。文末我会拆开 Karpathy 的 AutoResearch、AgentHub 构想与一份流传很广的 Graph Engineering 综合资料看看一个已经跑过约 700 次尝试的强 Loop究竟什么时候需要继续长成 Graph。Prompt Engineering把这一轮话说清楚最早大家优化的是 Prompt目标怎么写限制怎么说输出格式如何约束例子应该放几个。它主要处理一次模型调用里的表达问题。模型理解偏了、格式不对、漏掉限制第一反应是改 Prompt。但 Prompt 再精细也不能保证模型获得了正确材料更不能负责工具权限、长任务恢复或下一轮什么时候发生。Context Engineering决定这一轮看见什么当 Prompt 已经说清楚问题常常变成模型根本没看到它需要的信息。Context Engineering 管的是进入当前上下文窗口的内容系统指令、用户请求、检索结果、文件片段、工具返回、对话状态以及哪些旧信息应该压缩或丢弃。它解决的不是“怎么说”而是“该让模型基于什么做决定”。Harness Engineering给模型一套能工作的环境再往外一层模型即使看到了正确信息也未必有能力安全地完成任务。Harness 是模型周围的运行机制工具、文件系统、沙箱、权限、记忆、模型路由、持久化、日志、预算和人工审批。两个团队使用同一个模型效果却差很多往往不是智力不同而是一个给了稳定工具和可观察状态另一个只给了模糊提示和脆弱的 API 封装。可以这样诊断前三层• 模型总是误解目标或输出格式先检查Prompt• 模型漏掉事实、看到旧状态或被噪声带偏先检查Context• 工具不可用、状态丢失、权限失控或无法审计先检查Harness。前三层主要在准备模型的工作条件。接下来的 Loop 和 Graph开始处理模型调用结束之后工作怎样继续。Loop Engineering 概念到底是什么我们今天熟悉的大多数 Agent都在跑一个循环接收任务决定下一步调用工具读取结果再根据新观察修改计划。你给模型一个目标、一些工具和一套规则具体路线在运行时才逐步形成。完整的工程 Loop 至少要回答什么触发它、目标是什么、状态保存在哪里、允许采取什么动作、拿什么证据验收、失败后反馈什么以及何时停止。模型可以选择下一次动作Harness 也可以根据测试、规则、预算或最大轮数决定继续还是停止。没有可靠反馈和停止条件的循环只是一个会反复烧 token 的while true。比如让 Agent 修复“用户被重复保存”的问题。它可能先读报错再查 parser发现 parser 没问题又去看 normalizer绕了一圈才定位到 dedupe。每次工具返回的观察都可能改变下一步计划。这就是 Loop 的价值在一个局部目标里根据新证据不断修正直到通过验收或触发停止条件。Loop Engineering 并不只是写一句“请一步一步思考”。真正的工程工作包括• 给模型哪些工具以及每个工具的权限• 上下文里保存哪些状态何时压缩• 如何限制最大轮数、预算和重复调用• 什么时候必须调用测试或 Judge• 什么条件算完成什么条件应该停止• 模型走错后如何让它回到有效状态。它的强项是探索代价则是控制过程比较隐式。路线常常埋在对话记录里同一个任务重跑两次也可能选择不同顺序。Graph Engineering把跨节点控制写出来Graph Engineering 是把多个工作单元之间的依赖、状态传递和控制关系写成一张可以运行的图。图里不只有模型。一个节点可以是• 一次模型调用• 一段普通 Python• 一组测试• 一个数据库事务• 一次人工审批• 一个仍然可以自主调用工具的 Agent Loop。节点之间的边则负责回答• 成功后去哪里• 失败后重试哪个节点• 哪些分支可以并行• 哪些结果需要汇总• 哪一步必须经过机械验收或人工确认。所以Graph Engineering 的重点不是“画出很多方框”而是把原来藏在模型对话里的跨节点控制逻辑变成程序能够读取、保存、测试和恢复的对象。Loop 让一个工作单元在反馈中收敛Graph 让多个工作单元按依赖关系协作。这也是为什么 Graph 不等于工作流图更不等于把 prompt 拆成几段。只有当节点、状态和边真正参与运行时控制它才是一张工程意义上的 Graph。三个最容易把人带偏的说法也可以在这里一次澄清•Graph 不等于多 Agent。单个模型可以跑完整张 Graph多个 Agent 也可以全部塞进一个 Loop•Graph 不等于并行。并行只是某些边的执行方式隐藏依赖没处理好只会更快地产生错误•用了 LangGraph 不等于完成 Graph Engineering。框架提供运行时不替你决定节点怎么拆、状态怎么建模、Verifier 是否可信。这不就是以前的 Workflow Agent 和 LangGraph 吗是而且不是“有一点像”而是同一条技术谱系。LangChain 在 2026 年 7 月发布的《3 Years of Graph Engineering with LangGraph》里说得很直接把 Agent 系统表示成 Graph 并不是新发明LangGraph 已经围绕这件事做了三年。LangGraph 官方对自己的核心抽象也一直是三样东西•State当前系统状态•Node执行工作的函数、模型调用、工具或完整 Agent•Edge决定下一步执行哪个节点的固定或条件转移。它还提供 checkpoint、持久化、人工介入、并行、回放和故障恢复。这些能力和今天大家讨论的 Graph Engineering 高度重合。那为什么又出现一个新词可以把三者的关系理解成•Workflow 是一种任务形状。路径大多预先确定例如“分类 → 检索 → 生成 → 审核”•LangGraph 是一种实现工具。它让节点、边、状态、循环和 checkpoint 真正运行起来•Graph Engineering 是一组设计工作。它关心节点边界怎么划、状态如何建模、失败从哪里恢复、谁来验收、哪些路径应该固定、哪些决定继续交给模型。所以“Graph Engineering”更多是在给一组已经存在的工程问题重新命名和聚焦不是凭空创造了新架构。LangChain 对这轮变化给出的解释也很克制过去一个节点常常只是一段代码或一次 LLM 调用现在 Agent 已经可靠到可以把一个完整的 Agent Loop 放进节点里。工程师开始编排的不只是模型调用而是能够独立工作的 Agent 单元。反过来传统 Workflow 也不是低级版本。如果业务路径本来就稳定普通状态机、任务队列甚至一段清楚的 Python 代码都能解决没必要为了追新词换框架。Workflow 描述路径LangGraph 提供运行时Graph Engineering 负责把这张图设计对。Loop 和 Graph 并不冲突从拓扑结构看Loop 确实可以看成 Graph 的一个特例一个节点加一条指回自己的边就是最小的有环图。Graph 里的节点也可以继续运行 Loop。比如一个“调查根因”节点内部仍由模型反复读代码、调用工具、检查结果和修改计划只有当它交出结果后外部控制器才决定进入测试、人工确认还是返工。所以两者更准确的关系是• **拓扑层面**Loop 可以表示成一张带回边的 Graph• **运行层面**一张 Graph 可以包含许多内部运行 Loop 的节点• **工程层面**Loop Engineering 主要处理节点内部如何迭代Graph Engineering 主要处理节点之间如何传递状态和控制。但“Loop 是 Graph 的特例”只是一种结构描述不是选型结论。任何循环都能画成图不代表都值得投入 Graph Engineering。真正需要权衡的仍然是哪些决定留给模型临场处理哪些决定值得外置成可测试的程序控制。一张能进生产的 Graph至少有五样东西1. State脱离聊天记录的状态Loop 常把进度保存在一段不断增长的 transcript 里。Graph 更倾向于把状态定义成明确对象例如任务 ID、当前阶段、产物、重试次数、剩余预算和最近一次错误。状态可以写入磁盘或数据库也可以设置 schema、版本和幂等键。进程重启后系统不必靠“回忆整段对话”猜自己做到哪一步。当然Loop 也可以把状态写盘。区别不在于 Graph 垄断了持久化而在于 Graph 通常把状态当作控制器的一等输入。2. Node一次可单独测试的工作一个好节点只负责一个相对稳定的职责例如“提取结构”“生成候选”“执行测试”。更重要的是节点要有契约输入从哪里来、输出是什么结构、允许使用什么工具、失败如何表达。输入输出最好能用 schema 验证而不是依赖下一个节点从一大段自由文本里猜。节点边界越清楚就越容易隔离上下文、单独测试、替换模型、限制预算和重跑失败部分。节点也不必很小如果某一步本身充满未知性它完全可以是一个内部带 Loop 的探索 Agent。3. Edge显式写出的下一步边不是一句模糊的“然后做 B”而是数据、约束或控制依赖的契约A 产出什么B 为什么必须等它这份状态以什么结构跨过去。如果 B 完全不读取 A 的结果两者之间可能根本没有边只是我们习惯把它们按书写顺序排成了一条线。这类假依赖才是 Graph 可以拆开并行的地方。最简单的边就是确定性条件测试通过就输出测试失败就返回修复预算耗尽就交给人。也可以让模型充当 router读取状态后选择分支。但这时要把 router 的成本、误判率和回退路径单独计算不能因为它被画进 Graph就当作确定性控制。4. Verifier真的能分出对错的验收门Graph 很容易让人产生一种错觉多画一个 “Reviewer” 节点系统就会更可靠。并不会。如果 Reviewer 只能生成一段“整体不错”的主观文字它只是另一次模型调用。真正有效的 Verifier 应尽量连接机械证据测试、schema、diff、约束检查、权限规则或可审计的评分标准。Graph 能安排验收发生在哪里却不能凭空创造判断正确性的能力。5. Checkpoint让失败只重跑一部分Graph 的恢复价值来自每次跨边时保存状态和产物。如果第三个节点崩溃系统可以从第三个节点重新开始而不是把前两个节点再跑一遍。只有节点具备幂等性、产物有完整性校验checkpoint 才不是“保存了一个过期进度条”。带回边的 Graph 还必须有收敛契约什么算通过、最多重试几次、预算耗尽后去哪里、何时交给人。Graph 可以有环但不能只有环。Loop 和 Graph工程上到底差在哪里这张表比较的是常见工程重心不是不可打破的能力边界。Loop 也能写盘、并行、接机械 VerifierGraph 如果没有 checkpoint、幂等节点和可信 Gate也不会自动获得局部恢复与可靠验收。Graph 的实际价值是把一部分已经知道的控制关系前移成设计时约束。它不是白送的可靠性你要先知道哪些状态值得保存哪些节点可以重试哪些副作用不能重复哪些分支真的独立。如果任务本身只跑一次搭 Graph 的时间可能比 Agent 完成任务还长。什么任务应该用 Graph先别问“Graph 是不是更先进”问下面六个问题。1. 运行前知道大部分步骤吗数据库迁移后跑测试、文档经过抽取后进入审核、PR 经过实现后进入 CI这些依赖关系可以提前写清适合 Graph。如果每获得一条观察调查计划都会改变更适合 Loop。2. 同一种任务形状会重复多少次重复不决定能不能用 Loop它只影响 Graph 的建设成本能否被摊薄。每天、每个 PR、每批数据都要执行而且路线相对稳定的流程更值得为状态和恢复投入工程成本。如果任务虽然高频但每次拿到的观察都会改变后续路线仍然需要 Loop。反过来一次性任务若包含昂贵副作用、人工审批或跨天恢复也可能值得用 Graph。3. 机器能不能判断正确有测试、schema、规则或可计算指标Graph 才能建立有效 gate。只能靠品味判断的任务需要人工确认不能拿一个模型 Reviewer 假装机械验收。4. 一次失败有多贵如果任务会运行几个小时、调用昂贵工具或产生外部副作用checkpoint 和局部重试非常重要。十几秒就能重跑的任务恢复系统可能比失败本身更贵。5. 分支真的独立吗只有写集合、资源锁和依赖关系能被证明独立Graph 的并行才有意义。否则先串行别用图形上的平行位置替代依赖分析。6. 过程需要审计或人工审批吗预算控制、合规审批、证据留存和跨天恢复都是外部控制图的强信号。可以把选择压缩成一句话稳定、重复、可验证、失败昂贵是更值得外置成 Graph 的信号未知、低频、需要临场改计划则更值得保留 Loop。它们是权衡条件不是硬规则。不要重写系统从 Loop 渐进长出 Graph把现有 Agent 改成 Graph不应该从“先画一张巨大的流程图”开始。更安全的顺序是先记录路线。统计 Agent 实际调用了哪些工具、在哪失败、哪些步骤每次都会出现。把状态移出 transcript。先保存任务 ID、阶段、产物、预算和错误不急着拆很多节点。提取稳定节点。只把重复出现、输入输出清楚的步骤外置。增加机械 Judge。没有可信验收时不要先扩并行和自动重试。写明失败边。区分可重试错误、永久失败、预算耗尽和人工接管。确认独立后再并行。先证明分支独立再做 fan-out / join。保留探索节点。不确定的部分继续由 Loop 处理不强迫整套系统都确定化。实际得到的往往不是一张纯 Graph而是一套混合结构外层 Graph 负责预算、状态、恢复、审批和证据内层 Loop 负责阅读新观察、调用工具和调整局部计划。一个真实案例Karpathy 的 Loop 跑了约 700 次以后真正跑过约 700 次的是 AutoResearch2026 年 3 月Karpathy 公开了 AutoResearch让一个 Coding Agent 自动修改一个小型语言模型训练程序执行训练再根据验证指标决定保留还是回滚。它的结构并不复杂Agent 阅读任务说明和当前train.py提出一个改动并提交用固定约 5 分钟的训练预算运行实验读取val_bpb指标指标变好就保留没变好或崩溃就回滚把结果写进results.tsv继续下一轮。Karpathy 后来总结说这套 Loop 在大约两天内尝试了约 700 次改动其中约 20 项改善被保留下来而且可以叠加、迁移到更大的模型。这组事实很有价值因为它证明了一件容易被“Graph 永生”口号遮住的事只要目标单一、指标可机械验证、动作可以回滚一个工程化的 Loop 已经能跑得非常远。AutoResearch 证明了强 Loop不是 Graph 更强AutoResearch 有明确指标、Git 回滚和results.tsv日志证明一个工程化 Loop 可以持续运行、保留改善并从失败中恢复。但它没有做 Loop 与 Graph 的对照实验也没有回答多条探索分支、多个 Agent 协作和跨会话事实追溯的问题。更准确的问题是一个单线程 Loop 的本地历史什么时候不足以支撑更大范围的协作与状态管理这才是 Graph 开始有价值的地方。这份 11 页 PDF 到底讲了什么Karpathy 还公开过 AgentHub 构想多个 Agent 围绕同一个仓库在不同分支上工作通过提交图和留言板协作。它展示的是一张“工作谱系图”——哪个实验从哪个提交分叉、由谁完成、指标如何、能否合并。Karpathy 分享的这份 11 页 Graph Engineering PDF又把 AutoResearch、AgentHub、Anthropic 的 Agent 模式与知识图谱串在一起。它提出的核心路线是先让一个 Loop 能被测量和回滚再逐步增加工具、计划、多 Agent、持久图谱和大规模并行。PDF 首页和最后一页已经把边界写得很清楚它是基于公开仓库、课程、演讲和 Anthropic 资料整理的独立汇编不隶属于 Karpathy 或 Anthropic也没有获得双方背书。这份 PDF 真正有用的是把架构演进拆成了六个阶段Day 1可测量的 Loop。保存每版产物用明确标准评估失败后修改并设置停止条件。Day 2增加工具。只针对已经观察到的错误类型增加搜索、代码执行、数据库或文件工具。Week 1增加计划。只有任务路径会变化时才生成计划并验证依赖、限制重试与总成本。Week 2进入多 Agent。用角色分工、结构化交付物和 worktree 隔离解决并行协作而不是只增加聊天窗口。Month 1接入持久图谱。保存实体、主张、来源、关系、产物、运行与评估让每条边都能追溯来源。Month 2扩成 Swarm。只并行真正独立的工作并提前定义 reducer、预算、去重、超时和最终验收。它还区分了两张不能混在一起的图commit DAG 保存“工作如何分叉与演进”知识图谱保存“事实、实体与来源如何关联”。生产系统再用控制、执行、产物、图谱和评估五个平面把它们连接起来。这是一份架构路线图不是一场由 Karpathy 完成的 Graph 实验。下面这张图的作用就是把三种证据拆开。但这里也要把证据边界写清楚•AutoResearch 是已经运行过的真实 Loop 实验•AgentHub 是 Karpathy 公开的多 Agent 协作构想不是成熟生产系统•这份 11 页 PDF 由 Karpathy 分享但文档本身注明它是一份 independent synthesis并非 Karpathy 署名论文或 Anthropic 官方报告•“知识图谱作为共享记忆”是值得尝试的架构方向但不是那 700 次实验已经验证出的结论。因此这个案例不能证明“Graph 比 Loop 更强”。它真正提供的是一条很清楚的演进路线• **单目标优化结果可量化失败可回滚**先做一个带 Verifier、日志和停止条件的强 Loop• **多条实验路线要同时保留、比较和合并**再增加 commit DAG 或其他显式工作谱系• **多个 Agent 要协作又不能互相覆盖**增加分支隔离、调度、消息和合并规则• **事实要跨任务复用还要追溯来源**再考虑带 provenance 的长期存储或知识图谱。AutoResearch 证明的是“一个有外部评估、回滚和历史记录的 Loop 能跑得很远”AgentHub 与知识图谱展示的则是当一个 Loop 不够时Graph 应该外置哪些关系。两者不能被包装成同一场对照实验。从 Prompt 到 Graph没有哪一层真的死了回头看这五层会发现所谓“新概念”并不是五次推倒重来• Prompt 管表达• Context 管模型看见的材料• Harness 管工具、权限和运行环境• Loop 管一个工作单元如何根据反馈收敛• Graph 管多个工作单元怎样连接、传递状态和恢复。外层解决了更大范围的问题却仍然依赖内层。Graph 的节点需要 Harness、Context 和 Prompt很多节点内部仍然运行 Loop。Graph Engineering 真正带来的变化不是“让更多 Agent 组队”而是把跨节点的控制权、状态和失败语义从模型对话里拿出来变成可以测试的工程对象。但不是所有未知都值得提前画成边。已经知道路怎么走就别每到一个路口都花钱请模型开会。还不知道路在哪里也别先画一张 Graph再逼现实按图施工。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
这几天Graph Engineering 突然成了 Agent 圈的新词。更离谱的是Loop Engineering 才火了40 天左右。一个月前还在学怎么设计 Loop一个月后讨论中心已经换成 Graph。真是应了 AI 圈那句玩笑这周不学下周就不用学了。OpenClaw 创建者 Peter Steinberger 也问了一句“我们还在聊 Loop还是已经切到 Graph 了”于是有人把 Graph 解释成“多个 Agent 组队”还有一句更狠的Loop 已死Graph 永生。可我把几篇讨论和官方文档放在一起看后发现这根本不是一场淘汰赛。从 Prompt、Context、Harness、Loop 到 Graph真正发生的变化是 Agent 工程的控制边界一直在向外扩这不是五代技术的升级表也不是一套公认的行业标准。它更像五个逐渐扩大的工程边界从优化一次模型调用一直扩展到治理一整套有状态的执行系统。这篇文章只回答两个问题• 五个 Engineering 分别在工程什么• 什么任务值得用 Graph什么任务继续保留 Loop。文末我会拆开 Karpathy 的 AutoResearch、AgentHub 构想与一份流传很广的 Graph Engineering 综合资料看看一个已经跑过约 700 次尝试的强 Loop究竟什么时候需要继续长成 Graph。Prompt Engineering把这一轮话说清楚最早大家优化的是 Prompt目标怎么写限制怎么说输出格式如何约束例子应该放几个。它主要处理一次模型调用里的表达问题。模型理解偏了、格式不对、漏掉限制第一反应是改 Prompt。但 Prompt 再精细也不能保证模型获得了正确材料更不能负责工具权限、长任务恢复或下一轮什么时候发生。Context Engineering决定这一轮看见什么当 Prompt 已经说清楚问题常常变成模型根本没看到它需要的信息。Context Engineering 管的是进入当前上下文窗口的内容系统指令、用户请求、检索结果、文件片段、工具返回、对话状态以及哪些旧信息应该压缩或丢弃。它解决的不是“怎么说”而是“该让模型基于什么做决定”。Harness Engineering给模型一套能工作的环境再往外一层模型即使看到了正确信息也未必有能力安全地完成任务。Harness 是模型周围的运行机制工具、文件系统、沙箱、权限、记忆、模型路由、持久化、日志、预算和人工审批。两个团队使用同一个模型效果却差很多往往不是智力不同而是一个给了稳定工具和可观察状态另一个只给了模糊提示和脆弱的 API 封装。可以这样诊断前三层• 模型总是误解目标或输出格式先检查Prompt• 模型漏掉事实、看到旧状态或被噪声带偏先检查Context• 工具不可用、状态丢失、权限失控或无法审计先检查Harness。前三层主要在准备模型的工作条件。接下来的 Loop 和 Graph开始处理模型调用结束之后工作怎样继续。Loop Engineering 概念到底是什么我们今天熟悉的大多数 Agent都在跑一个循环接收任务决定下一步调用工具读取结果再根据新观察修改计划。你给模型一个目标、一些工具和一套规则具体路线在运行时才逐步形成。完整的工程 Loop 至少要回答什么触发它、目标是什么、状态保存在哪里、允许采取什么动作、拿什么证据验收、失败后反馈什么以及何时停止。模型可以选择下一次动作Harness 也可以根据测试、规则、预算或最大轮数决定继续还是停止。没有可靠反馈和停止条件的循环只是一个会反复烧 token 的while true。比如让 Agent 修复“用户被重复保存”的问题。它可能先读报错再查 parser发现 parser 没问题又去看 normalizer绕了一圈才定位到 dedupe。每次工具返回的观察都可能改变下一步计划。这就是 Loop 的价值在一个局部目标里根据新证据不断修正直到通过验收或触发停止条件。Loop Engineering 并不只是写一句“请一步一步思考”。真正的工程工作包括• 给模型哪些工具以及每个工具的权限• 上下文里保存哪些状态何时压缩• 如何限制最大轮数、预算和重复调用• 什么时候必须调用测试或 Judge• 什么条件算完成什么条件应该停止• 模型走错后如何让它回到有效状态。它的强项是探索代价则是控制过程比较隐式。路线常常埋在对话记录里同一个任务重跑两次也可能选择不同顺序。Graph Engineering把跨节点控制写出来Graph Engineering 是把多个工作单元之间的依赖、状态传递和控制关系写成一张可以运行的图。图里不只有模型。一个节点可以是• 一次模型调用• 一段普通 Python• 一组测试• 一个数据库事务• 一次人工审批• 一个仍然可以自主调用工具的 Agent Loop。节点之间的边则负责回答• 成功后去哪里• 失败后重试哪个节点• 哪些分支可以并行• 哪些结果需要汇总• 哪一步必须经过机械验收或人工确认。所以Graph Engineering 的重点不是“画出很多方框”而是把原来藏在模型对话里的跨节点控制逻辑变成程序能够读取、保存、测试和恢复的对象。Loop 让一个工作单元在反馈中收敛Graph 让多个工作单元按依赖关系协作。这也是为什么 Graph 不等于工作流图更不等于把 prompt 拆成几段。只有当节点、状态和边真正参与运行时控制它才是一张工程意义上的 Graph。三个最容易把人带偏的说法也可以在这里一次澄清•Graph 不等于多 Agent。单个模型可以跑完整张 Graph多个 Agent 也可以全部塞进一个 Loop•Graph 不等于并行。并行只是某些边的执行方式隐藏依赖没处理好只会更快地产生错误•用了 LangGraph 不等于完成 Graph Engineering。框架提供运行时不替你决定节点怎么拆、状态怎么建模、Verifier 是否可信。这不就是以前的 Workflow Agent 和 LangGraph 吗是而且不是“有一点像”而是同一条技术谱系。LangChain 在 2026 年 7 月发布的《3 Years of Graph Engineering with LangGraph》里说得很直接把 Agent 系统表示成 Graph 并不是新发明LangGraph 已经围绕这件事做了三年。LangGraph 官方对自己的核心抽象也一直是三样东西•State当前系统状态•Node执行工作的函数、模型调用、工具或完整 Agent•Edge决定下一步执行哪个节点的固定或条件转移。它还提供 checkpoint、持久化、人工介入、并行、回放和故障恢复。这些能力和今天大家讨论的 Graph Engineering 高度重合。那为什么又出现一个新词可以把三者的关系理解成•Workflow 是一种任务形状。路径大多预先确定例如“分类 → 检索 → 生成 → 审核”•LangGraph 是一种实现工具。它让节点、边、状态、循环和 checkpoint 真正运行起来•Graph Engineering 是一组设计工作。它关心节点边界怎么划、状态如何建模、失败从哪里恢复、谁来验收、哪些路径应该固定、哪些决定继续交给模型。所以“Graph Engineering”更多是在给一组已经存在的工程问题重新命名和聚焦不是凭空创造了新架构。LangChain 对这轮变化给出的解释也很克制过去一个节点常常只是一段代码或一次 LLM 调用现在 Agent 已经可靠到可以把一个完整的 Agent Loop 放进节点里。工程师开始编排的不只是模型调用而是能够独立工作的 Agent 单元。反过来传统 Workflow 也不是低级版本。如果业务路径本来就稳定普通状态机、任务队列甚至一段清楚的 Python 代码都能解决没必要为了追新词换框架。Workflow 描述路径LangGraph 提供运行时Graph Engineering 负责把这张图设计对。Loop 和 Graph 并不冲突从拓扑结构看Loop 确实可以看成 Graph 的一个特例一个节点加一条指回自己的边就是最小的有环图。Graph 里的节点也可以继续运行 Loop。比如一个“调查根因”节点内部仍由模型反复读代码、调用工具、检查结果和修改计划只有当它交出结果后外部控制器才决定进入测试、人工确认还是返工。所以两者更准确的关系是• **拓扑层面**Loop 可以表示成一张带回边的 Graph• **运行层面**一张 Graph 可以包含许多内部运行 Loop 的节点• **工程层面**Loop Engineering 主要处理节点内部如何迭代Graph Engineering 主要处理节点之间如何传递状态和控制。但“Loop 是 Graph 的特例”只是一种结构描述不是选型结论。任何循环都能画成图不代表都值得投入 Graph Engineering。真正需要权衡的仍然是哪些决定留给模型临场处理哪些决定值得外置成可测试的程序控制。一张能进生产的 Graph至少有五样东西1. State脱离聊天记录的状态Loop 常把进度保存在一段不断增长的 transcript 里。Graph 更倾向于把状态定义成明确对象例如任务 ID、当前阶段、产物、重试次数、剩余预算和最近一次错误。状态可以写入磁盘或数据库也可以设置 schema、版本和幂等键。进程重启后系统不必靠“回忆整段对话”猜自己做到哪一步。当然Loop 也可以把状态写盘。区别不在于 Graph 垄断了持久化而在于 Graph 通常把状态当作控制器的一等输入。2. Node一次可单独测试的工作一个好节点只负责一个相对稳定的职责例如“提取结构”“生成候选”“执行测试”。更重要的是节点要有契约输入从哪里来、输出是什么结构、允许使用什么工具、失败如何表达。输入输出最好能用 schema 验证而不是依赖下一个节点从一大段自由文本里猜。节点边界越清楚就越容易隔离上下文、单独测试、替换模型、限制预算和重跑失败部分。节点也不必很小如果某一步本身充满未知性它完全可以是一个内部带 Loop 的探索 Agent。3. Edge显式写出的下一步边不是一句模糊的“然后做 B”而是数据、约束或控制依赖的契约A 产出什么B 为什么必须等它这份状态以什么结构跨过去。如果 B 完全不读取 A 的结果两者之间可能根本没有边只是我们习惯把它们按书写顺序排成了一条线。这类假依赖才是 Graph 可以拆开并行的地方。最简单的边就是确定性条件测试通过就输出测试失败就返回修复预算耗尽就交给人。也可以让模型充当 router读取状态后选择分支。但这时要把 router 的成本、误判率和回退路径单独计算不能因为它被画进 Graph就当作确定性控制。4. Verifier真的能分出对错的验收门Graph 很容易让人产生一种错觉多画一个 “Reviewer” 节点系统就会更可靠。并不会。如果 Reviewer 只能生成一段“整体不错”的主观文字它只是另一次模型调用。真正有效的 Verifier 应尽量连接机械证据测试、schema、diff、约束检查、权限规则或可审计的评分标准。Graph 能安排验收发生在哪里却不能凭空创造判断正确性的能力。5. Checkpoint让失败只重跑一部分Graph 的恢复价值来自每次跨边时保存状态和产物。如果第三个节点崩溃系统可以从第三个节点重新开始而不是把前两个节点再跑一遍。只有节点具备幂等性、产物有完整性校验checkpoint 才不是“保存了一个过期进度条”。带回边的 Graph 还必须有收敛契约什么算通过、最多重试几次、预算耗尽后去哪里、何时交给人。Graph 可以有环但不能只有环。Loop 和 Graph工程上到底差在哪里这张表比较的是常见工程重心不是不可打破的能力边界。Loop 也能写盘、并行、接机械 VerifierGraph 如果没有 checkpoint、幂等节点和可信 Gate也不会自动获得局部恢复与可靠验收。Graph 的实际价值是把一部分已经知道的控制关系前移成设计时约束。它不是白送的可靠性你要先知道哪些状态值得保存哪些节点可以重试哪些副作用不能重复哪些分支真的独立。如果任务本身只跑一次搭 Graph 的时间可能比 Agent 完成任务还长。什么任务应该用 Graph先别问“Graph 是不是更先进”问下面六个问题。1. 运行前知道大部分步骤吗数据库迁移后跑测试、文档经过抽取后进入审核、PR 经过实现后进入 CI这些依赖关系可以提前写清适合 Graph。如果每获得一条观察调查计划都会改变更适合 Loop。2. 同一种任务形状会重复多少次重复不决定能不能用 Loop它只影响 Graph 的建设成本能否被摊薄。每天、每个 PR、每批数据都要执行而且路线相对稳定的流程更值得为状态和恢复投入工程成本。如果任务虽然高频但每次拿到的观察都会改变后续路线仍然需要 Loop。反过来一次性任务若包含昂贵副作用、人工审批或跨天恢复也可能值得用 Graph。3. 机器能不能判断正确有测试、schema、规则或可计算指标Graph 才能建立有效 gate。只能靠品味判断的任务需要人工确认不能拿一个模型 Reviewer 假装机械验收。4. 一次失败有多贵如果任务会运行几个小时、调用昂贵工具或产生外部副作用checkpoint 和局部重试非常重要。十几秒就能重跑的任务恢复系统可能比失败本身更贵。5. 分支真的独立吗只有写集合、资源锁和依赖关系能被证明独立Graph 的并行才有意义。否则先串行别用图形上的平行位置替代依赖分析。6. 过程需要审计或人工审批吗预算控制、合规审批、证据留存和跨天恢复都是外部控制图的强信号。可以把选择压缩成一句话稳定、重复、可验证、失败昂贵是更值得外置成 Graph 的信号未知、低频、需要临场改计划则更值得保留 Loop。它们是权衡条件不是硬规则。不要重写系统从 Loop 渐进长出 Graph把现有 Agent 改成 Graph不应该从“先画一张巨大的流程图”开始。更安全的顺序是先记录路线。统计 Agent 实际调用了哪些工具、在哪失败、哪些步骤每次都会出现。把状态移出 transcript。先保存任务 ID、阶段、产物、预算和错误不急着拆很多节点。提取稳定节点。只把重复出现、输入输出清楚的步骤外置。增加机械 Judge。没有可信验收时不要先扩并行和自动重试。写明失败边。区分可重试错误、永久失败、预算耗尽和人工接管。确认独立后再并行。先证明分支独立再做 fan-out / join。保留探索节点。不确定的部分继续由 Loop 处理不强迫整套系统都确定化。实际得到的往往不是一张纯 Graph而是一套混合结构外层 Graph 负责预算、状态、恢复、审批和证据内层 Loop 负责阅读新观察、调用工具和调整局部计划。一个真实案例Karpathy 的 Loop 跑了约 700 次以后真正跑过约 700 次的是 AutoResearch2026 年 3 月Karpathy 公开了 AutoResearch让一个 Coding Agent 自动修改一个小型语言模型训练程序执行训练再根据验证指标决定保留还是回滚。它的结构并不复杂Agent 阅读任务说明和当前train.py提出一个改动并提交用固定约 5 分钟的训练预算运行实验读取val_bpb指标指标变好就保留没变好或崩溃就回滚把结果写进results.tsv继续下一轮。Karpathy 后来总结说这套 Loop 在大约两天内尝试了约 700 次改动其中约 20 项改善被保留下来而且可以叠加、迁移到更大的模型。这组事实很有价值因为它证明了一件容易被“Graph 永生”口号遮住的事只要目标单一、指标可机械验证、动作可以回滚一个工程化的 Loop 已经能跑得非常远。AutoResearch 证明了强 Loop不是 Graph 更强AutoResearch 有明确指标、Git 回滚和results.tsv日志证明一个工程化 Loop 可以持续运行、保留改善并从失败中恢复。但它没有做 Loop 与 Graph 的对照实验也没有回答多条探索分支、多个 Agent 协作和跨会话事实追溯的问题。更准确的问题是一个单线程 Loop 的本地历史什么时候不足以支撑更大范围的协作与状态管理这才是 Graph 开始有价值的地方。这份 11 页 PDF 到底讲了什么Karpathy 还公开过 AgentHub 构想多个 Agent 围绕同一个仓库在不同分支上工作通过提交图和留言板协作。它展示的是一张“工作谱系图”——哪个实验从哪个提交分叉、由谁完成、指标如何、能否合并。Karpathy 分享的这份 11 页 Graph Engineering PDF又把 AutoResearch、AgentHub、Anthropic 的 Agent 模式与知识图谱串在一起。它提出的核心路线是先让一个 Loop 能被测量和回滚再逐步增加工具、计划、多 Agent、持久图谱和大规模并行。PDF 首页和最后一页已经把边界写得很清楚它是基于公开仓库、课程、演讲和 Anthropic 资料整理的独立汇编不隶属于 Karpathy 或 Anthropic也没有获得双方背书。这份 PDF 真正有用的是把架构演进拆成了六个阶段Day 1可测量的 Loop。保存每版产物用明确标准评估失败后修改并设置停止条件。Day 2增加工具。只针对已经观察到的错误类型增加搜索、代码执行、数据库或文件工具。Week 1增加计划。只有任务路径会变化时才生成计划并验证依赖、限制重试与总成本。Week 2进入多 Agent。用角色分工、结构化交付物和 worktree 隔离解决并行协作而不是只增加聊天窗口。Month 1接入持久图谱。保存实体、主张、来源、关系、产物、运行与评估让每条边都能追溯来源。Month 2扩成 Swarm。只并行真正独立的工作并提前定义 reducer、预算、去重、超时和最终验收。它还区分了两张不能混在一起的图commit DAG 保存“工作如何分叉与演进”知识图谱保存“事实、实体与来源如何关联”。生产系统再用控制、执行、产物、图谱和评估五个平面把它们连接起来。这是一份架构路线图不是一场由 Karpathy 完成的 Graph 实验。下面这张图的作用就是把三种证据拆开。但这里也要把证据边界写清楚•AutoResearch 是已经运行过的真实 Loop 实验•AgentHub 是 Karpathy 公开的多 Agent 协作构想不是成熟生产系统•这份 11 页 PDF 由 Karpathy 分享但文档本身注明它是一份 independent synthesis并非 Karpathy 署名论文或 Anthropic 官方报告•“知识图谱作为共享记忆”是值得尝试的架构方向但不是那 700 次实验已经验证出的结论。因此这个案例不能证明“Graph 比 Loop 更强”。它真正提供的是一条很清楚的演进路线• **单目标优化结果可量化失败可回滚**先做一个带 Verifier、日志和停止条件的强 Loop• **多条实验路线要同时保留、比较和合并**再增加 commit DAG 或其他显式工作谱系• **多个 Agent 要协作又不能互相覆盖**增加分支隔离、调度、消息和合并规则• **事实要跨任务复用还要追溯来源**再考虑带 provenance 的长期存储或知识图谱。AutoResearch 证明的是“一个有外部评估、回滚和历史记录的 Loop 能跑得很远”AgentHub 与知识图谱展示的则是当一个 Loop 不够时Graph 应该外置哪些关系。两者不能被包装成同一场对照实验。从 Prompt 到 Graph没有哪一层真的死了回头看这五层会发现所谓“新概念”并不是五次推倒重来• Prompt 管表达• Context 管模型看见的材料• Harness 管工具、权限和运行环境• Loop 管一个工作单元如何根据反馈收敛• Graph 管多个工作单元怎样连接、传递状态和恢复。外层解决了更大范围的问题却仍然依赖内层。Graph 的节点需要 Harness、Context 和 Prompt很多节点内部仍然运行 Loop。Graph Engineering 真正带来的变化不是“让更多 Agent 组队”而是把跨节点的控制权、状态和失败语义从模型对话里拿出来变成可以测试的工程对象。但不是所有未知都值得提前画成边。已经知道路怎么走就别每到一个路口都花钱请模型开会。还不知道路在哪里也别先画一张 Graph再逼现实按图施工。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
![[C++]内存管理：串顺序存储的内存回收](http://pic.xiahunao.cn/yaotu/[C++]内存管理：串顺序存储的内存回收)
