深入解析 Continue 的 continuedev/llm-info模型元数据、能力声明与两步新增模型机制【免费下载链接】continueopen-source coding agent项目地址: https://gitcode.com/GitHub_Trending/co/continue导读continuedev/llm-info是 Continueopen-source coding agent中负责描述大语言模型的轻量级核心包它统一承载了模型模板Templates、能力声明Capabilities如工具调用、图片输入、流式输出、预测输出等以及模型别名Model aliases三部分信息与负责API 类型翻译的continuedev/openai-adapters形成明确分工。读完本文你将掌握LlmInfo与ModelProvider两大核心数据结构的字段语义、findLlmInfo与getAllRecommendedFor的底层匹配逻辑、当前 16 个内置 Provider 的组织方式并理解编辑一个 LlmInfo 对象 挂入 ModelProvider两步新增模型的设计目标与真实落地现状。一、包定位llm-info 与 openai-adapters 的职责边界continuedev/llm-info在 README.md 中自我定位为提供各类大语言模型LLM的信息包括 embedding嵌入、reranking重排以及其他模型。它与同为 Continue 生态的continuedev/openai-adapters的关系被明确区分关注点openai-adaptersllm-infoAPI 类型翻译负责在不同 API 协议之间做转换不涉及模板Templates—负责能力Capabilities—负责工具调用、图片、流式、预测输出等模型别名Model aliases—负责README 同时点明两者存在依赖方向openai-adapters在部分场景下可能会依赖llm-info提供的信息。因此llm-info 本质上是一份模型事实数据库——它不关心请求如何发出只关心某个模型是什么、能做什么、怎么配置。从包配置看package.json该包当前版本为1.0.10采用 ESM 模块type: module通过tsc构建为dist/index.js并导出dist/index.d.ts类型声明以continuedev/llm-info的形式被核心模块引用。二、核心类型体系LlmInfo 与 ModelProvider2.1 LlmInfo单个模型的信息单元LlmInfo在 src/types.ts 中定义是描述一个模型长什么样的基础结构export interface LlmInfo { model: string; // providers: string[]; // TODO: uncomment and deal with the consequences displayName?: string; description?: string; contextLength?: number; maxCompletionTokens?: number; regex?: RegExp; chatTemplate?: ChatTemplate; /** If not set, assumes text only */ mediaTypes?: MediaType[]; recommendedFor?: UseCase[]; /** Any additional parameters required to configure the model */ extraParameters?: Parameter[]; }各字段语义如下model必填模型的规范标识符例如gpt-4o、claude-sonnet-4-6。displayName展示给用户的名字例如GPT-4o、Claude Sonnet 4.6。description模型的自然语言描述常用于 UI 展示。例如 Anthropic 的claude-sonnet-4-6描述为 Anthropics latest and most capable Sonnet model with exceptional coding, reasoning, and multilingual performance.见 anthropic.ts。contextLength上下文窗口长度token 数是 Continue 计算 prompt 预算的关键依据见后文 BaseLLM 用法。maxCompletionTokens单次生成的最大补全 token 数。regex模型别名匹配正则。当用户输入的模型名与model字段不完全一致时通过正则进行模糊匹配详见 2.4 节匹配逻辑。chatTemplate聊天模板枚举当前在 types.ts 中仅有None none一个取值其余模板待实现源码中留有// TODO。mediaTypes模型支持的媒体类型。不设置时默认仅支持文本。枚举定义见 types.tsText、Image、Audio、Video并提供了便捷常量AllMediaTypes四者全含。Gemini 系列模型普遍设置mediaTypes: AllMediaTypes见 gemini.ts。recommendedFor推荐使用场景取值为UseCase联合类型chat | autocomplete | rerank | embed见 types.ts。例如 embedding 模型models/text-embedding-004标记为recommendedFor: [embed]多数对话模型标记为[chat]。extraParameters配置该模型所需的附加参数类型为Parameter[]。其中Parameter结构types.ts定义了附加配置项的形态export interface Parameter { key: string; required: boolean; valueType: ParameterType; // string | number | boolean displayName?: string; description?: string; defaultValue?: any; }此外还有一个派生类型LlmInfoWithProvider LlmInfo { provider: string }用于在模型信息上再附加所属 Provider 标识types.ts。2.2 ModelProvider一组模型的容器ModelProvidertypes.ts描述某个 Provider 支持哪些模型export interface ModelProvider { id: string; displayName: string; // capabilities: ModelProviderCapability[]; // TODO: uncomment and deal with the consequences models: OmitLlmInfo, provider[]; extraParameters?: Parameter[]; }idProvider 的唯一标识如openai、anthropic、gemini、ollama。displayName展示名如OpenAI、Anthropic。models该 Provider 支持的全部模型列表。由于LlmInfo的provider字段仍处于注释状态源码// providers: string[]; // TODO模型通过挂在 Provider 的models数组上实现与 Provider 的绑定。extraParametersProvider 级别的附加配置参数。README 特别说明apiKey、apiBase以及model、provider被视为恒常存在不重复声明。类型中同样保留了未启用的ModelProviderCapability联合类型stream | fim | image | template_chat | tools见 types.ts指向未来按 Provider 声明能力的演进方向当前代码中以 TODO 注释挂起。2.3 为什么模型必须绑定 ProviderREADME 强调了一个关键设计点模型必须与 Provider 绑定因为同一个模型在不同 Provider 下可能有不同的属性例如上下文长度。README 给出的实践原则是Define as much as possible in the base object, and then spread to update for the specific providers as needed.即在基础对象中尽可能多定义通用属性然后针对具体 Provider 通过展开spread覆盖差异项。这一原则在仓库中有实例佐证gpt-4o在 openai.ts 中声明contextLength: 128000并标记recommendedFor: [chat]而在 azure.ts 中gpt-4o被重新声明为contextLength: 128_000使用数字分隔符的等价写法gpt-4o-mini亦然。两个 Provider 对同一模型的上下文长度认知保持一致但未来若出现差异即可通过 Provider 内的覆盖实现。2.4 匹配逻辑findLlmInfo 的别名解析机制模型别名解析的核心实现在 src/index.ts 的findLlmInfo函数export function findLlmInfo( model: string, preferProviderId?: string, ): LlmInfoWithProvider | undefined { if (preferProviderId) { const provider allModelProviders.find((p) p.id preferProviderId); const info provider?.models.find((llm) llm.regex ? llm.regex.test(model) : llm.model model, ); if (info) { return { ...info, provider: preferProviderId, }; } } return allLlms.find((llm) llm.regex ? llm.regex.test(model) : llm.model model, ); }其匹配策略包含三个要点优先 Provider 限定若传入preferProviderId先在对应 Provider 的模型列表中查找命中则返回带该 Provider 标识的LlmInfoWithProvider。regex 优先于精确匹配对每个模型若定义了regex则用正则测试模型名否则回退到llm.model model的精确比较。这实现了模型别名能力——例如 Anthropic 的claude-sonnet-4-6定义regex: /claude-(?:4[.-]6-sonnet|sonnet-4[.-]6).*/i因此claude-4-6-sonnet、claude-sonnet-4-6等书写形式都能命中同一条信息。全量兜底未指定 Provider 或 Provider 内未命中时遍历allLlms所有 Provider 模型扁平化后的全集再次匹配。值得注意的细节是 regex 与匹配顺序的耦合在 anthropic.ts 中有一行注释// order matters for regex conflicts并刻意将claude-opus-4.1的条目放在claude-opus-4之前——因为claude-opus-4的正则/claude-(?:4-opus|opus-4).*/i可能误吞claude-opus-4.1数组顺序保证了更具体的正则先被命中。这是维护模型条目时必须遵守的隐性规则。2.5 聚合导出allModelProviders 与 allLlmssrc/index.ts 提供两个聚合导出allModelProviders当前全部 16 个 Provider 的数组包括OpenAi、Gemini、Anthropic、Mistral、Voyage、Azure、Ollama、Vllm、Bedrock、Cohere、CometAPI、Inception、MiniMax、xAI、zAI另有os.ts中的本地模型集合被 Ollama 复用。新增 Provider 时需在此登记。allLlms通过flatMap将所有 Provider 的模型展开并附加provider字段形成LlmInfoWithProvider[]全量扁平列表。另有getAllRecommendedFor(useCase)src/index.ts按UseCase过滤出推荐模型例如getAllRecommendedFor(embed)会返回所有标记了recommendedFor: [embed]的 embedding 模型。三、内置 Provider 与模型数据的组织方式3.1 目录组织现状README 描述的目标结构是模型定义在models目录、Provider 定义在providers目录但从当前仓库的实际布局看模型定义已直接内联在各 Provider 文件中位于 packages/llm-info/src/providers 目录每个文件导出一个ModelProvider常量例如openai.tsGPT-3.5/GPT-4/GPT-4o/GPT-4.1/GPT-5/o 系列与text-embedding-*系列覆盖 chat 与 embed 两类 UseCase。anthropic.ts从claude-instant-1.2到claude-sonnet-4-6/claude-opus-4-6的完整 Claude 谱系。gemini.tsGemini 3.1 / 3 / 2.5 / 2.0 系列普遍声明mediaTypes: AllMediaTypes并附注官方文档中的弃用时间线如 Gemini 2.5 series (deprecating June 17, 2026)。azure.ts声明extraParameters: []展示 Provider 级附加参数的写法。ollama.ts直接复用 os.ts 导出的OsLlms当前仅含starcoder2:3bcontextLength: 8192演示了模型数组跨 Provider 复用的模式。3.2 一个完整的 Provider 定义示例以 OpenAI 为例openai.ts一条模型条目通常包含{ model: gpt-5.1, displayName: GPT-5.1, contextLength: 400000, maxCompletionTokens: 128000, regex: /^gpt-5\.1$/, recommendedFor: [chat], }可以看到模型条目充分利用了regex做精确别名锚定/^gpt-5\.1$/不会误匹配gpt-5.1-mini之类的变体同时为不同模型族gpt-4.1 系列、gpt-5 系列、o 系列、codex 系列标注了各自独立的上下文与最大输出长度。这印证了 README 中模型分组可依据语义自由组织的说明——同一 Provider 内部按系列分组排列便于维护。四、llm-info 在 Continue 中的实际消费点README 的 Where to use llm-info 章节列出了三个消费方向其中部分已在当前仓库落地4.1 BaseLLM 构造函数运行时自动检测模型参数已落地在 core/llm/index.ts 中BaseLLM构造函数通过findLlmInfo实现参数自动检测// Use continuedev/llm-info package to autodetect certain parameters const llmInfo findLlmInfo(this.model, this.underlyingProviderName); // ... this._contextLength options.contextLength ?? llmInfo?.contextLength; this.completionOptions { ...options.completionOptions, model: options.model || gpt-4, maxTokens: options.completionOptions?.maxTokens ?? (llmInfo?.maxCompletionTokens ? Math.min( llmInfo.maxCompletionTokens, // Even if the model has a large maxTokens, we dont want to use that every time, // because it takes away from the context length this.contextLength / 4, ) : DEFAULT_MAX_TOKENS), };这一实现揭示了 llm-info 的运行时价值上下文长度兜底用户未显式配置contextLength时直接采用 llm-info 中登记的llmInfo.contextLength。最大输出 token 的防御性钳制即使模型支持很大的maxCompletionTokens如 128000也取min(maxCompletionTokens, contextLength / 4)作为默认值——代码注释明确解释原因过大的 maxTokens 会挤占上下文预算。Provider 感知findLlmInfo的第二参传入this.underlyingProviderName让检测优先在当前 Provider 范围内进行。4.2 测试与工具代码中的消费已落地core/llm/index.test.ts 直接导入allModelProviders对全部 Provider 执行遍历式测试说明 llm-info 聚合数据是核心层单元测试的输入源。core/llm/llms/CometAPI.ts 通过allModelProviders.find((p) p.id cometapi)按 id 精确取回 Provider 数据演示了按 id 索引 Provider的典型用法。4.3 尚未完全落地的两个方向README 还列出了两个演进方向从仓库现状看仍未完全替换替换core/llm/autodetect.ts该文件autodetect.ts仍保留独立的模型能力检测逻辑如modelSupportsImages、modelSupportsReasoning等基于字符串/正则的推断函数说明 llm-info 尚未全面接管 autodetect 职责。替换gui/pages/AddNewModel/configs/[providers/models].ts经检索 GUI 目录未发现该路径下的对应文件表明 GUI 侧添加新模型配置页的数据源迁移也未完成。因此用 llm-info 替换 autodetect、并在所有相关位置统一使用 llm-info仍是 README 标注的进行中工作。五、设计目标两步新增一个模型README 用一句话定义了 llm-info 的完成标准Done criteriaWe know we are done when the steps required to add support for a new model in Continue are exactlyediting a single LlmInfo object, andadding it to the supporting ModelProviders.即在 Continue 中为某个新模型添加支持只需1编辑一个 LlmInfo 对象2将其加入支持的 ModelProvider——仅此两步。对照当前仓库这套流程的操作形态如下在对应 Provider 文件如 openai.ts 或 anthropic.ts中新增/编辑一个LlmInfo对象填充model、displayName、contextLength、maxCompletionTokens、recommendedFor等字段若模型存在命名变体补一个regex字段即可获得别名匹配能力。将该对象加入目标 Provider 的models数组若是一个全新厂商还需新建 Provider 文件并在 src/index.ts 的allModelProviders数组中登记注意第 3.2 节提到的 regex 冲突时的顺序规则。从模型必须挂在 Provider 下、且可针对 Provider 覆盖属性的设计来看两步走的目标是让模型元数据成为单一事实来源运行时通过findLlmInfo自动推导上下文长度与最大输出 tokenUI 通过displayName/recommendedFor/extraParameters渲染配置表单测试通过allModelProviders覆盖全部条目——而这一切都源自集中式的 LlmInfo 数据这正是该包存在的意义。六、小结continuedev/llm-info用两个核心接口LlmInfoModelProvider外加三个查询函数findLlmInfo、getAllRecommendedFor、allLlms聚合把 Continue 的模型事实层从各处硬编码的字符串判断收敛为可枚举、可测试、可自动检测的数据表。对使用者而言查询模型能力看findLlmInfo扩展模型看 Provider 文件与allModelProviders登记表理解模型差异看regex与按 Provider 覆盖的contextLength。其两步新增模型的设计目标与 BaseLLM 中的自动检测实现共同构成了 Continue 模型接入层配置驱动、数据优先的底层范式。【免费下载链接】continueopen-source coding agent项目地址: https://gitcode.com/GitHub_Trending/co/continue创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考