MCP协议 vs Skills系统：选哪个更高效？我们集合了127位用户真实观点，结论在这_服务软件

1. 为什么现在MCP越来越好用?揭秘我最多使用的Model Context Protocol!

2. MCP 不香了,Claude Code 又推出了 Skills!!(保姆级安装和使用教程分享)

3. 诞生才一周年，MCP凉了

4. Skills vs MCP，谁才是「大模型的 HTTP 时刻」？

5. 产品团队即代码：用 Claude Skill 重构组织能力系统

6. 【90分钟公开课】程序员失业？不存在的。手搓 Claude Skills “软编排”系统实战 (全程高能) | 回到 Axton

7. MCP协议迭代一周年：AI Agent从实验室走向生产环境的关键转折

8. 西瓜老师-2025年大模型 MCP 技术实战课

9. 微软发布云端MCP Server：企业级AI Agent开发的分水岭

10. MCP 双轨：技术改善与统一标准化

11. 据说，80%的人都搞不懂MCP底层？

12. MCP是不是真凉了？

13. 深度解析 Claude：如何打造高阶 Skill 以及它与 Tool 的本质区别

14. 新手入门指南.pdf

15. AIAgent终于不“卡壳”了！MCP解决接入难题，Skills弥补专业短板

16. 给 AI 装上“USB-C”接口：通俗解读 MCP 协议

17. Virtual MCP服务器：一种针对工具过载问题的基于用例驱动的解决方案。

18. 未来可能有个新职位，叫「Skill设计工程师」

19. OpenAI Codex 终于坐不住了！正式接入支持Claude Code Skills

20. 大模型入门必读：一文掌握MCP、Agent、RAG、RPA、A2A这5大"黑科技"

21. Agent架构新方向？Claude Skills工作原理解析

22. MCP服务构建、使用

23. 有手就会！Youtube下载字幕转录Claude Code Skill

24. 深度解析 Claude Skills 的渐进式上下文加载：AI 技能的高效赋能范式

25. MCP：AI工具调用协议的革命还是过渡？

26. 强化Dify！还支持MCP，这款开源AI数据库绝了～【附喂饭级教程】

27. 基于Mobile MCP与AI的“一套指令”自动化测试实践

28. 从 Prompt 到 Skills：Claude 和 LangChain 带来的 AI 新范式

29. 新项目上线！ C++ MCP 服务器实现

30. LangGraph学习笔记(八):MCP协议和开发

31. MCP技术深度解析：如何用数据库+AI解决知识库检索难题，零代码吊打传统RAG！

32. 让 Claude Code Skills 100%生效的NB技巧

33. 利用 MCP 的代码执行：构建更高效的代理

34. 西瓜老师 2025年大模型 MCP开发技术实战课大模型工程师必会技能

35. 一文理清什么是MCP

36. MCP 刚满一周年，就凉了？

37. AI 接管数字世界，再谈MCP, Agent

38. 看漫画学会Claude Code Skills！

39. Codex 即将支持 Skills：让 AI 编程助手拥有"记忆力"

40. RAG-MCP：利用检索增强生成和模型上下文协议增强人工智能代理

41. 从“看懂”到“落地”：MCP开发的底层方法论（可复用、可迁移）

42. FastMCP：5分钟搞定MCP服务开发，让AI智能体调用任意工具

43. AI产品如何应对MCP的不确定性

44. Anthropic正式出手

45. 大模型进阶之路

46. 2025年前沿技术

47. #如何评价苹果引入外部AI#苹果打破封闭，计划接入ChatGPT、谷歌Gemini外，国行或合作阿里、百度，让Siri和Apple Intelligence成AI聚合平台。其开放原因很明确，一是弥补自研AI的短板，二是适配不同地区法规（如国行的合规要求），三是应对安卓阵营的竞争以避免Siri功能落后，且会通过MCP协议搭建底层框架，实现不同AI跨App协同，既降低自研风险又巩固硬件生态优势。这种开放能让用户按需选AI，比如想要全球服务选ChatGPT、侧重本土体验用百度或阿里，但也可能带来体验碎片化、选择混乱的问题，而这次转型本质是从做AI转向做AI平台，成败关键就在于能否平衡AI多样性与使用体验统一性，毕竟用户要的从来不是更多AI，而是更好用的AI

