WorkBuddy 专家团的下一步：用 MetaSkill 把「提示词约定」升级为「运行时硬约束」

从「主 Skill 当团长」到「YAML 声明式 DAG」------同一套多 Agent 编排思想，两种工程实现，效果差在哪里。

一、WorkBuddy 专家团做对了什么

最近在读《一个人活成一家公司：WorkBuddy 专家团 + 数字员工完全指南（终章）》，这篇重度玩家篇把一件事讲得很透：

复杂工作不能靠一个长提示词驱动，需要显式的编排结构。

它的「专家团」模型是：

一个主 Skill 当团长，挂多个子 Skill，按工作流串联（选题 → 素材 → 初稿 → 校对 → 发布）；
用 Rule 定义「怎么想」：拆问题、分方向、定产出格式、定收敛条件；
用 Subagent 并行执行，配工具调用预算；
超时熔断写进 Rule：「若任一 subagent 超过 3 分钟未返回，终止并标记跳过」；
断点续传靠手写 state_stepX.json 落盘，崩溃后从 next_step 恢复。

这套设计在方向上完全正确------它本质上已经是一个 DAG 工作流了：有步骤、有依赖、有并行、有降级、有检查点。

但问题也在这里：专家团的这一切，都是写在提示词里的「约定」，而不是运行时里的「约束」。

而这恰恰是 GoodCrew 数字员工平台基于 OpenClaw.NET MetaSkill 做得更好的地方：同样的编排思想，下沉为 YAML 声明式 DAG，由 .NET 运行时强制执行。

二、关键区分：约定靠自觉，约束靠引擎

WorkBuddy 专家团的 Rule 里写着「超时 3 分钟就终止」。这句话由谁来执行？由模型自己。 模型既是运动员又是裁判------上下文一长、任务一复杂，「自觉」就会打折扣。

MetaSkill 的思路不同：编排逻辑不是提示词，而是 YAML 声明的 DAG，执行前先过一遍解析时校验：

步骤 ID 唯一性、Kind 有效性、依赖引用完整性；
无环校验（DAG 不允许循环依赖）；
on_failure 五条工程约束（fallback 不能自引用、禁止链式降级、不能带 depends_on 等）；
Route 条件路由的八项目标检查。

校验不通过，0 次 API 调用，一分钱不花。 这是提示词约定永远做不到的事------提示词只能在花完钱之后告诉你它没遵守。

三、逐项映射：专家团机制 → MetaSkill 原语

WorkBuddy 专家团	实现方式	MetaSkill 对应物	效果差异
主 Skill 团长 + 子 Skill	提示词串联	`kind: meta` 的 `composition.steps`，`agent` 步骤委托子 Skill	依赖关系由 `depends_on` 声明，运行时调度，不靠模型记住顺序
Rule（怎么想）	自然语言规则	YAML 声明 + `routes` 条件路由 + `llm_classify` 路由分类器	路由是闭集合标签的硬输出，不是「建议」
超时熔断	写进 Rule 的提示词	4 层超时保护（step / retry / session contract / agent loop）+ `on_failure` 降级	超时由运行时掐断，降级输出镜像到主步骤 ID，下游无感知
断点续传	手写 `state_stepX.json`	`MetaExecutionCheckpoint` + `TryRestoreMetaExecutionCheckpoint` 自动恢复	已完成步骤零重跑，无需手工维护状态文件格式
并行化	「不用刻意追求」	`fan_out` 动态展开 + 波次调度（同 wave 内并行）+ `fan_out_max_concurrency` 限流	并行是声明出来的，并发度可控
审计追溯	依赖人工复盘习惯	`SessionMetaRunRecord` 持久化：每步耗时、失败码、执行证据，CLI 可 `replay` / `reconstruct`	审计是系统能力，不是使用习惯
责任边界 / 人工拍板	管理约定（「法务只做初筛」）	`user_input` 原生暂停点：流程挂起等人工输入，恢复时从断点继续	「必须人来拍板」是流程结构的一部分，绕不过去
权限管控	未覆盖	三步安全门禁：`tool_allowlist` + `capabilities` + `MetaSkill.Enabled`	每个 Skill 能碰什么工具，解析期就锁死
多 Agent 成本	积分消耗为单专家的 3--5 倍	步骤级成本分层：`llm_classify` / `tool_call` 不走 LLM 生成，`llm_chat` 有界生成，只有 `agent` 步骤满成本	路由和确定性步骤几乎零 Token，编排不再等于烧钱

四、三个「更好效果」的具体战场

4.1 可靠性：熔断从「请求」变成「机制」

专家团的降级策略是三行提示词：网页抓取失败 → 用本地素材；API 超时 → 用缓存；模型失败 → 换便宜模型重试。思路完全正确，但执行者是模型自己。

MetaSkill 里，这是 on_failure 声明的替代步骤。主步骤失败时，运行时激活 fallback，并把 fallback 的输出镜像到主步骤的 ID 槽位------下游步骤根本不知道发生过降级。配合五条工程约束在解析期就堵死「降级链雪崩」（fallback 不能再有 fallback），可靠性是被结构保证的，不是被提示词祈求的。

4.2 成本：编排不等于烧钱

专家团的痛点写得很坦白：多 Agent 协作积分消耗是单专家的 3--5 倍，所以「简单任务不要一上来拉一支队伍」。

MetaSkill 的六种步骤类型本质上是一个成本光谱：

