一句话看懂：一篇来自掘金的技术解读厘清了 MCP（Model Context Protocol）在 Agent 工具调用链路中的真实位置——它管的不是模型怎么”想”，而是应用怎么”接”。对正在搭 Agent、写工具适配的开发者来说，这能省下不少重复造轮子的功夫。
事件核心：发生了什么
2026 年 9 月 23 日，掘金作者”杨杨杨大侠”发布了一篇辨析 MCP 定位的文章，回应一个高频疑问：既然最后都是 Agent 在调工具，MCP 到底多做了什么？文章给出的结论是：Function Calling 解决的是模型如何结构化地表达”调用哪个工具、传什么参数”，而 MCP 约定的是应用与外部服务之间怎么对接，二者处于不同层但可串联在同一条链路上。文章还区分了 MCP 的三种能力：Tool 通常由模型选择、应用执行；Resource 是可寻址的资料，由应用决定何时加入上下文；Prompt 是提问模板，由用户选择。此外，MCP 文档中的 Host、Client、Server 三方角色也被逐一拆解。
为什么重要
MCP 自提出以来常被误读为”Function Calling 的另一种写法”，这种模糊认知会直接影响架构决策。文章点出的关键判断是：MCP 要解决的是连接规模变大后的协作问题。当同一个代码平台、知识库或工单系统需要同时服务 IDE、桌面 Agent 和内部审查平台时，每个宿主各写一套适配会迅速变成重复劳动。把能力沉淀为独立 MCP Server，多个应用就能用同一套方式发现和调用。反过来，单一应用加两三个稳定本地函数，直接用 Function Calling 更省事。这个视角对判断 MCP 的采用时机比背定义更实用。
对用户/开发者/创作者的影响
对开发者而言，最直接的启示是不要为了”用 MCP”而用 MCP。文章建议先用简单工具把需求跑通，等第二个宿主出现、或同一套接入开始被重复实现时，再考虑引入 MCP Server。另一个容易被忽略的点是：MCP Client 不一定非要放在 Agent Harness 里，IDE、桌面应用甚至后端服务都能自行实现，普通程序不接模型也能读取 Resource 或调用 Tool。目前公开信息显示，部分平台已原生支持 MCP 接入，并不要求应用先把每个 MCP 工具转换成普通 function tool。这意味着工具生态的复用门槛在降低，但前提是开发者先想清楚能力该由谁使用。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
值得关注的后续
一是主流 Agent 平台是否会进一步原生支持 MCP 能力发现，减少应用侧的转换成本；二是 MCP Server 的复用是否会在代码托管、知识库、工单系统等场景形成事实标准；三是权限与安全边界如何落实——文章强调 MCP Server 本身不负责权限，执行时的规则仍由应用承担，这块的实践方案值得持续观察。
来源：juejin
