[RFC] 006 - 支持插件自定义会话时序逻辑

[arvinxx]

背景

refs: #341

当前的 LobeChat 的插件机制基本 follow ChatGPT 。 ChatGPT 里的插件基本都是展示型的组件，没有富交互能力。

Vercel 的ai sdk 文档里也提到了function call 的三阶段，第三阶段就是富交互，允许用户和插件进行除基础展示外的复杂交互。

由于当前的插件机制，缺少发送会话数据的时机控制，因此无法实现在插件中进行若干操作后，再继续进行会话。

目标

实现高自由度的会话时序控制，以支持复杂会话功能的实现。

思路

当前插件中触发 FunctionCall 的实现如下：

// src/store/session/slices/chat/actions/message.ts#L219
    // 生成 ai message
    const { isFunctionCall } = await generateMessage(messages, mid);

    // 如果是 function，则发送函数调用方法
    if (isFunctionCall) {
      triggerFunctionCall(mid);
    }

核心触发FC的代码在 triggerFunctionCall 中：

  triggerFunctionCall: async (id) => {
    // ...

    // ============ 下方为与插件侧交互的关键逻辑  ===========

    let data: string;
    try {
      const abortController = toggleChatLoading(true, id);
      data = await fetchPlugin(payload, { signal: abortController?.signal });
    } catch (error) {
      dispatchMessage({ id, key: 'error', type: 'updateMessage', value: error });

      data = '';
    }
    toggleChatLoading(false);
    // 如果报错则结束了
    if (!data) return;

    dispatchMessage({ id, key: 'content', type: 'updateMessage', value: data });

    const chats = chatSelectors.currentChats(get());

    await realFetchAIResponse(chats, message.id);
  },

为了支持用户更加灵活的时序控制，我们需要在该方法上增加对应的功能。

目前与插件交互的步骤有两个如下：

1. 从插件侧获取结果消息，将消息接入 content 中；
2. 触发一次 ai 请求，进行下一步的操作；

更加灵活意味着，插件可以自行决定：

1. 何时让 LobeChat 主体获取插件侧消息写入 content。应该包含 LobeChat 请求（目前的方案）或者插件向 LobeChat 主动推送消息（LobeChat 订阅 插件侧消息）；
2. 触发 ai 请求的控制时机，LobeChat 可以接受插件触发 ai 消息的事件。

[arvinxx]

LobeChat 与插件的通信机制

先来讨论第一个问题： 如何控制从插件侧获取结果消息并写入 content 的时机。

由于 content 是文档会话流的关键信息，content中的内容会发送给 ai 进行总结或者生成。因此我们可以把控制写入 content 作为插件消息的结束时机。

复交互的卡点就是在这里。有些复交互是需要用户进行一些操作后，才会得到相应的 content 。

比如一个 sd 插件，希望用户选择生成风格后，再进行生成。这就需要 LobeChat 在获取消息阶段时 pend 住。然后开始订发布一个消息订阅，并在收到插件消息后往下进行。此时的 loading 需要结束。然后用户在进行相关操作后再触发 ai 消息。

---

根据以上讨论，需要支持的核心功能：

• 一个 manifest 配置 type: standalone ，控制插件决定是否走自定义消息时机；
• 一个监听函数，当接收到通知后，触发 content 写入等一系列操作。

这种模式下，所有的前后端逻辑似乎应该全部都在插件侧完成，插件和 LobeChat 的消息通知应该全部走前端 postMessage 逻辑。

那这么看来，更进一步来说，插件似乎可以成为完全独立的应用，在接收到 LobeChat 的消息通知后，自行决定内部的交互逻辑，最后在完成交互后，再通知 LobeChat 得到 content 内容。

[arvinxx]

当我们完成上述核心功能后，再来看第二个问题，富交互的状态持久化。content 是插件发给主体的终态信息，但中间态的用户配置需要能保存下来。我们需要允许插件通过发送消息的方式，将状态持久化到对应消息的另外一个字段中，例如 pluginState。

当用户再次打开时，主体会向插件发送 content 和 pluginState 两个消息，进而让插件恢复上一次的状态

此外，插件侧除了需要知道pluginState，同样需要感知到 pluginSettings ，以便获取全局配置。但每个插件都应该只感知自己作用域的settings信息

[arvinxx]

根据上一条的分析，我们发现新机制下对于各种现成的应用是非常友好的，可以做到不改动任何现成代码的情况下，实现与 LobeChat 集成。而集成所需要做的事情就这么几项:

