OmX（oh-my-codex）`.omx-config.json` 模型与环境路由配置完全指南

.omx-config.json 是 oh-my-codex（OmX）在 Codex 之上叠加 hooks、agent 团队、HUD 等能力时的核心配置文件。本文以仓库内权威参考文档 docs/reference/omx-config-schema-routing.md 为骨架，完整讲解该文件的读取位置、全部受支持的顶层键，以及模型与环境路由（model/env routing）的解析顺序、优先级与实战配置。读完本文，你将能准确写出可被当前版本 OmX 识别、可复制运行的模型路由配置，学会用 omx setup --force 与 omx doctor 验证生效结果，并理解底层源码（src/config/models.ts）的真实解析逻辑，避免踩到"未知键不是稳定扩展点"的坑。

配置文件在哪里读取

绝大多数 .omx-config.json 的读取器都经由当前激活的 Codex home 解析文件，具体取决于安装时的 setup 形态（scope）：

Setup 形态	配置文件路径	说明
用户级（user scope）	${CODEX_HOME:-~/.codex}/.omx-config.json	默认形态。CODEX_HOME 一旦设置即优先
项目级（project scope）	./.codex/.omx-config.json	当 ./.omx/setup-scope.json 声明为 project 且 CODEX_HOME 未设置时，由 OmX 启动路径使用

项目级 setup 还会写入 ./.codex/config.toml、./.codex/hooks.json，以及项目本地的 skills / prompts / agents；用户级 setup 则把对应文件写入 ${CODEX_HOME:-~/.codex} 之下。

有两个细节需要特别注意：

1. wiki 生命周期读取器是例外：它运行在 hook payload 的 cwd 上，因此先检查 <root>/.omx-config.json，再回退到 ${CODEX_HOME:-~/.codex}/.omx-config.json，若两者都没有合法的 wiki 对象，则使用内置 wiki 默认值。注意 ./.codex/.omx-config.json 只有在 CODEX_HOME 恰好解析到 ./.codex 时才生效，它并不是 wiki 专用的额外查找路径。
2. 启动路径的向上查找：omx setup --scope project 会把项目级选择持久化到 ./.omx/setup-scope.json（对应源码 src/cli/setup-preferences.ts 中 getSetupScopeFilePath() 返回的路径）。而 src/cli/codex-home.ts 中的 resolveProjectLocalCodexHomeForLaunch() 会从当前工作目录向上逐级查找最近的项目级 scope，保证从项目树的任意子目录启动都能命中项目配置而不会静默落到用户配置。omx doctor 会打印解析出的 setup scope 以及它正在检查的 Codex home 与配置路径。

受支持的顶层键

当前代码只识别以下顶层键，不要随意添加未识别的键——未知键不是稳定的扩展点，JSON 格式错误或分节形状不对时，读取该分节的特性可能直接忽略该节，或对该特性 fail closed：

顶层键	受支持形状	主要用途
agentModels	对象，映射 agent 名到非空模型字符串	可选的按 agent 模型覆盖，作用于生成的 native agent TOML、AGENTS.md 模型表，以及基于角色的 worker/Ralph 回退路由
agentReasoning	对象，映射 agent 名到 low/medium/high/xhigh/max	可选的按 agent 推理强度覆盖，作用于生成的 native agent TOML 与基于角色的 worker/Ralph 人员安排指导
env	对象，非空字符串值	模型路由与辅助启动路径的回退环境值，支持的模型相关键见下文
models	对象，非空字符串值	模式默认值与低复杂度模型别名，支持的模型路由键见下文
notifications	对象	通知传输、profile、模板、冷却、回复，以及 OpenClaw/自定义别名。完整示例见 OpenClaw 指南
stopHookCallbacks	遗留对象	兼容旧版会话结束通知（telegram/discord）；新配置请用 notifications
promptRouting	{ "triage": { "enabled": boolean } }	开启/关闭 advisory triage 提示路由；键缺失时默认开启，形状错误时 fail closed 为关闭
autoNudge	对象	native 自动续写设置，针对匹配的 permission/stall 提示。支持 enabled、patterns、response、delaySec、stallMs、ttlMs 以及遗留的 cooldownMs。注意：这不是已废弃的 team worker stall/progress nudge 路径，不要添加 OMX_TEAM_PROGRESS_STALL_MS 或 OMX_TEAM_WORKER_TURN_STALL_MS 作为调优建议
wiki	对象	项目 wiki 生命周期设置。支持 enabled、autoCapture、maxContextLines、staleDays、maxPageSize、feedProjectMemoryOnStart

