【免费下载链接】opencodexUniversal provider proxy for OpenAI Codex Claude Code — use any LLM (Claude, Gemini, Grok, DeepSeek, Ollama…) with Codex CLI, App, SDK, and Claude Code项目地址https://gitcode.com/gh_mirrors/ope/opencodex点击查看免费下载opencodex 作为一个面向 OpenAI Codex 与 Claude Code 的通用 Provider 代理当前仅通过少量适配器解析上游调用jawcode 参考实现中仍存在五个存活但尚未完全路由进 opencodex 的 Provider。本文基于devlog/_fin/140_remaining-provider-ports/01_provider-survey.md的调研结论逐项拆解google-antigravity、google-vertex、amazon-bedrock、kiro、cursor五个上游的线协议、认证机制、流式行为与模型面并对照 opencodex 的适配器契约给出移植缺口分析。读完本文你将掌握这五类上游与 OpenAI/Anthropic 风格接口的本质差异、各自的认证与流式陷阱以及它们在 opencodex 五适配器架构下的落地路径与风险等级。调研基线证据来源与模型计数口径该调研以 jawcode 参考实现为证据来源模型计数以packages/ai/src/models.json中的行数为准除非标注为静态列表。全部证据锚点如google-gemini-cli.ts:1-5、amazon-bedrock.ts:217-218均指 jawcode 参考实现中的具体文件与行号用于支撑线协议、认证与流式怪癖的结论。总览表Provider模型数jawcodeApi主实现认证机制google-antigravity15google-gemini-cligoogle-gemini-cli.ts共享OAuth JSON 凭据 Bearergoogle-vertex13google-vertexgoogle-vertex.tsgoogle-sharedAPI key或GCP ADC Beareramazon-bedrock119bedrock-converse-streamamazon-bedrock.tsAWS SigV4profile/env/ADC 链kiro8静态kiro-streamingkiro.tsBearer kiro-cli SQLite / refreshcursor145cursor-agentcursor.tscursor/gen/agent_pbCursor OAuth access token各 Provider 的描述符默认模型jawcodedescriptors.ts:301-304、291bedrock 默认us.anthropic.claude-opus-4-6-v1antigravity 默认gemini-3-pro-highvertex 默认gemini-3-pro-previewcursor 默认claude-sonnet-4-6kiro 默认kiro-auto。注本文讨论的opencodex 缺口对应调研文档撰写时的规划状态。从当前仓库源码看其中部分端口已逐步落地见文末从调研到现状一节缺口分析代表各上游向 opencodex 移植时的核心工作量与约束。1.google-antigravity状态与共享实现Alive活跃产品。Antigravity 与google-gemini-cli共享 Cloud Code Assist 流式实现Provider slug 在运行时切换google-gemini-cli.ts:1-5、291。这意味着两者的请求封装、SSE 解析与认证逻辑高度重合差异仅在 Provider 标识与少量头部。线协议端点Antigravity 日常/沙箱回退地址google-gemini-cli.ts:69-72、310daily-cloudcode-pa.googleapis.com、daily-cloudcode-pa.sandbox.googleapis.com。路径POST …/v1internal:streamGenerateContent?altsse338。请求体信封CloudCodeAssistRequest—— 顶层字段为{ project, model, request, requestType?, userAgent?, requestId? }195-222、785-796。Antigravity 额外注入requestType: agent、userAgent: antigravity、requestId: agent-{uuid}789-794。内层请求Gemini 形状的contents、systemInstruction、generationConfig、tools、toolConfig727-756。流式SSE JSON 分块嵌套的response.candidates[].content.parts394-501承载文本、thought/thoughtSignature、functionCall。认证要求options.apiKey中携带 OAuth 凭据 JSON286-288。经parseGeminiCliCredentials解析为{ accessToken, projectId, refreshToken?, expiresAt? }143-179。请求头使用Authorization: Bearer ${accessToken}320。登录/引导流程位于utils/oauth/google-antigravity.ts—— Google OAuth loadCodeAssist/onboardUser项目供给116-172并将 project id 写入凭据 blob。刷新偏差refresh skewantigravity 为 60 秒89、182-192。流式 / 保真怪癖怪癖证据Antigravity session id 由首个用户文本哈希推导653-659、731-733Claude 模型在 Antigravity 上anthropic-beta头、VALIDATED工具模式95-97、324、765-770针对 Claude/Gemini-3 的系统指令注入773-783工具 schema经normalizeSchemaForCCA将parametersJsonSchema→parameters662-678空流重试最多 2 次513-557重试时端点故障转移337-338非 Claude 的 antigravity 模型删除maxOutputTokens758-763模型发现当 OAuth token 存在时通过fetchAntigravityDiscoveryModels动态拉取google.ts:47-66markUnlistedOutsideDynamic: true。opencodex 缺口opencodex 既有google适配器面向 AI Studio URLgoogle.ts:108-110/v1beta/models/{id}:streamGenerateContent使用扁平 Gemini 请求体与x-goog-api-key——并非CCA 信封或 Bearer 认证。因此 antigravity 移植的关键不是重新发明解析器而是为google适配器补上CCA 信封封装 Bearer/OAuth 凭据两个挂钩。2.google-vertex线协议以api: google-vertex委托streamGoogleGenAIgoogle-vertex.ts:24-28。两种 URL 模式API keyhttps://aiplatform.googleapis.com/v1/publishers/google/models/{id}:streamGenerateContent?altsse携带x-goog-api-key37-44。ADChttps://{location}-aiplatform.googleapis.com/v1/projects/{project}/locations/{location}/publishers/google/models/{id}:streamGenerateContent?altsse携带Authorization: Bearer47-57。请求体标准buildGoogleGenerateContentParams经google-shared生成 Gemini generateContent 形状。流式与 AI Studio 路径共用streamGoogleGenAI内部的同一套 SSE JSON 解析。认证API keyGOOGLE_CLOUD_API_KEY或形似真实的options.apiKey61-67。ADCgetVertexAccessToken来自google-auth.ts:1-13—— 服务账号 JWT、authorized_user刷新、或 GCE 元数据6-9。ADC 路径强制要求 project/location69-87。怪癖vertex 开启retainTextSignature: true28——保留 thought 签名以支撑工具/思考连续性。尚无动态模型发现google.ts:36-44注释。opencodex 缺口google适配器硬编码了 AI Studio 的 base URL 与 API key 请求头。Vertex 需要可配置的 base host、路径前缀projects/…/locations/…以及来自 ADC 刷新的 Bearer 注入。3.amazon-bedrock线协议APIBedrock RuntimeConverseStream——POST /model/{modelId}/converse-streamamazon-bedrock.ts:217-218。Acceptapplication/vnd.amazon.eventstream244。请求体ConverseStreamRequest——messages、可选system、inferenceConfig、toolConfig思考模式经additionalModelRequestFields传递204-214、763-810。流式AWS eventstream 帧由decodeEventStream解码276事件类型包括messageStart、contentBlockStart/Delta/Stop、messageStop、metadata298-334。认证resolveAwsCredentials支持可选 profile233-237测试旁路AWS_BEDROCK_SKIP_AUTH230-231。请求经自定义signRequest签名SigV4不依赖 AWS SDK246-255。消息 / 工具映射消息转换为 Bedrock 线角色并为 Anthropic 模型插入缓存点570-714。工具结果批量合并进单条 user 消息662-696。思考additionalModelRequestFields.thinking支持 adaptive 与 budget 两种模式763-810thinkingDisplay默认summarized65、779。模型目录models.json中共119个模型。通过 models.dev 的amazon-bedrockkey 做发现openai-compat.ts:2170-2204带跨区域 id 变换与 Claude 的 EU 变体复制2184-2202。opencodex 缺口opencodex 没有 Bedrock 适配器、没有 SigV4 签名器、也没有 eventstream 解析器。即便消息语义与anthropic适配器相近请求/响应形状也不一致无法直接复用 —— 需要新建适配器。4.kiro线协议Hosthttps://runtime.{region}.kiro.dev/kiro.ts:49-50、545-546。请求头AWS 风格x-amz-target: AmazonCodeWhispererStreamingService.GenerateAssistantResponse50、92。Content-Typeapplication/x-amz-json-1.090。Acceptapplication/vnd.amazon.eventstream91。请求体conversationState携带history、currentMessage.userInputMessage可选tools/toolResults放于 context145-240。流式复用共享decodeEventStream591parseKiroPayload256-305中的负载 JSON 启发式处理 ——content、工具{name,input,toolUseId}、{stop:true}、{usage}。认证多来源解析器resolveKiroAuth392-487显式 token、aoa*apiKey 前缀、KIRO_ACCESS_TOKEN、缓存 刷新、prokiroauth.json、kiro-cli SQLite328-368、462-484。刷新POST https://prod.{region}.auth.desktop.kiro.dev/refreshToken312、371-389。反检测User-Agent 中的机器指纹72-83、85-98。怪癖怪癖证据模型 id 映射表kiro-auto→auto等728-749由消息哈希得到的稳定conversationId751-765工具名截断至 64 字符121无思考流 —— 仅文本 工具602-671401 → 刷新 单次重试562-579模型8个静态条目位于special.ts:82-91不在models.json。默认kiro-autodescriptors.ts:222。opencodex 缺口专有负载 IDE 模拟头。eventstream 解码器可与 Bedrock 移植共享但请求构造器与认证导入路径是 Kiro 特有的。5.cursor线协议并非 LLM REST API。HTTP/2 Connect 到AgentService/Runcursor.ts:133-134、355-368。Content-Typeapplication/connectproto360。分帧5 字节 Connect 帧175-180、412-421protobuf 负载AgentClientMessage/AgentServerMessage。流式interactionUpdate各分支 ——textDelta、thinkingDelta、toolCallStarted、toolCallDelta、toolCallCompleted、turnEnded1955-2098。双向服务端发送execServerMessage、kvServerMessage客户端必须应答611-622、968-1203。认证必须携带 Bearer access token337-340。OAuthPKCE 浏览器登录 轮询utils/oauth/cursor.ts:4-76经exchange_user_api_key刷新98。描述符oauthProvider: cursordescriptors.ts:291。会话 / 提示状态buildGrpcRequest维护conversationState、blob store、rootPromptMessagesJson2509-2640—— 对多轮至关重要2273-2276。Host 覆盖系统提示避免模型误以为身处 Cursor IDE2293-2297。工具经requestContextexec 握手通告而非放在初始 Run 请求里2616-2617、977-998。Exec / 工具主要复杂度Shell、read、write、grep、ls、mcp 等处理器1005-1167。缺少execHandlers时工具返回 Tool not available / Not implemented1256-1257、1108、1135。每 5 秒心跳468-479。模型models.json中145个条目。API key 存在时动态发现special.ts:46-58→fetchCursorUsableModels。opencodex 缺口需要新的适配器HTTP/2 protobuf 可选 exec 桥。无法映射到既有五个适配器中的任何一个。最高风险点Codex 工具调用与 Cursor 原生工具循环的语义错配。交叉参考jawcode 类型系统types.ts:35-61将全部五个 API 注册进KnownApi/ApiOptionsMap。Provider slugtypes.ts:101-149包含本次调研的全部五个对象。流式分发register-builtins.ts:358-371gemini-cli/antigravity、366-371vertex外加同一文件中 bedrock、cursor、kiro 的懒加载器。opencodex 适配器接口目标形状每个移植都必须满足 src/adapters/base.ts 中的ProviderAdapter契约调研文档以adapters/base.ts:8-20锚定// 构造上游请求可为异步如 Vertex ADC 会先解析短期凭据 buildRequest(parsed: OcxParsedRequest, incoming: IncomingMeta) → AdapterRequest | PromiseAdapterRequest // { url, method, headers, body } // 将上游响应解析为 AdapterEvent 异步生成器SSE / eventstream / Connect 帧皆在此归一 parseStream(response: Response, budget: TranslatorBudget) → AsyncGeneratorAdapterEvent // 可选一次性响应解析非流式路径 parseResponse?(response: Response, budget: TranslatorBudget) → PromiseAdapterEvent[]此外还支持可选的fetchResponse、runTurn自带传输的适配器如 Cursor 的整轮重放、localTerminal输入已含答案时短路上游Kiro 重放历史即此类场景等扩展钩子。buildRequest支持异步正对应 Vertex AI ADC 这类每次请求前刷新短期凭据的认证形态。OAuth 模式参考oauth/index.ts:11-17login、refresh、providerConfig、defaultModel—— 范例流程见oauth/xai.ts:1-71PKCE、发现、token 刷新。在 opencodex 中适配器由 src/server/adapter-resolve.ts 的resolveAdapter()经 src/adapters/registry.ts 的ADAPTER_REGISTRY构建createRegisteredAdapter会为每个适配器包装 tier 观测与输入媒体守卫registry.ts:177-214。新增适配器即新增一个 registry 条目与对应的create*Adapter工厂。从调研到现状当前仓库中的落地印证调研文档撰写时以五个缺口为结论而从当前仓库源码结构看部分端口已经落地可作为调研正确性的旁证Google 三模式合一src/adapters/google.ts 中provider.googleMode ?? ai-studio表明google适配器已演进为ai-studio/vertex/cloud-code-assist三种模式的分支。Vertex 路径google.ts:1059-1083正是调研中描述的双模式https://aiplatform.googleapis.com/v1/publishers/google/models/{id}:streamGenerateContentx-goog-api-key或 location 化 host ADC Bearerantigravity/CCA 路径则要求非空baseUrl并携带anthropic-beta等头部google.ts:930-949。kiro 适配器已存在src/adapters/kiro/wire.ts 中的https://runtime.${region}.kiro.dev/与 src/adapters/kiro/adapter.ts 中的x-amz-target头与调研描述的 CodeWhisperer 风格流协议一致。cursor 适配器已存在src/adapters/cursor/下包含 protobuf 生成代码src/adapters/cursor/gen/agent_pb.ts 中的interactionUpdate、execServerMessage、HTTP/2 Connect 传输src/adapters/cursor/live-transport.ts 的/agent.v1.AgentService/Run、src/adapters/cursor/http1-bidi.ts 的application/connectproto以及心跳机制印证了调研对Connectproto 双向流的判断。bedrock 仍未出现在 registry 中ADAPTER_REGISTRY尚无bedrock条目与调研需新建适配器 SigV4 签名器 eventstream 解析器的缺口结论一致。这印证了调研文档对五个上游的分类Gemini 家族vertex/antigravity通过扩展google适配器落地为三模式分支而 kiro/cursor 因协议异构各自独立成适配器bedrock 的 SigV4 eventstream 路线仍是规划中待实现的最大独立工程。结语一份可复用的移植决策模板01_provider-survey.md的价值在于把五个活着的上游从黑盒还原成可移植的契约每条线协议都精确到端点、路径、请求体信封与流式事件类型每套认证都列出凭据来源、刷新机制与反检测约束每个流式怪癖都给出file:line证据。移植任何上游到 opencodex都可以照此模板先产出线协议 → 认证 → 流式怪癖 → 模型面 → 缺口五段式调研再对照ProviderAdapter三方法契约评估扩展既有适配器还是新建适配器——这正是该调研文档在仓库 devlog 体系中承担的研究先行、实现后置职能。赞分享【免费下载链接】opencodexUniversal provider proxy for OpenAI Codex Claude Code — use any LLM (Claude, Gemini, Grok, DeepSeek, Ollama…) with Codex CLI, App, SDK, and Claude Code项目地址https://gitcode.com/gh_mirrors/ope/opencodex点击查看免费下载相关推荐opencodex 移植 kiroAWS CodeWhisperer提供方import-first 认证与 Amazon eventstream 流式协议全解析opencodex 移植 kiroAWS CodeWhisperer提供方import first 认证与 Amazon eventstream 流式协议opencodex 剩余 jawcode Provider 移植路线解析五适配器架构下的路由扩展蓝图opencodex 剩余 jawcode Provider 移植路线解析五适配器架构下的路由扩展蓝图 opencodex 是一个面向 OpenAI Codexopencodex 剩余 Provider 移植执行路线图五阶段 PABCD 落地 Google Vertex、Antigravity、Bedrock、Kiro 与 Cursoropencodex 剩余 Provider 移植执行路线图五阶段 PABCD 落地 Google Vertex、Antigravity、Bedrock、Kir创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 opencodex Provider 移植调研：五大未路由上游的线协议、认证体系与流式兼容性全景
【免费下载链接】opencodexUniversal provider proxy for OpenAI Codex Claude Code — use any LLM (Claude, Gemini, Grok, DeepSeek, Ollama…) with Codex CLI, App, SDK, and Claude Code项目地址https://gitcode.com/gh_mirrors/ope/opencodex点击查看免费下载opencodex 作为一个面向 OpenAI Codex 与 Claude Code 的通用 Provider 代理当前仅通过少量适配器解析上游调用jawcode 参考实现中仍存在五个存活但尚未完全路由进 opencodex 的 Provider。本文基于devlog/_fin/140_remaining-provider-ports/01_provider-survey.md的调研结论逐项拆解google-antigravity、google-vertex、amazon-bedrock、kiro、cursor五个上游的线协议、认证机制、流式行为与模型面并对照 opencodex 的适配器契约给出移植缺口分析。读完本文你将掌握这五类上游与 OpenAI/Anthropic 风格接口的本质差异、各自的认证与流式陷阱以及它们在 opencodex 五适配器架构下的落地路径与风险等级。调研基线证据来源与模型计数口径该调研以 jawcode 参考实现为证据来源模型计数以packages/ai/src/models.json中的行数为准除非标注为静态列表。全部证据锚点如google-gemini-cli.ts:1-5、amazon-bedrock.ts:217-218均指 jawcode 参考实现中的具体文件与行号用于支撑线协议、认证与流式怪癖的结论。总览表Provider模型数jawcodeApi主实现认证机制google-antigravity15google-gemini-cligoogle-gemini-cli.ts共享OAuth JSON 凭据 Bearergoogle-vertex13google-vertexgoogle-vertex.tsgoogle-sharedAPI key或GCP ADC Beareramazon-bedrock119bedrock-converse-streamamazon-bedrock.tsAWS SigV4profile/env/ADC 链kiro8静态kiro-streamingkiro.tsBearer kiro-cli SQLite / refreshcursor145cursor-agentcursor.tscursor/gen/agent_pbCursor OAuth access token各 Provider 的描述符默认模型jawcodedescriptors.ts:301-304、291bedrock 默认us.anthropic.claude-opus-4-6-v1antigravity 默认gemini-3-pro-highvertex 默认gemini-3-pro-previewcursor 默认claude-sonnet-4-6kiro 默认kiro-auto。注本文讨论的opencodex 缺口对应调研文档撰写时的规划状态。从当前仓库源码看其中部分端口已逐步落地见文末从调研到现状一节缺口分析代表各上游向 opencodex 移植时的核心工作量与约束。1.google-antigravity状态与共享实现Alive活跃产品。Antigravity 与google-gemini-cli共享 Cloud Code Assist 流式实现Provider slug 在运行时切换google-gemini-cli.ts:1-5、291。这意味着两者的请求封装、SSE 解析与认证逻辑高度重合差异仅在 Provider 标识与少量头部。线协议端点Antigravity 日常/沙箱回退地址google-gemini-cli.ts:69-72、310daily-cloudcode-pa.googleapis.com、daily-cloudcode-pa.sandbox.googleapis.com。路径POST …/v1internal:streamGenerateContent?altsse338。请求体信封CloudCodeAssistRequest—— 顶层字段为{ project, model, request, requestType?, userAgent?, requestId? }195-222、785-796。Antigravity 额外注入requestType: agent、userAgent: antigravity、requestId: agent-{uuid}789-794。内层请求Gemini 形状的contents、systemInstruction、generationConfig、tools、toolConfig727-756。流式SSE JSON 分块嵌套的response.candidates[].content.parts394-501承载文本、thought/thoughtSignature、functionCall。认证要求options.apiKey中携带 OAuth 凭据 JSON286-288。经parseGeminiCliCredentials解析为{ accessToken, projectId, refreshToken?, expiresAt? }143-179。请求头使用Authorization: Bearer ${accessToken}320。登录/引导流程位于utils/oauth/google-antigravity.ts—— Google OAuth loadCodeAssist/onboardUser项目供给116-172并将 project id 写入凭据 blob。刷新偏差refresh skewantigravity 为 60 秒89、182-192。流式 / 保真怪癖怪癖证据Antigravity session id 由首个用户文本哈希推导653-659、731-733Claude 模型在 Antigravity 上anthropic-beta头、VALIDATED工具模式95-97、324、765-770针对 Claude/Gemini-3 的系统指令注入773-783工具 schema经normalizeSchemaForCCA将parametersJsonSchema→parameters662-678空流重试最多 2 次513-557重试时端点故障转移337-338非 Claude 的 antigravity 模型删除maxOutputTokens758-763模型发现当 OAuth token 存在时通过fetchAntigravityDiscoveryModels动态拉取google.ts:47-66markUnlistedOutsideDynamic: true。opencodex 缺口opencodex 既有google适配器面向 AI Studio URLgoogle.ts:108-110/v1beta/models/{id}:streamGenerateContent使用扁平 Gemini 请求体与x-goog-api-key——并非CCA 信封或 Bearer 认证。因此 antigravity 移植的关键不是重新发明解析器而是为google适配器补上CCA 信封封装 Bearer/OAuth 凭据两个挂钩。2.google-vertex线协议以api: google-vertex委托streamGoogleGenAIgoogle-vertex.ts:24-28。两种 URL 模式API keyhttps://aiplatform.googleapis.com/v1/publishers/google/models/{id}:streamGenerateContent?altsse携带x-goog-api-key37-44。ADChttps://{location}-aiplatform.googleapis.com/v1/projects/{project}/locations/{location}/publishers/google/models/{id}:streamGenerateContent?altsse携带Authorization: Bearer47-57。请求体标准buildGoogleGenerateContentParams经google-shared生成 Gemini generateContent 形状。流式与 AI Studio 路径共用streamGoogleGenAI内部的同一套 SSE JSON 解析。认证API keyGOOGLE_CLOUD_API_KEY或形似真实的options.apiKey61-67。ADCgetVertexAccessToken来自google-auth.ts:1-13—— 服务账号 JWT、authorized_user刷新、或 GCE 元数据6-9。ADC 路径强制要求 project/location69-87。怪癖vertex 开启retainTextSignature: true28——保留 thought 签名以支撑工具/思考连续性。尚无动态模型发现google.ts:36-44注释。opencodex 缺口google适配器硬编码了 AI Studio 的 base URL 与 API key 请求头。Vertex 需要可配置的 base host、路径前缀projects/…/locations/…以及来自 ADC 刷新的 Bearer 注入。3.amazon-bedrock线协议APIBedrock RuntimeConverseStream——POST /model/{modelId}/converse-streamamazon-bedrock.ts:217-218。Acceptapplication/vnd.amazon.eventstream244。请求体ConverseStreamRequest——messages、可选system、inferenceConfig、toolConfig思考模式经additionalModelRequestFields传递204-214、763-810。流式AWS eventstream 帧由decodeEventStream解码276事件类型包括messageStart、contentBlockStart/Delta/Stop、messageStop、metadata298-334。认证resolveAwsCredentials支持可选 profile233-237测试旁路AWS_BEDROCK_SKIP_AUTH230-231。请求经自定义signRequest签名SigV4不依赖 AWS SDK246-255。消息 / 工具映射消息转换为 Bedrock 线角色并为 Anthropic 模型插入缓存点570-714。工具结果批量合并进单条 user 消息662-696。思考additionalModelRequestFields.thinking支持 adaptive 与 budget 两种模式763-810thinkingDisplay默认summarized65、779。模型目录models.json中共119个模型。通过 models.dev 的amazon-bedrockkey 做发现openai-compat.ts:2170-2204带跨区域 id 变换与 Claude 的 EU 变体复制2184-2202。opencodex 缺口opencodex 没有 Bedrock 适配器、没有 SigV4 签名器、也没有 eventstream 解析器。即便消息语义与anthropic适配器相近请求/响应形状也不一致无法直接复用 —— 需要新建适配器。4.kiro线协议Hosthttps://runtime.{region}.kiro.dev/kiro.ts:49-50、545-546。请求头AWS 风格x-amz-target: AmazonCodeWhispererStreamingService.GenerateAssistantResponse50、92。Content-Typeapplication/x-amz-json-1.090。Acceptapplication/vnd.amazon.eventstream91。请求体conversationState携带history、currentMessage.userInputMessage可选tools/toolResults放于 context145-240。流式复用共享decodeEventStream591parseKiroPayload256-305中的负载 JSON 启发式处理 ——content、工具{name,input,toolUseId}、{stop:true}、{usage}。认证多来源解析器resolveKiroAuth392-487显式 token、aoa*apiKey 前缀、KIRO_ACCESS_TOKEN、缓存 刷新、prokiroauth.json、kiro-cli SQLite328-368、462-484。刷新POST https://prod.{region}.auth.desktop.kiro.dev/refreshToken312、371-389。反检测User-Agent 中的机器指纹72-83、85-98。怪癖怪癖证据模型 id 映射表kiro-auto→auto等728-749由消息哈希得到的稳定conversationId751-765工具名截断至 64 字符121无思考流 —— 仅文本 工具602-671401 → 刷新 单次重试562-579模型8个静态条目位于special.ts:82-91不在models.json。默认kiro-autodescriptors.ts:222。opencodex 缺口专有负载 IDE 模拟头。eventstream 解码器可与 Bedrock 移植共享但请求构造器与认证导入路径是 Kiro 特有的。5.cursor线协议并非 LLM REST API。HTTP/2 Connect 到AgentService/Runcursor.ts:133-134、355-368。Content-Typeapplication/connectproto360。分帧5 字节 Connect 帧175-180、412-421protobuf 负载AgentClientMessage/AgentServerMessage。流式interactionUpdate各分支 ——textDelta、thinkingDelta、toolCallStarted、toolCallDelta、toolCallCompleted、turnEnded1955-2098。双向服务端发送execServerMessage、kvServerMessage客户端必须应答611-622、968-1203。认证必须携带 Bearer access token337-340。OAuthPKCE 浏览器登录 轮询utils/oauth/cursor.ts:4-76经exchange_user_api_key刷新98。描述符oauthProvider: cursordescriptors.ts:291。会话 / 提示状态buildGrpcRequest维护conversationState、blob store、rootPromptMessagesJson2509-2640—— 对多轮至关重要2273-2276。Host 覆盖系统提示避免模型误以为身处 Cursor IDE2293-2297。工具经requestContextexec 握手通告而非放在初始 Run 请求里2616-2617、977-998。Exec / 工具主要复杂度Shell、read、write、grep、ls、mcp 等处理器1005-1167。缺少execHandlers时工具返回 Tool not available / Not implemented1256-1257、1108、1135。每 5 秒心跳468-479。模型models.json中145个条目。API key 存在时动态发现special.ts:46-58→fetchCursorUsableModels。opencodex 缺口需要新的适配器HTTP/2 protobuf 可选 exec 桥。无法映射到既有五个适配器中的任何一个。最高风险点Codex 工具调用与 Cursor 原生工具循环的语义错配。交叉参考jawcode 类型系统types.ts:35-61将全部五个 API 注册进KnownApi/ApiOptionsMap。Provider slugtypes.ts:101-149包含本次调研的全部五个对象。流式分发register-builtins.ts:358-371gemini-cli/antigravity、366-371vertex外加同一文件中 bedrock、cursor、kiro 的懒加载器。opencodex 适配器接口目标形状每个移植都必须满足 src/adapters/base.ts 中的ProviderAdapter契约调研文档以adapters/base.ts:8-20锚定// 构造上游请求可为异步如 Vertex ADC 会先解析短期凭据 buildRequest(parsed: OcxParsedRequest, incoming: IncomingMeta) → AdapterRequest | PromiseAdapterRequest // { url, method, headers, body } // 将上游响应解析为 AdapterEvent 异步生成器SSE / eventstream / Connect 帧皆在此归一 parseStream(response: Response, budget: TranslatorBudget) → AsyncGeneratorAdapterEvent // 可选一次性响应解析非流式路径 parseResponse?(response: Response, budget: TranslatorBudget) → PromiseAdapterEvent[]此外还支持可选的fetchResponse、runTurn自带传输的适配器如 Cursor 的整轮重放、localTerminal输入已含答案时短路上游Kiro 重放历史即此类场景等扩展钩子。buildRequest支持异步正对应 Vertex AI ADC 这类每次请求前刷新短期凭据的认证形态。OAuth 模式参考oauth/index.ts:11-17login、refresh、providerConfig、defaultModel—— 范例流程见oauth/xai.ts:1-71PKCE、发现、token 刷新。在 opencodex 中适配器由 src/server/adapter-resolve.ts 的resolveAdapter()经 src/adapters/registry.ts 的ADAPTER_REGISTRY构建createRegisteredAdapter会为每个适配器包装 tier 观测与输入媒体守卫registry.ts:177-214。新增适配器即新增一个 registry 条目与对应的create*Adapter工厂。从调研到现状当前仓库中的落地印证调研文档撰写时以五个缺口为结论而从当前仓库源码结构看部分端口已经落地可作为调研正确性的旁证Google 三模式合一src/adapters/google.ts 中provider.googleMode ?? ai-studio表明google适配器已演进为ai-studio/vertex/cloud-code-assist三种模式的分支。Vertex 路径google.ts:1059-1083正是调研中描述的双模式https://aiplatform.googleapis.com/v1/publishers/google/models/{id}:streamGenerateContentx-goog-api-key或 location 化 host ADC Bearerantigravity/CCA 路径则要求非空baseUrl并携带anthropic-beta等头部google.ts:930-949。kiro 适配器已存在src/adapters/kiro/wire.ts 中的https://runtime.${region}.kiro.dev/与 src/adapters/kiro/adapter.ts 中的x-amz-target头与调研描述的 CodeWhisperer 风格流协议一致。cursor 适配器已存在src/adapters/cursor/下包含 protobuf 生成代码src/adapters/cursor/gen/agent_pb.ts 中的interactionUpdate、execServerMessage、HTTP/2 Connect 传输src/adapters/cursor/live-transport.ts 的/agent.v1.AgentService/Run、src/adapters/cursor/http1-bidi.ts 的application/connectproto以及心跳机制印证了调研对Connectproto 双向流的判断。bedrock 仍未出现在 registry 中ADAPTER_REGISTRY尚无bedrock条目与调研需新建适配器 SigV4 签名器 eventstream 解析器的缺口结论一致。这印证了调研文档对五个上游的分类Gemini 家族vertex/antigravity通过扩展google适配器落地为三模式分支而 kiro/cursor 因协议异构各自独立成适配器bedrock 的 SigV4 eventstream 路线仍是规划中待实现的最大独立工程。结语一份可复用的移植决策模板01_provider-survey.md的价值在于把五个活着的上游从黑盒还原成可移植的契约每条线协议都精确到端点、路径、请求体信封与流式事件类型每套认证都列出凭据来源、刷新机制与反检测约束每个流式怪癖都给出file:line证据。移植任何上游到 opencodex都可以照此模板先产出线协议 → 认证 → 流式怪癖 → 模型面 → 缺口五段式调研再对照ProviderAdapter三方法契约评估扩展既有适配器还是新建适配器——这正是该调研文档在仓库 devlog 体系中承担的研究先行、实现后置职能。赞分享【免费下载链接】opencodexUniversal provider proxy for OpenAI Codex Claude Code — use any LLM (Claude, Gemini, Grok, DeepSeek, Ollama…) with Codex CLI, App, SDK, and Claude Code项目地址https://gitcode.com/gh_mirrors/ope/opencodex点击查看免费下载相关推荐opencodex 移植 kiroAWS CodeWhisperer提供方import-first 认证与 Amazon eventstream 流式协议全解析opencodex 移植 kiroAWS CodeWhisperer提供方import first 认证与 Amazon eventstream 流式协议opencodex 剩余 jawcode Provider 移植路线解析五适配器架构下的路由扩展蓝图opencodex 剩余 jawcode Provider 移植路线解析五适配器架构下的路由扩展蓝图 opencodex 是一个面向 OpenAI Codexopencodex 剩余 Provider 移植执行路线图五阶段 PABCD 落地 Google Vertex、Antigravity、Bedrock、Kiro 与 Cursoropencodex 剩余 Provider 移植执行路线图五阶段 PABCD 落地 Google Vertex、Antigravity、Bedrock、Kir创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考