你的 LLM 应用真的需要 MCP 吗？MCP、CLI 与函数调用取舍
开发者社区里越来越常见一个问题：我做了一个 LLM 功能，需要让模型查数据库、读仓库或跑部署命令，是不是应该马上写一个 MCP server？有时答案是肯定的，但更多时候，更诚实的答案是：还不必。
MCP（Model Context Protocol）的价值很真实。官方文档把它定义为连接 AI 应用与外部系统的开放标准，Anthropic 发布 MCP 时也强调，它希望减少一次性集成，让工具、资源和提示能用统一协议暴露给 AI 客户端。但标准协议不等于所有场景都该优先使用。
如果你只是在一个产品里暴露三个内部工具，原生函数调用通常更简单。如果你在做代码 agent，让它复用已有测试、构建、迁移、搜索命令，CLI 封装可能更透明。如果同一套能力要给 Claude Desktop、Claude Code、内部 agent 和未来第三方客户端共用，MCP 才开始真正有意义。
先看集成面，而不是看热度
函数调用、CLI 和 MCP 都在解决同一个问题：模型需要安全、结构化的能力，才能真正做事。差别在于契约放在哪里。
原生函数调用把契约放在你的应用里。你定义 JSON schema，模型选择工具和参数，你的服务端执行动作并返回结果。Anthropic 的 tool use 文档和 OpenAI 的 function calling 文档大体都是这个模式。它直接、可调试，也最容易进入生产。
CLI 把契约放在可执行命令里。测试、类型检查、包管理、数据库迁移、Terraform plan、部署预览、代码生成脚本，本来就是命令形态。不要让模型随便跑 bash，而是做一个窄命令 broker：白名单、固定工作目录、超时、参数校验、输出截断、敏感信息脱敏和强制停止路径。
MCP 则把契约放在 MCP client 与 MCP server 之间。Server 暴露工具、资源和提示，client 发现并调用这些能力。它最擅长的不是替代每一次 tool call，而是让能力跨客户端、跨团队、跨模型运行时复用。
什么时候函数调用是默认选择
大多数 LLM 应用第一版都应该从函数调用开始。认证、日志、限流、重试、计费、租户隔离、事故响应都还在你已经运营的应用边界里。工具失败时，你能在一个地方看到用户、请求、模型输出和后端 trace。
如果工具是产品特定的，函数调用通常更合适。客服助手查订单、起草退款、总结账户历史，这些操作深度绑定权限和业务逻辑。太早抽成 MCP 可能只是增加了一个协议边界，却没有改善用户体验。
函数调用的问题是会蔓延。每个 host app 都长出一套略有差异的“查工单”“读仓库文件”“跑 SQL”schema。三个团队、三个模型供应商、三套实现，很快就变成九个集成面。到了这个阶段，MCP 的复用价值才会变得明显。
什么时候 CLI 比协议更合适
开发者常低估 CLI，因为它看起来不够“AI 原生”。但对 coding agent 和基础设施工作流来说，CLI 往往是最诚实的接口：可以本地复现，继承项目约定，输出人类看得懂的日志，并用退出码表达失败。
如果一个流程已经是命令原生的，先封装 CLI，而不是急着重写成 MCP 工具。命令 broker 可以把原始日志留给人类，把结构化摘要给模型。它适合测试、构建、迁移、部署预览、仓库搜索等场景。
代价是可发现性。CLI 描述不清或输出太嘈杂时，模型容易误用。MCP 的工具元数据和 schema 更利于枚举能力；函数调用在单应用内也可以做到类似效果。CLI 的优势在于复现性和对现有工程流程的贴合。
什么时候 MCP 值得引入
当同一能力需要进入多个 AI 环境时，MCP 才真正值回复杂度。知识库搜索、仓库上下文、设计系统、数据库元数据、审计日志查询，这类平台能力很适合做成 MCP server，让聊天助手、IDE agent、支持 copilots 和内部自动化共同使用。
MCP 也适合分布式所有权。数据平台团队维护 analytics server，开发体验团队维护 repository server，安全团队维护 audit-log server，应用团队只消费能力，不复制业务逻辑。生产侧可以参考我们的 MCP 生产集成模式。如果你是 SaaS 厂商，还可以参考 MCP SaaS 集成策略，判断它是否真的能成为分发渠道。
但 MCP 不是免费抽象。认证、授权、密钥管理、限流、遥测、schema 版本、错误信息安全，仍然都要你设计。如果函数调用阶段这些问题还没解决，加上 MCP 不会自动解决，只会把问题移到更漂亮的架构图后面。
决策清单
先问：这个工具会被几个客户端使用？只有一个产品界面，就从函数调用开始；多个助手、IDE 或 agent runtime 需要共用，再认真考虑 MCP。
再问：工具现在在哪里？如果它已经是人类稳定使用的命令，先封装 CLI。如果它是应用内部业务逻辑，函数调用更干净。如果它是平台团队拥有的共享能力，MCP 可能是更合适的边界。
第三问：动作有多敏感？只读搜索和“删除客户数据”“部署生产”不是同一个风险等级。高风险工具更需要审批、scope token、审计日志、dry-run 和人类可见 diff。
第四问：schema 稳定吗？MCP 更适合稳定、可发现、可复用的工具。快速实验的工具先留在函数调用里，等契约稳定再抽出来。
一条务实迁移路径
第一版产品功能用函数调用。保持工具名朴素、schema 清晰、错误结构化、副作用显式。当第二个客户端需要同一能力时，把实现抽到内部服务边界。当第三个客户端出现，再升级成 MCP server。
命令原生工作流则从安全 CLI broker 开始。多个 AI 客户端都需要同一命令面时，在 broker 前面加 MCP server，而不是把所有命令重写成应用代码。开发者工具里常见的混合模式就是：MCP 负责发现与互操作，CLI 负责执行。
如果你的 agent 在代码仓库里工作，还要结合 我如何用 LLM 写软件 里的流程纪律，以及 Claude 文件夹剖析 里的权限边界。工具架构只是其中一层，规划、审查、权限和回滚同样重要。
一个偏实用的答案
你的 LLM 应用真的需要 MCP 吗？如果是单一受控应用，第一版大概率不需要。用函数调用，保持契约干净，先观察用户真实怎么使用工具。
你的开发 agent 需要 CLI 吗？经常需要，但应该通过 broker，而不是开放 shell。白名单命令、结构化摘要、超时和日志，比“让模型自由发挥”安全得多。
你的平台需要 MCP 吗？如果你要把共享能力标准化到多个 AI 客户端，答案更可能是需要。MCP 很适合多客户端复用、分布式所有权和生态集成；如果只是给三个私有函数套一层新协议，它就不那么值得。
最好的架构不是最新的，而是在安全、可观测和未来复用之间，边界最少的那一个。先从小处开始，让契约保持诚实。等互操作性真的成为需求，再引入 MCP。