AGENT STACK · 2026

智能体 · MCP · Skill

智能体 Agent 运行时 · 决策与调度 Skill 技能包 教它「该怎么做」 MCP 协议 给它「能碰什么」 Agent 同时调度两者 缺任何一段都不闭环
🧩 三者分层
🔌 MCP 新规范
📦 渐进式披露
⚖️ 选型与成本
16 页 · ← → 翻页 · G 目录 · F 全屏 · P 导出
01 / 全景

三者不在同一层：不存在「选哪个」

它们是一条完整链路上的三段，各缺一段都跑不通。
1
Agent：运行时负责感知→规划→行动→观察的循环，把能力和知识编排成行动。
2
MCP：能碰到什么连接外部系统的协议层。凡需实时读写的外部资源都走这层。
3
Skill：该怎么做把 SOP、规范、模板封成文件夹，告诉 Agent 先后顺序与兜底。
4
组合才闭环Skill 编排步骤，MCP 提供执行这些步骤的工具。
会做 + 知道怎么做 + 够得着 = 交付
分层架构：越往下越「基础设施」 ① 智能体 Agent（运行时） 感知 → 规划 → 行动 → 观察 → 反思 ② Skill 知识层 SKILL.md + scripts/ + references/ + assets/ 静态文件 · 无进程 渐进加载 · 省 token 「怎么做 / 何时做」 ③ MCP 连接层 Tools / Resources / Prompts JSON-RPC · stdio / HTTP 跑进程 · 有鉴权 工具定义常驻上下文 「能碰到什么」 编排 ④ 外部世界：DB / API / 文件系统 / SaaS / 浏览器 Skill 无法直接触碰，必须借 MCP（或代码沙箱）落地 Skill 下发「做法」，MCP 真正执行并回传结果 结果回流 Agent → 继续下一轮循环
02 / 辨析

核心区别：一张表 + 一条判据

都能「扩展 Agent 能力」，但一个给能力、一个给方法。
维度Skill（怎么做）MCP（能碰到什么）
本质静态指令包（文件夹 + Markdown）客户端-服务器协议（跑进程）
触发方式描述命中后渐进式加载模型推理中自主决定调用
上下文成本未触发仅 ~50–100 token/个工具定义常驻，重 Server 可达上万
鉴权审计无内置鉴权，本地执行难观测OAuth 原生，可日志/限流/中心审计
实时数据❌ 内容凝固在创建时刻✅ 可接实时库、RAG、SaaS
更新方式改 Markdown 即可，无需重部署版本化 Server，需重新部署
典型场景代码评审、发版流程、领域规范接 Jira / GitHub / DB / 内部平台

🔑 唯一判据

缺的是「够得着」的能力 → MCP

缺的是「知道怎么做」的流程 → Skill

🧪 自检信号

  • 反复粘贴 curl 结果、SQL 查询、后台截图 → 缺 MCP
  • 每次都要重讲一遍团队规范 → 缺 Skill

🤝 不是二选一

Skill 定义流程与质量门禁，MCP 提供每一步的工具。真实工作流几乎总是两者叠加。

常见误解：「Skill 是轻量版 MCP」——错，它与工具调用毫无关系。
03 / MCP 协议

MCP：AI 应用的 USB-C

解决 N 个应用 × M 个数据源的集成爆炸。
1
连接层协议，不是 Agent 框架只定义「怎么连、怎么描述能力」，规划与编排是 Agent 的活。
2
集成成本 N×M → N+M双方各实现一次协议，无需为每个组合写适配。
3
与 Function Calling 的关系FC 是模型能力（何时调）；MCP 是接入协议（工具从哪来）。
4
治理成熟由 Linux 基金会旗下 AAIF 治理，官方 SDK 月下载近 5 亿。
集成成本：从 N×M 到 N+M 无 MCP：每个应用为每个数据源各写一套适配 App1 App2 App3 GitHub DB Jira 9 条连线 = 9 套适配 有 MCP：各实现一次协议 App1 App2 App3 MCP 协议 统一能力描述与调用 GitHub DB Jira 6 条连线 且随规模线性增长 生态：Claude、ChatGPT、VS Code、Cursor 等主流客户端均已支持 传输：stdio（本地进程）与 HTTP（远程服务）
04 / MCP 原语

三大原语：关键在「谁触发」

