Agent Skill 原理与工程实践（十八）：多个 Skill 如何组合与调用

Agent Skill 原理与工程实践（十八）：多个 Skill 如何组合与调用

上一章讨论了单个 Skill 内部的循环、重试与 Fallback。但真实任务往往无法由一个 Skill 独立完成。

例如一次系统性能分析，至少可能包含：

1
2
3
4
5
6
performance-analysis
       │
       ├── scheduler-analysis
       ├── memory-analysis
       ├── io-analysis
       └── report-generation

表面上看，只要让总 Skill 依次调用几个子 Skill 即可。真正困难的却是：

  • 谁决定调用哪个 Skill；
  • 子 Skill 是提供结果，还是接管后续任务；
  • 上游结果如何变成下游输入；
  • 多个 Skill 能否并行；
  • 某个 Skill 失败后，整体任务如何收敛；
  • 谁负责校验和生成最终答复。

因此，本章严格围绕大纲中的四个概念展开：

1
2
3
4
Orchestration  编排：谁控制整个执行过程
Composition    组合：多个能力怎样构成一个完整能力
Delegation     委派：谁把哪部分任务交给谁
Dependency     依赖：执行顺序由哪些数据和条件决定

1. 先澄清：组合 Skill 不等于拼接 Prompt

一个常见误区是把多个 Skill 的 SKILL.md 全部读入上下文，再让模型“综合执行”。这只是指令堆叠，不是工程意义上的组合。

真正的 Skill 组合至少应明确五种关系：

1
2
3
4
5
6
7
8
9
Task
  ↓
Router：选择需要的能力
  ↓
Orchestrator：安排调用顺序
  ↓
Specialists：完成边界明确的子任务
  ↓
Aggregator：合并结果并验证最终输出

如果缺少这些边界，常见结果是：

  • 多个 Skill 同时认为自己应该主导任务；
  • 同一份数据被重复分析；
  • 中间结果只有自然语言，无法可靠传递；
  • 子 Skill 修改了不属于自己的状态；
  • 最终报告互相矛盾，却没有组件负责仲裁。

所以，多 Skill 系统的核心不是“多”，而是清楚的控制权、数据契约和责任边界。

2. Skill、Agent 与 Tool 的组合层级

组合之前，必须先区分三个层级：

1
2
3
4
5
6
Agent
  ├── Skill A：领域工作流与判断规则
  │     ├── Tool 1
  │     └── Tool 2
  └── Skill B：另一套领域工作流
        └── Tool 3

2.1 Tool 组合

Tool 是一次明确操作，例如读取 trace、解析 JSON、查询指标或生成图表。组合 Tool 主要解决“动作如何执行”。

2.2 Skill 组合

Skill 是带有工作流、约束和领域知识的可复用能力。组合 Skill 主要解决“任务应怎样分解、判断和完成”。

2.3 Agent 组合

多个 Agent 通常意味着不同的模型上下文、工具权限、系统指令或对话所有权。组合 Agent 主要解决“谁来承担哪类角色”。

这三者不能简单画等号：

1
2
3
调用另一个 Skill
≠ 必然创建另一个 Agent
≠ 必然执行一个 Tool

一个 Agent 可以在同一上下文中依次使用多个 Skill；也可以把某个专门 Agent 包装成工具；还可以把控制权交给另一个 Agent。后两种模式与 Skill 组合相关，但属于运行时编排机制。

3. Orchestration：谁拥有整个流程

Orchestration 是多 Skill 系统的控制平面。它负责：

  • 理解总目标；
  • 分解子任务；
  • 选择 Skill；
  • 建立依赖关系；
  • 调度串行或并行执行；
  • 汇总状态；
  • 处理失败；
  • 验证最终结果。

可以把 Orchestrator 理解为“总导演”，但它不应该亲自完成所有专业分析。

1
2
3
4
5
6
7
8
9
User Request
      ↓
Orchestrator
      ├── plan
      ├── route
      ├── schedule
      ├── collect
      ├── validate
      └── respond

一个稳健的 Orchestrator 至少保存以下状态：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
goal: 分析服务器延迟抖动的根因
available_skills:
  - scheduler-analysis
  - memory-analysis
  - io-analysis
  - report-generation
