2025-05-10 08:00:00
有一天,我突然发现无法从外部连接家里的NAS了。我开始慌了,预感到不妙。莫非是公网IP被运营商回收了?我也成为一个大内网用户了。所幸已经有不少成熟的方案,而FRP就是其中之一。它开源免费,易上手,并且支持的协议还比较多(当然,部署服务器的费用得另算)。晚上回到家,我决定面对现实,好好折腾一番。虽然网上现有的FRP教程多数只完成了‘能用’的第一步,但距离‘好用易用’还有点距离。
本文简要描述一下我使用FRP的过程,并且看一下我们如何给FRP套上坚固的盾牌,配上易用的武器。我假定你已经知道FRP是什么,并且最基本的FRP使用已经了解。不了解也没关系,继续看你也大概能懂。
虽然咱数据或许对别人而言也没那么重要,但自我保护意识也不可松懈。
frp 是一个专注于内网穿透的高性能的反向代理应用,支持 TCP、UDP、HTTP、HTTPS 等多种协议,且支持 P2P 通信。可以将内网服务以安全、便捷的方式通过具有公网 IP 节点的中转暴露到公网。
为了方便迁移和管理,在使用FRP时我首推容器化方案。不过似乎没看到官方的镜像,但dockerhub上有一个社区广泛使用且下载量很高的镜像,大抵错不了:snowdreamtech/frpc
和snowdreamtech/frps
。
FRP是分客户端和服务端的,需要在不同的机器分别配置。frpc
一般部署在内网,用于将内部需要对外暴露的服务定义出来。而frps
一般部署在有公网IP的服务器上,用于接收外部连接并转发到内部服务。这里有几个安全事项需要关注:
很多分享的方案里基本不启用TLS,也对暴露的端口没有进一步的限制,这其实是不安全的。秉承这些目标,我们开始行动吧。
这里我直接使用docker-compose部署,并使用snowdreamtech/frpc
镜像。
|
|
这里需要的TLS证书一会我们再生成。这里的.env
文件内容如下:
|
|
为了方便修改和对齐,我们将frpc.toml
文件中的一部分配置放在.env
文件中定义。而frpc.toml文件内容如下:
|
|
我们的服务端一般是部署在一台有公网IP的服务器上,用于我们从任何地方通过它连接回家里内网。这个服务器可以从国内国外各种云上买一台或者找机会白嫖一台。我是在腾讯云上有一台机器,安装好docker以及docker-compose后,使用snowdreamtech/frps
镜像部署。部署在公网的服务,基于安全性考虑,我们希望即使frps被攻击,其它服务也是安全的,所以除了放在容器中,把网络也隔离出来。这里便不再使用network_mode: host
,而是使用默认的network_mode: bridge
,同时预留一些端口用于后续我们的服务暴露。
|
|
同样的,为了配置修改方便,我们将frps.toml
文件中的一部分配置放在.env
文件中定义:
|
|
而frps.toml文件内容如下:
|
|
为了让FRP的连接更安全,我们使用TLS证书来加密连接。它确保我们的frpc和frps之间的连接是安全的,并且防止中间人攻击。我们使用自签名证书来生成TLS证书。以下提供了一段脚本,方便一键生成我们需要的证书。
|
|
使用方式:
|
|
这样我们的服务器与客户端双向认证,谁都不可被冒充。
到这里,你的FRP连接已经通过TLS和双向认证得到了很好的保护,即使token
不慎泄露,没有匹配的证书也无法建立连接。接下来,我们在此基础上更进一步,结合云主机的防火墙(安全组)策略,实现更精细的访问控制。我们希望达成:
相信很多人都明白这个道理,但手动操作实在繁琐,所以我们需要一个工具来帮忙。在我看来,最便捷的莫过于再次祭出alfred workflow
来实现。于是我抽空写了一个,并开源在github上,感兴趣的可以看这里:alfred-workflow-sg-manager。
我们基于frpc.toml
中的一部分配置[[proxies]]
,来动态开启与关闭相关的端口。一点点前置工作还需要你做的,便是将你的服务器绑定一个安全组,至于安全组后续规则添加维护等就交给这个工具了。
比如先查看一下当前列表:
你上面可以看到这些内网服务还未开放,我们选择一个,比如想从外部访问家里的Mac mini了,我们在alfred框中输入
frp open
可以看到可开放的列表:
选中Mac mini,然后回车,这个通路便打开了。再次查看可以看到它开放并且绑定了本机的出口IP:
现在你可以开心的从外部VNC到你家内网的Mac mini了,并且安全得多了。
用过之后想关闭的一些端口,比如Mac mini的VNC端口,我们输入frp close
,然后选择对应的要关闭的服务回车即可:
现在咱是不是对于FRP的安全使用更有信心了。有些人可能会说:何苦呢,有谁会看中咱攻击咱呢?或许可能Maybe:我们就是控制欲作祟而已:)
还有两个小窍门我也想让你知道,看在这么认真的份上小手点点赞不过份吧!
第一:如上面截图出现了external-http,我们可以借助于将内网服务统一在一个ingress服务(反向代理)下,然后通过这个ingress服务进一步路由,这样我们只需要穿透一个端口即可访问内网的各种服务,免去了配置FRP的手续。也通过让ingress服务走TLS,或者后端服务对接OAuth2等更安全的认证方式,可以进一步保护我们的内网服务。
第二:FRPS除了默认有Dashboard外,还支持Prometheus。我们可以复用这种生态。Prometheus用于收集监控数据,Grafana用于可视化数据和配置告警。比如我们可监控FRP的连接访问情况,并且添加告警,这样某个敏感服务有连接,我们便可以及时收到通知。
本文整体到这里就结束了。我们尝试用docker来部署了FRP的客户端和服务端,并且基于安全的考虑,我们启用了TLS和创建了一个便捷的工具来快速修改云上的安全策略。这犹如一块坚固的盾牌,避免我们可能受到的攻击。
当我折腾好FRP,并且安全地将它保护起来后。有一天,我查看我家的外网IP,发现它居然是一个公网IP。我的天啦,我这折腾一番可是为了啥!我要不要重新回归到公网IP的路线呢?可是我却放不下这份安全了呢。
注:题图来自于互联网,我觉得画得挺棒,若有侵权请联系我删除。
我是个爱折腾技术的工程师,也乐于分享。欢迎点赞、关注、分享,更欢迎一起探讨技术问题,共同学习,共同进步。为了获得更及时的文章推送,欢迎关注我的公众号:爱折腾的风
2025-05-04 08:00:00
前阵子B站刷到小智AI机器人,入手了一个玩玩,官方的服务器显然不足以满足我的幻想,于是搭建了第三方服务器,顺便给它功能扩展了一下,到底做了点啥呢,似乎有一点意思了。
这个机器人似乎前阵子比较火,有不少硬件形态,有比较小巧可爱的,也有硬核直接的,但内核是不变的,如果你从来没玩过,好像长什么样,可以B站看看或淘宝啥的搜索一下。我家的比较抽象,长得像这样:
跟着电路图或者引脚说明接线,这步不是有手就行,还得有力气:)因为ESP32的针脚和面包板孔不完全匹配,需要用力强行按进去。看过B站有个哥们用锤子敲,也真是乐坏我了。供电的话我们可以随便拿个充电宝,倒也是很容易搞定、也有一定移动性。
最开始体验时,参考官方的DIY教程将设备刷好官方固件后,整体响应较快,对话流畅,不过模型数量有限,声音复刻收费,特别是如果这个不能联网做点啥,光和模型过时的数据聊天略有点无聊啊。结合当前较火的MCP功能,于是有了两个扩展目标:
消耗了一点闲暇时间,目前已经跑起来咯,下面简要分享一下过程。如果你也想折腾或者有好点子,欢迎一起交流。
小智官方并没有把服务器开源,但提供了交互协议等,有第三方开源服务器实现 xiaozhi-esp32-server,可供使用。要完成可以使用第三方服务器,我们做两件事:
其实都很简单,我们需要动脑的机会不多,像我这样一步步来即可。
参考xiaozhi-esp32-server的Docker运行全模块教程。我推荐使用docker部署,主要是为了保持本地的干净。
准备配置文件.config.yaml
,在这个服务器中,使用了多层config来互相覆盖,我们定义的.config.yaml会覆盖默认的config.yaml。
|
|
这里的配置不用太多,因为它的配置还有一层可以动态通过manager-api来下发更新,所以这里我们只需要配置一个manager-api的地址和secret即可。
然后我们使用docker-compose部署,在此之前你需要自行下载语音识别模型文件到models/SenseVoiceSmall/model.pt
,这些细节上面链接都有提,不啰嗦了,最终yaml如下:
|
|
使用命令启动:
|
|
等服务起来了之后,我们可以使用仓库自带的test
页面测试,浏览器打开main/xiaozhi-server/test/test_page.html
,可以看到如下页面:
你最好是在这个网页测试通过,聊天、语音等都符合你的预期,再进行下一步。话说这个页面也是调试利器了,效率高不少。
这里还有个小技巧,因为我们接下来需要将ota/websocket地址烧录在固件上,如果你不确定服务未来会部署在哪台机器上,可以通过一个反向代理来转发。给个示意了解一下即可:
|
|
上面我将api-xiaozhi
和web-xiaozhi
都指向了我的本地IP,这样我就可以通过api-xiaozhi.mrlin.cc
和web-xiaozhi.mrlin.cc
来访问了,未来迁移到其他机器上,只需要修改这个yaml文件即可。你不搞这一步一点问题也没有,继续用IP,注意那样就使用http/ws协议。
这里我们要进入到官方固件仓库来继续我们的操作。并且编译烧录等需要你在Windows下进行了。 我们可以参考这篇文章Windows搭建 ESP IDF 5.3.3开发环境以及编译小智大概了解整个过程;接着看这里简要而关键的固件构建过程。
简单来说,当前最新版本我们仅需要修改OTA_URL
地址即可,以往要修改websocket
地址,现在它已经通过OTA下发了。
当天我正在照着教程编译,发现不找到websocket的定义了,定睛一看刚好有提交重构了这一块,于是顺便向server那边也提了个PR,居然很快就被合并了。不过当时字段名取得不太好,我延用了固件那边的
websocket_url
,后面又被修改为server.websocket
,这确实更符合项目的命名规范一些。
之后构建就几个命令:
|
|
之后是烧录,将你的小智AI设备通过串口连接到电脑,然后使用idf.py build
构建,接着使用idf.py -p PORT flash
烧录。
这里的PORT根据你连接的设备不同,可能有所不同,在电脑中我的设备
查看串口,我的是COM4
。如果嫌烧录慢,可以添加参数-b 2000000
来加速。
一切成功后,同时也在上一步骤的服务器的server.websocket
中填入wss://api-xiaozhi.mrlin.cc/xiaozhi/v1/
,然后就可以打开设备连接自己的服务器开玩了。
现在你可能发现有了更多的LLM选择,有了更多的TTS(声音)等,似乎是更开放了,或许可以玩得更嗨了。
之前在玩火山引擎时,送了几次声音复刻给我,体验了一下,当我想用在小智上时,发现已经过期了,居然只有十天有效期,这也太抠了。我去腾讯云找了一下,也有免费的额度,申请下来有3个月,那么就玩玩吧。不像火山引擎的声音复刻在网页上提交声音即可,腾讯云的复刻要原始得多,需要自己使用API,所幸相关功能也在它的tccli
中,那么也就是敲命令的事,也不可能难倒我们。
我们可以参考文档声音复刻相关接口,使用命令行来把过程体验一下。至于如何安装tccli
,可以参考腾讯云命令行工具。
|
|
这一步要我们根据提供的文本来提供一段音频,我盲猜是不是要规避用别人的声音来复刻呢?
|
|
这一步看名称感觉多余,但是下一步创建任务需要这个AudioId
,所以还是得来一下。
|
|
我们得到了一个任务ID。原因或许是这一步是异步的,服务器训练这个声音也需要时间。
|
|
查到的结果里有几个比较关键的,VoiceType
、FastVoiceType
,前者是音色ID,后者是快速复刻时使用的音色ID,请用小本本记录下来备用。
|
|
这一步可能真没啥用了,我们要的信息前面也有了,说有用的话,你大概知道这是一个男人名叫kevin的声音。
|
|
返回的内容包括base64后的音频数据,我们使用jq
来提取并保存到文件:
|
|
播放来听听吧,感受一下自己声音的魔力或者惊吓。
当我使用复刻声音时,发现小智server并不支持,于是我给它添加了支持,并提交了PRfeat: 支持腾讯TTS声音一句话复刻后的合成,这次没有很快被合并,因为官方说某个字段要废弃了,又没说最新用什么方式,明儿就就腾讯云提工单。
如PR的修改所见,仅是增加了上述fast_voice_type
参数的传递即可。不管上游合不合修改,反正我本地已经用上了。有个小发现,这里server中处理不同语音合成模型的参数,UI是基于fields
的字段及其定义动态生成展示的,这还不错。顺手update一个DB,对应的UI就有新字段出来了。
|
|
不知道当你发现你自己在和自己说话时是什么感受,反正我挺惊奇的,感觉自己像个神经病。明儿我还是复刻一个我孩子的声音吧,我就可以随时亲子教育了:D
在这个第三方服务器的实现中,它支持了一部分MCP的能力,也即stdio
模式的mcp server。这会因为使用容器的模式,限制了它的使用。容器内可没有npx/uvx啥的,更没有chrome了。我就一个小小愿望,问它谁是最美丽的人,不对,问它昨天曼联输了个几比几,它不能实时联网找到正确答案我就不满意了。
同样的,让我们扩展它,只需要几行代码的修改就可以啦,详见PRfeat: MCP server支持使用sse模式。一般来说宿主机上使用npx/uvx/chrome等,容器内我们通过http协议使用mcp-server
还是更简单的。可是有一些mcp server人家就没实现sse咋办?一点都不困难,比如我们借助supergateway
就可以让几个模式互转。
Supergateway runs MCP stdio-based servers over SSE (Server-Sent Events) or WebSockets (WS) with one command. This is useful for remote access, debugging, or connecting to clients when your MCP server only supports stdio.
比如我有这样一个perplexity-ask
的mcp server,它只支持stdio模式,那么我就可以使用supergateway来让它支持sse模式:
|
|
使用supergateway来启动:
|
|
于是我们给小智server的mcp config就可以这么简单了:
|
|
现在你的小智就可以更好的使用MCP server了,我试着问了一下,它说曼联最近欧联13场不败!
|
|
像上面这样,它需要依赖机器安装相关的服务,换一台机器就歇菜了,并且为了转换为sse还是比较麻烦。前阵子在试用阿里云百炼平台时,发现有个有意思的扩展,对于它不支持的mcp server,可以通过云函数来自定义扩展它。我想何不借助于它来包装一下mcp server,这样就可以在任何地方使用它了。
我们可以打开https://cap.console.aliyun.com/explore?lang=MCP+Server,这里以高德地图为例,我们只要在云端部署它之后。
本地只需要一个url(填上面公网访问地址)即可使用这个mcp server了,它自动提供了sse接口。至此,你居然就将mcp server “上云”了:)审计和日志也一应俱全呢。现在你可以试一下再和小智聊天,对于地图信息,它比我们还清楚了。小声的说,地图API都提供了天气查询能力,咱也不用再找一个天气服务了呢。
这个机器人应该还有不少待开发的东西,无论软件还是硬件上。比如如果能再添加几个外设,预期会更有意思了。它本身也支持如Home Assistant等智能家居平台,可以实现如开关灯、开关窗帘等操作。 技术上也有不少地方可以进一步聊聊,比如MCP的使用姿势问题等,以及如何进一步提升对话的响应速度等。 记录一张图留念,本想放视频的,第一不好录制,第二声音这东西,你懂的。
考虑到篇幅问题,今天就到这里吧。如果你对某些地方感兴趣,欢迎留言讨论。如果你没什么想说的,点赞、分享、关注,都是对我最好的鼓励。我努力创作有价值的内容,期待未来与你再会。
我是个爱折腾技术的工程师,也乐于分享。欢迎点赞、关注、分享,更欢迎一起探讨技术问题,共同学习,共同进步。为了获得更及时的文章推送,欢迎关注我的公众号:
2025-04-24 08:00:00
在ChatGPT出现后,聊天相关的开源工具多如牛毛,但是一直以来没找到一个能集成多平台绘图能力的开源项目。有时为了给博客文章配一个图,辗转于多个平台,这也太难受了。于是闲暇时间我在lovable.dev
平台上搭建了一个集成式网页。
今天恰逢强大到令人瞠目的gpt-image-1
模型发布,我想是时候把这个小小项目给介绍一下,方便大家填上API就可以直接使用。使用它你不需要安装任何软件,即用即走,我保证。但你不妨点个赞再走,我感谢:)
这个叫PaintBot Hub的项目,旨在提供一个统一的操作界面,集成多个AI绘画平台的API,让你的创意更加触手可及。当前算是个小Demo,但未来会持续添加更多平台,并增加图片编辑、图生图、提示词辅助等功能。
我们看一下它长得什么样:
还是挺简洁的是不?当前支持的AI平台:
你可以直接使用在线版本,只需要配置自己的API密钥(安全存储在本地浏览器中),即可立即开始创作。
访问链接:https://paintbot-hub.lovable.app/。
为了解决使用者的后顾之忧,所有的交互都在你本地浏览器完成的,数据不会上传到任何地方。当然你的文生图提供商可能是知道的:) 你需要填上自己使用对应平台的API密钥等信息,这只能你自己去申请了。抱歉,这个我帮不了你呢:)
好消息是智谱AI CogView3模型生图还免费呢,不妨一试,更好一点的模型就要收钱啦。作为用户,每张图大概多少钱,UI中都给你标注了,作为参考咯。我可是太贴心了,会不会是我成本意识太强,说人话(太抠了哇)。
或许访问上面链接还不够快,又或者你更喜欢折腾可控,项目提供了私有化部署方案。私有化部署版本也提供了额外的好处:
你只需要在本地安装Docker,然后执行以下命令:
|
|
接着打开浏览器访问 http://localhost:8080
即可。
你可以本地编辑一个这样的文件,或者直接打开Github代码仓库中的docker-compose.yml文件并复制过来。
|
|
然后执行命令docker-compose up -d
,接着打开浏览器访问 http://localhost:8080
即可。
更多的使用以及未来可能的更新,可以参考Github项目。
PaintBot Hub是一个开源项目,欢迎大家参与共建,让这个工具变得更加强大和完善。如果你有好用的类似工具,不妨推荐给我,感谢啦~
这个项目最开始是基于lovable.dev平台创建和开发的,不过随着功能变多,似乎lovable不容易驾驭,我都生气了,仿佛会员白充了,那些吹这个平台有多厉害的人,你们到底有没有深度用过啊(假装发怒)。最后更多的功能还是在Cursor指导下开发完成。但不得不说平台提供免费的托管和一键的发布,这还是很方便的。上面公开的网站就是平台托管的,我没有额外成本付出。
最后,因为个人时间和精力有限,这个项目当前只支持了三四个平台,未来希望能将主流平台都集成进来。
GitHub项目源码,千万别给我Star哦。啊哈~~~
我是个爱折腾技术的工程师,也乐于分享。欢迎点赞、关注、分享,更欢迎一起探讨技术问题,共同学习,共同进步。为了获得更及时的文章推送,欢迎关注我的公众号:
2025-04-02 08:00:00
虽然大模型支持的上下文是越来越大,但不论出于知识库过大还是基于安全考虑,我们还是希望向模型提供适当的上下文即可。这其中选择合适的embedding模型就至关重要了。如何才能找到效果更好的embedding型呢,希望本文能提供一些参考。
我们不能为技术而技术,最好是解决某项具体问题而进行探索。我为何想去了解embedding这块呢?缘于最近MCP比较火,而我工作中经常需要分析一些仓库的提交历史,以发现某些内容的引入或修改历史,即我想和git历史进行交谈。虽然有时咱传统方式也能做,但写个MCP可以用自然语言获得诸如:
这一些问题的答案那自然是极好的。这些信息或许可基于git log
等进一步检索,而我们一个大项目是由几十个小仓组成的,难度就上升了一层。不过完整的解决方案已经开发得差不多了,今天就先聊一下如何解决第一个挑战,embedding!我计划了一场PK赛,看看哪个模型更适合我的场景。
先叠一层甲,我本人非AI领域人员,基于爱好和专用场景测试,受于个人知识限制,可能存在理解偏差,欢迎指正。
什么是embedding呢?wikipedia的描述比较抽象,以下是腾讯混元T1的解释:
Embedding模型是一种将高维数据(如文本、图像)映射到低维向量空间的技术,通过保留原始数据的语义和特征信息,实现高效计算与相似性分析。其核心原理是通过神经网络训练,将相似的数据点映射到向量空间中的相近位置,例如"猫"和"狗"的向量比"猫"和"苹果"的更接近,从而捕捉语义关联。
在huggingface上有一个排行榜,可以查看不同模型的效果。用于了解有哪些模型还不错,但我们具体使用上还是实测可能更靠谱。
我计划选择免费开源的一些模型,同时也测试一些闭源模型看其提升有多大,是否值得咱付费使用。而这个测试场景,大概有如下几步:
实测上有一些意想不到的结果呢,让我们拭目以待。
在网上查看了一些资料后,我选择了如下几个被推荐较多的模型用于后续测试。
模型名称 | 描述 | 维度 | 最大token | 支持语言 |
---|---|---|---|---|
text-embedding-gte-large-zh | GTE大型中文嵌入模型(本地) | 1024 | 512 | 中文 |
text-embedding-bge-large-zh-v1.5 | 百度开源的中英双语大型嵌入模型(本地) | 1024 | 512 | 中文、英文 |
text-embedding-m3e-base | M3E基础嵌入模型(本地) | 768 | 512 | 中文、英文 |
text-embedding-granite-embedding-278m-multilingual | Granite多语言嵌入模型(本地) | 768 | 512 | 多语言(英文、德文、西班牙文、法文、日文、葡萄牙文、阿拉伯文、捷克文、意大利文、韩文、荷兰文、中文等) |
text-embedding-multilingual-e5-large-instruct | E5大型多语言嵌入模型 | 1024 | 512 | 多语言 |
原本jina-embeddings
系列模型也想一并参赛的,无奈在LM Studio中支持得不太好,可能缘分未到,暂时跳过。若有朋友有使用经验,不妨留言分享一下实际效果。
以OpenAI为首的如text-embedding-3
系列,以及国内各个大厂BAT以及字节等都有自己的embedding模型都获得了参赛资格。这取决于我之前在OneAPI提到过收集的模型提供商了,只要他们有embedding模型,都跃跃欲试进组PK。
模型名称 | 描述 | 维度 | 最大词元数 | 支持语言 |
---|---|---|---|---|
text-embedding-3-large | OpenAI第三代大型嵌入模型 | 3072 | 8191 | 多语言 |
hunyuan-embedding | 腾讯混元嵌入模型 | 1024 | 1024 | 中文、英文 |
doubao-embedding-large-text-240915 | 豆包嵌入模型 | 1024 | 4096 | 中文、英文 |
Baichuan-Text-Embedding | 百川嵌入模型 | 1024 | 512 | 中文、英文 |
text-embedding-v3 | 通义千问嵌入模型 | 1024 | 8192 | 中文、英文 |
Embedding-V1 | 百度嵌入模型 | 1024 | 384 | 中文、英文 |
可以发现:收费的模型虽然咱还没有开赛,但肉眼一看,三围(维度、最大token、支持语言)上已经领先了:)果然没点特色,还真不敢收费。额,那个百度,百川你们咋回事?
为了公平公正,本次PK全过程已经记录在Github仓库: https://github.com/kevin1sMe/embedding-selector,欢迎大家围观。
先公布考题吧,我让AI生成了如下的测试数据以及Query的问题:
|
|
开源赛区的模型,我是使用的本地LM Studio部署的,已经尽量选择了当前(2025-3-29)最新版本。
本次参赛的5大选手,我们就叫他们F5吧,比赛开始!
|
|
虽然是本地部署,就这点计算量,分秒就拿捏了,我们看一下他们的成绩:
模型 | 处理时间(秒) | 数据量 |
---|---|---|
text-embedding-m3e-base | 0.7 | 40 |
text-embedding-bge-large-zh-v1.5 | 1.18 | 40 |
text-embedding-gte-large-zh | 1.12 | 40 |
text-embedding-granite-embedding-278m-multilingual | 0.68 | 40 |
text-embedding-multilingual-e5-large-instruct | 1.23 | 40 |
我们查看open-source-f5.json
的输出:
|
|
内容很多,眼花缭乱,我们先让AI来评测打分,选择了当前号称地表最强的Google新模型Gemini-2.5-Pro experimental 03-25
来打分,看看效果如何?"
模型检索结果对比表
注: 限于篇幅只截取一部分,完整内容查看代码仓库。
查询语句 | text-embedding-m3e-base | text-embedding-bge-large-zh-v1.5 | text-embedding-gte-large-zh | text-embedding-granite-embedding-278m-multilingual | text-embedding-multilingual-e5-large-instruct |
---|---|---|---|---|---|
如何修复bug | 1. fix: 修复了登录页面的bug (0.837)2. 修复了用户反馈的崩溃问题 (0.833)3. 根据Code Review反馈修改代码 (0.825)4. 修复了多线程并发导致的数据不一致问题 (0.807)5. 修复QA团队报告的regression问题 (0.791) | 1. 修复了用户反馈的崩溃问题 (0.599)2. fix: 修复了登录页面的bug (0.581)3. 修复了多线程并发导致的数据不一致问题 (0.576)4. 根据Code Review反馈修改代码 (0.541)5. 修复Redis连接池泄露问题 (0.532) | 1. fix: 修复了登录页面的bug (0.623)2. 修复了用户反馈的崩溃问题 (0.608)3. 修复首页加载速度慢的问题 (0.592)4. 修复Redis连接池泄露问题 (0.555)5. 协同后端API调整相应的前端代码 (0.527) | 1. fix: 修复了登录页面的bug (0.770)2. 修复了用户反馈的崩溃问题 (0.724)3. 修复Redis连接池泄露问题 (0.688)4. 修复首页加载速度慢的问题 (0.687)5. 修复QA团队报告的regression问题 (0.682) | 1. 修复QA团队报告的regression问题 (0.918)2. 修复了用户反馈的崩溃问题 (0.916)3. fix: 修复了登录页面的bug (0.914)4. 根据Code Review反馈修改代码 (0.907)5. 重构了代码结构,提高了可维护性 (0.895) |
添加新功能 | 1. 新增数据导出功能 (0.859)2. 添加了新功能的feature flag (0.845)3. feat: 添加了新的payment接口 (0.822)4. 新增Elasticsearch索引管理功能 (0.815)5. 更新了Webpack配置,提高构建速度 (0.812) | 1. 新增数据导出功能 (0.710)2. 添加了新功能的feature flag (0.653)3. feat: 添加了新的payment接口 (0.637)4. 实现了产品经理提出的新需求 (0.631)5. 优化用户登录流程 (0.625) | 1. 新增数据导出功能 (0.627)2. 添加了新功能的feature flag (0.602)3. 实现了产品经理提出的新需求 (0.548)4. feat: 添加了新的payment接口 (0.524)5. 根据UI设计稿更新组件样式 (0.511) | 1. 添加了新功能的feature flag (0.875)2. 新增数据导出功能 (0.804)3. feat: 添加了新的payment接口 (0.792)4. 新增Elasticsearch索引管理功能 (0.702)5. 实现了产品经理提出的新需求 (0.687) | 1. 添加了新功能的feature flag (0.954)2. 新增数据导出功能 (0.944)3. 实现了产品经理提出的新需求 (0.933)4. 更新文档说明 (0.931)5. 合并develop分支的最新更改 (0.924) |
更新文档 | 1. 更新文档说明 (0.957)2. docs: 更新API文档 (0.888)3. chore: 更新了package依赖 (0.791)4. 更新了Webpack配置,提高构建速度 (0.785)5. 合并develop分支的最新更改 (0.774) | 1. 更新文档说明 (0.857)2. docs: 更新API文档 (0.772)3. 新增数据导出功能 (0.580)4. 根据UI设计稿更新组件样式 (0.577)5. 修改了配置文件中的默认设置 (0.558) | 1. 更新文档说明 (0.871)2. docs: 更新API文档 (0.791)3. 合并develop分支的最新更改 (0.586)4. 新增数据导出功能 (0.582)5. 添加了新功能的feature flag (0.541) | 1. 更新文档说明 (0.930)2. docs: 更新API文档 (0.804)3. chore: 更新了package依赖 (0.691)4. 合并develop分支的最新更改 (0.667)5. 准备v2.0.0版本发布 (0.653) | 1. 更新文档说明 (0.980)2. docs: 更新API文档 (0.953)3. 新增数据导出功能 (0.920)4. 准备v2.0.0版本发布 (0.919)5. 合并develop分支的最新更改 (0.914) |
优化性能 | 1. 优化React组件的渲染性能 (0.841)2. perf: 优化了数据库查询性能 (0.817)3. 修改了配置文件中的默认设置 (0.800)4. 解决了Docker容器内存占用过高的问题 (0.798)5. 修复首页加载速度慢的问题 (0.794) | 1. 优化React组件的渲染性能 (0.632)2. perf: 优化了数据库查询性能 (0.595)3. 优化用户登录流程 (0.586)4. 重构了代码结构,提高了可维护性 (0.564)5. 修复了多线程并发导致的数据不一致问题 (0.554) | 1. 优化React组件的渲染性能 (0.645)2. perf: 优化了数据库查询性能 (0.611)3. 更新了Webpack配置,提高构建速度 (0.581)4. 修复了用户反馈的崩溃问题 (0.572)5. 解决了在iOS设备上的兼容性问题 (0.567) | 1. perf: 优化了数据库查询性能 (0.726)2. 优化React组件的渲染性能 (0.719)3. 优化用户登录流程 (0.684)4. 修复首页加载速度慢的问题 (0.644)5. 更新文档说明 (0.631) | 1. perf: 优化了数据库查询性能 (0.931)2. 优化React组件的渲染性能 (0.925)3. 优化用户登录流程 (0.913)4. 修复首页加载速度慢的问题 (0.907)5. 优化了MongoDB聚合查询的执行效率 (0.905) |
评估和分析
从上面的表格中,我们可以看到不同模型在不同查询语句下的表现。总体来看:
text-embedding-multilingual-e5-large-instruct
,可能意味着它在语义理解的深度上稍逊一筹。判断依据
结论
综合以上分析, text-embedding-multilingual-e5-large-instruct 模型最适合我们的commit message检索任务。它的分数更高,结果相关性也更高,表明它能够更好地理解查询意图,并返回更准确、更有用的结果。 在检索的准确性,覆盖范围和稳定性上都更好,能够胜任commit message检索这类任务。 虽然其他模型在某些特定查询下可能表现良好,但整体来看,text-embedding-multilingual-e5-large-instruct
在所有查询类型下都更加稳定和可靠。
我们再看一下上面各模型的大小,text-embedding-multilingual-e5-large
明显比其它都大一些,或为其中原因,当然也可能大只是因为支持多语言。不过在这个模型参赛前,其它4个模型偷偷比武了一番,结果text-embedding-m3e-base
这个尺寸最小的模型夺魁,这么说来,也并不是“底大一级压死人”啊:)
我们照葫芦画瓢的测试方式,这次将这些付费模型拉出来遛遛。我们先让国内各家来个PK,再看看和国外差距是否明显。国内“获得”测试资格的模型之前已经提过,我们直接看成绩(限于篇幅只截取一部分,完整内容查看代码仓库):
查询语句 | hunyuan | baidu | qwen | doubao | baichuan |
---|---|---|---|---|---|
如何修复bug | 1. 修复了用户反馈的崩溃问题2. 修复首页加载速度慢的问题3. fix: 修复了登录页面的bug4. 修复了多线程并发导致的数据不一致问题5. 修复Redis连接池泄露问题 | 1. fix: 修复了登录页面的bug2. 修复了用户反馈的崩溃问题3. 修复了多线程并发导致的数据不一致问题4. 修复首页加载速度慢的问题5. 修复Redis连接池泄露问题 | 1. 修复了用户反馈的崩溃问题2. fix: 修复了登录页面的bug3. 修复Redis连接池泄露问题4. 修复QA团队报告的regression问题5. 根据Code Review反馈修改代码 | 1. 修复QA团队报告的regression问题2. fix: 修复了登录页面的bug3. 修复了用户反馈的崩溃问题4. 根据Code Review反馈修改代码5. 修复了多线程并发导致的数据不一致问题 | 1. 修复了用户反馈的崩溃问题2. fix: 修复了登录页面的bug3. 修复了多线程并发导致的数据不一致问题4. 修复首页加载速度慢的问题5. 根据Code Review反馈修改代码 |
添加新功能 | 1. 新增数据导出功能2. 实现了产品经理提出的新需求3. 添加了新功能的feature flag4. feat: 添加了新的payment接口5. chore: 更新了package依赖 | 1. 新增数据导出功能2. 添加了新功能的feature flag3. 新增Elasticsearch索引管理功能4. 更新文档说明5. 实现了产品经理提出的新需求 | 1. 添加了新功能的feature flag2. 新增数据导出功能3. feat(api): 新增用户数据同步endpoint4. 更新文档说明5. 实现了产品经理提出的新需求 | 1. 更新文档说明2. 添加了新功能的feature flag3. 优化用户登录流程4. 删除了废弃的API调用5. 重构了代码结构,提高了可维护性 | 1. 新增数据导出功能2. 添加了新功能的feature flag3. 优化用户登录流程4. 实现了产品经理提出的新需求5. feat: 添加了新的payment接口 |
更新文档 | 1. 更新文档说明2. docs: 更新API文档3. chore: 更新了package依赖4. 更新了Webpack配置,提高构建速度5. 根据Code Review反馈修改代码 | 1. 更新文档说明2. docs: 更新API文档3. 根据UI设计稿更新组件样式4. chore: 更新了package依赖5. 新增数据导出功能 | 1. 更新文档说明2. docs: 更新API文档3. 新增数据导出功能4. chore: 更新了package依赖5. 根据UI设计稿更新组件样式 | 1. 更新文档说明2. docs: 更新API文档3. 删除了废弃的API调用4. 优化用户登录流程5. 重构了代码结构,提高了可维护性 | 1. 更新文档说明2. docs: 更新API文档3. 新增数据导出功能4. 根据UI设计稿更新组件样式5. 优化用户登录流程 |
优化性能 | 1. 修改了配置文件中的默认设置2. 修复了多线程并发导致的数据不一致问题3. 添加GraphQL查询缓存机制4. 更新了Webpack配置,提高构建速度5. perf: 优化了数据库查询性能 | 1. perf: 优化了数据库查询性能2. 优化React组件的渲染性能3. 优化用户登录流程4. 修复首页加载速度慢的问题5. 优化了MongoDB聚合查询的执行效率 | 1. 优化用户登录流程2. perf: 优化了数据库查询性能3. 优化React组件的渲染性能4. 修复首页加载速度慢的问题5. 重构了代码结构,提高了可维护性 | 1. 修复首页加载速度慢的问题2. 优化用户登录流程3. perf: 优化了数据库查询性能4. 修复了用户反馈的崩溃问题5. 删除了废弃的API调用 | 1. perf: 优化了数据库查询性能2. 优化用户登录流程3. 优化React组件的渲染性能4. 更新了Webpack配置,提高构建速度5. 优化了MongoDB聚合查询的执行效率 |
我们再请Gemini-2.5-pro来分析一下:
综合评判:
基于以上对所有查询的分析,各个模型的召回正确率表现如下:
最终结论: Baichuan 模型在召回上正确率最高,最适合这类任务。
判断依据与示例:
Baichuan 的优势 (示例):
perf: 优化了数据库查询性能
, 优化了MongoDB聚合查询...
, 添加GraphQL查询缓存机制
, 新增Elasticsearch索引管理功能
, 修复Redis连接池泄露问题
),覆盖了性能优化、缓存、索引、连接池等多个数据库相关方面。这显示了它对数据库领域术语和优化手段的深刻理解。优化React组件...
, style: 调整了UI组件...
, 根据UI设计稿...
, fix(ui): modal...
等高度相关的 commit,表现优于其他多数模型。不太合适的模型 (Doubao) 的劣势 (示例):
添加了新功能的feature flag
),其余 4 个是 更新文档说明
, 优化用户登录流程
, 删除了废弃的API调用
, 重构了代码结构...
,这些都与“添加新功能”的意图相去甚远。修复首页加载速度慢的问题
, 优化用户登录流程
, perf: 优化了数据库查询性能
这三个相关的,但也召回了 修复了用户反馈的崩溃问题
和 删除了废弃的API调用
,后者与性能优化关联不大,可能是因为看到了“修复”、“优化”等词就简单匹配了。因此,基于对所有查询结果的综合分析,Baichuan 模型在本次评测中展现了最高的召回正确率和最好的语义理解能力,是完成该任务的最佳选择。兼听则明?这个结果同时也让Deepseek-R1来分析了一下,都认证了Doubao在这轮里面垫底的事实(也可能注这个场景人家不行?),但第一名一个是Baichuan,一个是Baidu。
国外的embedding模型原本打算把除OpenAI外,Google家和Anthropic家请来的,无奈后两家模型要么主打模型不支持中文,要么我没API KEY(这是我的问题),都纷纷表示上不了场,于是咱就把OpenAI自家三姐妹一起端上来品评下。以下是它们的结果(限于篇幅只截取一部分,完整内容查看代码仓库):
查询语句 | text-embedding-3-small | text-embedding-3-large | text-embedding-ada-002 |
---|---|---|---|
如何修复bug | 1. 修复了登录页面的bug2. 修复了用户反馈的崩溃问题3. 根据Code Review反馈修改代码4. 修复QA团队报告的regression问题5. 修复首页加载速度慢的问题 | 1. 修复了登录页面的bug2. 修复了用户反馈的崩溃问题3. 修复QA团队报告的regression问题4. 修复了多线程并发导致的数据不一致问题5. 修复Redis连接池泄露问题 | 1. 修复了用户反馈的崩溃问题2. 修复QA团队报告的regression问题3. 修复了登录页面的bug4. 修复了多线程并发导致的数据不一致问题5. 修复首页加载速度慢的问题 |
添加新功能 | 1. 添加了新功能的feature flag2. feat: 添加了新的payment接口3. 合并develop分支的最新更改4. 新增数据导出功能5. 重构了代码结构,提高了可维护性 | 1. 添加了新功能的feature flag2. 新增数据导出功能3. feat: 添加了新的payment接口4. 新增Elasticsearch索引管理功能5. 添加单元测试用例 | 1. 添加了新功能的feature flag2. 新增数据导出功能3. 新增Elasticsearch索引管理功能4. 添加单元测试用例5. feat: 添加了新的payment接口 |
更新文档 | 1. 更新文档说明2. docs: 更新API文档3. 合并develop分支的最新更改4. chore: 更新了package依赖5. 根据UI设计稿更新组件样式 | 1. 更新文档说明2. docs: 更新API文档3. 新增数据导出功能4. chore: 更新了package依赖5. 准备v2.0.0版本发布 | 1. 更新文档说明2. docs: 更新API文档3. 修改了配置文件中的默认设置4. chore: 更新了package依赖5. 准备v2.0.0版本发布 |
优化性能 | 1. perf: 优化了数据库查询性能2. 优化React组件的渲染性能3. 优化了MongoDB聚合查询的执行效率4. 重构了代码结构,提高了可维护性5. 优化用户登录流程 | 1. perf: 优化了数据库查询性能2. 优化React组件的渲染性能3. 优化用户登录流程4. 优化了MongoDB聚合查询的执行效率5. 重构了代码结构,提高了可维护性 | 1. 优化React组件的渲染性能2. perf: 优化了数据库查询性能3. 优化了MongoDB聚合查询的执行效率4. 优化用户登录流程5. 重构了代码结构,提高了可维护性 |
综合评判:
text-embedding-3-large
: 表现最佳。它在大多数查询中都提供了最高度相关的结果,尤其是在需要理解具体技术动作(如 API 开发、React 组件相关、重构)的查询上表现突出。虽然在某些查询的填充结果上仍有不足,但其核心召回的相关性和准确性是三者中最高的。它似乎对 commit message 中的术语和隐含意图有更强的捕捉能力。text-embedding-3-small
: 表现良好,是强力的竞争者。在许多查询中,其表现非常接近 large
,有时甚至在 UI 调整等个别查询上略优。考虑到它是 “small” 模型,其性能令人印象深刻。它主要的弱点是在某些查询中会比 large
混入更多不相关或弱相关的结果。text-embedding-ada-002
: 表现相对最弱。虽然在一些直接的查询(如修复 bug、优化性能)上表现尚可,但在需要更细致区分和理解的查询中(如数据库优化、API 开发)明显落后于 large
和 small
,召回了更多不相关的结果。似乎更容易受到表面关键词的影响,而对深层语义的把握不如新一代的 text-embedding-3
系列。腾讯元宝网页版给了如下总结:
评估维度 | text-embedding-3-large | text-embedding-ada-002 | text-embedding-3-small |
---|---|---|---|
技术召回率 | 92% | 85% | 78% |
语义边界准确率 | 89% | 76% | 68% |
混合文本处理 | 94% | 83% | 72% |
过程任务召回 | 86% | 91% | 88% |
多个AI一致投票给了: text-embedding-3-large
模型。它在召回上正确率最高、最适合这类任务。
这其实和我预想的有点出入,本以为small便宜点可能只是维度小一些(1536 vs 3072),对这种场景没啥影响,但是却在多个召回上弱于large模型,或许维度高确实有用吧?不过这个场景原来旧的ada模型明显落后了,那些用旧模型的小伙伴要不要考虑升级一下呢?
那我们最后国内国外一起看一下当前的推荐(来源于Gemini2.5 pro): 推荐层级:
第一梯队:强烈推荐 (Overall Best Performance)
text-embedding-3-large
:
fix(ui)
)和细微语义差别方面表现最佳。其召回结果的相关性排序和准确性通常最高,混入的不相关结果最少。是追求最佳召回效果的首选。fix(ui)
细节。第二梯队:优秀选择 (Strong Contenders)
Baichuan
:
text-embedding-3-large
。尤其在理解数据库优化、UI/组件相关术语方面表现突出,显示出可能针对中文技术领域有良好的优化。对于侧重这些领域的场景,它可能是与 large
并驾齐驱的选择。text-embedding-3-small
:
large
的小型版本,其性能表现惊人地好,远超 ada-002
和第一批的大部分模型。在多数查询中紧随 large
和 Baichuan
,召回相关性高。考虑到其可能更优的成本效益和更快的速度,如果对极致性能要求稍低,或者成本是重要因素,small
是一个极具吸引力的选择。large
高度相似,性价比可能更高。第三梯队:可以考虑 (Good / Acceptable)
Baidu
:
第四梯队:谨慎使用 (Fair / Use with Caution)
Qwen
:
text-embedding-ada-002
:
text-embedding-3
系列显著超越。虽然在简单查询上还行,但在复杂或需要区分技术领域的查询(如数据库优化、API 开发)中表现较差,召回结果混杂。除非有特定原因(如兼容性),否则不建议优先选择。第五梯队:不推荐 (Not Recommended)
Hunyuan
:
Doubao
:
总结建议:
text-embedding-3-large
。text-embedding-3-small
是极佳的选择,性能接近顶尖且可能更经济。Baichuan
也值得重点考虑和测试,它在这些方面展现了特长。Baidu
是一个可以考虑的选项,但需注意其潜在的稳定性问题。Hunyuan
和 Doubao
用于此类需要较高语义理解准确性的任务。text-embedding-ada-002
也应被视为过时选项。这个场景对于Hunyuan和Doubao我也很抱歉,不是你不好,可能是我们不适合:P
因为测试数据较多,文章显得较长,对于如何找到适合的embedding模型这个问题,虽然可以看到一些模型的成色如何,但也可能有所偏颇,建议你根据自己的具体应用场景和数据上进行测试验证。你也看到我这个测试是针对这种特殊场景的,而你可能要考虑很多因素:
虽然Google今天没有参赛,江湖传闻它也有特别的能力,在Embedding时指定任务类别,可能可以更精准使用,详见: Google Embedding Task Types
最终我会选择哪一个呢?你猜。
我是个爱折腾技术的工程师,也乐于分享。欢迎点赞、关注、分享,更欢迎一起探讨技术问题,共同学习,共同进步。为了获得更及时的文章推送,欢迎关注我的公众号:
2025-03-16 08:00:00
突然MCP就很火了,这里闲聊一点使用经验(开发经验计划下一篇),面对变化,不变的是什么呢?同时借自己文章畅想一下未来,这或许是技术人的浪漫吧:)
大模型相关技术真是日新月异,还记得我在2个月前写了一篇关于Cursor的文章,当时还对比说Cline的MCP有不错的想象空间。于是稍作研究,年前积累了几篇相关文章因为家事忙都没空整理发出来,感觉再不理出来就过时了呢。但是我们有时并不应该简单看技术本身,而是应该思考技术背后的价值,比如它是什么生态位的?
自从有了function call
之后,给模型的能力赋予了更多的想象空间。但略遗憾的事这个功能并没有很快大红大紫,其原因可能有多种。比如要很好的支持function call,需要模型本身具备一定的能力,咱们很多很火的大模型都不能很好的支持(或者完全不支持),比如说deepseek(注:最新Google开源的Gemma3在很小模型下支持了function call,有空测试一下,成立的话咱能节省不少成本呢,请关注后续文章)。同时function call 的使用门槛挺高,每家公司标准也不一样,OpenAI和Google对于function call的定义就不一样,这导致相关功能可复用性不强。在这种情况下,Claude模型背后的公司Anthropic提出了一种大模型的通用交互标准协议,这就是MCP。
关于MCP已经有很多文章介绍了,我们关注最终能干点啥,这就是今天的主角mcp-server。每天都有不少mcp-server被开发出来,本文主要从使用者角度聊一下如何用好MCP的能力。之后或许会从开发角度聊聊mcp-server的实现原理以及如何开发一些实用的mcp相关工具(不止mcp-server)。
从最早Anthropic自己当家的Claude Desktop开始,目前已经有相当多使用MCP的应用了,比如:
不过多数是在代码编辑器中集成,看起来程序员对自动化、智能化的接受程度果然是更高的呀:) 各种APP对MCP协议支持程度不一,支持最好的当然要数Claude了。详情看这里:MCP Feature Support Matrix
因为国内网络问题,我不是很推荐使用Claude Desktop。
而Cursor最近0.46/0.47虽然疯狂修复MCP的支持bug,但到目前为止依然问题多多。如果你是在Cursor中编辑和调试mcp-server,你要准备好随时掉进坑里。
依托于VCode的Cline使用会简单方便得多,配置一个模型,然后就可以开始愉快地使用MCP了。特别是现在它有了Marketplace
,可以很方便的安装和使用各种mcp-server。从对于MCP支持的稳定性上来说,cline还是合格的,基本能按预期调起。比如以下是我用cline通过perplexity API
检索一些信息。
Windsurf在使用MCP的体验也很不错,后文有截图Windsurf的过程呈现(UI)更漂亮易懂。
但有时我们也不是想要写代码,只是用工具找点乐子,我发现一个更纯粹更小巧的工具mcphost
(https://github.com/mark3labs/mcphost)。
A CLI host application that enables Large Language Models (LLMs) to interact with external tools through the Model Context Protocol (MCP). Currently supports both Claude 3.5 Sonnet and Ollama models.
关于mcphost,最开始使用它是为了调试mcp-server,后来发现它其实是一个很纯粹的MCP客户端,可以很方便的调用各种mcp-server。它的功能简单描述:
我们可以一个命令搞定mcphost安装(前提是已经安装了go):
|
|
之后我们配置一个简单的mcp-server来玩一下,创建一个mcp.json文件,内容如下:
|
|
这个mcp-server是基于uvx来运行服务的,所以你若本地没安装最好提前安装一下。
uvx 是一个轻量级的工具,主要用于在临时环境中运行 Python 工具和脚本。通过其即用即走的特性和临时虚拟环境的使用,解决了环境管理的复杂性和工具版本管理的问题,特别适合快速试用工具或在 CI/CD 环境中执行临时任务。
然后运行mcphost:
|
|
成功加载完mcp-server后,就进入了交互模式:
|
|
本来没有啥时间概念的大模型,现在很清楚的掌握了当前时间。接下来我多问了一嘴:
|
|
工具不够用了,是时候进入下一个环节。
PS: 当然你可以使用/help查看到mcphost支持的一些命令如tools/servers等,试用一下呗。
如上面展示,我想知道农历怎么办,可能有某个mcp-server能回答这个问题,不过我相信只要大模型能联网,它或许也能回答。我们继续在上面mcp.json中添加一个mcp-server,我们选择了tavily,一个搜索引擎。需要申请一个tavily的API key
|
|
接下来再问一次:
|
|
它居然把出处也写上了呢,还真是有效的一个链接,有联网后幻觉的病也好多了。
如果你像我一样平常已经习惯使用Perplexity来搜索信息,那么我们也可以使用Perplexity的MCP-Server来随便调起搜索。只是它这个API是使用Sonar API在线搜索的,或许和官网可用的几种模式略有区别,比如深度研究等估计是没有了,期待未来更完善,当前也能满足日常使用。同样的,我们要注册一个API KEY,但木有免费额度,所以可能要借助信用卡或Google pay等注册充值后才可以调用。这个mcp-server的安装稍麻烦一些,没有上传到官方仓库等,我们可能要手动编译构建一下。
|
|
之后会在对应dist目录下会有一个index.js
文件,我们就可以修改mcp.json让node运行它。
|
|
使用呈现:
|
|
我也不知道对不对,但看起来就很厉害。还有一些搜索工具也很推荐:
Brave Search
,你可以很方便使用它(比上面这个容易用得多)。Firecrawl
,你可以在这里查看firecrawl-mcp-server,它支持深度研究等搜索。据说网页抓取成功率非常高。免费注册有一些次数可使用。当然这些都需要一个Key,看自己喜好去注册吧,成人也可以不做选择。
过往我们除了手动一个个文件去找东西外,也就能用命令行或一些字符串匹配的方式来找东西。有了这个mcp-server可以让我们很方便智能的和文件系统互动了。同样的添加一个配置就可以玩了:
|
|
比如我们可以这样聊
|
|
呃,一不小心暴露了我月更党的倾向。
Smithery.ai是一个mcp server平台,面向新手使用友好,我们可以用来它配置mcp-server。它还提供了交互式让你填写必要的配置。比如我们看这里: https://smithery.ai/server/obsidian-mcp,在右边可以基于自己的应用选择相应的安装方式。
比如我选择了Windsurf,拷贝命令在本地执行后:
|
|
然后就可以直接在Windsurf中使用它了。我们不妨看一眼配置:
|
|
我们随便问点东西,可以和你的Obsidian知识库互动了。
之后就可以和AI聊聊你的个人知识库了,更多的细节实践未来有空再分享。关于Obsidian结合大模型的使用,最近正考虑另写一篇。
在真实使用上,不论是支持MCP的应用,还是mcp-server本身成熟度,都还有一段路要走。比如:现在似乎正在野蛮生长期,
但是这些不是我们否定MCP的理由,相反,我更愿意相信MCP会是一个趋势,就像他们所描述的,期待它能成为一个类似USB一样的标准,连接、连接、连接。
我们不妨想象一下,未来为了抢夺用户,各个AI应用如元宝、豆包等,它们或许也会支持MCP,让用户可以将智能应用于更多场景。不过大厂也不可能将各种功能都实现,所以还是会调用其它平台能力吧?如何整合到一起,想一想挺有意思。
我们不妨想象一下,未来我们的第二大脑是大模型,我们给的是需求,它自己决定调用哪些工具。作为被调用的工具方,在初期应该会有一波流量,因为大家在建设各自的智能体时(Agent),最终都需要终端能干活的“手”,但最终的发展可能还是看各个工具自己的品质和对需求的洞察与满足情况。
而在认识到MCP及有一些实际体验后,会发现在工作与日常中,目前就有很多场景可以应用。比如:
李开复先生的“所有行业都会被人工智能触及、改变、转型并提效。” 是有见地的,你看过高效而智能的做法,将再也回不去过往的流程了。
这篇文章就开个头,下一篇文章可能会聊聊开发mcp-server的经验,包括一些调试技巧。同时未来有更多AI实践经验觉得有意思有价值的话也会再分享,下回见喽。
我是个爱折腾技术的工程师,也乐于分享。欢迎点赞、关注、分享,更欢迎一起探讨技术问题,共同学习,共同进步。为了获得更及时的文章推送,欢迎关注我的公众号:
2025-02-20 08:00:00
我仍然有点恍惚,即便站在车水马龙的闹市中,依旧有些不真实感。不真实在从未想象的疾病会突然降临在我可爱的儿子身上,紧接着一系列的不安、恐惧、焦急,各种情绪找不到突破口,只在深夜,抓着媳妇的手,噙着泪花说,一切都会好起来的。
难得有像春节这般长的假期,一家人整整齐齐的每天在一起。看着3岁女儿和2岁的儿子,他们在老家的田间奔跑嬉戏,在楼上楼下床上床下反复蹦哒,在为谁先使用玩具而争吵哭闹。我为假期也准备了不少他们的手工书和玩具,希望一起开心玩玩。
谁料想,儿子在2月3号突然发烧,观察一天4号仍未好转伴食欲不振且半夜喝奶呕吐。下午带去乡镇卫生院检查,我们本以为只是一次简单的感冒,血常规检查时,护士惊讶了为什么血小板这么低,以为机器异常又让我们扎了一次手指,确认只有14后,同时白细胞、血红蛋白也都有下降。未等到找医生确认,她建议我们马上立即带去市里大医院看看。
我和媳妇意识到不对,立马回家收拾一点行李,借了邻居小伟的车,赶紧奔赴泉州妇幼保健院,也即儿童医院。车程有点长,60多公里的路,既要更少颠簸,又想尽快到达,我比平常多了很多的变道和超车,几十秒的红灯都比日常漫长多了。后视镜里,小家伙耷拉在妈妈肩膀似乎在睡觉。他可能啥也不知道,只是有点倦,而大人的内心满是担忧,但具体什么病却一无所知。
到了妇幼进入急诊,重新抽血去检查,等待,等待,着急的等待。娃的状态好点,大抵是饿了,娃妈妈给喂了一些面包。大概在17点半左右,血常规检验报告出来。考虑到血小板只有8(又降了),随时有身体内部器官出血风险,医生带我们上楼,直接住到了PCIU(儿童ICU)。娃哭着要妈妈,可是没有办法,不允许陪护,后续每天只能探望一次。ICU自动门关闭的那一刻,我仍然听到了撕心裂肺的哭喊。我们来不及悲伤于分离,便接到医生找我们谈话,在病危通知单上签字的手微微有些颤抖。仅仅3-4个小时,像过山车一样,但见不断上升上升,内心只有害怕,只有恐惧。
不能陪伴,我们在医院也没用。于是驱车回家,岳母问虎子人呢,媳妇都要哭了,几个人都红了眼睛。我们草草吃了一些饭菜,味同嚼蜡。原本想明早过去(60+公里远),媳妇放心不下,我也一样,于是晚上又借了婶婶的车。我们只觉得住靠近医院一点,离娃近一点,才能获得一丝心安。同时又放心不下女儿,把她也一起带上了。晚上酒店在918房,儿子的床位是917。在电梯我和媳妇开个玩笑,你看我们就住在儿子隔壁呢?她没有笑,我也没有,因为心底都压着沉沉的石头。
血小板减少症入院,具体原因还需进一步诊查。和医院沟通,当务之急是要尽快输血小板,但是医院说只报上去了,等血站调货,不确定什么时候能到。性命攸关之下,我们找了不少朋友,我的大学同学和媳妇的同学也尽力在帮忙中,让我们看到晚上十点多娃在ICU病床上安稳睡下了,我们稍微放心一些。晚上躺在酒店床上,难以入睡,我还能做点啥呢?我不能因为自己的难以启齿而放弃一些机会,我一定要尽快给娃搞到血小板!于是在公司内部乐问求助,也第一次注册小红书发本地求助贴,希望有人看到可以帮忙。最终确实也收到了一些热心朋友支招和安慰,比如凌晨3点公司同事还在给我解答疑问和安抚,也有人支招蹲血站,找黄牛,这些给人多了一些希望。
5号上午9点多,本来想和媳妇分头行动她去探视、我去血站求助和献血,看能否加速娃的供血。媳妇说不行,日常倔强的她显然此刻已乱了心神,我察觉到稍闲下来她已偷偷在抹眼泪。于是和她一起在医院,等统一的探视时间。媳妇出来后,听说虎子躺在床上被绑着(怕孩子磕碰),见到妈妈一直哭,我想大抵哭诉着“我要出去,我要妈妈”之类吧,媳妇在里面哄了一会,娃可能哭累了睡去,探视早已超时。
预约了下午两点采集血小板,中午要求吃了才能采,怕到时血不合格,只能强迫自己尽量多吃一点。血站离儿童医院只有1-2公里,提前到了便在外等爱心屋开门。血站工作人员说,小朋友是什么血型就需要献血的人是什么血型,这又是一个大坑:虎子血型到底是A还是O并不知晓。过往没专门查过,医院的几次检查里也没涉及血型,这可能使献血了因为血型不对派不上用场。只能想要不两者都献?遗憾的是媳妇的身体不便献血。恰逢有两个妹子过来献血,又恰好其中一个是A型血,我厚着脸皮靠近想开口,她没有开口,眼神和手势就赏了我一个闭门羹。确实,要献成分血更漫长,无亲无故谁会帮你呢?犯愁之际,连续来了两辆车,老婆家里叔叔伯伯家人以及邻居表弟都来了,看着他们一个个撸手袖子去测血型,只要能用上随时准备着,我的鼻子酸酸、异常感动。当时我便默默对自己和未来的虎子说,要记住他们、善待他们,这些是可以随时为你流血的人。虽然最终没有一个合适的A型,但所幸也得知了最终虎子是O型血,那么我的采集血小板就可以交换到一份O型供他使用了(注:国外成分血可血型不一致使用),天无绝人之路!看着血液从身体流出,想着或能帮助到儿子,有一点欣慰。拿到献血证后,马不停蹄敲开ICU找到护士,请求尽快申请输板。护士也告诉我们,今天做过骨穿检查了,板到了就会输。晚上大概十点多,和护士简单沟通,已经输过板了,终于放心一些。
晚上我们也联系了北京的专家,也问了上海的医学方面朋友,因为骨穿结果暂时没有,以仅有的一些报告,有说是再障的,也有说是急淋的。听起来都不像是很容易解决的病情。上海的朋友很给力的安排了医院留床,若是需要过去便可快速入院,考虑到这种危险程度,能尽快入院确实让我们安心不少,听说很难排到床位。凌晨1点多,有点撑不住了,大脑降频严重,睡了过去,不知道娃今晚在病房睡得可好。
6号一早,我们便赶往泉州儿童医院,血液科专家吴姓医生找我们聊了一下病情,从骨穿涂片等初步结果来看,应该是急性淋巴细胞白血病,简称急淋。医生也很自信的告诉我们,这个病是血液科常见的,儿童治愈率很高,80-90%以上可以治愈,但会是长期的过程,听到这里,我们高悬的心稍微放下了一些。那么去北京上海,或者还是留在泉州或者是回深圳治疗?如果在泉州的话,马上可以下一步大骨穿(可能要活检等),最快下周就可以开始上药。考虑到我们家实际情况,结合当前医生判断和对更换医院的建议,我和媳妇商量后决定在广州找医院进行治疗。
我继续找人联系广州的医院,当下这种情况,若过去后无法入院那是极危险的。公司的同事linda还有秘书都很帮忙,在我忙不开交时他们不停的帮联系人和沟通病情、寻找资源,很快收到电话推荐到广州妇女儿童医疗中心并且可入院,同学也通过关系找到这家医院的一个主任答应可以安排住院。在双重保障下,我们告诉泉州医院我们的决定:去广州下一步治疗。何时出动?事不宜迟,医院说上午安排了输血,那下午即刻动身。
亲戚们也陆续赶来,顺便把我们的行李带过来了,缺少的东西他们分头去采购。我们预定下午6点直飞广州白云机场,并且联系好在深圳的亲人来接送。安排妥当后,中午在医院等候椅上吃了个盒饭,这次的饭终于有了一点味道。离下午2点还有些时间,他们(老婆?)还在门口买了个虎子喜欢的大大的奥特曼气球,我在想象从ICU接虎子出来时,他看到后会不会开心的笑,一边在妈妈怀里一边用他那稚嫩的声音说:奥特曼。可是并没有-当护士呼唤我们拿些衣物进去,他们给换好后衣物后,门缓缓打开,虎子颤颤巍巍地走出来时,没有看到爸妈的开心,脸上呆呆,有点不知所措。我内心一阵酸楚,两天见不到亲人,浑身被绑,哭喊无助,定是伤心透了。媳妇很快把他抱入怀里,无论如何,宝贝总算回到爸妈身边了。原来有分离焦虑的不光是孩子,爹娘何偿不是呢?我轻摸了一下他的手和脚,他身体紧紧贴住妈妈。
小伟和几个亲戚送我们到机场,挥手告别。在飞往广州的飞机上,看着虎子迷糊在妈妈怀里,小家伙,未来可能会有些困难,但无论如何,爸妈都会尽一切力量给你治好的,你也会很努力的,对吗?我知道,你可以的!你每次摔倒第一件事就是告诉大家,“我没事”,然后自己爬起来。是的,你肯定没事!
我们相信,穿过这场突如其来的暴风雨,终将在阳光里重逢。