从 Harness 引擎到 MetaSkill DAG 的确定性架构 - 张善友
内容提要
OpenClaw.NET提出Graph Engineering，通过MetaSkill DAG编排多Skill节点，解决单循环中的上下文膨胀、错误难纠和工具选择不准问题。其核心是Plan-Execute-Verify契约，独立验证器避免“运动员兼裁判”，代码负责确定性，模型负责判断。该方法适用于复杂任务，简单任务仍用单Skill Loop，强调围绕结果构建确定性。
延伸解读
从循环到图：不是取代，而是分层
文章指出，Prompt、Context、Harness、Loop、Graph 这五个概念并非互相取代，而是一层层往外叠，每一层解决上一层够不着的问题。前三层属于单个 Skill 内部，Loop 解决单个 Skill 持续工作，Graph 解决多个 Skill 的组织。理解这个分层，有助于避免盲目追逐新概念，而是根据任务复杂度选择合适的层级。
独立验证器：避免“运动员兼裁判”
文章强调，单循环中模型自己执行又自己验证，容易产生“目标失明”和自欺欺人。OpenClaw.NET 通过独立的 MetaClarifyValidator 节点，用全新的眼睛只看最终结果，不看过程，从而避免结构性缺陷。这种设计思路提醒我们，在 AI 系统中，验证环节应独立于执行环节，才能保证可靠性。
成本与收益：何时该用 DAG
文章给出硬数据：单 Skill 循环约 5k token，MetaSkill DAG 约 50k token，成本相差 10 倍。因此，DAG 只适用于高价值、复杂、需要并行或审批的任务；简单任务用单 Skill Loop 更优。判断标准是任务是否会分叉、并行、要审批或跨天。这提醒我们，不要为了用 DAG 而用 DAG，要权衡成本与收益。
治理红线：工作图可快变，角色图必须慢变
文章提出一条治理红线：任务怎么拆、怎么合（工作图）可以灵活调整，但谁有权改数据库、谁能绕过审批（角色图）必须慢变、可审计。否则容易引发生产事故。这提醒我们，在 AI 系统中，权限和审批等长期策略必须由人设定并强制约束，不能让模型现场发挥。
Q&A
OpenClaw.NET 的 MetaSkill DAG 是什么？
MetaSkill DAG 是 OpenClaw.NET 中用于编排多个 Skill 节点的有向无环图，它定义了 Skill 节点之间的依赖关系、状态传递和策略控制，使得多个 Skill 可以协同工作，形成一个可观测、可恢复、可扩展的系统。
单 Skill Loop 存在哪些缺陷？
单 Skill Loop 存在五个主要缺陷：上下文膨胀、错误难以纠正、工具选择不准、无法暂停和审批、缺乏可观测性。这些缺陷源于循环结构本身，导致模型在长任务中容易迷失、错误累积、工具选择准确率下降，且无法进行人工干预和审计。
OpenClaw.NET 如何解决上下文膨胀问题？
OpenClaw.NET 通过 FractalMemory 的上下文注入机制解决上下文膨胀问题。它利用本体投影（Ontology Projection）决定每一步需要哪些领域对象，并通过本体切片（Ontology Slicing）过滤无关信息，实现结构化注入，而不是无差别堆叠历史。
什么是 Plan-Execute-Verify 契约？
Plan-Execute-Verify 契约是 OpenClaw.NET 的核心执行模式，它要求每个 Skill 先规划（Plan），再执行（Execute），最后验证（Verify）。验证由独立的 MetaClarifyValidator 节点完成，避免模型既当运动员又当裁判，确保结果可靠。
MetaSkill DAG 的常见拓扑有哪些？
MetaSkill DAG 的常见拓扑有三种：扇出/扇入（Fan-out/Fan-in）、主管/工人（Supervisor/Worker）和流水线（Pipeline）。扇出/扇入用于并行处理，主管模式用于任务分派，流水线用于固定步骤的串行处理。
什么情况下应该使用 MetaSkill DAG 而不是单 Skill Loop？
当任务需要分叉、并行、审批或跨天执行时，应该使用 MetaSkill DAG。如果任务只有一个目标、一个领域、一个明确的停止条件，则单 Skill Loop 更合适。判断标准是任务是否会分叉、并行、要审批或跨天。
OpenClaw.NET 如何实现持久化执行？
OpenClaw.NET 通过 Harness 引擎在每个超级步结束时，使用 SessionGoal 持久化模型保存整个 DAG 的状态快照。这提供了暂停/恢复、断点续跑、审计追踪和待写入（pending writes）等能力，确保执行的可恢复性和可靠性。
MetaSkill DAG 与老工作流有何区别？
MetaSkill DAG 不是老工作流的复辟，而是第三代架构。它保留了节点内部的模型判断力，但节点之间的路由、状态传递、权限控制、失败恢复全部工程化、代码化、可审计。它结合了 ReAct 的灵活性和传统工作流的确定性。