task_graph: []
completed: []
failed: []
evidence: []
open_questions: []
budget:
  max_skill_calls: 8
  deadline_seconds: 600

关键点是：Orchestrator 管理的是任务图与状态，不是一段不断增长的思维过程。

4. 官方文档给出的首要判断：谁拥有最终答复

OpenAI 官方的 orchestration 文档把多 Agent 编排分为两种核心模式：

1
2
3
4
5
Handoff
  专门 Agent 接管当前分支和后续答复

Agent as Tool
  管理 Agent 保持控制权，把专门 Agent 当作有边界的能力调用

这个判断同样适用于多个 Skill 的组合：

4.1 管理者保持控制权

当子能力只是提供局部结果时，应由主 Skill 或 Orchestrator 保持控制权：

1
2
3
4
5
performance-analysis
  ├── call scheduler-analysis → scheduler finding
  ├── call memory-analysis    → memory finding
  ├── call io-analysis        → I/O finding
  └── synthesize final report

适用于：

  • 最终报告需要综合多个领域；
  • 子任务有清晰的输入输出；
  • 用户只需要一个统一答复；
  • 主流程需要统一控制预算和质量。

4.2 专门能力接管控制权

当任务进入一个独立领域，且后续对话、工具、规则都应由专门角色负责时，可以 handoff：

1
2
3
4
triage
  ↓ identify database incident
database-incident-specialist
  ↓ owns subsequent interaction

适用于：

  • 后续步骤需要完全不同的权限或政策；
  • 专门能力需要直接向用户追问；
  • 专门能力应负责其分支上的最终答复；
  • 主 Agent 不应继续充当中间转述者。

不要把 handoff 当作普通函数调用。一旦移交控制权，就必须定义如何返回、是否返回，以及会话状态如何继承。

5. Composition：四种常见组合结构

5.1 顺序组合 Pipeline

后一步依赖前一步输出：

1
2
3
4
5
6
7
collect-data
    ↓ trace_bundle
normalize-data
    ↓ normalized_events
scheduler-analysis
    ↓ findings
report-generation

适合确定性较强的流水线。重点是每一步都要输出下游可消费的结构，而不是只输出面向人的解释。

5.2 并行组合 Fan-out / Fan-in

多个分析彼此独立，可以共享同一份输入并行执行：

1
2
3
                    ┌→ scheduler-analysis ─┐
normalized bundle ──┼→ memory-analysis    ─┼→ evidence merge
                    └→ io-analysis        ─┘

适合缩短总延迟，但必须处理：

  • 共享输入是否只读；
  • 各分支是否会产生冲突副作用；
  • 部分失败能否继续；
  • 合并时如何去重和处理矛盾。

5.3 路由组合 Router

先分类，再调用必要的 Skill：

1
2
3
4
5
6
request / evidence
        ↓
      router
  ┌─────┼────────┐
  ↓     ↓        ↓
sched memory     io

路由不应只靠关键词。更可靠的路由条件包括：

  • 用户目标；
  • 输入类型；
  • 已检测到的信号；
  • 所需权限；
  • 能力契约；
  • 成本和时延预算。

5.4 层级组合 Hierarchical

总 Skill 调用领域 Skill，领域 Skill 再调用更小能力：

1
2
3
4
5
performance-analysis
  └── scheduler-analysis
        ├── runqueue-analysis
        ├── wakeup-latency-analysis
        └── cpu-affinity-analysis

层级组合适合大型系统，但要限制深度。层级过深会造成上下文重复、调用链难以追踪、错误难以定位和预算失控。

6. Delegation：委派的是任务，不是模糊目标

差的委派：

1
请分析一下性能问题。

好的委派应形成 Delegation Contract：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
task_id: sched-001
skill: scheduler-analysis
objective: 判断 14:00-14:10 的 P99 延迟是否由 CPU 调度导致
inputs:
  trace_path: artifacts/perf.trace
  time_range: [14:00:00, 14:10:00]
  symptom: request_p99_spike
allowed_tools:
  - trace-reader
  - statistics
constraints:
  max_runtime_seconds: 120
  read_only: true
