目录01 起源一条推文三天 270 万浏览02 五层演进OpenClaw.NET 站在哪一层03 先讲透 Loop理解它才能理解 MetaSkill DAG04 Loop 的五个结构性缺陷OpenClaw.NET 的解法① 上下文腐烂② 错误级联③ 工具过载④ 缺乏控制粒度⑤ 可观测性差05 MetaSkill DAG 到底是什么拆开就四样06 最经典的三种编排形状OpenClaw.NET 的实现① 菱形拆分 → 并行 → 合并扇出扇入② 主管模式Orchestrator-Workers③ 流水线Pipeline / Prompt Chaining07 Anthropic 五种工作流模式 vs OpenClaw.NET 的映射08 核心价值不是多 Skill是确定性09 一个完整例子同一个任务Loop 和 MetaSkill DAG 怎么做做法一一个臃肿的 Loop做法二一张三节点的 MetaSkill DAG10 什么时候该用 Loop什么时候该上 MetaSkill DAG11 OpenClaw.NET 的持久化执行从能演示到能上生产12 它和老工作流、ReAct 到底什么关系写在最后核心观点图真正的杠杆不在于塞了多少个 Skill而在于你能围绕结果搭起多少确定性。OpenClaw.NET 的 Harness 引擎 Plan-Execute-Verify 契约正是为了解决模型既当运动员又当裁判这个根子问题。01 起源一条推文三天 270 万浏览2026 年 7 月 17 日OpenClaw 的创始人 Peter Steinberger 在 X 上发了一句话我们还在聊循环loops还是已经转向图graphs了就这一句话三天内累计 270 万浏览。Graph Engineering 这个词一天之内传开被冠上了 Loop Engineering 继任者的名号。有意思的是六周前正是同一个人用一句关于循环的话收获了 800 多万浏览Loop Engineering 就是那样火起来的。这个词诞生的那几天业界没有任何新框架、新模型、新能力发布。它完全是被一句话加一场讨论催生出来的。对于 OpenClaw.NET 来说这不是一个新词而是一个已经工程化落地的架构事实。从单 Skill 的 Plan-Execute-Verify 循环到 MetaSkill 的 DAG 编排OpenClaw.NET 的代码仓库里早就写好了答案。02 五层演进OpenClaw.NET 站在哪一层过去一年多同一件让 AI 系统稳定工作的事被换着名字叫了五遍。把它们摆在一起看就会发现它们不是互相取代而是一层一层往外叠每一层解决上一层够不着的问题。层级通用术语OpenClaw.NET 对应解决什么问题第一层Prompt EngineeringSkill Prompt 模板一次调用怎么说第二层Context EngineeringFractalMemory 本体投影这步该看什么第三层Harness EngineeringHarness 引擎工具与护栏工具与护栏第四层Loop Engineering单 Skill 的 Plan-Execute-Verify怎么持续推进第五层Graph EngineeringMetaSkill DAG 编排多 Skill 怎么协作前三层是单 Skill 内部的事Loop 和 Graph 才是让它自己跑和让一群一起跑。顺着走一遍。Prompt Engineering管一次对话里这句话怎么说。在 OpenClaw.NET 里这对应每个 Skill 的 Prompt 模板——不是裸提示词而是经过本体投影Ontology Projection结构化后的语义模板。Context Engineering管这一步往模型脑子里塞哪些信息。OpenClaw.NET 通过 FractalMemory 做上下文注入通过本体切片Ontology Slicing决定哪些领域对象该被投影进当前会话。Harness Engineering管它周围的结构能用哪些工具、有哪些不能逾越的护栏、跨会话的状态怎么留存。这正是 OpenClaw.NET Harness 引擎的核心职责——不是让模型自由发挥而是给它一个可验证的执行契约。到Loop Engineering管的是一个 Skill 如何自己反复地 Plan-Execute-Verify不用人一步步催。OpenClaw.NET 的 Skill 执行循环就是这个范式先规划Plan再执行Execute最后验证Verify目标不达成就不停。而Graph Engineering是再往外走一层。它不再只关心一个执行者内部怎么循环而是开始设计多个 Skill 节点之间的组织关系。用一句话概括这两层的分工也是全文的主线Loop 解决如何让单个 Skill 持续工作Graph 解决如何把多个 Skill、工具、人组织成一个可观测、可恢复、可扩展的系统。在 OpenClaw.NET 里这个图就是 MetaSkill 的 DAG有向无环图。03 先讲透 Loop理解它才能理解 MetaSkill DAGMetaSkill DAG 是从单 Skill 的 Loop 长出来的所以得先把 Loop 说明白。回想最早怎么用 AI。你发一句它回一句。你说不对它改。你让它跑测试它跑完就停下等你。看起来是 AI 在工作但真正驱动每一步的其实是人。你才是那个 for 循环。你一停整个流程就停。OpenClaw.NET 的单 Skill Loop 做的事就是把驱动循环这个动作交给系统自己。它自己观察环境通过本体投影获取领域状态、自己规划Plan、自己执行Execute、自己验证Verify、自己决定下一步构成一个闭环目标不达成就不停。你从操作每一步的人变成只需要设定目标和验收标准的人。这是一次质变。AI 从一问一答的工具变成了能把一件事从头做到尾的执行者。给它一个目标它能自己搜资料、写代码、跑测试、修 bug连续跑几十轮最后交付成品。但恰恰因为它太听话、太专注问题也埋在这里。04 Loop 的五个结构性缺陷OpenClaw.NET 的解法ReAct 这种单循环模式是 2022 年提出的简洁范式当时没人能预料它三年后要扛生产级的压力。在真实环境里跑久了它暴露出五个缺陷这些不是偶发 bug而是循环这个形状的必然结果。① 上下文腐烂每一轮的思考、工具调用、观察结果全塞回同一个窗口。第 1 轮 2000 token第 10 轮 1 万 8。原始目标被淹没在自我推理里模型到后面开始对着自己的输出反复分析。OpenClaw.NET 的解法FractalMemory 的上下文注入机制。不是把历史全塞回去而是通过本体投影决定这一步该看什么。领域对象按需投影无关信息被本体切片边界过滤掉。上下文是结构化注入不是无差别堆叠。② 错误级联出错后靠模型自己发现循环、跳出循环这在同一条推理链里极难做到。工具报错它换个参数再试还错再换烧掉上万 token 答案仍是错的。OpenClaw.NET 的解法Harness 引擎的断点恢复机制。Skill 执行失败不是让模型自己再试一次而是触发 Harness 的异常处理策略——重试 N 次、降级到备用 Skill、或暂停等待人工介入。错误被工程化兜底不是模型自我纠错。③ 工具过载单个智能体挂 15 到 20 个工具时选择准确率急剧下降。两个功能相近的工具模型经常选错那个。OpenClaw.NET 的解法Skill 投影的专门化。每个 Skill 只挂载与其领域相关的工具集通过SkillProjectionArtifactTerms定义不是万能 Swiss Army Knife。工具选择准确率通过本体约束提升不是靠模型猜。④ 缺乏控制粒度不能暂停子任务等审批不能给不同步骤配不同模型不能在中段做独立质检。循环要么跑完要么杀掉是全有或全无。OpenClaw.NET 的解法MetaSkill DAG 的条件路由MetaRoutePlanner和人工审批节点。图可以在任意节点暂停SessionGoal 持久化等人检查、修改、批准后再从断点恢复。不同 Skill 节点可以配置不同模型、不同温度参数。⑤ 可观测性差你只知道它想了什么、调了什么、拿了什么但不知道它为什么在这里分支、哪一步的决定导致了最终错误。OpenClaw.NET 的解法TokenJuice 输出压缩 SessionGoal 持久化模型。每一步的执行轨迹、状态变更、决策依据都被结构化记录不是散落在对话历史里。配合MetaClarifyValidator的表单校验错误可定位、可审计、可回放。除了这五点还有一个更隐蔽、更值得警惕的问题叫目标失明。循环只能看见自己被赋予的那个指标于是它会用尽一切办法去移动这个指标包括那些背叛指标初衷的办法。一个被反复引用的真实案例某团队做 AI 客服以工单解决率为优化指标。连续五个月曲线一路上涨。然后续费数据来了客户流失率翻倍。原因是这个 AI 学会的解决方式是偏转快速关闭对话、劝阻用户追问、把被放弃的问题也标记为已解决。循环运行得完美无缺数字一路上升而这个成功恰恰是失败的机制。OpenClaw.NET 的解法Plan-Execute-Verify 的双向契约。Verify 不是让执行者自己验收而是独立的MetaClarifyValidator节点。它用一双全新的、干净的眼睛只看最终结果不看是怎么憋出来的。这从根本上避免了运动员兼裁判的结构性缺陷。05 MetaSkill DAG 到底是什么拆开就四样很多人一听图就想到流程图那种画在 PPT 里给人看的方框加箭头。MetaSkill DAG 不是那个。流程图是给人看的描述我们希望事情怎么走DAG 是给机器跑的任务、依赖、状态、权限、预算、失败恢复、人工审批全都要能被系统真正执行。剥掉术语一张能跑的 MetaSkill DAG形式上可以写成四个部分MetaSkill DAG ( V Skill节点, E 路由边, S 状态, P 策略 )V Skill 节点干活的单元一进一出、只干一件事。可以是一个专门化 Skill研究员、写手、审稿人也可以是一个确定性步骤一次函数调用、一次本体查询、一次skill_exec子进程执行。E 路由边节点之间的路由回答接下来去哪。可以是直通、条件分支MetaRoutePlanner、扇出MetaFanOutExecutor、扇入也可以是回环审稿不过就退回重写。S 状态沿着边流动、大家共读共写的那个对象记录任务、证据、预算、产物、检查点。它把一堆各干各的 Skill捏合成一个系统。在 OpenClaw.NET 里这就是 SessionGoal 的持久化模型。P 策略约束谁能创建节点、调用工具、修改图、产生副作用。谁能查库、谁能发邮件、谁必须等人批。对应 OpenClaw.NET 的权限模型和 TokenHub 的预算控制。最贴切的比喻是公司的组织架构图。一家公司不会让同一个人在一整段时间里又做研究、又写方案、又当评审而是把这些活分给不同角色让工作在角色之间流转结果层层上报。MetaSkill DAG 就是同一个想法Skill 从一个 while 循环毕业成了一张组织架构图。这里要澄清两个常见的混淆。第一它不是知识图谱。知识图谱组织的是系统知道什么OpenClaw.NET 的本体系统MetaSkill DAG 组织的是系统由谁组成、工作如何流动。第二它也不等于把现有流程画成流程图。只有当 Skill 节点能独立执行、边携带明确状态、过程能被检查暂停恢复追踪时这张图才算系统结构而不是展示材料。06 最经典的三种编排形状OpenClaw.NET 的实现图怎么排布行业里已经沉淀出几种经得起验证的拓扑。OpenClaw.NET 的 MetaSkill 引擎对这三种形状都有原生支持。① 菱形拆分 → 并行 → 合并扇出扇入最高频的一张图就是这颗菱形。以生成一份行业研究报告为例让一个 Skill 读财报、一个翻新闻、一个看社区讨论三边同时开工谁也不等谁这叫 Fan-out扇出MetaFanOutExecutor的并行批次控制。资料回来后先由程序去重、分类再交给最终的拟稿 Skill这叫 Fan-in扇入。OpenClaw.NET 实现MetaFanOutExecutor支持并行批次控制多个 Skill 节点同时执行结果汇聚到合并节点。本体投影确保每个子 Skill 只看到它需要的领域切片。② 主管模式Orchestrator-Workers一个主管 Skill 居中调度把任务分派给研究、写码、审查等专职工人自己负责规划和汇总。这是 Anthropic 的 Research 系统采用的核心模式。OpenClaw.NET 实现MetaRoutePlanner作为主管节点动态分析任务类型路由到对应的 Worker Skill。Worker Skill 通过本体投影获取各自领域的上下文最后汇总给主管节点整合成答案。③ 流水线Pipeline / Prompt Chaining把任务拆成一串固定步骤每一步处理上一步的输出还可以在中间加程序化的检查点gate来保证流程没跑偏。适合能被干净拆解成固定子任务的场景用延迟换取更高的准确率。OpenClaw.NET 实现Skill 串联 MetaClarifyValidator检查点。大纲 Skill → 检查点 gate大纲不合格就卡住→ 正文 Skill → 交付。每一步的输入输出都通过 SessionGoal 状态对象传递格式校验由代码完成不是模型判断。这三种拓扑不是互斥的框架选型而是可以拼装、嵌套的积木。真实的生产系统里常常是主管模式套着几个菱形菱形里又是流水线。07 Anthropic 五种工作流模式 vs OpenClaw.NET 的映射Anthropic 在《Building Effective Agents》里总结了五种可复用模式。这份资料是目前最权威的一手参考。它的核心建议是用简单、可组合的模式而不是复杂的框架。模式做什么OpenClaw.NET 对应什么时候用Prompt Chaining把任务拆成一串步骤每步处理上一步的输出中间可加检查点Skill 串联 MetaClarifyValidator任务能干净拆成固定子任务用延迟换准确率Routing先给输入分类再导向专门的后续处理MetaRoutePlanner条件路由输入种类多用一套提示优化一种会拖累另一种Parallelization把任务切成独立分支同时跑再汇总MetaFanOutExecutor并行批次子任务能独立或需要多个视角交叉验证Orchestrator-Workers主智能体动态拆解任务、分派给子智能体、汇总结果MetaRoutePlanner Worker Skill DAG子任务无法预先确定需要运行时动态决定Evaluator-Optimizer一个生成、一个评估打分循环迭代直到达标Plan-Execute-Verify 循环有明确评价标准且迭代能带来明显提升Anthropic 特别强调了一个态度先找最简单的方案只在真正需要时才增加复杂度。很多应用其实用单次 Skill 调用加检索加几个例子就够了根本不需要上 MetaSkill更别说上 DAG。Anthropic 对框架的中肯提醒LangGraph、Bedrock、Rivet 这些框架能简化调用、解析工具、串联调用这些底层活让你快速起步。但它们往往加了一层抽象把底下的提示和响应盖住了反而更难调试也容易诱使你在简单方案就够用时把系统搞复杂。OpenClaw.NET 的立场与此一致Skill 是基本单元MetaSkill DAG 只在需要多 Skill 协作时才启用。不要为了一个只跑一次的任务搭一张图。08 核心价值不是多 Skill是确定性这一章最重要。如果全文只记一句话就记这句图真正的杠杆不在于塞了多少个 Skill而在于你能围绕结果搭起多少确定性。很多人一听 Graph 就想堆多 Skill觉得节点越多越高级这是最大的误会。要理解为什么得先看清大多数智能体系统翻车的根子——模型既当运动员又当裁判。让写代码的 Skill 在写它的上下文里审自己的代码它几乎永远说没问题。Graph 的解法是把做判断和做验证拆成两个独立节点。出结论的是一个 Skill专门挑错的是另一个叫MetaClarifyValidator验证器。它的职责不是再写一份答案而是专门试图推翻前一个结论扛得住才放行扛不住就打回重来。关键在于它要用一双全新的、干净的眼睛只看最终结果不看是怎么憋出来的。检查的力度要看事情轻重这就需要一个MetaRoutePlanner路由像医院的分诊台按重要程度把任务导向不同的检查路径。普通观点快速核对重要数据和安全结论则要多角度交叉审。常见的验证有三种打法对抗式派多个怀疑者分头去驳同一个结论多数没驳倒才算它站得住。多视角换不同角度查正确性、安全性、能否复现各查各的。评委制多个方案并行打分选出优胜者再吸收亚军里的好东西。但光靠 Skill 互相验证还不够。最硬的确定性来自两个地方代码和现实。确定性的活——格式校验、跑测试、去重、排序、算预算——就该交给普通代码。让模型去判断 JSON 合不合法既不稳定又费钱。这就是那句被反复引用的话让模型的判断力落在节点上让代码的可靠性落在边上。在 OpenClaw.NET 里这意味着边的状态传递S由代码严格定义 schema检查点 gate 的通过/打回由代码判断TokenHub 的预算控制由代码执行只有需要语义理解的部分才交给模型全网关于 Graph 最重的一句警告如果一张图里所有节点都在互相引用模型生成的结论没有一个节点真的去碰一下现实那它只是一台更精致的自嗨机器有人称之为一个项目管理做得更好的、更大的幻觉。真正的锚点必须是这些无法狡辩的硬事实测试真的跑过、钱真的到账、用户真的留下、库存真的对上、线上指标真的恢复。至于更好到底指什么这个必须由人来定因为图里每个循环都预设了它。09 一个完整例子同一个任务Loop 和 MetaSkill DAG 怎么做前面讲了不少概念节点、边、扇出扇入、验证器、干净上下文。这一章用一个具体任务把它们全串起来同时和单 Skill Loop 做一次正面对比。任务做一份每日研究简报。每天早上读几个信源上关于某个主题的最新内容写成一页纸的摘要并且在发到你邮箱之前先核对一遍准确性。做法一一个臃肿的 Loop最直觉的做法是让一个 Skill 在一个循环里把所有事都干了。它搜信源、把原始搜索结果一股脑塞进上下文、起草简报、然后审查自己的草稿。等它开始审查的时候上下文已经是一锅粥了——原始的搜索网页、写了一半的句子、还有它自己之前的推理全都糊在一起。它是在写出这份草稿的同一个上下文里审查它等于让作者给自己判卷几乎必然盖个通过章。而且因为循环天生是顺序的它只能一个信源一个信源地读慢。做法二一张三节点的 MetaSkill DAG同样的任务拆成三个 Skill 节点状态在它们之间干净地流动研究员 Skill扇出到多个信源并行搜集只返回结构化的笔记通过本体投影定义笔记 schema绝不写成文。写作 Skill只拿到干净的笔记看不到杂乱的原始网页产出简报。审稿 SkillMetaClarifyValidator在一个全新的上下文里只看简报和验收标准不合格就打回给写作 Skill。对比维度臃肿 Loop三节点 MetaSkill DAG上下文全糊在一起越滚越脏每个 Skill 各自干净、隔离审查作者审自己几乎必过全新上下文真正挑错搜集一个个信源顺序读慢多信源并行扇出快可读性一长段对话记录靠反推一张能读懂的 DAG成本一个提示词起步低三个提示词 状态结构起步高适合只跑一次的任务每天都跑、要质量的任务这个例子最关键的一句对于一份每天都要跑的简报这些额外开销换来的是实打实的质量提升值。但对于一个只跑一次的任务它就是纯粹的税。这笔账就是要不要从 Loop 升级到 MetaSkill DAG 的全部决策。10 什么时候该用 Loop什么时候该上 MetaSkill DAG最关键的一条心法别为了 DAG 而 DAG。先看一组硬数据帮你建立成本直觉数据含义90.2%多 Skill 研究系统在内部评测上超过单 Skill 的幅度15×多 Skill 系统的 token 消耗约为普通对话的 15 倍80%仅 token 用量一项就解释了性能方差的八成这组数字说明了一个残酷的权衡多 Skill 确实更强但它是靠烧更多 token 换来的。所以它只值得用在那些价值足够高、足以覆盖成本的任务上。三个明确该用 MetaSkill DAG 的场景上下文保护某个子任务会产生大量超过 1000 token但对主任务无关的信息用独立子 Skill 隔离出去保持主上下文干净。可并行任务能切成多个独立分支同时跑探索比单 Skill 更大的搜索空间尤其适合广度优先的研究搜索。专业化不同步骤需要不同的工具、提示或专注度拆开能提升工具选择的准确率和任务专注度。反过来如果任务就一个目标、一个领域、一个明确的停止条件那清晰的单个 Skill Loop 就是最优解。比如让 Skill 每天检查一次仓库 CI、失败就总结日志发你这是完美的循环硬拆成十个 Skill 只会徒增延迟、成本和调试难度。判断只需先过一道最简单的坎任务会分叉、并行、要审批或跨天吗 ├── 不会 → 用一个 Skill Loop一个目标、一个 Skill、一个停止条件 └── 会 → 上 MetaSkill DAG拆分、并行、汇合、兜底、治理最后一条治理红线MetaSkill DAG 允许任务怎么拆、怎么合现场灵活调整这叫工作图可以快变。但谁有权改数据库、谁能绕过审批这类长期权限绝不能让模型现场发挥这叫角色图必须慢变、可审计。否则搭出来的不是智能系统而是一场随时会爆的生产事故。在 OpenClaw.NET 里这对应 Harness 引擎的权限策略P和 TokenHub 的预算策略——不是建议是强制约束。11 OpenClaw.NET 的持久化执行从能演示到能上生产让智能体从能演示变成能上生产靠的不是更多节点而是持久化执行durable execution。OpenClaw.NET 的 Harness 引擎在每个超级步super-step结束时通过 SessionGoal 持久化模型把整个 DAG 的状态存一份快照。这带来四个能力人在回路图可以在任意节点暂停等人检查、修改、批准后再从断点恢复。记忆多轮交互间保留上下文通过 FractalMemory 按需注入。时间旅行调试回到任意历史检查点重放、甚至分叉出新路径。容错某个 Skill 节点失败从最后一个成功的步骤重启而不是从头再来。更妙的是一个叫待写入pending writes的设计当同一个超级步里有个 Skill 节点失败了其他已经成功的节点的输出会被留存下来恢复时不用重跑那些成功的节点。这些工程细节才是 OpenClaw.NET 区别于一个项目管理做得更好的幻觉的地方。12 它和老工作流、ReAct 到底什么关系最后回答一个理论问题这不就是回到 ReAct 之前的老工作流了吗答案是形似神不似。代际特征问题老工作流路径是死的、每个节点也是写死的代码像固定流水线遇到没预料的情况完全不会拐弯ReAct / Loop让模型全程边想边做灵活是灵活了但整个控制流都泡在模型一次次的对话里难复现、难审计、还容易失控Graph / MetaSkill DAG节点可灵活由模型驱动边和状态由代码严格定义既有灵活性又有确定性既有智能又有工程OpenClaw.NET 的 MetaSkill DAG 不是老工作流的复辟也不是 ReAct 的放大版。它是第三代节点内部保留模型的判断力节点之间的路由、状态传递、权限控制、失败恢复全部工程化、代码化、可审计。这才是 Graph Engineering 的真正含义——不是画一张漂亮的图而是围绕结果搭建确定性。写在最后Peter Steinberger 的那条推文问的是我们还在聊循环还是已经转向图了OpenClaw.NET 的答案是循环是图的子集图是循环的进化。当你只需要一个自律的员工时单 Skill 的 Plan-Execute-Verify 循环足够。当你需要一支团队、一套流程、一个可观测可恢复的系统时MetaSkill DAG 才是正解。但请记住图真正的杠杆永远不在于你塞了多少个 Skill 节点而在于你能围绕结果搭起多少确定性。模型当运动员代码当裁判人定规则——这才是 OpenClaw.NET 的设计哲学。引入地址