0%

MCP 协议与古茗排队事件解析 | 2025 年第 16 周草梅周报

本文在 草梅友仁的博客 发布和更新,并在多个平台同步发布。如有更新,以博客上的版本为准。您也可以通过文末的 原文链接 查看最新版本。

前言

欢迎来到草梅周报!这是一个由草梅友仁基于 AI 整理的周报,旨在为您提供最新的博客更新、GitHub 动态、个人动态和其他周刊文章推荐等内容。


最新 AI 动态

最近研究了下 MCP(Model Context Protocol,模型上下文协议),发现一些有意思的东西。

MCP 虽然看上去高大上,实际上只是个封装调用函数给大模型的协议。简而言之,就是把函数和函数的介绍发送给大模型,让大模型来判断下一步要调用哪些函数,MCP 在这个过程中只是进行了一些规范。

当然了,虽然实现方案就是这么的简单直接,但这并不代表 MCP 就不好用。

实际上,MCP 最大的意义就是统一了 AI 大模型和外部系统的连接方式,让系统对接 AI 大模型更加方便。

其次,通过预先确定函数,则可以更好的管控权限问题,在最极端的情况下,大模型也无法调用 MCP 没有提供的功能,在权限和安全问题上更加可控。

对开发者而言,通过 MCP 协议,可以简化开发所需的代码量,可复用他人的 MCP 集成(例如 GitHub/Google Drive 等。

此外,通过跨多步任务保持上下文连续性,避免了传统 RAG 的单次检索局限,增强了上下文感知能力。

当然了,最好的是,通过统一的 MCP 协议,可以兼容不同 LLM 厂商(如 OpenAI、Anthropic、DeepSeek 等),极大的降低开发压力。

MCP 现有的生态在快速爆发,发布仅一个季度,MCP Server 数量已接近 5000 个,主流厂商(如 OpenAI、腾讯云、阿里云)纷纷支持,东方超算等国内企业推出第三方服务平台。

甚至还出现了类似 MCPFlow 这样的 MCP 聚合搜索平台,更加方便快捷的对接 MCP。

虽然现在 MCP 生态还不是特别成熟,但在可预见的未来内,MCP 会成为调用 AI 大模型的主要方式之一。


古茗排队事件解析

最近参加了下古茗×崩坏星穹铁道联动的活动,抛开一些业务上的问题不谈,今天只从技术上谈这次联动存在的问题。

首先,最抽象的事情就是那最逆天的全国用户一起排队了。

img

喜欢我一百万用户一起排队吗?

img

此事在微博热搜亦有记载

我来帮各位理一下这里的逻辑。

由于用户量过大,所以要排队,这个逻辑很合理,但不合理的地方在于全国只有一个队列。

一个很显然的事情是:用户是全国分散的,也只会就近参与门店点单,所以,按门店来排队是最优解。如果说为了缓解各门店的压力,则至少该按区县排队,从而减少门店查询的压力。

而古茗程序员选择了最差的做法,将全国用户放在一个队列里,轮到之后才能去选择到店自取或者外送。

然而就算是这样,这个排队功能依旧存在 bug,用户可以点进历史订单再下单,就可以卡进门店……

image-20250420185806302

第二个抽象的事情就是,古茗的地图 API 调用量达到了上限。

可见到底有多少人

这里的问题就是古茗作为使用方,是向腾讯位置服务这边购买了一定额度的接口调用量,只不过联动的时候调用次数过多,超过了额度,被腾讯这边拦截了。

这个问题其实也不算技术问题,更多的是业务上没想到还有这样的问题,只能说没有备用方案。

image-20250420190334347

第三个抽象的事情就是无法支付了。

一般而言,订单系统都会把生成订单和支付分开,并且会在生成订单这一步锁定库存,然后走支付流程。

在这个过程中,在生成订单这一步承受流量是比在支付这一步承受流量来的方便的,因为订单系统一般是内部的,更加可控,支付系统是外部的,不一定可控(同时,一般还要处理来自支付系统的回调)。

不过,古茗没有在生成订单的时候就锁定库存,而是等到支付的时候再判断,此时就导致大量用户堵在支付步骤,导致支付业务崩溃。

不少用户(包括笔者)都是在反复支付失败后回到了点单页面,而此时联动套餐早已售罄……

当然,不锁库存对于非秒杀系统其实是有好处的,那就是不会因为用户进了订单而没有支付导致库存被无端锁住。

当然了,其实古茗程序员对于系统可用性还是做了一点优化的,比如说接口降级、刷新提示等image-20250420191803089

当然,代价就是用户会时不时看到等待刷新的提示,用户体验极差。

虽然上面从技术上分析了很多,但从技术上解决远不如从业务上解决。

本次联动最大的问题就是把来自线上的高额流量,直接击穿到了线下的门店,导致各家门店都爆满,而数量极少的主题店更是直接爆单,订单数奔着 2000+ 去了。

如果要解决问题,最好的方式就是开预售,售卖兑换券,让线上的流量在线上承担,然后线下承受的流量就会大大下降。

此时用户量已经被兑换券筛过一遍,上限不会超过兑换券数量,摊到每个门店之后就到了可控范围内。

如果要进一步优化的话就是线下门店也预定,事先知道有多少用户来点餐的话,那么也方便饮品和周边的准备。

总之,这次 古茗×崩坏星穹铁道联动 的本质还是流量分配失衡,将线上的高额流量直接击穿到线下,导致门店实际服务能力与线上流量严重不匹配。

由此引发的一些问题,值得业务方和技术方思考。

作为一个普通的玩家兼程序员,只希望后续的联动都能吸取下这次的教训。

最新 GitHub 加星仓库

  • CaoMeiYouRen starred afdian-linker - 2025-04-20 17:17:13
    爱发电 API 集成旨在提供统一的订单管理和外部查询功能。该项目主要使用 Vue 语言开发,目前有 1 个星标。
  • CaoMeiYouRen starred easevoice-trainer - 2025-04-20 17:16:34
    EaseVoice Trainer 是一款简单易用的语音克隆和语音模型训练工具,主要使用 Python 语言开发,目前在 GitHub 上获得了 188 个星标。
  • CaoMeiYouRen starred lexe - 2025-04-20 17:16:26
    将 Node.js 应用程序打包成单个可执行文件,且文件大小限制在 10MB 以内。主要使用 Rust 语言实现,项目在 GitHub 上获得了 300 个星标。

其他博客或周刊推荐

阮一峰的网络日志

HelloGitHub 热点速览

阿猫的博客

潮流周刊

二丫讲梵的学习周刊

总结

本周的更新和动态如上所示。感谢您的阅读!
您可以通过以下方式订阅草梅周报的更新:

往期回顾

本文作者:草梅友仁
本文地址: https://blog.cmyr.ltd/archives/2025-16-caomei-weekly-mcp-protocol-guming-queue-analysis-.html
版权声明:本文采用 CC BY-NC-SA 4.0 协议 进行分发,转载请注明出处!

坚持原创技术分享,您的支持将鼓励我继续创作!