skill-to-workflow

Skill 转 Workflow

把一个面向 Agent 的 Skill 转换为可实现的 Workflow 规格。转换的目标不是照抄原文中的编号，而是恢复它的真实执行图，并让每个节点都具有明确责任、结构化输入输出、工具权限、停止条件和失败处理。

输入与默认交付

• 输入可以是 Skill 目录、SKILL.md、Prompt、SOP、操作手册或用户描述的 Agent 流程。
• 用户指定目标平台时，使用该平台支持的节点、变量、分支和子工作流能力；未指定时输出平台无关规格，不猜测 Dify、Coze、n8n、LangGraph 等具体实现。
• 用户只要求概括时，先给阶段数、主链路和关键回路；用户要求设计或转换时，再给完整节点规格。
• 未明确要求实现、创建文件或部署时，只交付设计，不修改原 Skill，也不创建平台配置。

需要输出完整 Workflow 规格时，读取 references/workflow-spec-template.md。

开始前

1. 完整读取源 Skill 及其声明的必读 references；不要只根据 SKILL.md 的表层编号拆解。
2. 检查源 Skill 使用的 scripts、schema、模板、校验器和正式产物路径。只需读取会改变流程设计的资源。
3. 区分三类信息：
   • 业务语义与判断规则；
   • 执行机制与工具操作；
   • 输出格式与验收约束。
4. 记录原 Skill 的授权边界、隐私边界、禁止事项和不可破坏的事实来源。
5. 不执行源 Skill 的业务任务，除非用户同时要求运行或验证转换后的 Workflow。

转换流程

1. 建立源 Skill 契约

提取：

• 触发条件与不适用范围；
• 必需输入、可选输入和输入选择规则；
• 最终产物及其消费者；
• 事实来源、数据契约和质量门槛；
• 禁止行为、权限限制和人工确认点；
• 可复用历史产物与幂等要求。

这些约束必须在 Workflow 中找到承接位置，不能因拆节点而消失。

2. 恢复真实执行图

不要把原文的“七步”机械转换成七个节点。先识别：

• 批次级步骤与单对象循环；
• 串行依赖和可并行任务；
• 条件分支、回退、补充调研和重试；
• 阻断失败、允许继续的部分完成和正常空结果；
• 中间分析状态与正式交付物。

用一句主链路和必要的回路表示真实执行图，再决定节点数量。

3. 划分节点

一个节点应完成一种稳定责任，并产生可验证的状态变化。满足任一条件时优先拆开：

• 判断依据、工具权限或失败策略不同；
• 结果需要单独缓存、复用、人工检查或重试；
• 下游只依赖其中一部分输出；
• 确定性处理与模型判断混在一起；
• 一个节点同时在找事实、做业务判断、评分和写最终报告。

不要拆分纯粹的格式搬运、无法独立验收的思维碎片，或只会增加上下文传递成本的微小步骤。

4. 给节点分类

为每个节点选择主要执行类型：

• **确定性节点：**解析、清洗、计算、字段映射、文件生成、Schema 校验；优先使用代码或平台原生节点。
• **LLM 判断节点：**分类、推理、提炼、取舍和结构化写作；必须约束输入证据与输出 Schema。
• **工具节点：**搜索、网页读取、数据库查询、API 调用或文件解析；只授予本节点需要的工具。
• **人工节点：**需要业务授权、主观定案或高风险外部变更时使用。
• **路由节点：**根据显式状态或规则选择下一步，不承担额外业务分析。

能由确定性逻辑可靠完成的计算、组装和校验，不交给 LLM。

5. 抽取共享能力子工作流

当两个或以上节点重复使用同一种外部机制，并且能够形成稳定输入输出契约时，将机制抽成共享子工作流。例如：

• 搜索规划 → Web Search → URL 去重 → Web Open → 证据提取；
• 文件解析 → 格式规范化 → 字段质量检查；
• 结构化产物组装 → 构建 → 正式校验；
• 通知发送、审批或外部系统写入。

分析节点只提交“需要回答什么”，共享子工作流负责“如何调用工具并返回材料”。共享的是获取或处理机制，不是不同节点的业务结论。

共享子工作流至少定义：请求类型、问题或目标、已知上下文、工具与来源偏好、预算、停止条件、返回数据、未解决问题、限制、缓存键和错误状态。

不要在以下情况强行抽象：

• 只有工具名称相同，但输入语义、权限或失败风险完全不同；
• 共用后会让子工作流直接替业务节点作结论；
• 一次性操作没有稳定复用价值；
• 抽象会隐藏人工授权或高风险副作用。