48. 大模型只是能力，必须要跟场景结合。 #大咖观察 #红衣聊AI #大模型

49. 当微信支付开放MCP之后，我却有一点后怕。

50. 这可能是我写的最“接地气”的 AI 科普：从家政阿姨看懂 Agent、MCP 和 Skill我家请了个家政阿姨打扫卫生，这位阿姨高中毕业，但是经过了家政公司专业训练，学会了该怎么针对不同家庭去打扫卫生，使用各种不同的清洁工具。当然她不可能记住所有工具的用法，所以额外的，家政公司还给她了一本《家政技能手册》，这个手册有两部分，一部分是目录，不同技能的简要介绍，字数不长，阿姨每次来干活之前都会读一遍目录，以便需要时能想起来；《家政技能手册》的另一部分是技能的详细介绍，详细介绍里面不仅说明了各种技能的详细做法，有的还有配套的手册，有的还需要借助一些工具。家政公司还给阿姨配备了一款定制的平板电脑，这个平板电脑支持一种智能家居协议，所有支持这种智能家居协议的家电她都可以用这个平板电脑连上操作。为了提升效率，家政公司还给她配备了便携式扫地机器人，每次她都开车带上，一些扫地的任务就直接使用扫地机器人。为了我经常需要阿姨来家里打扫，为了避免麻烦，所以我把我家的一些基本情况写成了说明书，好让阿姨知道该怎么更好的清扫我们家，并且阿姨很专业，每次工作完都写了一份详细的工作记录，这样她下次来还可以看一下以前都做了啥。虽然有这个说明书，当然每次过来我还是要交代一下：“阿姨，明天我家要开了个 party，客厅一定要弄干净整洁点。”---说了这么多我当然不是为了炫耀我家请了个阿姨干活或者帮这家家政公司打广告，而是借这个来“辅助解释”一些常见的 AI 名词。- 家政阿姨：AI Agent，有基础知识（类似于大语言模型），经过训练，会规划会使用工具- 每次过来交代的话：Prompt，一次性的、即时的指令。阿姨听到就会去做，做完就结束了。- 扫地机器人：SubAgent，专业的、自主的执行者。主AI（阿姨）负责委托和监督，机器人（SubAgent）负责具体执行。这大大解放了主AI的精力（上下文窗口），让她可以去干更重要的活。- 智能家居协议：MCP(模型上下文协议)，智能家居协议就是那个家电的统一标准：支持智能家居协议（MCP 协议）的家电工具阿姨都可以使用。- 《家政技能手册》：Skills，家政技能手册可以帮助阿姨（Agent）学会她没有被训练过的技能，而且这些技能是“动态加载”和“渐进式披露”的。“动态加载”的意思是：阿姨只有在需要用特定技能的时候，才会去《家政技能手册》翻该技能的详细内容。“渐进式披露”的意思更进一步：阿姨不会一开始就把整本手册都读完，她干活前先看一眼目录（元数据，大约 100 个词），“哦，这个技能跟我现在的任务有关”。然后它再打开读具体章节（完整的指令，小于 5000 词）。这有什么好处？省脑子（省上下文窗口）。确保阿姨总是在最需要的时候，用最少的“脑力”获取最关键的专业知识。- 我家：Project，存放了与我家相关的说明书、历史信息。希望上面这个比喻能帮助你更好的理解这些概念。⚠️ 需要注意的是，这些比喻只是帮助你理解这些概念，并不能代替你深入的去学习和理解这些知识。Q & AQ：假设这个阿姨没学过洗碗，那么她应该去看手册用技能呢，还是去用洗碗机器人呢？A：如果洗碗这个技能没训练过，取决于两点：1. 家政公司给她的指南（系统提示词）有没有给她洗碗这个工具可以用？如果有提供这个工具，那么她优先直接使用这个工具2. 家政公司给的《家政技能手册》目录里面有没有洗碗这个技能？如果没有工具有技能，就会去阅读技能3. 如果都没有，那她可能会用网络搜索工具去搜索洗碗指南，搜到了就现学，搜不到也许还会自己做一个工具（写代码编工具），或者她甚至可能会用洗衣机去洗碗（会尝试其他类似工具），Agent 总会采用各种方法去尝试完成任务

