importzhh

Skills、子代理与行为塑造:三种形态的一种能力

Agent; Skills; MCP; 子代理; 行为塑造 1958 字 10 min read

本文是「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 社区约定一致(注意

hub,不是有治理机构的正式标准)。

渐进式披露

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 的极简规则。

这一派回答的核心问题各不相同:

项目内核问题
SuperpowersAI 会不会在压力下绕过规则?
Karpathy SkillsAI 的默认行为模式对不对?
ECCAI 有没有这个领域的背景知识?

Superpowers

Superpowers 最有价值的贡献,是它把”Skill 设计”当成可测试、可迭代的工程问题,而不是一次性文档写作。它的实测数据很惊人:

组合使用 Authority(权威)+ Commitment(承诺)+ Scarcity(稀缺)三种说服原则,AI 对规则的合规率从 33% 提升到 72%。

它的做法是 Iron Law + Red Flags + Rationalization 表:

  • Iron Law
    ,用强硬措辞写死
  • Red Flags
    即将违规时的征兆
  • Rationalization 表
    AI 违规时的理由化措辞,然后逐条反驳——因为 AI 绕过规则前,总会先给自己找个”这次情况特殊”的借口

两条被验证的反直觉规则

agent开发 从 Superpowers 的实证里提炼了两条:

  1. CSO 规则(Config-Say-Only)

    的 description 字段只能写触发条件,绝对不能写流程摘要。因为 AI 读完 description 觉得”我懂了”,就会跳过正文。描述越完整,正文越容易被忽略。

  2. 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