expected_output:
  schema: scheduler_finding_v1
success_criteria:
  - 给出支持或反对调度根因的结论
  - 每个结论关联证据
  - 明确置信度与未知项
return_control_to: performance-analysis

一个完整委派至少包含：

1
2
Objective + Inputs + Scope + Permissions
+ Output Contract + Budget + Return Rule

6.1 最小必要上下文

不要把父任务的全部历史复制给每个子 Skill。只传递：

  • 子任务目标；
  • 必要输入或工件路径；
  • 已确认事实；
  • 不可违反的约束；
  • 预期输出 Schema。

这既减少上下文成本，也避免子 Skill 被无关讨论干扰。

6.2 明确禁止越界

例如 scheduler-analysis 应明确：

1
2
3
4
5
- 只分析调度证据；
- 不重写原始 trace；
- 不直接生成整体根因结论；
- 发现内存信号时仅返回 cross_domain_signal；
- 最终控制权交回 performance-analysis。

这能避免子 Skill 逐渐膨胀成第二个总控 Skill。

7. Dependency：先画数据依赖，再安排调用顺序

多个 Skill 的依赖不应只写成“先 A，再 B”。至少要区分四类依赖。

7.1 数据依赖

B 需要 A 的输出：

1
trace-normalization → scheduler-analysis

7.2 条件依赖

只有 A 发现特定信号才运行 B：

1
2
3
baseline-scan
  └── if major_fault_rate > threshold
        → memory-analysis

7.3 资源依赖

两个 Skill 争用同一资源，不能并行：

1
2
3
system-profiler ─┐
                 ├─ exclusive host access
kernel-tracer  ──┘

7.4 权限依赖

某个 Skill 需要审批、凭证或更高权限，必须先完成授权检查。

因此，应把任务表示成有向无环图，而不是静态清单：

1
2
3
4
5
6
7
8
9
10
11
collect
   ↓
normalize
   ├─────────────┬─────────────┐
   ↓             ↓             ↓
scheduler      memory          io
   └─────────────┴─────────────┘
                 ↓
              correlate
                 ↓
               report

只有没有未完成依赖的节点才进入 ready 状态。

8. 为 Skill 定义可组合的输入输出契约

Skill 能否组合，首先取决于接口，而不是文字写得是否漂亮。

8.1 不可组合的输出

1
系统似乎存在一些调度问题，建议继续观察。

下游无法判断：证据是什么、时间范围是什么、置信度多高、是否需要进一步分析。

8.2 可组合的输出

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
{
  "schema_version": "scheduler_finding_v1",
  "status": "completed",
  "conclusion": "scheduler_contention_likely",
  "confidence": 0.86,
  "evidence": [
    {
      "metric": "runqueue_latency_p99_ms",
      "value": 47.2,
      "time_range": "14:03:10/14:04:00",
      "artifact_ref": "artifacts/sched-summary.json"
    }
  ],
  "cross_domain_signals": ["possible_io_wait"],
  "unknowns": ["cpu_affinity_history_unavailable"],
  "recommended_next_skills": ["io-analysis"]
}

8.3 Envelope 与领域 Payload 分离

推荐所有 Skill 共用统一外壳：

1
2
3
4
5
6
7
8
9
10
task_id: string
skill_name: string
skill_version: string
status: completed | partial | failed | blocked
started_at: timestamp
finished_at: timestamp
payload: object
artifacts: list
warnings: list
error: object | null

payload 由各领域定义，外壳则帮助 Orchestrator 统一处理状态、日志、失败和工件。

8.4 Schema 必须版本化

如果 scheduler-analysis 修改字段名，而 report-generation 仍按旧格式读取，组合链会在运行时断裂。因此应：

  • 给输入输出 Schema 加版本；
  • 明确兼容范围；
  • 在边界执行校验；
  • 不兼容时尽早失败；
  • 必要时提供 adapter，而不是让下游猜测。

9. 一个完整的 performance-analysis 编排设计

9.1 总 Skill 的职责

