【免费下载链接】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 仓库中 AntigravityGoogle Cloud Code Assist / Vertex适配层的一次专项改造展开主题是把推理签名thoughtSignature重放状态从按顺序内容假设升级为按稳定 role/content/index 规范化追踪并让模型选择器的下线决策picker retirement与入站别名兼容性inbound alias compatibility彻底解耦。读完本文你将理解 Gemini 3 无状态交错思考在代理侧的签名重放机制、其有界缓存语义与持久化快照设计、畸形签名诊断的安全边界以及为什么隐藏 picker 行与保留解析别名必须分开处理——这些逻辑全部能在 opencodex 的源码与测试中找到直接实现证据。1. 背景Gemini 无状态交错思考与签名重放1.1 为什么需要签名重放Gemini 3 系列通过 Antigravity/CCA 与 Vertex 暴露的交错思考interleaved thinking在上游是无状态的响应流中每个模型内容 part 携带一个thoughtSignature下一轮请求必须把该签名回显到对应的 part 上否则上游会以 HTTP 400 拒绝该轮次。opencodex 的做法是在响应流上**观察observe**签名按model session维度缓存在下一轮请求组装request.contents时重新注入apply。这一设计直接对应 CLIProxyAPI 的internal/runtime/executor/antigravity_reasoning_replay.go并复用于 Vertex使用带 transport/project/location 前缀的模型身份。实现位于 src/adapters/google-antigravity-replay.ts文件头注释完整记录了这一数据流。1.2 Claude-on-Antigravity 走另一条路并非所有模型都走重放缓存antigravityUsesReplayCache(model)明确排除了claude命名的模型src/adapters/google-antigravity-replay.ts。Claude-on-Antigravity 使用内联签名净化inline signature sanitization对应测试组claude-on-antigravity inline signature sanitizationtests/adapters/google/google-antigravity-replay.test.ts。这是本改造涉及的两个并列机制之一也是下文中按模型身份决定重放路径的语义基础。2. 本次改造的核心目标与依赖关联文档 devlog/_fin/260717_non_openai_provider_chase/030_antigravity_replay_alias.md 明确了两个相互独立的决策目标Track replay state per content-block index and decide picker retirement independently from inbound alias compatibility.即按内容块索引追踪重放状态重放条目的规范化normalize与对账reconcile要基于稳定的 role/content/index而不是假设内容总是顺序出现的旧形态选择器下线与别名兼容解耦模型选择器picker是否展示某一行由认证后的可用性策略authenticated availability policy决定而已保存配置中的别名解析resolver alias则无条件保留二者不得互相绑架。改造前旧行为Before是重放/签名净化假设当前的顺序内容形态、重放应用缺乏显式的畸形/交错激活证明、gemini-3.1-pro-high同时作为 picker 行与线上别名改造后After是按稳定角色/内容/索引规范化并对账携带有界缓存语义、传递规范化索引内容状态并为非法签名放置提供安全诊断、解析别名无条件保留picker 行仅在认证可用性策略判定其仍在役时暴露。3. 重放缓存的规范化与有界语义源码纵深3.1 条目的稳定身份functionCall 身份键而非 part 下标旧实现假设当前顺序内容形态的隐患在于一个多步工具循环tool loop中多个 functionCall 可能落在同一个 part 下标上若按位置记忆签名第二步的签名就会覆盖第一步。opencodex 的解法是按 functionCall 身份键name 规范化 args记忆签名而非按 part 下标functionCallKey(name, args)对 name 与 args 的规范化 JSON 做 SHA-256得到固定 64 位十六进制键src/adapters/google-antigravity-replay.ts规范化走canonicalJsonBounded带 64 KiB 预算REPLAY_MAX_CANONICAL_ARGS_BYTES与 128 层深度上限溢出即放弃该次重放绝不物化无界字符串src/adapters/google-antigravity-replay.ts对象键排序保证{a:{p:1,q:2}}与{a:{q:2,p:1}}落在同一身份键上——测试 key is order-independent for nested object keys 直接断言了这一点tests/adapters/google/google-antigravity-replay.test.ts。会话键同样固定大小replayKey(model, sessionId)对长度前缀的字符串增量做 SHA-256src/adapters/google-antigravity-replay.ts且原始 model/session 字符串绝不作为 Map 键保留测试专用接口antigravityReplaySessionKeysForTests专门验证这一点src/adapters/google-antigravity-replay.ts。3.2 观察侧跨 SSE 块携带未配对签名observeAntigravityReplaysrc/adapters/google-antigravity-replay.ts按整个会话累积每一次调用的签名而不是只记住最新 part 槽位。两个关键细节carriedThoughtSig 线程流式响应会把一个 thought part 和它的 functionCall 拆到不同 SSE 块因此观察函数接收上一次块的未配对签名并在返回时把剩余部分交给下一次对应 issue #897、#2125独立 thought part 的签名配给同一数组内后续的 functionCall part调用自身的签名永远优先于携带的签名。测试组逐一验证了这些配对规则独立 thought 签名重放到下一个调用#897、重放到同一轮所有后续调用、跨块携带、调用自身签名优先、以及独立 thought 签名绝不反向配对或泄漏到后续 observetests/adapters/google/google-antigravity-replay.test.ts。3.3 应用侧从记录列表尾部对齐applyAntigravityReplaysrc/adapters/google-antigravity-replay.ts是按内容块索引重放的核心兑现遍历所有model turn而非仅最后一个只填充缺少真实签名的 functionCall part由于历史可能被压缩compaction / previous_response_id截断从记录签名列表的尾部倒序对齐最后一次出现是最新调用必须拿到最新签名反向遍历时每个出现无论是否已签名都占据其时间槽位已签名 part如机制①或上游原样回传的保持原样绝不覆盖支持 freeform/custom_tool_call 的{input: string}与已解析 JSON 参数的替代键匹配altKey并对超大 input 在JSON.parse之前就拒绝tests/adapters/google/google-antigravity-replay.test.ts。这也正是文档 Diff map 中google.ts一行的含义适配器把规范化索引后的内容状态传给重放应用并为非法签名放置提供安全诊断。3.4 有界缓存语义全部常量级上限重放缓存是一整套可审计的预算体系全部在 src/adapters/google-antigravity-replay.ts 顶部以常量声明常量值语义MIN_SIGNATURE_LEN16过短签名直接忽略MAX_SIGNATURES_PER_CALL32单个调用最多保留的签名数新签名入队、队首淘汰REPLAY_TTL_MS1h会话级 TTL过期即清ANTIGRAVITY_REPLAY_MAX_ENTRIES10,240全局会话数上限REPLAY_MAX_CALLS_PER_SESSION256单会话内调用身份键上限ANTIGRAVITY_REPLAY_MAX_BYTES_PER_SESSION2 MiB单会话字节预算ANTIGRAVITY_REPLAY_MAX_TOTAL_BYTES64 MiB全局字节预算REPLAY_MAX_SIGNATURE_BYTES64 KiB单签名大小上限REPLAY_SNAPSHOT_MAX_BYTES/REPLAY_SNAPSHOT_REFUSE_BYTES24 MiB / 32 MiB持久化快照写入/拒读上限对应测试覆盖单会话调用数与字节的精确边界淘汰maxCallsPerSession: 2时第三个调用挤掉最老的maxBytesPerSession: 300时按固定键算术驱逐、24 个签名调用在限额内全部保留、clear-on-invalid清空会话并修正字节记账tests/adapters/google/google-antigravity-replay.test.ts。3.5 持久化快照防重启丢失与自愈加载签名缓存会落盘为antigravity-replay.json位于配置目录OPENCODEX_HOME沙箱化测试用临时 HOME 隔离tests/adapters/google/google-antigravity-replay.test.ts懒加载ensureReplaySnapshotLoaded缺失、损坏、超 32 MiB 的快照一律从空缓存开始过期会话在加载时即被丢弃快照自愈写侧带 2s 防抖、序列化写者门闩writer gate、最多 8 次收敛尝试的 flushflushAntigravityReplay不收敛则抛固定文案错误以拒绝假持久性字节记账把 JSON 文档框架与逗号分隔符也计入 24 MiB 上限按最近活跃优先排序以保证快照内保留的是真正在用的会话过期既是内存事件也是持久化事件TTL 过期后签名不得继续静置在磁盘上src/adapters/google-antigravity-replay.ts。3.6 验证器绕过哨兵与畸形签名安全边界对于 Gemini 3 拒绝首 functionCall 无签名的校验器THOUGHT_SIGNATURE_BYPASS skip_thought_signature_validator是官方哨兵src/adapters/google-antigravity-replay.ts。但哨兵绝不能注入非 Gemini 模型——antigravitySupportsThoughtSignatureSentinel把模型身份归约到最后一个://段再匹配/^gemini[-.\d]/i防止vertex:gemini-prod:global:gpt-oss-120b这类项目名误触发src/adapters/google-antigravity-replay.ts。applyAntigravityThoughtSignatureFallback独立成 pass 而非并入重放是为了让缓存未命中在测试里依然读作未命中18 条断言依赖thoughtSignature undefined的语义。回到本文档激活场景中的畸形签名只从受影响块移除诊断输出不含 token/body 内容适配器在签名错误signature|thought_signature|thoughtSignature命中且确认为签名类错误时只调用clearAntigravityReplay(replayModel, replaySession)清除会话缓存src/adapters/google.ts防止中毒签名无限重放成循环同时flushAntigravityReplay、快照写失败等路径一律使用固定文案警告绝不回显可能携带路径或环境细节的底层错误src/adapters/google-antigravity-replay.ts——这正是安全诊断的实现证据。4. Picker 下线与别名兼容的解耦模型目录侧4.1 三层模型身份wire id / picker 行 / 兼容别名src/providers/antigravity-models.ts 明确维护三层身份单一事实来源是 Antigravity 的:fetchAvailableModels后端即agyCLI 解析标签所用的同一接口Wire IDsCCA 信封的model字段必须收到的线上标识如 Gemini 3.1 Pro (High) →gemini-pro-agentPicker 行折叠后的已知基础模型仅当 CCA 返回全部已知档位时才暴露如gemini-3.1-pro隐藏兼容别名为已保存选择保留的解析目标不占 picker 行。4.2gemini-3.1-pro-high可见别名非 picker 行改造的核心案例是gemini-3.1-pro-high。它存在于可见客户端别名表中src/providers/antigravity-models.tsconst ANTIGRAVITY_VISIBLE_MODEL_ALIASES: Recordstring, string { gemini-3.1-pro-high: gemini-pro-agent, gemini-3.1-pro-preview: gemini-pro-agent, };而 picker 列表ANTIGRAVITY_MODELSsrc/providers/antigravity-models.ts不含gemini-3.1-pro-high——它只有折叠的基础模型gemini-3.8-flash、gemini-3.7-flash、gemini-3.1-pro、gemini-3.1-flash-image、claude-sonnet-4-6、claude-opus-4-6-thinking、gpt-oss-120b-medium。ANTIGRAVITY_MODEL_ALIASES是可见别名与隐藏兼容别名的合并src/providers/antigravity-models.tsresolveAntigravityWireModelId对任何别名无条件解析src/providers/antigravity-models.tsexport function resolveAntigravityWireModelId(modelId: string, baseUrl?: string): string { const discovered discoveredAntigravityWireModelId(modelId, baseUrl); if (discovered) return discovered; return Object.hasOwn(ANTIGRAVITY_MODEL_ALIASES, modelId) ? ANTIGRAVITY_MODEL_ALIASES[modelId] : modelId; }这意味着即使认证后的模型列表不再返回gemini-3.1-pro-highpicker 行被隐藏一条直接保存的旧选择依然能解析到gemini-pro-agent——解析永不失效。4.3 认证可用性如何控制 picker 暴露parseAntigravityAvailableModels消费:fetchAvailableModels响应src/providers/antigravity-models.ts其折叠逻辑pickerModelIdForDiscoveredWireIdsrc/providers/antigravity-models.ts按优先级决定一行是否可见显式 picker 映射存在且其全部必需 wire id 都在 available 集合中 → 折叠为该 picker id-tiered后缀 → 剥后缀并折叠为已知 picker 模型-(low|medium|high)后缀 → 仅当三个档位全部在场才折叠为基础模型否则发独立档位行防止破坏推理档位控制display 标签 slug 是最后手段曾因先查标签导致 #1897 回归每个折叠模型又被拆成三行、推理档位控制失效。关键防线在兼容别名过滤src/providers/antigravity-models.ts落在ANTIGRAVITY_MODEL_ALIASES中的 wire id如已退役的 3.5/3.6 Flash 档位不会作为独立发现行重新发布——CCA 可能仍在 agent 列表里服务旧代际但别名表存在的意义就是退役它们。路由对已保存 id 依然生效经别名解析只是不再有 picker 行。同时discoveredAntigravityMapping带有模型缓存代际检查isModelCacheGenerationCurrentsrc/providers/antigravity-models.ts缓存代际过期即丢弃映射。这对应文档激活场景最后一条——列表拉取失败时保留保守的静态回退网络错误不会被误判为模型下线。4.4 推理档位解析的优先级规则resolveAntigravityEffortWireModelsrc/providers/antigravity-models.ts是隐藏 picker 行后路由仍正确的另一半gemini-3.1-pro的 effort 映射把high指向gemini-pro-agentsrc/providers/antigravity-models.ts并按规则 0退役 Flash 档位重定向到 3.7 并携带原档位、规则 1后缀/兼容别名后缀即档位不发 thinkingConfig、规则 1b单 wire id thinkingLevel、规则 2/3映射基础模型、规则 4Claude 走 thinkingConfig、规则 5其余直解逐级解析。5. 验证矩阵与测试证据5.1 文档给出的验证命令bun test tests/google-antigravity-replay.test.ts tests/google-antigravity-wire.test.ts tests/google-models-listing.test.ts bun run typecheck注意文档中写的是相对于旧测试布局的简写路径仓库中实际路径为 tests/adapters/google/google-antigravity-replay.test.ts、tests/adapters/google/google-antigravity-wire.test.ts、tests/adapters/google/google-models-listing.test.ts。文档同时给出硬性前提变更 picker 暴露前必须先有认证可用性/推理证明authenticated availability/inference proof。5.2 新增测试夹具对应本改造目标交错/索引签名interleaved/indexedgoogle-antigravity-replay.test.ts的顺序工具循环回归fc1/fc2 同 part 下标不同身份 → 各自拿回自己的签名tests/adapters/google/google-antigravity-replay.test.ts与嵌套参数不碰撞回归证明身份键的稳定性过期缓存stale-cache持久化快照加载测试手工写入过期会话随后断言其被丢弃且apply不再注入tests/adapters/google/google-antigravity-replay.test.ts畸形签名malformed signature短签名忽略、已签名 part 不覆盖、clear-on-invalid 清空字节记账有界会话bounded-session调用数/字节数边界驱逐、全局条目上限10,240 会话、快照字节上限。5.3 Picker/别名解耦的测试断言google-antigravity-wire.test.ts断言gemini-3.1-pro-high不在ANTIGRAVITY_MODELSpicker 隐藏同时通过buildRequest验证以该别名构造的入站请求仍解析到gemini-pro-agenttests/adapters/google/google-antigravity-wire.test.ts——正是文档 Diff map 中隐藏的 picker 别名仍能解析已保存入站配置的证明google-models-listing.test.ts的可用性/认证列表测试断言认证后的列表结果控制暴露但不删除入站兼容性且冷启动兜底fallback在冷却期内不被重复拉取tests/adapters/google/google-models-listing.test.ts。6. 终止结果判定标准按文档约定该改造以四种终态收口供评审与回滚决策使用终态判定条件处置DONE索引化重放夹具通过且线上证据支持 picker 决策、别名兼容保持合入NOOP当前重放结构无法复现签名丢失picker 保持上线仅保留夹具与证据NEEDS_HUMAN无可用 Antigravity 账号完成可用性证明人工介入UNSAFE变更会无迁移地删除已保存配置的别名立即拦截其中UNSAFE正是本文主题的反向约束别名兼容是入站契约任何让picker 隐藏演变成别名删除的变更都被判定为不安全——这与resolveAntigravityWireModelId的无条件解析互为表里。7. 工程启示小结从 devlog/_fin/260717_non_openai_provider_chase/030_antigravity_replay_alias.md 这份计划文档到落地实现可以提炼出三条可复用的设计原则状态身份用稳定键而非位置键重放签名按 functionCall 规范化身份记忆天然免疫 part 下标漂移、历史截断与流式分块缓存必须有界且可审计每层签名/调用/会话/全局/快照都有显式字节与数量上限超限驱逐、TTL 过期、加载自愈全部有测试背书展示面与兼容面解耦picker 行是当下是否在役的展示决策别名解析是保存配置永远可用的契约决策二者必须由不同机制独立控制——这正是gemini-3.1-pro-high案例的设计意图也定义了UNSAFE终态的触发条件。赞分享【免费下载链接】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点击查看免费下载相关推荐终极指南如何用Solidity构建防签名重放攻击的一次性签名安全机制终极指南如何用Solidity构建防签名重放攻击的一次性签名安全机制 WTF Solidity是一个面向Solidity初学者的开源项目专注于提供简洁易懂的示例工程区块链教程如何签名 EIP-155 防重放交易用 chainId 计算签名哈希与 v 值如何签名 EIP 155 防重放交易用 chainId 计算签名哈希与 v 值 在 EVM 链上签名一笔防重放交易时核心任务是三件事拿到当前链的 CHA区块链文档Web3AgentGovernanceToolkit AgentMeshDjango AgentTrustMiddleware 的 Ed25519 请求签名与 Nonce 防重放实践AgentGovernanceToolkit AgentMeshDjango AgentTrustMiddleware 的 Ed25519 请求签名与 Non人工智能AI AgentAI 安全治理策略引擎Agent 沙箱认证鉴权上一篇老Mac重获新生的终极指南OpenCore-Legacy-Patcher从入门到精通的完整实战手册下一篇Switch注入零基础教程3步用TegraRcmGUI完成RCM注入全流程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