51. Anthropic 发布了 Agent Skills ，是很好的东西，可以引导 Agent 获取某些技能，而且制作起来很方便。制作一个技能，就好像给新员工写一份入职手册。不需要为每一个不同任务都专门打造一个独立的智能体，而是只要共享特定领域的专业知识，任何人都可以快速将智能体变成对应领域的高手。我之前提到过朋友做一个基于他们 Design System 的 Agent，需要通过提示词引导 Agent 去 grep 检索文档，现在就更简单了，只要在全局或者项目目录下的 .claude/skills 下面添加目录，并且放一个包含meta信息的 SKILL\.md 文件，就可以引导 Agents 去学习使用这些 Skill。官方也给了一个例子就是 PDF Skill，就是包含了一系列 PDF 操作的说明和脚本，Agent 借助这些脚本，就可以操作 PDF，比如提取表单之类。也就是说 Skill 不仅可以包含文档，还可以包含可执行的脚本。需要注意的是 Skill 里面的 Meta 信息是默认会加载到上下文文的，其余信息用到才会加载。更多介绍：www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills

52. 想深度了解Claude Agent Skills，看这篇就行了AI Agent和工具（Tools）的热潮席卷了整个技术圈，几乎成了大模型应用的标配。然而，当我们深入剖析Anthropic Claude的Agent Skills实现时，却发现了一条与众不同的技术路径。它并非我们熟知的函数调用或插件执行。1. Skills 不是代码，而是高级“提示词模板”当我们谈论给AI增加“技能”时，脑海中浮现的通常是可执行的Python函数或API端点。Claude 的Skills与传统的函数调用或插件有着本质区别，它们不直接运行任何Python或JavaScript代码。Skills的真正作用是“提示词扩展（prompt expansion）”和“上下文修改（context modification）”。当一个skill被调用时，它实际上是向当前的对话历史中，动态注入了一段为特定任务量身定制的、极其详细的指令。这些指令会彻底引导Claude后续的思考方式和行为路径，就像给一个通用型专家临时“灌输”了某个领域的专业知识。它将AI能力的扩展与执行代码所带来的安全风险和复杂性完全分离开来，实现了前所未有的灵活性和安全性。Skills are not executable code. They do NOT run Python or JavaScript, and there’s no HTTP server or function calling happening behind the scenes. ... Skills are specialized prompt templates that inject domain-specific instructions into the conversation context.2. 没有算法路由，全凭大模型“自己决定”用哪个技能Claude选择使用哪个skill的决策过程也比较有特色。传统思路可能会涉及复杂的路由系统，比如基于关键词匹配、正则表达式、向量相似度搜索，甚至是专门的意图分类模型。Claude Agent Skills 将所有可用技能的名称和描述打包成一段文本，然后将这段文本作为名为Skill的“元工具（meta-tool）”的描述信息。当用户提出请求时，Claude就凭借其原生的、强大的语言理解能力，在一次完整的前向传播（forward pass）中，直接判断用户的提示词与哪个技能的描述最为匹配。这种设计体现了对大模型核心推理能力的极致信任，是一种“第一性原理”的体现。它没有在应用层添加任何复杂的工程逻辑，而是把决策权完全交还给了大模型本身。There is no algorithmic skill selection or AI-powered intent detection at the code level. The decision-making happens entirely within Claude’s reasoning process based on the skill descriptions provided. ... This is pure LLM reasoning.3. 独特的架构：技能信息不在System Prompt里，而在“工具”里许多AI系统（如ChatGPT）习惯于将可用的工具信息一股脑儿地塞进系统提示词（System Prompt）中。这种做法虽然直接，但当工具数量庞大时，会导致系统提示词变得异常臃肿和低效。Claude另辟蹊径。它的Agent Skills信息并不存储在系统提示词里。相反，所有的技能都被封装在一个名为Skill的“元工具”中。这个Skill元工具与其他标准工具（如Read, Bash）一起，并列存在于每次API请求的tools数组里。所有可用技能的列表，动态地构成了这个Skill元工具的描述部分。这种架构的优势显而易见：它极大地解放了系统提示词，让技能的管理变得更加模块化和动态化，可以根据会话需求灵活地加载或卸载，而不会污染全局的系统设定。4. 优雅的实现：一条消息给人看，一条“隐藏”消息给AI看一个优秀Agent系统的设计，必须在“用户透明度”和“界面简洁性”之间找到平衡。如果系统调用skill的过程完全隐藏，用户会感到困惑；如果把几千词的内部指令全部展示在聊天窗口，用户界面则会变得混乱不堪。Claude通过一个名为isMeta的布尔标志，巧妙地解决了这个矛盾。当一个skill被激活时，系统会向对话历史中注入两条消息：1）第一条消息 (isMeta: false): 这是一条简短的元数据信息，比如“‘pdf’ skill正在加载”。这条消息在用户界面中是可见的，清晰地告知用户系统正在做什么。2）第二条消息 (isMeta: true): 这条消息包含了完整的、可能长达数千词的SKILL.md指令内容。它在用户界面中是不可见的，但会完整地发送给API，作为Claude执行任务的详细行动指南。这种“双通道通信”机制既保证了用户对系统行为的知情权，又避免了海量的内部指令污染聊天界面，实现了极致优雅的用户体验。5. 终极心智模型：技能的本质是“上下文修改器”，而非“动作执行器”我们可以提炼出一个关于Claude Agent Skills的终极心智模型。如果说传统的工具是“动作执行器”（Action Executor）——执行一个动作，返回一个结果；那么Claude的技能则是“上下文修改器”（Context Modifier）。它的核心作用是修改两个层面的上下文：首先，它通过注入详细指令来修改对话上下文（conversation context），从而改变Claude的思考模式和工作流程；其次，它通过变更工具权限和模型选择来修改执行上下文（execution context），从而改变Claude在特定任务中被允许使用的能力。理解这个根本性的区别是掌握Claude Agent Skills的关键。Skills并不是直接去解决问题，而是通过“赋能”和“引导”的方式，让Claude本身变成一个能够更好地解决特定领域问题的专家。By treating specialized knowledge as prompts that modify conversation context and permissions that modify execution context rather than code that executes, Claude Code achieves flexibility, safety, and composability that would be difficult with traditional function calling.总之，Claude Agent Skills的设计哲学，为我们展示了一种与传统函数调用截然不同的AI能力扩展范式。它通过一种基于提示词的、精巧的上下文修改机制，实现了极高的灵活性、安全性和组合性，将大模型自身的推理能力推向了核心。#ai创造营# #程序员#