通知相关键（notifications）

notifications 支持以下当前形状：

• 全局字段：enabled、verbosity（取值 verbose/agent/session/minimal）、includeChildAgents、defaultProfile、profiles、events、hookTemplates、reply、dispatchCooldownSeconds、idleCooldownSeconds。
• 平台字段：discord、discord-bot、telegram、slack、webhook。
• OpenClaw/自定义传输字段：openclaw、custom_webhook_command、custom_cli_command。
• 顶层 notifications.events 下的事件键：session-start、session-stop、session-end、session-idle、ask-user-question。每个事件可设置 enabled、messageTemplate 与平台覆盖；notifications.telegram 这类平台块自身不拥有 events 过滤器。
• native 子 agent/subagent 生命周期 hook 派发在 minimal/session 级别默认被抑制。把 notifications.verbosity 设为 agent/verbose，或设置 notifications.includeChildAgents: true，即可收到独立的子 agent 开始/结束 hook 事件。
• hookTemplates 支持 version、enabled、events、defaultTemplate；按事件的模板配置支持 enabled、template 与平台模板覆盖。
• reply 支持 enabled、authorizedDiscordUserIds、pollIntervalMs、rateLimitPerMinute、maxMessageLength、includePrefix。
• notifications.openclaw 支持 enabled、gateways、hooks。Gateway 条目可以是 HTTP（type、url、headers、method、timeout）或命令（type、command、timeout）；Hook 条目使用 gateway、instruction、enabled。

Discord webhook-vs-bot 的完整搭建见 docs/discord-integration.md，通知/OpenClaw 完整示例见 docs/openclaw-integration.md。密钥尽量放在环境变量中。

模型与环境键

模型路由读取器支持 env、models，以及按角色覆盖的 agentModels 与 agentReasoning。下面是一份可复制的完整示例（模型名仅为示例字符串，实际应替换为你可用的模型名）：

{
  "agentModels": {
    "planner": "gpt-5.6-sol",
    "architect": "gpt-5.6-sol",
    "researcher": "gpt-5.6-terra",
    "explore": "gpt-5.6-luna"
  },
  "agentReasoning": {
    "architect": "xhigh",
    "critic": "xhigh"
  },
  "env": {
    "OMX_DEFAULT_FRONTIER_MODEL": "gpt-5.6-sol",
    "OMX_DEFAULT_STANDARD_MODEL": "gpt-5.6-terra",
    "OMX_DEFAULT_SPARK_MODEL": "gpt-5.6-luna"
  },
  "models": {
    "default": "gpt-5.6-sol",
    "team": "gpt-5.6-sol",
    "team_low_complexity": "gpt-5.6-luna"
  }
}

env

env 提供回退环境值：只有当真实 shell 环境没有设置对应变量时才生效，shell 环境变量始终优先。支持的环境键如下：

键	用途
OMX_DEFAULT_FRONTIER_MODEL	主/前沿默认模型，leader 与前沿类角色在没有更强配置时使用
OMX_DEFAULT_STANDARD_MODEL	可选的标准通道覆盖；省略时标准 agent 继承主/前沿默认
OMX_DEFAULT_SPARK_MODEL	spark/快通道默认，用于低成本探索与低复杂度 worker
OMX_SPARK_MODEL	遗留 spark 回退；新配置优先用 OMX_DEFAULT_SPARK_MODEL
OMX_TEAM_CHILD_MODEL	直接读取该设置的特定 team-child 路径的默认子模型

源码层面，src/config/models.ts 中的 readConfiguredEnvOverrides() 会遍历 env 对象里所有非空字符串值并原样透传给 omx explore、omx sparkshell 等启动助手——也就是说其他 env 键会被当作高级环境覆盖透传，而不是按角色路由模型的结构化 schema。

针对 omx sparkshell，文档明确的辅助专用环境键有：

键	用途
OMX_SPARKSHELL_BIN	覆盖 native omx-sparkshell 二进制路径
OMX_SPARKSHELL_MODEL	覆盖主摘要模型
OMX_SPARKSHELL_FALLBACK_MODEL	主模型不可用时重试摘要模型
OMX_SPARKSHELL_MODEL_INSTRUCTIONS_FILE	覆盖随包分发的轻量摘要指令文件
OMX_SPARKSHELL_SUMMARY_TIMEOUT_MS	覆盖本地 API 摘要超时（毫秒）

