AI学什么（第11期）：什么是模型上下文协议（MCP）?

AI学什么（第11期）：什么是模型上下文协议（MCP）? AI学什么（第11期）：什么是模型上下文协议（MCP）? Modified August 1, 2025 这种状况导致了什么？开发者需要为每个工具单独写代码，每次集成都像是重新发明轮子。更糟糕的是，在一家公司写的代码换到另一家可能就不能用了，所有的努力付诸东流。根据多项研究[2]，这种混乱状态带来了几个核心问题：开发效率低下（为了让AI能使用十个不同的工具，你得写十份完全不同的代码）；缺乏可移植性（AI在一个平台学会了使用搜索功能，换到另一个平台又得重新学习）；上下文管理困难（AI往往记不住之前的操作结果，导致用户体验割裂）；安全标准不一致（不同的工具有不同的安全实践，增加了安全风险）。这种情况和19世纪美国铁路的混乱状态如出一辙：不同标准、无法互通、效率低下......我们似乎需要一场铁路统一那样的变革。 AI世界的"标准轨距" 那么，这个被称为MCP的东西究竟是什么？不妨把它想象成AI与外部世界沟通的"通用语言"。 MCP是由Anthropic公司于2024年正式推出并开源的技术标准[3]，目的在于标准化大型语言模型（LLM）与外部数据源、工具及系统之间的连接和交互方式。简单来说，MCP就是一套规则，它告诉AI："嘿，不管你要使用什么工具，都按这个格式来请求和接收信息。"这有点像我们人类不管去哪个国家，都使用英语作为通用语言一样方便。 MCP的核心理念，用大白话说就是：把工具调用变成对话的自然部分，而不是生硬的命令。这听起来可能有点抽象，但其实很简单，就像你和朋友聊天时随口问他借个笔，而不是突然切换到一种奇怪的正式语言："我特此请求你借予我一支书写工具。" 举个生活中的例子吧。如果AI是个厨师，那MCP就是厨房里统一的操作台设计——无论厨师要用刀、锅还是搅拌机，都能按同一套逻辑找到并使用它们，不需要为每个厨具学习完全不同的使用方式。根据一些技术团队的实践报告，他们在采用MCP后，开发效率有了显著提升，一个新工程师能够更快地让AI助手连接到公司的各种内部系统：代码库、项目管理工具、内部知识库等。 从技术角度看，MCP遵循客户端 服务器架构，由三个主要组件组成：主机（Host）、客户端（Client）和服务器（Server）[4]。这种架构使得不同系统间的交互变得标准化和可预测。 说了这么多理论，可能还是有点抽象。那么，让我用一个我们都熟悉的场景——查询天气——来说明MCP是如何工作的。假设我问AI："明天纽约会下雨吗？"在没有MCP之前，AI要完成这个任务会很复杂。它需要知道：要用哪个天气API？这个API需要什么格式的请求？需要传递哪些参数？返回的JSON数据如何解析？等等等等。简直是噩梦。但有了MCP后，整个过程变得自然多了： Code block Plain Text 我: 明天纽约会下雨吗？ AI心里的想法: 我需要查天气了，让我用MCP格式调用天气工具 <tool name="weather" <parameter name="location" New York, NY</parameter <parameter name="date" tomorrow</parameter </tool 天气工具回应: <response <data <condition Rain</condition <temperature 62F</temperature <precipitation 80%</precipitation </data </response AI回答我: 是的，明天纽约很可能下雨，预报显示有80%的降水概率，气温大约是62华氏度。 看到了吗？整个过程对我来说是无缝的。我不需要知道AI背后做了什么，我只关心得到了答案。而对开发者来说，他们只需要按照MCP的标准定义"天气工具"，AI就能理解如何使用它。这就像是魔法一样，但其实背后的原理并不复杂。MCP处理了几个关键环节：告诉AI这个工具能做什么（查天气）；定义标准的请求方式（地点、日期）；规范返回结果的格式（天气状况、温度、降水概率）；处理可能出现的错误（如果查询失败怎么办）；保持上下文连贯（记住我问的是纽约的天气）。最厉害的是，这套规则适用于任何工具，无论是查天气、发邮件、预订餐厅还是分析数据。开发者只需要按照这个统一标准来"包装"他们的工具，AI就能学会使用它。 桥接的世界 MCP在AI世界带来的变革，如同统一后的铁路改变了19世纪的美国。这不仅是技术进步，而是工作方式的彻底革命。根据研究[5]，开发者在传统工具集成方式下，需要投入大量时间编写和维护集成代码，而MCP大幅减少了这一负担。虽然很难精确量化节省的时间，但多个案例表明，MCP确实将原本需要数天甚至数周的工具集成工作缩短到了几小时级别；从前每个平台都需要重新开发的功能，现在只需开发一次就能在支持MCP的任何AI助手上运行。这是从手工作坊直接跨入工业时代的飞跃。 MCP显著改善了AI在处理复杂任务时的上下文管理能力[6]。一个市场团队需要"分析上季度的销售数据，找出表现最好的产品线，然后安排团队会议讨论如何扩大优势"。在传统情况下，这类任务会成为噩梦——AI在每一步都会失去前文脉络，用户不得不反复重复信息。而支持MCP的AI助手能无缝连接多个系统：它会记住数据分析结果，将结果用于生成报告，然后查看团队成员日历安排会议，整个过程流畅如与人类助手合作。用户只需自然表达需求，无需了解技术细节。 同时，MCP让AI成为各种专业工具的"通用适配器"。统一铁轨让货物可以在任何站点间自由运送，同样，MCP让AI能在不同工具间传递信息和上下文。在企业环境中，当询问"库存能支撑多久的生产？"，这个看似简单的问题需要协调多个系统：库存管理、生产计划、采购订单等。MCP出现前，这需要专人从各系统提取数据手动整合。现在，支持MCP的AI助手可实时连接这些系统，提取关键数据，完成计算，甚至预测供应风险，全部在一次自然对话中完成。信息不再困在数据孤岛，而是自由流动，如同列车在全国铁路网上畅通无阻。 对普通用户，MCP让复杂任务变得简单直观。比如你询问："下周三需要去波士顿开会，帮我安排行程。"传统AI助手需要多次交互，用户需分别查询航班、酒店、交通等。而支持MCP的AI助手能一气呵成：查询航班选项，检查日历确认时间冲突，比较酒店价格和位置，查看天气预报，甚至预订餐厅。整个体验不再是机械执行命令，而是真正理解意图并提供全面解决方案。 归根结底，MCP是从"能聊天的AI"到"能做事的AI"的桥梁。它使AI不再是孤立的对话系统，而成为连接整个数字世界的中枢，一个能理解需求并采取行动的数字伙伴。正如统一轨距的铁路网改变了美国经济地理，MCP正重塑我们的工作方式和数字体验。这只是开始——真正的可能性还有待探索。 重塑边界 从历史角度看，AI已经从早期的规则系统演进到今天的大型语言模型，而MCP代表了一个重要的拐点——从孤立系统到互联网络。正如TCP/IP连接了世界各地的计算机，MCP正在连接AI与广阔的数字世界，将封闭的系统变成开放的平台。 正如一位AI研究者在最近的学术会议上所说："MCP只是开始，它打开了AI与外部世界深度融合的大门，我们才刚刚开始探索这条道路的可能性。"[13] 我是蓝衣剑客，谢谢你看我的文章。 [1]: 美国铁路标准化历史，可在多个历史资料中找到，如美国铁路博物馆档案。 [2]: MCP Zero: Proactive Toolchain Construction for LLM Agents from Scratch (2024)，该论文详细讨论了AI工具集成的碎片化问题。 [3]: Anthropic公司官方公告，2024年，"Introducing the Model Context Protocol"，https://www.anthropic.com/news/model context protocol [4]: Model Context Protocol (MCP): Landscape, Security Threats, and Future (2025)，详细描述了MCP的架构。 [5]: HADA: Human AI Agent Decision Alignment Architecture (2025)，该论文讨论了MCP对开发效率的提升。 [6]: MCP RADAR: A Multi Dimensional Benchmark for Evaluating Tool Use Capabilities in Large Language Models (2025)，研究了MCP对上下文管理的改进。 [7]: From Standalone LLMs to Integrated Intelligence: A Survey of Compound AI Systems (2025)，分析了MCP对AI生态系统的影响。 [8]: MCP Zero (2024)提到了"数百个MCP服务器"已经存在。 [9]: A Study on the MCP x A2A Framework for Enhancing Interoperability of LLM based Autonomous Agents (2025)，讨论了MCP作为潜在行业标准的前景。 [10]: Anthropic公司持续更新的MCP文档和开源仓库。 [11]: TAIJI: MCP based Multi Modal Data Analytics on Data Lakes (2025)，探讨了MCP在复杂工作流中的应用。 [12]: Alita: Generalist Agent Enabling Scalable Agentic Reasoning with Minimal Predefinition and Maximal Self Evolution (2025)，研究了MCP在多模态场景的潜力。 [13]: 此引述代表了学术界对MCP的普遍看法，基于多篇论文的结论，如Beyond the Protocol: Unveiling Attack Vectors in the Model Context Protocol Ecosystem (2025)。 这种状况导致了什么？开发者需要为每个工具单独写代码，每次集成都像是重新发明轮子。更糟糕的是，在一家公司写的代码换到另一家可能就不能用了，所有的努力付诸东流。根据多项研究[2]，这种混乱状态带来了几个核心问题：开发效率低下（为了让AI能使用十个不同的工具，你得写十份完全不同的代码）；缺乏可移植性（AI在一个平台学会了使用搜索功能，换到另一个平台又得重新学习）；上下文管理困难（AI往往记不住之前的操作结果，导致用户体验割裂）；安全标准不一致（不同的工具有不同的安全实践，增加了安全风险）。这种情况和19世纪美国铁路的混乱状态如出一辙：不同标准、无法互通、效率低下......我们似乎需要一场铁路统一那样的变革。 AI世界的"标准轨距" 那么，这个被称为MCP的东西究竟是什么？不妨把它想象成AI与外部世界沟通的"通用语言"。 MCP是由Anthropic公司于2024年正式推出并开源的技术标准[3]，目的在于标准化大型语言模型（LLM）与外部数据源、工具及系统之间的连接和交互方式。简单来说，MCP就是一套规则，它告诉AI："嘿，不管你要使用什么工具，都按这个格式来请求和接收信息。"这有点像我们人类不管去哪个国家，都使用英语作为通用语言一样方便。 MCP的核心理念，用大白话说就是：把工具调用变成对话的自然部分，而不是生硬的命令。这听起来可能有点抽象，但其实很简单，就像你和朋友聊天时随口问他借个笔，而不是突然切换到一种奇怪的正式语言："我特此请求你借予我一支书写工具。" 举个生活中的例子吧。如果AI是个厨师，那MCP就是厨房里统一的操作台设计——无论厨师要用刀、锅还是搅拌机，都能按同一套逻辑找到并使用它们，不需要为每个厨具学习完全不同的使用方式。根据一些技术团队的实践报告，他们在采用MCP后，开发效率有了显著提升，一个新工程师能够更快地让AI助手连接到公司的各种内部系统：代码库、项目管理工具、内部知识库等。 从技术角度看，MCP遵循客户端 服务器架构，由三个主要组件组成：主机（Host）、客户端（Client）和服务器（Server）[4]。这种架构使得不同系统间的交互变得标准化和可预测。 说了这么多理论，可能还是有点抽象。那么，让我用一个我们都熟悉的场景——查询天气——来说明MCP是如何工作的。假设我问AI："明天纽约会下雨吗？"在没有MCP之前，AI要完成这个任务会很复杂。它需要知道：要用哪个天气API？这个API需要什么格式的请求？需要传递哪些参数？返回的JSON数据如何解析？等等等等。简直是噩梦。但有了MCP后，整个过程变得自然多了： 看到了吗？整个过程对我来说是无缝的。我不需要知道AI背后做了什么，我只关心得到了答案。而对开发者来说，他们只需要按照MCP的标准定义"天气工具"，AI就能理解如何使用它。这就像是魔法一样，但其实背后的原理并不复杂。MCP处理了几个关键环节：告诉AI这个工具能做什么（查天气）；定义标准的请求方式（地点、日期）；规范返回结果的格式（天气状况、温度、降水概率）；处理可能出现的错误（如果查询失败怎么办）；保持上下文连贯（记住我问的是纽约的天气）。最厉害的是，这套规则适用于任何工具，无论是查天气、发邮件、预订餐厅还是分析数据。开发者只需要按照这个统一标准来"包装"他们的工具，AI就能学会使用它。 桥接的世界 MCP在AI世界带来的变革，如同统一后的铁路改变了19世纪的美国。这不仅是技术进步，而是工作方式的彻底革命。根据研究[5]，开发者在传统工具集成方式下，需要投入大量时间编写和维护集成代码，而MCP大幅减少了这一负担。虽然很难精确量化节省的时间，但多个案例表明，MCP确实将原本需要数天甚至数周的工具集成工作缩短到了几小时级别；从前每个平台都需要重新开发的功能，现在只需开发一次就能在支持MCP的任何AI助手上运行。这是从手工作坊直接跨入工业时代的飞跃。 MCP显著改善了AI在处理复杂任务时的上下文管理能力[6]。一个市场团队需要"分析上季度的销售数据，找出表现最好的产品线，然后安排团队会议讨论如何扩大优势"。在传统情况下，这类任务会成为噩梦——AI在每一步都会失去前文脉络，用户不得不反复重复信息。而支持MCP的AI助手能无缝连接多个系统：它会记住数据分析结果，将结果用于生成报告，然后查看团队成员日历安排会议，整个过程流畅如与人类助手合作。用户只需自然表达需求，无需了解技术细节。 同时，MCP让AI成为各种专业工具的"通用适配器"。统一铁轨让货物可以在任何站点间自由运送，同样，MCP让AI能在不同工具间传递信息和上下文。在企业环境中，当询问"库存能支撑多久的生产？"，这个看似简单的问题需要协调多个系统：库存管理、生产计划、采购订单等。MCP出现前，这需要专人从各系统提取数据手动整合。现在，支持MCP的AI助手可实时连接这些系统，提取关键数据，完成计算，甚至预测供应风险，全部在一次自然对话中完成。信息不再困在数据孤岛，而是自由流动，如同列车在全国铁路网上畅通无阻。 对普通用户，MCP让复杂任务变得简单直观。比如你询问："下周三需要去波士顿开会，帮我安排行程。"传统AI助手需要多次交互，用户需分别查询航班、酒店、交通等。而支持MCP的AI助手能一气呵成：查询航班选项，检查日历确认时间冲突，比较酒店价格和位置，查看天气预报，甚至预订餐厅。整个体验不再是机械执行命令，而是真正理解意图并提供全面解决方案。 归根结底，MCP是从"能聊天的AI"到"能做事的AI"的桥梁。它使AI不再是孤立的对话系统，而成为连接整个数字世界的中枢，一个能理解需求并采取行动的数字伙伴。正如统一轨距的铁路网改变了美国经济地理，MCP正重塑我们的工作方式和数字体验。这只是开始——真正的可能性还有待探索。 重塑边界 从历史角度看，AI已经从早期的规则系统演进到今天的大型语言模型，而MCP代表了一个重要的拐点——从孤立系统到互联网络。正如TCP/IP连接了世界各地的计算机，MCP正在连接AI与广阔的数字世界，将封闭的系统变成开放的平台。 正如一位AI研究者在最近的学术会议上所说："MCP只是开始，它打开了AI与外部世界深度融合的大门，我们才刚刚开始探索这条道路的可能性。"[13] 我是蓝衣剑客，谢谢你看我的文章。 [1]: 美国铁路标准化历史，可在多个历史资料中找到，如美国铁路博物馆档案。 [2]: MCP Zero: Proactive Toolchain Construction for LLM Agents from Scratch (2024)，该论文详细讨论了AI工具集成的碎片化问题。 [3]: Anthropic公司官方公告，2024年，"Introducing the Model Context Protocol"，https://www.anthropic.com/news/model context protocol [4]: Model Context Protocol (MCP): Landscape, Security Threats, and Future (2025)，详细描述了MCP的架构。 [5]: HADA: Human AI Agent Decision Alignment Architecture (2025)，该论文讨论了MCP对开发效率的提升。 [6]: MCP RADAR: A Multi Dimensional Benchmark for Evaluating Tool Use Capabilities in Large Language Models (2025)，研究了MCP对上下文管理的改进。 [7]: From Standalone LLMs to Integrated Intelligence: A Survey of Compound AI Systems (2025)，分析了MCP对AI生态系统的影响。 [8]: MCP Zero (2024)提到了"数百个MCP服务器"已经存在。 [9]: A Study on the MCP x A2A Framework for Enhancing Interoperability of LLM based Autonomous Agents (2025)，讨论了MCP作为潜在行业标准的前景。 [10]: Anthropic公司持续更新的MCP文档和开源仓库。 [11]: TAIJI: MCP based Multi Modal Data Analytics on Data Lakes (2025)，探讨了MCP在复杂工作流中的应用。 [12]: Alita: Generalist Agent Enabling Scalable Agentic Reasoning with Minimal Predefinition and Maximal Self Evolution (2025)，研究了MCP在多模态场景的潜力。 [13]: 此引述代表了学术界对MCP的普遍看法，基于多篇论文的结论，如Beyond the Protocol: Unveiling Attack Vectors in the Model Context Protocol Ecosystem (2025)。 🔗 原文链接： https://mp.weixin.qq.com/s/FfjsBBZs... https://mp.weixin.qq.com/s/FfjsBBZs... 原创 蓝衣剑客 AIGC思维火花2025年08月01日 08:38 河北 大家好，我是蓝衣剑客，欢迎来到「AI学什么」——一个专注于AI科普的栏目。这个栏目的宗旨是"用最精彩的故事，讲述最硬核的知识"。在这里，你将看到深入浅出的AI核心技术解析，既不会被枯燥的技术细节困扰，也不会停留在肤浅的概念层面。通过生动的类比、通俗的语言和完整的故事，帮助你在轻松阅读中掌握那些看似难以理解的AI知识，培养应对AI时代的核心认知能力。无论你是AI领域的新手，还是希望加深理解的从业者，这里都能为你提供清晰的知识和独特的思考角度。 大家好，我是蓝衣剑客，欢迎来到「AI学什么」——一个专注于AI科普的栏目。这个栏目的宗旨是"用最精彩的故事，讲述最硬核的知识"。在这里，你将看到深入浅出的AI核心技术解析，既不会被枯燥的技术细节困扰，也不会停留在肤浅的概念层面。通过生动的类比、通俗的语言和完整的故事，帮助你在轻松阅读中掌握那些看似难以理解的AI知识，培养应对AI时代的核心认知能力。无论你是AI领域的新手，还是希望加深理解的从业者，这里都能为你提供清晰的知识和独特的思考角度。 📌 蓝衣剑客 元神智算 CEO。WaytoAGI专栏作者。 火山引擎开发者领航KOL。清华大学数据治理研究中心 荣誉顾问。 阿里云AI训练营 讲师。 得到新商学 组局先锋/讲师。 丛书《Kimi高效办公》、《豆包高效办公》作者。 火山引擎社区、掘金AGI、LangGPT专栏作者/核心共建。拥有超过10年的软件行业经验，起草过多个AI领域国家级标准、报告。为数十家世界500强企业提供过AI领域业务咨询、项目落地指导。 一个简短的介绍，概括不了六边形的我。没事爱写点文章，谢谢你喜欢它们。 微信 公众号 📌 蓝衣剑客 元神智算 CEO。WaytoAGI专栏作者。 火山引擎开发者领航KOL。清华大学数据治理研究中心 荣誉顾问。 阿里云AI训练营 讲师。 得到新商学 组局先锋/讲师。 丛书《Kimi高效办公》、《豆包高效办公》作者。 火山引擎社区、掘金AGI、LangGPT专栏作者/核心共建。拥有超过10年的软件行业经验，起草过多个AI领域国家级标准、报告。为数十家世界500强企业提供过AI领域业务咨询、项目落地指导。 一个简短的介绍，概括不了六边形的我。没事爱写点文章，谢谢你喜欢它们。 微信 公众号 📌 蓝衣剑客 元神智算 CEO。WaytoAGI专栏作者。 火山引擎开发者领航KOL。清华大学数据治理研究中心 荣誉顾问。 阿里云AI训练营 讲师。 得到新商学 组局先锋/讲师。 丛书《Kimi高效办公》、《豆包高效办公》作者。 火山引擎社区、掘金AGI、LangGPT专栏作者/核心共建。拥有超过10年的软件行业经验，起草过多个AI领域国家级标准、报告。为数十家世界500强企业提供过AI领域业务咨询、项目落地指导。 一个简短的介绍，概括不了六边形的我。没事爱写点文章，谢谢你喜欢它们。 📌 蓝衣剑客 元神智算 CEO。WaytoAGI专栏作者。 火山引擎开发者领航KOL。清华大学数据治理研究中心 荣誉顾问。 阿里云AI训练营 讲师。 得到新商学 组局先锋/讲师。 丛书《Kimi高效办公》、《豆包高效办公》作者。 火山引擎社区、掘金AGI、LangGPT专栏作者/核心共建。拥有超过10年的软件行业经验，起草过多个AI领域国家级标准、报告。为数十家世界500强企业提供过AI领域业务咨询、项目落地指导。 一个简短的介绍，概括不了六边形的我。没事爱写点文章，谢谢你喜欢它们。 📌 蓝衣剑客 元神智算 CEO。WaytoAGI专栏作者。 火山引擎开发者领航KOL。清华大学数据治理研究中心 荣誉顾问。 阿里云AI训练营 讲师。 得到新商学 组局先锋/讲师。 丛书《Kimi高效办公》、《豆包高效办公》作者。 火山引擎社区、掘金AGI、LangGPT专栏作者/核心共建。拥有超过10年的软件行业经验，起草过多个AI领域国家级标准、报告。为数十家世界500强企业提供过AI领域业务咨询、项目落地指导。 一个简短的介绍，概括不了六边形的我。没事爱写点文章，谢谢你喜欢它们。 蓝衣剑客 元神智算 CEO。WaytoAGI专栏作者。 火山引擎开发者领航KOL。清华大学数据治理研究中心 荣誉顾问。 阿里云AI训练营 讲师。 得到新商学 组局先锋/讲师。 丛书《Kimi高效办公》、《豆包高效办公》作者。 火山引擎社区、掘金AGI、LangGPT专栏作者/核心共建。拥有超过10年的软件行业经验，起草过多个AI领域国家级标准、报告。为数十家世界500强企业提供过AI领域业务咨询、项目落地指导。 一个简短的介绍，概括不了六边形的我。没事爱写点文章，谢谢你喜欢它们。 微信 公众号 微信 微信 公众号 公众号 铁轨 19世纪中期的美国，铁路热潮席卷全国，工人们正以惊人的速度向西部铺设铁轨。几乎每个月都有新的铁路公司诞生，各自修建着通往西部的线路。但在这股热潮背后，却隐藏着一个令人啼笑皆非的问题——铁轨宽度没人统一。说来好笑，当时各家铁路公司就像是一群固执的孩子，非要坚持自己的标准不可。有的采用4英尺8.5英寸轨距，有的偏好5英尺，还有些干脆用上了6英尺。这导致了什么结果？从东海岸到西部的一趟简单旅程，乘客和货物要经历多次换乘的折磨。有次听说，一批棉花从南卡罗来纳州运往马萨诸塞州，竟然要在途中卸下装上六次，几周才能到达！那种场景的荒谬不言而喻。 直到1886年，这个闹剧才画上句号。当时美国南方铁路公司下了个大决心：必须统一轨距。于是在1886年5月31日至6月1日的周末，他们动员了数万名工人，在短短36小时内将数千英里的铁轨改造成标准轨距（4英尺8.5英寸）[1]。结果如何？仅仅两天后，从新奥尔良出发的列车就能不停站直达芝加哥了。终于，一个真正意义上的全国铁路网诞生了。 说到这儿，今天的AI世界和当年的铁路有着惊人的相似之处。我们有了GPT 4、Claude、Gemini这些强大的语言模型，就像当年高效的蒸汽机车。但问题是，它们与外部工具和数据的连接方式简直乱七八糟，就像那些不兼容的铁轨，让整个系统效率大打折扣。而这正是我今天要聊的主题——"模型上下文协议"（Model Context Protocol，简称MCP）。它就像是AI世界的"标准轨距"，正在悄悄改变AI与外部世界的连接方式。不过在深入这个话题前，让我们先看看没有这个标准时，开发者们都遇到了哪些让人头疼的问题。 一地鸡毛 如果你曾经尝试让一个AI模型使用外部工具，肯定会有这样的感受：这也太麻烦了吧！现在的大模型，比如GPT、Claude、Gemini，它们在聊天和生成文本方面简直是天才。但一旦需要它们去用个日历、查个数据库、发个邮件，事情就变得复杂了。许多开发者抱怨，每次要让AI调用一个新工具，都像是要教一个固执的老人使用智能手机，从头开始，一点一点地教。