MCP、Skills 与 Agent 控制面¶

从 Function Calling 到 MCP，再到 Skills / Subagents / AGENTS.md，本质上是在把 agent 工程标准化。

1. 为什么会有这条演进链¶

最早的模式是：

模型输出文本
程序员自己解析文本去调用工具

后来变成：

Function Calling / Tools——模型原生支持结构化工具调用，不再需要手动解析

再后来变成：

MCP——标准化工具接入协议，一次对接多处复用，解决"N 个模型 × M 个工具"的碎片化问题

再往上演进则是：

Skills——把可重复的工作流封装为标准化指令包，让 agent 自动知道该做什么
Subagents——将任务委派给具有隔离上下文的子代理，支持并行与专业化分工
AGENTS.md——将项目规则持久化到 agent 可读取的上下文中
企业级 control plane——统一治理权限、审计与策略

这条链背后的目标很明确：

更稳定地接工具（从手动解析到标准化协议）
更清晰地描述能力（从单次调用到可复用的任务方法包）
更方便治理与复用（从零散 prompt 到标准化、可移植的工程流程）

2. 四个概念怎么区分¶

概念	本质	典型作用
Tool / Function	单次能力调用，定义始终在上下文中	查天气、读文件、执行命令
MCP	工具与上下文接入协议，连接外部系统与数据	标准化连接数据库、API、云存储等外部能力
Skill	面向任务的能力封装，渐进式加载（元数据常驻、指令触发时加载、资源按需加载）	营销分析、代码审查、文档生成等可重复工作流
Control Plane	治理与审计层	权限白名单、操作日志、策略执行、回滚机制

可以把它理解成：

Tool 是零件——锤子、锯子，定义（名称、描述、参数）始终在上下文中
MCP 是接口标准——把不同品牌的零件统一接入
Skill 是装好的工具包——包含说明书（指令）、零件（脚本）、参考手册（资料），只在需要时打开
Control Plane 是工厂管理系统——决定谁能用什么工具、记录每次操作

3. AGENTS.md 和 Skills 为什么重要¶

AGENTS.md 的价值在于把仓库规则、流程、命令、限制，放进 agent 可读取的上下文——它在每个会话中自动加载，是 agent 理解项目约定的"入职手册"。

Skills 的价值在于把一类任务沉淀成可复用方法。一个 Skill 本质上是一个结构化的文件夹，核心是 SKILL.md 文件（含 YAML 元数据 + Markdown 指令），并可搭配 scripts/（脚本）、references/（参考资料）、assets/（模板与资源）三个可选目录。它解决的是：

什么时候该做什么——通过 YAML 中的 name 和 description 让 agent 自动识别何时触发
具体怎么做——Markdown 正文定义步骤化的工作流指令
需要什么辅助——脚本、参考资料、模板按需加载，不浪费上下文窗口
产出格式是什么——明确的输入输出规范确保结果一致

这比只给一个 prompt 更稳定，因为它更接近工程流程，而不是一次性文本指令。没有 Skills 时，每次都要重新描述指令、重新打包参考资料，且难以保证流程或产出一致。

4. 企业为什么需要控制面¶

如果 agent 能：

改代码
跑命令
调数据库
访问外部系统

那企业一定会关心：

什么工具能用
谁能调用
调了什么
出错了怎么追责
怎么回滚

所以 agent control plane 不是额外花活，而是生产化必需品。

5. 你在项目里至少要做的治理动作¶

最低限度建议：

明确工具白名单
区分只读与可写工具
对命令执行保留日志
对高风险操作要求人工确认
对 agent 输出做 review / test gate
对失败任务保留回放信息

6. 面试高频问法¶

为什么有了 tools 还要 MCP？
为什么有了 MCP 还要 Skills / Subagents？
Skill 和 RAG 的边界在哪？
如果 agent 能执行 shell，你怎么做权限控制？
你怎么避免 agent 滥用工具或误删内容？

7. 在本仓库里的对应位置¶

更偏工具与协议：本页
更偏系统与编码： 03-MCP与工具生态
更偏项目交付： 09-Agentic软件工程项目交付模板

如果你想冲 AI Coding / Agent 平台 / DevEx 方向，这页是必须讲明白的。

⚠️ 核验说明（2026-03-26）：本页已纳入 2026-03-26 全站统一复核批次。若文中涉及外部模型、API、版本号、价格或第三方产品名称，请以官方文档和实际运行环境为准。

最后更新日期： 2026-03-26