一个 Server 能暴露的能力只有三类。
谁来控制它？ 🔧 Tools　模型控制 让模型「做事」：执行函数、调 API、写文件，有副作用 name + description + inputSchema（JSON Schema） 例：建 Issue · 查 SQL · 发消息 · 部署 📄 Resources　应用控制 给模型「读数据」：只读、URI 标识、由 Host 决定何时注入 file:///README.md · postgres://db/tables · 可订阅 例：仓库文件 · 表结构 · API 文档 · 用户画像 💭 Prompts　用户控制 给用户「选模板」：参数化预定义提示词，UI 手动触发 把复杂多步指令固化为一致入口 例：代码评审模板 · 缺陷报告 · 周报模板 类比：Tools 是菜刀（动手）· Resources 是食材（原料）· Prompts 是菜谱（模板）
1
区分标准是控制方不是功能差异，而是由谁触发：模型 / 应用 / 用户。
2
Tools 最常用也最危险唯一能产生副作用的一类，需白名单与人工确认闸门。
3
协同顺序先 Resources 读状态 → 再套 Prompts 模板 → 最后 Tools 执行。
4
客户端侧原语Sampling（请求补全）与 Elicitation（索取输入），新规范改由 MRTR 实现。
05 / MCP 2026-07-28

最新规范：转向无状态核心

MCP 问世以来最大修订，共 9 项破坏性变更。
1
取消握手与会话移除 initialize 与 Mcp-Session-Id，请求自包含于 _meta。
2
可直接上 Serverless无需粘性会话，任意实例可接，Lambda / Workers 原生承载。
3
MRTR 多轮往返服务端返回 input_required，客户端带答案重放 → 工具必须幂等。
4
头部路由 + 可缓存列表必带 Mcp-Method/Mcp-Name，网关按头路由与鉴权。
5
授权加固RFC 9207 issuer 校验、DCR→CIMD；确立 12 个月废弃窗口。
有状态 → 无状态 旧规范：有状态双向 Client 握手 Server 会话ID 粘性会话+共享存储 • 必须握手，服务端内存维护连接状态 • 请求须路由到同一实例，难水平扩展 • 服务端发起请求需常开双向流 新规范：无状态请求/响应 Client 自包含请求（版本+能力在 _meta） 任意实例 / 网关 轮询负载均衡即可 • 无握手、无 Session ID，每请求独立自足 迁移要点（破坏性） 工具必须幂等（MRTR 会重放）· 网关需透传 Mcp-Method / Mcp-Name Python SDK 升至 2.0.0（FastMCP→MCPServer）· TS SDK 拆分多包
06 / MCP 工程

工程要点：成本、设计、安全

连得多了上下文被吃光，权限给大了会出事。
1
头号陷阱：上下文常驻工具定义常驻窗口，几个重型 Server 轻松吃掉上万 token。
2
工具设计原则一工具一职责、动词命名、返回精简、报错要能被模型读懂并自纠。
3
控量：少而准只连当前任务需要的 Server，合并细碎操作成一个粗粒度工具。
4
安全三主线提示注入 · 越权数据 · 信息外泄；工具返回视为数据而非指令。
5
可观测性优势中心化服务：调用可日志、限流、审计、告警，直接接入既有监控栈。
连接 Server 数 → 常驻上下文占用 高 0 1 个 3 个 5 个 8 个 12 个 工具定义 已吃掉 可观窗口 建议红线：工具定义 ≤ 10% 窗口 对策：按需挂载 · 合并细碎工具 · 精简描述 引用工具务必用完全限定名 ServerName:tool_name
07 / Skill 基础

Skill：把专业知识打包成文件夹

无进程、离线可用，2025-12 起成为开放标准。
1
极简本质一个目录 + 带 YAML frontmatter 的 SKILL.md，没有进程在跑。
2
目录结构SKILL.md 必需；scripts/、references/、assets/ 可选。
3
解决什么不必每次重讲规范与流程；也让非工程师能贡献能力。
4
开放标准规格在 agentskills.io，约 30–40 款产品支持同一套 SKILL.md。
一个 Skill 的标准目录 deploy-to-staging/ SKILL.md　← 必需 YAML frontmatter（name / description）+ Markdown 正文 scripts/　执行代码，运行即生效，不占上下文 preflight_check.sh rollback.py references/　按需加载的文档 runbook.md risk-checklist.md assets/　模板、样例、静态文件 frontmatter 规范（硬性） name：1–64 字符，小写字母/数字/连字符，须与目录名一致 description：1–1024 字符，须同时说清「做什么」与「何时用」 正文建议 < 500 行，超出拆进 references/
08 / Skill 核心机制

渐进式披露：最大的技术优势

三级加载，让「装几十个技能」几乎不占上下文。
1
L1 元数据（常驻）只有 name + description 进系统提示，约 50–100 token/个。
2
L2 正文（命中才加载）判断相关后才读 SKILL.md，约 ~500 token。
3
L3 引用文件（按需）scripts / references 用到才读，不用则零成本。
4
脚本的正确用法写「运行 validate.py」而非「阅读它」——执行不占文件内容的上下文。
三级加载漏斗 L1 · 元数据 name + description · ~50–100 token/个 · 常驻 L2 · SKILL.md 正文 命中才加载 · ~500 token L3 · 引用文件 / 脚本 按需探索 · 2000+ token · 不用则零成本 脚本执行：只把运行结果计入上下文 文件内容本身不进窗口 装 50 个技能对比：全量加载 ≈ 50,000+ token　vs　渐进式发现 ≈ 200–500 token
设计要点：description 决定会不会被命中，写得太口号化，技能就永远不触发。
09 / Skill 编写