步骤类型	是否走 LLM	成本	典型用途
`llm_classify`	是（闭集合标签）	最低	路由分类：先分类，再决定走哪条分支
`tool_call`	否	最低	确定性副作用：读写文件、调 API
`skill_exec`	子进程	低	CLI 包装的执行
`llm_chat`	是（有界）	低	有界综合
`agent`	是（完整工具访问）	最高	开放式推理，只在真正需要的步骤用
`user_input`	否	暂停开销	人工检查点

一支「专家团」里，真正需要满血推理的往往只有两三步。把分类、抓取、格式化从 LLM 步骤里剥离出来，同样一支队伍的 Token 成本可以降一个数量级。

4.3 企业级：权限、审计、责任边界是内建的

WorkBuddy 终章列的企业级关注点------权限、审计、复核、责任边界------目前主要靠管理约定和使用习惯。MetaSkill 把它们变成了运行时能力：

权限：tool_allowlist + capabilities 三步门禁，每个 Skill 的工具触达面在加载期锁定；
审计：每次执行落 SessionMetaRunRecord，openclaw skills meta-runs replay/reconstruct 可回放重建任意一次运行；
复核：user_input 暂停点就是「必须人来拍板」的结构化实现------合同初筛完，流程挂起，人确认后才进入签署建议步骤。

「法务数字员工只做初筛不做最终判断」，在专家团里是一句叮嘱；在 MetaSkill 里是 DAG 的一个节点形状。

五、实战：把「内容运营专家团」重写成 MetaSkill

原文的专家团案例是「选题 → 素材 → 初稿 → 校对 → 发布」。用 MetaSkill 表达，大致长这样：

yaml 复制代码

name: content-ops-team
kind: meta
composition:
  steps:
    # 选题：有界 LLM 生成，低成本
    - id: topic
      kind: llm_chat
      with:
        instruction: "基于 {{ input }} 生成 3 个选题，含标题与角度"

    # 素材搜集：fan_out 并行三路，限流 3，失败自动降级到本地素材库
    - id: gather
      kind: fan_out
      iterable: "['行业动态', '竞品情报', '用户反馈']"
      fan_out_max_concurrency: 3
      depends_on: [topic]
      fan_out_template:
        kind: agent
        with:
          skill: web-researcher
          instruction: "围绕选题搜集 {{ item }} 素材"
      on_failure: gather_local_fallback

    - id: gather_local_fallback
      kind: tool_call
      with:
        tool: local_material_search
        args: { query: "{{ outputs.topic }}" }

    # 初稿 + 校对：串行，校对输出结构化验收报告
    - id: draft
      kind: agent
      depends_on: [gather]
      with:
        skill: copywriter
        instruction: "基于素材撰写初稿：{{ outputs.gather }}"

    - id: review
      kind: llm_chat
      depends_on: [draft]
      with:
        instruction: "按验收清单校对 {{ outputs.draft }}，输出 通过/修改 结论"

    # 发布前必须人工拍板------这是 DAG 的形状，不是一句叮嘱
    - id: human_gate
      kind: user_input
      depends_on: [review]
      with:
        prompt: "校对结论：{{ outputs.review }}。确认发布？"

    - id: publish
      kind: tool_call
      depends_on: [human_gate]
      with:
        tool: wechat_publish
        args: { content: "{{ outputs.draft }}" }

对照原文的五步实操，变化在于：

**「擅长的自己造」**不变------子 Skill 照旧沉淀领域经验；
**「组装专家团」**从把流程写进团长的提示词，变成声明一张 DAG------依赖、并行、降级、人工门禁各就各位；
「迭代优化」 有了抓手：每次运行的 SessionMetaRunRecord 告诉你哪一步慢、哪一步败、败在什么码上，调优从玄学变成数据。

六、公平地说：什么时候专家团够用，什么时候该上 MetaSkill

场景	推荐
探索期、一次性任务、流程还没定型	专家团：提示词迭代快，改一句话就生效
非技术用户、个人效率场景	专家团：零 YAML 门槛，大白话就能搭
流程已稳定、每天重复跑	MetaSkill：声明一次，运行时保证每次都一样
无人值守自动化、出错要可追溯	MetaSkill：checkpoint + 持久化审计 + CLI 回放
企业级落地，要权限/复核/责任边界	MetaSkill ：门禁 + `user_input` + 审计记录是内建能力
成本敏感的长链路编排	MetaSkill：步骤级成本分层，分类和确定性步骤不烧 Token

一句话：专家团是验证流程的最快方式，MetaSkill 是流程验证通过后的正确归宿。 这也正好接上 WorkBuddy 自己的心法------「先跑通，再自动化」；我们想补后半句：自动化之后，把约定升级成约束。

七、结语

WorkBuddy 专家团的终章标题叫「系统自己转」。这个愿景完全正确，而让它真正转得稳、转得省、转得可审计的，是编排从提示词层下沉到运行时层的那一步。

从「主 Skill 当团长」到「YAML 声明式 DAG」，不是推翻，而是接力：

复杂 AI 工作流需要显式的编排结构------这是共识。区别只在于，这个结构是模型要记得的约定，还是引擎要执行的约束。

GoodCrew 数字员工平台基于 OpenClaw.NET 的 MetaSkill 体系，正在把后者做成开箱即用的生产力：数字员工的每一条工作流，都是一张可校验、可降级、可暂停、可回放的有向无环图。

一个人活成一家公司，靠的不是更多叮嘱，而是更硬的结构。