第三章：Skill 生态与插件化架构设计

“陈小鱼看着后台面板上那211个Skill的列表，陷入了深深的无力感。作为大厂AI Agent平台的产研负责人，她的团队花了8个月搭建了一个’人人都能提交Skill’的开放平台——初衷是好的，结果却是一场噩梦：重复的Skill（光’天气查询’就有6个），无文档的Skill（137个只有标题没有说明），还有3个Skill被安全团队紧急下架——因为它们能绕过权限直接读用户通讯录。距离CEO要求的下季度GMV目标还有6周，陈小鱼知道她需要的不只是更多Skill，而是一套全新的设计哲学。”

3.1 Skill 的本质：为什么大模型不够用？

前两章我们讲了Agent需要理解用户意图、管理对话状态。这些是Agent的"大脑"。但大脑想得再好，没有手也做不了任何事。Skill就是Agent的"手"。

但很多PM对Skill的理解停留在"给大模型加个API调用"上。这是一个需要立刻纠正的误解。

"你能调API"就是Skill吗？

来看两组对比：

误区型"Skill"（林然第一版的实现）：

// prompt里写：当用户问物流时，调用track_order_api
// 把API文档塞进system prompt
// 上线，祈祷

设计型Skill（林然第二版的重构）：

Skill: 物流查询 (track-order-v2)
├── 描述：查询指定订单的实时物流状态
├── 输入槽位：order_id(必填), phone_last4(选填)
├── 输出格式：{ status, location, estimated_delivery, history[] }
├── 权限要求：用户本人订单或客服权限
├── 超时策略：3s超时→告知用户"稍后自动通知"
├── 失败策略：API不可用→读取缓存→缓存也空→"我暂时查不到，30分钟后重试"
├── 使用示例："帮我查下JD123到哪了"
└── 测试用例：3个正向+2个异常+1个边界

二者的核心区别：前者是一段prompt instruction，后者是一个完整的"能力产品"。前者上线后出了问题你只能改prompt，后者每个环节都是可定位、可修复、可独立测试的。

这一区别就是整个第三章要展开论述的核心——Skill不是"调个API"，而是Agent的最小可交付能力单元。

Skill 的原子化三原则

既然Skill是能力单元，那怎么定义一个好的Skill？陈小鱼经过了那场211个Skill的治理噩梦后，总结了三条铁律：

原则一：单一职责（Single Responsibility）

一个Skill只做一件事，但要把这件事做到极致的"产品化完成度"。不是"能调接口就行"，而是包含输入校验、输出格式化、错误分类、用户提示——

• ✅ 好的Skill定义：物流查询（含超时重试、缓存降级、异常用户提示）
• ❌ 坏的Skill定义：订单相关操作（把查物流、改地址、取消订单揉一起，调用方不知道每个子功能的状态）

原则二：可组合（Composable）

Skill应该像乐高积木。复杂的任务不是靠一个巨大的Skill完成，而是靠多个小Skill串联。这意味着每个Skill的输出必须是下一个Skill可以消费的格式：

• ✅ "查物流"的输出包含标准化的order_id和location，可以被"判断是否延迟"这个下游Skill直接使用
• ❌ "查物流"返回一大段自然语言描述，下游Skill需要重新做NLP来提取信息

原则三：可测试（Testable）

一个Skill应该能脱离整个Agent独立测试。如果测试一个Skill需要拉起整个对话系统，这个Skill的设计耦合度就太高了：

• ✅ 给一个order_id，Skill返回确定性的结构化结果
• ❌ “调一下试试，看它能返回什么”

这三条原则看起来简单，但陈小鱼的团队在实际执行中发现：遵守原则的Skill大约占20%，但贡献了90%以上的用户成功任务。 剩下的80%混乱Skill，用户很少用、用了也容易出错。

---

3.2 MCP 协议：为什么Agent需要"USB接口"

如果说Skill是Agent的能力单元，那么MCP（Model Context Protocol）就是这些单元的"接口标准"。