models

models 把模式名映射为显式模型覆盖，值必须是非空字符串。内置默认值是 gpt-5.6-sol（frontier）、gpt-5.6-terra（standard）、gpt-5.6-luna（spark）；已知别名表恰好包含这三个 GPT-5.6 模型（源码中即 KNOWN_CODEX_MODEL_ALIASES/GPT_5_6_MODEL_ALIASES）。旧世代名称（如 gpt-5.5、gpt-5.4-mini、gpt-5.3-codex-spark）不是别名，也没有特殊路由含义——它们和其它任何厂商模型名一样，只会作为不透明覆盖字符串透传。已知别名表只用于展示与契约测试，不是封闭的允许列表。

受支持的模型路由键：

键形状	用途
default	getModelForMode(mode) 在请求的模式没有显式键时的回退
任意模式键（如 team、autopilot、ralph）	代码调用 getModelForMode("mode") 时该模式的显式模型。若 models.autopilot 或继承的主/默认模型是便宜/mini 模型，Autopilot 会为重活 ralplan 规划记录专属 planner 归属
team_low_complexity	低复杂度 team/spark 模型覆盖
team-low-complexity	team_low_complexity 的别名
teamLowComplexity	team_low_complexity 的别名

不要发明 models.executor、models.architect、models.roles 这类按角色映射，除非你的安装版本明确记录了该键。当前的角色路由基于 agent 定义与模型类别（model class），而不是任意的按角色 JSON 映射。

从源码看，getModelForMode() 的解析顺序是：models[mode] → models.default → getMainDefaultModel()；而 getTeamLowComplexityModel() 会依次尝试三个低复杂度别名键（TEAM_LOW_COMPLEXITY_MODEL_KEYS），取第一个非空值。空字符串、纯空白值会被 normalizeConfiguredValue() 丢弃（该函数对字符串 trim 后判空），测试用例 src/config/tests/models.test.ts 明确覆盖了"空值回退到 default""值带空白自动 trim""models 节是数组时视为无效回退到 frontier 默认"等边界行为。

agentModels

agentModels 是受支持的按 agent 模型覆盖表。键是规范化后的 OmX agent 名，规范化规则与 agentReasoning 一致：agent 名大小写不敏感，允许字母、数字、下划线与连字符（源码 normalizeAgentName() 的规则是首字符为字母或数字、整体匹配 [a-z0-9_-]* 并小写化）。值必须是非空字符串；畸形 agent 名、空值、非字符串值会被忽略而非报错（测试 reads normalized per-agent model overrides from .omx-config.json 验证了这一点）。

{
  "agentModels": {
    "architect": "gpt-5.6-sol",
    "planner": "gpt-5.6-sol",
    "researcher": "gpt-5.6-terra",
    "explore": "gpt-5.6-luna"
  }
}

这些覆盖不会改变源码里的内置默认值，它们是用户/项目配置，在 OmX 解析以下内容时生效：生成的 native agent TOML、生成的开发者元数据/指令、AGENTS.md 模型能力表，以及基于角色的 team/Ralph 回退模型选择。修改本表后请重新运行 omx setup --force，让 setup 管理的 native agent TOML 与 AGENTS.md 托管分节重新生成。

对某个命名角色，生效的模型优先级是：

1. .omx-config.json 的 agentModels[role]
2. 内置 exactModel 固定，例如 planner/architect 固定 gpt-5.6-sol、researcher 固定 gpt-5.6-terra
3. 特殊角色逻辑，例如 executor 使用主/前沿通道
4. modelClass 路由：fast 用 spark/低复杂度，frontier 用主/前沿，standard 用标准通道

agentModels 是持久的按角色配置面。不要把按角色模型放进 models.executor、models.architect 或 models.roles。

agent 定义的真实形状可以在 src/agents/definitions.ts 看到：每个 AgentDefinition 都带 reasoningEffort、可选的 exactModel、modelClass（frontier/standard/fast）与 posture（frontier-orchestrator/deep-worker/fast-lane）等元数据，这正是角色路由决策的输入。

agentReasoning

agentReasoning 是受支持的按 agent 推理强度覆盖表。键是规范化后的 agent 名；配置的字符串值会被 trim 并统一小写，最终必须是 low、medium、high、xhigh、max 之一。这个规范化只发生在配置层：它并不会让 max 成为根级 CLI 值或启动简写。

