1. Codex 审 PR 的第一道坎不是 Prompt是 Key 怎么排队用 Codex 跑 PR 审查最容易被低估的一步是把 Key 池管起来。TaoToken 的控制台https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentcodex_pr_keypool只负责发 Key并给出统一的 Base URLhttps://taotoken.net/api剩下的排队、冷却、故障切换逻辑得由你的 PR 机器人自己写。近期 Codex 的产品线动作挺密集Linear 那边负责过 Agent 化产品的人被拉去做 Codex 与 ChatGPT 的产品工作信号很明确Codex 正在从补全插件变成能读仓库、改文件、跑测试、发 PR 的执行体。一旦它开始承担这类任务PR 审查就成了最典型的落地场景也最快暴露工程问题。原因不复杂。PR 审查和普通对话的负载特征完全不同单次请求上下文长一个 diff 加上下文可能几万 token触发时间集中一个仓库一次 push 可能同时打开好几个 PR运行位置尴尬CI 里没有人盯着失败就是失败。这三个特征叠加最先崩的通常不是模型质量而是 Key 的使用方式。很多人第一次接 Codex 做审查都是把一把 Key 塞进环境变量然后让 CI 直接打。单仓库、单人、串行跑没问题。一旦变成多仓库共享、并发触发、有人手动补跑401 和 429 就会交替出现日志里只剩一行review failed排查成本极高。这一篇不聊模型选型也不复述新闻。下面给的是可跟做的部分config.toml怎么改、Key 池怎么写、PR 审查请求怎么发、并发对照怎么测。TaoToken 在这里只承担两件事——提供 Key提供 Base URL。它是通道不是审查逻辑的替代品审查规则、分块策略、失败回滚仍然要你自己设计。顺带说一句边界下文所有涉及仓库、数据库、命令的操作都在你本地或 CI 沙箱内执行不要让 Agent 直接持有生产库凭据也不要给它可写的高权限 Token。PR 审查 Agent 的权限应该尽可能小最好只读代码、只产出文本。2. 把 Codex 指向 TaoTokenconfig.toml 的最小改动Codex CLI 的供应商配置落在~/.codex/config.toml。核心只有三行base_url、env_key、wire_api。把base_url指向 TaoToken 的 API 入口即可Key 不写死在文件里用环境变量注入。# ~/.codex/config.toml # 默认走 TaoToken 这个 provider model_provider taotoken # 按你实际可用的模型名填写不要照抄 model gpt-5-codex [model_providers.taotoken] name TaoToken # 注意Base URL 不带任何查询参数 base_url https://taotoken.net/api # Key 从环境变量读取避免提交进仓库 env_key TAOTOKEN_API_KEY # Codex 默认走 responses 协议若你的调用方式不同再切换 wire_api responses # 给 PR 审查单独开一个 profile [profiles.pr-review] model_provider taotoken model gpt-5-codex # 只读沙箱审查任务不需要写权限 sandbox_mode read-only # 非交互场景不要让它在 CI 里停下来等人确认 approval_policy never环境变量这样注入# 单 Key 场景 export TAOTOKEN_API_KEYYOUR_API_KEY # 验证配置是否生效 codex --profile pr-review 读取当前目录的 git diff输出风险点清单这里有两个坑很常见。第一base_url后面不要随手补/v1或者斜杠。配置项按你实际使用的调用方式填写如果后续请求出现 404先检查是不是路径被拼接成了/api/v1/v1/chat/completions。第二不要把 Claude Code 的那套环境变量混进来。Claude Code 侧用的是ANTHROPIC_*系列变量和settings.jsonCodex 侧用的是config.toml加env_key两套配置属于两个不同的客户端。你在同一台机器上同时维护两条工作流最容易犯的错就是把ANTHROPIC_BASE_URL抄到 Codex 的配置里然后困惑为什么请求发不出去。两边都指向 TaoToken 是可以的但变量名必须各归各位。如果你还管理着 Claude Code 那侧的工作流Key 的创建入口是同一个在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentcodex_pr_keypool_2 拿到 Key 之后Codex 用config.toml的env_keyClaude Code 用settings.json的 env 段互不干扰。3. Key 池的三个状态位in-flight、cooldown、failure单 Key 换成 Key 池不是简单地随机取一个。你需要给每把 Key 维护三个状态inflight当前正在被多少请求占用用来控制单 Key 并发上限cooldown_until触发限流后的冷却截止时间戳failures连续失败次数超过阈值就把它踢出可用列表。下面是一个可以直接跑的最小实现不依赖第三方库只用标准库加requests。# key_pool.py import os import time import threading from dataclasses import dataclass, field dataclass class KeyState: key: str inflight: int 0 cooldown_until: float 0.0 failures: int 0 total_calls: int 0 class KeyPool: def __init__(self, keys, max_inflight_per_key2, cooldown_seconds60): self._lock threading.Lock() self._states [KeyState(k) for k in keys] self.max_inflight max_inflight_per_key self.cooldown cooldown_seconds classmethod def from_env(cls, env_nameTAOTOKEN_KEYS, **kwargs): raw os.environ.get(env_name, ) keys [k.strip() for k in raw.split(,) if k.strip()] if not keys: raise RuntimeError(f{env_name} 为空无法初始化 Key 池) return cls(keys, **kwargs) def acquire(self, timeout30.0): deadline time.time() timeout while time.time() deadline: now time.time() with self._lock: # 先挑冷却结束、并发未满、失败次数最少的 candidates [ s for s in self._states if now s.cooldown_until and s.inflight self.max_inflight and s.failures 5 ] if candidates: chosen min(candidates, keylambda s: (s.inflight, s.failures, s.total_calls)) chosen.inflight 1 chosen.total_calls 1 return chosen time.sleep(0.2) raise TimeoutError(Key 池中没有可用 Key检查并发上限或冷却时间) def release(self, state, okTrue, retry_afterNone): with self._lock: state.inflight max(0, state.inflight - 1) if ok: state.failures 0 else: state.failures 1 wait retry_after or self.cooldown state.cooldown_until time.time() wait def snapshot(self): with self._lock: now time.time() return [ { tail: s.key[-6:], inflight: s.inflight, cooling: now s.cooldown_until, failures: s.failures, calls: s.total_calls, } for s in self._states ]用法上Key 从环境变量TAOTOKEN_KEYS注入逗号分隔export TAOTOKEN_KEYSYOUR_API_KEY,YOUR_API_KEY_2,YOUR_API_KEY_3为什么要有inflight这个状态因为限流通常和瞬时并发相关而不是和总量相关。你在一秒内打 20 个请求和在一分钟内打 20 个请求结果可能完全不同。把单 Key 并发钉在 2 到 4 之间再配合冷却稳定性会明显好于随机取一把直接打。snapshot()是为后面的并发对照实验准备的它让你能在压测过程中每隔几秒打一次状态看清楚是哪把 Key 先进入冷却。4. 从 diff 到审查结论可复现的请求骨架PR 审查 Agent 的输入是 diff输出是结构化的问题清单。中间这一步很多人直接整段塞进 Prompt结果遇到大 PR 就超上下文。正确的做法是先本地切分再逐块请求。先在本地生成 diff这一步由读者在仓库里执行# 取到完整历史避免浅克隆导致 diff 为空 git fetch origin main --quiet # 生成三点 diff只保留目标分支引入的改动 git diff --unified3 origin/main...HEAD /tmp/pr.diff # 看一眼规模和文件分布 wc -l /tmp/pr.diff grep -c ^diff --git /tmp/pr.diff按文件切块而不是按字符切块。按文件切的好处是每个请求的上下文语义完整审查结论也能对应到具体路径。# split_diff.py import re def split_by_file(diff_text, max_chars40000): parts re.split(r(?^diff --git ), diff_text, flagsre.MULTILINE) chunks, current, size [], [], 0 for part in parts: if not part.strip(): continue if size len(part) max_chars and current: chunks.append(.join(current)) current, size [], 0 current.append(part) size len(part) if current: chunks.append(.join(current)) return chunks然后是请求骨架。base_url是https://taotoken.net/api拼接 OpenAI 兼容路径# review_client.py import json import time import requests from key_pool import KeyPool BASE_URL https://taotoken.net/api ENDPOINT f{BASE_URL}/v1/chat/completions SYSTEM_PROMPT 你是一名严格的代码审查者。 只报告真实存在的问题按以下格式输出 1. 文件路径 2. 风险等级高/中/低 3. 问题描述 4. 建议改法 没有把握的地方标注待确认不要编造行号。 def review_chunk(pool: KeyPool, chunk: str, model: str gpt-5-codex): state pool.acquire(timeout60) payload { model: model, messages: [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: f请审查以下 diff\n\n{chunk}}, ], temperature: 0.2, stream: False, } headers { Authorization: fBearer {state.key}, Content-Type: application/json, } started time.time() try: resp requests.post(ENDPOINT, headersheaders, jsonpayload, timeout180) elapsed time.time() - started if resp.status_code 429: retry_after float(resp.headers.get(Retry-After, 60)) pool.release(state, okFalse, retry_afterretry_after) raise RuntimeError(rate limited) if resp.status_code 400: pool.release(state, okFalse, retry_after30) raise RuntimeError(fHTTP {resp.status_code}: {resp.text[:200]}) pool.release(state, okTrue) data resp.json() return { latency: elapsed, content: data[choices][0][message][content], } except requests.Timeout: pool.release(state, okFalse, retry_after20) raise def review_files(pool: KeyPool, chunks): results [] for idx, chunk in enumerate(chunks): try: out review_chunk(pool, chunk) results.append({index: idx, ok: True, **out}) except Exception as exc: results.append({index: idx, ok: False, error: str(exc)}) return results几个设计取舍值得说明。temperature压到 0.2是因为审查任务要的是可复现同样的 diff 跑两次结论差太多团队就没法把它当成流程的一环。失败不要静默吞掉。review_files把每一块的成败都记下来后面做并发对照的时候才能算成功率。Retry-After优先于固定的冷却时间。有些限流会明确告诉你要等多久照着等比自己拍脑袋更有效率。如果你打算把审查结果自动贴回 PR记得只贴高和中这两个等级低等级的问题留在 artifact 里。评论区刷屏会直接导致这个 Agent 被团队关掉这是审查类工具最常见的死法。5. 并发对照实验把感觉慢变成一张表Key 池写完接下来要回答一个具体问题单 Key 并发开到多少多 Key 池才真正划算这个问题不能靠猜得靠一张对照表。实验设计很简单控制变量是并发度和Key 数量观测量是成功率、P50/P95 延迟、429 次数。# bench.py import time import statistics from concurrent.futures import ThreadPoolExecutor from key_pool import KeyPool from review_client import review_chunk from split_diff import split_by_file def run_once(pool, chunk, workers): started time.time() with ThreadPoolExecutor(max_workersworkers) as ex: futures [ex.submit(review_chunk, pool, chunk) for _ in range(workers)] oks, errors, latencies 0, 0, [] for f in futures: try: r f.result() oks 1 latencies.append(r[latency]) except Exception: errors 1 total time.time() - started return { workers: workers, ok: oks, errors: errors, success_rate: round(oks / workers, 3), p50: round(statistics.median(latencies), 2) if latencies else None, p95: round( sorted(latencies)[int(len(latencies) * 0.95) - 1], 2 ) if len(latencies) 2 else None, wall: round(total, 2), pool: pool.snapshot(), }跑的时候每个并发档位间隔一段时间避免上一个档位的冷却影响下一个python - PY import time, json from key_pool import KeyPool from bench import run_once pool KeyPool.from_env(max_inflight_per_key2, cooldown_seconds60) diff_text open(/tmp/pr.diff).read() chunk diff_text[:20000] rows [] for workers in [1, 2, 4, 8, 16]: rows.append(run_once(pool, chunk, workers)) time.sleep(65) # 等冷却窗口过去 print(json.dumps(rows, ensure_asciiFalse, indent2)) PY结果按这个表格整理空表先给出来数字由你自己的实验填并发度Key 数量单 Key 并发上限成功率P50(s)P95(s)429 次数备注111基线21242282416441682看表的时候重点不是找最快的那一行而是找成功率还没掉下来的最大并发。延迟随并发上升是正常的成功率掉下来才是真正的信号。如果某一档的 429 次数突然跳起来而成功率开始低于 0.95那这一档就是你的实际上限再往上加 Key 也没用问题出在别的地方。再补一句实测之外的经验PR 审查这类任务P95 比 P50 重要得多。开发者提了 PR 就在等反馈P50 快但 P95 拖到十分钟体验和全都很慢差不多。把 P95 作为调参目标比优化平均值更贴近真实使用。6. 错误码速查从 401 到diff 为空接入阶段真正花时间的通常不是写代码而是对着一行错误日志猜。下面这份清单按出现频率排。401 / 403。Key 没读到或者读到了空字符串。先确认echo $TAOTOKEN_API_KEY | wc -c有输出再确认没有多余引号或换行。Key 池场景下还要注意把多把 Key 塞进同一个变量用逗号分隔时切分后没strip()会留下空格Authorization 头里带空格的结果就是 401。404。路径拼接问题。base_url已经是https://taotoken.net/api如果你的客户端又自动补了一层前缀就会变成重复路径。检查实际请求的 URL而不是配置文件里写的 URL。429。限流。三种可能单 Key 并发超了、Key 池冷却逻辑没生效、上游确实在压。先看pool.snapshot()如果所有 Key 都在 cooling说明冷却时间设得太短或者并发设得太高。把max_inflight_per_key从 4 降到 2 再试一轮这是最快见效的一步。超时 / 连接中断。多数情况下是单次请求体太大。一个几万行的 diff 塞进去模型侧处理时间会拉长到超出客户端 timeout。回到第 4 节的分块逻辑把max_chars从 40000 降到 20000观察超时是否消失。上下文超限。即使分块了也可能超因为 diff 里包含大量上下文行。两个动作--unified1减少上下文行数对生成文件、lock 文件、压缩产物做路径白名单过滤这些文件根本不需要审查。# 过滤掉不需要审查的路径 git diff --unified1 origin/main...HEAD -- \ :(exclude)*.lock \ :(exclude)dist/* \ :(exclude)*.min.js \ /tmp/pr.diff.filtereddiff 为空。CI 里最经典的坑。actions/checkout默认fetch-depth: 1浅克隆下origin/main和HEAD没有共同祖先三点 diff 出来是空的Agent 拿着空字符串一本正经地输出未发现问题。修法就是显式fetch-depth: 0。未发现问题但显然有问题。这通常不是模型的问题而是 diff 被切得太碎每块都缺上下文模型看不到跨文件的调用关系。这时应该调整切分策略把同一个目录下的文件合并成一块或者把调用方和被调用方放在同一个请求里。7. 接进 CI权限收紧与执行边界把 Key 池和审查脚本接进流水线配置文件本身不复杂难的是权限边界。# .github/workflows/pr-review.yml name: codex-pr-review on: pull_request: types: [opened, synchronize, reopened] permissions: contents: read pull-requests: write jobs: review: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 with: fetch-depth: 0 - uses: actions/setup-pythonv5 with: python-version: 3.12 - name: Install deps run: pip install requests - name: Generate diff run: | git fetch origin ${{ github.base_ref }} --quiet git diff --unified2 origin/${{ github.base_ref }}...HEAD \ :(exclude)*.lock :(exclude)dist/* /tmp/pr.diff - name: Run review env: TAOTOKEN_KEYS: ${{ secrets.TAOTOKEN_KEYS }} run: python scripts/batch_review.py --diff /tmp/pr.diff --out review.json - name: Upload artifact uses: actions/upload-artifactv4 with: name: pr-review path: review.json权限部分要克制。contents: read是必须的pull-requests: write只在你确实要自动发评论时才加。如果只是产出 artifact 让人去看把写权限去掉。Key 池通过 repository secret 注入不要用明文变量也不要在日志里打印 Key 本体snapshot()里只输出尾号就是这个原因。另外提醒一句PR 审查 Agent 只应该读代码。不要给它任何能连到生产数据库的凭据也不要让它在流水线里执行仓库里定义的任意脚本。需要查数据、跑 SQL 的时候把语句生成出来由人在本地或者受控环境里执行。这不是保守是让这个 Agent 能长期活下来的前提——一个偶尔会误操作的自动化流程团队很快就会把它禁掉。还有一点关于并发控制CI 天然会并发。同一个仓库连续 push 三次可能触发三个 workflow 同时跑每个都开 8 并发打 API。这时候 Key 池是进程内的跨 workflow 不共享状态所以最好的做法是在 workflow 层面加并发限制concurrency: group: pr-review-${{ github.event.pull_request.number }} cancel-in-progress: true同一个 PR 只保留最新一次审查前面的直接取消。这一条能省掉大量无效请求。8. 收尾Key 池是工作流里最不该临时拼的一块回到开头那个判断。Codex 这类工具正在从帮你写一段代码变成帮你跑完一段流程PR 审查是这条路上最容易验证的场景因为它有明确的输入diff、明确的输出问题清单、明确的边界只读。但它同时也是最考验工程细节的场景因为它跑在无人值守的地方。把这件事做稳的顺序是先用config.toml把客户端指向https://taotoken.net/api再用一个带状态位的 Key 池把并发和冷却管住然后用按文件切分的策略控制单次请求体积最后用一张并发对照表把调参这件事变成可复现的实验而不是凭感觉改数字。这套东西写完之后你会发现真正的收益不在审得快而在审得稳。成功率稳定在 0.95 以上之后团队才会开始信任它输出的结论才开始把低风险 PR 直接交给它先过一遍。如果你准备开始搭这套流程按下面这个顺序走一遍先在模型对话页面确认你要用的模型和调用方式https://taotoken.net/models/detail/chat?utm_sourcetaotoken_aicg_blog_endutm_contentcodex_pr_review如果 PR 审查是高频任务看一下套餐是否更适合你的调用量https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcodex_pr_review到控制台创建 Key多 Key 池就多建几把分别注入TAOTOKEN_KEYShttps://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentcodex_pr_review如果你同时维护 Claude Code 侧的工作流它的配置方式在另一份文档里注意两套变量不要混用https://taotoken.net/doc/ClaudeCodeAnthropic?utm_sourcetaotoken_aicg_blog_endutm_contentcodex_pr_review官网入口统一从这里进https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentcodex_pr_review_endKey 和 Base URL 这两件事交出去之后剩下的部分才是你自己的东西审查规则怎么定、哪些文件不审、什么等级的问题值得打断人。这些判断没法外包也不该外包。