OmX Agent Tiers 指南用 role、tier、posture 与 exactModel 四维控制 Agent 路由的推理成本【免费下载链接】oh-my-codexOmX - Oh My codeX: Your codex is not alone. Add hooks, agent teams, HUDs, and so much more.项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-codex导读Agent Tiers 是 OmXOh My codeX中用于控制 Agent 路由时推理成本与工作风格的一套实用指南解决的核心问题是当一个角色既要做快速检索、又要做深度实现时如何在责任与推理开销之间取得平衡。本文基于 docs/shared/agent-tiers.md 展开并结合仓库中的 src/agents/definitions.ts、src/agents/native-config.ts 与 src/config/models.ts 等源码讲清楚LOW/STANDARD/THOROUGH三个 tier 的选型规则、frontier-orchestrator/deep-worker/fast-lane三种 posture 的行为差异以及exactModel如何绕过 tier 默认值。读完你既能照单配置各角色的模型与推理档位也能理解 OmX 底层是如何把这些元数据落成 Codex 原生 Agent TOML 的。一、心智模型把责任、深度、风格三件事分开1.1 三个易混概念的解耦agent-tiers.md 开篇强调OmX 把过去混在一起的Agent 该干什么拆成了三个正交维度维度含义取值示例role该 Agent 负责什么executor、planner、architecttier该角色要投入多少推理/成本LOW、STANDARD、THOROUGHposture角色以何种风格运作frontier-orchestrator、deep-worker、fast-laneexactModel可选的角色级模型锁定gpt-5.6-sol、gpt-5.6-terra一句话概括用 role 选责任用 tier 选深度用 posture 选风格。exactModel是当某个角色需要特定模型契约时才使用的绕行通道它优先于 tier 默认值。这一设计在源码里有直接对应 src/agents/definitions.ts 的AgentDefinition接口同时携带reasoningEffort、posture、modelClass、routingRole、tools、category、可选exactModel与可选nativeSubagentDelegation等字段其中exactModel的类型被限定为gpt-5.6-terra | gpt-5.6-sol两个已知别名。1.2 tier 只是深度维度不等于模型强绑定需要澄清tier 描述的是推理深度档位而真正决定跑哪个模型的是源码中的modelClassfrontier/standard/fast与exactModel的组合。从源码实现看模型解析顺序为per-agentagentModels[role]覆盖 exactModel精确锁定 modelClass按车道路由见 src/agents/native-config.ts 的resolveAgentModel。因此 tier 与模型是预算意图与物理资源的关系两者配合而非等同。二、三个 Tier 的定位与典型角色2.1 LOW快查与窄检查适用场景简单探索、风格检查、轻量文档编辑。典型角色explore、style-reviewer、writer。源码佐证在 definitions.ts 中explore的reasoningEffort为low、modelClass为fast、tools为read-onlystyle-reviewer同样为low推理、fast模型类definitions.ts。它们都走 spark/fast 车道模型解析见resolveAgentModel中case fast默认取getSparkDefaultModel内置默认gpt-5.6-luna见 src/config/models.ts。2.2 STANDARD实现、调试与常规验证的默认档适用场景绝大多数代码改动、调试、常规验证。典型角色executor、debugger、test-engineer、quality-reviewer。源码佐证executor的reasoningEffort为medium、modelClass为standarddefinitions.ts。executor还是源码中的一个特殊案例生成原生 Agent TOML 时它优先读取 Codexconfig.toml根model否则回落到主/frontier 默认见 native-config.ts 与 docs/reference/omx-config-schema-routing.md 的说明。2.3 THOROUGH架构、安全敏感与多文件高影响改动适用场景架构设计、安全/信任边界改动、跨大量文件的大型重构。典型角色architect、critic、security-reviewer、executor。重要迁移提示文档明确标注deep-executor已废弃实现类路由统一走executor。源码佐证architect使用reasoningEffort: xhigh且exactModel: gpt-5.6-soldefinitions.tscritic为high推理、frontier模型类definitions.ts。注意reasoningEffort的合法取值是low | medium | high | xhigh四档见 definitions.ts而 per-agent 配置层面还允许max见 src/config/models.ts 的PER_AGENT_REASONING_EFFORTS。2.4 三个 Tier 的选型速查表Tier什么时候用典型角色推理档位示例LOW任务有界、非侵入explore、style-reviewer、writerlowSTANDARD默认起点覆盖大部分改动executor、debugger、test-engineer、quality-reviewermediumTHOROUGH安全/架构/大规模多文件architect、critic、security-reviewerhigh/xhigh三、Selection Rulestier 的实战选择规则agent-tiers.md 给出了四条可直接照做的规则大多数代码改动从STANDARD起步——不要一开始就拉满成本。仅在任务有界且非侵入时使用LOW——例如只查一个符号、改一处注释。满足以下任一条件就升级到THOROUGH安全 / 认证 / 信任边界相关改动影响全系统的架构决策跨大量文件的大型重构。Ralph 完成度检查至少使用STANDARD档的 architect 验证。其中第 4 条是团队级完成度检查的硬性下限实践中对应 Ralplan/Ralph 流程里的 architect 角色验证环节关于 Ralplan 中planner/architect/critic的角色分工与 posture 归属可进一步参考 docs/reference/omx-config-schema-routing.md。四、Posture Guidance三种工作风格的行为契约posture 决定了角色拿到任务后怎么行事OmX 会在生成 Agent 指令时注入对应的 posture overlay 文本见 src/agents/native-config.ts 的POSTURE_OVERLAYS每条都是一段posture_overlay ... /posture_overlay指令块。4.1 frontier-orchestrator可操控前沿模型 领导型角色定位适合可引导性强的前沿模型与 leader 型角色。优先级意图分类、委派、验证、架构判断。典型角色planner、analyst、architect、critic、code-reviewer。指令要点来自POSTURE_OVERLAYS源码实施前先做意图分类存在专家时默认委派与编排把第一个决策当成路由问题研究 vs 规划 vs 实现 vs 验证在实现前简洁地质疑可能引发问题的用户假设保持显式的 executor 交接边界不吸收本应由专门 executor 承担的深度实现工作。Ralplan 的落地细节文档明确说明planner锁定精确模型gpt-5.6-sol medium 推理architect锁定精确模型gpt-5.6-sol xhigh 推理critic共识门禁保持在前沿车道。这一点与源码完全一致planner与architect在 definitions.ts 中都带exactModel: gpt-5.6-sol且 native-config.test.ts 用测试断言了这两个角色生成的 TOML 固定为model gpt-5.6-sol、推理档位分别为medium与xhigh。4.2 deep-worker把实现干到底的深度工作者定位适合实现密集型角色承担任务直到完成。优先级直接执行、最小化 diff、严格验证。典型角色executor、debugger、test-engineer、build-fixer。指令要点任务一旦明确是实现导向就偏向直接执行与端到端完成先探索再实施最小改动并匹配既有模式验证必须严格诊断、测试与构建证据是宣称完成前的强制项只有当方法确实失败或架构权衡超出本地实现范围时才升级。4.3 fast-lane廉价/快速模型的快速通道定位适合用于 triage、搜索与窄范围综合的廉价/快速模型。优先级快速路由、简洁搜索、及时升级而非深度自主工作。典型角色explore、writer以及轻量研究/搜索专家。指令要点面向快速 triage、搜索、轻量综合与窄路由决策优化除非任务高度有界且显然否则不启动深度实现任务一旦膨胀就升级到 frontier-orchestrator 或 deep-worker 角色保持质量优先、范围感知模糊场景下保守。五、exactModel绕过 tier 默认值的角色级模型锁定5.1 什么时候需要 exactModel当某个角色对模型契约有硬性要求时例如 planner 的规划稳定性、architect 的长程权衡判断tier 默认的按模型类路由不足以表达这种必须用某个模型的约束此时用exactModel直接锁定。5.2 仓库中的两个精确锁定实例角色exactModelreasoningEffort来源plannergpt-5.6-solmediumdefinitions.tsarchitectgpt-5.6-solxhighdefinitions.tsresearchergpt-5.6-terrahighdefinitions.ts5.3 解析优先级与运行时行为从 native-config.ts 的resolveAgentModel可以确认完整解析链agentModels[role]per-agent 覆盖优先其次exactModel最后按modelClass路由。当解析出的模型恰好等于精确锁定时composeRoleInstructions还会追加一段exact_model_guidance强制要求严格执行顺序inspect → plan → act → verify只有实现完成且新验证通过后才能宣称完成遇到阻塞如实报告、不编造结果见 native-config.ts 与 native-config.test.ts 的断言。5.4 配置层如何覆盖虽然exactModel是内建锁定但用户仍可通过.omx-config.json的agentModels与agentReasoning块做 per-agent 覆盖。配置结构见 src/config/models.ts 的文档注释{ agentReasoning: { architect: xhigh }, agentModels: { architect: gpt-5.6-sol } }agentModels[role]优先生效其次是内建exactModel最后才是modelClass车道路由。测试 native-config.test.ts 验证了agentModels 覆盖精确锁定后不会残留过期的 exact 指导文本native-config.test.ts 则验证了 per-agent 推理档位支持max而ultra会被回落到high。六、落地链路从定义到 Codex 原生 Agent TOML理解 tier/posture 的最终落点是看 OmX 如何把 definitions.ts 里的定义转换成 Codex CLI 可用的原生 Agent 配置定义层AGENT_DEFINITIONS 集中声明所有角色的reasoningEffort、posture、modelClass、routingRole、tools、category与可选exactModel。指令合成层composeRoleInstructions 把prompts/role.md的提示词与 posture overlay、modelClass overlay、exact-model guidance、native subagent 叶子护栏拼接并写入## OMX Agent Metadata包含 role、posture、model_class、routing_role、resolved_model 等元数据。模型解析层resolveAgentModel 按per-agent 覆盖 exactModel modelClass决策modelClass: frontier走主/frontier 默认gpt-5.6-solfast走 spark 默认gpt-5.6-lunastandard走标准车道未配置时继承主/frontier可用OMX_DEFAULT_STANDARD_MODEL显式切到更便宜的模型见 models.ts。TOML 生成层generateAgentToml 输出包含model、model_provider、model_reasoning_effort、developer_instructions的独立 TOML再由 installNativeAgentConfigs 安装到~/.codex/agents/或./.codex/agents/。对应的角色提示词文件全部位于 prompts/ 目录如 executor.md、architect.md、planner.md定义完整性由 src/agents/tests/definitions.test.ts 与 src/agents/tests/native-config.test.ts 双重守护——例如definitions.test.ts断言reasoningEffort为必填且仅允许low | medium | high | xhigh并逐角色核对 plannermedium、architectxhigh、critichigh的档位。七、与模型车道配置的关系tier、posture 与模型车道最终统一在 docs/reference/omx-config-schema-routing.md 描述的模型路由体系里。要点归纳内置默认三车道gpt-5.6-solfrontier、gpt-5.6-terrastandard、gpt-5.6-lunaspark/fast见 src/config/models.ts。环境变量覆盖OMX_DEFAULT_FRONTIER_MODEL是主/frontier 默认的最强环境配置OMX_DEFAULT_STANDARD_MODEL是可选的 standard 车道覆盖OMX_DEFAULT_SPARK_MODEL与OMX_SPARK_MODEL控制 spark 车道。省略 standard 覆盖时standard 角色默认继承 leader/frontier 模型见 models.ts 与 omx-config-schema-routing.md。一个容易踩的细节原生 Agent TOML 生成路径中frontier 角色与executor特殊场景先读 Codexconfig.toml根model再回落到主默认——因此显式写在config.toml的根model不会被.omx-config.json的env.OMX_DEFAULT_FRONTIER_MODEL覆盖见 omx-config-schema-routing.md 的专门说明。结语OmX 的 Agent Tiers 把角色责任、推理深度、工作风格拆成三个正交维度并辅以exactModel做角色级精确锁定让路由决策既直观先定 role再选 tier再定 posture又可预测每层都有明确的模型解析优先级。本文对应的权威定义位于 docs/shared/agent-tiers.md其底层实现可分别在 src/agents/definitions.ts、src/agents/native-config.ts 与 src/config/models.ts 中逐行核对两侧相互印证是理解 OmX 多智能体编排成本控制的完整入口。【免费下载链接】oh-my-codexOmX - Oh My codeX: Your codex is not alone. Add hooks, agent teams, HUDs, and so much more.项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-codex创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 OmX Agent Tiers 指南：用 role、tier、posture 与 exactModel 四维控制 Agent 路由的推理成本
OmX Agent Tiers 指南用 role、tier、posture 与 exactModel 四维控制 Agent 路由的推理成本【免费下载链接】oh-my-codexOmX - Oh My codeX: Your codex is not alone. Add hooks, agent teams, HUDs, and so much more.项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-codex导读Agent Tiers 是 OmXOh My codeX中用于控制 Agent 路由时推理成本与工作风格的一套实用指南解决的核心问题是当一个角色既要做快速检索、又要做深度实现时如何在责任与推理开销之间取得平衡。本文基于 docs/shared/agent-tiers.md 展开并结合仓库中的 src/agents/definitions.ts、src/agents/native-config.ts 与 src/config/models.ts 等源码讲清楚LOW/STANDARD/THOROUGH三个 tier 的选型规则、frontier-orchestrator/deep-worker/fast-lane三种 posture 的行为差异以及exactModel如何绕过 tier 默认值。读完你既能照单配置各角色的模型与推理档位也能理解 OmX 底层是如何把这些元数据落成 Codex 原生 Agent TOML 的。一、心智模型把责任、深度、风格三件事分开1.1 三个易混概念的解耦agent-tiers.md 开篇强调OmX 把过去混在一起的Agent 该干什么拆成了三个正交维度维度含义取值示例role该 Agent 负责什么executor、planner、architecttier该角色要投入多少推理/成本LOW、STANDARD、THOROUGHposture角色以何种风格运作frontier-orchestrator、deep-worker、fast-laneexactModel可选的角色级模型锁定gpt-5.6-sol、gpt-5.6-terra一句话概括用 role 选责任用 tier 选深度用 posture 选风格。exactModel是当某个角色需要特定模型契约时才使用的绕行通道它优先于 tier 默认值。这一设计在源码里有直接对应 src/agents/definitions.ts 的AgentDefinition接口同时携带reasoningEffort、posture、modelClass、routingRole、tools、category、可选exactModel与可选nativeSubagentDelegation等字段其中exactModel的类型被限定为gpt-5.6-terra | gpt-5.6-sol两个已知别名。1.2 tier 只是深度维度不等于模型强绑定需要澄清tier 描述的是推理深度档位而真正决定跑哪个模型的是源码中的modelClassfrontier/standard/fast与exactModel的组合。从源码实现看模型解析顺序为per-agentagentModels[role]覆盖 exactModel精确锁定 modelClass按车道路由见 src/agents/native-config.ts 的resolveAgentModel。因此 tier 与模型是预算意图与物理资源的关系两者配合而非等同。二、三个 Tier 的定位与典型角色2.1 LOW快查与窄检查适用场景简单探索、风格检查、轻量文档编辑。典型角色explore、style-reviewer、writer。源码佐证在 definitions.ts 中explore的reasoningEffort为low、modelClass为fast、tools为read-onlystyle-reviewer同样为low推理、fast模型类definitions.ts。它们都走 spark/fast 车道模型解析见resolveAgentModel中case fast默认取getSparkDefaultModel内置默认gpt-5.6-luna见 src/config/models.ts。2.2 STANDARD实现、调试与常规验证的默认档适用场景绝大多数代码改动、调试、常规验证。典型角色executor、debugger、test-engineer、quality-reviewer。源码佐证executor的reasoningEffort为medium、modelClass为standarddefinitions.ts。executor还是源码中的一个特殊案例生成原生 Agent TOML 时它优先读取 Codexconfig.toml根model否则回落到主/frontier 默认见 native-config.ts 与 docs/reference/omx-config-schema-routing.md 的说明。2.3 THOROUGH架构、安全敏感与多文件高影响改动适用场景架构设计、安全/信任边界改动、跨大量文件的大型重构。典型角色architect、critic、security-reviewer、executor。重要迁移提示文档明确标注deep-executor已废弃实现类路由统一走executor。源码佐证architect使用reasoningEffort: xhigh且exactModel: gpt-5.6-soldefinitions.tscritic为high推理、frontier模型类definitions.ts。注意reasoningEffort的合法取值是low | medium | high | xhigh四档见 definitions.ts而 per-agent 配置层面还允许max见 src/config/models.ts 的PER_AGENT_REASONING_EFFORTS。2.4 三个 Tier 的选型速查表Tier什么时候用典型角色推理档位示例LOW任务有界、非侵入explore、style-reviewer、writerlowSTANDARD默认起点覆盖大部分改动executor、debugger、test-engineer、quality-reviewermediumTHOROUGH安全/架构/大规模多文件architect、critic、security-reviewerhigh/xhigh三、Selection Rulestier 的实战选择规则agent-tiers.md 给出了四条可直接照做的规则大多数代码改动从STANDARD起步——不要一开始就拉满成本。仅在任务有界且非侵入时使用LOW——例如只查一个符号、改一处注释。满足以下任一条件就升级到THOROUGH安全 / 认证 / 信任边界相关改动影响全系统的架构决策跨大量文件的大型重构。Ralph 完成度检查至少使用STANDARD档的 architect 验证。其中第 4 条是团队级完成度检查的硬性下限实践中对应 Ralplan/Ralph 流程里的 architect 角色验证环节关于 Ralplan 中planner/architect/critic的角色分工与 posture 归属可进一步参考 docs/reference/omx-config-schema-routing.md。四、Posture Guidance三种工作风格的行为契约posture 决定了角色拿到任务后怎么行事OmX 会在生成 Agent 指令时注入对应的 posture overlay 文本见 src/agents/native-config.ts 的POSTURE_OVERLAYS每条都是一段posture_overlay ... /posture_overlay指令块。4.1 frontier-orchestrator可操控前沿模型 领导型角色定位适合可引导性强的前沿模型与 leader 型角色。优先级意图分类、委派、验证、架构判断。典型角色planner、analyst、architect、critic、code-reviewer。指令要点来自POSTURE_OVERLAYS源码实施前先做意图分类存在专家时默认委派与编排把第一个决策当成路由问题研究 vs 规划 vs 实现 vs 验证在实现前简洁地质疑可能引发问题的用户假设保持显式的 executor 交接边界不吸收本应由专门 executor 承担的深度实现工作。Ralplan 的落地细节文档明确说明planner锁定精确模型gpt-5.6-sol medium 推理architect锁定精确模型gpt-5.6-sol xhigh 推理critic共识门禁保持在前沿车道。这一点与源码完全一致planner与architect在 definitions.ts 中都带exactModel: gpt-5.6-sol且 native-config.test.ts 用测试断言了这两个角色生成的 TOML 固定为model gpt-5.6-sol、推理档位分别为medium与xhigh。4.2 deep-worker把实现干到底的深度工作者定位适合实现密集型角色承担任务直到完成。优先级直接执行、最小化 diff、严格验证。典型角色executor、debugger、test-engineer、build-fixer。指令要点任务一旦明确是实现导向就偏向直接执行与端到端完成先探索再实施最小改动并匹配既有模式验证必须严格诊断、测试与构建证据是宣称完成前的强制项只有当方法确实失败或架构权衡超出本地实现范围时才升级。4.3 fast-lane廉价/快速模型的快速通道定位适合用于 triage、搜索与窄范围综合的廉价/快速模型。优先级快速路由、简洁搜索、及时升级而非深度自主工作。典型角色explore、writer以及轻量研究/搜索专家。指令要点面向快速 triage、搜索、轻量综合与窄路由决策优化除非任务高度有界且显然否则不启动深度实现任务一旦膨胀就升级到 frontier-orchestrator 或 deep-worker 角色保持质量优先、范围感知模糊场景下保守。五、exactModel绕过 tier 默认值的角色级模型锁定5.1 什么时候需要 exactModel当某个角色对模型契约有硬性要求时例如 planner 的规划稳定性、architect 的长程权衡判断tier 默认的按模型类路由不足以表达这种必须用某个模型的约束此时用exactModel直接锁定。5.2 仓库中的两个精确锁定实例角色exactModelreasoningEffort来源plannergpt-5.6-solmediumdefinitions.tsarchitectgpt-5.6-solxhighdefinitions.tsresearchergpt-5.6-terrahighdefinitions.ts5.3 解析优先级与运行时行为从 native-config.ts 的resolveAgentModel可以确认完整解析链agentModels[role]per-agent 覆盖优先其次exactModel最后按modelClass路由。当解析出的模型恰好等于精确锁定时composeRoleInstructions还会追加一段exact_model_guidance强制要求严格执行顺序inspect → plan → act → verify只有实现完成且新验证通过后才能宣称完成遇到阻塞如实报告、不编造结果见 native-config.ts 与 native-config.test.ts 的断言。5.4 配置层如何覆盖虽然exactModel是内建锁定但用户仍可通过.omx-config.json的agentModels与agentReasoning块做 per-agent 覆盖。配置结构见 src/config/models.ts 的文档注释{ agentReasoning: { architect: xhigh }, agentModels: { architect: gpt-5.6-sol } }agentModels[role]优先生效其次是内建exactModel最后才是modelClass车道路由。测试 native-config.test.ts 验证了agentModels 覆盖精确锁定后不会残留过期的 exact 指导文本native-config.test.ts 则验证了 per-agent 推理档位支持max而ultra会被回落到high。六、落地链路从定义到 Codex 原生 Agent TOML理解 tier/posture 的最终落点是看 OmX 如何把 definitions.ts 里的定义转换成 Codex CLI 可用的原生 Agent 配置定义层AGENT_DEFINITIONS 集中声明所有角色的reasoningEffort、posture、modelClass、routingRole、tools、category与可选exactModel。指令合成层composeRoleInstructions 把prompts/role.md的提示词与 posture overlay、modelClass overlay、exact-model guidance、native subagent 叶子护栏拼接并写入## OMX Agent Metadata包含 role、posture、model_class、routing_role、resolved_model 等元数据。模型解析层resolveAgentModel 按per-agent 覆盖 exactModel modelClass决策modelClass: frontier走主/frontier 默认gpt-5.6-solfast走 spark 默认gpt-5.6-lunastandard走标准车道未配置时继承主/frontier可用OMX_DEFAULT_STANDARD_MODEL显式切到更便宜的模型见 models.ts。TOML 生成层generateAgentToml 输出包含model、model_provider、model_reasoning_effort、developer_instructions的独立 TOML再由 installNativeAgentConfigs 安装到~/.codex/agents/或./.codex/agents/。对应的角色提示词文件全部位于 prompts/ 目录如 executor.md、architect.md、planner.md定义完整性由 src/agents/tests/definitions.test.ts 与 src/agents/tests/native-config.test.ts 双重守护——例如definitions.test.ts断言reasoningEffort为必填且仅允许low | medium | high | xhigh并逐角色核对 plannermedium、architectxhigh、critichigh的档位。七、与模型车道配置的关系tier、posture 与模型车道最终统一在 docs/reference/omx-config-schema-routing.md 描述的模型路由体系里。要点归纳内置默认三车道gpt-5.6-solfrontier、gpt-5.6-terrastandard、gpt-5.6-lunaspark/fast见 src/config/models.ts。环境变量覆盖OMX_DEFAULT_FRONTIER_MODEL是主/frontier 默认的最强环境配置OMX_DEFAULT_STANDARD_MODEL是可选的 standard 车道覆盖OMX_DEFAULT_SPARK_MODEL与OMX_SPARK_MODEL控制 spark 车道。省略 standard 覆盖时standard 角色默认继承 leader/frontier 模型见 models.ts 与 omx-config-schema-routing.md。一个容易踩的细节原生 Agent TOML 生成路径中frontier 角色与executor特殊场景先读 Codexconfig.toml根model再回落到主默认——因此显式写在config.toml的根model不会被.omx-config.json的env.OMX_DEFAULT_FRONTIER_MODEL覆盖见 omx-config-schema-routing.md 的专门说明。结语OmX 的 Agent Tiers 把角色责任、推理深度、工作风格拆成三个正交维度并辅以exactModel做角色级精确锁定让路由决策既直观先定 role再选 tier再定 posture又可预测每层都有明确的模型解析优先级。本文对应的权威定义位于 docs/shared/agent-tiers.md其底层实现可分别在 src/agents/definitions.ts、src/agents/native-config.ts 与 src/config/models.ts 中逐行核对两侧相互印证是理解 OmX 多智能体编排成本控制的完整入口。【免费下载链接】oh-my-codexOmX - Oh My codeX: Your codex is not alone. Add hooks, agent teams, HUDs, and so much more.项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-codex创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考