从 Harness 引擎到 MetaSkill DAG 的确定性架构
核心观点：图真正的杠杆，不在于塞了多少个 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 Engineering | Skill Prompt 模板 | 一次调用怎么说 |
| 第二层 | Context Engineering | FractalMemory + 本体投影 | 这步该看什么 |
| 第三层 | Harness Engineering | Harness 引擎（工具与护栏） | 工具与护栏 |
| 第四层 | Loop Engineering | 单 Skill 的 Plan-Execute-Verify | 怎么持续推进 |
| 第五层 | Graph Engineering | MetaSkill 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 DAG
MetaSkill 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：只拿到干净的笔记，看不到杂乱的原始网页，产出简报。
- 审稿 Skill（
MetaClarifyValidator）：在一个全新的上下文里，只看简报和验收标准，不合格就打回给写作 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 的设计哲学。
欢迎大家扫描下面二维码成为我的客户，扶你上云
浙公网安备 33010602011771号