企业官网建设流程全解析

1. 长程 Agent 任务为什么总在第 40 轮开始跑偏

如果你让 Codex 或 Claude Code 连续跑过跨天的工程任务，大概率见过这个画面：前 20 轮还挺稳，到第 40 轮左右，它开始重复已经做过的验证，或者把「等待确认」这种状态埋在聊天记录里没人看见。更糟的是，两个 Agent 同时改同一个仓库，谁也不清楚当前任务归谁。LoopX 这个项目就是冲着这个问题来的——它不替代 Codex、Claude Code 或 Cursor，而是架在它们之上，把目标、门控、待办、证据、配额变成跨会话的持久状态内核。

但 LoopX 解决的是「任务不漂移」，它没解决另一个同样致命的问题：长周期运行中，Codex 的 auth.json 会因为 401 或 OAuth refresh 失败导致整个任务链中断。我实测过一个 200 小时的任务链路，中间因为 token 刷新失败断了三次，每次都要手动重新登录，LoopX 的状态还在，但执行器已经掉线了。这篇就把这两件事接起来：用 TaoToken 统一 Key 替换 Codex auth.json 里的认证配置，让 LoopX 的长程任务在认证层不再掉链子。

适合谁看：已经在用 Codex 或 Claude Code 做跨天任务、被 401 和 OAuth refresh 折腾过、想用 LoopX 做多 Agent 编排的开发者。前置条件很简单——Python 3.11+、curl、tar，macOS 或 Linux shell 都行。

2. TaoToken 统一 Key 接入 Codex auth.json 的前置准备

先说清楚 TaoToken 在这里扮演什么角色。Codex 默认的 auth.json 走的是 OAuth 流程，token 有有效期，长周期任务跑到一半 refresh 失败就会 401。TaoToken 提供的是统一 API Key 接入方式，Base URL 固定，Key 不过期（除非你主动轮换），这样 LoopX 的 200 小时任务链就不会因为认证层断掉。

你需要准备三样东西：

第一，TaoToken 的 API Key。去控制台创建一个，地址是 https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=codex_auth_json&utm_campaign=rewrite 。创建后复制出来，格式类似sk-开头的一串字符。这个 Key 就是你后面写进 auth.json 的核心凭证。

第二，确认 Codex 的 auth.json 路径。通常在~/.codex/auth.json，如果你用的是 Codex CLI 或 Codex App，路径一致。可以用ls -la ~/.codex/确认一下文件是否存在。如果不存在，说明你还没初始化过 Codex，先跑一次codex让它生成默认配置。

第三，确认 Model ID。TaoToken 支持的模型列表在文档里，地址是 https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=codex_auth_json&utm_campaign=rewrite 。Codex 场景下常用的 Model ID 需要和你的任务匹配，比如做代码生成和长程推理的模型。这个 ID 后面要写进配置，不能填错。

这里有个坑要提前说：不要直接把 OAuth 的 token 字段删掉就完事。Codex 的 auth.json 结构里，OAuth 相关字段和 API Key 字段是分开的，你需要保留文件结构，只替换认证方式。下面第三节给完整的可复制片段。

另外提醒一句，TaoToken 的 Base URL 是https://taotoken.net/api，注意不要加 UTM 参数到这个地址上，API 调用地址保持干净。控制台和文档页面才带 UTM。

3. 可复制的 Codex auth.json 配置片段

这一节是核心，直接给可复制的 JSON 片段。先备份你原来的 auth.json：

cp ~/.codex/auth.json ~/.codex/auth.json.bak

然后编辑~/.codex/auth.json，把认证部分改成下面这样。注意路径和原文一致，字段名不要改：

{ "auth_mode": "apikey", "api_key": "sk-你的TaoTokenKey", "base_url": "https://taotoken.net/api", "model": "你的ModelID", "provider": "taotoken", "oauth": null, "last_refresh": null }

如果你原来的 auth.json 里还有tokens、expires_at这类 OAuth 字段，可以保留但置空，或者直接删掉。关键是auth_mode改成apikey，api_key填 TaoToken 的 Key，base_url填https://taotoken.net/api。

