企业官网建设流程全解析

从今天觉醒,技术赋予每一个人数字生命

从“拒绝 MCP”到“真香”：一次协议选型的源码级复盘

① 技术背景：工具调用为什么成了新战场

大模型应用开发在过去两年里经历了一次范式转移：从“把提示词写好”转向“让模型能动手做事”。模型不再只是生成文本，它要读文件、查数据库、调 API、跑测试。于是问题从“模型聪不聪明”变成了“工具怎么接、怎么管、怎么组合”。

早期做法是每个框架自定义一套函数调用格式，OpenAI 一套、Anthropic 一套、各家 SDK 又一套。开发者写一个工具，要适配 N 个平台。MCP（Model Context Protocol）想解决的就是这个碎片化问题：定义一套标准协议，让工具提供方和工具消费方解耦。它本质上是一个发现 + 调用的协议层，类似 LSP 之于编辑器。

但标准协议从来不是免费的。它带来抽象，也带来开销；带来互操作，也带来“为了协议而协议”的复杂度。这就是围绕 MCP 争论的核心。

② 主流方案盘点：三条技术路线

路线一：原生函数调用（Native Function Calling）

职责：由模型厂商在推理层直接支持结构化输出。代表是 OpenAI 的 tools 参数、Anthropic 的 tool_use、以及国内主流大模型如 Qwen3.6 Max、GLM 5.1、DeepSeek 4.0 Pro 的原生工具调用能力。

关键抽象是“工具 schema 直接进 prompt，模型输出结构化 JSON”。没有中间协议，延迟最低。缺点是工具定义和模型强绑定，跨模型迁移要重写适配层。

路线二：MCP（Model Context Protocol）

职责：把工具封装成独立的 server，通过 stdio 或 HTTP 暴露 resources/tools/prompts 三类能力，client 负责发现和调用。代表实现是官方 SDK 和大量社区 server。

关键抽象是“协议边界”。工具不再属于某个应用，而是可被任意 client 复用。代价是每次调用要经过序列化、进程通信或网络往返，且组合多个工具时需要 client 自己编排。

路线三：CLI / Shell 工具

职责：把能力暴露成命令行程序，模型生成命令、执行、读回 stdout。代表是各类 agent 框架内置的 shell 工具。

关键抽象是“文本即接口”。Unix 管道天然支持组合，grep | sort | uniq就是最古老的工具编排。缺点是输出非结构化，错误处理靠退出码，安全性需要沙箱兜底。

③ 对比与优劣

一个常被误判的点：MCP 的“标准化”并不自动等于“可组合”。协议解决了发现问题，但没解决编排问题。多个 tool 之间的数据流转、错误传播、事务性，仍然落在 client 身上。这正是“no MCP”派最初的论据——如果组合是刚需，CLI 的管道语义反而更成熟。

④ 选型建议

场景 A：单模型、工具集稳定的产品
选原生函数调用。少一层抽象就少一类 bug，延迟和可调试性都占优。适合在校学生做课程项目或作品集里的“AI 助手”模块。

场景 B：工具要被多个应用复用
选 MCP。比如你写了一个查天气的 server，既想给 IDE 插件用，又想给聊天机器人用。协议层的价值在复用次数上摊薄。

场景 C：需要复杂数据流水线
选 CLI 组合。curl拿数据、jq解析、grep过滤，这套组合的可靠性经过几十年验证。把每个步骤包成 MCP tool 反而增加编排负担。

场景 D：快速验证想法
先用原生调用跑通，别过早引入协议。等工具数量超过 5 个、或出现复用需求，再考虑抽成 MCP server。

面试常被追问的点：如果让你设计一个工具协议，你会把“组合”放在协议层还是应用层？这题没有标准答案，但能看出你是否理解“协议只解决它声明要解决的问题”。

⑤ 未来展望

已经出现的趋势：工具调用正在从“协议之争”转向“编排之争”。谁能让多个工具可靠地串起来、并在失败时优雅回滚，谁就掌握了下一层价值。另一个趋势是沙箱化，CLI 路线的安全性短板正在被容器和权限系统补齐。

仍未解决的问题：跨协议的语义对齐（同一个“读文件”在不同协议里语义不同）、工具调用的可观测性（一次 agent 跑了 30 个工具，怎么定位是哪一步出错）、以及成本控制（工具调用 token 消耗往往超过生成本身）。

“说过不用 MCP”后来改口，本身不丢人。技术选型从来不是信仰，而是约束条件下的权衡。真正值得学的是：先想清楚你的核心约束是什么，再决定要不要那一层抽象。