1. 问题的提出

小U同学目前在可操作性对话上取得了显著的进步，可以通过在线模型的配置（当然需要耗费money），以及通过MCP server调用，实现对本地软件、数据等资源的直接操作与读写，但确实很耗费token，并且调用本地大语言模型服务（本地私有模型）时，明显慢很多。以下为证据。

我在本地，使用llama.cpp部署了一个大语言模型（127.0.0.1:8080），我的PC只有CPU，无GPU，我用两种方式调用该大模型（纯聊天），二者区别如下：

（1）llama.cpp自带的网页客户端

速度要快很多，即时响应。

（2）用小U同学客户端

响应慢很多，且常常如上所示，答非所问。

2. 原因分析

（1）小U同学，始终处于调用MCP 服务（可操作）模式，消耗更多的token
即使纯聊天，也在我输入的内容上附加了太多的本地可调用MCP服务信息，导致LLM接收了太多的额外的信息，使得LLM处理时间大大加长，并可能被污染，而产生错误的输出，
（2）小U同学没有提供给大语言模型接口传输流式参数："stream":true的设置界面,默认的方式是：非流式。
这对于纯聊天，可能不是一个好的设置。如果模型服务平台性能不好，处理速度慢，用户需要等它处理完，才一次发给客户端输出内容，导致客户端给人感觉响应十分缓慢。

3. 建议

3.1 小U应该明确区分“纯对话”与“可操作”两种模式

可以通过类似于chatbox的对话模式和工作模式切换在两种状态间由用户手动切换，纯对话时，不要附加“额外的信息”，减少token浪费

3.2 小U应该可以做类似如下的对话设置

流式设置，应该可以减少用户不必要的本地等待。

3.3 小U同学可以很好地借鉴chatbox的UI设计

我对比了anythingLLM,chatbox,小U，我认为，小U无论在功能设计，还是界面设计，都还有非常大的改进空间。另外，小U完全可以借鉴chatbox模式，高级版用户适当收费，每星期给普通用户送一点token，用完继续用服务，需充值，可确保开发能持续推进。毕竟，要提供云上LLM服务，是要烧钱的，取之于民，用之于民，合情合理，但也必须给普通用户一定的体验空间，毕竟这种体验也能够促进技术的进步。