1. 增加一个监听 hooks useOnStandalonePluginInit，接受 LobeChat 发送过来的入参信息，然后基于这些信息完成初始化逻辑。

2. 使用两个 postMessage 方法: postToUpdatePluginState 和 fetchPluginState，用于向 lobeChat 推送/获取需要存储的数据 (state 和 settings)。

   • 针对react 应用 提供两个 hooks usePluginState 和 usePluginSettings ，用于替换 useState 从 LobeChat 获取状态。

3. 使用一个 postMessage postToFillPluginContent 方法，用于向 LobeChat 推送最终 message 的 content。

---

举例: 假设有一个现成的在线图表配置工具，支持配置若干种图表。

用户通过发送消息 我要画个折线图，然后ai识别到图表配置工具的插件，然后参数是折线图。

LobeChat 正常加载图表配置工具后，将折线图这个参数发给图表工具。

图表工具通过 useOnStandalonePluginInit 拿到 LobeChat 发送给插件的参数（payload，即会话发送过来的 Function Call 参数），然后自动进入折线图配置模式。

然后用户开始进行各种配置，配置中的参数可以通过 usePluginState 或者 postToUpdatePluginState 将状态存入 message 的 pluginState 字段。

最后当用户点击完成配置按钮，图表工具生成折线图代码，并通过 postToFillPluginContent 将该信息存入 content，然后触发 ai 消息。

更近一步，假设我们有另外一个插件，可以实现运行代码，并将其可视化出来。

图表工具生成的消息，会触发该插件，将这些代码渲染为可运行的折线图。

当然，图表工具也可以保存折线图的md数据到 content，并触发ai消息。而此时ai则会尝试去总结以上消息，给出一些数据洞察

[arvinxx]

这样的机制对于纯前端来说非常友好，我们可以借此接入大量的纯前端工具，这是 chatGPT 插件无法比拟的。

总的来说 ChatGPT 的插件机制更适合纯后端的开发者，因为不需要额外书写前端界面。而我们的新插件机制，则可以实现更加丰富的交互模式，对前端开发者来说有更大的施展空间。

[arvinxx]

在 #356 中实施

[arvinxx]

standalone 类型的案例：「时钟插件」已上线插件市场。

clock.time.mp4

特点：不包含任何后端 API，纯前端实现。

插件仓库：https://github.com/lobehub/chat-plugin-clock-time

[arvinxx]

在这里讨论第二个问题： 触发 ai 请求的控制时机

在随着更多开发者接触到 LobeChat 的插件机制，我们收到了很多对于是否发送 ai 请求、如何控制发送 ai 请求等很多诉求。例如：

插件能自己或者控制agent输出一段md当成结果显示么？很多场景不需要写自定义 render ，一个模版 md 就可以解决结果输出的问题。比如我查现在北京几点，插件可以直接返回给我几点几分的对话信息，而不用再传给json给gpt。一些简单的展示也不需要写自定义render，而只需要有个模版 md

另外有没可能在lobechat里加一个强制限制调用function的配置，比如我设置为1的话，那么lobechat只调1次funcition call，无论gpt4后续返回的数据是否还包含function信息，都不要管他
—— #366 (comment)

上面有两个需求：

1. 新增一种md渲染方式。
2. 支持控制后续的响应逻辑

针对上述的诉求，我们在消息展示上，可以控制插件的显示内容，从无到完全自定义，总结下来有四类：

• 不显示插件消息，完全由 GPT 总结。适用于网页内容总结等场景；
• 只显示 markdown 模板，适用于结果很明确，不需要再发送给 GPT 的场景。例如： XXX 的负责人是谁？ 插件返回结果直接是人名，就不需要再做一次 AI 总结；
• 渲染自定义 render，适用于需要自定义前端展示的场景，但这种模式偏向纯展示，缺少复交互操作；
• 接入独立应用，完全由插件控制逻辑。适用于存在复杂交互的场景，也就是上一条讨论中所实现的场景；

在消息触发上，我们同样需要提供一个配置，运行插件控制接下来的消息模式。

• 自动模式，返回结果后，必然触发一次 AI 消息；
• 不触发，无论返回什么结果，都不触发 AI 消息（和 显示 markdown 模板搭配使用）。
• 程序化触发，通过一个 postMessage 来触发一次 AI 消息（和 postToFillPluginContent 功能不同）。
• 不触发 ai 消息，单纯将 content 作为 assistant 消息创建出来；

[arvinxx]

理论上来说，上述两类大需求满足后，我们就可以使用 LobeChat 的插件机制构建出所有复杂度的插件。

[arvinxx]

Markdown 插件实现：#865