2024年底之前，每个Agent产品给模型加工具的方式各不相同——有的写进system prompt、有的走Function Calling JSON Schema、有的自己搭middleware。结果是：每换一个模型或框架，所有工具集成要重做一遍。这个状态就像智能手机出现前，每个手机都有自己的充电口。

MCP协议的出现改变了这个局面。它的设计哲学可以用一句话概括：定义了一套Agent与外部工具/数据源之间的标准通信协议，让Skill可以"即插即用"。

MCP的架构层

用户对话层
    ↓
[Agent核心] ←→ [MCP Client]
                   ↓ (标准协议)
              [MCP Server A] ── 负责数据库操作 (SQL查询、读写)
              [MCP Server B] ── 负责文件系统 (读取、搜索)
              [MCP Server C] ── 负责外部API (CRM、ERP、邮件)
              [MCP Server D] ── 负责知识库 (RAG检索)

每一个MCP Server封装了一类能力域，Agent通过统一的Client协议与这些Server通信。对产品经理来说，这意味着：

1. 工具接入标准化：新增一个外部系统（比如对接一个新的CRM），不再需要改Agent核心代码，只需部署一个新的MCP Server
2. 跨模型复用：换模型（从GPT换到Claude，或同时支持多个模型）时，工具层不需要改动
3. 权限管控集中化：MCP层可以做统一的鉴权和审计，不用在每个Skill里重复实现

数据佐证：根据行业调研数据，采用MCP协议的企业在AI Agent集成效率上提升了约90%，代码复用率达到80%。这不是协议本身多神奇，而是标准化的力量——把"每次集成都是新项目"变成了"写一个标准的Connector"。

产品经理的MCP设计Checklist

MCP不是纯技术议题。以下问题需要PM在设计中回答：

设计决策	你要定义什么
MCP Server的粒度	一个系统一个Server？还是一个业务域一个Server？（推荐后者）
哪些操作暴露为工具	不是所有API都该变成工具——只暴露Agent真正需要执行的原子操作
工具的"人类可读"描述	每个工具的description字段要写得多详细？（建议包含：干什么、输入什么、输出什么、什么时候用）
MCP Server的权限范围	这个Server能访问哪些数据？读写还是只读？有没有速率限制？

---

3.3 从单 Agent 到多 Agent 协作：编排的艺术

讲完单个Skill的设计和MCP的标准化接入，我们自然会遇到下一个问题：当Agent需要执行复杂任务时，是让一个大而全的Agent自己调度所有Skill，还是分派给多个Agent各司其职？

这就是多Agent协作（Multi-Agent System, MAS）的设计问题。

三种编排模式

模式一：单Agent调度（1 Agent × N Skills）

适合场景：任务有明确的线性流程，所有Skill调用共享同一个上下文。

[用户意图] → [一个Agent] → [解析意图 → 选Skill1 → 等结果 → 选Skill2 → 等结果 → 汇总]

优点是简单，缺点是复杂任务中Agent容易"迷路"——它既要理解用户、又要选Skill、又要判断结果、又要处理异常，一个context window里塞了太多信息。

模式二：主从Agent（1 Orchestrator × N Specialist Agents）

适合场景：任务可以被自然拆分成多个独立的子任务。

[用户: 下周杭州出差，全帮我安排]
         ↓
[Orchestrator Agent]
    ├→ [旅行Agent]    查航班、比价、订票
    ├→ [酒店Agent]    查酒店、比价、预订
    ├→ [日程Agent]    查客户、约时间、发邀请
    └→ [汇报Agent]    汇总三个结果，统一展示

每个Specialist Agent只专注于自己的领域，有自己的工具集（MCP Server集群）。Orchestrator负责拆解任务、分派子任务、汇总结果。

模式三：对等协作（Peer-to-Peer）

适合场景：任务没有明确的"主Agent"，多个Agent需要互相协商。

[代码Agent] ←→ [测试Agent]
     ↕              ↕
