最新

在过去的几周里，我一直沉浸在学习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 迁移出去？