Skip to main content

概述

模型层采用两层结构:上层是 Credential,下层是该提供商支持的若干模型族 —— Chat ModelTTSEmbeddingRealtime Model
Credential
ChatModelBase
OpenAIChatModel
AnthropicChatModel
DashScopeChatModel
...
TTSModelBase
DashScopeTTSModel
DashScopeRealtimeTTSModel
RealtimeModelBase (coming soon)
Credential 承载某个提供商的 API 认证字段(api_keybase_url 等)。从一个凭证出发,可以列出该提供商在每个模型族下支持的全部可用模型。 这种分层与前端的自然交互流程一致 —— 先注册凭证,再从凭证下挑选模型 —— 让界面只需鉴权一次,就能展示该提供商支持的所有模型族。

Chat Model

Chat Model 是驱动 agent 对话与工具调用的 LLM,输入输出可以是文本之外的多模态内容。AgentScope 当前提供以下 Chat Model 类:

创建 Chat Model

每个 Chat Model 接收一个凭证、一个模型名,以及可选的提供商专属 Parameters 对象。下面三个 tab 分别展示流式、工具调用与推理三种典型初始化场景:
所有 Chat Model 共享的构造参数:

调用 Chat Model

通过传入一组 Msg 对象(以及可选的 toolstool_choice)调用模型:
返回类型取决于模型的 stream 设置:
  • stream=False —— 返回单个 ChatResponse,承载完整输出。
  • stream=True —— 返回 AsyncGenerator[ChatResponse, None]。中间 chunk(is_last=False)只携带本步生成的增量内容。为了让调用方无需自行累积增量,AgentScope 会在末尾追加一个 is_last=True 的 chunk,承载完整的累积内容
一段典型的流式输出示例,展示「增量 → 累积」的模式:
每个 ChatResponse 包含若干 content block(TextBlockThinkingBlockToolCallBlockDataBlock)、一个 is_last 标志,以及记录 token 数与耗时的 ChatUsage

生成结构化输出

当需要返回符合 Pydantic 模型或 JSON schema 的结构化结果时,调用 generate_structured_output 而非 __call__。它返回一个 StructuredResponse,其 content 是经过 schema 校验的 dict:
generate_structured_output 会基于 schema 合成一个强制工具调用,再对模型输出做校验与修复。

Formatter

Formatter 负责把 AgentScope 的 Msg 对象转换为各提供商 API 期望的 list[dict] 载荷。它通过 Chat Model 构造函数中可选的 formatter 参数配置。每个提供商内置两种 formatter: 切换到多 agent 模式只需传入 MultiAgent 变体,无需修改 agent 代码:
如果提供商的载荷格式不属于 OpenAI 或 Anthropic 风格,开发者可以继承 FormatterBase 实现自定义 formatter,并通过同一个 formatter 参数传入。

自定义 Provider

开发者可以通过实现一个 credential 与一个 chat model,并注册该 credential,把自定义模型提供商接入 AgentScope。

步骤 1:定义 Credential

继承 CredentialBase,使用唯一的 type 判别字段,并实现 get_chat_model_class()

步骤 2:实现 Chat Model

继承 ChatModelBase,定义内部 Parameters 类,并实现 _call_api

步骤 3:添加 Model Card(可选)

把 YAML 文件放在模型实现旁边的 _models/ 目录里。每个文件描述一个模型 —— 它的能力(input_typesoutput_types)、上限(context_sizeoutput_size),以及该模型专属的 parameter_overrides
MyProviderChatModel.list_models() 会加载该目录下的所有 YAML。如果想从其他位置(例如应用自己维护的模型注册表)拉取 Model Card,传入 custom_yaml_dir

前端集成

什么是 ModelCard

ModelCard 是对模型能力与约束的声明式描述,用于驱动前端 —— 模型选择器、参数表单、能力开关都可以基于它动态渲染,无需在前端硬编码任何提供商相关的逻辑。 每个 ModelCard 包含以下字段: input_typesoutput_types 都用 MIME 类型描述模态,常见取值如下: claude-sonnet-4-6 的典型 YAML:

参数 schema 与 override

暴露给前端的 parameter_schema 由两层叠加而成:
  1. 基础 schema —— 由 Chat Model 的 Parameters 类通过 model_json_schema() 自动生成,列出全部可调参数(temperaturemax_tokensthinking_enable 等),并给出类型与 API 通用范围。
  2. per-model override —— YAML 中的 parameter_overrides 块会按字段叠加在基础 schema 之上。
override 之所以重要,是因为同一个 API 下不同模型的可调范围并不一致:每个 Qwen 模型都接受 max_tokens,但上限各不相同。借助 override,Model Card 可以收紧某个范围、固定默认值,或隐藏某个不适用的参数。

获取 ModelCard

通过 credential 类或 model 类调用 list_models() 获取 Model Card。CredentialBase.list_models() 内部会委托到与之关联的 ChatModelBase 子类(通过 get_chat_model_class() 拿到),后者会从其 _models/ 目录加载 YAML。
get_chat_model_class() 返回对应的 ChatModelBase 子类,该子类知道如何定位它的 Model Card YAML:
这种设计让前端只需一个 credential,就能发现所有可用模型、它们的能力与合法参数范围 —— 无需任何硬编码的提供商逻辑。

TTS

TTS Model 将文本转换为合成语音音频,支持标准模式和实时(流式输入)合成模式。AgentScope 当前提供以下 TTS 模型类:

创建 TTS Model

