[Request] 默认助手的设置逻辑问题

[bbb3n]

🥰 需求描述 | Feature Description

根据我自己的使用来看，现在的流程是：
先去 /settings/agent 里设置 默认助手 的相关参数
再去对话页 新建助手 ，来实现创建想要的 默认助手 。

但这个逻辑链条貌似有很严重的误区
你们单独在设置里做了 默认助手 这一个设置
其一个可能的效果是让用户 只设计一个 助手 ？
（我表述可能不太恰当

我的建议是：
不要在设置里 单独 放一个 默认助手
而是在 新建助手 时，让用户现场设计 这个新建的助手 。

🧐 解决方案 | Proposed Solution

• 去除 设置 里的 默认助手 设置
• 在每次 新建助手 时，让用户现场设计 新的助手

📝 补充信息 | Additional Information

暂无

[lobehubbot]

Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑‍🤝‍🧑👫🧑🏿‍🤝‍🧑🏻👩🏾‍🤝‍👨🏿👬🏿

---

🥰 Requirement Description | Feature Description

According to my own use, the current process is:
First go to /settings/agent to set the relevant parameters of Default Assistant
Go to the dialog page New Assistant to create the desired Default Assistant.

But there seems to be a serious misunderstanding in this logical chain
You have made the Default Assistant setting separately in the settings.
One possible effect of this is to allow users to design just one assistant?
(My expression may not be appropriate

my suggestion is:
Do not put a default assistant in the settings separately
Instead, when creating a new assistant, the user is allowed to design this new assistant on site.

🧐 Solution | Proposed Solution

• Remove the Default Assistant setting in Settings
• Allow users to design new assistants on-site every time new assistant is created

📝 Additional Information |

No

[lobehubbot]

👀 @B3nDan

Thank you for raising an issue. We will investigate into the matter and get back to you as soon as possible.
Please make sure you have given us as much context as possible.
非常感谢您提交 issue。我们会尽快调查此事，并尽快回复您。 请确保您已经提供了尽可能多的背景信息。

[arvinxx]

其实可以先创建助手以后，直接点击右上角的设置来修改这个助手

默认助手的作用是，在每次创建新助手的时候，默认沿用这个助手的设置。比如我希望每个创建的助手的模型是 GPT-4 ，那么设置一次默认助手的模型为 GPT-4 就好了。

[lobehubbot]

Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑‍🤝‍🧑👫🧑🏿‍🤝‍🧑🏻👩🏾‍🤝‍👨🏿👬🏿

---

In fact, after creating the assistant first, you can directly click on the settings in the upper right corner to modify the assistant.

The function of the default assistant is to use the settings of this assistant by default every time a new assistant is created. For example, if I want the model of each assistant created to be GPT-4, then just set the default assistant model to GPT-4 once.

[arvinxx]

可能名称改成助手默认设置更易于理解一些？

[lobehubbot]

Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑‍🤝‍🧑👫🧑🏿‍🤝‍🧑🏻👩🏾‍🤝‍👨🏿👬🏿

---

Maybe changing the name to Assistant Default would make it easier to understand?

[bbb3n]

可能名称改成助手默认设置更易于理解一些？

你说的对。

我主要认为的是，本来基础配置的选项就不多，没必要提前填好（就像模板？）
每次新建时完全可以现场写
因为我觉得新建助手应该是很低频的行为（对于大部分客户），大部分人更倾向于用别人做好的（比如市场里）

[lobehubbot]

Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑‍🤝‍🧑👫🧑🏿‍🤝‍🧑🏻👩🏾‍🤝‍👨🏿👬🏿

---

Maybe changing the name to the default setting of the assistant will make it easier to understand?

you're right. I mainly think

[bbb3n]

@arvinxx

刚才我又去看了一下 新建助手 的流程

我发现：
一个助手都没有的情况下，助手列表 和 最上方 都会有一个 新建助手 的按钮
如下图

新建一个助手 后，助手列表 的 新建助手 按钮会消失，仅 最上方 都会有 新建助手 的按钮
如下图

能否仅保留 助手列表 的 新建助手 按钮（哪怕已经存在一个或多个助手）
然后将 最上方 的 新建助手 按钮换成 新建聊天/话题 ？
现在打开一个新的聊天窗口是点击右侧默认创建的 默认话题临时，就感觉很奇怪，可能是我习惯了nextweb的新建聊天方式
不知道你们是否认同nextweb的新建聊天的 “明显 快捷"的设计

[lobehubbot]

Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑‍🤝‍🧑👫🧑🏿‍🤝‍🧑🏻👩🏾‍🤝‍👨🏿👬🏿

---

@arvinxx

Just now I took another look at the process of creating a new assistant.

I find:
If there is no assistant, there will be a New Assistant button on both the Assistant List and the Top
As shown below

After creating a new assistant, the New Assistant button in the Assistant List will disappear, and there will only be a New Assistant button at the top.
As shown below

Can I keep only the New Assistant button of the Assistant List (even if one or more assistants already exist)
Then replace the New Assistant button at the top with New Chat/Topic?
Now when I open a new chat window, I click on the default topic Default Topic Temporary on the right, which feels very strange. Maybe I am used to the new chat method of nextweb.
I don’t know if you agree with the “obvious and fast” design of nextweb’s new chat

[mushan0x0]

话题、助手这两个是不同维度的，目前这样设置明显更合理，next-web 没有话题这个维度，是不具备参考性的。助手列表为空时的按钮明显是占位的，当有内容时就不需要了，不然很冗余。

[lobehubbot]

Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑‍🤝‍🧑👫🧑🏿‍🤝‍🧑🏻👩🏾‍🤝‍👨🏿👬🏿

---

Topics and assistants have different dimensions. Currently, this setting is obviously more reasonable. Next-web does not have the topic dimension and is not referenceable. The button when the assistant list is empty is obviously a placeholder. It is not needed when there is content, otherwise it will be redundant.

[lobehubbot]

✅ @B3nDan

This issue is closed, If you have any questions, you can comment and reply.
此问题已经关闭。如果您有任何问题，可以留言并回复。

[arvinxx]

补充一下我们背后的考量：

首先讲下 LobeChat 的产品架构。在 我们设计的框架中，顶级对象是「助手」（agent），然后助手下才是「话题」（topic），话题中承载「消息」（message）。

而 目前 Chat-Next 的方案，以及 1106 以前的 ChatGPT ，只有「话题」 与「消息」 两个层级。这会导致一个问题是，如果用户需要一个特定领域的助手，在每次会话开始前都得重复输入一下相应的 systemRole，然后才能开始会话。这在实际生产应用中非常不方便。

而在 1106 OpenAI 开发者大会上，OpenAI 推出了 GPTs，同样提出了「Assistant」 的概念，让大家可以自行设计助手来进行会话。「Assistant」 和我们的助手概念是完全一致的，而 Chat-Next 已经官宣过后续也会跟进该设计。所以在产品架构维度上， LobeChat 的「助手 - 话题 - 消息」的三层框架是不会变的，未来的产品功能演进也是围绕这三层展开。

然后回到你的问题中，你的问题其实是创建助手不够高频，放在那里有点浪费，希望将功能改掉。这块我目前的想法是这样的：

1. 创建助手的频率的确不是特别高，但这个功能按钮一定会保留，怎么呈现还需要细化；
2. 将默认行为变成「创建话题」不是不可以，行为上的确是高频行为。但是这里存在一个问题是，点这个按钮创建的话题，到底是在哪个助手下创建，因为在上述产品框架下，话题一定得归属于助手，不会孤立存在。
3. 目前想到最有可能的方式是，当前激活哪个助手，就在哪个助手下创建话题，这个可能是将那个按钮改成创建话题下的唯一合理解。
4. 但是我们仍然需要保留创建助手的功能，所以这个添加的按钮可能会变成一个点击后出现 menu 的方式，允许用户选择新建的类型，比如：

• 在当前助手下新建话题
• 新建助手
• 新建助手并进行设计

如果要改动的话，未来的方式可能就是第四点描述的那样。

[lobehubbot]

Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑‍🤝‍🧑👫🧑🏿‍🤝‍🧑🏻👩🏾‍🤝‍👨🏿👬🏿

---

Let’s add some considerations behind us:

Let’s talk about the product architecture of LobeChat. In the framework we designed, the top-level object is the "agent", and then under the assistant is the "topic", which carries the "message".

The current Chat-Next solution, as well as ChatGPT before 1106, only have two levels: "topic" and "message". This will lead to a problem that if the user needs an assistant in a specific field, he has to repeatedly enter the corresponding systemRole before starting the session. This is very inconvenient in actual production applications.

At the 1106 OpenAI Developer Conference, OpenAI launched GPTs and also proposed the concept of "Assistant", allowing everyone to design their own assistants to conduct conversations. "Assistant" is completely consistent with our assistant concept. Chat-Next has officially announced that it will follow up on this design. Therefore, in terms of product architecture, LobeChat's three-layer framework of "Assistant - Topic - Message" will not change, and future product function evolution will also revolve around these three layers.

Then back to your question, your problem is actually that the creation of assistants is not high-frequency enough, and it is a bit wasteful to put it there. I hope the function can be changed. My current thoughts on this are this:

1. The frequency of creating assistants is indeed not very high, but this function button will definitely be retained, and how to present it needs to be refined;
2. It is not impossible to change the default behavior to "create topic". The behavior is indeed a high-frequency behavior. But there is a problem here, which assistant creates the topic created by clicking this button, because under the above product framework, the topic must belong to the assistant and will not exist in isolation.
3. The most likely way that comes to mind at present is to create a topic under whichever assistant is currently activated. This may be the only reasonable understanding of changing that button to create a topic.
4. But we still need to retain the function of creating an assistant, so the added button may become a menu that appears after clicking, allowing the user to select a new type, such as:

• Create a new topic under the current assistant
• New assistant
• Create new assistants and design them

If changes are to be made, the future approach may be as described in point 4.