跳到主要内容

MCP（模型上下文协议）

先用一句话说清楚​

MCP（模型上下文协议）是一种让模型客户端以统一方式连接外部工具、资源和上下文的协议。

新手通俗解释​

可以把 MCP（模型上下文协议）理解成“AI（人工智能）应用连接工具的插座规范”。没有统一规范时，每个工具都要单独接：文件系统一种接法，数据库一种接法，浏览器一种接法，企业系统又一种接法。MCP（模型上下文协议）希望把这些工具、资源和上下文用更统一的方式暴露出来，让客户端更容易发现和调用。

但要注意：MCP（模型上下文协议）不是魔法。它解决的是连接方式和生态标准化问题，不自动解决权限、安全、业务校验和结果质量。

为什么智能体工程师岗位会问它​

现在很多岗位把 MCP（模型上下文协议）写进 JD（职位描述），面试官想看的不是你能背协议名，而是你是否理解工具生态接入和企业安全边界。

他们通常会观察 4 件事：

考察点应该怎么理解
协议定位MCP（模型上下文协议）用于连接工具和上下文，不等于业务系统本身
Client（客户端）与 Server（服务端）客户端发起使用，服务端暴露工具、资源或提示能力
安全边界工具必须有白名单、权限、审批、审计和沙箱
工程取舍不是什么项目都必须上 MCP（模型上下文协议），普通 API（应用程序接口）也能先落地

它在项目里到底怎么用​

以“业务工具调用平台”为例，你可以先把工具分成三层：

层级做什么是否必须用 MCP（模型上下文协议）
业务 API（应用程序接口）查询订单、创建工单、读取资料、提交反馈不一定
工具治理层定义工具名称、参数、权限、审计、超时和失败处理必须设计
MCP（模型上下文协议）接入层把部分工具或资源按协议暴露给客户端视项目需要

作品集里可以这样讲：我不会为了追热点强行使用 MCP（模型上下文协议）。如果项目目标是展示工具治理，可以先用普通 Tool Calling（工具调用）完成；如果目标是展示生态接入能力，再把工具注册、工具发现、资源读取和权限审批抽象成 MCP Server（模型上下文协议服务端）。

常用 MCP（模型上下文协议）能力类型​

学习 MCP（模型上下文协议）时，不要只问“有哪些热门 MCP Server（模型上下文协议服务端）”。更重要的是按能力分类，知道每类能力适合解决什么问题。

能力类型连接对象适合场景风险边界
Filesystem MCP（模型上下文协议）文件、目录、项目资料、配置读项目、生成文档、整理资料防止误删、越界读取和泄露敏感文件
Git（版本控制工具） MCP（模型上下文协议）提交、分支、差异、历史记录代码审查、变更复盘、发布说明防止误合并、误回滚、误推送
GitHub（代码托管平台） MCP（模型上下文协议）Issue（议题）、Pull Request（合并请求）、CI（持续集成）任务管理、PR（合并请求）审查、自动化检查控制写权限和自动触发范围
Browser MCP（模型上下文协议）页面、表单、截图、控制台前端验收、静态站检查、登录流程排查禁止自动提交高风险表单
Database MCP（模型上下文协议）表结构、样本数据、查询结果报表分析、后台排查、数据问答只读优先，生产写入必须审批
Vector Database（向量数据库） MCP（模型上下文协议）向量索引、检索片段、相似度结果RAG（检索增强生成）调试、知识库质量检查防止跨租户检索和错误引用
Search MCP（模型上下文协议）Web（网页）、站内搜索、企业知识库查官方文档、找资料、补上下文标注来源和时间，避免不可靠内容
Document MCP（模型上下文协议）PDF（便携式文档格式）、Word（文字文档）、Excel（电子表格）资料解析、报告生成、版式检查防止表格误读、格式丢失和引用缺失
Deployment MCP（模型上下文协议）服务器、Nginx（反向代理服务器）、对象存储、面板静态站发布、日志检查、服务状态确认高风险动作要审批和回滚
Observability MCP（模型上下文协议）日志、指标、Trace ID（追踪编号）、告警线上排障、智能体运行复盘日志脱敏，避免误判
Ticket MCP（模型上下文协议）工单、审批、客服系统、CRM（客户关系管理系统）客服 Agent（智能体）、审批预检、任务跟踪写入业务系统必须有人确认

作品集优先展示 2 到 3 类能力即可。比如 Filesystem MCP（模型上下文协议）加 Browser MCP（模型上下文协议）可以证明你会读项目和验收页面；再加 Deployment MCP（模型上下文协议）或 GitHub（代码托管平台） MCP（模型上下文协议），就能讲出完整工程闭环。

和普通 API（应用程序接口）的区别​

普通 API（应用程序接口）通常是业务系统之间的明确调用；MCP（模型上下文协议）更面向模型客户端使用工具和上下文的统一接入。两者不是替代关系。