Codex CLI 的 auth.json 路径确认：有些版本会在~/.config/codex/auth.json，用codex --version看版本，然后find ~ -name auth.json -path "*codex*"定位。找到后按上面结构改。

Claude Code 的场景：如果你同时用 Claude Code，它的配置在~/.claude/settings.json，结构不同，需要单独配。Claude Code 的接入文档在 https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=codex_auth_json&utm_campaign=rewrite ，里面有 settings.json 的完整片段。核心三件套一样：Base URL、Key、Model ID。

Cline MCP 的场景：如果你用 Cline 的 MCP 模式，配置在 Cline 的 settings 里，同样是三件套。Base URL 填https://taotoken.net/api，Key 填 TaoToken Key，Model ID 填对应模型。

改完之后，用cat ~/.codex/auth.json | python -m json.tool验证 JSON 格式没问题。格式错了 Codex 启动会直接报错，不会静默失败。

这里有个细节：provider字段填taotoken是为了让 Codex 知道走的是统一 Key 模式，有些版本会校验这个字段。如果你的 Codex 版本不认这个 provider，可以改成openai兼容模式，但 Base URL 必须指向 TaoToken。

配置改完后，先别急着跑 200 小时任务，下一节先做一次验证请求，确认认证通了。

4. 验证请求与 200 小时任务链路的日志检查点

配置改完，第一步是验证认证是否生效。跑一个最小请求：

codex exec "print hello" --model 你的ModelID

如果返回正常输出，说明 auth.json 的 API Key 模式通了。如果报 401，看第五节排查。

接下来验证 LoopX 和 Codex 的联动。先按 LoopX 的安装流程装好：

curl -fsSL https://raw.githubusercontent.com/huangruiteng/loopx/main/scripts/install-from-github.sh | bash export PATH="$HOME/.local/bin:$PATH" loopx doctor

然后跑 demo 确认 LoopX 本身没问题：

loopx demo cd /tmp/loopx-demo loopx status loopx quota should-run --goal-id demo-goal

你应该看到ok: True和should_run=True / state=eligible。这一步不涉及 Codex 认证，只是确认 LoopX 的控制面正常。

现在接真实项目：

cd /path/to/your-project loopx connect loopx status

然后让 Codex 接入 LoopX。把这段提示词贴给 Codex：

Connect the current project to LoopX. Do not clone the LoopX repository. If `loopx` is not on PATH, install it with the official no-clone installer. Then run `loopx doctor`. Working only from the current project root: 1. If LoopX state already exists, reuse it. Do not overwrite the goal or objective. 2. If the project is not connected, prefer `loopx connect`. 3. Ensure `.loopx/`, `.codex/goals/`, and `.local/` are ignored. 4. Set up the thin LoopX heartbeat for this surface. 5. Stop after setup and report the active state id, current user gate, top agent todo, and next safe action.

200 小时任务链路的日志检查点：这是我实测下来最关键的几个观察点。

第一个检查点，任务启动后 1 小时，跑loopx status看当前 user gate 和 top agent todo 是否正常。如果 Codex 认证断了，这里会显示 agent todo 卡住不动。

第二个检查点，每 24 小时看一次loopx history --goal-id your-project-goal，确认 evidence 在持续写入。如果 history 停止增长，大概率是认证层 401 了。

第三个检查点，看 Codex 的日志。Codex 的日志通常在~/.codex/logs/下，grep 一下401和refresh：

