cc @jiangsier-xyz

如果我们在LanguageModel中添加一个可选方法，例如：

default Response<TextSegment> generateTextSegment(String prompt) {
    return Response.from(TextSegment.from(generate(prompt).content()));
}

通过重写此方法，模型可以在需要时在响应中包含任何其他元数据。

如果你只想使用 TextSegment 来包含元数据，我建议将类似 Map<String, String> metadata 的内容添加到 Response 类中，因为它被设计成可以扩展这样的功能。这样每个集成都可以将自定义的 LLM-provider-specific 字段放入该Map中。

另一个选择是在 Response<Content, Metadata> 类中添加第二个泛型参数，这样每个集成都可以提供一个自定义 POJO 而不是Map，类似于 Response<AiMessage, OpenAiMetadata>、Response<AiMessage, DashscopeMetadata> 等。但这对最终用户来说感觉更复杂，尤其是考虑到这个功能可能不会经常使用。

另一种方法是使用第二种选项中的自定义 POJO,但在 Response 类中使用 Object metadata 或 Metadata metadata(通用标记接口),并强制用户根据提供者将其转换为实际类型。

如果你只想使用 TextSegment 来包含元数据，我建议将类似 Map<String, String> metadata 的内容添加到 Response 类中，因为它被设计成可以扩展这样的功能。然后每个集成都可以将自定义的 LLM-provider-specific 字段放入该Map中。
另一个选择是在 Response<Content, Metadata> 类中添加第二个通用参数，这样每个集成都可以提供一个自定义 POJO 而不是Map，如下所示：Response<AiMessage, OpenAiMetadata>、Response<AiMessage, DashscopeMetadata> 等。但这对最终用户来说感觉更复杂，尤其是考虑到这个功能可能不会经常使用。
另一种方法是使用第二种选项中的自定义 POJO,但在 Response 类中用 Object metadata 或 Metadata metadata(通用标记接口)替换泛型，并强制用户根据提供者将其转换为实际类型。
你建议 Model 实现类自己设计生成方法，还是让扩展机制在接口中统一设计？

使用上述方法，您无需更改模型的接口并添加新的 generate 方法。只需在已经由所有模型方法返回的 Response 中添加额外的 metadata 字段。

通过上述方法，您无需更改模型的接口并添加新的 generate 方法。只需在已经由所有模型方法返回的 Response 中添加额外的 metadata 字段即可。
哦，明白了。

通过上述方法，您无需更改模型的接口并添加新的 generate 方法。只需在已经由所有模型方法返回的 Response 中添加额外的 metadata 字段即可。
明白了。
感谢各位，期待新版本的这个功能。