MCP 课程学习笔记：我如何理解工具、上下文和 Agent

type

Post

status

Published

date

Mar 18, 2025

slug

mcp-course-learning-notes

summary

我把 MCP 当成连接模型、工具和数据源的一套通用协议来学习。真正重要的不是概念本身，而是它如何让 Agent 稳定拿到上下文并调用外部能力。

📝 主旨内容

如果大模型要真正进入工作流，它不能只会聊天，还要能稳定地读取资料、调用工具、写入系统。

我最开始学习 MCP 的时候，脑子里其实有一个很朴素的问题：为什么每个 AI 应用都要重新接一遍数据库、搜索、文件系统、Notion、GitHub？如果每个模型、每个客户端、每个工具都各自写一套适配逻辑，最后一定会变成一张很乱的网。

MCP 给我的第一层理解是：它把这种连接关系拆成更清楚的角色。模型所在的客户端负责发起请求，MCP server 负责暴露工具、资源和提示词，二者之间通过约定好的协议沟通。这样一来，工具不再是某个应用里的私有能力，而是可以被不同 AI 客户端复用的能力。

Agent 的能力上限，很大一部分取决于它能不能拿到正确上下文。

以前我用 AI 写代码，经常会遇到一种感觉：模型本身很强，但它不知道我的项目结构、不知道数据库字段、不知道当前页面状态，所以回答只能停留在泛泛而谈。MCP 把“外部上下文”变成了一等公民，工具可以返回结构化结果，资源可以提供文档或文件，客户端再把这些信息交给模型继续推理。

这让我重新理解了“上下文工程”。它不是简单把一堆文本塞进 prompt，而是设计一条可靠的数据通路：什么时候读取、读什么、怎么鉴权、结果如何压缩、错误如何暴露。MCP 的价值就在于让这些环节有一个相对统一的承载方式。

我以前很容易兴奋地给 Agent 接很多工具，但学 MCP 的过程中我反而更谨慎了。工具越多，模型的选择空间越大，错误调用、权限误用和信息泄露的风险也越高。

所以我现在更倾向于这样设计 MCP server：

这也是我后来写 Notion 发布 skill 时的一个启发：数据库要每次确认，封面要每次确认，发布状态也要显式确认。Agent 可以帮我提效，但边界要由我来定。

我现在会这样判断一个场景是否适合 MCP

如果答案大多是“是”，那我会优先考虑把它做成 MCP server，而不是写死在某个 prompt 或脚本里。

学完 MCP 后，我最大的感受是：它不是一个炫技协议，而是在给 Agent 应用补基础设施。模型负责推理，MCP 负责把工具和上下文稳定地送进来。

作为学习者，我现在还不会把 MCP 看成银弹。它解决的是连接问题，不自动解决权限、安全、工具设计和结果质量。但只要我想让 AI 真正参与工作流，MCP 就会是一个绕不开的基础概念。

💡

我后面如果继续深入 MCP，会重点看两块：一是权限和安全边界，二是如何把工具返回结果设计得更适合模型继续推理。