Loop Engineering循环工程这个说法正在从一种工作技巧变成一套可以标准化的工作方法。它的核心并不复杂把开发过程拆成“计划、生成、运行、观察、修复”的循环让 AI 在每个循环里完成一部分可验证的工作开发者只负责判断方向、审查结果和把报错喂回模型。真正让这套循环跑起来的关键是工具能否原生支持模型切换——在 Codex 和 Claude Code 这类终端 AI 编程工具里不退出会话、不丢上下文地切换模型决定了这个循环是流畅的还是被频繁重启打碎的。不少人在实际使用 Codex 或 Claude Code 时会遇到两类问题一类是安装和启动层面的比如claude命令不被识别、提示 native binary 没有安装另一类是接入第三方模型后出现的路由错误例如本地代理转发到 Codex endpoint 时返回 HTTP 400原因是reasoning_content没有回传。这些问题看起来零散其实都围绕同一个主题模型通道和模型切换机制没有梳理清楚。这篇文章会从 Loop Engineering 的概念讲起把 Codex 和 Claude Code 的原生模型切换方式、配置方法、典型报错和排查链路完整过一遍。1. 先理解 Loop Engineering 和原生模型切换1.1 Loop Engineering 是什么Loop Engineering 可以理解成一种以“循环”为单位组织 AI 开发的方式。传统的一次性提问是“用户给一个需求模型给一个答案”而循环工程把整个过程拆成多个小步骤明确一个可验证的子任务。让模型生成代码、命令或配置。运行测试、构建或脚本观察结果。把失败的报错、日志或差异反馈给模型。进入下一轮直到任务通过验证。这个流程和 TDD 的思想很像区别在于“执行者”变成了模型。循环的价值不在于某一轮生成得有多完美而在于状态被保留每一轮都知道上一轮做了什么、报了什么错、改了什么文件。这样模型不需要从头理解项目开发者也不需要反复粘贴上下文。真正适合 Loop Engineering 的工具至少要满足三个条件能在终端里执行命令、能读写项目文件、能在一个会话里持续保留上下文。Codex CLI 和 Claude Code 都符合这些条件所以它们成了这个工作流里最常见的选择。1.2 为什么模型切换是循环里的核心动作一个完整的循环里不同步骤对模型能力的要求差别很大。搭骨架、写测试桩、生成文档这类任务只需要模型对语法和常见模式足够熟练速度越快越好成本越低越好。但遇到一个很隐蔽的并发问题、一个诡异的构建报错、一段性能瓶颈就需要推理能力更强的模型慢慢分析。同一个循环里如果只能用同一个模型就会出现两种尴尬要么强模型做简单任务成本和延迟都高要么弱模型啃硬骨头循环转好几圈都出不来。原生模型切换解决的就是这个问题。它允许开发者在同一个会话中根据当前循环的难度动态选择模型简单任务切到快速模型复杂问题切到强推理模型收尾阶段再切回低成本模型。这样既不打断会话也不丢失上下文。1.3 “原生”切换和“非原生”切换的区别所谓原生切换是指工具自身就提供了模型选择能力比如命令行参数、配置文件、交互命令或环境变量。开发者不需要写外部脚本来替换模型标识不需要复制粘贴会话内容到另一个工具里。非原生切换的典型场景是开着一个 Codex 会话处理到一半发现模型能力不够只能把关键报错复制出来退出当前会话用另一个模型重新开启会话。这样做的代价很大上下文被截断模型对之前改过的文件失去了记忆同样的错误可能在下一轮重新犯一遍。原生切换的意义就在这里把“换模型”变成一次命令或一次配置修改而不是一次会话重建。Codex 和 Claude Code 在这方面的实现方式不同但目标一致——让模型切换成为循环中的一个普通操作。2. 环境准备把 Codex 和 Claude Code 安装到可复现状态2.1 安装前置条件在开始配置模型切换之前先确认本机环境满足基本要求。两个工具都依赖 Node.js 运行时所以 Node 版本是第一个检查点。检查项建议要求说明Node.js18 及以上两个 CLI 都基于 Node.js 分发版本过旧会导致安装失败npm9 及以上用于全局安装 CLI 包终端bash / zsh / PowerShell两个工具都需要交互式终端支持Git建议安装部分项目操作和依赖安装会用到API 凭证OpenAI / Anthropic 或兼容服务首次运行需要登录或配置密钥检查命令node -v npm -v git --version这里要注意不同时间点的 CLI 版本对 Node 版本要求可能不同。落地前先看官方 README 或 npm 包页面的 engines 字段不要凭经验跳过版本检查。2.2 安装命令与版本确认Codex CLI 和 Claude Code 都可以通过 npm 全局安装npm install -g openai/codex npm install -g anthropic-ai/claude-code安装完成后验证命令是否存在codex --version claude --version如果codex命令可以执行而claude提示“不是内部或外部命令”或“无法将 claude 项识别为 cmdlet”问题通常不在安装本身而在 npm 全局 bin 目录没有加入 PATH。用下面的命令查看全局目录npm config get prefix把输出目录下的 bin 路径加入系统 PATH再重开终端即可。Windows 下更容易遇到这个问题因为 PowerShell 不会自动加载新加入 PATH 的目录。另一个高频安装报错是error: claude native binary not installed. either postinstall did not run这个提示说明 npm 包安装时的 postinstall 脚本没有执行成功。常见原因有网络中断、权限不足或 npm 缓存异常。处理方式是按顺序尝试npm uninstall -g anthropic-ai/claude-code npm cache clean --force npm install -g anthropic-ai/claude-code如果还不行可以手动执行包内的 postinstall 脚本或者换成 Node 版本管理工具如 nvm重装 Node 后再安装 CLI。日常开发中不建议用sudo npm install -g来解决权限问题容易把全局目录权限弄乱。2.3 认证与配置目录要先对齐安装通过后下一步是认证。Codex 支持交互式登录和 API Key 两种方式Claude Code 类似。在正式配置模型切换前先把两个工具各自跑通一个最小请求codex exec print hello claude -p print hellocodex exec和claude -p都是非交互模式适合做连通性验证。如果这一步报认证失败后面所有模型切换配置都没有意义。两个工具的配置目录也需要提前知道工具配置文件作用Codex~/.codex/config.toml模型、provider、请求参数Codex~/.codex/auth.json登录凭据Claude Code~/.claude/settings.json全局设置可覆盖模型和环境变量Claude Code~/.claude.json会话和项目状态Claude Code项目内.claude/settings.json项目级设置注意auth.json和 API Key 属于敏感信息不要提交到 Git 仓库。配置文件和认证文件分开存放正是为了让配置可以分享、密钥必须保密。3. Codex 的原生模型切换配置、参数与会话保持3.1 Codex 的三种切换入口Codex CLI 提供三种模型切换入口使用场景不一样命令行参数codex exec --model 模型名适合单次任务临时指定。配置文件~/.codex/config.toml中的model字段适合固定项目默认模型。交互命令会话中输入/model适合在循环过程中动态切换。三者优先级从高到低一般是命令行参数高于交互命令交互命令高于配置文件。实际使用中最顺手的方式是默认模型写在配置文件里进入会话后根据任务难度用/model切换。3.2 用 config.toml 固定模型与自定义 providerCodex 的模型配置核心是~/.codex/config.toml。一个最小的配置示例model gpt-5.2 model_provider openai [model_providers.openai] name openai base_url https://api.openai.com/v1 env_key OPENAI_API_KEY各字段含义如下字段说明model默认使用的模型名称model_provider使用的 provider 名称对应下方配置块base_urlAPI 端点地址env_key读取 API Key 的环境变量名model_reasoning_effort推理强度设置影响模型分析深度这里的model_provider是关键。Codex 支持通过 provider 机制接入不同的 API 网关或兼容服务而不只是官方端点。这也是“原生”的体现不需要改代码不需要写代理脚本只需要在配置里声明 provider。如果要在不同模型之间做默认切换可以直接修改model字段。例如把默认模型切换为另一个推理能力更强的模型model gpt-5.5 model_reasoning_effort high需要注意模型名称和model_reasoning_effort的取值会随版本变化。配置前先确认当前 Codex 版本支持的模型列表不要照搬旧文档。3.3 切换模型时上下文是否保留很多新手担心一件事会话中途切换模型之前的对话会不会丢失在 Codex 里模型切换不会清空会话历史。会话的消息列表仍然保留切换模型后后续请求会带着同样的历史消息发给新模型。这一点非常重要它是 Loop Engineering 能成立的基础。想象一个场景代码跑出异常你在会话里把异常栈贴给模型模型分析后给出修复建议。此时如果想换一个更强的模型来验证这个建议直接切换模型新模型能看到完整的异常栈和分析过程不需要你重新粘贴一遍。不过有两个限制要注意切换模型后如果新模型不支持某些参数比如上一个模型开启了高推理强度而新模型不识别这个字段请求可能报错。遇到这种情况先用/model切换再调整对应参数。上下文窗口是有上限的。循环次数很多、贴入的日志很长时历史消息可能被截断。此时模型切换只能解决“能力”问题解决不了“上下文过长”问题。长期运行的会话要定期清理无用输出。4. Claude Code 的模型通道与切换方式4.1 交互式切换/model 与 /statusClaude Code 在交互模式下的模型切换更直观。进入会话后输入/model可以看到当前模型列表通过方向键选择目标模型。如果想确认当前会话正在使用哪个模型输入/status这个命令会输出当前模型、上下文使用情况、工作目录等信息。在循环工程里/status适合每个循环结束时做一次检查确认切换是否生效。4.2 环境变量与 settings.json 固定模型除了交互切换Claude Code 也支持通过环境变量和配置文件固定模型。常用的环境变量有export ANTHROPIC_MODELclaude-sonnet-4-5 export ANTHROPIC_SMALL_FAST_MODELclaude-haiku-4-5ANTHROPIC_MODEL控制主模型ANTHROPIC_SMALL_FAST_MODEL控制轻量快速任务使用的模型。这两个变量可以配合成一个策略主模型负责复杂推理快速模型负责摘要、提取等轻量操作。项目级配置写在.claude/settings.json{ env: { ANTHROPIC_MODEL: claude-sonnet-4-5 } }这样做的好处是项目团队可以统一模型基线每个成员 clone 代码后拉到同一份配置减少“为什么我用的模型和你不一样”这类问题。需要注意settings.json里如果包含密钥类环境变量不要提交到仓库。4.3 Codex 与 Claude Code 切换机制对比两种工具的原生模型切换各有特点对比如下对比项CodexClaude Code交互切换命令/model/model状态确认命令exec返回模型信息/status命令行临时指定codex exec --modelclaude -p --model配置文件~/.codex/config.tomlsettings.json环境变量OPENAI_API_KEY、provider 相关ANTHROPIC_MODEL自定义网关model_providers配置块ANTHROPIC_BASE_URL会话上下文保留切换后保留切换后保留从使用习惯上看Codex 更偏“配置文件驱动”适合把模型、provider、推理强度统一管理Claude Code 更偏“交互命令驱动”适合在会话过程中快速换模型。两者都能满足循环工程的需求选择哪个取决于团队已有的技术栈和模型订阅情况。5. 自定义网关接入第三方模型时最容易踩的 400 错误5.1 为什么会出现“本地代理”和自定义端点在真实团队里很少让每个开发者直接持有所有模型服务商的 API Key。更常见的做法是在中间加一层 API 网关或路由服务统一管理密钥、记录调用量、做成本统计还可以把请求路由到不同提供方。Codex 和 Claude Code 都支持通过配置把请求发往自定义端点。这种做法是合规的工程模式解决的是密钥统一管理、成本核算和模型路由问题。于是就有了类似下面这种报错出现的条件cc switch local proxy failed while handling codex endpoint /responses. provider: deepseek; model: deepseek-v4-flash; upstream_status: http 400; cause: the reasoning_content in the thinking mode must be passed back to the api.这条报错看起来复杂拆开来看其实只有三层信息请求经过了本地代理或配置切换工具转发到 Codex endpoint 的/responses接口。provider 是 DeepSeek模型是deepseek-v4-flash。上游返回 400原因是“思考模式下的reasoning_content必须回传给 API”。后面这个原因才是真正的根因。5.2 典型报错根因reasoning_content 没有被回传部分提供方在“思考模式”下模型生成的完整响应里除了正常回复内容还会带一个reasoning_content字段用于存放推理过程文本。这个字段在多轮对话里有特殊要求后续请求必须把上一次的reasoning_content原样带回去否则服务端无法还原推理状态直接返回 400。用请求样例说明。第一轮请求{ model: deepseek-v4-flash, messages: [ {role: user, content: 解释这段代码的并发问题} ] }第一轮响应{ choices: [ { message: { role: assistant, content: 这里存在一个竞态条件……, reasoning_content: 先看共享变量再看锁的粒度…… } } ] }第二轮请求必须把reasoning_content带回{ model: deepseek-v4-flash, messages: [ {role: user, content: 解释这段代码的并发问题}, { role: assistant, content: 这里存在一个竞态条件……, reasoning_content: 先看共享变量再看锁的粒度…… } ] }如果本地代理或配置切换工具在转发时只保留了content把reasoning_content丢弃上游就会报 400。这不是 Codex 本身的问题而是中间网关做了一次有损转换。排查时按这个顺序来读完整报错记录provider、model、upstream_status三个字段。打开代理或网关的请求日志查看发往上游的实际 payload。对比上游返回的响应体确认reasoning_content是否在后续请求里被保留。直接用 curl 模拟两轮请求绕过网关测试上游是否正常。如果绕过网关没问题问题就锁定在网关的字段转换逻辑上。curl 直连测试示例curl -X POST https://api.deepseek.com/v1/chat/completions \ -H Authorization: Bearer $DEEPSEEK_API_KEY \ -H Content-Type: application/json \ -d { model: deepseek-v4-flash, messages: [{role: user, content: hello}] }拿到响应后把 response 中的reasoning_content拼进第二条请求继续发送如果第二条请求成功说明上游没问题问题在网关。5.3 另一个高频报错模型不在支持列表里接入自定义 provider 时还会遇到一类模型名单校验错误。典型提示类似the gpt-5.6-sol model is not supported when using codex with a ...这种报错的意思是Codex 在发起请求前会校验模型名是否合法或者服务端返回了模型不支持的错误。常见原因有三个模型名写错比如多写或少写了后缀。自定义 provider 的服务端模型名单里没有这个模型。某些模型名是内部别名只在特定网关里有效直接发给上游服务不可用。处理方式也很直接先查询模型列表接口确认可用的模型名再检查 Codex 配置里写的模型名是否完全一致。查询模型列表的兼容写法curl -X GET https://api.example.com/v1/models \ -H Authorization: Bearer $API_KEY如果返回列表里没有配置中的模型名那就要么改配置要么换一个网关支持的别名。不要通过改报错信息、绕过校验的方式强行使用不存在的模型这是无效且危险的。5.4 网关类问题的通用预防建议网关选型和配置是循环工程里最容易被低估的一环。几个建议网关必须支持透传模型响应中的扩展字段比如reasoning_content、token 用量等。修改网关配置后先用一个两轮对话的最小脚本验证再进入正式循环。网关日志要保留原始请求和响应体否则排查 400 时无从下手。使用社区配置切换工具前先确认它是否支持目标提供方的完整字段尤其是推理类模型。6. 用一个小任务跑通“切换模型”的完整循环6.1 任务定义与循环设计用一个小任务验证整条链路写一个 Python 脚本统计文本文件中单词出现次数并配套一个测试用例。这个任务足够小能快速跑完又包含了编码、运行、测试、修复四个循环步骤可以完整演示模型切换。循环设计成三个阶段阶段一用快速模型生成脚本和测试目标是速度。阶段二运行测试后故意制造一个边界条件失败切到强推理模型分析原因。阶段三修完后切回快速模型做代码整洁度检查。6.2 循环中的实际命令先启动 Codex 非交互任务指定一个快速模型生成骨架codex exec --model gpt-5.2 \ create word_count.py that counts word frequency in a text file, add test_word_count.py运行测试python -m pytest test_word_count.py假如测试里有一个空文件边界用例失败进入交互模式把失败信息贴给模型codex进入会话后输入/model切换为强推理模型然后把测试输出粘贴过去要求修复测试报错如下 粘贴 pytest 输出 请定位原因并修复。修复完成后运行测试确认通过再输入/model切回快速模型做最终检查请检查 word_count.py 的代码风格和可读性不要改变功能。Claude Code 的流程类似只是交互命令换成claude进入会话后输入/model选择目标模型。在执行阶段也可以用命令行方式claude -p --model claude-sonnet-4-5 分析这个报错并修复6.3 验证与结果记录一个循环是否成功不能只看“最后测试通过了”。建议每个循环记录以下信息记录项说明当前模型该轮使用的模型名称任务类型生成、修复、审查还是重构轮次耗时从提交到模型返回的时间结果成功、失败或部分成功关键报错该轮遇到的错误关键字上下文长度会话消息递增情况把这些信息记在桌面便签或项目里的 LOOP_LOG.md 中运行几次后就能看到哪些任务用快速模型就够了哪些任务必须强推理模型帮一把切换模型带来的时间收益到底有多大。没有数据支撑模型切换很容易变成凭感觉操作。7. 高频报错速查与 Loop Engineering 最佳实践7.1 高频报错速查表把前面提到的报错和排查路径汇总成一张速查表适合贴到团队 Wiki 或项目 README 里问题现象常见原因检查方式处理建议claude不是内部或外部命令npm 全局 bin 不在 PATHnpm config get prefix把 bin 目录加入 PATH 后重开终端claude native binary not installedpostinstall 脚本未执行成功查看安装日志重装包或手动执行 postinstallcc switch local proxy failed ... reasoning_content网关丢弃了推理字段查看代理请求日志让网关透传reasoning_contentmodel is not supported模型名不在支持名单查询/models接口修正模型名或换网关别名认证失败API Key 未设置或过期检查环境变量和 auth 文件重新登录或更新密钥切换模型后请求报错新模型不支持旧参数查看请求参数清掉不兼容参数后重新请求7.2 Loop Engineering 的最佳实践几个经过反复验证的做法第一模型按任务分档而不是按心情切换。建议在项目配置里固定三档快速模型负责生成骨架、摘要、格式化主力模型负责常规开发强推理模型只在循环卡住时切换。分档规则写入 README避免团队成员各用各的模型导致结果无法复现。第二循环中的报错信息要完整不要截断。贴报错时尽量包含异常类型、堆栈前几行、命令退出码。模型对信息的敏感度很高少一行关键输出可能就多两轮循环。第三上下文是成本不是免费的。每个循环结束及时用/status或codex的会话信息检查上下文占用。日志、测试输出、大段配置文件都吃上下文。能用一句话总结的报错就不要把整个日志原文贴进去。第四配置外置且分层。全局配置放用户目录项目配置放仓库内敏感信息走环境变量。这样新成员加入时不需要手动复制模型配置也不会把密钥带到仓库。7.3 上线前检查清单在把 Loop Engineering 工作流交给团队之前按下面的清单过一遍[ ] Node.js 和 npm 版本符合两个 CLI 的要求。[ ]codex --version和claude --version都能正常输出。[ ] 两个工具的最小非交互请求都通过。[ ] 全局配置和项目配置已经分离。[ ] 模型名和 provider 配置经过模型列表接口验证。[ ] 使用自定义网关时完成两轮对话的透传测试。[ ]reasoning_content等扩展字段在网关日志中可见。[ ] API Key 没有写入任何配置文件。[ ] 团队成员知道/model和/status的基本用法。[ ] 每个循环的结果记录模板已就绪。模型切换本身不复杂复杂的是把切换动作放进一个可持续的循环里。Codex 和 Claude Code 的原生支持已经解决了“不丢上下文换模型”这个核心问题剩下的就看你怎么组织任务、记录结果、控制上下文和排查网关问题。建议从一个小型重构任务开始记录每轮切换前后的模型、耗时和输出质量先找到自己项目里最损耗时间的那一环再把模型切换配置固化到项目配置里。
