第9篇：Skill的组合与编排——构建复杂工作流

第9篇Skill的组合与编排——构建复杂工作流适用人群高阶 | 字数约25,000字 | 预计阅读时间60分钟前言前八篇我们一直在讨论单个 Skill——如何设计、创作、测试一个独立完整的 Skill。但单个 Skill 的力量是有限的。一个 Skill 只能完成一个专门的任务——翻译、摘要、会议纪要、天气查询。现实世界的工作流往往是多个步骤的链条每天早上 → 搜索行业新闻 → 筛选与我相关的内容 → 生成简报 → 推送到团队群这个链条涉及四个步骤每个步骤如果单独做需要四个独立的操作。但如果能把四个步骤编排成一个自动化工作流——那就是 112 的效果。Skill 的组合与编排就是让多个 Skill 协同工作形成完整的工作流。这一篇我们讲解什么是 Skill 组合——多个 Skill 如何串联工作什么是工作流编排——如何设计多步骤的自动化流程实战案例——从简单到复杂的编排模式设计原则——让组合和编排稳定可靠第一章从单一能力到系统能力1.1 单个 Skill 的局限单个 Skill 在设计上追求专注做好一件事。但现实世界的工作很少有一步到位的。单个 Skill 擅长 ✅ 翻译一段文字 ✅ 整理会议纪要 ✅ 查询天气信息 ✅ 生成周报 单个 Skill 不擅长 ❌ 每天早上自动搜索新闻→筛选→生成简报→发到群里 ❌ 会议结束后自动整理纪要→提取待办→更新项目进度 ❌ 收到客户邮件→分析内容→生成回复草稿→提醒我确认发送 这些任务需要多个步骤每个步骤需要一种不同的能力。1.2 组合创造新能力当多个 Skill 组合起来可以创造出单个 Skill 不具备的能力。组合示例1监控分析推送 搜索Skill获取信息 → 分析Skill筛选和提炼 → 简报Skill整理格式 → 消息Skill推送到群 一个全自动的舆情监控系统 组合示例2输入处理输出存档 会议纪要Skill整理内容 → 待办提取Skill提取行动项 → 文档Skill保存到知识库 → 消息Skill通知参会人 一个完整的会议管理流程1.3 组合 vs 编排组合Combination 多个 Skill 以固定顺序串联 前一个的输出直接作为后一个的输入 适合流程固定的标准化任务 编排Orchestration 有控制逻辑的组合 可以包含条件分支、并行执行、循环等 适合需要决策和灵活调整的复杂任务二章组合模式2.1 顺序组合Pipeline最简单的组合模式——Skill 按顺序执行前一个的输出是后一个的输入。Skill A → Skill B → Skill C 示例自动新闻简报 Step 1搜索新闻搜索 Skill → 输入关键词 → 输出搜索结果列表 Step 2筛选和摘要分析 Skill → 输入搜索结果列表 → 输出精选新闻摘要 Step 3生成简报写作 Skill → 输入新闻摘要 → 输出格式化的简报 Step 4发送推送消息 Skill → 输入简报内容 → 输出已发送顺序组合的指令设计在控制层编排系统中定义【工作流定义】 工作流名称每日新闻简报 触发条件每天早上 08:00 步骤列表 Step 1: web_search 参数{query: 科技行业新闻, count: 10} → 输出: search_results Step 2: analyze_and_filter 输入search_results 指令从以上搜索结果中筛选与{user_interest}相关的3-5条 每条用50字摘要 → 输出: filtered_news Step 3: format_briefing 输入filtered_news 指令将以下内容格式化为简报模板 → 输出: formatted_briefing Step 4: send_message 输入formatted_briefing 参数{target: team_group} → 输出: sent_confirmation2.2 分支组合Conditional Branching根据条件决定走哪条路径。条件判断 ├─ 条件A → Skill_A1 → Skill_A2 └─ 条件B → Skill_B1 → Skill_B2 → Skill_B3 示例客服工单分类 输入客户问题 Step 1分类分类 Skill → 判断问题类型 → 输出{type: refund} 或 {type: technical} Step 2根据类型分支 如果是退款类 → 退款处理 Skill → 通知财务 Skill 如果是技术类 → 技术诊断 Skill → 解决方案 Skill → 通知用户 Skill分支组合的指令设计【工作流定义——分支模式】 工作流名称客服工单处理 步骤1问题分类 使用classify_issue Skill 输入用户问题 输出issue_type 步骤2条件分支 如果 issue_type refund: 执行流程 A 步骤A1process_refund Skill 步骤A2notify_finance Skill 步骤A3send_confirmation Skill 如果 issue_type technical: 执行流程 B 步骤B1technical_diagnosis Skill 步骤B2generate_solution Skill 步骤B3notify_user Skill 如果 issue_type other: 执行流程 C 步骤C1forward_to_human Skill2.3 并行组合Parallel Execution多个 Skill 同时执行互不依赖。Skill_A ──┐ ├── 汇总 Skill → 输出 Skill_B ──┘ 示例综合市场报告生成 同时执行 → 搜索 Skill搜索市场新闻 → 数据 Skill查询销售数据 → 分析 Skill分析竞品动态 三个并行任务完成后 → 汇总 Skill整合三路信息生成综合报告并行组合的指令设计【工作流定义——并行模式】 工作流名称市场综合报告 并行执行的步骤互不依赖同时执行 任务Aweb_search 参数{query: 行业动态 2026年Q2, count: 10} 任务Bquery_database 参数{query: SELECT * FROM sales WHERE quarterQ2} 任务Ccompetitive_analysis 参数{competitors: [公司A, 公司B, 公司C]} 等待所有任务完成后 汇总步骤integrate_report 输入任务A结果 任务B结果 任务C结果 指令整合以上三部分信息生成结构化的市场综合报告2.4 循环组合Iterative Processing反复执行同一个 Skill直到满足条件。┌──────────────────┐ │ 检查是否完成 │ │ ──否──→ Skill │ │ │ └──是──→ 输出 │ 示例逐章分析长文档 Step 1将长文档分为 N 个章节 Step 2对每个章节执行摘要 Skill Step 3所有章节处理完成后执行汇总 Skill Step 4输出综合摘要第三章编排系统——让组合自动化的大脑3.1 什么是编排系统编排系统Orchestration System是管理和控制多个 Skill 协同工作的大脑。它负责编排系统的职责 1. 定义工作流结构步骤顺序、依赖关系 2. 管理数据传递前一步的输出 → 后一步的输入 3. 执行条件判断路劲选择 4. 处理异常某一步失败怎么办 5. 记录执行日志追踪每个步骤3.2 编排系统与单个 Skill 的关系编排系统层面 ┌──────────────────────────────────────────────┐ │ 定义工作流 │ │ Step 1 → Step 2 → Step 3 → Step 4 │ │ 条件完成所有步骤后输出最终结果 │ │ 异常某一步失败时重试或降级 │ └──────────────────────────────────────────────┘ │ ▼ 调用 Skill 层面 ┌──────────────────────────────────────────────┐ │ Skill_A搜索│ Skill_B分析│ ... │ │ 每个 Skill 专注于自己的任务 │ │ 不关心前一步是谁、后一步是谁 │ └──────────────────────────────────────────────┘3.3 编排 vs 单一 Skill 的对比单一 Skill 实现简单 容易测试 - 功能单一 - 难以组合复杂任务 编排工作流 - 实现较复杂 - 需要编排系统支持 功能强大可完成多步骤复杂任务 每个 Skill 职责单一容易维护 可灵活调整流程第四章实战案例——构建完整工作流4.1 案例一每日行业简报自动推送这是一个最常见的自动化工作流——每天早上自动获取信息、整理、推送。工作流设计工作流名称每日行业简报 触发条件每天早上 08:00定时触发 步骤1搜集信息 Skill财经资讯或搜索 Skill 参数{keywords: 科技行业动态, AI领域进展, count: 15} 输出raw_news_list 步骤2筛选相关新闻 Skill内容分类 Skill 输入raw_news_list 参数{interest: AI, 大模型, 创业公司, max_count: 5} 指令从以下新闻中筛选出与AI大模型和创业公司相关的5条 输出filtered_news 步骤3生成简报 Skill简报生成 Skill 输入filtered_news 参数{format: markdown, language: 中文} 输出daily_briefing 步骤4推送到群聊 Skill消息推送 Skill 输入daily_briefing 参数{target: 产品团队群, title: 每日行业简报} 输出推送成功确认实际运行示例[08:00] 工作流「每日行业简报」触发 [08:00:01] → 调用「财经资讯」Skill [08:00:03] ← 返回 15 条新闻 [08:00:03] → 调用「内容分类」Skill [08:00:05] ← 筛选出 5 条相关新闻 [08:00:05] → 调用「简报生成」Skill [08:00:07] ← 生成格式化简报 [08:00:07] → 调用「消息推送」Skill [08:00:08] ← 推送成功 [08:00:08] 工作流完成 ✅ 简报已推送至「产品团队群」4.2 案例二会议全流程自动化从会议结束到纪要分发、待办跟踪的完整流程。工作流设计工作流名称会议全流程管理 触发条件会议结束后事件触发 步骤1收集会议原始内容 Skill获取会议转写 输入会议 ID 输出raw_transcript 步骤2整理会议纪要 Skill会议纪要整理 Skill 输入raw_transcript 输出structured_minutes 步骤3提取待办事项 Skill待办提取 Skill 输入structured_minutes 输出task_listJSON格式 步骤4保存纪要到知识库 Skill文档保存 Skill 输入structured_minutes 参数{folder: 会议纪要/2026年5月} 输出doc_url 步骤5创建待办任务 Skill任务管理 Skill 输入task_list 输出created_tasks 步骤6通知参会人 Skill消息推送 Skill 参数{target: 所有参会人, content: 会议纪要和待办已创建} 输出推送完成4.3 案例三客服工单全自动处理从客户提交问题到解决方案推送的完整闭环。工作流名称客服工单处理 触发条件新工单创建 步骤1理解问题 Skill问题理解 Skill 输入用户问题 输出{issue_type: ..., urgency: ..., category: ...} 步骤2条件分支 如果 urgency high AND category refund: → 优先处理流程 → 调用退款 Skill → 通知客服主管 如果 urgency normal AND category technical: → 标准处理流程 → 调用技术诊断 Skill → 生成解决方案 → 通知用户 如果 urgency low: → 批量处理流程 → 加入待处理队列 → 每天批量处理 步骤3记录处理结果 Skill日志记录 Skill 输入所有步骤的日志 输出工单处理记录 步骤4用户满意度调查 Skill问卷推送 Skill 参数{target: 用户, delay: 24小时} 输出调查已排期第五章工作流设计的原则5.1 单一职责原则每个 Skill 只做一件事但把这件事做好。✅ 好的拆分 - 搜索 Skill只搜索 - 筛选 Skill只筛选 - 简报 Skill只生成简报 - 推送 Skill只发送 ❌ 不好的拆分 - 一个 Skill 既搜索又筛选又生成简报 → 太复杂难维护 → 改一个功能可能影响其他功能5.2 数据接口规范化前一个 Skill 的输出格式要能被后一个 Skill 正确解析。✅ 定义明确的数据格式 搜索 Skill 的输出格式 { items: [ {title: ..., summary: ..., source: ..., url: ..., date: ...} ], total_count: 15 } 筛选 Skill 的输入格式必须和搜索 Skill 的输出一致 { items: [...], // 同样的结构 max_count: 5, interest_keywords: [AI, 大模型] } ❌ 没有定义格式 搜索 Skill 输出了一段文字里面混杂着标题和摘要 筛选 Skill 不知道怎么解析 → 工作流断裂5.3 错误传播处理工作流中任何一个环节出错都应该有处理方案。【工作流错误处理】 每一步都定义 - 成功时输出正常结果给下一步 - 失败时输出错误信息并根据策略处理 错误处理策略 策略1跳过——当前步骤失败跳过继续执行后续步骤 适用非关键步骤如添加备注 策略2重试——自动重试当前步骤 适用临时性问题如网络超时 策略3降级——使用替代方案 适用核心步骤如搜索不可用时用缓存数据 策略4中断——终止工作流通知管理员 适用关键步骤失败如支付处理 全局规则 - 任何步骤失败都要记录日志 - 如果用户等待结果告知用户处理到哪一步出了问题 - 提供手动重试的选项5.4 幂等性设计同一个工作流被多次触发不应该产生副作用。幂等性Idempotency 同一个操作执行一次和执行多次结果相同。 示例非幂等 工作流每次触发都发送每日简报 如果不小心触发了两次 → 群里收到两份一样的简报 → 用户体验差 示例幂等 工作流先检查今天是否已经发过简报 如果已经发过 → 跳过 如果没有发过 → 发送 → 即使触发两次也只发一次第六章编排的工具与平台6.1 平台内置编排大多数 Skill 平台支持内置的编排能力——不需要额外工具即可组合 Skill。平台内置编排的能力 - 顺序执行A → B → C - 条件分支IF ... THEN A ELSE B - 并行执行A 和 B 同时执行 - 定时触发每天早上 8 点执行 - 事件触发当某事件发生时执行 配置方式通过可视化界面或配置文件6.2 自定义编排对于更复杂的需求可以通过编排 Skill来自定义编排逻辑。编排 Skill 的工作原理 编排 Skill 本身也是一个 Skill——它的任务是管理和调度其他 Skill。 编排 Skill 的指令设计你是一个工作流编排助手。你的任务是根据用户的需求调度多个 Skill 协同完成工作。当前可用的 Skill 列表search_skill搜索信息summarize_skill生成摘要translate_skill翻译send_message_skill发送消息工作流程Step 1理解用户需要什么Step 2规划需要调用的 Skill 和顺序Step 3逐个调用 Skill传递正确的参数Step 4汇总所有结果交付给用户6.3 选择编排方式的决策选择平台内置编排 适合流程固定、不需要动态调整的工作流 优点配置简单、执行稳定 例子每日定时新闻推送 选择自定义编排 适合流程需要动态调整的复杂工作流 优点灵活、可扩展 例子用户自定义的按需工作流 选择混合编排 适合既有固定流程又有动态调整需求的场景 例子标准流程走内置编排异常情况走自定义编排第七章工作流的测试与监控7.1 工作流测试和单个 Skill 一样工作流也需要测试。工作流测试的层级 第一层单步测试 测试工作流中的每一步是否正常工作 方法独立测试每个 Skill 第二层链路测试 测试步骤之间的数据传递是否正确 方法用上一步的真实输出作为下一步的输入 第三层端到端测试 测试从触发到完成的完整流程 方法用完整的输入触发工作流 第四层异常测试 测试某一步失败时整个工作流是否按预期降级 方法模拟工具调用失败7.2 工作流监控上线后的工作流需要持续监控。监控指标 执行次数每天执行了多少次 成功率成功完成的占比 单次耗时从触发到完成的总时长 每一步耗时哪些步骤最耗时 错误率哪些步骤最容易出错 降级率降级策略被触发的频率 告警规则 成功率 95% → 告警 单次耗时 5分钟 → 告警 某一步错误率 10% → 告警 连续 3 次执行失败 → 告警第八章编排的反模式反模式1过度编排表现把 2 步就能完成的工作流硬要拆成 8 步。后果增加了复杂性和错误概率。正确做法拆分的粒度以每一步是一个独立的 Skill 能力为准。可以合并的步骤不需要拆分。反模式2链式过长表现工作流有 10 个步骤只要中间一步出问题整个流程崩溃。后果成功率低、难以排查问题。正确做法限制工作流的步骤数建议不超过 5-7 步。如果确实需要更多步骤考虑拆分为子工作流。反模式3忽略数据转换表现假设前一个 Skill 的输出格式和后一个 Skill 的输入格式完全相同。后果数据格式不匹配工作流断裂。正确做法明确定义每个 Skill 的输入输出格式。如果格式不匹配增加数据转换步骤。反模式4没有降级方案表现假设所有步骤都会完美执行没有考虑失败情况。后果某一步失败整个工作流中断。正确做法为每个步骤设计降级方案——至少决定这步失败了是继续还是终止。第九章工作流的数据流设计9.1 数据在 Skill 之间如何流动理解数据在工作流中的流动路径是设计可靠工作流的基础。数据流动路径 Skill_A 输出 → 编排系统接收 → 格式校验 → 数据转换如需要 → 传递给 Skill_B → Skill_B 处理 → Skill_B 输出 → ...数据流动中的关键节点节点一输出格式化 Skill_A 完成处理后输出应该是一个标准格式的数据结构。 ✅ 好的输出格式 { status: success, data: { title: ..., content: ... }, metadata: { execution_time: 2.3s, token_used: 1500 } } ❌ 差的输出格式 好了处理完了结果是……非结构化文本后续 Skill 难以解析 节点二格式校验 编排系统在接收到 Skill_A 的输出后应该校验格式是否符合预期。 校验内容 - 是否有 status 字段 - data 字段是否存在且不为空 - 关键字段是否存在 节点三数据转换 如果 Skill_A 的输出格式和 Skill_B 的输入格式不完全匹配需要数据转换。 转换类型 - 字段名映射field_a → field_b - 格式转换文本 → JSON - 内容过滤只传递需要的字段 - 内容增强添加默认字段或补充信息 节点四参数注入 将上一步的数据注入到下一步的输入参数中。 示例 Step 1 输出{news_list: [...], total: 15} Step 2 输入需要{items: [...], max_count: 5} 注入方式将 news_list 映射为 items9.2 数据格式的契约工作流中的每个 Skill 都需要定义清晰的数据契约——输入和输出的格式规范。数据契约的定义 Skill_A搜索 Skill 输入契约 { keywords: string搜索关键词, count: number返回数量默认10 } 输出契约 { status: success | error, data: { items: [ { title: string, summary: string, source: string, url: string, date: string } ], total_count: number }, error: string如果statuserror时存在 } Skill_B筛选 Skill 输入契约 { items: array和Skill_A输出的items结构一致, filters: { keywords: string[]筛选关键词, max_count: number } } 输出契约 { status: success | error, data: { filtered_items: array格式同items, filtered_count: number, removed_count: number } }数据契约的好处每个 Skill 的开发者知道该输出什么、该接收什么编排系统的开发者知道怎么串联各步骤测试时可以基于契约生成测试数据9.3 数据传递的中间状态在复杂工作流中可以在步骤之间存储中间状态——让后续步骤不仅能使用上一步的输出还能引用更早步骤的信息。中间状态存储示例 工作流会议全流程 Step 1会议纪要生成了纪要内容 → 存储{minutes_content: ...} Step 2待办提取从纪要中提取了待办 → 存储{minutes_content: ..., tasks: [...]} → Step 2 的输入来自 Step 1 的输出 Step 3保存纪要需要纪要内容和待办列表 → 从中间状态读取minutes_content tasks → Step 3 的输入来自 Step 1 和 Step 2 Step 4通知参会人需要纪要链接和待办数量 → 从中间状态读取doc_url tasks.length → Step 4 的输入来自 Step 3 和 Step 2中间状态的设计原则每个步骤的输出都保留在中间状态中后续步骤可以引用任意之前的步骤输出工作流完成后清理中间状态第十章工作流的触发模式10.1 定时触发最常见的触发方式——在预设的时间点自动执行。配置示例 工作流每日新闻简报 触发时间每个工作日 08:00 时区Asia/Shanghai 定时触发的高级用法 模式1固定时间 每天早上 08:00 模式2间隔触发 每 4 小时执行一次 模式3Cron 表达式 0 8 * * 1-5工作日早上8点10.2 事件触发由外部事件触发工作流执行。常见的事件类型 新文档创建 → 触发文档分析工作流 新消息收到 → 触发消息处理工作流 文件上传完成 → 触发文件处理工作流 数据库记录更新 → 触发数据同步工作流 事件触发器的配置 { workflow: meeting_automation, trigger: { type: event, event_source: calendar_system, event_type: meeting.ended, filter: { duration_minutes: { gte: 15 }, has_transcript: true } } }10.3 链式触发一个工作流完成后自动触发另一个工作流。示例 工作流A每日新闻简报08:00执行 → 完成后自动触发 工作流B简报归档将简报保存到知识库 → 完成后自动触发 工作流C发送周报每周五汇总本周简报 链式触发设计 { workflow: daily_briefing, on_complete: { trigger: archive_briefing, condition: previous.status success } }第十一章工作流的可观测性11.1 什么是可观测性可观测性Observability是指能从外部了解系统内部状态的能力。对于工作流可观测性意味着可观测性包含三个支柱 1. 日志Logs → 工作流每一步的发生了什么 → 用于问题排查 2. 指标Metrics → 工作流的运行状态数据 → 用于性能监控和趋势分析 3. 追踪Traces → 一个请求在工作流中的完整路径 → 用于定位瓶颈和异常11.2 工作流日志的设计每一步都应该记录标准格式的日志[2026-05-21 08:00:00] WORKFLOW_START | namedaily_briefing | triggerscheduled [2026-05-21 08:00:01] STEP_START | step1 | skillsearch_skill | input{keywords:科技新闻} [2026-05-21 08:00:03] STEP_END | step1 | statussuccess | output_items15 | duration2.1s [2026-05-21 08:00:03] STEP_START | step2 | skillfilter_skill | input_items15 [2026-05-21 08:00:05] STEP_END | step2 | statussuccess | filtered_items5 | duration1.8s [2026-05-21 08:00:05] STEP_START | step3 | skillbriefing_skill [2026-05-21 08:00:07] STEP_END | step3 | statussuccess | duration2.0s [2026-05-21 08:00:07] STEP_START | step4 | skillsend_message_skill [2026-05-21 08:00:08] STEP_END | step4 | statussuccess | duration0.8s [2026-05-21 08:00:08] WORKFLOW_END | namedaily_briefing | total_duration8.0s | statussuccess11.3 工作流追踪对于复杂的编排需要追踪一个请求的完整路径追踪IDTRACE-20260521-001 工作流daily_briefing 时间线 08:00:00.000 → 触发定时触发 08:00:00.100 → Step 1 开始search_skill 08:00:02.200 → Step 1 结束成功15条结果 08:00:02.300 → Step 2 开始filter_skill 08:00:04.100 → Step 2 结束成功5条结果 08:00:04.200 → Step 3 开始briefing_skill 08:00:06.200 → Step 3 结束成功 08:00:06.300 → Step 4 开始send_message_skill 08:00:07.100 → Step 4 结束成功 08:00:07.200 → 工作流完成总耗时7.2s 瓶颈分析 - Step 1 耗时最长2.1s占总耗时 29% - Step 3 第二2.0s占总耗时 28% - 整体效率可以接受第十二章从组合到生态12.1 Skill 网络的涌现效应当足够多的 Skill 被创作出来Skill 之间开始形成网络——这就是 Skill 生态的雏形。孤立状态 Skill_A 不知道 Skill_B 的存在 Skill_C 和 Skill_D 都可能做同样的事 网络状态 创作者知道有哪些 Skill可用 编排时选择最合适的组合 Skill 之间形成互补关系 生态状态 Skill 之间有标准的接口和协作方式 新 Skill 创作时考虑了和其他 Skill 组合的可能性 出现了专门负责编排的 Skill12.2 Skill 的可组合性设计想让自己的 Skill 在生态中被广泛组合需要在设计时就考虑可组合性可组合性设计原则 原则一输入输出结构化 不要用一段话作为输出 用 JSON 等结构化格式让其他 Skill 能准确解析 ✅ { status: success, data: { ... } } ❌ 处理完了结果是这样的…… 原则二功能单一明确 一个 Skill 只做一件事 ✅ 搜索 Skill 只负责搜索不负责筛选 ✅ 筛选 Skill 只负责筛选不负责生成报告 越专注的 Skill越容易被组合 原则三有明确的能力声明 告诉编排系统我能做什么、我需要什么、我产出什么 就像是 API 文档12.3 生态对创作者的价值对 Skill 创作者来说生态意味着 更多使用场景 你的 Skill 可能被编排到各种工作流中 使用范围远超过你最初设计时的想象 更低的创作门槛 不需要每个 Skill 都从零开始 可以组合已有的 Skill 快速构建新能力 更好的反馈循环 生态中的用户会给你更多使用反馈 让 Skill 迭代更快、质量更高 更大的影响力 一个好的 Skill 通过生态传播 帮助的人远超过你直接能接触到的范围写在最后单个 Skill 是工具。多个 Skill 的组合是系统。从创作一个 Skill到编排多个 Skill是一次能力的跃迁从解决单一问题到解决完整流程从手工调用到自动化执行从简单功能到复杂系统回顾核心要点四种组合模式顺序、分支、并行、循环编排系统管理多 Skill 协同的大脑设计原则单一职责、规范接口、错误传播、幂等性测试与监控端到端测试、持续监控避免反模式不过度编排、不过长链路、必须有降级回顾核心要点四种组合模式顺序、分支、并行、循环——覆盖了绝大多数工作流场景编排系统管理多 Skill 协同的大脑负责调度、数据传递和异常处理设计原则单一职责让 Skill 更专注、规范接口让协作更顺畅、错误传播让工作流更健壮、幂等性让执行更安全数据契约每个 Skill 定义清晰的输入输出格式是工作流可靠运行的基础测试与监控端到端测试、持续监控、完善的日志追踪可组合性设计让 Skill 天生就适合被组合是生态建设的第一步避免反模式不过度编排、不过长链路、必须有降级方案当你掌握了组合与编排你的能力就从创作一个工具跃迁到了设计一套系统。这是 Skill 创作者最具价值的进化方向。课后练习设计练习设计一个每日工作复盘工作流——包含信息获取、分析、生成复盘报告、推送四个步骤。数据接口练习为上面的工作流定义每个步骤的输入输出数据格式。异常处理练习为上面的工作流设计降级方案——如果信息获取步骤失败整个流程怎么降级下一篇预告《第10篇Skill的生态建设与未来趋势》最后一篇了我们把视野拉到最高——Skill 的生态怎么构建创作社区怎么建立Skill 的未来趋势是什么从创作者到生态建设者。单个 Skill 是一把瑞士军刀。多个 Skill 的组合是一整套工具箱。️