max 会被原样传递到生成的 native-agent TOML 与 Team 角色默认值中。它是否可用，取决于已安装的 Codex 版本、所选模型与提供商的能力；OmX 不会探测能力、不会把它降级/重试为 xhigh，也不会隐藏下游错误。ultra 在 OmX 拥有的 agentReasoning 配置面上不受支持，也不是 max 的别名。源码中 PER_AGENT_REASONING_EFFORTS = ['low', 'medium', 'high', 'xhigh', 'max'] 与根级 ROOT_REASONING_EFFORTS = ['low', 'medium', 'high', 'xhigh'] 是两个刻意分离的词表，测试 keeps legacy, per-agent, and root reasoning vocabularies distinct 用类型断言保证了这一点。

{
  "agentReasoning": {
    "architect": "MAX",
    "critic": "xhigh"
  }
}

注意上面的示例故意用了大写的 "MAX"——它会先被 trim、再小写化为 max 后生效，演示了配置层的规范化。但同样地：这些覆盖不改变源码内置默认；每个内置 AgentDefinition.reasoningEffort 仍然必须是 low/medium/high/xhigh 之一，绝不省略、绝不是 max/ultra。合法的覆盖只影响那个规范化后的 agent 键；畸形 agent 名、空/非字符串值、ultra 与未知值都会被忽略，因此同组里其它合法兄弟覆盖仍然生效，受影响的角色则保留未改动时的内置回退。修改本表后同样要重跑 omx setup --force 重新生成 setup 管理的 native agent TOML。

有效模型优先级

对生成的 native agent 与基于角色的 worker/Ralph 回退路由，agentModels[role] 先于内置固定与模型类别路由被检查。以下各节描述的是没有任何按 agent 覆盖时使用的通道默认值。

主/前沿默认

主默认按以下顺序解析：

1. shell 环境变量 OMX_DEFAULT_FRONTIER_MODEL
2. .omx-config.json 的 env.OMX_DEFAULT_FRONTIER_MODEL
3. 当前 Codex config.toml 根级 model
4. 内置默认：gpt-5.6-sol

这对应源码 getMainDefaultModel()：getEnvConfiguredMainDefaultModel()（shell 优先、配置回退）→ getCodexConfigRootModel()（解析 config.toml 的根 model，使用 @iarna/toml）→ DEFAULT_FRONTIER_MODEL。

按模式查询模型

当代码请求 getModelForMode(mode) 时，模式模型按以下顺序解析：

1. .omx-config.json 的 models[mode]
2. .omx-config.json 的 models.default
3. 上述主/前沿默认

示例：models.team = "gpt-5.6-sol"、models.default = "gpt-5.6-terra" 时，team 用 gpt-5.6-sol；没有自己键的模式用 gpt-5.6-terra。测试 resolves different modes independently 验证了 team/autopilot/ralph 各自独立解析。

标准通道 agent

标准通道 agent 按以下顺序解析：

1. shell OMX_DEFAULT_STANDARD_MODEL
2. .omx-config.json 的 env.OMX_DEFAULT_STANDARD_MODEL
3. 主/前沿默认

也就是说：除非你显式设置标准通道覆盖，否则标准 agent 默认继承 leader/frontier 模型（源码 getStandardDefaultModel() 注释称之为"opt-in escape hatch"，测试 inherits the main default for standard agents 验证了继承行为）。

spark/快通道 agent

spark/快默认按以下顺序解析：

1. shell OMX_DEFAULT_SPARK_MODEL
2. shell 遗留 OMX_SPARK_MODEL
3. .omx-config.json 的 env.OMX_DEFAULT_SPARK_MODEL
4. .omx-config.json 遗留 env.OMX_SPARK_MODEL
5. .omx-config.json 的 models.team_low_complexity / models.team-low-complexity / models.teamLowComplexity
6. 内置默认：gpt-5.6-luna

对 team 低复杂度助手，精确顺序取决于调用路径：getSparkDefaultModel() 先检查 spark 环境/配置值再检查低复杂度别名；而 getTeamLowComplexityModel() 先检查低复杂度别名，再回退到 spark 默认。测试 uses OMX_DEFAULT_SPARK_MODEL when low-complexity config is absent、falls back to legacy OMX_SPARK_MODEL、prefers OMX_DEFAULT_SPARK_MODEL over legacy OMX_SPARK_MODEL 分别锁定了这些分支。

角色/类别路由示例