[安全Agent]  ←→ [文档Agent]

例如一个代码审查场景：代码Agent写完代码后，自动通知测试Agent生成测试、安全Agent做静态分析，三者互相通知结果，最终汇总到文档Agent生成报告。

选型决策矩阵

场景特征	推荐模式	关键风险
任务线性、步骤少（≤5步）	单Agent调度	Agent上下文过载
任务可拆分为独立子任务	主从Agent	编排Agent本身复杂
多角色需要持续交互	对等协作	通信开销、一致性
MVP阶段	从单Agent开始	不要过早优化

陈小鱼的经验：他们的平台最初也是单Agent调度，直到一个"同时处理售后+退款+重新发货"的复杂场景出现，单Agent经常把不同售后类型的流程搞混。拆成[售后Agent]和[物流Agent]后，各自维护自己的对话状态和工具集，任务成功率从68%提升到了89%。拆分的代价是编排层的复杂度增加了大约30%的开发工作量，但用户价值是确定的。

---

3.4 案例拆解：pm-skills——把一整套PM方法论装进插件生态

如果说前面是理论，那这一节是活生生的工程实践。

pm-skills 是一个在GitHub上获得15900+ Star的开源项目，由社区开发者维护。它的架构是我们讨论的Skill生态设计的绝佳范例。

三层架构：Skill → Command → Plugin

Plugin（打包单元，按领域组织）
├── pm-product-discovery (13 Skills, 5 Commands)
├── pm-product-strategy  (12 Skills, 5 Commands)
├── pm-execution         (16 Skills, 11 Commands)
├── pm-market-research   (7 Skills, 3 Commands)
├── pm-data-analytics    (3 Skills, 3 Commands)
├── pm-go-to-market      (6 Skills, 3 Commands)
├── pm-marketing-growth  (5 Skills, 2 Commands)
├── pm-toolkit           (4 Skills, 5 Commands)
└── pm-ai-shipping       (2 Skills, 5 Commands)
        ↓
  [68个Skill = 原子能力单元]
  [42条Command = 链式工作流 = 多个Skill的组合]
  [9个Plugin = 按产品领域的打包单元]

Skill是原子单位。 比如 opportunity-solution-tree 这个Skill，它内嵌了Teresa Torres的OST方法论——知道怎么引导你从 Outcome → Opportunity → Solution → Experiment 逐层展开。Skill文件本身是一个Markdown文档，里面包含了方法论知识、使用场景、输入输出规范。

Command是用户触发的链式工作流。 比如 /discover 命令会串联4个Skill：brainstorm-ideas → identify-assumptions → prioritize-assumptions → brainstorm-experiments。每一步暂停让用户审阅，用户可以随时调整方向。

Plugin是打包单元。 按PM工作领域组织，一个Plugin安装后，该领域的所有Skill和Command一次性可用。

三个值得PM学习的设计决策

决策一：Skill文件就是产品文档

每个Skill是一个独立的.md文件，包含了该能力的完整定义。这不是"开发文档"，这就是产品——Skill文件同时是给AI看的instruction，也是给人类开发者看的接口文档。这意味着Skill的设计天然就要求"自解释"。

决策二：用Command串联, 不是硬编码工作流

/discover、/write-prd这些Command不是预设的固定流程。它们是多个Skill的"推荐串联方式"。用户可以跳过某个步骤、调整顺序、或在中间插入其他Skill。这种"软编排"设计比硬编码的工作流引擎灵活得多。

决策三：复用优先

prioritization-frameworks 这个Skill被 /discover、/write-prd、/triage-requests 等多个Command共享。pm-skills的架构鼓励这种复用——被复用的Skill会被更多的使用场景打磨，质量天然更高。

---

3.5 Skill 市场的冷启动与治理

陈小鱼平台上的211个Skill中，合格的只有约40个。这不是技术问题，是产品治理问题。

Skill市场的"冷启动死亡螺旋"

