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 → 证据提取；
• 文件解析 → 格式规范化 → 字段质量检查；
• 结构化产物组装 → 构建 → 正式校验；
• 通知发送、审批或外部系统写入。

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

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

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

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

6. 设计状态与数据契约

优先传递结构化状态，不把自然语言报告当作节点间接口。至少区分：

• 原始输入；
• 规范化输入；
• 来源或证据账本；
• 中间判断与置信度；
• 限制和未解决问题；
• 正式产物；
• 运行状态与错误。

推荐基础状态为 complete | partial | failed，但应按业务语义补充 skipped、needs_human 或其他状态。正常空结果不能误判为失败。

每个节点的输出只能包含下游需要的数据。Workflow 内部字段在生成正式产物前必须过滤，不得污染原 Skill 的正式 Schema。

7. 设计提示词

采用“共享约束 + 节点任务”的提示词结构：

• 共享 System Prompt 保存事实边界、来源规则、禁止事项、表达与结构化输出要求；
• 节点 Prompt 只说明本节点目标、输入变量、判断顺序、输出字段和停止条件；
• 工具调用策略放在工具节点或共享子工作流，不让每个业务节点重复维护；
• 输出使用 JSON Schema 或平台结构化输出，不依赖模型自觉遵守自然语言格式。

提示词必须说明：哪些是事实、哪些允许有限推断、证据不足如何处理、不得新增什么、何时停止。评分节点只能消费已建立的证据，不应重新搜索并引入新事实。

8. 设计分支、循环与失败处理

每个回路都定义：

• 触发条件；
• 回到哪个节点；
• 允许补充或修改哪些字段；
• 最大次数、时间或成本预算；
• 停止后是 partial、failed 还是转人工。

区分：

• 技术失败：超时、解析失败、API 错误；
• 数据失败：缺必需字段、Schema 不合法；
• 证据不足：允许部分完成或转人工；
• 业务冲突：保留冲突并按规则降置信度；
• 高风险操作：执行前请求授权，不用自动重试绕过审批。

9. 把生成与验收确定性化

如果源 Skill 已有构建器、校验器或唯一事实源，Workflow 必须继续使用。推荐结构：

中间分析状态
→ 标准事实源组装
→ Schema 校验
→ 确定性生成交付物
→ 正式校验器

校验失败时优先修正标准事实源并重新生成，不让 LLM 直接分别修改多个派生产物。无法依据现有证据修复时，路由回真正缺失信息的上游节点。

10. 交付并做覆盖检查

完整规格至少说明：

• 主链路、节点数量和节点图；
• 每个节点的目标、类型、输入、输出、工具、提示词和验收；
• 共享子工作流及请求/响应契约；
• 状态、缓存、来源、分支、回路和重试；
• 正式产物、构建方式和端到端完成条件；
• 从源 Skill 到 Workflow 节点的规则覆盖表。

最后逐条核对源 Skill 的必需步骤、核心边界和完成检查，确保没有规则只存在于原文、却在 Workflow 中无人承接。

关键设计原则

• 节点数由稳定责任和状态边界决定，不由源文档的标题数量决定。
• 共享工具机制可以抽象，业务判断不能因工具复用而被混合。
• 搜索、读取和证据提取负责提供材料；分析节点负责形成领域结论。
• 先建立事实和任务，再评分或决策；不要让模型边搜索边凭印象评分。
• 中间状态可以丰富，正式数据契约必须保持干净和兼容。
• 可观测性不是额外报告：节点状态、来源、限制、重试原因和产物路径应成为运行状态的一部分。
• 没有用户授权时，设计 Workflow 不等于执行、部署或触发外部副作用。