1. 夜间批量任务为什么总在凌晨断掉如果你把 Claude Code 或 Codex 挂在终端里跑批量重构第二天早上大概率会看到两种结果一种是任务确实跑完了但中间某几次请求返回了 502另一种更常见——进程还在但日志停在凌晨两点后面全是重试超时。很多人第一反应是模型不行、上下文太长、任务太复杂但把日志翻出来逐行看真正卡住的位置往往跟模型推理无关而是请求在链路上被掐断了。我试过把同一个重构任务分别跑在直连和固定 endpoint 两种配置下直连那晚在 3 小时 17 分左右开始出现ECONNRESET之后每 5 分钟重试一次直到早上都没恢复换成固定 endpoint 后同样的任务连续跑了 6 小时 40 分中间只有两次正常的 429 限流退避没有一次因为通道问题中断。差别不在模型在于请求出口是否稳定。夜间批量任务的特殊性在于它没有人盯着没有交互式重试一旦某次请求失败且客户端没有正确退避整个 Agent 循环就会卡死在一个状态上。Claude Code 的 agentic loop 和 Codex 的 exec 模式都会在请求失败后进入等待如果失败原因是网络层而不是模型层等待时间会非常长。所以让它们稳定跑一整晚核心动作只有一个把 endpoint 固定到一个可控的入口让请求失败的原因收敛到「限流」和「业务错误」这两类可处理的情况而不是「通道抖动」这种没法处理的情况。这篇文章拆的就是这个工作流怎么改 endpoint、auth.json 里哪些字段必须对齐、连续跑 6 小时要看哪些日志、以及最常见的几个报错怎么排。适合已经在用 Claude Code 或 Codex 做自动化、但被夜间中断折磨过的人。2. 把 endpoint 固定到 TaoToken 的前置准备在改配置之前先把三件套对齐Base URL、API Key、Model ID。这三者任何一个不匹配夜间任务都会以 401 或 404 的形式断掉而且断得毫无规律因为有些客户端只在第一次请求时校验后续请求复用连接就不报错了等你发现时已经跑了几个小时。TaoToken 的 API 入口是https://taotoken.net/api这个地址不带任何查询参数直接作为 Base URL 使用。注意不要把它和官网地址混用官网是https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content那是给人看的页面不是给客户端请求的。客户端只认/api这个路径。API Key 在控制台的 API Keys 页面生成生成后只显示一次复制下来存到环境变量里不要硬编码进配置文件。Model ID 要跟你实际调用的模型对齐Claude Code 走 Anthropic 协议时用 Claude 系列模型 IDCodex 走 OpenAI 兼容协议时用对应的模型 ID两者不要混。前置准备清单一个可用的 API Key存到TAOTOKEN_API_KEY环境变量确认 Base URL 为https://taotoken.net/api确认要用的 Model ID写进配置本地或远程环境能访问该地址用 curl 测一次这里有个容易踩的坑很多人把 Base URL 写成https://taotoken.net/api/带尾斜杠某些客户端拼接路径时会变成//v1/messages服务端返回 404但错误信息里不会明确说是路径问题只会说 model not found误导排查方向。所以 Base URL 结尾不要带斜杠。另外夜间任务建议在远程 Linux 主机上跑本地笔记本合盖休眠会直接杀掉进程这跟 endpoint 无关但会伪装成「通道中断」。用 tmux 挂住会话SSH 断了任务还在。这一步做完再进入配置环节。3. 可复制的 endpoint 配置与 auth.json 字段这一节给三套配置Claude Code 的 settings、Codex 的 auth.json、以及通用的环境变量方式。三套都基于同一个 Base URL 和同一个 Key只是客户端读取位置不同。3.1 Claude Code 的 settings.jsonClaude Code 读取~/.claude/settings.json把 endpoint 和 key 写进去{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: sk-你的key, ANTHROPIC_MODEL: claude-sonnet-4-20250514 }, permissions: { allow: [ Bash(git *), Bash(npm *), Bash(pytest *) ] } }注意ANTHROPIC_BASE_URL不要带/v1Claude Code 会自己拼/v1/messages。如果你写成https://taotoken.net/api/v1最终请求会变成/api/v1/v1/messages直接 404。这是夜间任务最常见的配置错误之一。permissions.allow里把夜间任务需要的命令放开避免 Agent 在凌晨卡在权限确认上。但只放开任务必需的不要用Bash(*)全放开。3.2 Codex 的 auth.jsonCodex 读取~/.codex/auth.json字段名跟 Claude Code 不同{ OPENAI_BASE_URL: https://taotoken.net/api, OPENAI_API_KEY: sk-你的key, OPENAI_MODEL: gpt-5-codex, provider: openai }Codex 的OPENAI_BASE_URL同样不带/v1它会拼/v1/chat/completions或/v1/responses取决于模型。如果你用的是 Codex 的 exec 模式跑批量任务还要在~/.codex/config.toml里确认model_provider指向正确的 providermodel_provider openai model gpt-5-codex [model_providers.openai] base_url https://taotoken.net/api env_key OPENAI_API_KEYTOML 和 JSON 两处都要对齐只改一处会出现「auth.json 读到了但 config.toml 还在用默认地址」的情况表现为部分请求走旧地址、部分走新地址日志里看起来像随机中断。3.3 环境变量方式通用如果你不想改配置文件或者要在 CI 里跑用环境变量export ANTHROPIC_BASE_URLhttps://taotoken.net/api export ANTHROPIC_API_KEYsk-你的key export OPENAI_BASE_URLhttps://taotoken.net/api export OPENAI_API_KEYsk-你的key环境变量的优先级通常高于配置文件但不同客户端行为不一致建议只保留一种方式避免排查时搞不清哪个生效了。3.4 三件套对照表客户端Base URL 字段Key 字段Model 字段配置文件路径Claude CodeANTHROPIC_BASE_URLANTHROPIC_API_KEYANTHROPIC_MODEL~/.claude/settings.jsonCodexOPENAI_BASE_URLOPENAI_API_KEYOPENAI_MODEL~/.codex/auth.jsonCodex TOMLbase_urlenv_keymodel~/.codex/config.toml三件套必须同时对齐缺一个都会在夜间任务里以不同形式爆出来。改完配置后先别急着跑长任务用下一节的验证请求确认一次。4. 验证请求与连续 6 小时日志观察配置改完先用一条最小请求确认链路通。Claude Code 用curl -s https://taotoken.net/api/v1/messages \ -H x-api-key: $ANTHROPIC_API_KEY \ -H anthropic-version: 2023-06-01 \ -H content-type: application/json \ -d { model: claude-sonnet-4-20250514, max_tokens: 64, messages: [{role: user, content: reply with ok}] }返回里如果有content字段且stop_reason是end_turn说明 Base URL、Key、Model 三件套都对。如果返回 401是 Key 问题返回 404大概率是 Base URL 带了多余路径返回 400 且提示 model 不存在是 Model ID 写错。Codex 用curl -s https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $OPENAI_API_KEY \ -H content-type: application/json \ -d { model: gpt-5-codex, messages: [{role: user, content: reply with ok}], max_tokens: 64 }两条都通了再挂夜间任务。挂的时候把日志重定向到文件方便第二天分析tmux new -s night-agent claude --dangerously-skip-permissions -p 按 TASK.md 执行重构任务 21 | tee -a ~/logs/night-$(date %F).log--dangerously-skip-permissions只在隔离环境用配合前面 settings.json 里的 allow 列表避免凌晨卡权限确认。连续跑 6 小时后看日志里这几个指标第一请求成功率。用 grep 统计grep -c HTTP 200 ~/logs/night-2025-01-01.log grep -c ECONNRESET\|ETIMEDOUT\|502\|503 ~/logs/night-2025-01-01.log如果 502/503 出现次数为 0说明通道稳定如果出现但后面跟着成功的重试说明退避逻辑生效了可以接受如果出现后没有恢复说明客户端退避策略有问题需要调max_retries。第二请求间隔。正常 agentic loop 的请求间隔在几秒到几十秒如果日志里出现超过 5 分钟的空白说明卡住了。用 awk 算时间差awk /timestamp/ {print $1} ~/logs/night-2025-01-01.log | \ awk NR1 {print $1-prev} {prev$1} | sort -rn | head第三token 消耗曲线。如果某段时间 token 消耗突然归零说明请求没发出去。这个要结合客户端自己的 usage 日志看。实测下来配置正确的情况下6 小时连续运行只会看到两类日志正常的请求成功记录和偶发的 429 限流退避。任何ECONNRESET、ETIMEDOUT、502都不应该出现。如果出现了按下一节排查。5. 夜间任务常见报错排查5.1 401 Unauthorized日志里出现401且提示invalid api key先确认环境变量有没有被覆盖。Claude Code 会优先读ANTHROPIC_API_KEY如果你在 shell 里 export 了一个旧 keysettings.json 里的新 key 就不生效。用env | grep ANTHROPIC确认当前生效的值。另一个原因是 key 复制时带了空格或换行。把 key 用echo -n $ANTHROPIC_API_KEY | wc -c看长度跟控制台显示的长度对比。5.2 local proxy failed / connection refused这个报错说明客户端在尝试连本地代理而不是直连 Base URL。常见于之前配过代理工具、环境变量里残留了HTTP_PROXY或HTTPS_PROXY。夜间任务里这个报错特别隐蔽因为白天手动跑可能走的是另一套 shell 配置。排查env | grep -i proxy如果有输出在启动夜间任务前 unsetunset HTTP_PROXY HTTPS_PROXY ALL_PROXY然后在同一个 tmux 会话里启动任务确保环境干净。5.3 reading choices 相关报错日志里出现error reading choices或unexpected response format通常是响应体不是预期的 JSON 结构。原因可能是 Base URL 指向了一个返回 HTML 的地址比如误填了官网地址或者 Model ID 跟协议不匹配用 Anthropic 协议调了 OpenAI 模型。确认 Base URL 是https://taotoken.net/api不是官网地址。确认 Claude Code 用 Anthropic 协议、Codex 用 OpenAI 协议不要交叉。5.4 OAuth 相关报错如果日志里出现OAuth token expired或refresh token failed说明客户端在走 OAuth 流程而不是 API Key。Claude Code 和 Codex 都支持两种认证方式夜间任务必须用 API KeyOAuth 的 token 有效期短凌晨过期后无法自动刷新。检查~/.claude/settings.json里有没有oauth相关字段有就删掉只保留ANTHROPIC_API_KEY。Codex 同理auth.json里只保留OPENAI_API_KEY。5.5 报错对照表报错关键词最可能原因排查动作401 invalid api keykey 被环境变量覆盖或带空格env grep 长度检查local proxy failed残留代理环境变量unset HTTP_PROXYreading choicesBase URL 或协议不匹配确认 /api 路径 协议OAuth token expired用了 OAuth 而非 API Key删掉 oauth 字段404 model not foundBase URL 带 /v1 或 Model ID 错去掉尾斜杠 核对 Model ID排障时优先看第一条报错后面的报错往往是第一条的连锁反应。比如 401 之后客户端会重试重试时可能触发 OAuth 流程日志里就同时出现 401 和 OAuth 报错但根因只有一个。6. 把夜间任务跑成可复用的工作流配置和排障都过了之后剩下的就是把整套动作固化成脚本下次直接跑。我自己的做法是写一个night-run.sh里面做四件事检查环境变量、启动 tmux 会话、跑任务、把日志按日期归档。#!/bin/bash set -e export ANTHROPIC_BASE_URLhttps://taotoken.net/api export ANTHROPIC_API_KEY$TAOTOKEN_API_KEY unset HTTP_PROXY HTTPS_PROXY ALL_PROXY LOG~/logs/night-$(date %F).log mkdir -p ~/logs tmux new-session -d -s night claude --dangerously-skip-permissions -p \$(cat TASK.md)\ 21 | tee -a $LOG echo started, log at $LOG第二天早上先看日志尾部的stop_reason如果是end_turn说明任务正常结束如果是max_turns或空说明中途卡住了用第 4 节的 awk 命令找时间空白点。长期跑的话建议把 API Key 和 Base URL 的管理集中到一处比如用.env文件配合 direnv避免每个项目都要重新配。TaoToken 的控制台可以生成多个 Key给不同项目分配不同的 Key这样某个 Key 出问题时不会影响其他夜间任务。最后一点经验夜间任务不要一次跑太复杂的重构拆成多个小任务串行跑每个任务单独提交 Git这样即使某个任务失败前面的成果还在。Agent 的稳定性不只取决于 endpoint也取决于任务粒度。粒度越细单次失败的影响越小第二天恢复的成本越低。