嘿，各位！👋
在浅浅使用这两种方法一段时间后，我想和大家分享一下 Function Calling 和 MCP 在实战中的权衡考量。
我猜大多数读者已经对 MCP 和Function Calling 有所了解了。所以我就不再赘述技术细节：
场景：身份验证和会话管理
举个例子，我正在开发 Quaily，一个 AI 驱动的 Newsletter 工具。我希望能通过 AI 来发布文章到 quaily.com，当然，这需要身份验证：
使用 MCP 方式：
我可以使用本地程序（也就是 quail-cli）来处理身份验证和会话管理。这样登录状态自然存在于 MCP 服务器也就是 quail-cli 中，登录凭证永远不会泄露给 LLM。
如果凭证过期，MCP 服务器可以简单地强制用户在 quail-cli 中重新登录。
认证和 LLM 处理之间有着清晰的界限，就像把钥匙和锁分开保管，不用担心被偷走。
使用 Function Calling 方式：
显然我不能把 token 或其他登录凭证发送给 LLM：因为存在会话标识符被 LLM 记住的风险，谁知道这些 LLM 会不会偷偷复制一把钥匙呢？
可能的解决方案：
- 使用超短期 token：比如生成只有 10 秒有效期的 token
- 甚至强制每个请求使用新 token 以防止重用
然而，所有这些方法都增加了复杂性，而且仍然无法提供与 MCP 架构方法相同的安全保障。根本问题依然存在：使用 Function Calling 时，是在通过一个无法控制的系统传递敏感信息。
商业模式影响
不仅仅是安全问题，还涉及商业模式。一个商业模式基本上是向你的客户或者用户提供一系列有收费站的高速公路，然后从这些收费站赚钱。
比如在 Quaily 中，收费站是对付费内容的访问，商业模式是订阅制。
如上文所述，Function Calling 很难提供与 MCP 架构方法相同的安全保障，所以它也许适合快速构建产品，但难以创建服务边界，这样的商业模式实施起来不说是别扭，只能说很蛋疼。
而 MCP 天生就适合构建访问控制 —— 尤其对那些想做 AI 应用但没有能力构建像 OpenAI 那样基础设施的应用开发者来说，是这样的。
决策：选择 MCP
今天，两种方案都在解决实际问题，但在深入使用两种方法后，我觉得 MCP 更适合大多数场景，以下是我的观点：
- 安全设计：MCP 的架构从根本上解决了 Function Calling 难以应对的凭证暴露问题
- 面向未来：随着应用程序的增长，MCP 的模块化架构扩展得更加优雅
- 清晰边界：数据访问和 LLM 处理之间的分离创造了更易维护的系统
- 生态系统建设：MCP 可以构建可在应用程序之间共享的能力网络，有利于商业化
你觉得怎么样？欢迎与我分享你的想法。