面试时可以这么说：API（应用程序接口）是业务能力本身，MCP（模型上下文协议）是把这些能力以智能体可发现、可描述、可调用的方式暴露出来。真正关键仍然是工具权限、参数校验、执行审计和失败兜底。

MCP（模型上下文协议）和 Skill（技能）怎么配合​

很多新手会把 MCP（模型上下文协议）、Tool Calling（工具调用）和 Skill（技能）混成一个概念。面试时要分清层次：

概念负责什么不负责什么
MCP（模型上下文协议）把外部工具、资源和上下文以统一方式暴露给客户端不自动决定任务流程
Skill（技能）规定某类任务应该怎么做、什么时候调用工具、哪些动作要审批、如何验收不等于具体工具连接协议
Tool Calling（工具调用）在某一步真正请求使用工具不保证业务安全和结果质量
Guardrail（护栏）限制越权、误操作、敏感数据和高风险动作不替代业务需求判断

可以这样理解：MCP（模型上下文协议）解决“工具怎么接进来”，Skill（技能）解决“接进来的工具应该怎样被正确使用”。一个企业级 Coding Agent（智能体）通常需要两者配合：MCP Server（模型上下文协议服务端）提供浏览器、文件、数据库、知识库或部署能力；Skill（技能）规定调用顺序、权限限制、失败处理、人工确认和验证标准。

面试回答可以这样组织：

我不会把 MCP（模型上下文协议）理解成完整智能体。它主要是工具和资源接入层。真正做任务时，还需要 Skill（技能）定义流程，例如先读取上下文、再制定计划、再调用工具、最后运行验收；同时要有 Guardrail（护栏）和 Audit（审计）记录，避免工具越权和不可追踪执行。

常见误解​

误解为什么不对正确理解
MCP（模型上下文协议）就是 Tool Calling（工具调用）Tool Calling（工具调用）是模型请求用工具的能力，MCP（模型上下文协议）是工具和上下文的连接协议两者可以配合，但不是同一层
MCP（模型上下文协议）就是 Skill（技能）Skill（技能）是任务流程和边界，MCP（模型上下文协议）是连接工具和资源的协议一个解决怎么接工具，一个解决怎么把工具用对
上了 MCP（模型上下文协议）就安全协议不等于安全策略权限、审批、日志和沙箱仍要自己设计
所有项目都应该用 MCP（模型上下文协议）小项目可能普通 API（应用程序接口）更直接先看交付目标和工具生态需求
MCP Server（模型上下文协议服务端）越多越好工具越多，误用风险越高需要白名单、分级权限和审计

面试官可能怎么追问​

1. MCP（模型上下文协议）和 Tool Calling（工具调用）是什么关系？​

考察点： 是否能分清协议层和调用能力。

参考回答： Tool Calling（工具调用）强调模型在任务中请求使用工具；MCP（模型上下文协议）强调把外部工具、资源和上下文以统一协议暴露给客户端。可以把 MCP（模型上下文协议）看成工具生态接入方式之一，最终仍然要落到工具定义、参数校验、权限和执行审计。

容易扣分： 说“MCP（模型上下文协议）就是把 API（应用程序接口）改个名字”。

2. 企业项目接 MCP（模型上下文协议）最大的风险是什么？​

考察点： 是否有安全意识。

参考回答： 最大风险是把过多工具暴露给模型，导致越权读取、误操作、敏感信息泄露或不可追踪执行。所以我会做工具白名单、用户身份绑定、权限范围、只读与写入分级、高风险审批、日志脱敏和 Trace ID（追踪编号）追踪。

容易扣分： 只讲“接入很方便”，不讲治理。

3. 不会 MCP（模型上下文协议）是不是不能做智能体工程师？​

考察点： 是否能理性看待岗位关键词。

参考回答： MCP（模型上下文协议）是重要趋势，但智能体工程师的核心能力仍然是工具治理、上下文管理、业务集成、测试评估和安全边界。作品集可以先用普通工具调用证明这些能力，再补一个 MCP（模型上下文协议）接入层展示协议理解。

容易扣分： 要么完全否定 MCP（模型上下文协议），要么把它神化。

作品集里怎么展示它​

建议做一个“工具调用平台”作品：

  • 工具注册表：每个工具有名称、用途、输入字段、输出字段、风险等级。
  • 权限模型：区分只读工具、写入工具和高风险工具。
  • 审批流程：高风险动作进入人工确认。
  • 日志追踪：每次工具调用都有 Trace ID（追踪编号）。
  • MCP（模型上下文协议）说明页：解释哪些工具可以作为 MCP Server（模型上下文协议服务端）能力暴露，哪些不应该暴露。

这样你既能覆盖岗位关键词，又不会给人“只追热点”的感觉。

和哪些术语一起理解​

对应章节与项目​