[Feat]: 异步处理消息？

[QAbot-zh]

Search for answers in existing issues

• [X] I have searched issues, there is no similar issue related

Feature description

小小地畅想一下，要是支持异步处理消息的机制，应该会很不错。比如有调用ChatGPT的，有调用plugin的，它们并不会造成资源的冲突，但是没有异步处理的话它们只能串行等待执行，响应速度就咔咔掉了。

Motivation

No response

[liangchaoUpUp]

我也在考虑这个问题，群聊中多人在提问时，GPT是需要将某个人的答复完了之后才会回答下一个人的，响应上感觉不是那么友好

[markvlenvision]

我也在考虑这个问题，群聊中多人在提问时，GPT是需要将某个人的答复完了之后才会回答下一个人的，响应上感觉不是那么友好

如果异步处理，同时发送多条消息，会不会触发微信的账号风控机制（我不清楚）。同步机制我认为是合理的。

[QAbot-zh]

我也在考虑这个问题，群聊中多人在提问时，GPT是需要将某个人的答复完了之后才会回答下一个人的，响应上感觉不是那么友好

如果异步处理，同时发送多条消息，会不会触发微信的账号风控机制（我不清楚）。同步机制我认为是合理的。

异步处理不一定要同时发送，发送消息时间很短，而gpt请求响应时间略长，可以做成异步请求gpt回复，回复内容放入一个消息队列，由发送线程按最少1s时间间隔从消息队列里取内容、发送消息，就是很多搬运工、一个发货员的模式。就是实现起来要复杂很多。

[markvlenvision]

我也在考虑这个问题，群聊中多人在提问时，GPT是需要将某个人的答复完了之后才会回答下一个人的，响应上感觉不是那么友好

如果异步处理，同时发送多条消息，会不会触发微信的账号风控机制（我不清楚）。同步机制我认为是合理的。

异步处理不一定要同时发送，发送消息时间很短，而gpt请求响应时间略长，可以做成异步请求gpt回复，回复内容放入一个消息队列，由发送线程按最少1s时间间隔从消息队列里取内容、发送消息，就是很多搬运工、一个发货员的模式。就是实现起来要复杂很多。

你就是要异步请求openai API，然后在wx和API之间加一层消息队列以此来增加响应速度。 实现起来太复杂，而且用户使用成本增高。 但如果第二条消息快于第一条消息，那不就乱了吗。

[QAbot-zh]

我也在考虑这个问题，群聊中多人在提问时，GPT是需要将某个人的答复完了之后才会回答下一个人的，响应上感觉不是那么友好

如果异步处理，同时发送多条消息，会不会触发微信的账号风控机制（我不清楚）。同步机制我认为是合理的。

异步处理不一定要同时发送，发送消息时间很短，而gpt请求响应时间略长，可以做成异步请求gpt回复，回复内容放入一个消息队列，由发送线程按最少1s时间间隔从消息队列里取内容、发送消息，就是很多搬运工、一个发货员的模式。就是实现起来要复杂很多。

你就是要异步请求openai API，然后在wx和API之间加一层消息队列以此来增加响应速度。 实现起来太复杂，而且用户使用成本增高。 但如果第二条消息快于第一条消息，那不就乱了吗。

不太理解用户使用成本提高这点。可能我们的日常使用场景不同，我给身边几个同学用的，基本都是跟小号机器人私聊，很少有在群里@的，大概都不想被其他人看到提问的内容，所以如果某个消息请求卡住了，串行同步的其他人只能被动等待，这个时间成本还是有的。 至于消息乱这点，也是可以通过其他方法来缓解，比如我在 #83 设想过的使用微信的引用回复功能。由于作者使用的hook暂不支持引用回复功能，我现在使用的是在回复消息前面加上提问者的问题文本，来尽量避免提问和回答乱掉。

[markvlenvision]

我也在考虑这个问题，群聊中多人在提问时，GPT是需要将某个人的答复完了之后才会回答下一个人的，响应上感觉不是那么友好

如果异步处理，同时发送多条消息，会不会触发微信的账号风控机制（我不清楚）。同步机制我认为是合理的。

异步处理不一定要同时发送，发送消息时间很短，而gpt请求响应时间略长，可以做成异步请求gpt回复，回复内容放入一个消息队列，由发送线程按最少1s时间间隔从消息队列里取内容、发送消息，就是很多搬运工、一个发货员的模式。就是实现起来要复杂很多。

你就是要异步请求openai API，然后在wx和API之间加一层消息队列以此来增加响应速度。 实现起来太复杂，而且用户使用成本增高。 但如果第二条消息快于第一条消息，那不就乱了吗。

不太理解用户使用成本提高这点。可能我们的日常使用场景不同，我给身边几个同学用的，基本都是跟小号机器人私聊，很少有在群里@的，大概都不想被其他人看到提问的内容，所以如果某个消息请求卡住了，串行同步的其他人只能被动等待，这个时间成本还是有的。 至于消息乱这点，也是可以通过其他方法来缓解，比如我在 #83 设想过的使用微信的引用回复功能。由于作者使用的hook暂不支持引用回复功能，我现在使用的是在回复消息前面加上提问者的问题文本，来尽量避免提问和回答乱掉。

我说的用户指的，使用作者当前项目的用户，对于一些人而言，能搭建好目前的这一套已经很不容易了。我想表达的意思是其实很多人并非技术出身，服务设备性能也不优秀，加太多东西怕扛不住。

[QAbot-zh]

我也在考虑这个问题，群聊中多人在提问时，GPT是需要将某个人的答复完了之后才会回答下一个人的，响应上感觉不是那么友好

如果异步处理，同时发送多条消息，会不会触发微信的账号风控机制（我不清楚）。同步机制我认为是合理的。

异步处理不一定要同时发送，发送消息时间很短，而gpt请求响应时间略长，可以做成异步请求gpt回复，回复内容放入一个消息队列，由发送线程按最少1s时间间隔从消息队列里取内容、发送消息，就是很多搬运工、一个发货员的模式。就是实现起来要复杂很多。

你就是要异步请求openai API，然后在wx和API之间加一层消息队列以此来增加响应速度。 实现起来太复杂，而且用户使用成本增高。 但如果第二条消息快于第一条消息，那不就乱了吗。

不太理解用户使用成本提高这点。可能我们的日常使用场景不同，我给身边几个同学用的，基本都是跟小号机器人私聊，很少有在群里@的，大概都不想被其他人看到提问的内容，所以如果某个消息请求卡住了，串行同步的其他人只能被动等待，这个时间成本还是有的。 至于消息乱这点，也是可以通过其他方法来缓解，比如我在 #83 设想过的使用微信的引用回复功能。由于作者使用的hook暂不支持引用回复功能，我现在使用的是在回复消息前面加上提问者的问题文本，来尽量避免提问和回答乱掉。

我说的用户指的，使用作者当前项目的用户，对于一些人而言，能搭建好目前的这一套已经很不容易了。我想表达的意思是其实很多人并非技术出身，服务设备性能也不优秀，加太多东西怕扛不住。

技术畅想嘛，你看其它帖子，包括作者自己以前也有很多想法。而且其实目前都是配置式的，工作量主要在开发者那里，项目用户没有那么大的搭建成本，按流程走就行了。 至于性能嘛，现在这个项目量跟其他项目比起来真的不咋吃性能，我一个挂机宝都跑得起来。实在跑不起来的也可以跑老版本呀。这不应该是制约一个项目发展的理由。