performance-analysis 不负责深入分析所有领域，而负责：

  1. 确认分析目标和输入；
  2. 做最低成本的初筛；
  3. 建立任务图；
  4. 调用必要的专业 Skill；
  5. 合并跨域证据；
  6. 识别矛盾和缺口；
  7. 调用报告 Skill；
  8. 验证最终报告。

9.2 执行状态机

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
RECEIVED
   ↓
VALIDATING_INPUT
   ├── invalid → BLOCKED
   ↓
TRIAGING
   ↓
PLANNED
   ↓
RUNNING_SPECIALISTS
   ├── partial failure → DEGRADED
   ↓
CORRELATING
   ├── evidence conflict → RESOLUTION
   ↓
GENERATING_REPORT
   ↓
FINAL_CHECK
   ├── failed → REPAIR
   ↓
COMPLETED

9.3 Orchestrator 伪代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
def run_performance_analysis(request):
    context = validate_and_normalize(request)
    signals = run_skill("baseline-triage", context)

    graph = build_task_graph(signals)
    results = {}

    while graph.has_ready_nodes():
        batch = graph.ready_nodes()
        batch_results = run_independent_skills_in_parallel(batch)

        for result in batch_results:
            validate_result_envelope(result)
            results[result.task_id] = result
            graph.update(result)

        if budget_exhausted() or no_progress(graph):
            break

    correlated = run_skill(
        "evidence-correlation",
        select_relevant_results(results),
    )

    report = run_skill(
        "report-generation",
        build_report_input(correlated, results),
    )

    return validate_final_report(report, context)

注意：这里的并行、状态更新、预算与 Schema 校验最好由运行时代码保障；Skill 指令负责描述策略和判定规则。

10. 结果合并不是简单拼接

多个 Skill 返回的内容不能直接依次放入报告。Aggregator 至少应做四件事。

10.1 证据去重

多个分析可能引用同一个时间段、指标或日志。应根据稳定标识去重，而不是靠文本相似度猜测。

10.2 证据关联

例如：

1
2
3
4
5
6
7
I/O latency ↑
    ↓
task enters uninterruptible sleep
    ↓
runnable pattern changes
    ↓
request latency ↑

这比把“I/O 异常”和“调度异常”并列展示更有价值。

10.3 冲突处理

如果两个 Skill 得出冲突结论，不要让最后执行者覆盖前者。应记录：

1
2
3
4
5
6
7
conflict:
  claim: CPU contention is primary cause
  supporting:
    - scheduler-analysis/evidence-3
  opposing:
    - io-analysis/evidence-7
  resolution: request additional off-CPU evidence

10.4 不确定性传播

下游不能把上游的低置信度推测改写成确定事实。报告中的结论强度，应受最弱关键证据约束。

11. 并行调用的安全条件

满足以下条件时，两个 Skill 才适合并行：

1
2
3
4
5
No data dependency
+ No conflicting write
+ Independent permission
+ Merge rule exists
+ Budget allows

例如，scheduler-analysis 与 memory-analysis 读取同一个不可变 trace，可以并行；但两个 Skill 都要启动独占系统采样器时，必须串行。

可以为每个任务声明：

1
2
3
4
5
6
7
reads:
  - artifact://normalized-trace
writes:
  - artifact://scheduler-findings
locks:
  - null
side_effects: none

调度器据此判断冲突，而不是让模型临场猜测。

12. 失败语义：局部失败不等于整体失败

多 Skill 系统至少需要四种结果：

1
2
3
4
completed  完整成功
partial    有结果，但证据或覆盖不完整
blocked    缺少输入、权限或用户决定
failed     执行失败且当前无法恢复

Orchestrator 应根据依赖关系判断影响：

子 Skill 状态 是否继续 处理方式
可选分析失败 是 标记覆盖缺口
关键上游失败 否 阻断依赖节点
部分成功 通常是 降低结论强度
权限阻塞 视情况 请求授权或走无权限路径
输出不符合 Schema 否 修复一次，随后失败

最终输出必须披露未完成的分支，不能把“其他 Skill 成功”包装成“整体完整成功”。

13. Skill 选择：自动触发与显式编排如何配合

Anthropic 官方文档说明，Skill 在可用环境中会根据任务相关性自动触发；其 metadata 用于发现，完整 SKILL.md 在触发后才加载。这使多个 Skill 可以按需组合，而不必预先把全部正文装入上下文。

