最新

在过去的几周里，我深入学习了MCP，这是一种新协议，可以为任何大型语言模型（LLM）配备一套工具，这些工具可以在您自己的机器上或您控制的远程服务器上运行，从而赋予人工智能代理各种强大的功能，例如搜索等。 作为这项研究的一部分，我已经构建了一个非常完善且实用的MCP服务器，并在这里分享（不过我最近对其进行了更多的改进！），这个LLM Gateway MCP服务器允许您使用一个大型模型来委托给一个更便宜的模型（此外还有很多其他功能，比如运行自动化的多轮LLM比赛，我最近也在X上发布了相关内容）。 不过，要实际使用这些MCP服务器，您需要一个MCP客户端。大多数人似乎在使用Claude桌面应用程序。我尝试过这个应用，并且能够正常工作，但设置过程有点麻烦，而且有很多我不喜欢的地方。我想要一个更好的选择。 因此，两天前我开始着手开发我所称之为终极MCP客户端。经过大约24小时的工作，它已经完成并准备就绪，我对它的出色表现感到非常自豪。这将成为我个人的一个重要工具。 它是纯Python编写的，所有代码都在一个大型.py文件中，如果需要，可以作为一个自包含的uv脚本进行部署。它提供了各种功能和丰富的控制台输出，便于在终端中交互使用，同时也支持命令行界面（CLI）。但它也可以在后台使用。 我主要打算利用这种后台功能，优雅地协调多个MCP服务器。但当我看到交互式终端体验如此出色时，我意识到可以在其上添加一个FastAPI服务器，制作一个网页图形用户界面（GUI）。 由于我非常讨厌不必要的复杂性，我将网页GUI制作成一个单一的自包含HTML文件，您只需在浏览器中打开（类似于我的Your-Source-to-Prompt工具），它使用Alpine、Daisy和其他优秀的用户界面库，看起来非常棒，所有库都是通过CDN加载的。

我注意到微软的 .NET Framework 4.x 和甲骨文的 JDK 8.x 系列之间有很强的相似之处。尽管新版本不断推出——如 .NET Core、.NET 6/7/8，JDK 11/17/21——这些旧版本却依然顽强存在。 原因有几个： - 企业使用广泛，特别是在中型企业和中小型企业中。 - 行业惯性——团队在没有强有力的商业理由的情况下，不愿意重写已经在运行的系统。 - 在某些情况下，旧技术栈更稳定，经过“实战检验”，特别是对于像 WinForms 或厚客户端应用这样的用例。 有点讽刺的是，即使在今天，新的 Windows 安装中默认的 .NET 版本仍然是 4.6（或相近版本），而不是闪亮的新 .NET 8/9。与此同时，甲骨文仍然提供 JDK 8——尽管是在付费支持的框架下——就像微软继续通过 Windows 更新为 .NET 4.x 提供补丁一样。 最终，这些旧版本将会被淘汰。但考虑到它们的稳定性和广泛的工业应用，我觉得那一天可能是几十年而不是几年后。 我很想听听你的看法——你认为这个过渡将如何展开？有没有好的例子显示团队成功地从 4.x 或 8.x 迁移？