写好一个 Skill：实战清单

失败模式很集中：该触发时不触发，或触发了做不对。

🎯 触发可靠

  • description 用完整句子，含领域关键词
  • 必须写清「做什么 + 何时用」
  • 按用户真实措辞补关键词

📐 结构克制

  • 正文 < 500 行，超出拆分
  • 引用保持一层深，别套娃
  • 术语一致，时效信息不写死

⚙️ 脚本优先

  • 确定性操作写成脚本，别让模型现生成
  • 显式声明依赖与安装步骤
  • 路径统一正斜杠

🧪 评估方法

  • 10–20 条真实查询测自动命中率
  • 对比开关技能后的 token 消耗
  • 弱/中/强模型各测一遍
与 MCP 协同时的写法 ✗ 错误写法 "用 create_issue 建一个单子" → 多 Server 环境下报 tool not found "用 pdf 库处理文件"（假设已装） → 环境无此包，执行直接失败 ✓ 正确写法 "用 GitHub:create_issue 建单，repo 取自 GitHub:list_repos" → 完全限定名 ServerName:tool_name，不歧义 "先 pip install pypdf，再 from pypdf import PdfReader" → 显式声明依赖，模型可自行补齐环境
权限收窄：用 allowed-tools 限定某技能激活时只能用指定工具，为只读或敏感流程加护栏。
10 / 协同链路

一次真实任务：三者如何配合

以「线上故障排查」为例。
任务：服务 P95 延迟突增，排查并给出结论 用户请求 "服务变慢了，查一下" Agent 匹配技能 命中 incident-triage Skill 加载 SOP 读 SKILL.md → 按步骤执行 MCP 提供工具 执行并回传真实数据 结论 + 证据 + 建议 附证据链与出处 Skill 定义的 SOP（左）与 MCP 实际执行（右）一一对应 SKILL.md 规定「怎么做」 ① 确认影响面：读最近部署与告警 ② 定位根因：查慢查询日志 + 错误率 ③ 有可疑变更 → 比对 diff 评估回滚 ④ 输出格式固定：结论/证据/影响/下一步 ⑤ 任一步失败 → 转人工，禁止臆造 ⑥ 回滚属高危：必须二次确认 （全是静态文本，Skill 自己不执行任何一步） MCP Server 提供「做得到」 ① Deploy:list_recent_deploys · Grafana:query ② Postgres:run_query（只读）· Logs:search ③ GitHub:compare_commits 拿到 diff ④ Agent 按 Skill 模板组织输出 ⑤ 工具报错 → 按 Skill 兜底规则处理 ⑥ Deploy:rollback 写操作 → 人工确认 （全部真实调用，可日志、可限流、可审计）
关键观察：少 Skill → 乱序调用、漏掉兜底与确认；少 MCP → 流程再好也只是纸上谈兵，够不着真实系统。
11 / 上下文账本

最本质的工程差异：常驻 vs 按需

选型时最易忽略、上线后最易爆雷的一项。
1
MCP：常驻成本工具定义连接时注册并常驻，用不用都占额度。
2
Skill：按需成本未触发仅几十 token，装 50 个也才几百 —— 用不上等于不要钱。
3
组合策略用 Skill 描述「什么场景启用哪些工具」，避免工具定义无差别常驻。
4
延迟与离线MCP 有网络往返与失败率；Skill 本地读取，几乎零延迟、无网络依赖。
上下文占用：随规模增长曲线 token 0 MCP：工具定义常驻，随 Server 数线性上涨 Skill：仅元数据常驻，几乎持平 规模 → 窗口红线 MCP 成本 ≈ Σ(工具数 × 定义长度)，与调用次数无关 Skill 成本 ≈ 元数据 + 命中后才计的正文
12 / 选型决策

四问定方案：遇到争论时按序过一遍

「要不要做成 MCP / Skill」的标准答案，藏在这四个问题里。
Q1
需读/写外部系统吗？要 → MCP，连接本身无法用文本模拟。
Q2
需要实时数据吗？要 → MCP。Skill 内容凝固在创建那一刻。
Q3
需鉴权、限流、中心审计吗？要 → MCP。Skill 本地执行，中心系统看不见。
Q4
是可复用流程/规范/判断吗？是 → Skill，尤其含先后顺序与质量门禁的。
Q5
答案是「都要」？正常。用 Skill 编排步骤、MCP 提供工具，这是生产环境常态。
决策路径 要扩展 Agent 能力？ 外部系统 / 实时数据 / 鉴权审计 MCP Server 「能碰到什么」 流程 / 规范 / 判断 Skill 技能包 「该怎么做」 Agent 统一调度 Skill 编排步骤 → MCP 执行动作 完整闭环：既知道怎么做，又真做得到 生产环境常见形态，不是「二选一」
反直觉提醒：「Skill + 代码沙箱 ≈ MCP」对个人成立，对企业不成立——凭证必须有地方放，MCP 把鉴权收在服务端。
13 / 治理