但自动触发不等于无需编排。推荐分成两层：

1
2
3
4
5
Discovery Layer
  根据 name + description 找到候选 Skill

Execution Layer
  根据任务图、契约、权限和预算决定是否调用

对低风险开放任务，可以让模型动态选择；对高风险或稳定流水线，应显式规定允许的 Skill 集合、调用顺序和退出条件。

13.1 不要挂载所有 Skill

Anthropic 的 Managed Agents 文档明确提醒：挂载更多 Skill 会增加会话沙箱启动时间，应只附加当前 Agent 所需的 Skill。

工程上可以进一步建立 Capability Profile：

1
2
3
4
5
6
7
8
9
agent: performance-orchestrator
skills:
  always_available:
    - performance-triage
    - report-generation
  conditionally_mount:
    - scheduler-analysis
    - memory-analysis
    - io-analysis

这会比“全量挂载后依靠模型自律”更稳定。

14. Orchestrator Skill 的 SKILL.md 模板

下面是一个可复用骨架：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
---
name: performance-analysis
description: Orchestrate scheduler, memory, and I/O analysis for system performance incidents. Use when the user asks for cross-domain root-cause analysis or a consolidated performance report.
---

# Performance Analysis

## Role

Own task planning, specialist selection, evidence correlation,
final validation, and the user-facing report.

Do not perform deep scheduler, memory, or I/O analysis directly.

## Inputs

- Incident objective
- Time range
- Trace, metrics, or log artifact references
- Runtime and cost budget

## Workflow

1. Validate inputs and preserve originals as read-only.
2. Run baseline triage.
3. Build a dependency graph from observed signals.
4. Delegate only to relevant specialist Skills.
5. Run independent, read-only analyses in parallel.
6. Validate every returned result against its declared schema.
7. Correlate evidence; never concatenate findings blindly.
8. Resolve or disclose contradictory findings.
9. Invoke report-generation with selected evidence.
10. Run the final checklist before returning.

## Delegation rules

- scheduler-analysis owns scheduler evidence only.
- memory-analysis owns memory evidence only.
- io-analysis owns storage and I/O evidence only.
- Every specialist returns control to this Skill.
- Pass only the minimum context required by the subtask.

## Failure policy

- Block dependents when a required upstream result fails.
- Continue after optional branch failure and disclose the gap.
- Never present partial coverage as complete analysis.

## Final check

- Every conclusion references evidence.
- Evidence time ranges match the incident window.
- Conflicts and unknowns are visible.
- Recommendations follow from confirmed or clearly labeled hypotheses.

这个模板表达的是组合策略。真正的并行执行、超时、锁、Schema 校验和持久化状态，应由运行时或脚本完成。

15. 子 Skill 的最小模板

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
---
name: scheduler-analysis
description: Analyze scheduler traces and CPU scheduling symptoms. Use when run-queue delay, wakeup latency, CPU contention, or affinity problems require focused analysis.
---

# Scheduler Analysis

## Scope

Analyze only scheduler-related evidence.

## Required inputs

- task_id
- incident time range
- normalized trace reference
- analysis question

## Workflow

1. Validate trace availability and time range.
2. Calculate scheduler indicators.
3. Compare anomalies with the incident window.
4. Record evidence and counter-evidence.
5. Return scheduler_finding_v1.

## Boundaries

- Do not modify source artifacts.
- Do not generate the final incident report.
- Return memory or I/O observations as cross_domain_signals only.
- Return control to performance-analysis.

父 Skill 和子 Skill 都明确“做什么”和“不做什么”，组合关系才稳定。

16. Composition 与 Delegation 的区别

这两个概念经常混用：

概念 关注点 典型问题
Composition 能力怎样拼成更大能力 A、B、C 是顺序、并行还是路由关系？
Delegation 一次运行中任务怎样交出去 谁执行？传什么？何时归还控制权？

例如：

1
2
3
4
5
“性能分析由调度、内存和 I/O 分析组成”
→ Composition

“本次发现 runqueue 延迟，把 14:00-14:10 的 trace 交给 scheduler-analysis”
→ Delegation