每个 TTS Model 接收一个凭证、一个模型名,以及可选的提供商专属 Parameters 对象。下面两个 tab 分别展示标准和实时两种初始化场景:
所有 TTS 模型通用的构造参数: DashScopeRealtimeTTSModel 额外参数:

调用 TTS Model

通过 synthesize() 方法合成语音:
返回类型取决于 stream 设置:
  • stream=False — 返回单个 TTSResponse,包含完整音频。
  • stream=True — 返回 AsyncGenerator[TTSResponse, None],每个 chunk 携带增量音频 delta;最后一个 chunk 的 is_last=True
每个 TTSResponse 包含:

实时 TTS(流式输入)

实时模型(DashScopeRealtimeTTSModel)支持增量推送文本(典型场景:对接 LLM 的流式输出)。两者共享相同的 push() / synthesize() 接口。通过 async with 或手动调用 connect() / close() 管理生命周期:
DashScopeRealtimeTTSModel(Qwen3)以 token 级别粒度产出音频——每次 push() 通常都能返回音频数据。

与 Agent 集成

在 agent 层,TTS 通过 TTSMiddleware 集成 —— 自动拦截 agent 的文本输出并合成语音:
中间件根据 TTS 模式自动选择最优策略:

TTS Model Card

TTSModelCard 描述 TTS 模型的能力(可用音色、流式支持、参数范围),用于驱动前端模型选择器。每个 card 由模型实现旁的 YAML 文件定义:
Qwen3 TTS
voices 列表会自动注入 parameter_schemavoice 字段的 enum 约束,前端据此渲染下拉选择器。 获取 TTS 模型卡片:
或直接通过模型类:

自定义 TTS Provider

添加新的 TTS Provider,需实现 TTSModelBase 子类并在凭证上注册:

Embedding

Embedding Model 将文本(多模态模型还包括图片、视频等媒体)转换为稠密向量,支撑语义检索、RAG 与记忆召回。AgentScope 当前提供以下 Embedding 模型类:

创建 Embedding Model

每个 Embedding 模型接收一个凭证、一个模型名,以及可选的 Parameters 对象 —— 与 Chat Model 的模式完全一致。Parameters 承载 dimensions,即输出向量的维度:
所有 Embedding 模型共享的构造参数:
dimensions 的合法取值因模型而异 —— 每个 Model Card 通过 parameter_overrides 固定支持的 enum 与默认值(例如 text-embedding-v4 接受 2048 / 1536 / 1024 / … / 64)。参见 EmbeddingModelCard

调用 Embedding Model

通过传入一组输入调用模型。纯文本模型接受 list[str];多模态模型还接受 DataBlock 元素:
分批与重试由框架自动处理:
  1. 输入按模型的批大小切分(DashScope 文本为 10,OpenAI 为 2048,Gemini 为 100,Ollama 为 512)。
  2. 所有批次通过 asyncio.gather 并发发出。
  3. 每个批次在提供商专属的可重试错误下独立重试,最多 max_retries 次。
  4. 结果合并为单个 EmbeddingResponse,并保持输入顺序。
每个 EmbeddingResponse 包含:

多模态 Embedding

多模态模型(DashScopeEmbeddingModel 搭配 qwen3-vl-embedding 等,GeminiEmbeddingModel 搭配 gemini-embedding-2)在字符串之外还接受 DataBlock 输入 —— 图片支持 URL 或 base64,视频仅支持 URL:
多模态模型用内容感知分批取代简单的批大小切分:输入会按贪心策略打包,确保每个批次满足模型对总元素数、图片数、视频数的单次请求限制(例如 qwen3-vl-embedding 单次允许 20 个元素 / 5 张图片 / 1 个视频,tongyi-embedding-vision-plus 允许 20 / 64 / 8)。你无需自行拆分输入。

Embedding 缓存

通过 embedding_cache 参数传入一个 EmbeddingCacheBase 实现,即可复用已计算过的向量。内置的 FileEmbeddingCache 将每次结果存为 .npy 文件,以请求的 SHA-256 哈希命名:
当超过 max_file_numbermax_cache_size 时,最旧的文件会被优先淘汰。如需其他后端(Redis、SQLite 等),继承 EmbeddingCacheBase 并实现它的四个方法:storeretrieveremoveclear

自定义 Embedding 提供商

新增 Embedding 提供商的步骤与 Chat 提供商一致。

第一步:关联凭证

在你的凭证上重写 get_embedding_model_class()(基类默认返回 None,表示”不支持 Embedding”):

第二步:实现 Embedding Model

继承 EmbeddingModelBase 并实现 _call_api 处理单个批次 —— 分批、并发与重试逻辑全部继承自基类。通过 _get_retryable_exceptions 声明提供商专属的瞬态错误:
按提供商支持的输入类型绑定泛型参数:纯文本用 EmbeddingModelBase[str],多模态用 EmbeddingModelBase[str | DataBlock] —— IDE 会据此为调用方提示正确的 inputs 类型。

第三步:添加 Model Card(可选)

将 YAML 文件放入实现旁边的 _models/ 目录,MyProviderEmbeddingModel.list_models() 即可加载 —— 与 Chat Model Card 完全一致。

EmbeddingModelCard

EmbeddingModelCard 是面向前端的 ModelCard 对应物,带有 Embedding 专属的默认值 —— 输出类型 application/x-embedding 表示该模型产出稠密向量: 典型的 YAML 卡片:
可以直接在模型类上获取卡片,也可以通过凭证的 get_embedding_model_class() 发现模型类:

Realtime Model

即将上线 —— Realtime Model 支持正在从 v1.0 迁移到 v2.0。