关于并行对话的疑问

[hansedong]

并非报告问题，想了解一个问题，可以的话希望能够帮忙解惑，感谢～

按我理解，这个项目是依赖 2 个 Bot 通过对话的形式进行交互，而这个交互是在 Discord 来中转的。这个过程中：

1. 我通过 ChatGPT 客户端，发送请求。
2. coze-discord-proxy 将数据，通过 Discord BotB，发送到 Discord Channel，并且，@了 Discord BotA 来发送消息。
3. Discord BotA 对接了 Coze ，Coze 回复数据，最终，经有 Discord Channel，回复到 BotB，进而，数据通过 coze-discord-proxy 流转到 ChatGPT 客户端。

想了解的问题有 2 个：

1、关于对话轮数携带问题

ChatGPT 客户端如果我设置了对话数据为 5 轮，按我理解，客户端工具确实是会携带 5 轮会话的。然而我在 Discord Channel 中看到 Robot 在对话时，是没有携带多轮回话信息堆栈的。

并且，我如果将客户端的对话轮数设置为 2（也就是携带历史 2 条对话信息），我让它回答我们的对话第一个问题是什么，结果它可以回答到更早之前的第 11 条对话问题。这说明，ChatGPT 的客户端对话设置轮数，和实际的对话轮数，是不一样的。

想问的是：这个对话轮数，到底哪里会起到决定性作用？是 Coze 那边吗？如果是 Coze 那边，那 coze-discord-proxy 往 Coze 机器人发消息时，携带的数据轮数是多少呢？

2、关于对话并行发生时，是否可能会有干扰的问题

如果 ChatGPT 客户端是多人在使用，实际上，会在 DIscord Channel 中形成多人的对话，而且可能是并行回答的对话。

想问的是：这种多人对话是不是可能相互干扰上下文（比如有人在问编码，有人在问天气），最终形成相互干扰的多轮对话？甚至，并行对话发生时，有没有可能问题并行 @Coze Bot，最终 coze-discord-proxy 再转发对话回复时，会串台（A 问的问题收到 B 的问题的回复，B 问的问题收到了 A 的问题的回复）？

[deanxv]

1. 目前对于coze托管的机器人，上下文我们无法控制，也就说我们无法像调用官方请求接口一样把对话记录存储为msg数组作为上下文。Bot的上下文则是默认读取当前对话频道/线程内的对话记录。所以我们在ChatGPT客户端发起请求时可以指定ChannnelId(可以不指定，默认为环境变量中的ChannelId)来作为机器人所在的上下文环境。至于coze配置中的多轮对话设置参数我没有详细测试过，如果设置无效的话，可以合理怀疑该参数对coze托管的机器人无效(也可能是bug)。

2. 在同一频道中，一个我们托管的机器人，一个bot托管的机器人，两个人A和B使用coze-discord-proxy对话时是不会发生串台的，会记录发送消息的id。但由于频道内上下文共享的关系，A和B使用coze-discord-proxy对话时在discord中其实都是由我们的机器人发送的，也就时说此时两个人共享了一套上下文。想解决也很简单，每个对话接口中均带有ChannelId，每个人的对话指向不一样的频道即可。另外的方法配置多【机器人-频道】进阶配置，每个人一个secret，每个secret对应自己的coze机器人和专属频道去隔离上下文。

[hansedong]

@deanxv 了解了，同我预想的差不多，感谢解惑，感谢🌹

[hansedong]

@deanxv 另外想问下，考虑把环境变量部分的获取，改为参数形式吗？环境变量的确有利于容器部署，但个人觉得在工程师直接依赖外部环境变量，通过 GetEnv 获取不太优雅。 有一些 cli 参数库，可以做到命令行参数读取也可以支持环境变量读取。 如果考虑的话，我可以认领一下

[deanxv]

@deanxv 另外想问下，考虑把环境变量部分的获取，改为参数形式吗？环境变量的确有利于容器部署，但个人觉得在工程师直接依赖外部环境变量，通过 GetEnv 获取不太优雅。 有一些 cli 参数库，可以做到命令行参数读取也可以支持环境变量读取。 如果考虑的话，我可以认领一下

使用cli命令的场景大多都在直接执行二进制文件的时候，但其实本项目是非常推荐容器化部署，尤其是可能后期集成了mysql、redis等等，cli就显得很麻烦了，不过我可以把一些与业务绑定不是那么深的环境变量支持cli，比如端口。后期可能会修改。

十分谢谢你的建议，我来修改就可以。