Composition 是静态架构关系，Delegation 是动态执行行为。

17. 常见反模式

17.1 God Skill

一个总 Skill 同时包含所有领域知识和全部执行细节。结果是无法复用、难以测试、上下文巨大。

17.2 俄罗斯套娃式委派

子 Skill 随意继续委派，调用深度没有上限。最终无法判断控制权在哪里。

修复：规定最大深度、允许调用列表和返回规则。

17.3 自然语言作为唯一接口

子 Skill 返回散文，下游依靠模型重新理解。结果容易发生字段遗漏、事实升级和解析歧义。

修复：结构化 Envelope + 版本化 Payload。

17.4 把所有上下文广播给所有 Skill

这会增加成本，也会让专业 Skill 越界。修复方法是最小必要上下文和工件引用。

17.5 没有最终结果所有者

多个 Skill 各说一段，却没有组件负责冲突、去重和最终质量。修复：在设计开始时明确最终答复的 owner。

17.6 循环调用

1
Skill A → Skill B → Skill C → Skill A

修复：任务图尽量保持 DAG；若业务必须回环，则使用上一章的显式循环状态、进展条件和预算。

17.7 隐藏失败

某个分支失败后，系统仍输出漂亮报告，却不说明证据缺口。这是组合系统最危险的错误之一。

18. 可观测性：记录“为什么调用”，不只记录“调用了什么”

建议每次 Skill 调用产生统一事件：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
{
  "trace_id": "perf-20261007-001",
  "parent_task_id": "root",
  "task_id": "sched-001",
  "skill": "scheduler-analysis",
  "skill_version": "2.1.0",
  "reason": "runqueue_latency exceeded triage threshold",
  "input_artifacts": ["normalized-trace@sha256:..."],
  "status": "completed",
  "duration_ms": 18420,
  "output_schema": "scheduler_finding_v1",
  "token_usage": 4380,
  "warnings": []
}

至少要能回答：

  • 为什么选择这个 Skill；
  • 谁发起了委派；
  • 输入来自哪里；
  • 使用了哪个版本；
  • 是否发生 handoff；
  • 控制权最终回到哪里；
  • 哪个结果影响了最终结论。

否则，一旦最终报告出错，很难判断是路由错误、子 Skill 错误、数据契约错误，还是合并错误。

19. 多 Skill 组合的测试矩阵

单独测试每个 Skill 还不够，还要测试它们的连接处。

19.1 Contract Test

验证上游输出是否满足下游输入 Schema。

19.2 Routing Test

验证不同症状是否选择正确的 Skill，并确保不相关 Skill 不被调用。

19.3 Graph Test

验证依赖顺序、可并行节点和循环检测。

19.4 Partial Failure Test

让一个可选分支失败，检查系统是否继续并披露缺口；让关键上游失败，检查下游是否被阻断。

19.5 Conflict Test

让两个 Skill 返回矛盾结论，验证系统不会静默覆盖。

19.6 Context Isolation Test

验证子 Skill 只能得到完成任务所需的最小上下文和权限。

19.7 Ownership Test

验证 manager 模式下子 Skill 会归还控制权，handoff 模式下新 owner 能正确承接状态。

19.8 Version Compatibility Test

用新旧 Schema 组合运行，确认兼容版本成功、不兼容版本快速失败。

20. 如何判断应该拆成多个 Skill

并不是流程长就必须拆。OpenAI 官方建议只在专业能力能够显著改善能力隔离、政策隔离、Prompt 清晰度或 trace 可读性时增加 specialist；过早拆分会增加 Prompt、trace 和审批面。

可以使用以下判断表：

问题 倾向拆分
是否有独立、可复用的领域目标？ 是
是否需要不同工具或权限？ 是
是否有稳定的输入输出契约？ 是
是否能独立测试和版本化？ 是
是否可能被其他工作流复用？ 是
是否只是同一流程中的两三个简单步骤？ 否
拆分后是否只能互相传递大量隐式上下文？ 否

最稳妥的原则是：

从一个清晰的 Skill 开始，在职责、权限、上下文或输出契约真正发生变化时再拆分。

