ROUTE() Skill 路由与编排
1. 基本信息
Skill ID: zayn-route
Display Name: ROUTE()
Chinese Name: Skill 路由与编排
Project: WorkFn
Author Prefix: zayn
Category: Skill Orchestration
Version: 0.1.0
Status: Draft for testing
2. 解决的问题
ROUTE() 用于解决以下问题:
- 用户遇到复杂问题,不知道先调用哪个 Skill
- 一个问题可能需要多个 Skill 串联
- 前一个 Skill 的结果没有被正确传给下一个 Skill
- Skill 调用顺序错误
- 信息不足时仍然继续后续分析
- 多个 Skill 重复分析同一问题
- 最终输出 Skill 不明确
- 路由过程越来越复杂,重新变成万能工具
3. 适用场景
适用于:
- 用户的问题涉及多个阶段
- 需要先理解再澄清
- 需要先判断再报价
- 需要先分析客诉再判断责任
- 需要先检查订单再启动交付
- 需要先梳理重点再汇报或决策
- 用户不确定应该调用哪个 Skill
- 需要明确 Skill 调用链和停止条件
4. 不适用场景
不适用于:
- 一个明确 Skill 已足够解决的问题
- 用户已经明确指定要调用的 Skill
- 只需要执行简单翻译
- 只需要普通总结
- 需要 ROUTE() 自己完成全部业务分析
- 需要自动执行所有 Skill
- 需要创建复杂多 Agent 系统
5. 输入参数
必填参数
| 参数 | 说明 |
|---|---|
| user_problem | 用户当前遇到的问题 |
| desired_outcome | 用户最终希望得到什么 |
| available_context | 当前已有上下文和材料 |
建议参数
| 参数 | 说明 |
|---|---|
| current_stage | 当前处于理解、澄清、判断、决策、执行、沟通、跟踪或复盘阶段 |
| known_facts | 已确认事实 |
| missing_information | 已知缺失信息 |
| existing_outputs | 已经运行过的 Skill 结果 |
| constraints | 时间、权限、风险、数据和业务限制 |
| final_output_type | 最终希望得到回复、报价、汇报、方案、计划或纪要 |
| user_selected_skill | 用户已经指定的 Skill |
| available_skills | 当前项目已有 Skill 列表 |
6. 参数运行要求
正式路由前必须输出参数状态表。
参数状态只使用:
已命中
部分命中
缺失
冲突
待验证
最低运行条件:
- 用户问题基本明确
- 最终目标基本明确
- 当前已有上下文可识别
- 能判断至少一个候选 Skill
- 能识别是否需要停止补充信息
如果用户问题和最终目标都不明确,不得生成 Skill 调用链。
7. 问题类型识别
ROUTE() 必须先判断当前问题属于哪一种或哪几种类型:
- 理解
- 澄清
- 判断
- 决策
- 执行
- 沟通
- 跟踪
- 复盘
示例:
客户原话看不懂
属于:
理解
示例:
客户需求不完整,需要确认配置
属于:
澄清
示例:
判断是否值得报价
属于:
判断
示例:
确定价格后生成报价
属于:
执行
8. 单 Skill 优先原则
ROUTE() 必须先判断:
一个 Skill 是否已经足够解决问题。
如果一个 Skill 足够,不得为了展示能力而增加调用链。
例如:
帮我检查这份报价是否完整
只使用:
QUOTE()
例如:
帮我整理会议结论和责任人
只使用:
MINUTES()
9. 多 Skill 调用原则
只有在以下情况下才使用多个 Skill:
- 当前问题包含明显的前后阶段
- 后一个 Skill 依赖前一个 Skill 的输出
- 直接调用后一个 Skill 会缺少关键参数
- 不同 Skill 之间职责明确
- 每一步都有必要性
- 调用链长度合理
第一版建议:
最多推荐 5 个 Skill。
超过 5 个时,应重新检查是否过度设计。
10. Skill 调用链设计
调用链必须说明:
- 顺序
- Skill 名称
- 作用
- 所需输入
- 产出
- 产出传给哪个 Skill
- 停止条件
统一格式:
| 顺序 | Skill | 作用 | 所需输入 | 关键输出 | 输出传给 | 停止条件 |
|---|
11. 参数传递规则
前一个 Skill 的输出传给下一个 Skill 时,必须:
- 只传必要字段
- 不原样传递整段长文本
- 保留已确认事实
- 保留待验证信息
- 保留冲突
- 不把推测升级为事实
- 标明来源 Skill
例如,INTENT_DECODE() 输出:
客户明确表达
客户核心关注点
可能意图
待确认事项
传给 CLARIFY() 时,只保留:
已确认需求
待确认事项
不可过度推断的部分
12. 停止条件
ROUTE() 必须为每个调用链设置停止条件。
常见停止条件:
- 关键参数缺失
- 产品身份无法确认
- 客户需求范围不明确
- 责任状态无法确认
- 价格、库存或交期未确认
- 订单尚未确认
- 用户目标发生变化
- 当前证据不足
- 后续 Skill 不具备最低运行条件
停止时必须明确说明:
- 为什么停止
- 缺什么
- 应该补什么
- 补充后从哪个 Skill 继续
13. 正式路由触发条件
只有同时满足以下条件,才生成完整 Skill 调用链:
- 用户问题明确
- 最终目标明确
- 至少一个候选 Skill 明确
- 关键输入可识别
- Skill 之间有真实依赖
- 调用链没有明显重复
- 已设置停止条件
14. 输出结构
ROUTE() 必须按以下结构输出:
A. 参数完整度结论
只使用:
可直接路由
需要补充关键参数
当前只适合单 Skill
存在冲突,暂不建议继续
B. 参数状态表
列出:
- 用户问题
- 最终目标
- 当前阶段
- 已有材料
- 已有 Skill 输出
- 限制条件
C. 问题识别
当前问题类型:
核心目标:
当前阶段:
D. 单 Skill 或多 Skill 判断
明确说明:
- 一个 Skill 是否足够
- 为什么
- 是否需要调用链
E. 推荐 Skill 链
使用统一表格。
F. 当前先执行哪一步
只给一个当前动作。
例如:
先调用 INTENT_DECODE()
G. 参数传递说明
明确哪些结果传给下一个 Skill。
H. 停止条件
列出必须停止的情况。
I. 最终输出 Skill
明确最终由哪个 Skill 生成结果。
15. 常见路由示例
示例一:客户表达不清,需要回复
INTENT_DECODE()
↓
CLARIFY()
↓
REPLY()
示例二:陌生产品询价并报价
PRODUCT_BRIEF()
↓
CLARIFY()
↓
RFQ()
↓
PRICE()
↓
QUOTE()
↓
REPLY()
示例三:客户压价
INTENT_DECODE()
↓
PRICE()
↓
NEGOTIATE()
↓
REPLY()
示例四:客户投诉并要求退款
COMPLAINT()
↓
RESPONSIBILITY()
↓
RMA()
↓
SOLUTION()
↓
REPLY()
示例五:订单确认后的交付
ORDER()
↓
ORDER_KICKOFF()
↓
DELIVERY()
↓
MEETING()
↓
MINUTES()
示例六:复杂项目汇报
KEYPOINT()
↓
REPORT()
↓
DECISION()
以上示例只是候选路径,不得无条件套用。
16. 风险检查
必须检查:
- 是否推荐过多 Skill
- 是否存在职责重复
- 是否跳过参数检查
- 是否缺少停止条件
- 是否把一个简单问题复杂化
- 是否让 ROUTE() 自己完成业务分析
- 是否把推测继续传给下游
- 是否忽略用户已指定的 Skill
- 是否忽略已有 Skill 输出
- 是否重复询问已经提供的信息
17. 禁止事项
ROUTE() 不得:
- 自动执行全部 Skill
- 直接完成所有业务分析
- 为简单问题创建长调用链
- 推荐超过 5 个 Skill,除非有明确必要
- 跳过前置 Skill 的最低运行条件
- 把前一个 Skill 的全部长文本传给下一个
- 删除冲突信息
- 把待验证信息写成确定事实
- 强行使用所有现有 Skill
- 覆盖用户指定的合理路径
- 在关键信息不足时继续后续流程
- 把路由器重新做成万能工具
18. 人工判断边界
- 用户可以指定或修改路由
- 用户可以跳过某个 Skill
- 人工确认事实优先
- ROUTE() 只能建议,不得强制执行
- AI 不得修改原始材料
- AI 不得覆盖已有人工判断
- 所有自动传递内容必须可追溯到来源 Skill
19. 验收标准
一个合格的 ROUTE() 输出必须满足:
- 能识别问题类型
- 能判断一个 Skill 是否足够
- 不为了展示能力增加 Skill
- 调用顺序合理
- 参数传递清楚
- 每一步有明确作用
- 有停止条件
- 明确当前先做什么
- 明确最终输出 Skill
- 不直接代替业务 Skill
- 不把问题复杂化
- 不把待验证信息传成确定事实
20. 当前状态
Version: 0.1.0
Status: Draft for testing
评论
加载中…