Native agent TOML 生成与 team 模型契约逻辑使用带 modelClass、可选 exactModel、reasoningEffort 元数据的 agent 定义（见 src/agents/definitions.ts）。按 agent 的 agentModels[role] 覆盖最先胜出；只有当不存在按 agent 模型覆盖时，exact-model 固定才先于类别路由。native-agent 生成有一个重要的 frontier 通道优先级细节：对 frontier 角色与 executor 特殊情形，它先读当前 Codex config.toml 根级 model，缺失时才回退到 getMainDefaultModel()（相关逻辑在 src/agents/native-config.ts）。因为 getMainDefaultModel() 在这条路径上只是回退，所以对生成的 native-agent TOML 而言，.omx-config.json 的 env.OMX_DEFAULT_FRONTIER_MODEL 不会覆盖显式的 config.toml 根 model。

角色/类别	示例	模型类别行为
精确规划/研究固定	planner、architect、researcher	除非设置了 agentModels[role]，否则先使用内置 exactModel 固定再走类别路由：planner 固定 gpt-5.6-sol + medium 推理，architect 固定 gpt-5.6-sol + xhigh 推理，researcher 固定 gpt-5.6-terra。Ralplan 的 critic 仍走 frontier 路由以服务共识门（consensus gate）。Autopilot 中当 [main] 是便宜/mini 模型或配置了 agentModels.planner 时，planning_routing.owner 会把初始 ralplan Planner 草稿/分解切换到专属 planner 角色
前沿编排	critic、code-reviewer、security-reviewer、team-executor、vision	native-agent 生成先使用当前 config.toml 根 model，再回退到主/前沿默认
标准 worker/评审	debugger、quality-reviewer、api-reviewer、performance-reviewer、dependency-expert、writer	使用标准通道默认，除非设置了 OMX_DEFAULT_STANDARD_MODEL，否则继承主/前沿
快/低复杂度	explore、style-reviewer	使用 spark/低复杂度默认
executor 特殊情形	executor	native-agent 生成先使用当前 config.toml 根 model，再回退主/前沿默认；team 回退路由保持它在 frontier 通道

Team worker 启动还会叠加一层解析（实现位于 src/team/model-contract.ts，其中 LOW_COMPLEXITY_AGENT_TYPES 集合包含 explore、explorer、style-reviewer）：

1. OMX_TEAM_WORKER_LAUNCH_ARGS 内显式 --model ... 最先胜出；
2. 可继承的 leader 启动模型参数可透传给 worker；
3. 若没有显式/继承的模型，worker 角色的默认模型类别选择回退模型；
4. explore 等快速角色以及以 -low 结尾的角色名使用低复杂度/spark 回退。

需要查看运行中团队的模型解析提示时，用 omx team status <team-name> --model-inspect；常规 status 路径不会为摘要消耗模型配额。

推理强度：只放在受支持的位置

.omx-config.json 不是配置根级 model_reasoning_effort 的常规位置。不要添加 reasoningEffort、modelReasoningEffort、reasoning 之类的任意键，也不要添加未声明的按角色推理表。受支持的按 agent 覆盖表只有 agentReasoning。

根级与按 agent 的推理词表刻意分离：

• 根级 config.toml 接受 model_reasoning_effort = "low"、"medium"、"high"、"xhigh"。
• omx reasoning <low|medium|high|xhigh> 编辑该根级设置。没有 omx reasoning max、omx --max 或根级 max 简写。
• omx --high 与 omx --xhigh 向 Codex 启动传递 -c model_reasoning_effort="high|xhigh"。
• .omx-config.json 的 agentReasoning 接受前文所述五个按 agent 配置值，并在不改变内置默认的前提下，覆盖所选角色默认、作用于生成的 native agent TOML 与基于角色的 Team/Ralph 人员安排。
• 其余情况下，生成的 native agent TOML 写入每个角色未改动的内置 reasoningEffort 元数据。

Team 运行时在没有显式推理覆盖时，可以注入角色默认或被 agentReasoning 覆盖的值。显式的原生 -c model_reasoning_effort=... 是不透明的 Codex 透传：它优先于配置与内置角色默认，原样转发（包括 ultra 或未来值），并保留 Team 显式推理对"环境显式推理"的继承优先级。OmX 不会校验、规范化、降级、重试或宣称提供商支持该原始值。

启动解析器有一条狭窄的 end-of-options 规则：字面量 --max 与 --ultra 在 -- 之前会被当作 OmX 简写拒绝，但 omx -- --max 与 omx -- --ultra 会原样透传给 Codex。这并不使 -- 之后无关的参数成为 OmX 配置面。