绝大多数Skill市场（包括WorkBuddy的Skill生态）都会经历这个阶段：

Skill少 → 用户发现不了价值 → 贡献者没动力 → Skill继续少

打破这个死循环的关键不是"激励更多贡献者"，而是以下三个产品策略：

策略一：种子Skill的质量比数量重要100倍

陈小鱼后来总结：平台刚上线时，应该由团队精雕细琢20个Skill，让第一批用户用完之后觉得"这个Agent真能干"——这20个Skill就是用户信心的锚点。 而不是急着开放提交入口，收进来200个半成品。

策略二：Skill必须有"社交证明"

用户怎么知道一个Skill靠不靠谱？需要三样东西：

• 使用次数和成功率：这个Skill被调用了多少次？成功率是多少？
• 用户评分+使用评价：不只是打分，还有"这个Skill在什么场景下好用/不好用"
• 维护者活跃度：最近更新时间、响应issue的速度

策略三：安全审核不能事后补

陈小鱼最大的教训是——3个越权Skill被发现之前，它们已经运行了2周。安全审核必须是Skill上架的第一道门，不能靠用户反馈来发现安全问题。

Skill治理Checklist

治理维度	具体措施	频率
准入审核	代码审查、安全沙箱测试、文档完整性检查	每个新Skill上架前
质量评级	成功率、响应时间、用户评分三维度评估	每周自动更新
废弃管理	连续30天零调用→标记"休眠"；90天零调用→下线	每月清理
安全巡检	权限变更检测、异常调用模式告警	实时监控
兼容性	Skill接口变更后的下游影响评估	每次发布前

---

3.6 决策矩阵与本章小结

Skill架构选型矩阵

你在什么阶段	Skill策略	MCP策略	编排策略
0→1 MVP	自建5-10个核心Skill	按需集成，先不做MCP封装	单Agent调度
PMF验证期	扩展至20-30个Skill	核心系统走MCP标准化	单Agent→主从（看需求）
规模化前	开放Skill提交+治理体系	全部外部系统MCP化	主从为主，特定场景对等
平台化	完整的Skill市场+生态激励	MCP Server SDK开放给第三方	三种模式按场景混用

本章核心要点

1. Skill不是"调个API"，是Agent的最小可交付能力单元。 一个好的Skill包含：输入输出定义、权限模型、超时/失败策略、测试用例——这才叫"产品化"。
2. MCP协议让工具接入从"项目级集成"变成"生态级互操作"。 它的价值不在协议本身，而在标准化带来的接入效率提升和权限集中管控。
3. 多Agent协作不是银弹。 单Agent调度在主流程清晰的场景下反而更稳定。选择编排模式的核心判断标准是：子任务是否独立、是否需要独立的状态管理。
4. Skill市场的第一性原理不是"多"，是"好"。 20个精雕细琢的种子Skill > 200个半成品。
5. 治理不是后续工作，是Skill生态的一等设计要素。 准入审核、安全巡检、废弃管理——上线第一天就要有，不能等出事了再补。

行动建议

• 今天就做的：盘点你Agent产品中现有的所有"工具调用"——有多少是只有API调用的裸接口？有多少是包装了输入校验、错误处理、用户提示的完整Skill？
• 本周完成的：选你的Agent中最核心的3个任务，按照本章的Skill设计三原则（单一职责、可组合、可测试）重构——写下每个Skill的完整定义。
• 长期建设的：如果你计划做Skill生态/市场，先写完20个种子Skill的完整文档（不是API文档，是"这个Skill能帮用户做什么"的产品文档），再考虑开放平台。

---

Skill让Agent有了"手"——能查询、能操作、能执行。但"手"的能力越强，越需要回答一个严肃的问题：哪些事Agent可以帮用户做？哪些绝对不能碰？这就是第四章的核心——安全合规与边界设计。陈小鱼的平台上有3个Skill因为越权被下架，如果那时的她有一份安全设计蓝图，那场危机本可以避免。