托尼理发店分享一个用 AI 初步了解一个较为陌生的概念的过程：
早上看到时间线上有多条关于 MCP 的讨论，虽然对这个名词有印象，但之前一直没深入了解过。于是在煮鸡蛋的间隙跟 Kimi 聊了几句。
Q1: MCP 是什么？
Kimi 回复了这个缩写的全称，介绍了核心功能、工作流程、优势和应用场景。
=> 我的思考：大致和我之前印象里了解的差不多，于是继续追问。
Q2: 可以理解为 MCP 是一个协议，我如果要做一个产品，支持 MCP 协议的话，就可以被 AI 调用了。是吗？
Kimi 回复我的理解基本正确，然后解释了为什么支持 MCP 协议很重要，以及简单介绍了如何让产品支持 MCP 协议，并给了一个简单的例子：文件管理工具——支持 MCP 请求读取特定文件内容，让 AI 分析或生成总结，然后保存为新的文件。
=> 我的思考：所有产品都适合这样做吗？所以继续追问。
Q3: 有哪些应用适合接入 MCP？
Kimi 给了一些例子，比如 AI 驱动的开发工具（如 IDE 等），企业自动化管理工具（如项目管理，CRM 系统等），数据处理和分析工具，智能客服和聊天机器人，内容生成和创意工具，研究和学术工具，个人生产力工具等等。
=> 我的思考：例子都比较空泛，只是说了这些产品、应用可以接入 MCP，没有讲为什么适合以及如何接入。
=> 但这时候我又突然想到，这种接入其实不就是把原有产品的功能做成标准接口提供出去给 AI 调用么？这和提供 API 有什么区别？所以继续追问。
Q4: 但从另一个角度看，这不就是提供应用的 API 给外部服务么？
Kimi 回复说本质上确实可以理解为一种特殊的 API，但 MCP 不仅仅是传统 API 的简单扩展，更适合 AI 模型的交互需求。然后给了 MCP 和传统 API 的区别分析，包括标准化与通用性，上下文管理，安全性和信任机制，动态交互和实时反馈等。然后总结了 MCP 的核心价值：为 AI 时代量身定制的协议。
=> 我的思考：这里的解释都过于理论化，我其实还是没有很直观的感受到它和传统 API 的区别。所以准备让它举例子。
Q5: 用几个例子帮我理解一下 MCP 和传统 API 的对比。
Kimi 开始举例，在几个场景中对比了传统 API 的限制，和用 MCP 协议实现后可以达到的程度。
=> 我的思考：这些例子简单来看，基本都是对「用户输入」进行「理解」，然后转化为类似「传统 API」的请求。和之前了解过的另一个概念「Function Calling」很类似。所以这里有一个关键问题：「理解」这一步是谁来负责实现？
Q6: 这部分“理解”的工作是应用需要提供的能力吗？
Kimi 回复是的，这是应用本身需要提供的能力，并不是由 MCP 协议完成。然后给了一些描述用来解释 MCP 和应用的关系，同时给了一些在应用层面实现「理解」的方案。
=> 我的思考：到这一步其实我已经大致了解了 MCP 的概念，虽然远谈不上掌握，但如果下一步要开始做兼容 MCP 协议的应用，心里至少有底了。这时候鸡蛋已经差不多煮好了，关火继续焖一会儿，顺便再问一下具体实现方式。
Q7: 如果我已经有了一个应用，并有了一些标准的 REST API，接下来如果我想要兼容 MCP，应该如何做？用具体的例子回答。
Kimi 给了这些执行建议：（1）为应用创建一个 MCP 服务器，作为应用和 AI 模型之间的通信桥梁；（2）封装 REST API 为 MCP 工具函数；（3）处理上下文信息。
==========
整个过程差不多 6 分钟左右，用的是 Kimi 的普通模型（不是长思考）。令我意外的其实并不是回答内容，而是我的学习行为模式在被潜移默化地改变了。
上面的每个问题其实都可以用对应的关键词在搜索引擎里找回答，但有些问题很难直接搜索得到。
- 比如 Q2 和 Q4 这类想用类比快速理解概念的问题，只有 AI 能够给你明确的答案「正确」或「错误」，并且还能给你解释。
- 还有 Q6 这类强上下文关联的追问，特定的词语只有在上下文中才能找到正确的含义。
- 以及，如果没有 Q1 到 Q6 的信息摄入，我自己没办法直接问出 Q7 这类实现方案的问题，因为即便 AI 回答了，我也没办法和已有的信息做校验，并发展新的问题。
学无止境，AI 可真是个好老师啊！
留言
暂无留言。来第一个留言吧！