53. 对于向深入学习上下文工程（Context Engineering）的同学，Anthropic刚发的这篇《Code execution with MCP: Building more efficient agents》又是一篇必看的文章。这篇文章讲的是如何解决 MCP 工具太多的问题，但凡你做过 Agent 开发，用了大量 MCP 工具，就会知道 MCP 工具多了后最大的问题就是上下文占用太多，不仅导致成本高，还会影响推理和生成质量。另外一个问题就是 MCP 工具返回的中间结果也会挤占大量的上下文空间。看这文章的时候忍不住夸了一下 Manus，他们确实在上下文工程方面探索的很深入了，里面的工程技巧和他们以前分享过的很类似。> Manus 把工具分成了 3 层，预定义了很多 Shell 工具，也是让 Agent 通过文件系统直接检索，另外也会实时编写 Python 代码来创造工具网页链接> Manus 《AI 智能体的上下文工程：构建 Manus 的经验教训》解读网页链接Anthropic 的方案也很简单直接，就是把“代码”也当作工具的一种，然后从代码中去调用 MCP。这样做有很多好处：1. 解决了系统提示词中工具定义太多的问题不需要在系统提示词中加载所有 MCP 工具，只需要定义一个“代码”工具。那需要工具了怎么办呢？这些代码都保存在统一的目录下，去目录检索下就能找到合适的工具了，比如这是文中的一个目录示例：servers├── google-drive│ ├── getDocument.ts│ ├── ... (other tools)│ └── index.ts├── salesforce│ ├── updateRecord.ts│ ├── ... (other tools)│ └── index.ts└── ... (other servers)找不到现成的工具怎么办？直接现写一个！写完了还可以保存起来下次继续用。2. 解决了 MCP 工具返回结果太长的问题比如说我们要用 MPC 工具获取 1 万行数据后筛选转换出合格的数据，就可以先从代码中调用 MCP 工具获取这 1 万行数据，然后从代码中去筛选过滤，最后只返回 5 条数据，这样上下文中就只需要保留那 5 条过滤的数据，而不是像以前一样有 1 万条数据在里面。3. 解决了数据隐私问题如果你直接使用 MCP 工具，工具返回的数据都要加载到上下文每次上传给 LLM，用代码就可以对敏感数据先二次处理再加到上下文4. 中间结果持久化和技能沉淀代码可以把一些中间结果写入文件保存到硬盘，一方面可以不占用上下文空间，另一方面也可以随时从硬盘避免反复调用 MCP。还有就是虽然很多代码是临时生成的，但是这些临时生成的代码可以保存下来，沉淀为“技能”（Skill），加上 SKILL .MD 文件就和 Claude Code 的技能一样可以被反复使用了。可能有人还记得 2023 年 Jim Fan 他们团队做的一个玩 Minecraft 的 Agent Voyager，就能把玩游戏的技能写成代码，保存起来后续使用，最终让 Agent 在 Minecraft 中做很多事。现在想想还是蛮超前的。网页链接原文：网页链接翻译：网页链接

