OpenClaw Sub-Agent vs Skill 选型指南

2026-02-10 OpenClaw AI Agent 子智能体 Skill 多智能体架构

《韩非子·扬权》有云："事在四方，要在中央。"治理的关键，在于知道什么该亲力亲为，什么该委任于人。AI agent 的架构设计，竟也暗合此理。

OpenClaw 提供两种机制扩展 agent 的能力：Skill（技能注入）与 Sub-Agent（子智能体）。一个是把规矩写进主帅的脑子，一个是另遣偏将独当一面。两者定位不同，选错了，轻则上下文溢出徒耗 token，重则主对话阻塞、长流程半途而废。

本文从机制、创建、生命周期到选型做完整梳理，并以一次真实改造收尾。

Skill：写在墙上的规矩

Skill 的本质，是一段注入主 agent system prompt 的指令文本。它以 SKILL.md 的形式存在，session 启动时根据 metadata 门控规则筛选，符合条件的 skill 被编入系统提示词——就像衙门口张贴的告示，来者皆可读取，但占据的是公共墙面。

特征很明确：

主 agent 在自己的 session 里直接执行
占用主 agent 的上下文窗口
文件位置：<workspace>/skills/<name>/SKILL.md 或 ~/.openclaw/skills/<name>/SKILL.md

Skill 适合轻量的事——格式转换、工具用法说明、快速查询。就像贴在墙上的操作手册，翻一眼就能照做。

Sub-Agent：另遣偏将

Sub-Agent 则是另一番气象。它是独立隔离的 session（agent:<agentId>:subagent:<uuid>），有自己的 workspace、AGENTS.md、认证体系和会话存储。后台非阻塞运行，做完了才回来禀报——颇有"将在外，君命有所不受"的意思。

通过 sessions_spawn 工具创建：

1
2
3
4
5
6
7
8
9
sessions_spawn({
  task: "整理桌面文件，来源目录 ~/Desktop",
  agentId: "desktop-organizer",
  label: "organize-files",
  model: "kimi-coding/k2p5",        // 可选，覆盖默认模型
  thinking: "low",                    // 可选，覆盖思考级别
  runTimeoutSeconds: 600,             // 可选，超时中止
  cleanup: "keep"                     // keep=归档保留 / delete=立即清理
})

调用是非阻塞的，立即返回 { status: "accepted", runId, childSessionKey }。主帅发出调令，不必站在城头等回信。

参数一览

参数	类型	默认值	说明
`task`	string	必填	子 agent 要执行的任务描述
`label`	string	—	短标签，便于识别
`agentId`	string	调用者的 agent	目标 agent id
`model`	string	—	覆盖模型
`thinking`	string	—	覆盖思考级别（off/low/medium/high）
`runTimeoutSeconds`	number	0（无限）	超时自动中止
`cleanup`	string	keep	keep=归档保留 / delete=立即清理

模型解析的优先级

模型选择遵循 first match wins 规则，依次查找：

sessions_spawn 调用中显式指定的 model
per-agent 配置：agents.list[].subagents.model
全局默认：agents.defaults.subagents.model
目标 agent 的正常模型解析

这意味着你可以让主帅用最好的模型思考全局，而派出去跑腿的偏将用便宜的模型就好。

生命周期：从调遣到归档

Spawn → Run → Announce → Archive

1. Spawn    主 agent 调用 sessions_spawn，非阻塞返回
2. Run      创建隔离 session，在 subagent 专用队列执行
3. Announce  完成后将结果摘要+统计发回主 agent 的 session
4. Archive   默认 60 分钟后自动归档（可通过 archiveAfterMinutes 配置）

四步走完，一次委派的生命便结束了。归档不是销毁——transcript 被重命名保留，日后可以调阅，像是存入了档案室的卷宗。

约束：偏将也有不能做的事

不能嵌套：子 agent 不能再 spawn 子 agent。没有"将中将"，只有一层委派
精简上下文：只携带 Tooling/Workspace/Runtime + AGENTS.md + TOOLS.md，不含 SOUL.md/IDENTITY.md/USER.md。轻装上阵
工具受限：默认拒绝 sessions_spawn、gateway、memory_search 等工具
Announce 是尽力而为：gateway 重启会丢失未完成的 announce。战报送到一半，驿站塌了，也是有的
共享进程资源：子 agent 仍在同一 gateway 进程内，用 maxConcurrent 控制并发上限

