Skip to main content

概述

AgentScope 的模型层由 API 凭证(Credential)和模型族组成。一个凭证对应一个 API(例如 OpenAI,Gemini,DashScope等),并对应该 API 下的若干模型族(LLM,TTS,Embedding,Realtime)。
Credential
ChatModelBase
OpenAIChatModel
AnthropicChatModel
DashScopeChatModel
...
TTSModelBase
OpenAITTSModel
DashScopeTTSModel
DashScopeRealtimeTTSModel
DashScopeCosyVoiceRealtimeTTSModel
RealtimeModelBase (coming soon)
Credential 承载某个提供商的 API 认证字段(api_keybase_url 等)。从一个凭证出发,可以列出该提供商在每个模型族下支持的全部可用模型。 这种分层与前端的自然交互流程一致 —— 先注册凭证,再从凭证下挑选模型 —— 让界面只需鉴权一次,就能展示该提供商支持的所有模型族。

Chat Model

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

创建 Chat Model

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

调用 Chat Model

通过传入一组 Msg 对象(以及可选的 toolstool_choice)调用模型:
返回类型取决于模型的 stream 设置:
  • stream=False —— 返回单个 ChatResponse,承载完整输出。
  • stream=True —— 返回 AsyncGenerator[ChatResponse, None]。中间 chunk(is_last=False)只携带增量内容;最后一个 chunk(is_last=True)承载完整的累积内容
如果运行中的模型调用被中断,模型层会返回一个最终 ChatResponse,其中包含已累积的部分内容,并将 finished_reason 设为 FinishedReason.INTERRUPTED;正常结束时为 FinishedReason.COMPLETED
一段典型的流式输出示例,展示「增量 → 累积」的模式:
每个 ChatResponse 包含若干 content block(TextBlockThinkingBlockToolCallBlockDataBlock)、一个 is_last 标志、一个 finished_reasonFinishedReason.COMPLETEDFinishedReason.INTERRUPTED),以及记录 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。基类现在负责重试、流式累积与中断处理,因此 _call_api 只需要把提供商返回结果转换为 AgentScope 的 ChatResponse chunk:
对自定义 ChatModel 子类而言,直接以 ChatResponse(content=..., is_last=False) 产出增量返回即可。如果 _call_api 结束时没有产出 is_last=True 的最终 chunk,ChatModelBase.__call__ 会通过 ChatResponse.append_chat_response() 自动累积这些增量并返回最终响应;如果流式过程被取消,则会返回带有部分累积内容且 finished_reason=FinishedReason.INTERRUPTED 的响应。

步骤 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 模型通用的构造参数: DashScopeRealtimeTTSModelDashScopeCosyVoiceTTSModel(实时模式)额外参数:

调用 TTS Model

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

实时 TTS(流式输入)

实时模型(DashScopeRealtimeTTSModelDashScopeCosyVoiceTTSModelrealtime=True))支持增量推送文本(典型场景:对接 LLM 的流式输出)。两者共享相同的 push() / synthesize() 接口。通过 async with 或手动调用 connect() / close() 管理生命周期:
DashScopeRealtimeTTSModel(Qwen3)以 token 级别粒度产出音频——每次 push() 通常都能返回音频数据。而 DashScopeCosyVoiceTTSModelrealtime=True)依赖 CosyVoice 服务端自动分句后才进行合成,音频只在检测到完整句子边界后才返回,因此 push() 对不完整的句子可能返回空响应。调用 synthesize() 会强制合成所有剩余文本(包括未完成的句子)。

与 Agent 集成

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

TTS Model Card

TTSModelCard 描述 TTS 模型的能力(可用音色、流式支持、参数范围),用于驱动前端模型选择器。每个 card 由模型实现旁的 YAML 文件定义:
OpenAI TTS-1
Qwen3 TTS
CosyVoice
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。