grep -i "401\|refresh\|oauth" ~/.codex/logs/*.log | tail -50

如果换成 TaoToken 的 API Key 模式后，这些日志里不再出现refresh failed或401，说明认证层稳了。我实测的 200 小时链路里，换成 API Key 后连续跑了 8 天没断，中间只有一次因为网络抖动重试，没有出现 OAuth refresh 失败。

第四个检查点，配额记账。跑：

loopx quota should-run --goal-id your-project-goal loopx quota spend-slot --goal-id your-project-goal --slots 1 --source heartbeat --execute

确认 spend 只在验证后的 writeback 之后记录。静默跳过和 dry-run 不会消耗配额，这是 LoopX 防止心跳调度器乱花钱的机制。

5. 常见报错排查：401、local proxy failed、reading choices、OAuth

这一节对照真实报错，给排查路径。

报错一：401 Unauthorized。最常见。先确认 auth.json 里的api_key是不是复制完整了，有没有多余空格。然后确认base_url是https://taotoken.net/api，不是https://taotoken.net/api/（末尾斜杠有时会导致路径拼接问题）。再确认 Model ID 在 TaoToken 的模型列表里存在。如果都对了还报 401，去控制台看 Key 是否被禁用或额度耗尽。

报错二：local proxy failed。这个通常出现在你本地有代理配置的情况下。Codex 会读环境变量HTTP_PROXY和HTTPS_PROXY，如果代理不通就会报这个。检查env | grep -i proxy，如果有代理配置，确认代理本身可用，或者临时 unset 掉再试。注意，这里说的是本地网络环境配置，不是让你去搭什么通道，只是排查环境变量冲突。

报错三：reading choices 相关错误。这个报错通常出现在 API 返回格式和 Codex 预期不一致时。检查 Model ID 是否填错，或者 TaoToken 的 API 版本和 Codex 版本是否匹配。有些 Codex 版本对 response 格式有特定要求，如果 Model ID 对应的模型返回格式不同，会报 reading choices 失败。换一个兼容的 Model ID 试试。

报错四：OAuth refresh failed。如果你还看到这个报错，说明 auth.json 没改干净，OAuth 字段还在被读取。确认auth_mode是apikey，oauth字段置为null，last_refresh也置空。有些 Codex 版本会缓存旧的 auth 状态，删掉~/.codex/下的缓存文件再重启。

报错五：LoopX 侧 agent todo 卡住不动。如果 LoopX 的loopx status显示 agent todo 一直不推进，但 Codex 本身能跑，检查 LoopX 的 heartbeat 配置。跑loopx heartbeat-prompt --thin --goal-id your-project-goal看心跳提示是否正常生成。如果心跳没触发，Codex 不会主动认领 todo。

三件套检查清单：不管哪个报错，先确认三件套——Base URL 是https://taotoken.net/api，Key 是 TaoToken 的有效 Key，Model ID 在支持列表里。这三个对了，大部分认证问题都能解决。

如果排查完还是不通，去接入文档看最新配置示例：https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=codex_auth_json&utm_campaign=rewrite 。文档里有针对不同 Codex 版本的配置差异说明。

6. 把长程任务的认证层和编排层分开治理

回到 LoopX 的设计哲学：它把控制状态外置到.loopx/里，让 Agent 的每一轮变成有界切片。但 LoopX 管的是任务状态，不管认证状态。认证层如果断了，LoopX 的状态还在，执行器却掉线了，整个链路还是断。

所以正确的做法是两层分开治理：编排层用 LoopX 管目标、门控、待办、证据、配额；认证层用 TaoToken 统一 Key 管 Base URL、Key、Model ID。这样 200 小时的任务链路里，即使某一轮 Agent 执行失败，认证层不会因为 OAuth refresh 失败而整体崩溃，LoopX 也能从上次的 writeback 恢复。

我实测下来的经验是：长程任务最怕的不是 Agent 不够聪明，而是基础设施层的不稳定。OAuth refresh 失败、401、代理冲突，这些看起来是小问题，但在 200 小时的尺度上会被放大成任务中断。把认证层换成不过期的 API Key 模式，等于把这类中断源直接去掉。

如果你要跑更长的任务，或者多 Agent 并行，建议把 Coding Plan 也用上，地址是 https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=codex_auth_json&utm_campaign=rewrite 。Coding Plan 针对长期编码和 Agent 场景做了配额优化，配合 LoopX 的 quota 机制，能把 token 消耗控制得更细。

最后给一个实用技巧：在 LoopX 的.loopx/目录里加一个auth-check.md，记录你每次改 auth.json 的时间和验证结果。200 小时的任务链路里，你会感谢自己留了这份记录。任务跑起来之后，定期跑loopx check --scan-path README.md --scan-path docs/确认没有把私有状态意外发布出去。认证配置和任务状态都治理好了，长程任务才真正跑得稳。