MCP on 随手记

客户端、Skill 与 MCP：大模型如何调用本地能力

Sat, 16 May 2026 08:35:00 +0800

很多人第一次接触大模型工具调用时，容易把几个角色混在一起：大模型是不是直接读取了本地文件？Skill 是不是一个可执行插件？MCP Server 是不是直接连到了模型？

实际链路更清晰，也更安全：模型只看见客户端发给它的上下文和工具定义；真正访问本地文件、数据库、命令行或服务的是客户端；MCP 是客户端调用本地能力的一种标准接口；调用结果再被客户端作为新消息发回模型。

总览：先看完整链路

一次完整交互可以拆成四步：

客户端读取用户问题，并加载本地 Skill、系统提示词、可用工具列表。
客户端把这些信息整理成一次模型请求，发给大模型。
大模型判断需要调用工具时，不直接执行本地动作，而是返回一个 tool_call 请求。
客户端根据 tool_call 调用本地 MCP Server，把结果作为 tool 消息回填给模型，模型再基于结果继续回答。

这里最重要的边界是：模型提出“我要调用什么”，客户端决定“能不能调用、怎么调用、结果如何回传”。

Skill 是什么：给模型看的操作说明

Skill 可以理解成一份本地能力说明书。它通常不是让模型直接执行的程序，而是一组面向模型的规则、流程、约定和示例。

例如，一个写博客的 Skill 可能告诉模型：

# Blog Writing Skill

- 写中文技术文章。
- 文件名必须是英文小写 slug。
- 创建文章前先读取已有标签。
- 图片必须通过 blog MCP 上传。
- 创建后再次读取文章确认 frontmatter 和图片引用。

客户端在发起模型请求前，会把匹配到的 Skill 内容放进上下文。于是模型知道：当前任务不是随便写一段 Markdown，而是要按照这个博客系统的规范完成“查标签、写正文、上传图片、创建文章、验证结果”这些步骤。

注意，Skill 本身不等于工具。它更像操作手册：告诉模型什么时候应该做什么、输出应该长什么样、有哪些约束不能违反。

MCP 是什么：给客户端调用的本地能力接口

MCP Server 则更接近真正的本地工具提供者。它把本地能力包装成结构化接口，比如：

{
 "name": "blog.create_post",
 "description": "创建一篇 Hugo 博客文章",
 "input_schema": {
 "type": "object",
 "properties": {
 "title": { "type": "string" },
 "content": { "type": "string" },
 "tags": {
 "type": "array",
 "items": { "type": "string" }
 },
 "draft": { "type": "boolean" }
 },
 "required": ["title", "content"]
 }
}

客户端启动或连接 MCP Server 后，会拿到这些工具定义。随后客户端可以把工具名、描述和参数结构告诉模型，让模型知道有哪些工具可用。

大模型周边概念速通：MCP、Skill、Agent、Tool 到底是什么

Wed, 29 Apr 2026 16:05:00 +0800

大模型应用发展到现在，很多词会一起出现：MCP、Skill、Agent、Tool、Prompt、Resource、Memory、Guardrail、Handoff、Plugin、Connector。它们看起来都像“给 AI 增强能力”的东西，但实际所在的层级完全不同。

如果把大模型应用想成一个软件系统：大模型负责理解和生成，Agent 负责决策和调度，Tool 负责执行动作，MCP 负责把外部能力标准化接进来，Skill 负责沉淀一套可复用的任务方法。理解这些边界之后，再看各种 AI IDE、智能客服、自动化助手、博客发布机器人，就不会被概念绕晕。

总览：先看一条完整链路

一次典型的大模型应用调用，可以拆成这条链路：

用户请求
 -> 应用 / Agent
 -> 组装 Prompt、历史记录、上下文 Resource、Memory
 -> 调用大模型
 -> 大模型决定是否调用 Tool
 -> Tool 可能来自本地代码、平台内置能力，或 MCP Server
 -> 工具返回结果
 -> Agent 继续推理、校验、生成最终回答

这里最容易混淆的是三层：

层级	解决的问题	典型概念
模型层	负责语言理解、推理、生成	LLM、大模型、多模态模型
编排层	决定怎么完成任务	Agent、Prompt、Memory、Guardrail、Handoff
能力接入层	连接外部数据和动作	Tool、MCP、Resource、Connector、Plugin、Skill

一句话概括：大模型是大脑，Agent 是工作流控制器，Tool 是手，MCP 是标准插口，Skill 是做事手册和工具包。

大模型：能力核心，但不是完整应用

大模型，也就是 LLM 或多模态模型，核心能力是根据上下文预测和生成内容。它可以读文字、写代码、解释日志、分析图片、生成计划，但它本身通常不直接拥有你的文件系统、数据库、浏览器、Git 仓库、公司内部系统权限。

所以，大模型应用真正要解决的是：

给模型什么上下文。
允许模型调用哪些能力。
模型何时该自己回答，何时该查数据或执行动作。
工具调用前后如何校验安全性和结果质量。
多步骤任务失败时如何恢复。

这就是 Agent、Tool、MCP、Skill 等概念出现的原因。

用 MCP 管理 Hugo 博客：这个项目是怎么搭起来的

Tue, 28 Apr 2026 16:45:00 +0800

这个仓库表面上是一个很轻量的 Hugo 博客，实际目标更明确：把博客内容、构建部署、以及 AI 写作入口放在同一个工程里。最终形成的工作流是：文章仍然以 Markdown 存在仓库中，Hugo 负责生成静态站点，仓库流水线负责构建部署，而 mcp/ 目录里的 MCP 服务负责给 AI 提供一组可控的读写工具。

项目目标

这个项目解决的是一个很具体的问题：写博客时不想每次都手动打开仓库、创建 frontmatter、提交文章、再等待部署。更理想的方式是直接和 AI 对话，让 AI 能够读取已有文章、理解站点配置、创建新文章、修改元数据，必要时还能上传图片。

为了不把 AI 直接暴露给整个文件系统，项目没有设计成“随便执行命令”的形式，而是把能力收敛成 MCP 工具。每个工具只做一件事，例如列文章、读文章、创建文章、更新文章、上传图片。这样既方便使用，也比较容易控制边界。

顶层结构

当前仓库大致分成几块：

.
├── hugo.toml # Hugo 站点配置
├── content/ # 博客内容
│ ├── about.md
│ └── posts/ # Markdown 文章目录
├── layouts/partials/ # 本站覆盖的局部模板
├── themes/terminal/ # Hugo terminal 主题
├── .github/workflows/ # 构建与部署流水线
└── mcp/ # 自定义 blog MCP 服务

hugo.toml 定义站点基础信息，例如语言、标题、主题、分页和菜单。文章目录使用 Hugo 默认的 content/posts。内容层仍然保持 Hugo 最朴素的方式：每篇文章是一个 Markdown 文件，文件头部用 TOML frontmatter 描述标题、日期、标签、摘要等信息。这样即使以后不使用 MCP，也不会被锁死在某个特殊系统里。