#MCP

2周前
MCP so 秒开优化经验总结👇 1. 底层框架升级 新版本升级到了 ShipAny v2,对应组件是 nextjs15 + react19 + tailwindcss4。底层框架升级带来了更好的 SSR 渲染性能,构建效率更高,构建产物体积更小,配合 cloudflare 的 CDN 分发,让静态资源加载速度更快了。 2. 部署方案升级 新版本使用 OpenNext 包裹,部署到了 cloudflare workers,跟之前部署在 cloudflare pages 的方案相比,支持 Node.js 运行时,可以使用更加完整的 nextjs 特性,配合 cloudflare 的 KV,R2 等组件,在动态读取数据时效率更高了。 3. 数据索引 之前的版本,数据库用的是 supabase, 用户每次访问都需要实时读取数据,数据量在增长、公网调用延时高,因为用的是 SSR(服务端渲染,需要读到数据再显示页面),最终表现就是用户打开页面很慢。 新版本优化,给数据表建索引,根据数据查询语句创建复合索引,比如 idx_featured_project (type,is_featured,created_at),让读取推荐的 server 或client 数据时速度更快。 4. 数据缓存 给数据表建索引只是让从数据库读数据更快了,但是导航站大部分情况是没必要实时读数据的,因此需要加一个数据缓存,减少对数据库的访问。 因为部署在 cloudflare,直接使用 cloudflare 的 KV 组件做缓存是最方便的,只需要在 worker 的配置绑定一下 KV,然后通过 set,get 方法存,取数据就行了。比如把从数据库读到的 featured servers 缓存到 KV,设置 1 小时后自动过期,这样 1 小时内这部分数据的读取就只会走 KV,速度更快了。 5. 增量静态再生 新版本使用 ISR(增量静态再生)代替原来的 SSR(服务端渲染),主要是在访问页面 page.tsx 里面加上这两行: export const dynamic = "force-static" export const revalidate = 600 dynamic = "force-static" 指示 nextjs 在构建阶段生成静态页面,cloudflare worker 自动把静态资源发到 CDN,用户访问页面走 CDN,速度飞快。 revalidate = 600 指示 nextjs 距离上一次生成静态页面超过 10 分钟就重新生成,这样新产生的数据最多等十分钟就能被用户访问到。 ISR 是秒开的关键。 6. 图片懒加载 新版本使用了 react-lazy-load-image-component 这个 npm 包来实现图片懒加载,让图片加载不影响页面渲染,用户打开页面更快。 因为没有部署在 vercel,next/image 的很多优化特性用不了,所以选择一个轻量的图片懒加载库,而不是用 next/image。 7. 链接页面预取 通过 next/link 替换带链接的 a 标签,自动预取页面,当用户点击链接时,目标页面已经加载好了,就会快速打开新的页面,体验很好。 总结: MCP so 通过升级底层框架,配合 ISR,充分利用了 cloudflare 上的 KV,R2 等组件实现数据和静态资源缓存,配合 cloudflare CDN 分发优势,从而实现了秒开。 经验可复制性: 1. 如果你的项目是基于 ShipAny 开发的,记得更新 cloudflare 分支的最新代码 2. 如果你的项目是基于 nextjs 的,可以参考 OpenNext 文档包一层,部署到 cloudflare workers 3. 如果你的项目需要频繁读取数据,记得合理添加数据库索引,同时设置数据缓存(Redis 或者 cloudflare KV 之类) 4. 如果你的项目不需要实时展示数据(比如导航站),记得设置 ISR,通过静态构建加速访问,配置 revalidate 时间,增量生成新内容 5. 如果你的项目涉及大量图片/视频等资源,记得压缩资源体积,上传文件存储,通过 CDN 做分发
1个月前
#BestBlogs 一文带你 "看见" MCP 的过程,彻底理解 MCP 的概念 | 阿里云开发者 深度解析 AI 上下文协议(MCP),对比 RAG 与 Function Calling,并通过实践演示理解其工作流程。 摘要: 文章详细介绍了模型上下文协议(MCP),一个旨在标准化 AI 助手与外部系统连接的开放标准。作者首先回顾了 RAG 和 Function Calling 等相关概念,阐述了它们与 MCP 的联系和区别。接着,文章深入讲解了 MCP 的核心组件(主机、客户端、服务器)及客户端-服务器架构,并对比分析了 MCP 相较于传统 API 在动态适应性方面的优势。随后,文章通过 ModelScope 的 MCP 市场和 Cherry Studio 客户端,一步步演示了 MCP 的实际配置和调用过程,通过开发者模式让读者“看见”并理解模型选择工具并请求服务器的数据交互流程。最后,文章总结了 RAG、Function Calling 和 MCP 在借助外部工具增强大模型能力上的共同本质。 主要内容: 1. MCP 是连接 AI 助手与外部数据/工具的开放标准 -- 模型上下文协议(MCP)由 Anthropic 开源,旨在为 AI 模型访问内容、工具提供标准化的“USB-C”式接口,提升 AI 应用的互操作性。 2. MCP 采用客户端-服务器架构,组件包括主机、客户端、服务器 -- 主机提供 AI 交互环境,客户端运行于主机内与 MCP 服务器通信,服务器暴露工具、资源、提示等功能,实现结构化互动。 3. MCP 通过动态能力描述克服传统 API 硬编码问题 -- 客户端能查询服务器当前功能并动态适应,无需硬编码参数变更,提高了 AI 应用与外部系统集成的灵活性和稳定性。 4. RAG、Function Calling、MCP 本质都是增强大模型外部能力 -- 这几种技术殊途同归,都是为了让大模型能够获取外部信息或使用外部工具,以完成更复杂、更准确的任务。 5. 通过开发者工具可“看见”MCP 调用的实际过程 -- 文章通过工具演示,展示了 AI 应用选择 MCP 工具、发送请求、接收结果,并最终由大模型生成回复的完整流程,增强体感理解。 文章链接:
「Qwen3, Token, Agent」分析 added_tokens, 如主板上的卡槽,预留大模型新功能空间。 昨天Qwen3发布,最亮眼的是,原生支持agentic tool call以及MCP。这篇分析,主要从tool call入手,了解大模型中added_tokens的作用和意义。 每当大模型发布,我都会打开它的tokenizer.json去看added_tokens。 added_tokens的意义在于,在LLM的vacabulary中添加特殊token,我自己称之为 “协议token”,这部分token不会被BPE分词,会完成输出,目的就是规则性地提示大模型此处要进行特别的功能,比如tool call和thinking。 当我们打开Qwen3的tokenizer.json, 会很看十几个added_tokens,我把它们总结如下,并加上我对他们功能的理解和猜想: 普通会话类: <|endoftext|> <|im_start|> <|im_end|> :会话边界 Tool call,Agent类: <tool_call> / </tool_call> : 函数执行JSON <tool_response> / </tool_response>:工具执行结果 <think> / </think>: 思考 短评: [像不像Paper: ReCall? 参考我前一篇分享] 多模态类: <|vision_start|End>: 预留视觉空间 <|image_pad|>:预留图片空间 <|video_pad|>: 预留视频空间 短评:Qwen3只支持文本,但未来一定会多模态! 代码和RAG类: <|fim_prefix|>: 代码类 <|repo_name|>:代码repo <|file_sep|>:大文件 比喻的来说,这些added_token就像是计算机主板的卡槽,为新的功能,新的性能,提前预留空间。 比如tool call,agent类,Qwen3已经支持,那就说明这个卡槽被利用,如何实现的,就是training recipe (SFT+RL),具体的可以参考我分享的ReCall, ReSearch, ReTool, APR, PASTA等文章。 那Qwen3是如何支持MCP的呢? 一个完整例子 用户问题:When will the ISS fly over Stockholm next, and could you add a calendar reminder for me? 在mcp server中定义了两个tool来追踪国际空间站: def get_next_iss_pass(city: str) -> dict: def add_calendar_event(title: str, datetime_utc: str) -> str Jinja template会直接把用户的问题结合added_token,render给大模型: <|im_start|>user When will the ISS fly over Stockholm next, and could you add a calendar reminder for me? <|im_end|> <|im_start|>assistant <think>I need an orbital pass → then a calendar entry.</think> <tool_call>{"name":"get_next_iss_pass","arguments":{"city":"Stockholm"}} </tool_call> <|im_end|> 工具get_next_iss_pass的返回结果,直接给mcp host side, <tool_response>{"datetime_utc":"2025-04-30T19:12:00Z"}</tool_response> <|im_end|> 然后继续触发下一个tool call。 喜欢钻研的朋友,会发现其实DeepSeek R1也有类似的add_token, "<|tool▁calls▁begin|>", 但它不支持mcp,因为它只是预留了,并没有在实际训练中让LLM跟mcp互动。 希望看完这篇分享的你,明白了added_token是什么,你也许也更加深刻地理解了我之前分享的一系列“协议token”的文章,ReCall, ReSearch, ReTool, APR, PASTA.