54. Anthropic 官方教程：为 Agent 设计高效工具的最佳实践

55. 给 AI 设计“工具”时，不要把 AI 当成“程序”，要把它当成“用户”。大多数人，是把自己的后端 API 直接封装成工具给 AI。比如查 Slack，你给了它三个 API 工具：1. 加载对话；2. 用用户 ID 查用户名；3. 用频道 ID 查频道名。结果 AI 为了看懂一条消息，得手忙脚乱地调用三次工具，然后自己去拼凑。正确的做法是：你的工具应该对标你的“UI”，而不是“API”。你应该只给它一个工具，叫“查看 Slack 频道”，这个工具在后台默默调用完那三个 API，然后一次性把所有 ID 替换成名字、对话渲染得漂漂亮亮，就像你在电脑上看到的那样，然后把这个最终结果返回给 AI。

56. 继昨天Google Agents 白皮书（网页链接），我们今天把mcp的白皮书也总结一下。 Agent Tools & Interoperability with Model Context Protocol (MCP)这应该是目前 MCP 体系最系统的白皮书（之一）了吧，通篇结构清晰，既讲了工具在智能体系统中的定义和设计原则，又深入分析了 MCP 在技术架构、安全与治理方面的优势与风险。1. 工具是智能体的“手与眼”。大模型本质上只是一个模式预测引擎，不能主动感知世界或执行动作。工具让模型拥有了外部交互能力，也因此成为智能体系统的核心组件。文中对工具类型有很清晰的划分：Function Tools（函数调用型）、Built-in Tools（内置工具）和 Agent Tools（智能体级调用）。特别有意思的是，Agent 本身也可以被封装成一个 Tool，这意味着多智能体系统可以通过“工具接口”彼此互操作。2. 工具设计的关键是可解释与细粒度。文档强调“Describe actions, not implementations”，也就是工具描述应聚焦行为语义，而非实现细节。并提出几个值得长期遵守的设计准则：文档清晰、输入输出有 schema 验证、输出简洁、错误信息具引导性。这些看似“文档规范”的建议，其实是让 LLM 能在推理过程中正确选择与调用工具的前提。3. MCP 出现的根本原因，是为了解决“N×M 集成问题”。过去模型和外部系统之间的连接高度碎片化，每个工具都要单独适配。MCP 通过标准化接口和通信协议把模型、工具和数据源解耦，形成“Host–Client–Server”的三层结构，从而实现了可复用、可组合、可动态发现的工具生态。4. MCP 的优势在于生态与扩展性。它让工具注册、发现与调用变得统一，支持动态工具加载，这使得智能体系统不再需要在部署前定义好所有能力。文中提到 MCP Registry 的构想（类似 npm 或 PyPI），也许会形成 AI 工具层的“包管理体系”。这将极大加速企业级智能体生态的互通。5. 但 MCP 也带来了新的安全威胁。白皮书后半部分几乎一半篇幅都在讨论风险，包括： 1）Dynamic Capability Injection：服务器可动态更改工具集，导致智能体意外获得高危能力； 2）Tool Shadowing：恶意工具通过相似描述“抢占”合法工具调用； 3）Confused Deputy 问题：智能体误用自身权限代替用户执行越权操作； 4）数据泄露与 prompt 注入：通过工具输入输出通道泄露敏感信息。文中提出的防御策略（如工具白名单、版本固定、mTLS、HIL 审批、输出净化、最小权限原则等）都是非常实用的企业级落地建议。6. MCP 的发展路径很可能会复现云计算早期的模式——底层协议开放，但企业实际使用都建立在“托管与治理层”之上。未来我们也许会看到“安全版 MCP 平台”，它提供身份管理、审计追踪、工具签名验证、访问控制等功能，就像当年的 API Gateway 成为了 REST 的守门人。7. 另一点值得注意的是“上下文膨胀”问题。文中指出，当 MCP 工具数量增多时，所有工具定义都要塞入模型上下文，会导致 tokens 暴涨、推理性能下降。文中提出用“RAG 化的工具检索”替代预加载——先检索，再动态注入。有个名词叫“ToolRAG”。MCP 已经成为智能体生态走向工业级互操作的关键里程碑，但它还远没到“可直接上生产”的成熟阶段。未来的重点不在于“协议标准”，而在于“安全与治理层”的建设。只有当工具、智能体与企业系统之间的边界被有效约束，Agent 才能在真正意义上成为可信的“行动者”。#ai创造营# #程序员#