选型：何时立规矩，何时派人手

维度	用 Skill	用 Sub-Agent
任务复杂度	简单，几步完成	多步骤长流程
上下文消耗	小，规则简短	大，规则/数据量多
是否阻塞主对话	是，占用主 agent 回合	否，后台运行
用户交互	需要频繁交互	给任务后自主跑完
独立性	依赖主 agent 上下文	完全独立，有自己的 workspace
模型选择	跟随主 agent	可用更便宜的模型
典型场景	工具用法说明、格式转换、快速查询	文件整理、批量处理、长时间研究

一言以蔽之：Skill 是"教主 agent 怎么做"，Sub-Agent 是"派一个独立的人去做"。 任务越重、上下文越大、自主性越强，越该用 Sub-Agent。

实战：desktop-organizer 的改造

纸上得来终觉浅。以下是一次真实的 Skill → Agent 改造记录。

改造前：四百行规矩贴满墙

desktop-organizer 最初是一个纯 Skill。SKILL.md 洋洋洒洒 400 余行，塞满了坚果云目录结构、三级分析策略、课程名精确匹配表、重命名规则……全部注入主 agent 的 system prompt。

问题显而易见：

每次对话都占用 token，即使用户根本没打算整理文件
执行时阻塞主对话，用户只能干等
上下文窗口被大段分类规则挤占，影响其他任务的质量

这就像把整本《大清律》刻在县衙的照壁上——来办任何事的人，都得先看完这面墙。

改造后：轻量触发 + 独立执行

改造的思路很简单：SKILL.md 瘦身为 46 行的触发器，只告诉主 agent"遇到整理文件的请求时，派 desktop-organizer agent 去干"。全部分类规则迁入 agent 自己的 AGENTS.md，住在独立的 workspace 里。

配置结构：

~/.openclaw/openclaw.json                        # agents.list 注册 agent
~/.openclaw/workspace-desktop-organizer/
  └── AGENTS.md                                   # agent 系统指令（分类规则+工作流程）
~/.openclaw/workspace/skills/desktop-organizer/
  └── SKILL.md                                    # 轻量触发器（spawn 入口）

openclaw.json 中的关键配置：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
{
  "agents": {
    "list": [
      { "id": "main", "default": true, "name": "Main Assistant" },
      {
        "id": "desktop-organizer",
        "name": "Desktop Organizer",
        "workspace": "~/.openclaw/workspace-desktop-organizer"
      }
    ]
  }
}

用户说一句"整理桌面"，主 agent 匹配 skill，调用 sessions_spawn(agentId: "desktop-organizer")，子 agent 在后台自主跑完扫描、分类、确认、移动的全流程，最后 announce 结果回来。主对话全程不阻塞。

四百行的照壁，变成了一纸调令。

全局配置参考

如果你管辖着多个子 agent，可以在全局设置默认行为：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
{
  "agents": {
    "defaults": {
      "subagents": {
        "model": "minimax/MiniMax-M2.1",
        "thinking": "low",
        "maxConcurrent": 4,
        "archiveAfterMinutes": 30
      }
    }
  }
}

管理子 agent

通过 /subagents 命令随时检视和调度：

命令	说明
`/subagents list`	列出所有子 agent（活跃+已完成）
`/subagents stop <id>`	停止指定子 agent
`/subagents log <id> [limit]`	查看子 agent 对话记录
`/subagents info <id>`	查看运行元数据
`/subagents send <id> <msg>`	向运行中的子 agent 发消息

余论

技术架构的选择，说到底是分寸感的问题。什么该内化为本能（Skill），什么该委派给独立个体（Sub-Agent），没有放之四海皆准的答案。但有一条朴素的判断标准：如果你发现主 agent 的 system prompt 因为某个 skill 变得臃肿，而那个 skill 描述的又是一个可以独立完成的长流程——那它就不该是一段规矩，而该是一个人。

古人说"用人不疑"。对 Sub-Agent 也是如此：给它清晰的任务，给它独立的空间，然后等它回来交差。