正如我一直强调的：https://epicai.pro/stop-making-llm-wrappers-y4d1y… 您需要的是一个功能强大的MCP服务器（例如 @kodykoala 的实现）。不要与现有模型和工具框架竞争。

停止制作大语言模型封装器

来源：https://www.epicai.pro/stop-making-llm-wrappers-y4d1y 您是否正在为网站构建AI聊天机器人？请立即停止。我有个消息要告诉您：这并非用户真正需要的。

试想一下：当托尼·斯塔克需要完成某项任务时，他会为每项任务切换不同的AI助手吗？当然不会。他有贾维斯——一个全能的AI系统。星际迷航的舰员与飞船计算机的关系也是如此。这正是我们所预见的未来，我建议现在就应做好准备。

当前我们正在创造割裂的AI体验。每个网站或应用都拥有自己的AI助手，迫使用户不断切换上下文。这就像为家里的每个房间都配备不同的私人助理——完全是不必要的开销。

但问题的关键在于：用户不希望体验被割裂。 他们渴望一个强大统一的AI助手，能够与任何网站或应用交互。

这正是MCP的价值所在。

MCP（模型上下文协议）允许用户偏好的AI助手直接与您的网站或应用交互。无需切换上下文，不再有割裂的体验，也不再需要为系统集成编写粘合代码。

通过MCP，您的网站将成为可供任何AI助手调用的工具集。这相当于将应用控制面板的访问权交给贾维斯。用户可以继续使用熟悉的AI助手，在舒适区内与您的特定服务进行交互。

我理解您此刻的想法：“但我已经投入时间为网站封装了大语言模型！”我完全明白。但残酷的现实是：从长远来看，用户不会想要这种模式。

与其创建又一个对用户偏好和目标一无所知的聊天界面，我们应该专注于构建健壮的MCP服务器，为用户正在使用的AI助手提供清晰的工具和API——这些助手本身已经掌握了用户所需的上下文信息。

这是思维方式的转变，但至关重要。我们的视角需要从“如何为网站添加AI功能”转变为“如何让网站更好地接入AI助手生态”。

遗憾的是，截至2025年4月，AI助手的MCP支持仍不完善。客户端体验有待提升，MCP服务器的发现机制也不够理想。我相信这种情况会很快改变，但如果您现在就需要为用户提供卓越价值，可以采取以下方案：在为不可避免的未来做准备的同时，服务好当前用户。

如果确实需要为应用封装大语言模型并添加聊天功能，至少可以构建一个供您的封装器调用的MCP服务器。这样一来，当AI助手技术成熟时，用户就能立即通过首选客户端接入并使用您的MCP服务器。

需要明确的是，我并非否定后端AI处理或专门与模型交互的智能体的价值。这类技术在幕后运作时非常出色。但在用户交互层面，我们需要追求最佳体验。

通过拥抱MCP模式并专注于提供工具而非封装器，我们正在为未来铺路。一个用户能在整个网络（而不仅是我们自己的小天地）中实现无缝AI交互的未来。

因此，让我们停止建造信息孤岛，转而架设连接桥梁。您的用户（及其AI助手）必将为此感激。

鲍勃大叔·马丁 (@unclebobmartin)： 是的，我们需要重新思考这个问题。

过去几周我一直在努力构建一个能严格约束智能体行为模式的框架。我设置了各种门控、测试、工具和协议……

当我埋头苦干时——