本文介绍了AI Agent领域中的五个工程阶段Prompt、Context、Harness、Loop和Graph解释了它们各自的功能和区别。文章指出这些阶段并非淘汰赛而是控制边界不断扩大的过程。作者探讨了Loop和Graph的区别并建议在适当的时候使用Graph来管理复杂的任务。最后文章通过Karpathy的AutoResearch案例展示了强Loop的价值和Graph的潜力。这几天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 也可以全部塞进一个 LoopGraph 不等于并行。 并行只是某些边的执行方式隐藏依赖没处理好只会更快地产生错误用了 LangGraph 不等于完成 Graph Engineering。 框架提供运行时不替你决定节点怎么拆、状态怎么建模、Verifier 是否可信。这不就是以前的 Workflow Agent 和 LangGraph 吗是而且不是“有一点像”而是同一条技术谱系。LangChain 在 2026 年 7 月发布的《3 Years of Graph Engineering with LangGraph》里说得很直接把 Agent 系统表示成 Graph 并不是新发明LangGraph 已经围绕这件事做了三年。LangGraph 官方对自己的核心抽象也一直是三样东西State当前系统状态Node执行工作的函数、模型调用、工具或完整 AgentEdge决定下一步执行哪个节点的固定或条件转移。它还提供 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不应该从“先画一张巨大的流程图”开始。更安全的顺序是1. 先记录路线。 统计 Agent 实际调用了哪些工具、在哪失败、哪些步骤每次都会出现。2. 把状态移出 transcript。 先保存任务 ID、阶段、产物、预算和错误不急着拆很多节点。3. 提取稳定节点。 只把重复出现、输入输出清楚的步骤外置。4. 增加机械 Judge。 没有可信验收时不要先扩并行和自动重试。5. 写明失败边。 区分可重试错误、永久失败、预算耗尽和人工接管。6. 确认独立后再并行。 先证明分支独立再做 fan-out / join。7. 保留探索节点。 不确定的部分继续由 Loop 处理不强迫整套系统都确定化。实际得到的往往不是一张纯 Graph而是一套混合结构外层 Graph 负责预算、状态、恢复、审批和证据内层 Loop 负责阅读新观察、调用工具和调整局部计划。一个真实案例Karpathy 的 Loop 跑了约 700 次以后真正跑过约 700 次的是 AutoResearch2026 年 3 月Karpathy 公开了 AutoResearch让一个 Coding Agent 自动修改一个小型语言模型训练程序执行训练再根据验证指标决定保留还是回滚。它的结构并不复杂1. Agent 阅读任务说明和当前train.py2. 提出一个改动并提交3. 用固定约 5 分钟的训练预算运行实验4. 读取val_bpb指标5. 指标变好就保留没变好或崩溃就回滚6. 把结果写进results.tsv继续下一轮。Karpathy 后来总结说这套 Loop 在大约两天内尝试了约 700 次改动其中约 20 项改善被保留下来而且可以叠加、迁移到更大Karpathy 还公开过 AgentHub 构想多个 Agent 围绕同一个仓库在不同分支上工作通过提交图和留言板协作。它展示的是一张“工作谱系图”——哪个实验从哪个提交分叉、由谁完成、指标如何、能否合并。Karpathy 分享的这份 11 页 Graph Engineering PDF又把 AutoResearch、AgentHub、Anthropic 的 Agent 模式与知识图谱串在一起。它提出的核心路线是先让一个 Loop 能被测量和回滚再逐步增加工具、计划、多 Agent、持久图谱和大规模并行。PDF 首页和最后一页已经把边界写得很清楚它是基于公开仓库、课程、演讲和 Anthropic 资料整理的独立汇编不隶属于 Karpathy 或 Anthropic也没有获得双方背书。这份 PDF 真正有用的是把架构演进拆成了六个阶段1. Day 1可测量的 Loop。 保存每版产物用明确标准评估失败后修改并设置停止条件。2. Day 2增加工具。 只针对已经观察到的错误类型增加搜索、代码执行、数据库或文件工具。3. Week 1增加计划。 只有任务路径会变化时才生成计划并验证依赖、限制重试与总成本。4. Week 2进入多 Agent。 用角色分工、结构化交付物和 worktree 隔离解决并行协作而不是只增加聊天窗口。5. Month 1接入持久图谱。 保存实体、主张、来源、关系、产物、运行与评估让每条边都能追溯来源。6. 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 由于新岗位的生产效率要优于被取代岗位的生产效率所以实际上整个社会的生产效率是提升的。但是具体到个人只能说是“最先掌握AI的人将会比较晚掌握AI的人有竞争优势”。这句话放在计算机、互联网、移动互联网的开局时期都是一样的道理。我在一线科技企业深耕十二载见证过太多因技术卡位而跃迁的案例。那些率先拥抱 AI 的同事早已在效率与薪资上形成代际优势我意识到有很多经验和知识值得分享给大家也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。我们整理出这套AI 大模型突围资料包✅ 从零到一的 AI 学习路径图✅ 大模型调优实战手册附医疗/金融等大厂真实案例✅ 百度/阿里专家闭门录播课✅ 大模型当下最新行业报告✅ 真实大厂面试真题✅ 2026 最新岗位需求图谱所有资料 ⚡️ 朋友们如果有需要《AI大模型入门进阶学习资源包》下方扫码获取~① 全套AI大模型应用开发视频教程包含提示工程、RAG、LangChain、Agent、模型微调与部署、DeepSeek等技术点② 大模型系统化学习路线作为学习AI大模型技术的新手方向至关重要。 正确的学习路线可以为你节省时间少走弯路方向不对努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划带你从零基础入门到精通③ 大模型学习书籍文档学习AI大模型离不开书籍文档我精选了一系列大模型技术的书籍和学习文档电子版它们由领域内的顶尖专家撰写内容全面、深入、详尽为你学习大模型提供坚实的理论基础。④ AI大模型最新行业报告2025最新行业报告针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估以了解哪些行业更适合引入大模型的技术和应用以及在哪些方面可以发挥大模型的优势。⑤ 大模型项目实战配套源码学以致用在项目实战中检验和巩固你所学到的知识同时为你找工作就业和职业发展打下坚实的基础。⑥ 大模型大厂面试真题面试不仅是技术的较量更需要充分的准备。在你已经掌握了大模型技术之后就需要开始准备面试我精心整理了一份大模型面试题库涵盖当前面试中可能遇到的各种技术问题让你在面试中游刃有余。以上资料如何领取为什么大家都在学大模型最近科技巨头英特尔宣布裁员2万人传统岗位不断缩减但AI相关技术岗疯狂扩招有3-5年经验大厂薪资就能给到50K*20薪不出1年“有AI项目经验”将成为投递简历的门槛。风口之下与其像“温水煮青蛙”一样坐等被行业淘汰不如先人一步掌握AI大模型原理应用技术项目实操经验“顺风”翻盘这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。以上全套大模型资料如何领取