21. 官方资料带来的工程启示

21.1 OpenAI：先选择控制权模型

OpenAI 将 orchestration 的核心选择归纳为 handoff 与 agents-as-tools。对 Skill 系统而言，这意味着设计者首先要回答：子能力是接管对话，还是只返回有边界的结果？

21.2 OpenAI：专业化必须有实际收益

专业组件应该职责狭窄，描述简短具体；只有当分支真的需要不同指令、工具或政策时才值得拆分。

21.3 Anthropic：Skill 天然支持组合，但依赖渐进加载

Anthropic 将“组合多个 Skill 完成复杂多步骤任务”列为 Skill 的核心价值之一。metadata 常驻用于发现，SKILL.md 和资源按需进入上下文，因此组合不等于一次性加载全部内容。

21.4 Anthropic：可用数量不等于应该全部挂载

平台可以支持很多 Skill，但更多挂载会增加启动成本；应按 Agent 的职责附加必要能力，并把 Skill 来源纳入信任边界。

22. 本章最终模型

可以把多 Skill 系统浓缩成下面这张图：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
                  User Goal
                      │
                      ▼
             ┌────────────────┐
             │  Orchestrator  │
             │ owner / budget │
             └───────┬────────┘
                     │ build DAG
      ┌──────────────┼──────────────┐
      │              │              │
      ▼              ▼              ▼
Scheduler Skill  Memory Skill    I/O Skill
narrow contract  narrow contract  narrow contract
      │              │              │
      └──────────────┼──────────────┘
                     ▼
             Evidence Aggregator
          dedupe / correlate / resolve
                     │
                     ▼
             Report Generation
                     │
                     ▼
                Final Check

其中：

1
2
3
4
5
6
Orchestration 决定谁控制流程；
Composition 定义能力之间的静态结构；
Delegation 描述运行时如何交付子任务；
Dependency 决定节点何时可以执行；
Contract 保证结果可以可靠传递；
Ownership 保证最终有人负责。

23. Skill 专项复盘

23.1 这个逻辑应该写在 SKILL.md 还是运行时代码？

角色、路由原则、委派规则、输入输出语义和失败政策写在 SKILL.md；任务图调度、并发、锁、超时、持久化和 Schema 强校验由代码实现。

23.2 子 Skill 应该获得完整会话吗？

默认不应该。传递目标、必要事实、工件引用、约束和输出契约即可。只有 handoff 后需要承接用户交互时，才传递经过筛选的相关历史。

23.3 子 Skill 应该直接回答用户吗？

取决于所有权模型。manager 模式下只返回结构化结果；handoff 模式下可以接管该分支的用户答复。

23.4 什么时候可以并行？

没有数据依赖、写冲突和资源冲突，并且存在明确合并规则时才可以并行。

23.5 如何证明组合设计有效？

测量路由准确率、无效调用率、Contract 通过率、并行加速比、局部失败隔离率、冲突披露率、调用深度、上下文成本和最终任务成功率。

24. 本章实践

围绕 performance-analysis 完成以下设计：

  1. 定义总 Skill 的最终答复所有权；
  2. 为 scheduler、memory、I/O 和 report 四个子 Skill 划定职责边界；
  3. 分别写出输入输出 Schema；
  4. 画出包含数据依赖与条件依赖的 DAG；
  5. 标出可以并行和必须串行的节点；
  6. 为每次委派定义目标、上下文、权限、预算和返回规则；
  7. 设计统一结果 Envelope；
  8. 设计证据去重、关联和冲突处理规则；
  9. 模拟一个子 Skill 部分失败；
  10. 编写 Contract、Routing、Ownership 和 Version Compatibility 测试。

下一章将严格按照大纲进入：

第 19 章：Skill 之间如何避免职责重叠。

官方参考资料

AI > Agent Skill
#Agent Skill #Orchestration #Composition #Delegation #Dependency
Agent Skill 原理与工程实践（十八）：多个 Skill 如何组合与调用
https://cj0510.github.io/2026/10/07/AI/Skill/18-多个Skill如何组合与调用/
作者
CJ1018
发布于
2026年10月7日
许可协议
CC BY-NC-SA 4.0