风险面不同：防护重点也不一样

把两者当成同一种风险来管理，是很多团队踩坑的起点。

⚠️ Skill 的风险

  • 恶意指令：正文里藏提示注入
  • 不安全 shell：scripts/ 越权
  • 凭证外泄指令：诱导读取密钥
  • 不可观测：本地执行，中心看不到

对策：仅用可信来源 · allowed-tools 收窄 · 安装前人工审阅 · 纳入代码评审。

⚠️ MCP 的风险

  • 权限过大：拿到超出需要的范围
  • 破坏性工具：删改发布无闸门
  • 数据外泄：返回含敏感信息
  • 注入载体：网页/文档经工具返回进入上下文

对策：最小权限 · 返回视为数据非指令 · 写操作白名单+人工确认 · 全量留痕。

🏛️ 治理成熟度

  • MCP：Linux 基金会 AAIF 治理；规范版本化，正式废弃策略 ≥12 个月
  • Skill：规格小、迭代快，由 Anthropic 维护；厂商实现细节有差异

实践含义：需合规审计的场景，关键动作放 MCP 侧，Skill 只承担流程描述。

共同底线：最小权限原则，破坏性动作一律留人工确认；Skill 脚本与 MCP 工具都应纳入生产代码同级评审。
14 / 落地路线

从 0 到 1：一条务实的构建顺序

别一上来搭框架、连一堆 Server；每步都能独立验证价值。

第一步 先写 Skill

  • 挑高频、有明确 SOP 的任务
  • 跑 10 条真实查询验证触发率
  • 确定性步骤抽成 scripts/
  • 零基础设施，当天可验证

第二步 标出「够不着」

  • 哪些步骤缺外部数据？
  • 哪些在靠人工粘贴？
  • 这些就是该上 MCP 的位置
  • 不为「以后可能用」提前接

第三步 按需接 MCP

  • 工具定义精简，控常驻 token
  • 只读优先，写操作后加
  • Skill 里用完全限定名引用
  • 写清失败兜底规则

第四步 补评测护栏

  • 金标集 + 坏例回归集
  • 成功率/触发率/token/P95
  • 高风险动作人工确认
  • 全量 trace，坏例沉淀回测
① Skill 沉淀流程 零基础设施 · 当天可验证 ② 按需接 MCP 只补「够不着」的环节 ③ 编排成闭环 Skill 定步骤 + MCP 给能力 ④ 评测 + 护栏 → 上线 可量化、可回滚、可审计 顺序反了（先接一堆 Server 再想流程）的典型结果：上下文被吃光、工具没人用、出事故查不到谁调的
15 / 速查

一页速查：记住这 12 条

遇到设计争论时回来对一遍。

🤖 Agent

  • 运行时：感知→规划→行动→观察→反思
  • 本身不提供能力与知识，只负责编排
  • 终止条件：步数、预算、时间、人工确认
  • 单步可靠性 > 重试次数（0.95¹⁰≈60%）

🔌 MCP

  • 连接层协议，N×M → N+M
  • 三大原语：Tools / Resources / Prompts
  • 2026-07-28 起无状态核心，可上 Serverless
  • 工具定义常驻上下文，连接数要克制

📦 Skill

  • 文件夹 + SKILL.md，静态、无进程、离线可用
  • 三级加载：元数据 → 正文 → 引用文件
  • description 决定触发，须写「做什么+何时用」
  • 确定性操作写成脚本：执行不占文件上下文

🚧 高频坑

  • 把 Skill 当「轻量 MCP」——与工具调用无关
  • Server 贪多，工具定义吃光上下文
  • 引用工具没写完全限定名 → 找不到
  • description 口号化 → 永不触发

✅ 上线自检

  • 每个工具都有明确场景，无僵尸连接
  • 每个 Skill 触发率达标（真实问法测过）
  • 写操作有白名单与人工确认
  • 有金标集、trace、成本告警与回滚

🔑 一句话总纲

Agent 负责把事做成
Skill 负责知道怎么做
MCP 负责够得着外部世界
同一条链路上的三段，缺一段都不闭环

按 G 打开目录 · P 导出 PDF · F 全屏演示
1 / 16
← → 翻页 · G 目录 · F 全屏 · P 导出