拓冰网站定制 
Open Interpreter 模型体系完全指南模型元数据来源、推理控制、harness 默认值与本地开源模型接入【免费下载链接】openinterpreterA coding agent for open models like Kimi K3 and GLM 5.3项目地址: https://gitcode.com/GitHub_Trending/op/openinterpreterdocs/zh/models.md是 Open Interpreter本仓库面向 Kimi K3、GLM 5.3 等开放模型的编码代理中关于「模型」机制的核心指南。它以/model交互为入口讲清了模型列表从哪来、元数据能控制什么、推理与输入模式如何在协议层建模以及如何接入 Ollama / LM Studio 本地开源模型。读完本文你将能在交互界面、Shell 参数与 TOML 配置三个层面精确选择并提供者无关的推理、多模态与 harness 控制并能读懂仓库中的元数据目录与源码实现。从/model开始提供商、模型与 harness 的三层分离在终端启动 Open Interpreter 后输入/model即可打开模型选择器在一处完成三层选择提供商provider决定请求发往何处、如何认证模型model发送到该端点的具体模型 IDharness工具链决定面向代理的提示、工具与消息行为。选择器同时暴露「模型特定控制」model-specific controls例如推理档位、思考开关等。会话页脚footer会持续显示当前生效的模型选择方便随时核对。如果系统已为某个模型系列自动配置了默认 harness你也可以用/harness检查并覆盖它。排查问题时务必保持「提供商 / 模型 / harness」三层分离的思维提供商管端点与凭证、模型管要发送的 ID、harness 管请求格式与提示工程。更完整的提供商配置请见 模型提供商指南。Shell 覆盖一条命令完成模型指定在非交互场景Open Interpreter 提供-m与--oss两组快速参数interpreter -m gpt-5.1-codex review this module interpreter --oss use my local open source provider这些参数在源码中定义于 共享 CLI 参数结构体可供交互式与非交互式入口共用-m, --model MODEL指定代理使用的模型 ID--oss切换为开源提供商本地 OSS 模式--local-provider PROVIDER配合--oss指定本地提供者lmstudio或ollama未指定时回退到配置默认或弹出选择器-i, --image FILE向初始提示附加一张或多张图片逗号分隔num_args 1..允许多张。-m的取值即选择器内展示的模型 ID两者保持一致便于把交互中确认的模型固化到脚本里。配置默认值TOML 中固化你的模型偏好以下 TOML 片段来自文档示例用于在配置文件中固化默认模型行为model_provider openai model gpt-5.1-codex model_reasoning_effort medium model_reasoning_summary auto model_verbosity medium各字段在 配置结构定义 中都有对应的强类型字段与注释含义如下配置项作用取值/默认model_provider默认提供商 ID任意已配置提供商model默认模型 ID如gpt-5.1-codexmodel_reasoning_effort默认推理努力档位minimal/low/medium/high/xhighmodel_reasoning_summary推理摘要交付方式auto/concise/detailed/nonemodel_verbosity输出详细程度GPT-5 系列 Responses API 的text.verbositylow/medium/high源码中还有两个相关但未出现在示例中的字段值得注意plan_mode_reasoning_effortconfig_toml.rs专门为 plan 模式单独设置的推理档位model_supports_reasoning_summariesconfig_toml.rs强制启用当前模型的推理摘要支持。值得说明的是ReasoningSummaryauto/concise/detailed/none与Verbositylow/medium/high都是在 协议配置类型 中定义的枚举序列化时统一使用小写以与 OpenAI API 对齐——配置文件中写auto、medium与协议层 wire 值完全一致。模型元数据的来源分层数据而非手写清单Open Interpreter 并没有维护一份手写全部模型 ID 的 Rust 列表而是采用分层元数据策略多个来源按角色各司其职SourceRoleProvider/modelsendpoint在端点可用时获取活动提供者的实时模型 ID。model-provider-info/provider_catalog.json由models.dev生成并结合已配置的实时提供者模型来源的捆绑 provider/model 种子数据。codex-api/model_compatibility_catalog.json兼容性元数据如支持的参数、搜索支持、推理等级和输入模式。models-manager/models.json管理器使用的 OpenAI 风格模型预设元数据。Configmodel_catalog可选的用户提供的静态目录用于特定提供者/会话。这些文件在仓库中的真实路径分别为 provider_catalog.json、model_compatibility_catalog.json 与 models.json用户自定义的静态目录则通过配置键model_catalog_jsonconfig_toml.rs指向一个 JSON 文件路径仅在本进程启动时应用一次。模型管理器model manager的实际工作方式是先向活动提供者请求模型列表再在能够通过 Anthropic 身份、基础 URL、提供者名称或认证环境变量识别提供者时使用捆绑数据补充或种子化结果。这一点很关键——它意味着即使用户把请求指向某个代理proxy或网关只要代理明确指向一个已知提供者Open Interpreter 依然能让模型条目继承有用的元数据而不是降级为裸 ID 列表。捆绑模型条目在无更精确来源时如何兜底可以看 provider_catalog_models.rs 的实现它会以模型 ID 作为 slug 建立 fallback 条目若模型声明了reasoning或thinking_toggle则把default_reasoning_level设为medium若模型支持思考开关则把reasoning_control标记为ThinkingToggle。能力元数据一条模型记录到底能控制什么元数据不只是「名字 上下文长度」一条完整的模型条目可以控制以下能力面选择器可见性picker visibility是否在/model中展示显示名称与描述上下文窗口context window输入模式如文本和图像模型是否受 API 支持supported_in_api支持的请求参数推理控制形态reasoning control shape网页 / 搜索支持并行工具调用支持。从源码结构看这些字段会在模型管理器中聚合为ModelInfo结构如 provider_catalog_models.rs 中ModelVisibility::List、ReasoningEffort::Medium等赋值并被选择器、会话启动与请求序列化阶段共同消费。可以推断选型器里看到的优先级排序、搜索开关、是否能调图像都来自这条聚合后的模型元数据而非运行时临时探测。推理从「单一布尔值」到五种控制形态在 UI 与协议层推理都不是单一的布尔值。Open Interpreter 协议定义了五种推理控制形态见 ReasoningControl 枚举ControlMeaningnone无已知推理控制。fixed模型会推理但 UI 不应暴露控制。effortOpenAI 风格的努力控制。thinking_toggle布尔型思考开/关控制。thinking_budget令牌预算思考控制。也就是说同样是「会思考的模型」有的应当给用户一个低/中/高档位选择器有的只该给开关有的干脆由系统固定推理、不需要暴露任何 UI——协议通过reasoning_control区分这些情况。推理努力档位与 harness 映射当模型暴露的是effort控制时Open Interpreter 统一使用以下五档取值值用途minimal快速、简单的编辑。low常规实现。medium默认的平衡工作。high硬核调试、重构、审查。xhigh模型特定的额外推理。这五档直接对应协议层 ReasoningEffort 枚举 中Minimal/Low/Medium/High/XHigh的 wire 值as_str()输出小写minimal…xhigh。协议还额外预留了None、Max、Ultra以及Custom(String)用于客户端尚不认识的模型自定义档位例如 thinking-toggle 模型把Thinking作为开启选项见 openai_models.rs。这些档位并不会被原样发给所有服务商。不同的 harness 会把它们映射到提供者特定字段。文档给出的实例是kimi-cli将minimal与low映射为低推理medium映射为中等high或xhigh映射为高。因此你在选择器里看到的五档 UI 是统一的落到各提供商请求体里的字段却可能截然不同。对于不暴露推理控制的模型Open Interpreter 会根据提供者行为选择隐藏、忽略或拒绝推理控制——这既防止向不支持的端点发送无效参数也解释了为什么某些模型在选择器里看不到推理档位。输入模式text、image 与老负载的兼容默认规范的输入模式标签定义在 InputModality 枚举协议层已预留text、image、audio三种值含义text正常的用户回合和工具负载。image通过-i等命令附加的图像。附加图像的实际命令为interpreter -i screenshot.png what is wrong here?-i参数在 shared_options.rs 中定义为可重复、逗号分隔的多值参数因此一条命令可同时携带多张图片。需要注意向后兼容策略省略模式元数据的旧式负载legacy payload会保守地默认支持文本和图像以免老请求被新模型拒绝而由目录生成器产出的新 provider 条目则应在已知时注明真实模式如仅文本的模型就只标text。本地开源模型Ollama 与 LM StudioOpen Interpreter 内置了两个本地开源OSS提供商无需任何 API 密钥提供商默认基础 URL覆盖方式ollamahttp://localhost:11434/v1CODEX_OSS_PORT或CODEX_OSS_BASE_URLlmstudiohttp://localhost:1234/v1CODEX_OSS_PORT或CODEX_OSS_BASE_URL这两个内置提供者的基础 URL 拼接逻辑可以在 create_oss_provider 实现 中看到先用CODEX_OSS_PORT拼出http://localhost:{port}/v1若CODEX_OSS_BASE_URL存在则整体覆盖。代码注释明确标注这些CODEX_OSS_*环境变量目前是实验性的。使用流程是先启动本地服务再启动 Open Interpreter 并直接指定提供者interpreter --oss --local-provider ollama interpreter --oss --local-provider lmstudio不带--local-provider的--oss会使用你已保存的oss_provider配置配置键见 config_toml.rs其取值在校验函数中只接受lmstudio、ollama两个内置 ID见 validate_oss_provider若未保存则弹出选择器逐个探测默认本地端点是否有响应。若本地服务器位于其他主机或端口需在启动 Open Interpreter 前设置完整的、兼容 OpenAI 的/v1基础 URLCODEX_OSS_BASE_URLhttp://192.168.1.20:1234/v1 \ interpreter --oss --local-provider lmstudio -m qwen/qwen3-coder-next针对远程 Ollama 服务器同样使用--local-provider ollama。文档特别强调一条使用纪律不要仅仅为了更改任一内置本地提供者的地址而创建单独的model_providers条目——CODEX_OSS_BASE_URL才是受支持的覆盖方式自己包一层 provider 反而会绕开内置端点的特殊处理逻辑。模型元数据警告输出中出现Model metadata for ... not found时表示本地服务器返回的模型 ID 未出现在 Open Interpreter 的兼容性目录中——它本身并不代表服务器连接失败。正确的处理路径是确认服务器真实暴露的准确模型 ID用该 ID 原样通过-m传入更新 Open Interpreter 以获得最新的兼容性目录。Open Interpreter 可以继续使用回退元数据运行fallback 逻辑见 provider_catalog_models.rs但部分模型特定的控制或行为如推理档位、思考开关可能不可用。提供者系列与 Harness 默认值某些模型系列在未显式指定 harness 时会从模型/提供商系列自动推导出默认 harness模型/提供商系列默认 harnessClaude/Anthropic/Messagesclaude-codeKimi/Moonshotkimi-codeQwen/QwQ/DashScopeqwen-codeDeepSeekclaude-code-bare选择逻辑从「匹配条件」推导默认 harness详见 模型提供商指南中的默认 harness 选择命中 Anthropic/Messages wire API 或claude系列 ID 走claude-code命中 Kimi/Moonshot 相关名称或域名走kimi-code命中 Qwen/QwQ/DashScope 走qwen-code命中 DeepSeek 走claude-code-bare。因此文档表格里的四行本质上覆盖了当前主流开源编码模型的 wire-api 形态Anthropic Messages 原生协议的模型 →claude-codeKimi / Moonshot 平台 →kimi-code阿里云 DashScope 生态的 Qwen 系 →qwen-codeDeepSeek 需要 Anthropic 兼容请求但无复杂工具行为 →claude-code-bare。如果默认推导不符合你的预期可在配置中用harness ...显式覆盖。各 provider 的详细认证与推荐模型路径可分别参考 Kimi K3 指南、DeepSeek 指南 与 Z.AI / GLM 指南wire API 兼容性矩阵见 Harness 文档。小结模型能力的完整闭环把以上几节串起来Open Interpreter 的模型体系是一条完整的「元数据 → 选择器 → 配置 → 请求」链路目录provider_catalog.json提供模型种子兼容性目录model_compatibility_catalog.json提供推理与多模态能力注解管理器优先用提供者实时/models端点刷新、再按提供者特征匹配捆绑数据做增强最终在/model选择器、页脚、-m与 TOML 默认值中统一呈现。推理控制以ReasoningControl五种形态建模、以五档努力值为统一 UI、由 harness 负责映射到提供者字段输入模式用规范的InputModality标签描述并为老负载保留文本图像的兼容默认。理解了这层分层与聚合逻辑无论是接入本地 Ollama/LM Studio、调试「元数据未找到」警告还是在不同模型之间评估推理与多模态能力都能直接定位到仓库中对应的源码与数据文件。【免费下载链接】openinterpreterA coding agent for open models like Kimi K3 and GLM 5.3项目地址: https://gitcode.com/GitHub_Trending/op/openinterpreter创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Open Interpreter 模型体系完全指南：模型元数据来源、推理控制、harness 默认值与本地开源模型接入
Open Interpreter 模型体系完全指南模型元数据来源、推理控制、harness 默认值与本地开源模型接入【免费下载链接】openinterpreterA coding agent for open models like Kimi K3 and GLM 5.3项目地址: https://gitcode.com/GitHub_Trending/op/openinterpreterdocs/zh/models.md是 Open Interpreter本仓库面向 Kimi K3、GLM 5.3 等开放模型的编码代理中关于「模型」机制的核心指南。它以/model交互为入口讲清了模型列表从哪来、元数据能控制什么、推理与输入模式如何在协议层建模以及如何接入 Ollama / LM Studio 本地开源模型。读完本文你将能在交互界面、Shell 参数与 TOML 配置三个层面精确选择并提供者无关的推理、多模态与 harness 控制并能读懂仓库中的元数据目录与源码实现。从/model开始提供商、模型与 harness 的三层分离在终端启动 Open Interpreter 后输入/model即可打开模型选择器在一处完成三层选择提供商provider决定请求发往何处、如何认证模型model发送到该端点的具体模型 IDharness工具链决定面向代理的提示、工具与消息行为。选择器同时暴露「模型特定控制」model-specific controls例如推理档位、思考开关等。会话页脚footer会持续显示当前生效的模型选择方便随时核对。如果系统已为某个模型系列自动配置了默认 harness你也可以用/harness检查并覆盖它。排查问题时务必保持「提供商 / 模型 / harness」三层分离的思维提供商管端点与凭证、模型管要发送的 ID、harness 管请求格式与提示工程。更完整的提供商配置请见 模型提供商指南。Shell 覆盖一条命令完成模型指定在非交互场景Open Interpreter 提供-m与--oss两组快速参数interpreter -m gpt-5.1-codex review this module interpreter --oss use my local open source provider这些参数在源码中定义于 共享 CLI 参数结构体可供交互式与非交互式入口共用-m, --model MODEL指定代理使用的模型 ID--oss切换为开源提供商本地 OSS 模式--local-provider PROVIDER配合--oss指定本地提供者lmstudio或ollama未指定时回退到配置默认或弹出选择器-i, --image FILE向初始提示附加一张或多张图片逗号分隔num_args 1..允许多张。-m的取值即选择器内展示的模型 ID两者保持一致便于把交互中确认的模型固化到脚本里。配置默认值TOML 中固化你的模型偏好以下 TOML 片段来自文档示例用于在配置文件中固化默认模型行为model_provider openai model gpt-5.1-codex model_reasoning_effort medium model_reasoning_summary auto model_verbosity medium各字段在 配置结构定义 中都有对应的强类型字段与注释含义如下配置项作用取值/默认model_provider默认提供商 ID任意已配置提供商model默认模型 ID如gpt-5.1-codexmodel_reasoning_effort默认推理努力档位minimal/low/medium/high/xhighmodel_reasoning_summary推理摘要交付方式auto/concise/detailed/nonemodel_verbosity输出详细程度GPT-5 系列 Responses API 的text.verbositylow/medium/high源码中还有两个相关但未出现在示例中的字段值得注意plan_mode_reasoning_effortconfig_toml.rs专门为 plan 模式单独设置的推理档位model_supports_reasoning_summariesconfig_toml.rs强制启用当前模型的推理摘要支持。值得说明的是ReasoningSummaryauto/concise/detailed/none与Verbositylow/medium/high都是在 协议配置类型 中定义的枚举序列化时统一使用小写以与 OpenAI API 对齐——配置文件中写auto、medium与协议层 wire 值完全一致。模型元数据的来源分层数据而非手写清单Open Interpreter 并没有维护一份手写全部模型 ID 的 Rust 列表而是采用分层元数据策略多个来源按角色各司其职SourceRoleProvider/modelsendpoint在端点可用时获取活动提供者的实时模型 ID。model-provider-info/provider_catalog.json由models.dev生成并结合已配置的实时提供者模型来源的捆绑 provider/model 种子数据。codex-api/model_compatibility_catalog.json兼容性元数据如支持的参数、搜索支持、推理等级和输入模式。models-manager/models.json管理器使用的 OpenAI 风格模型预设元数据。Configmodel_catalog可选的用户提供的静态目录用于特定提供者/会话。这些文件在仓库中的真实路径分别为 provider_catalog.json、model_compatibility_catalog.json 与 models.json用户自定义的静态目录则通过配置键model_catalog_jsonconfig_toml.rs指向一个 JSON 文件路径仅在本进程启动时应用一次。模型管理器model manager的实际工作方式是先向活动提供者请求模型列表再在能够通过 Anthropic 身份、基础 URL、提供者名称或认证环境变量识别提供者时使用捆绑数据补充或种子化结果。这一点很关键——它意味着即使用户把请求指向某个代理proxy或网关只要代理明确指向一个已知提供者Open Interpreter 依然能让模型条目继承有用的元数据而不是降级为裸 ID 列表。捆绑模型条目在无更精确来源时如何兜底可以看 provider_catalog_models.rs 的实现它会以模型 ID 作为 slug 建立 fallback 条目若模型声明了reasoning或thinking_toggle则把default_reasoning_level设为medium若模型支持思考开关则把reasoning_control标记为ThinkingToggle。能力元数据一条模型记录到底能控制什么元数据不只是「名字 上下文长度」一条完整的模型条目可以控制以下能力面选择器可见性picker visibility是否在/model中展示显示名称与描述上下文窗口context window输入模式如文本和图像模型是否受 API 支持supported_in_api支持的请求参数推理控制形态reasoning control shape网页 / 搜索支持并行工具调用支持。从源码结构看这些字段会在模型管理器中聚合为ModelInfo结构如 provider_catalog_models.rs 中ModelVisibility::List、ReasoningEffort::Medium等赋值并被选择器、会话启动与请求序列化阶段共同消费。可以推断选型器里看到的优先级排序、搜索开关、是否能调图像都来自这条聚合后的模型元数据而非运行时临时探测。推理从「单一布尔值」到五种控制形态在 UI 与协议层推理都不是单一的布尔值。Open Interpreter 协议定义了五种推理控制形态见 ReasoningControl 枚举ControlMeaningnone无已知推理控制。fixed模型会推理但 UI 不应暴露控制。effortOpenAI 风格的努力控制。thinking_toggle布尔型思考开/关控制。thinking_budget令牌预算思考控制。也就是说同样是「会思考的模型」有的应当给用户一个低/中/高档位选择器有的只该给开关有的干脆由系统固定推理、不需要暴露任何 UI——协议通过reasoning_control区分这些情况。推理努力档位与 harness 映射当模型暴露的是effort控制时Open Interpreter 统一使用以下五档取值值用途minimal快速、简单的编辑。low常规实现。medium默认的平衡工作。high硬核调试、重构、审查。xhigh模型特定的额外推理。这五档直接对应协议层 ReasoningEffort 枚举 中Minimal/Low/Medium/High/XHigh的 wire 值as_str()输出小写minimal…xhigh。协议还额外预留了None、Max、Ultra以及Custom(String)用于客户端尚不认识的模型自定义档位例如 thinking-toggle 模型把Thinking作为开启选项见 openai_models.rs。这些档位并不会被原样发给所有服务商。不同的 harness 会把它们映射到提供者特定字段。文档给出的实例是kimi-cli将minimal与low映射为低推理medium映射为中等high或xhigh映射为高。因此你在选择器里看到的五档 UI 是统一的落到各提供商请求体里的字段却可能截然不同。对于不暴露推理控制的模型Open Interpreter 会根据提供者行为选择隐藏、忽略或拒绝推理控制——这既防止向不支持的端点发送无效参数也解释了为什么某些模型在选择器里看不到推理档位。输入模式text、image 与老负载的兼容默认规范的输入模式标签定义在 InputModality 枚举协议层已预留text、image、audio三种值含义text正常的用户回合和工具负载。image通过-i等命令附加的图像。附加图像的实际命令为interpreter -i screenshot.png what is wrong here?-i参数在 shared_options.rs 中定义为可重复、逗号分隔的多值参数因此一条命令可同时携带多张图片。需要注意向后兼容策略省略模式元数据的旧式负载legacy payload会保守地默认支持文本和图像以免老请求被新模型拒绝而由目录生成器产出的新 provider 条目则应在已知时注明真实模式如仅文本的模型就只标text。本地开源模型Ollama 与 LM StudioOpen Interpreter 内置了两个本地开源OSS提供商无需任何 API 密钥提供商默认基础 URL覆盖方式ollamahttp://localhost:11434/v1CODEX_OSS_PORT或CODEX_OSS_BASE_URLlmstudiohttp://localhost:1234/v1CODEX_OSS_PORT或CODEX_OSS_BASE_URL这两个内置提供者的基础 URL 拼接逻辑可以在 create_oss_provider 实现 中看到先用CODEX_OSS_PORT拼出http://localhost:{port}/v1若CODEX_OSS_BASE_URL存在则整体覆盖。代码注释明确标注这些CODEX_OSS_*环境变量目前是实验性的。使用流程是先启动本地服务再启动 Open Interpreter 并直接指定提供者interpreter --oss --local-provider ollama interpreter --oss --local-provider lmstudio不带--local-provider的--oss会使用你已保存的oss_provider配置配置键见 config_toml.rs其取值在校验函数中只接受lmstudio、ollama两个内置 ID见 validate_oss_provider若未保存则弹出选择器逐个探测默认本地端点是否有响应。若本地服务器位于其他主机或端口需在启动 Open Interpreter 前设置完整的、兼容 OpenAI 的/v1基础 URLCODEX_OSS_BASE_URLhttp://192.168.1.20:1234/v1 \ interpreter --oss --local-provider lmstudio -m qwen/qwen3-coder-next针对远程 Ollama 服务器同样使用--local-provider ollama。文档特别强调一条使用纪律不要仅仅为了更改任一内置本地提供者的地址而创建单独的model_providers条目——CODEX_OSS_BASE_URL才是受支持的覆盖方式自己包一层 provider 反而会绕开内置端点的特殊处理逻辑。模型元数据警告输出中出现Model metadata for ... not found时表示本地服务器返回的模型 ID 未出现在 Open Interpreter 的兼容性目录中——它本身并不代表服务器连接失败。正确的处理路径是确认服务器真实暴露的准确模型 ID用该 ID 原样通过-m传入更新 Open Interpreter 以获得最新的兼容性目录。Open Interpreter 可以继续使用回退元数据运行fallback 逻辑见 provider_catalog_models.rs但部分模型特定的控制或行为如推理档位、思考开关可能不可用。提供者系列与 Harness 默认值某些模型系列在未显式指定 harness 时会从模型/提供商系列自动推导出默认 harness模型/提供商系列默认 harnessClaude/Anthropic/Messagesclaude-codeKimi/Moonshotkimi-codeQwen/QwQ/DashScopeqwen-codeDeepSeekclaude-code-bare选择逻辑从「匹配条件」推导默认 harness详见 模型提供商指南中的默认 harness 选择命中 Anthropic/Messages wire API 或claude系列 ID 走claude-code命中 Kimi/Moonshot 相关名称或域名走kimi-code命中 Qwen/QwQ/DashScope 走qwen-code命中 DeepSeek 走claude-code-bare。因此文档表格里的四行本质上覆盖了当前主流开源编码模型的 wire-api 形态Anthropic Messages 原生协议的模型 →claude-codeKimi / Moonshot 平台 →kimi-code阿里云 DashScope 生态的 Qwen 系 →qwen-codeDeepSeek 需要 Anthropic 兼容请求但无复杂工具行为 →claude-code-bare。如果默认推导不符合你的预期可在配置中用harness ...显式覆盖。各 provider 的详细认证与推荐模型路径可分别参考 Kimi K3 指南、DeepSeek 指南 与 Z.AI / GLM 指南wire API 兼容性矩阵见 Harness 文档。小结模型能力的完整闭环把以上几节串起来Open Interpreter 的模型体系是一条完整的「元数据 → 选择器 → 配置 → 请求」链路目录provider_catalog.json提供模型种子兼容性目录model_compatibility_catalog.json提供推理与多模态能力注解管理器优先用提供者实时/models端点刷新、再按提供者特征匹配捆绑数据做增强最终在/model选择器、页脚、-m与 TOML 默认值中统一呈现。推理控制以ReasoningControl五种形态建模、以五档努力值为统一 UI、由 harness 负责映射到提供者字段输入模式用规范的InputModality标签描述并为老负载保留文本图像的兼容默认。理解了这层分层与聚合逻辑无论是接入本地 Ollama/LM Studio、调试「元数据未找到」警告还是在不同模型之间评估推理与多模态能力都能直接定位到仓库中对应的源码与数据文件。【免费下载链接】openinterpreterA coding agent for open models like Kimi K3 and GLM 5.3项目地址: https://gitcode.com/GitHub_Trending/op/openinterpreter创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考