【免费下载链接】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 代理需要通过注入的模型目录让 Codex CLI / App 把路由模型当作原生 Codex 模型使用。本指南以devlog/_fin/100_codex-native-parity/10_search-and-tool-discovery.md及其关联决策文档为主线完整拆解 Codex 原生目录中supports_search_tool与web_search_tool_type两个字段的真实含义、缺失字段回退语义以及 opencodex 如何通过目录规范化catalog normalization与 sidecar 合成搜索工具让非 OpenAI 路由模型安全地获得托管搜索能力而不谎报能力。读完本文你将掌握这两个字段的判别方法、opencodex 的端到端搜索链路以及能力元数据诚实性在代理层是如何被保障的。两个易混淆的搜索能力hosted web search 与 deferred tool searchCodex 原生模型目录里存在两个名称相似、职责完全不同的搜索相关字段opencodex 的 Phase 100 对齐研究首先就是要厘清这一点。supports_search_tool不是OpenAI 托管hostedweb-search 工具的开关。它控制的是 Codex 的延迟工具发现deferredtool_search表面即面向 MCP / App / extension 工具的那一层能力。当该字段为false或缺失时Codex 不会向模型暴露延迟的tool_search但普通direct工具仍然可以通过常规的 tool plan 暴露给模型。换句话说它决定的是模型是否需要先调用tool_search去发现 MCP 等动态工具而不是模型能不能联网搜索。web_search_tool_type则控制托管 web-search 工具的形状。默认值是文本专用text-only当取值为text_and_image时Codex 会发出一个带有图片搜索内容类型的托管搜索工具运行时表现为search_content_types: [text, image]。字段控制对象默认/回退值text_and_image效果supports_search_tool延迟工具发现deferredtool_search面向 MCP/App/extensionfalse启用延迟工具发现表面web_search_tool_type托管 web-search 工具形状texttext-only托管搜索工具带图片内容类型缺失字段与未知模型时的回退语义devlog 中明确记录了当元数据缺失或无法识别时的回退规则这些规则决定了一个不完整目录条目在 Codex 眼中的真实能力supports_search_tool回退为falseweb_search_tool_type回退为 text-onlytext不发出search_content_types托管 web-search 的可用性仍然受 Codex 配置、模型传输方式model transport和 hosted-tool 模式的多重门控目录字段只是必要条件之一未知模型的回退元数据不会启用延迟工具发现。值得强调的是第三条即使目录把web_search_tool_type写成text_and_image最终是否真的执行托管搜索还取决于 Codex 侧的 hosted-tool 模式是否开启以及请求链路是否允许。这意味着 opencodex 必须同时处理好目录声明与运行时执行两个层面。原生 Codex 默认模型的实际搜索元数据为了回答路由模型到底该继承什么Phase 100 首先盘点了一套原生 Codex 默认模型的实际取值。devlog11_search-defaults-and-inherited-state.md记录了观察到的原生目录行模型web_search_tool_typesupports_search_tool备注gpt-5.5text_and_imagetruepriority 0、picker 可见当前原生默认模型gpt-5.4text_and_imagetruepicker 可见gpt-5.4-minitext_and_imagetruepicker 可见 / helpergpt-5.3-codextexttruepicker 可见gpt-5.2texttruepicker 可见codex-auto-reviewtext_and_imagetrue隐藏 helperCodex 选择默认模型的方式是对可用模型按priority排序然后取第一个 picker 可见的模型。在上述目录中gpt-5.5因此成为原生默认模型其原生托管搜索形状就是text_and_image。这一点可以直接在当前仓库的本地目录数据中得到印证src/codex/data/upstream-models.json中gpt-5.5第 350 行起与gpt-5.4-mini第 565 行起的web_search_tool_type均声明为text_and_image。在运行时解释层面text不发出search_content_types而text_and_image会发出search_content_types: [text, image]同时supports_search_tool独立存在、独立门控延迟的tool_search两者互不替代。opencodex 的目录克隆与元数据继承问题opencodex 采用克隆原生 Codex 目录模板的方式来构建自己的模型目录当前实现分布在src/codex/catalog/目录下devlog 记录中的旧路径src/codex-catalog.ts在现行仓库中已拆分为src/codex/catalog.ts、src/codex/catalog/derive-entry.ts、src/codex/catalog/parsing.ts等文件。早期阶段Phase 100 研究开始时的观察结论是路由routed条目没有显式删除或覆盖supports_search_tool与web_search_tool_type这意味着路由模型可能静默继承原生 OpenAI 的搜索 / 工具发现能力提示。这带来一个真实的风险即 devlog 记录的 Gap目录可能宣称了原生托管搜索语义即使路由的上游 provider 并没有原生的 OpenAI 托管搜索。opencodex 的 sidecar 让这种能力部分可用但元数据本身并不明确。如果 sidecar 前置条件不满足Codex 可能围绕一个在请求到达路由 provider 之前就被移除的能力做规划。这正是整个 Phase 100 搜索子专题要解决的问题目录声明必须与运行时真实执行路径一致否则会出现模型以为自己能搜索、实际请求被脱掉搜索工具的能力幻觉。请求时的运行时缓解hosted 工具抑制与合成web_search工具在目录元数据之外opencodex 在请求时对托管搜索做了三层缓解当前源码可以直接佐证Responses 解析器识别托管的web_search工具。src/web-search/synthetic-tool.ts中的extractHostedWebSearch()会在请求的tools[]中查找{type: web_search, ...}条目并原样取出这样它的配置如external_web_access、filters、user_location、search_context_size可以被回放到 sidecar 真实的web_search工具中src/responses/parser.ts在解析阶段把这段托管web_search配置暂存起来。路由模型的翻译层会把托管 OpenAI web-search 从发给上游 provider 的 tool calls 中丢弃——上游永远收不到 OpenAI 形态的托管图片搜索工具。只有当 sidecar 前置条件满足时sidecar 才会向路由模型注入一个合成的web_search(query)函数工具。buildWebSearchTool()构造的合成工具带有webSearch: true标志供代理循环拦截模型像调用普通函数一样调用它代理拦截后通过 sidecar 执行真实搜索调用永远不会被转发给 Codex。16_search-image-sidecar-correction.md记录了这套端到端路径的完整形态Codex 根据目录元数据启用托管 web searchopencodex 解析并在请求发往上游前抑制托管的web_search工具当 sidecar 前置条件满足时opencodex 向路由模型暴露合成的web_search(query)函数sidecar 通过原生 ChatGPT forward provider 执行真实的托管搜索devlog 记录当时的默认执行模型为gpt-5.4-mini当前实现中的默认常量已演进为gpt-5.6-luna见 src/web-search/index.ts并支持 anthropic / xai / gemini 等多后端各自有独立的默认执行模型如果最终路由目标是纯文本模型sidecar 会把相关图片结果以文字形式转述并附带来源 URL。路由条目的目录规范化normalizeRoutedCatalogEntry元数据层面Phase 100.2 落地为src/codex/catalog/parsing.ts中的normalizeRoutedCatalogEntry()。这个函数对每个从原生模板克隆出来的路由条目做显式重写而不是放任继承删除model_messages、tool_mode、multi_agent_version、use_responses_lite、supports_websockets、supports_experimental_context、supports_reasoning_summaries以及服务档位service tier等原生 OpenAI 专属字段对非 Cursor 路由条目显式设置web_search_tool_type text_and_imageCursor 条目则删除web_search_tool_type因为 Cursor 的 runTurn 路径绕过托管搜索 sidecar对所有路由条目设置supports_search_tool true。supports_search_tool true不是允许联网的意思而是有明确的工具发现动机路由条目在 code mode 下携带tool_mode code_mode_only延迟的 MCP 工具本来就可以通过 exec 的tools全局 /ALL_TOOLS被调用无需tool_search往返如果在这里盖章false反而会强制把每个 MCP 声明塞进exec.description造成实测的首轮 payload 膨胀约 2.7 倍源码注释中记录的实测数据96,699 → 258,929 字符。因此延迟工具发现位保持开启是经过权衡的主动决策而不是无意继承。无模板的路由回退条目也遵循同样的显式元数据策略src/codex/catalog/derive-entry.ts的兜底分支第 195-235 行对普通路由条目直接写入web_search_tool_type: text_and_image与supports_search_tool: trueCursor 回退条目则仅保留supports_search_tool: true。为什么text_and_image对路由条目是诚实的一个反直觉的点是opencode-go/kimi-k2.7-code这类第三方模型并不具备 OpenAI 原生的托管图片搜索能力为什么目录要给它写web_search_tool_type text_and_imagedevlog16_search-image-sidecar-correction.md给出了最终定论其逻辑是能力归属整条 opencodex 路由而非最终上游模型原生 Codex 元数据将gpt-5.4-mini标记为text_and_image且supports_search_tool trueopencodex 的 sidecar 正是用这类原生模型去执行真实的托管搜索调用因此对opencodex 路由整体而言托管搜索 图片搜索能力是真实存在的目录声明与实际执行能力一致最终上游模型拿到的仍然是合成函数工具加文字化的图片结果摘要绝不会收到 OpenAI 托管图片搜索工具。这就是能力诚实性的判据目录字段描述的是代理层最终能交付的能力而不是上游 provider 的原生能力。决策总结与最佳实践综合三个关联文档10_search-and-tool-discovery.md、11_search-defaults-and-inherited-state.md、16_search-image-sidecar-correction.md最终敲定的策略可以归纳为原生 OpenAI 直通passthrough条目可以保留text_and_image与supports_search_tool路由的非 OpenAI 模型不应静默继承托管 OpenAI 搜索语义必须经过normalizeRoutedCatalogEntry()显式归一化路由条目统一声明web_search_tool_type text_and_image且supports_search_tool true因为托管搜索由原生模型 sidecar 真实执行路由上游 provider 不会直接收到 OpenAI 托管图片搜索工具代理层负责抑制托管工具并暴露合成搜索函数纯文本路由模型的图片搜索结果以文字 来源 URL 的形式转述supports_search_tool不应该被当作 web-search 标志使用它是延迟工具发现位它保持开启是因为 opencodex 通过 parser / bridge 处理主动中继了 Codex 的延迟工具发现表面。对实现者的可操作建议即文档中的 Phase 100 Recommendation把两个搜索概念始终分开处理supports_search_tool仅在有意让路由模型使用 Codex 延迟工具发现时才保留web_search_tool_type应基于 opencodex sidecar 的真实能力设定而非原生模板继承补充回归测试证明托管web_search要么被翻译为合成 sidecar 工具、要么被可预期地抑制并在文档中明确原生 OpenAI 直通可保留托管搜索元数据、非 OpenAI 路由模型依赖 sidecar 搜索的边界。验证范围与延伸阅读16_search-image-sidecar-correction.md记录的回归验证范围包括四条断言路由目录条目将web_search_tool_type归一化为text_and_image原生裸 GPT 条目仍然保留text_and_image无模板的路由回退条目获得相同的显式元数据请求时的 sidecar 前置条件仍然控制托管搜索是否真正执行。本主题属于 Phase 100 Codex 原生对齐研究的一个切片若要继续深入建议按序阅读同一目录下的关联文档00_overview.mdPhase 100 总目标与模板只作结构、路由字段必须显式归一化的总体原则、11_search-defaults-and-inherited-state.md原生默认值与继承状态快照、16_search-image-sidecar-correction.mdtext-only → text_and_image 的修正与最终策略。核心实现证据集中在 src/codex/catalog/parsing.ts、src/codex/catalog/derive-entry.ts、src/web-search/synthetic-tool.ts 与 src/web-search/index.ts可供继续追踪与二次开发。赞分享【免费下载链接】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点击查看免费下载相关推荐Fuse.js vs Semantic Search模糊搜索与语义搜索的选型对比与工程实践Fuse.js vs Semantic Search模糊搜索与语义搜索的选型对比与工程实践 构建 AI 驱动的应用时嵌入向量embeddings与向量数前端搜索引擎opencodex 对齐 Codex 上游 GPT-5.6 模型元数据PR 31684 models.json 快照移植实战opencodex 对齐 Codex 上游 GPT 5.6 模型元数据PR 31684 models.json 快照移植实战 本文基于 opencodexOopencodex 原生 Codex 路由模型目录规约Phase 100 实现指南opencodex 原生 Codex 路由模型目录规约Phase 100 实现指南 opencodex 作为 OpenAI Codex 与 Claude Co创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考