cfdaily
27 KiB
27 KiB
课题4 设计方案：智能拆解机制 + Skill 体系工程落地
作者: 庞统士元
日期: 2026-05-15
状态: 方案待确认
前置: 课题1/2/3 已结题
调研报告: docs/research/v2.6-research-04-decomposition-skills.md
Part A：智能拆解机制
1. 设计目标
v1.0 的拆解是"关键词匹配 → 固定 DAG 模板"，问题是：
- 模板太死板（5个固定DAG），无法根据需求动态调整
- 关键词匹配粗糙，复杂需求容易匹配错模板
- 庞统拆解时靠 LLM 理解，没有结构化引导
课题4要解决：庞统收到用户需求后，如何把它变成黑板上的任务（含依赖关系、角色分配、风险等级）。
2. 和课题1/2/3的关系
课题1-3 已经定义了"任务在黑板上长什么样"（tasks 表 schema、状态机、reviews 表、Guardrail 配置）。课题4定义的是"任务怎么被创建出来"。
课题4（创建） → 课题2（触发执行） → 课题3（审查） → 课题1（失败处理）
3. 设计决策
D4-1：模板组件库替代固定 DAG
参考实践：
- MetaGPT：SOP 自动链 +
_watch声明式订阅，不是固定 DAG- get-shit-done：discuss→plan→execute→verify→ship 五阶段，但每阶段内部灵活
- open-multi-agent：Goal → DAG 自动分解，按 complexity 决定粒度
- v1.0：5 个固定模板（full_role_development / circular_review_test / multi_stage_review / data_acquisition / multi_edge_discussion）
方案：不是 5 个完整 DAG，而是模板组件库（Phase Components）。庞统按需组合。
# template_components.yaml
components:
research:
trigger: "需要调研/分析"
mandatory: false
steps:
- id: lit_search
name: "资料调研"
agent: zhaoyun-data
output: "research_report.md"
- id: analysis
name: "分析总结"
agent: pangtong-fujunshi
output: "analysis.md"
design:
trigger: "需要架构/设计"
mandatory: false
steps:
- id: arch_design
name: "架构设计"
agent: pangtong-fujunshi
output: "design.md"
- id: design_review
name: "设计评审"
agent: simayi-challenger
review_type: plan_review
coding:
trigger: "需要编码/实现"
mandatory: false
steps:
- id: implement
name: "编码实现"
agent: zhangfei-dev
output: "code/"
- id: code_review
name: "代码评审"
agent: simayi-challenger
review_type: output_review
data:
trigger: "需要数据获取/处理"
mandatory: false
steps:
- id: data_acquire
name: "数据获取"
agent: zhaoyun-data
output: "data/"
- id: data_validate
name: "数据验证"
agent: zhaoyun-data
deploy:
trigger: "需要部署"
mandatory: false
steps:
- id: deploy
name: "部署"
agent: jiangwei-infra
output: "deploy_log.md"
- id: deploy_verify
name: "部署验证"
agent: jiangwei-infra
risk_control:
trigger: "涉及实盘/资金/策略"
mandatory: true # 触发条件满足时强制包含
steps:
- id: risk_check
name: "风控检查"
agent: guanyu-dev
review:
trigger: "always"
mandatory: true # 铁律 IR-1
steps:
- id: final_review
name: "最终审查"
agent: simayi-challenger
review_type: final_review
custom:
trigger: "none" # 不自动触发，庞统主动选择
description: "庞统自由定义的 phase，结构与标准组件相同"
steps: [] # 空的，庞统运行时填充
custom 组件接口：与标准组件同 schema（steps 列表，每个 step 有 id/name/agent/output/review_type）。Plan Checker 对 custom 组件的验证和标准组件相同——检查覆盖性、依赖性、粒度、铁律。唯一区别是 custom 不从库中引用，而是庞统在 Step 2 中自由定义。
**庞统的拆解流程**：
Step 1：需求结构化
- 分析用户输入，提取需求列表
- 每个需求标注类型（数据/编码/分析/部署/风控）
- 评估复杂度（简单/中等/复杂）
- 隐含需求挖掘（如用户说"回测"→ 隐含需要数据获取）
- 产出：structured_requirements → 写入黑板 decisions 表
Step 2：组件选择 + 组合
- 根据需求类型，从组件库选择需要的 phases
- 检查 mandatory 组件是否被遗漏
- 组合 phases，排列依赖关系
- AI 增强：增删调整（如"这次数据已有，跳过 data_acquire"）
- 产出：draft_plan → 写入黑板 decisions 表
Step 3：Plan Checker 验证
- 独立验证（不是庞统自己验证自己）
- 检查项：
- 覆盖性：每个需求是否被至少一个 step 覆盖
- 依赖性：step 依赖是否合理（无环、无遗漏前置）
- 粒度性：step 是否过大/过小
- 铁律：IR-1（每任务至少2 Agent）是否满足
- 风险：risk_level 是否合理，高风险任务是否有对抗审查
- 不通过 → 回 Step 2 调整（最多 2 轮）
- 2 轮不通过 → 庞统带着 Plan Checker issues 创建任务，标注 risk_level=high，由审查者在 plan_review 阶段进一步验证。不升级用户（庞统能处理）
- 通过 → 进入 Step 4
Step 4：任务创建
- 将 plan 转为黑板 tasks
- 每个 step → 一个 task（含 truths / artifacts / constraints / risk_level / assigned_to）
- 依赖关系 → tasks 的 depends_on 字段
- 庞统在黑板上写 scope_declaration
- 产出：tasks 写入黑板 → Daemon 检测 → 开始执行
#### D4-2：需求结构化的输出格式
庞统分析用户需求后，输出结构化需求到黑板：
```json
{
"original_input": "实现一个双均线策略的回测",
"requirements": [
{
"id": "req-001",
"description": "获取标的分钟线数据",
"type": "data",
"acceptance_criteria": "数据文件存在于 NAS 指定路径",
"complexity": "simple",
"implicit": true
},
{
"id": "req-002",
"description": "编写双均线策略逻辑",
"type": "coding",
"acceptance_criteria": "策略代码通过单元测试",
"complexity": "medium",
"implicit": false
},
{
"id": "req-003",
"description": "回测并生成报告",
"type": "analysis",
"acceptance_criteria": "回测报告包含收益曲线和关键指标",
"complexity": "medium",
"implicit": false
}
],
"inferred_components": ["data", "coding", "analysis"],
"risk_level": "standard",
"estimated_tasks": 3
}
D4-3：Plan Checker 独立验证
参考实践：
- superpowers：plan-document-reviewer subagent 独立验证方案
- oh-my-claudecode Critic：预判→验证→自审五阶段
- get-shit-done：Scope Reduction Detection（完成后反向检查覆盖）
Plan Checker 是一个 Subagent（不需要 Agent 身份），Daemon spawn 后执行：
# review_protocols/plan_check.yaml
name: plan_check
description: "验证庞统的拆解方案是否合理"
dimensions:
- id: coverage
description: "每个需求是否被至少一个 task 覆盖"
weight: critical
method: "需求 ID → task ID 映射矩阵，检查是否有遗漏"
- id: dependency
description: "依赖是否合理"
weight: critical
method: "拓扑排序检查无环，前置是否完整"
- id: granularity
description: "粒度是否合适"
weight: major
method: "检查每个 task 的 truths 是否是一个 Agent 一次 spawn 能完成的"
- id: iron_rules
description: "铁律是否满足"
weight: critical
method: "IR-1: 至少 2 Agent 参与；IR-2: 每个 task 有 truths"
- id: risk_alignment
description: "风险等级是否合理"
weight: major
method: "涉及资金/部署 → high；纯分析 → research"
output_schema: "schemas/plan-check-output.schema.json"
verdict_options: ["approved", "needs_revision"]
D4-4：复杂度驱动的粒度控制
参考实践：
- open-multi-agent：按 complexity 决定是否拆分子任务
- wanman：Token 预算控制执行深度
| 复杂度 | 判断标准 | 拆解策略 | truths 定义 |
|---|---|---|---|
| simple | 单一文件、单一操作、< 50 行 | 1 个 task | 1-2 条 truths |
| medium | 多文件、有依赖、需要验证 | 1-3 个 task + 依赖 | 每个 2-3 条 truths |
| complex | 跨模块、多角色、需要调研 | 多 phase 组件组合 | 每个 3-5 条 truths |
粒度自检规则（庞统的 Skill 中定义）：
- 一个 task 的 truths > 5 条 → 拆分
- 一个 task 需要跨 3+ 角色 → 拆分
- 一个 task 预计 > 30 分钟 → 拆分
D4-5：用户确认点
参考实践：
- get-shit-done：discuss phase 是必须的用户确认步骤
- v2.0 PRD：Phase 1 需求探索（苏格拉底对话）
不是每步都问用户，但在关键节点确认：
| 检查点 | 触发条件 | 用户看到什么 |
|---|---|---|
| 需求确认 | Step 1 完成后 | 结构化需求列表 + 隐含需求 |
| 方案确认 | Step 2 完成后（complex 任务） | 任务列表 + 依赖关系 + 预估时间 |
simple 任务跳过方案确认，直接创建。complex 任务必须确认。
用户干预三种模式（来源：2026 human-in-the-loop 综述 + OpenAI Agents SDK）：
| 模式 | 机制 | 适用 |
|---|---|---|
| 审批式 | Agent 暂停等用户确认 | high 任务方案确认、部署前 |
| 通知式 | 推送消息，用户可回复可不回复 | standard 任务产出审查后 |
| 中断式 | Agent 主动问用户 | 歧义需求、争议仲裁 |
当前落地：通过庞统 session（webchat/Signal）。未来：dashboard Checkpoint 面板。
干预点由 risk_level 动态决定：low→无干预、standard→通知式、high→审批式、用户随时可中断。
Part B：Skill 体系工程落地
4. 设计目标
三个课题产出了大量"Agent 需要知道怎么做"的内容（28 项 Skill TODO），需要一个系统的 Skill 体系来承载。
5. 核心洞察：被动触发不可靠
问题：我们写了好多个 Skill，但除了用户明文指定"用 PAV""用 delegation"，几乎没见哪个 Skill 被主动触发过。
根因：Agent 不知道自己不知道什么。OpenClaw 的 Skill 列表注入 system prompt 后，Agent 需要自己判断需要哪个——但 Agent 根本不知道"我应该先读一个 Skill 来学怎么做"。
优秀实践验证：superpowers / GSD / open-multi-agent 没有一个是靠被动 Skill 触发的——全部是编排器构造好 prompt 直接注入。
结论：moziplus 的关键操作规范不走被动 Skill 发现，走引擎注入。
5.1 铁律定义（L0 内容）
铁律是所有 Agent 共享的强制规则，不可定制。角色追加的规则放在 L1（SOUL.md）。
| 编号 | 铁律 | 来源 |
|---|---|---|
| IR-1 | 每个任务至少 2 个 Agent 参与（做 + 挑战） | v1.0 PRD |
| IR-2 | 每个 task 必须有 truths（可观测行为标准） | 课题1 must_haves |
| IR-3 | 结论必须有证据（file:line 或具体引用） | oh-my-claudecode Critic |
| IR-4 | 语义含糊先确认，不擅自执行 | SOUL.md 底线 |
| IR-5 | 改代码先改文档（需求→设计→测试→部署） | v1.0 实践 |
Token 估算：5 条铁律，每条 ~30 token（编号+一句话），总计 ~150 token + XML 包装 ~50 token = ~200 token。加上角色追加（L1 SOUL.md 已计入），L0 预算 ~200-300 token，远低于 ~500 上限。
6. 设计决策
D4-6：四层上下文架构
参考实践：
- superpowers：每个 subagent 有独立 prompt 模板（implementer-prompt.md / spec-reviewer-prompt.md），模板里写死操作步骤
- open-multi-agent：
buildTaskPrompt()拼 task title + description + 依赖产出 + messages- GSD：每个 executor 拿到 PLAN.md + PROJECT.md + STATE.md + CONTEXT.md，按 context window 大小自适应
- OpenClaw：Hook
agent_turn_prepare可注入 prependContext/appendContext
共同模式：操作规范（模板）+ 项目背景（固定）+ 任务上下文（动态），编排器拼装，不靠 Agent 自己找。
┌─────────────────────────────────────────────────────────────┐
│ Layer 0: 铁律（Iron Rules） │
│ 机制: OpenClaw Hook agent_turn_prepare │
│ 保证: 每轮强制注入 | Token: ~500 │
│ 内容: IR-1~IR-5（每个 Agent 可定制） │
├─────────────────────────────────────────────────────────────┤
│ Layer 1: 角色（Agent Identity） │
│ 机制: SOUL.md + IDENTITY.md + AGENTS.md │
│ 保证: 每轮强制 | Token: ~2000 │
│ 内容: 角色定义 + 行为准则 + 记忆 │
│ 变化频率: 极少（换平台不变） │
├─────────────────────────────────────────────────────────────┤
│ Layer 2: 操作规范 + 任务上下文（引擎注入） │
│ 机制: Daemon spawn 时拼装 bootstrap 消息 │
│ 保证: 每次 spawn 强制注入 | Token: ~1000-2000 │
│ 三段式： │
│ ① 角色操作规范模板（executor.md / reviewer.md / planner.md）│
│ → 固定部分，写死关键操作步骤（scope/output/handoff等） │
│ → 变化频率: 很少（moziplus 平台变了才改） │
│ ② 项目背景（项目路径/框架/NAS/回测服务） │
│ → 半固定部分，按项目配置 │
│ ③ 任务上下文（truths/artifacts/constraints + depends_on产出）│
│ → 动态部分，每次 spawn 不同 │
├─────────────────────────────────────────────────────────────┤
│ Layer 3: 参考信息（OpenClaw Skill 被动发现） │
│ 机制: OpenClaw Skill 列表注入 system prompt │
│ 保证: ❌ 不保证触发（锦上添花） │
│ 内容: 具体操作方法（回测流程/数据获取/部署步骤等） │
│ 优化: description 中加触发场景+示例对话+触发词（见D4-8） │
└─────────────────────────────────────────────────────────────┘
张飞编码时靠什么：
- L0+L1：身份和纪律（每轮都有）
- L2 ① executor.md："读黑板→写scope→执行→写output→写Handoff"（引擎注入，不会忘）
- L2 ③ 任务上下文："这次要做什么、truths 是什么、前序产出是什么"（引擎注入）
- L3 quant-backtest Skill：具体回测代码怎么写（自己判断要不要读）
D4-7：L2 引擎注入的拼装原则
参考实践：
- superpowers：implementer/spec-reviewer/code-quality-reviewer 三个独立 prompt 模板，只包含该角色需要的信息
- open-multi-agent：
buildTaskPrompt()只注入依赖链上的产出（default-deny），不是全量- GSD：按 context window 大小自适应（200K 只给任务级，1M 给全量）
原则：按角色和任务阶段精确注入，不统一拼装，不多不少。
| Agent 角色 | 注入内容 | 不注入 |
|---|---|---|
| 执行者 | executor.md + Guardrail 配置 + 任务上下文 | Review Protocol |
| 审查者 | reviewer.md + Review Protocol + required_reading | Guardrail 配置 |
| 庞统（规划） | planner.md + template_components + Plan Checker | Review Protocol |
| 庞统（裁决） | adjudicator.md + 正方 comment + 反方 comment | Guardrail 配置 |
| 反驳者 | rebuttal.md + 审查者 review + ACCEPT/REJECT 指令 | Review Protocol |
| Plan Checker | plan_checker.md + 需求列表 + 拆解方案 | 全部角色模板 |
拼装逻辑（Daemon 代码）：
def build_bootstrap(agent_id, role, task):
parts = []
# ① 角色操作规范模板
template = load_template(f"prompt_templates/{role}.md")
parts.append(template)
# ② 项目背景（半固定）
parts.append(format_project_context(task))
# ③ 任务上下文（动态）
parts.append(format_task_context(task))
# 按角色追加（只注入该角色需要的）
if role == "executor":
parts.append(format_guardrails(task.task_type))
elif role == "reviewer":
parts.append(format_review_protocol(task.review_type))
parts.append(format_required_reading(task))
elif role == "planner":
parts.append(format_template_components())
elif role == "rebuttal":
parts.append(format_review_to_respond(task))
return "\n\n".join(parts)
D4-8：L3 Skill 被动触发的优化写法
参考实践：
- superpowers code-reviewer：description 里嵌入
<example>标签，用对话示例教 Agent 触发场景- wiki-query：description 里加 Chinese/English triggers 列表
- gstack plan-design-review：加
Proactively suggest when...指令- SkillRouter 论文（2026）：Agent 自主搜索（agentic）比纯关键词/纯语义准确率最高
即使 L3 不保证触发，也要优化写法提高命中率。moziplus 的 Skill 全部按以下规范写 description：
---
name: quant-backtest
description: >
标准化量化回测技能。
When to use: 当需要回测量化策略、验证策略历史表现、测试策略参数时。
Chinese triggers: 回测、backtest、策略测试、历史表现验证、参数优化。
English triggers: backtest, strategy test, historical performance, parameter optimization.
Proactively suggest when: 用户提到策略实现完成后，主动建议运行回测验证。
Example: user says "帮我测一下双均线策略" → use quant-backtest skill.
---
description 四要素：
- 功能描述：这个 Skill 干什么
- 触发场景（When to use）：什么情况下该用
- 触发词（Chinese/English triggers）：中英文关键词
- 主动建议（Proactively suggest）：Agent 看到相关场景时主动推荐
D4-9：Skill 诚实边界
参考实践：nuwa-skill Agentic Protocol 要求每个 Skill 声明自己做不到什么
每个 Skill 必须包含 ## 诚实边界 section：
## 诚实边界
- 本 Skill 不覆盖实盘交易逻辑（实盘请参考 live-trading Skill）
- 性能问题需要实际测试数据，纯代码审查无法确认
- 复杂策略可能需要拆分为多个 task
D4-10：moziplus 目录结构
sanguo_moziplus/
prompt_templates/ ← L2 ① 角色操作规范（Daemon 读取拼装）
executor.md ← 执行者操作步骤（读黑板→scope→执行→output→handoff）
reviewer.md ← 审查者操作步骤（读Protocol→审查→写review）
planner.md ← 庞统拆解步骤（需求结构化→组件选择→PlanChecker）
adjudicator.md ← 庞统裁决步骤（正方反方→判断→写决策）
rebuttal.md ← 反驳步骤（读review→ACCEPT/REJECT/PARTIAL）
plan_checker.md ← Plan Checker 步骤（覆盖性→依赖→粒度→铁律）
review_protocols/ ← L2 审查协议（Daemon 构造 reviewer bootstrap 时读取）
plan_review.yaml ← 方案审查协议
output_review.yaml ← 产出审查协议
guardrail_l2.yaml ← L2 轻量AI检查协议
analysis_review.yaml ← 分析审查协议
plan_check.yaml ← Plan Checker 协议
schemas/ ← CLI 层 Schema 校验（blackboard.py 读取）
handoff.schema.json ← Handoff 格式校验
output.schema.json ← Output 格式校验
decide.schema.json ← Decision 格式校验
observe.schema.json ← Observation 格式校验
review-output.schema.json ← Review 格式校验
template_components.yaml ← 模板组件库（庞统拆解时参考）
guardrails.yaml ← 声明式 Guardrail（Daemon 执行检查）
project_context.yaml ← L2 ② 项目背景（NAS路径/回测服务/框架）
各目录作用：
| 目录/文件 | 谁读 | 作用 | 变化频率 |
|---|---|---|---|
prompt_templates/ |
Daemon | 按 Agent 角色拼装 bootstrap 消息 | 很少变 |
review_protocols/ |
Daemon | 构造审查者的 bootstrap 消息 | 偶尔变 |
schemas/ |
blackboard.py CLI | 写入时校验数据格式 | 偶尔变 |
template_components.yaml |
庞统（通过 L2 注入） | 拆解需求时选择组件 | 偶尔变 |
guardrails.yaml |
Daemon | 自动检查产出 | 偶尔变 |
project_context.yaml |
Daemon | 拼装项目背景信息 | 换项目时变 |
注意：Agent 不直接读这些文件——全部由 Daemon 读取后拼装到 bootstrap 消息中注入。
D4-11：L2 引擎注入示例（张飞编码场景）
Daemon spawn 张飞时拼装的完整 bootstrap 消息：
═══ 操作规范（executor.md 模板）═══
你是任务执行者。按以下步骤工作：
## 1. 理解任务
- 读黑板任务详情（blackboard.py read --task {task_id}）
- 理解 truths（可观测行为标准）、artifacts（必须产出）、constraints（约束）
## 2. 声明范围
- 写 scope_declaration（blackboard.py decide --task {task_id} --decider zhangfei-dev）
- 格式：{"decision": "我计划做什么", "rationale": "为什么", "artifacts": ["路径"]}
## 3. 执行工作
- 按你的专业能力完成任务
- 发现风险 → blackboard.py observe --task {task_id} --severity warning
- 需要协作 → blackboard.py comment --task {task_id} @mention
## 4. 提交产出
- blackboard.py output --task {task_id} --summary "一句话" --content-path "文件路径"
## 5. 写交接
- blackboard.py comment --task {task_id} --author zhangfei-dev \
--handoff '{"completed":"...", "artifacts":["..."]}'
## 6. 通知引擎
- 写 inbox 文件通知 Daemon 完成
═══ 项目背景（project_context.yaml）═══
项目：sanguo_quant_live
框架：vnpy
NAS 数据：/Volumes/stock/
回测服务：http://192.168.2.154:8088
编码规范：类型注解必须、禁止 any、match 现有风格
═══ 任务上下文（黑板动态读取）═══
任务 ID: task-001
任务标题: 实现双均线策略
truths: ["策略代码通过单元测试", "回测结果包含收益曲线"]
artifacts: ["task-001/strategy.py", "task-001/backtest_report.pdf"]
constraints: ["使用 vnpy 框架", "不超过 500 行"]
risk_level: standard
═══ 前序信息（depends_on 产出）═══
[赵云 Handoff] 完成了分钟线数据下载，产出 task-000/data/
数据路径: /Volumes/stock/min_data/IF888.csv
═══ 可选参考 ═══
如果需要具体操作方法，用 read 加载：
- 编码：~/.openclaw/skills/coding-implementation/SKILL.md
- 回测：~/.openclaw/skills/quant-backtest/SKILL.md
对比审查者（司马懿）收到的 bootstrap：
═══ 操作规范（reviewer.md 模板）═══
你是质量审查者。按 Review Protocol 执行审查：
## 审查步骤
1. 预判：先不读产出，预测 3-5 个最可能出问题的点
2. 验证：读实际产出（不是报告），逐条验证每个 truth
3. 多视角：从安全/新人/运维三个角度看产出
4. 缺口分析：不只看"什么有问题"，还看"什么缺失了"
5. 自审：给每个 finding 打 confidence，低 confidence 降级
## 写 Review
- blackboard.py review --task {task_id} --verdict [approved|rejected|needs_revision] ...
[... 对抗性指令 ...]
═══ Review Protocol（output_review.yaml）═══
[审查维度、方法、输出 Schema 等详细协议内容]
═══ 任务上下文 ═══
[同上]
═══ Required Reading ═══
- 执行者 scope_declaration: ...
- 产出物: task-001/strategy.py
- must_haves truths: [...]
7. 和现有设计的对齐检查
| 已有设计 | 课题4 补充 | 一致性 |
|---|---|---|
| §3.2 tasks 表 schema | D4-1 模板组件输出 → tasks 写入 | ✅ truths/artifacts/constraints/risk_level/depends_on 对齐 |
| §9.2 分级审查矩阵 | D4-4 复杂度→粒度控制 | ✅ risk_level 在创建时标注 |
| §4.2 Tick+Inbox | D4-1 Step 4 创建任务后 Daemon tick 检测 | ✅ 创建是事件源 |
| §9.4 Review Protocol Registry | D4-10 review_protocols/ 目录 | ✅ Daemon 构造审查者 bootstrap 时读取 |
| §9.9 Agent vs Subagent | D4-3 Plan Checker 走 Subagent | ✅ 无身份一次性检查 |
| Skill TODO 28项 | D4-10 prompt_templates/ 承载关键操作 | ✅ S-01~S-28 的关键操作写死在模板中 |
8. 遗留 TODO
| # | 待解决事项 | 归属 | 说明 |
|---|---|---|---|
| ✅ 方案已定，开发实现 | |||
| ✅ 方案已定，开发实现 | |||
| ✅ 方案已定，开发实现 | |||
| ✅ 方案已定，开发实现 | |||
| ✅ 方案已定，开发实现 | |||
| ✅ 方案已定，开发实现 | |||
| ✅ 方案已定，开发实现 | |||
| ✅ 方案已定，开发实现 | |||
| ➡️ 移至工具链课题（开发工具链的一部分，不属于拆解机制） | |||
| ➡️ 合并进课题6（经验→Skill的进化是经验沉淀闭环，课题6已有两级蒸馏+Skill生命周期） |