阅读要点
Agent负责理解、规划和执行。
Skill把领域方法封装成可复用说明书。
MCP提供访问外部系统与数据的能力。
Hook在固定生命周期节点自动触发动作。
一、Agent 与 Skill 的基本认识
Agent 是执行者,Skill 是专业说明书。Agent 本身具备理解意图、拆解任务、选择工具和完成操作的能力;Skill 则把某个领域的知识、步骤、脚本和素材整理成标准化工作包,让 Agent 面对同类任务时更稳定。
这和新同事入职很像。能力强的人能处理陌生问题,但如果同时拿到审核标准、操作 SOP、检查清单和现成脚本,结果会更快、更一致,也更容易复盘。Skill 的价值,就是把“高手经验”变成“任何合适的 Agent 都能调用的工作方法”。
1.1 一个 Skill 通常包含什么
常见 Skill 以SKILL.md为入口,再按需携带脚本、参考资料和素材。不同宿主可能对文件名或目录约定略有差异,应以对应平台的安装说明为准。
my-skill/
├── SKILL.md # 必需:名称、触发场景、工作流与边界
├── scripts/ # 可重复执行的 Python、Bash 等脚本
├── references/ # 详细规范、接口说明、检查清单
└── assets/ # 模板、图片和交付素材
SKILL.md:回答“这是什么、什么时候用、怎么做、什么时候停止”。
scripts:承接自由度低、容易出错或需要反复执行的步骤,例如格式校验、批量转换和结果检查。
references:保存不必每次全部加载的细节,例如标签规范、接口参数和长检查清单。
assets:保存交付时直接复用的模板、示例图片或品牌素材。
不是每个 Skill 都必须有四类目录。最小可用形态只有一个写清楚的SKILL.md;当任务变复杂,再把确定性步骤下沉为脚本,把大段细节移到参考资料中。
1.2 Skill 如何工作
Skill 的核心机制是渐进式披露(progressive disclosure):先暴露少量元数据,只有在任务匹配后才加载完整说明,执行中再按需读取更细的资料。
Agent 启动时扫描已安装 Skill 的名称与描述,知道自己“会什么”。
用户提出需求后,Agent 将意图与 Skill 描述进行匹配。
匹配成功后,Agent 读取对应的
SKILL.md,理解 SOP、输入输出和限制。任务需要复杂细节时,再读取
references或执行scripts。全部步骤结束后,Agent 校验并整合结果,再返回给用户。
这套机制避免了两个极端:一是把全部知识长期塞进上下文,导致信息冗余;二是只给 Agent 一个工具,却不给它判断何时使用、如何使用以及如何验收的方法。
二、Skill、MCP 与 Hook
三者解决的是不同层级的问题:Skill 管方法,MCP 管能力,Hook 管自动触发时机。
概念 | 主要作用 | 典型内容 | 触发方式 |
|---|---|---|---|
Skill | 告诉 Agent 怎样完成专业任务 | 指令、知识、脚本、模板、检查项 | 根据用户意图按需加载 |
MCP | 让 Agent 访问外部系统和数据 | 工具名称、参数定义、返回结构 | Agent 根据任务主动调用 |
Hook | 在固定节点自动执行动作 | 命令、脚本、检查、通知或回调 | 命中生命周期事件后自动运行 |
以内容审核为例:Skill 规定标签标准、审核步骤和边界案例的处理方法;MCP 读取待审数据集并提交审核结果;Hook 在提交前检查敏感字段,在任务结束后记录审计日志。三者组合后,Agent 才同时拥有方法、工具和自动防线。
MCP 不是必选项。若任务只需要调用一个简单命令,可以直接在 Skill 中写清参数和验收方式。只有当外部系统接入复杂、接口需要复用,或权限与返回结构需要统一管理时,才值得单独建设 MCP。
三、Skill 的安装与卸载
Skill 通常不会自动跨平台同步。即使目录格式兼容,同一份 Skill 也需要分别安装到 Aime、豆包、Trae 或自建 Agent 的对应宿主中。
3.1 从技能市场安装
最省事的方式是进入技能市场,搜索目标能力,选择安装到对应 Agent。安装页通常会给出支持的平台、版本、权限和具体命令。The Agent Skills Directory
3.2 通过安装命令添加
有些技能市场会提供终端命令。命令通常会检测本机已安装的 Agent,并询问目标宿主或安装路径。也可以把完整命令发给支持执行安装的 Agent。
示例:
npx -y --registry https://bnpm.byted.org @byted/tae@latest \ skills add <skill_name>
npm_config_registry=https://bnpm.byted.org \ npx agentbuddy@latest skill add \ skills.byted.org/test_infra/bits_ut \ --skill bits-unit-test-gen
命令执行成功只代表下载或安装步骤完成。最终还要检查目标 Agent 是否识别到 Skill、描述能否被正确匹配,以及一次真实任务能否跑通。
也可以直接选择要安装的agent就行(安装界面有的话)
3.3 在豆包中安装
豆包办公的本地工作区通常会区分系统预置目录与用户技能目录:
workspace/.skills/:系统预置 Skill。workspace/.user_skills/:用户自己安装的 Skill。
手动放入用户目录可以作为调试方式,但更推荐直接把安装包、技能名、仓库地址或安装命令交给 Agent,由它完成安装并验证识别结果。
3.4 在 Aime 中安装
Aime 常见的输入方式包括 ZIP 压缩包、Skill 名称、安装命令、Git 仓库和从零创建。只提供 Skill 名称时,可先搜索当前空间和技能市场,再从候选中确认目标;提供仓库时,还要明确版本和仓库内路径。
支持安装方式 | 需要提供 | 处理方式 |
|---|---|---|
ZIP 压缩包 | 完整 Skill 压缩包 | 将skill.zip上传给aime,aime会自动解压+安装到技能空间 |
Skill 名称 | 名称或希望实现的能力 | aime会调用skill查找的skill,先查当前空间,再搜索技能市场(内部skills.byted.org+外部skills.sh),生成候选,并让用户确认候选 |
安装命令 | 完整命令及必要参数 | 在skill广场获取目标skill的下载安装命令,将命令发送给agent即可 cli: npx skills add https://github.com/firebase/agent-skills --skill firebase-security-rules-auditor 命令成功不一定代表空间安装成功 |
Git 仓库 | 仓库、版本、仓库内 Skill 路径 | 字节仓库可绑定同步;其他仓库通常先下载再上传 |
从零创建 | 目标能力、触发场景、输出和边界 | 创建、验证后上传到空间 |
在 Aime 中,安装完成的判断不是“某条下载命令返回成功”,而是目标 Skill 已上传到当前技能空间并可被识别。这个区别能避免“终端里装过了,但 Agent 仍然不会用”的假成功。
3.5 卸载与更新
卸载优先使用宿主的技能管理页或让 Agent 执行卸载流程;本地调试环境才直接删除用户 Skill 目录。删除属于破坏性操作,应先确认目标名称与安装位置,必要时备份自定义脚本和素材。更新后也要重新检查描述匹配、依赖版本和关键用例。
四、在自建平台中接入 Skill
自建平台不只是“扫描一个文件夹”。要让 Skill 稳定工作,至少需要五个环节:
发现:扫描 Skill 的名称、描述和版本等元数据。
路由:根据用户意图匹配合适的 Skill,并处理多个候选的优先级。
加载:先读入口说明,再按需加载参考资料和脚本。
执行:为脚本、网络访问和文件操作设置权限边界与超时。
验收:记录调用过程、检查输出,并提供版本更新和回滚能力。
如果平台缺少权限隔离和可观测性,Skill 越多,排查成本反而越高。先把安装、路由、日志和失败处理做扎实,再扩充技能数量。
五、怎样写好一个 Skill
一个可用的SKILL.md至少要回答三个问题:它是谁、什么时候触发、触发后怎么完成任务。
--- name: my-skill description: 说明这个 Skill 能做什么、何时触发,以及关键关键词。 --- # Skill 标题 ## 适用场景 ## 输入与输出 ## 工作流 ## 注意事项与边界
name是 Skill 的唯一标识,通常与文件夹名一致;description是路由入口,决定 Agent 能否在正确时机找到它;正文则负责把操作步骤、工具选择、校验标准和停止条件讲清楚。
5.1 Description 决定“能不能被找到”
“这是一个很有用的 Skill”几乎没有路由价值。好的描述要写出能力、触发场景和用户常用表达。例如:
name: content-risk-boundary-review description: 为内容风控、模型评测和标注质检生成最小边界对照样本;当用户提到误杀、漏放、边界 case、规则冲突或回归样本时使用。
这段描述同时告诉 Agent:要做什么、服务于哪个领域、哪些关键词应触发。描述越具体,误触发和漏触发越少。
5.2 工作流要写到可执行、可验收
“分析数据并给出建议”不是 SOP。可执行的写法会明确输入检查、处理顺序、异常分支和验收条件。例如,边界样本 Skill 可以规定:先确认原标签与规则,再一次只改变一个变量,随后输出成对样本、风险翻转假设、预期标签和复核重点。
可重复且确定的步骤适合放进脚本;大段规范适合放进参考资料;模板和示例图片放进素材目录。入口文件只保留路由信息和任务主干,避免越写越长。
5.3 明确边界比堆功能更重要
写清不适用场景,避免 Skill 抢到不属于自己的任务。
涉及删除、发布、发消息等外部写操作时,规定确认机制。
涉及业务规则时,注明版本、来源和待确认项,不让 Agent 自行补全。
定义成功标准,例如文件生成、平台识别、用例通过或结果回填。