57. Claude 的 Agent Skills 本质上就是：AI 模型不必把所有能力硬塞在绝对静态的“大脑”里，而是通过“可插拔技能模块”的方式，让模型在面对不同任务时“辅以专属插件／套路”。这种方式在软件工程里早就被验证为经典，比如插件系统、微服务、模块化设计。可以关注 Antropic 这个开源的 Skills 项目：github.com/anthropics/skills「Skills 是一组“指令、脚本、资源”的集合，Claude可以动态载入这些 Skills，从而在特定任务或领域里表现得更好、更定制化」#人工智能##程序员#

58. 【最新玩法】n8n工作流秒变MCP工具，直连各种MCP客户端，零代码实操！

59. 3 分钟讲透什么是 MCP，AI 小白也能懂！

60. Nacos 开源 MCP Router，加速 MCP 私有化部署

61. 利用 MCP Prompts 实现工作流自动化

62. 在荣耀AI终端生态大会上，荣耀产品线总裁方飞正式发布八大AI场景化生态解决方案！覆盖家居、车联、陪伴、宠物、运动健康、教育、音频、办公等高频场景。智能家居可通过YOYO智能体主动联动空调、电视等高频设备车联方案覆盖超140个品牌、10000种车型潮玩陪伴、宠物健康等创新场景，更融合多模态情绪感知与反馈、MCP协议与数字孪生技术，让科技更有温度。方飞表示，这些解决方案连通软硬件，是荣耀生态构建的核心引擎，也将开放给行业，希望与行业一起进行AI垂域的生态共创。打造繁荣创新的AI生态。

