Skills、子代理与行为塑造:三种形态的一种能力
本文是「Agent 从概念到系统」系列第 12 篇。前面几篇把 Agent 的内部结构拆完了。这一篇讲怎么给 Agent 加新能力——以及一个容易被忽视的事实
,选错了要么烧钱要么埋雷。
每个团队第一次遇到”Agent 缺一种能力”时,第一反应都是**“再派一个 Agent”**。
大多数情况下,正确答案是**“写一个 Skill”。次多数情况下,正确答案是”接一个 MCP 服务器”**。完整的 Agent 循环是最强也最贵的选项——只在工作真的需要自己的上下文和推理时才用,其余场景几乎都用不上。
一个默认用子代理的团队,会累积看不见的成本(每次 spawn 都是一个完整模型循环)和迟早要还的复杂度(多智能体编排带来单 Agent 没有的失败模式)。一个懂决策规则、从最轻量级开始的团队,跑得更快、代码更干净。
三种形态,各一句话
同一种能力——比如”review 这个 PR”——可以有三种形态。选最轻的那个:
- Skill Agent 提示词的 Markdown 指令,教模型怎么用它已有的工具去做一件重复的事。
- MCP 服务器,把能力暴露成工具供 Agent 调用;能力活在 Agent 之外,可跨多个 Agent 复用。
- 子代理(Subagent) Agent 为一个有界子任务派生的完整 Agent 循环,有自己的提示词、工具集、预算和结果契约(见第9篇)。
一句话记住成本梯度:Skill 便宜,教模型”怎么做”;MCP 中等,隔离”执行”;子代理昂贵,隔离”推理”。
决策规则
| 你的情况 | 用哪个 |
|---|---|
| 模型已有工具,只是不知道怎么组合做一件重复的事 | Skill |
| 需要一个模型没有的外部能力(查数据库、调 API、控浏览器) | MCP 服务器 |
| 子任务需要自己的上下文、不同的模型/工具集,或要隔离推理 | 子代理 |
一个反直觉但重要的判断:Skill 比 MCP 服务器更危险。服务器的工具在进程隔离里执行;Skill 的文本在你模型的提示词里执行。后面会展开这一点。
Skill 的解剖
一个 Skill 是带 YAML frontmatter 的 Markdown 文件:
---
name: review_typescript
description: Review TypeScript code for type, async, and security issues.
version: 1.2.0
platforms: [coding-agent, code-review-bot]
prerequisites: [typescript-installed]
---
# 审查 TypeScript 代码
按此顺序审查:
1. 检查 public 函数入参是否有类型
2. 检查 async 错误是否被处理(没有被吞掉的 promise)
3. 检查用户可控的字符串是否安全地到达 shell / SQL / HTML sink
4. 先报告问题,再提风格建议
5. 引用你评论的 file:line
不要编造问题。不确定就标"建议人工复审"然后继续。五个字段在生产系统里反复出现:name、description、version、platforms、prerequisites。正文是自由 Markdown——指令、示例、坑。这个格式跟 agentskills.io 社区约定一致(注意
渐进式披露
Skill 的加载遵循第6篇讲过的渐进式披露:Skill 索引(名字+描述+版本)每轮都在提示词里,几百个 token,不管你有多少 Skill;Skill 正文通过 skill_view(name) 工具按需加载。
这里值得重申的一点
,每个正文都是潜在的提示注入面。二十个精准的 Skill,持续优于两百个大多不相关的。 长期不用的 Skill 该归档。Skill 的信任与提示注入风险
这是全系统杠杆最高的攻击面之一。一个 Skill 是 Agent 每个 session 都当指令读的文本——恶意 Skill 换个名字就是提示注入。默认原则:把每个用户安装或 hub 分发的 Skill 都视为不可信,除非有理由不这么做。
- 来源(Provenance) Skill 带
name、version和source(来源 URL/hub 条目/文件路径)。来自 bundled 集合之外的 Skill 不该悄悄进索引。 - 安装时审批 Skill 是一次人在环路审批,跟新 MCP 服务器一样。进索引前,把 Skill 正文的每一行都展示给用户看。
- 正文扫描。一个包含 “ignore previous instructions” 的 Skill 永远到不了提示词。
行为塑造派 Markdown 也能约束 AI
agent开发 系列横评的 16 个项目里,有一整个流派叫行为塑造派——它们不写代码、不接工具,只用 Markdown 约束 AI 的行为。代表是 Superpowers、ECC、Karpathy 的极简规则。
这一派回答的核心问题各不相同:
| 项目 | 内核问题 |
|---|---|
| Superpowers | AI 会不会在压力下绕过规则? |
| Karpathy Skills | AI 的默认行为模式对不对? |
| ECC | AI 有没有这个领域的背景知识? |
Superpowers
Superpowers 最有价值的贡献,是它把”Skill 设计”当成可测试、可迭代的工程问题,而不是一次性文档写作。它的实测数据很惊人:
组合使用 Authority(权威)+ Commitment(承诺)+ Scarcity(稀缺)三种说服原则,AI 对规则的合规率从 33% 提升到 72%。
它的做法是 Iron Law + Red Flags + Rationalization 表:
- Iron Law,用强硬措辞写死
- Red Flags 即将违规时的征兆
- Rationalization 表 AI 违规时的理由化措辞,然后逐条反驳——因为 AI 绕过规则前,总会先给自己找个”这次情况特殊”的借口
两条被验证的反直觉规则
agent开发 从 Superpowers 的实证里提炼了两条:
-
CSO 规则(Config-Say-Only)
的description字段只能写触发条件,绝对不能写流程摘要。因为 AI 读完 description 觉得”我懂了”,就会跳过正文。描述越完整,正文越容易被忽略。 -
Liking 原则必须禁用
Skill(比如 TDD、安全)里,不能用”讨好/亲和”的语气——它会直接摧毁 AI 对抗压力的能力。要严厉,不要友好。
三种形态如何演进
一个能力常常从一种形态迁移到另一种:
- 一个 Skill 用久了发现需要真实执行(不只是指令)→ 升级为 MCP 服务器
- 一个反复出现的工具序列 → Hermes 的 curator 会把它自动写成新 Skill(skills that write skills)
- 一个 Skill 需要自己的上下文和推理循环 → 升级为子代理
关键是从最轻的形态开始,让需求把它往上推,而不是一上来就派子代理。
小结
- 加能力有三种形态(教怎么做)、MCP(隔离执行)、子代理(隔离推理),成本递增,不可互换。
- 默认从 Skill 开始。子代理是最贵的,只在需要独立上下文/推理时用。
- Skill 比 MCP 更危险——它的文本在你的提示词里执行。把它当提示注入面对待、审批、正文扫描。
- 行为塑造是一门可测量的工程 用说服原则把合规率从 33% 做到 72%,CSO 规则和禁用 Liking 是两条反直觉但被验证的经验。
主要参考:
- Agentic System Course ch14(Skills, MCP, and Subagents)
- 《16个开源Agent项目》系列 Skill设计哲学与质量体系
- 《16个开源 AI Agent 项目全面差异对比》维度 2/5/11(工具与Skill、行为塑造、Skill质量体系)
- Superpowers(obra/superpowers)、ECC、Karpathy Skills