入门配置

JSON 不支持注释，请只复制下面的 JSON 块。

省钱入门配置（cost-saving starter）

该配置把编排保持在 frontier 默认，把标准 worker 路由到更便宜的标准模型，并用 spark 通道承担探索/低复杂度工作：

{
  "env": {
    "OMX_DEFAULT_FRONTIER_MODEL": "gpt-5.6-sol",
    "OMX_DEFAULT_STANDARD_MODEL": "gpt-5.6-terra",
    "OMX_DEFAULT_SPARK_MODEL": "gpt-5.6-luna"
  },
  "models": {
    "default": "gpt-5.6-terra",
    "team": "gpt-5.6-sol",
    "team_low_complexity": "gpt-5.6-luna"
  }
}

极致质量入门配置（max-quality starter）

该配置通过省略 OMX_DEFAULT_STANDARD_MODEL 让标准 agent 继承 frontier 模型，保留快速 spark 通道作为默认低复杂度路由，并显式把部分 exact-pinned/生成角色提升到 max 质量模型、配以匹配的推理覆盖：

{
  "agentModels": {
    "planner": "gpt-5.6-sol",
    "architect": "gpt-5.6-sol",
    "researcher": "gpt-5.6-terra",
    "explore": "gpt-5.6-luna"
  },
  "agentReasoning": {
    "planner": "medium",
    "architect": "xhigh",
    "researcher": "high",
    "explore": "medium",
    "critic": "xhigh"
  },
  "env": {
    "OMX_DEFAULT_FRONTIER_MODEL": "gpt-5.6-sol",
    "OMX_DEFAULT_SPARK_MODEL": "gpt-5.6-luna"
  },
  "models": {
    "default": "gpt-5.6-sol",
    "team": "gpt-5.6-sol",
    "autopilot": "gpt-5.6-sol",
    "ralph": "gpt-5.6-sol",
    "team_low_complexity": "gpt-5.6-luna"
  }
}

验证生效配置

编辑 .omx-config.json 的 agentReasoning 或 config.toml 之后，请在与启动 OmX 相同的 shell 与项目形状下重新生成 setup 管理的 native agent TOML：

omx setup --force
omx doctor

omx doctor 会报告解析出的 setup scope、Codex home、配置路径、hook 覆盖、prompt/skill/agent 可用性，以及选定的 prompt-routing 状态。这能验证安装接线是否正确、OmX 检查的是哪棵配置树。

但需要注意：omx doctor 全绿并不证明当前 Codex profile 能认证或运行所选模型。为此，请在相同的 shell/profile/项目下运行：

codex login status
omx exec --skip-git-repo-check -C . "Reply with exactly OMX-EXEC-OK"

如果行为与配置不符，先确认你处于 user 还是 project scope，以及 CODEX_HOME 是否覆盖了预期的 Codex home。

相关文档与源码

• 通知与 OpenClaw 配置：docs/openclaw-integration.md、docs/discord-integration.md
• 项目 wiki 配置：docs/reference/project-wiki.md
• 模型路由源码：src/config/models.ts，测试见 src/config/tests/models.test.ts
• 通知配置源码：src/notifications/config.ts、src/notifications/types.ts、src/notifications/hook-config-types.ts
• OpenClaw 配置源码：src/openclaw/types.ts、src/openclaw/config.ts
• Prompt 路由配置源码：src/hooks/triage-config.ts
• Auto-nudge 配置源码：src/scripts/notify-hook/auto-nudge.ts
• Wiki 生命周期配置源码：src/wiki/types.ts、src/wiki/lifecycle.ts
• Agent 角色定义：src/agents/definitions.ts
• Native agent TOML 生成：src/agents/native-config.ts
• Team 模型契约：src/team/model-contract.ts
• Scope/Codex home 启动解析：src/cli/codex-home.ts

最后再强调一次本文的核心纪律：只添加你的安装版本认识的键。未知键不是稳定扩展点；畸形 JSON 或形状错误的分节可能被忽略，也可能让读取它的特性 fail closed。把 agentModels 用作持久的按角色模型面、把 agentReasoning 用作唯一的按 agent 推理面、把 models 用作模式级覆盖、把 env 用作回退环境值，然后交给 omx setup --force 与 omx doctor 验证，就能稳定驾驭 OmX 的模型与环境路由。