热闻岛
返回全网热点雷达

智能体设计模式:MCP,让 Agent 像插 USB 一样连接外部系统

2小时前10 阅读
智能体设计模式:MCP,让 Agent 像插 USB 一样连接外部系统配图

要点速读

上一章讲多智能体协作。多个 Agent 能分工,但它们最终还是要连接真实系统。 问题来了:每个 Agent 都单独对接数

  • 上一章讲多智能体协作
  • 多个 Agent 能分工,但它们最终还是要连接真实系统
  • 问题来了:每个 Agent 都单独对接数
上一章讲多智能体协作。多个 Agent 能分工,但它们最终还是要连接真实系统。 问题来了:每个 Agent 都单独对接数据库、Git、日志平台、SaaS API,系统很快会失控。 MCP 解决的就是这个问题。它给 Agent 和外部系统之间

上一章讲多智能体协作。多个 Agent 能分工,但它们最终还是要连接真实系统。

问题来了:每个 Agent 都单独对接数据库、Git、日志平台、SaaS API,系统很快会失控。

MCP 解决的就是这个问题。它给 Agent 和外部系统之间加了一层标准接口。

一、为什么需要 MCP

普通工具调用能让 Agent 调 API。

但工具一多,问题马上出现。

每个模型、每个应用都要重复写工具适配。

工具描述分散在业务代码里,难复用。

新增工具要改代码、发版本、重启服务。

权限、审计、参数校验经常各做各的。

多个 Agent 想共享同一批工具,成本很高。

所以,Tool Use 解决“能不能调用工具”。

MCP 解决“工具如何标准化接入、发现、调用和治理”。

二、MCP 到底是什么

MCP,全称 Model Context Protocol,模型上下文协议。

可以把它理解成 AI 应用世界里的 USB-C。

模型不需要知道每个系统的私有接口。

它只要通过 MCP Client,连接对应的 MCP Server,就能发现和使用外部能力。

MCP 不是模型。

也不是一个新的 Agent 框架。

它更像一套通信标准:规定 AI 应用、连接器、工具服务之间如何说话。

三、MCP 的核心架构

MCP 采用 Host - Client - Server 架构。

这三个角色很关键。

Host:承载模型和用户界面的 AI 应用,比如聊天助手、IDE、企业 Agent 平台。

MCP Client:Host 内部的连接器,负责和 MCP Server 通信。

MCP Server:外部系统入口,负责暴露工具、资源和提示模板。

外部系统:真正的数据源和执行系统,比如数据库、代码仓库、日志平台、SaaS API。

四、MCP Server 暴露三类能力

理解 MCP,重点看三类能力:Tools、Resources、Prompts。

它们不是一回事。

Tools 是动作。

Resources 是上下文。

Prompts 是任务模板。

Tools:让 Agent 执行动作,例如查数据库、调接口、跑计算。

Resources:给 Agent 提供上下文,例如文件、schema、项目配置、文档内容。

Prompts:提供可复用的任务模板,例如排障报告模板、代码审查模板。

五、案例:研发排障助手

假设线上支付接口 500 增多。

研发希望 Agent 帮忙定位原因。

如果直接给 Agent 所有系统权限,非常危险。

更合理的做法是:用 MCP Server 把内部系统包装成只读工具。

排障 Agent 不直接连接数据库和日志平台。

它只连接 MCP Server。

MCP Server 决定暴露哪些工具、允许哪些参数、记录哪些日志。

GitHub MCP:只开放读取 Issue、PR、Commit 的能力。

日志 MCP:只开放按 traceId、时间窗口查询错误日志。

DB MCP:只开放只读查询,不允许更新、删除和导出敏感字段。

Agent 输出结论时,必须带证据链和工具调用结果。

六、源码级看运行逻辑

MCP 的底层通信基于 JSON-RPC。

你不一定要手写协议,但要理解它的运行链路。

一轮调用可以拆成 6 步

初始化:MCP Client 与 MCP Server 建立连接,完成能力协商。

发现工具:Client 发送 tools/list,拿到工具名称、描述、参数 schema。

模型决策:LLM 根据用户目标和工具说明,决定是否调用工具。

构造请求:Client 发送 tools/call,带上工具名和参数。

服务执行:Server 做鉴权、参数校验、调用底层 API 或数据库。

结果回填:Server 返回结构化结果,Client 放回上下文,Agent 继续推理。

这就是 MCP 与普通 API 调用的区别。

普通 API 调用是业务代码直接写死。

MCP 是先发现能力,再按协议调用能力。

它天然更适合多工具、多客户端、多 Agent 的系统。

七、什么时候该用 MCP

不是所有项目都需要 MCP。

如果你只接两个固定 API,普通函数调用就够了。

如果系统开始变复杂,MCP 的价值才会出来。

多个 Agent 需要共享同一批工具。

工具来自不同团队,需要标准化接入。

AI 应用要连接数据库、文件、代码仓库、SaaS、内部平台。

希望工具能力可以动态发现,而不是写死在代码里。

希望统一做权限、审计、过滤、超时和错误处理。

八、上线时最容易踩的坑

MCP 很强,但不能裸奔。

因为它把模型和真实系统连接起来了。

越能干,越要管住。

工程上要记住三句话。

第一,只读优先。

第二,危险动作必须人工确认。

第三,所有工具调用都要可追溯。

总结

MCP 的本质,是把 Agent 连接外部系统这件事标准化。

它不是为了替代 Tool Use,而是让工具使用变得可复用、可发现、可治理。

简单项目,可以先用函数调用。

复杂系统,尤其是企业级 Agent,应该尽早考虑 MCP。

一旦系统里出现多个 Agent、多个工具、多个数据源,MCP 就不只是锦上添花。

它会变成基础设施。

事件尾巴

热闻岛基于现有公开内容整理事件脉络。后续如果出现权威回应、更多现场信息或相关主体更新,本页相关热点与同类热榜会继续补充。

这件事后面看什么?

返回全网热点雷达