`useXChat` 使用方式

[zpc7]

需求动机

使用 useXChat 时发现有些地方对个人有点反直觉, 想一块探讨一下?

不传 agent 参数时候的使用

观察到给出的3个 demo 中都使用到了useXAgent 产生的agent, 但是看 API 文档这个参数不是必须的, 能够给一个不使用 agent 的demo?
如果不搭配agent使用的话, 跟自己使用useState管理的话有哪些差别呢?

使用 agent 参数时候, 调用 onRequest传递给agent的参数format

interface YourMessageType {
  role: string;
  content: string;
}

const [agent] = useXAgent<YourMessageType>({
    baseURL: BASE_URL,
    model: MODEL,
    dangerouslyApiKey: API_KEY,
  });
  const { onRequest, messages } = useXChat({
    agent,
  });

  function request(message) {
    onRequest({
      role: 'user',
      content: message,
    });
  }

我想要最大程度的简化使用方式, 但是这里实际发出的请求的payload其实是:

参见源码位置:https://github.com/ant-design/x/blob/main/components/useXChat/index.ts#L197-L198

是否能在某些地方提供 tramsform的口子呢, 而不是采用默认的message和messages的方式(不想完全再自定义useXAgenet的request方法)?

BTW: 我从discussion转成issue, 是否需要删除discussion..

提议的 API 是什么样的？

No response

[YumoImer]

观察到给出的3个 demo 中都使用到了useXAgent 产生的agent, 但是看 API 文档这个参数不是必须的, 能够给一个不使用 agent 的demo?

这个可以。

[YumoImer]

如果不搭配agent使用的话, 跟自己使用useState管理的话有哪些差别呢?

有了你提议的 demo 示例后，这个问题就有答案了。

[YumoImer]

是否能在某些地方提供 tramsform的口子呢, 而不是采用默认的message和messages的方式(不想完全再自定义useXAgenet的request方法)?

你提议的 API 是什么样的，可以详细说一下。

[YumoImer]

BTW: 我从discussion转成issue, 是否需要删除discussion..

不好意思，之前我映像中回复了 discussion ... 但看起来是我丢包了，抱歉。保留一个即可。

[zpc7]

是否能在某些地方提供 tramsform的口子呢, 而不是采用默认的message和messages的方式(不想完全再自定义useXAgenet的request方法)?

你提议的 API 是什么样的，可以详细说一下。

@YumoImer Hi, 大概这样
将请求的 payload 从默认的

{
message: YourMessageType,
messages:YourMessageType[]
}

变成可以自定义payload, 例如:

type YourMessageType = String

const [agent] = useXAgent<YourMessageType>({
  baseURL: BASE_URL,
  model: MODEL,
  dangerouslyApiKey: API_KEY,
});
const { onRequest, messages } = useXChat({
  agent,
  transform(message: YourMessageType, messages) {
    // payload 就是这个返回的这个对象
    return {
      messages: messages.map(item => ({
        role: item.role,
        message: item.content,
      }))
    };
  }
});

function request(message) {
  onRequest(message);
}

[YumoImer]

@YumoImer Hi, 大概这样 将请求的 payload 从默认的 ...

我理了一下，发出一个预设请求的调用链是这样的：

useXChat -> useXAgent -> XRequest

从定位上，useXChat 更关注数据管理，与模型推理服务的网络请求应该是 useXAgent 关注的事情。

所以感觉这个事情对 useXAgent 的 API 进行扩展更合适些。你觉得如何？

[zpc7]

@YumoImer Hi, 大概这样 将请求的 payload 从默认的 ...

我理了一下，发出一个预设请求的调用链是这样的：

useXChat -> useXAgent -> XRequest

从定位上，useXChat 更关注数据管理，与模型推理服务的网络请求应该是 useXAgent 关注的事情。

所以感觉这个事情对 useXAgent 的 API 进行扩展更合适些。你觉得如何？

确实也是, 可以放在 useXAgent 更为合适,
但是我并不想通过重新实现 useXAgent的request方法
来完成这个仅仅是payload转换的自定义需求

[YumoImer]

@YumoImer Hi, 大概这样 将请求的 payload 从默认的 ...

我理了一下，发出一个预设请求的调用链是这样的：
useXChat -> useXAgent -> XRequest
从定位上，useXChat 更关注数据管理，与模型推理服务的网络请求应该是 useXAgent 关注的事情。
所以感觉这个事情对 useXAgent 的 API 进行扩展更合适些。你觉得如何？

确实也是, 可以放在 useXAgent 更为合适, 但是我并不想通过重新实现 useXAgent的request方法 来完成这个仅仅是payload转换的自定义需求

抱歉，可能我没表达清楚，我的建议是将「payload转换」这个需求对useXAgent进行扩展。暂时的想法是给 useXAgent 增加一个配置参数 onRequest

export interface XAgentConfigCustom<Message> {
  request?: RequestFn<Message>;
  /** 请求中间件 */
  onRequest?: (...ags: Parameters<typeof fetch>) => Promise<Parameters<typeof fetch>>;
}

[kimteayon]

1.2.0版本已经新增了transformMessage 和 transformStream 可供选择，同时开放了 onRequest 入参的类型