OpenClaw Sub-Agent vs Skill 选型指南

OpenClaw Sub-Agent vs Skill 选型指南

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

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

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

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

特征很明确:

  • 主 agent 在自己的 session 里直接执行
  • 占用主 agent 的上下文窗口
  • 文件位置: 或

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

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

通过 工具创建:

调用是非阻塞的,立即返回 。主帅发出调令,不必站在城头等回信。

参数 类型 默认值 说明 string 必填 子 agent 要执行的任务描述 string — 短标签,便于识别 string 调用者的 openclaw skills 教程 agent 目标 agent id string — 覆盖模型 string — 覆盖思考级别(off/low/medium/high) number 0(无限) 超时自动中止 string keep keep=归档保留 / delete=立即清理

模型选择遵循 first match wins 规则,依次查找:

  1. 调用中显式指定的
  2. per-agent 配置:
  3. 全局默认:
  4. 目标 agent 的正常模型解析

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


四步走完,一次委派的生命便结束了。归档不是销毁——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 进程内,用 控制并发上限
维度 用 Skill 用 Sub-Agent 任务复杂度 简单,几步完成 多步骤长流程 上下文消耗 小,规则简短 大,规则/数据量多 是否阻塞主对话 是,占用主 agent 回合 否,后台运行 用户交互 需要频繁交互 给任务后自主跑完 独立性 依赖主 agent 上下文 完全独立,有自己的 workspace 模型选择 跟随主 agent 可用更便宜的模型 典型场景 工具用法说明、格式转换、快速查询 文件整理、批量处理、长时间研究

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

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

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

问题显而易见:

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

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

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

配置结构:


中的关键配置:

用户说一句”整理桌面”,主 agent 匹配 skill,调用 ,子 agent 在后台自主跑完扫描、分类、确认、移动的全流程,最后 announce 结果回来。主对话全程不阻塞。

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

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

通过 命令随时检视和调度:

命令 说明 列出所有子 agent(活跃+已完成) 停止指定子 agent 查看子 agent 对话记录 查看运行元数据 向运行中的子 agent 发消息

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

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

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请联系我们举报,一经查实,本站将立刻删除。

发布者:Ai探索者,转载请注明出处:https://javaforall.net/252828.html原文链接:https://javaforall.net

(0)
上一篇 2026年3月13日 下午4:26
下一篇 2026年3月13日 下午4:26


相关推荐

关注全栈程序员社区公众号