AI Agent人工智能大模型AI 应用工具调用本地部署MCP ClientsAgent 记忆【免费下载链接】OperitThe most powerful AI agent and AI chat software on Android/Operit是一款Android上能力最为强大、发展最久的AI Agent项目地址https://gitcode.com/gh_mirrors/op/Operit点击查看免费下载本指南围绕 OperitAndroid 端 AI Agent / AI Chat 客户端中 OpenCodeZen / Go接入的架构重构展开讲解如何把路由、认证与思考参数从公共 Provider 中剥离、收敛到 OpenCode 专用实现并逐一拆解 OpenAI Chat Completions、OpenAI Responses、Anthropic Messages、Gemini 四条协议路由的隔离边界与实现细节。读完本文你将理解 Operit 的 LLM Provider 分层设计掌握以受控扩展点承载协议差异、不让公共请求路径承担特例的改造方法并能对照源码与测试完成同类多协议网关接入的隔离验证。改造背景OpenCode 特例侵入公共 Provider 的问题OpenCode 首版接入时把路由、认证和思考参数通过OpenCodeReasoningParametersmarker 直接注入到 Claude、Gemini、OpenAI 与 Responses 四个 provider 中。其结果是这个只为 OpenCode 一个 provider 服务的 marker进入了所有普通请求的构建路径导致 ClaudeProvider、GeminiProvider、OpenAIProvider、OpenAIResponsesProvider 这些公共实现必须识别 OpenCode 特例公共请求路径被迫承担了本不属于自身的协议差异。从源码结构看Operit 的 LLM 接入层集中在 llmprovider 目录 下包含 ClaudeProvider.kt、GeminiProvider.kt、OpenAIProvider.kt、OpenAIResponsesProvider.kt、OpenCodeProvider.kt 等四十余个 provider 实现以及 ThinkingQualityMapping.kt、ModelListFetcher.kt、AIServiceFactory.kt 等支撑模块。任何特例分支一旦写入公共文件都会随公共路径被所有兼容 provider 共享既增加维护成本也容易在后续改动中互相干扰。修正意图与作用域本次重构的核心意图是让 OpenCode 的协议适配完全留在 OpenCode 专用实现中普通 provider 只保留自己的通用行为必要的继承点只表达稳定的请求构建扩展不引用 OpenCode 类型或分支判断。官方作用域记录于 index.md恢复公共 provider 的原有 reasoning、认证和端点行为为 OpenCode 的 Chat Completions、Responses、Anthropic 和 Gemini 路由提供隔离实现修正 OpenCode Gemini 的认证头和 SSE URL保留现有设置、模型目录和路由测试并补充隔离边界说明。改造完成后OpenCode Chat、Responses、Anthropic、Gemini 的专用实现已全部合并到 OpenCodeProvider.kt 单文件中公共 Provider 不再包含 OpenCode marker、端点判断和认证分支。公共 Provider 恢复边界恢复边界记录在 01-public-provider-baseline.md旧实现公共 provider 通过OpenCodeReasoningParametersmarker 改变 reasoning 自动注入、参数过滤和 Gemini 请求端点该 marker 进入所有普通请求构建路径目标实现公共 provider 不再导入或识别 OpenCode 类型OpenCode 请求使用专用子类或专用请求构建钩子普通请求的认证、端点和 thinking 行为保持原样完成标准ClaudeProvider.kt、GeminiProvider.kt、OpenAIProvider.kt、OpenAIResponsesProvider.kt不包含 OpenCode 特例判断OpenCode 专用代码承担显式 reasoning 参数和 Geminix-goog-api-key/ SSE URL。在现有源码中搜索OpenCode关键字命中的文件仅剩OpenCodeProvider.kt、AIServiceFactory.kt、ModelListFetcher.kt与CodexProvider.kt后者用于模型目录解析四个公共 provider 文件均已不再引用 OpenCode 类型与完成标准一致。公共 provider 的 thinking 注入统一走 ThinkingQualityMapping.kt 中的ThinkingConfigurationApplier.apply()通用机制——该机制按 providerTypeId modelName apiEndpoint 解析 thinking 配置本身与 OpenCode 解耦。OpenCode 路由隔离单文件四协议路由隔离记录于 02-opencode-routing.mdOpenCodeProvider负责根据模型选择协议并把请求交给专用 provider 实现专用实现可以复用通用 provider 的消息、工具和流处理但通过受控扩展点覆盖请求体和请求 URL不把 OpenCode 条件写回公共 provider。总体结构OpenCodeProvider.kt 内部包含三层OpenCodeProvider门面class OpenCodeProvider(private val delegate: AIService, ...) : AIService by delegate以委托方式持有协议专用实现对外保持统一的AIService接口sendMessage()中先调用ThinkingConfigurationApplier.modelParameters()把思考配置转成协议可见的显式参数再转发给 delegateOpenCodeRouting路由器负责协议判定、端点规范化与模型目录端点构造四个专用 Provider 子类OpenCodeChatProvider、OpenCodeResponsesProvider、OpenCodeClaudeProvider、OpenCodeGeminiProvider分别继承公共的OpenAIProvider、ClaudeProvider、GeminiProvider通过 override 扩展点改写请求。创建入口在 AIServiceFactory.kt当ApiProviderType.OPENCODE时调用OpenCodeProvider.create()。create()内部先去除模型名opencode/、opencode-go/前缀再依据端点与模型名路由到四个专用实现。协议路由判定表路由判定集中在OpenCodeRouting.protocolFor()规则如下按模型 ID 判定模型 ID 前缀路由协议gemini-GEMINI_GENERICclaude-、qwen3.minimax-Go 端点全量非 Go 端点仅-free后缀ANTHROPIC_GENERICgpt-、grok-、muse-spark-OPENAI_RESPONSES_GENERIC非 Go 端点下的minimax-OPENAI_GENERICbig-pickle-、deepseek-、glm-、hy3、hy4-、kimi-、ling-、longcat-、mimo-、nemotron-、omen-、qwen3-coder、ring-、north-、laguna-、trinity-、x-preview-OPENAI_GENERIC其他抛出IllegalArgumentException(Unsupported OpenCode model protocol: ...)端点构造由OpenCodeRouting.endpointFor()完成先对 base 做规范化去尾部/若不以/v1结尾则补上随后按协议拼接Responses{base}/responsesAnthropic{base}/messagesGemini{base}/models/{modelName}其余Chat Completions{base}/chat/completions模型目录端点modelsEndpoint()为{base}/modelscatalogProviderId()依据是否为 Go 端点返回opencode-go或opencode。Go 端点的判定isGo()检查 endpoint 是否以/zen/go或/zen/go/v1结尾。各协议的请求边界与实现细节OpenAI Chat CompletionsOpenCodeChatProvider继承OpenAIProviderproviderType OPENAI_GENERIC。显式传入reasoning_effort同时针对 OpenCode Chat 路由后端透传 DeepSeek 风格 thinking 输出的特性做了收敛处理——该协议要求历史 assistant 消息必须原样回传reasoning_content否则模型完成工具调用后的下一轮请求会返回 400The reasoning_content in the thinking mode must be passed back to the API.。实现上强制preserveThinkInHistory true让父类的buildMessagesAndCountTokens保留历史 assistant 消息中的think内容overridecustomizeFinalRequestObject()公共基类 OpenAIProvider.kt 中为空实现、专供子类扩展的受控钩子在 messagesArray 后处理阶段调用ChatUtils.extractThinkingContent()见 ChatUtils.kt将think内容拆分为reasoning_content字段并回填。该实现完全收敛在子类内部不动通用OpenAIProvider。OpenAI ResponsesOpenCodeResponsesProvider同样继承OpenAIProvideruseResponsesApi trueproviderType OPENAI_RESPONSES_GENERIC。显式传入reasoning而不触发公共自动注入在createRequestBody()中当未开启 thinking 时调用ChatUtils.stripOpenAiResponsesReasoningMetaTurns()ChatUtils.kt剥离历史消息中的 Responses reasoning 元信息避免关闭 thinking 后历史污染请求。Anthropic MessagesOpenCodeClaudeProvider继承ClaudeProviderproviderType ANTHROPIC_GENERIC传入空 thinking 配置[]思考参数由 OpenCode 侧显式下发不触发公共自动注入。overrideaddParameters()仅放行thinking、budget_tokens、output_config三类参数并按ParameterValueTypeOBJECT/STRING/INT/FLOAT/BOOLEAN将参数值写入请求 JSON——OBJECT 类型的非法 JSON 会被runCatching捕获并记录警告而非抛错。GeminiOpenCodeGeminiProvider继承GeminiProviderproviderType GEMINI_GENERIC。overridecreateRequest()与公共 GeminiProvider 的两处关键差异即本次修正认证头和 SSE URL的直接落点认证头公共 GeminiProvider.kt 使用 URL 查询参数?key...传递 API KeyOpenCode 网关要求x-goog-api-key请求头因此OpenCodeGeminiProvider改为.addHeader(x-goog-api-key, opencodeApiKeyProvider.getApiKey())SSE URL公共实现使用streamGenerateContent/generateContent方法OpenCode 在流式场景要求追加?altsse后缀。实现中method if (isStreaming) streamGenerateContent else generateContentsuffix if (isStreaming) ?altsse else 最终 URL 为{apiBase}/models/{modelName}:{method}{suffix}apiBase由OpenCodeRouting.apiBase()从 endpoint 中剥离/models/片段后规范化为/v1结尾。Go 端点专属头部Go 端点/zen/go需要agent 自有身份以维持网关侧 prompt-cache 路由稳定create()中对 routedHeaders 统一追加User-Agent: Operit/{VERSION_NAME}所有 OpenCode 路由生效x-opencode-session: operit-{config.id}仅 Go 端点。模型目录请求同样携带Authorization: Bearer {apiKey}与User-Agent: Operit/{VERSION_NAME}见 ModelListFetcher.kt且模型列表端点由OpenCodeRouting.modelsEndpoint()提供ModelListFetcher.kt与其他 provider 的/v1/models约定区分。思考参数从 marker 到协议显式参数隔离改造的关键点之一是 thinking 表达方式。公共路径不再识别任何 OpenCode marker改为OpenCodeProvider.sendMessage()调用ThinkingConfigurationApplier.modelParameters()ThinkingQualityMapping.kt该方法把思考配置解析结果转成一组ModelParameter显式参数随modelParameters opencodeParameters传入 delegate同时enableThinking enableThinking || thinkingMapping.reasoningRequired并在 Responses 协议下才把 enableThinking 透传enableThinking protocol OPENAI_RESPONSES_GENERIC避免其他协议触发公共自动注入。各协议对应的思考参数由 ModelThinkingConfigDefaultsCollect.kt 中的默认配置声明均为providers: [OPENCODE]下的规则配置规则 ID匹配范围参数标签档位opencode-gemini-thinking-levelgoogle/gemini-*thinkingLevel含thinkingConfig.includeThoughtsLOW/MEDIUM/HIGHopencode-anthropic-effortanthropic、minimax/claude-*、minimax-*output_config.effort含thinking.typeadaptive、thinking.displaysummarizedlow/medium/highopencode-zhipu-glm-effortzhipu、zai-org、thudm/ 含glmreasoning_effort含thinking.typeenabled/disabledlow/high/maxopencode-responses-effortopenai、azure、xai/ 含gpt-、grok-、codexreasoning.effort含reasoning.summaryauto、includelow/medium/high/xhighopencode-chat-effort兜底其他 Chat 模型reasoning_effortlow/medium/high用户可在模型配置中以自定义 thinkingConfigurations JSON 覆盖这些默认规则customConfigurationControlsOpenCodeOptionCount测试用例即验证了自定义规则对档位数量的控制。静态验证与测试覆盖验证记录见 03-verification.md本次按仓库执行准则不运行构建、Gradle 或测试命令完成后执行静态 diff 检查git diff --check并核对公共 provider 不再引用 OpenCode 专用类型。仓库现有测试可从侧面印证隔离边界OpenCodeThinkingConfigurationTest.kt 覆盖 5 个用例zhipu/glm-5.3与zai-org/glm-4.6走reasoning_effortlow/high/max档位、google/gemini-2.5-pro走thinkingLevelLOW/MEDIUM/HIGH档位、未知 provider 兜底reasoning_effortlow/medium/high以及自定义配置控制档位数量CodexModelListParserTest.kt 与 CodexModelPolicyTest.kt 覆盖 OpenCode 模型目录解析与显式模型放行策略。配置视角OpenCode 在 Operit 中的接入方式从用户/配置视角看OpenCode 以独立 Provider 类型注册于 ApiProviderConfigCollect.ktproviderType OPENCODE默认端点https://opencode.ai/zen端点选项含Zenhttps://opencode.ai/zen与Gohttps://opencode.ai/zen/go两种Go 端点即路由表与x-opencode-session头部生效的前提默认模型名为空需从模型目录拉取模型 ID 形如zhipu/glm-5.3、google/gemini-2.5-pro去除opencode/或opencode-go/前缀后参与路由判定ApiProviderType.OPENCODE注释明确说明按基础路径选择服务按模型 ID 选择协议ModelConfigData.kt。隔离边界小结本次改造形成的清晰边界可以概括为三层约定公共 provider 只保留通用行为ClaudeProvider、GeminiProvider、OpenAIProvider、OpenAIResponsesProvider 不再出现 OpenCode 特例判断thinking 注入统一走ThinkingConfigurationApplier通用机制OpenCode 专用代码集中收敛路由、端点、认证、思考参数、reasoning_content 回传等全部落在 OpenCodeProvider.kt 内以继承 override 公共基类中受控扩展点createRequestBody、customizeFinalRequestObject、addParameters、createRequest的方式实现不修改父类公共逻辑可验证性通过静态 grep 公共 provider 文件中的 OpenCode 引用、运行 OpenCodeThinkingConfigurationTest.kt 等既有测试、以及git diff --check静态检查即可确认隔离边界未被破坏。对于后续需要接入类似一个网关、多协议后端的 provider这套门面路由 路由表 四协议子类 受控扩展点的架构可以直接复用协议差异下沉到专用子类公共请求路径永远只理解自身的协议语义。赞分享AI Agent人工智能大模型AI 应用工具调用本地部署MCP ClientsAgent 记忆【免费下载链接】OperitThe most powerful AI agent and AI chat software on Android/Operit是一款Android上能力最为强大、发展最久的AI Agent项目地址https://gitcode.com/gh_mirrors/op/Operit点击查看免费下载相关推荐Operit 的 OpenCode Provider 隔离改造公共 Provider 恢复基线、协议专用路由与静态验证指南Operit 的 OpenCode Provider 隔离改造公共 Provider 恢复基线、协议专用路由与静态验证指南 本文以 docs/TODO/opeAI Agent人工智能大模型AI 应用工具调用本地部署MCP ClientsAgent 记忆GUI 自动化Operit 中 OpenCode Provider 隔离重构公共 Provider 基线恢复与专用路由实现解析Operit 中 OpenCode Provider 隔离重构公共 Provider 基线恢复与专用路由实现解析 导读 本文基于 Operit 仓库中 opeAI Agent人工智能大模型AI 应用工具调用本地部署MCP ClientsAgent 记忆GUI 自动化Operit OpenCode Provider 路由隔离多协议请求边界与专用适配实现解析Operit OpenCode Provider 路由隔离多协议请求边界与专用适配实现解析 导读 本文基于 Operit 仓库的 docs/TODO/openAI Agent人工智能大模型AI 应用工具调用本地部署MCP ClientsAgent 记忆GUI 自动化上一篇5分钟快速上手用rmats2sashimiplot轻松实现RNA-seq剪接可视化下一篇Amazon Bedrock Workshop依赖项管理Python环境隔离与版本控制创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考