63. 微信支付MCP上线 AI从“陪聊”到“收钱”：支付MCP如何让你的AI应用实现商业闭环？附10大场景与3大杠杆

64. 8000字讲解MCP与Function Call、Agent的关系

65. 目前最好用的AI写作工具是什么？

66. 解决 MCP 带来的上下文过长问题如果不启用代码执行（Code Execution），该如何缓解 MCP 带来的上下文和 token 过长问题？本周 Anthropic 发布了一篇文章，讲述了 Code Execution 能够解决 MCP 引发的两大痛点。确实，代码执行机制在提升效率、降低 token 消耗上有明显优势。但在很多企业环境中，出于安全、合规或运维限制，并不具备开放代码执行的条件。那么，在无法使用 Code Execution 的情况下，如何依然有效解决 MCP 带来的上下文冗长问题？我们先看原文提到的两个核心问题：1. 工具定义过多导致上下文窗口被占满；2. 工具中间结果消耗了大量 token。下面我们分别分析应对思路。一、避免“工具定义占满上下文”总体思路是：延迟加载 + 结构化查询。1. 分层加载工具定义不要在初始化阶段就把所有 MCP 工具定义一次性加载进上下文。可以先让模型仅了解“有哪些服务器”以及“每个服务器下的工具名称和简短描述”。例如：可用服务器：google-drive（文档相关）salesforce（CRM 相关）notion（知识库相关）当模型真正需要操作 google-drive 时，再通过类似 get_tool_definition(server="google-drive", tool="getDocument") 的调用获取完整定义。这样可以避免模型在初始化时被大量工具定义占满上下文。2. 基于搜索的按需加载构建一个 search_tools 接口，让模型能通过关键词（如 “email”、“lead”、“calendar”）搜索工具，并按需返回信息。返回粒度可分为：（1）仅返回工具名称；（2）名称 + 简介；（3）仅当模型明确请求时才返回完整 schema。这样 MCP 层就像一个“工具搜索引擎”，而不是一次性暴露全部内容。3. 缓存与复用策略对于高频使用的工具，可以将其定义缓存到短期上下文或系统记忆中，而非每次都重新加载全部定义。这种做法能在多轮交互中平衡上下文长度与调用效率。二、降低“中间结果占用上下文”可以通过在 MCP 客户端层面对中间结果进行压缩或引用处理，减少 token 消耗。1. 结果摘要当工具返回结果时，客户端先生成“摘要版”结果再返回给模型。例如，在获取会议记录后，不直接返回全文，而仅传递：已获取会议记录，共 12 页，主题：Q4 目标。样例前 5 行：……如需全文，请再次请求 getDocument(full=true)。模型若确实需要全文，再发起请求。这样可显著减少 token 消耗。2. 分页与数据采样对于表格或列表类数据（如 Google Sheet 或数据库查询），可以让 MCP 接口支持分页或条件参数，让模型每次仅获取部分内容（如前 100 条或满足过滤条件的数据）。3. 服务端数据操作尽可能在服务端完成数据筛选，而不是返回整批数据后再由模型过滤。例如 getSheet(sheetId, filter="Status='pending'")，直接在服务端筛选结果，避免中间数据占用上下文。4. 结果引用对于体量大或敏感的数据，可以采用“结果引用”的方式。模型只接收结果 ID（如 result_ref_12345），当需要时再通过 MCP 客户端获取对应数据。这种方式相当于在“无代码执行”的环境下，模拟“数据保留在外部，模型按引用访问”的机制。通过以上方法，即使不启用代码执行，也能在 MCP 架构下显著降低上下文开销，提升响应速度与 token 利用效率。#ai创造营##科技#

67. 实际上，LLM + MCP ，已经可见的...

68. 一文读懂MCP及三大传输协议

MCP协议 vs Skills系统：选哪个更高效？我们集合了127位用户真实观点，结论在这

精选参考来源