1. 从 Codex 的 config.toml 说起GPT-6 Pro 读 PR 时规划通道要先切到 TaoTokenCodex 的~/.codex/config.toml还在走默认 provider 时ChatGPT 网页版 GPT-6 Pro 读取 GitHub PR 的规划通道要先切到 TaoToken到 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentblog_gpt6pro_codex_mcp_intro 拿 Key工具里的 Base URL 用 https://taotoken.net/api。实际排障里常见报错不是 PR diff 太大而是401 invalid api key、stream error: unexpected EOF、飞书 OAuth 回调redirect_uri_mismatch以及 MCP tool 返回 403。很多排查会先怀疑 GitHub API 限流、MCP 超时但真正应该先确认的是Codex 的规划请求到底发给了哪个 provider。本文要还原的链路是Codex 把一台只读、最小权限、带飞书 OAuth 鉴权的 MCP Server 封装出来作为 ChatGPT 网页版的插件入口让 GPT-6 Pro 读取 GitHub PR 记录和脱敏后的生产数据进而做规划分析。Token 消耗方有三层GPT-6 Pro 的规划轮次、Codex 的执行请求、MCP 调用链上的数据读取与摘要请求。任何一层把 Base URL 配错都会让“省额度”变成“换一个地方消耗”。所以这篇不写泛泛的工作流而是给出可复现产出Codex 规划通道开关、GitHub PR 读取命令、MCP 只读工具边界、飞书 OAuth 配置、额度对照口径。先明确一个原则MCP Server 不直连 Oracle也不直连生产库。所有 SQL 查询、gh拉取、脱敏脚本都在读者本地机器或 CI 里执行MCP Server 只读取已经落盘的只读脱敏产物。这样 GPT-6 Pro 看到的是分析材料不是生产库连接串Codex 执行的是本地命令不是数据库写操作审计日志里能分清是谁在什么时候调用了哪个只读工具。2. 权限边界只读 MCP Server、飞书 OAuth 与“不许直连生产库”这个 MCP Server 的定位不是“把生产环境开放给模型”而是“把已经脱敏的 PR 与指标文件暴露成只读工具”。它需要满足四个条件只读不提供写文件、执行 SQL、合并 PR、修改配置的工具。最小权限飞书 OAuth 只用来做身份准入不拿通讯录写权限不拿审批写权限。脱敏GitHub PR 里的邮箱、手机号、内网地址、密钥样式字符串先在本地替换。不直连生产库MCP 工具只读/srv/mcp-readonly下的 JSON、diff、metrics 文件数据库查询由本地脚本提前导出。先建目录sudo mkdir -p /srv/mcp-readonly/{pr,metrics,audit} sudo chown -R mcp:mcp /srv/mcp-readonly sudo chmod -R 750 /srv/mcp-readonly飞书 OAuth 相关配置用环境变量注入不要写进代码仓库export FEISHU_APP_IDcli_xxx export FEISHU_APP_SECRETxxx export FEISHU_OAUTH_REDIRECT_URIhttps://mcp.example.com/oauth/feishu/callback export FEISHU_ALLOWED_OPEN_IDSou_xxx,ou_yyy export MCP_AUTH_MODEfeishu_oauth export MCP_READONLY_ROOT/srv/mcp-readonly export MCP_TOOL_SCOPEpr:read,metrics:read export MCP_SESSION_TTL3600OAuth 流程可以按下面顺序验证1. ChatGPT 网页版连接器打开 MCP Server URL。 2. MCP Server 返回 302跳转到飞书授权页。 3. 用户授权后飞书回调 /oauth/feishu/callback。 4. MCP Server 用 code 换取用户身份校验 open_id 是否在 FEISHU_ALLOWED_OPEN_IDS。 5. 校验通过后签发短期 MCP Session只带 pr:read、metrics:read。 6. 后续每次 tool call 都校验 session scope 与工具白名单。MCP 工具白名单建议写死不要让模型自由发现文件{ tools: [ { name: list_prs, scope: pr:read, description: 列出已脱敏的 PR 摘要不返回原始 diff, input: [repo, limit] }, { name: get_pr, scope: pr:read, description: 读取指定 PR 的脱敏 JSON 与截断后的 diff, input: [repo, number] }, { name: get_sanitized_metric, scope: metrics:read, description: 读取本地导出的脱敏指标文件, input: [metric, window] } ] }工具返回时要限制长度。比如get_pr默认只返回 PR 标题、文件列表、风险标签、diff 前 120KB不返回完整评论流。更完整的评论放在本地让读者按需执行命令查看。TaoToken 官网的控制台和文档入口可以放在这里作为配置参考https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentblog_gpt6pro_codex_mcp_boundary 。需要创建 Key 时走官网 API Keys 页面Base URL 仍然是https://taotoken.net/api不要在后面乱拼路径。3. Codex 规划通道开关config.toml 写 TaoToken不要把 ANTHROPIC_* 塞进去Codex 的配置入口是config.toml不是 Claude Code 的settings.json也不要把ANTHROPIC_*环境变量套到 Codex 上。两者协议、字段、计费入口都不同。下面是一个可复制的 Codex 配置示例用 profile 做“规划通道开关”# ~/.codex/config.toml model gpt-6-pro-planning model_provider taotoken approval_policy on-request [profiles.taotoken] model_provider taotoken model gpt-6-pro-planning approval_policy on-request [profiles.default] model_provider openai model codex-mini-latest approval_policy on-request [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY wire_api responses说明几个点base_url固定写https://taotoken.net/api不要带 UTM也不要写成带查询参数的地址。env_key是环境变量名不是 Key 本身。Key 用YOUR_API_KEY占位实际去 TaoToken 控制台创建。model填控制台实际可用的模型名。如果控制台展示的是别的规划模型名以控制台为准。wire_api按工具版本和控制台说明选择。若当前 Codex 版本只支持 chat 兼容模式就改成对应值不要通过ANTHROPIC_*强行改协议。设置环境变量并启动规划 profileexport TAOTOKEN_API_KEYYOUR_API_KEY codex --profile taotoken如果你希望一键切换“规划通道”和“默认通道”可以放一个本地脚本#!/usr/bin/env bash set -euo pipefail MODE${1:-taotoken} case $MODE in taotoken) codex --profile taotoken ;; default) codex --profile default ;; *) echo usage: $0 {taotoken|default} 2 exit 2 ;; esac验证规划通道是否真的切过去了可以让 Codex 只读本地脱敏 PR 文件codex --profile taotoken exec \ 只读取 /srv/mcp-readonly/pr/owner_repo-123.json输出变更风险点、影响模块、需要本地执行的验证命令。不要访问网络不要请求生产库凭据。常见报错与检查点现象优先检查处理方式401 invalid api keyTAOTOKEN_API_KEY是否设置、env_key名称是否一致重新在 TaoToken 控制台创建 Key确认环境变量已 export404 not foundbase_url是否多写路径保持https://taotoken.net/api不要手工拼/v1或带 UTMstream error: unexpected EOF网络、超时、代理层先跑最小请求再检查 MCP 工具返回体是否过大Codex 仍走旧 providerprofile 是否生效用--profile taotoken启动检查model_providerMCP OAuth 403飞书 open_id 白名单把授权用户 open_id 加入FEISHU_ALLOWED_OPEN_IDSredirect_uri_mismatch飞书回调地址与FEISHU_OAUTH_REDIRECT_URI完全一致4. GitHub PR 读取命令本地抓取、脱敏落盘再让 MCP 暴露MCP Server 不直接调用 GitHub API也不直连生产库。推荐做法是本地用gh拉 PR脱敏后写入只读目录MCP 只读这些文件。下面命令由读者在本地或 CI 执行export REPOowner/repo export PR123 export SAFE_DIR/srv/mcp-readonly/pr export SAFE_NAME${REPO//\//_}-${PR} mkdir -p $SAFE_DIR gh pr view $PR --repo $REPO \ --json number,title,body,author,baseRefName,headRefName,files,comments,reviews,commits \ $SAFE_DIR/$SAFE_NAME.raw.json gh pr diff $PR --repo $REPO \ $SAFE_DIR/$SAFE_NAME.raw.diff接着做本地脱敏。邮箱、手机号、内网地址、疑似密钥先替换掉不要把这些原文交给 MCPjq .title (.title // | gsub([A-Za-z0-9._%-][A-Za-z0-9.-]; [EMAIL])) | .body (.body // | gsub([A-Za-z0-9._%-][A-Za-z0-9.-]; [EMAIL])) | .comments (.comments // [] | map(.body (.body // | gsub([A-Za-z0-9._%-][A-Za-z0-9.-]; [EMAIL])))) | .reviews (.reviews // [] | map(.body (.body // | gsub([A-Za-z0-9._%-][A-Za-z0-9.-]; [EMAIL])))) $SAFE_DIR/$SAFE_NAME.raw.json $SAFE_DIR/$SAFE_NAME.json awk BEGIN{IGNORECASE1} {gsub(/[A-Za-z0-9._%-][A-Za-z0-9.-]/,[EMAIL]); print} \ $SAFE_DIR/$SAFE_NAME.raw.diff $SAFE_DIR/$SAFE_NAME.diff限制 diff 长度避免 GPT-6 Pro 规划轮次被超长 diff 拖爆head -c 120000 $SAFE_DIR/$SAFE_NAME.diff \ $SAFE_DIR/$SAFE_NAME.diff.shortMCP 只读工具读取/srv/mcp-readonly/pr/owner_repo-123.json /srv/mcp-readonly/pr/owner_repo-123.diff.short /srv/mcp-readonly/metrics/*.json给 GPT-6 Pro 的规划提示词模板可以固定为你正在读取本地脱敏后的 PR 数据 - JSON: /srv/mcp-readonly/pr/owner_repo-123.json - Diff: /srv/mcp-readonly/pr/owner_repo-123.diff.short 请输出 1. 变更摘要 2. 风险文件与风险类型 3. 需要 Codex 在本地执行的验证命令 4. 建议的回归范围 5. 不建议执行的操作。 不要请求生产库凭据不要执行写操作不要访问 MCP_READONLY_ROOT 之外的文件。如果 PR 数量多不要一次全量塞给模型。先本地生成索引jq -r [.number, .title, .author.login, (.files | length)] | tsv \ /srv/mcp-readonly/pr/*.json | sort -n /srv/mcp-readonly/pr/index.tsv然后让 MCP 的list_prs只返回索引摘要get_pr再按编号取详情。这样 GPT-6 Pro 读 PR 时走的是“摘要 → 规划 → 按需读取”而不是“全量 diff → 超时 → 重试”。5. ChatGPT 网页版 GPT-6 Pro 接入 MCP飞书 OAuth 与调用链验证ChatGPT 网页版连接器入口随版本变化字段名以实际界面为准。核心是填 MCP Server 地址、选择 transport、走 OAuth 授权MCP Server URL: https://mcp.example.com/feishu-oauth/mcp Transport: streamable HTTP Auth: OAuth 2.0 OAuth Provider: Feishu Scopes: pr:read, metrics:read Callback: https://mcp.example.com/oauth/feishu/callback授权完成后在 GPT-6 Pro 对话里先做一个最小调用测试请调用 get_pr(repoowner/repo, number123)只返回变更摘要和风险文件。 不要请求完整 diff不要输出任何邮箱、手机号、内网地址。再测试规划能力基于 get_pr 返回的摘要列出 Codex 需要在本地执行的 5 条验证命令。 每条命令说明目的、预期输出、失败时检查什么。 不要直接执行命令只生成命令清单。MCP Server 侧要记录审计日志至少包含时间、open_id、tool、参数摘要、耗时、返回字节数jq -c {ts, open_id, tool, args, latency_ms, bytes} \ /srv/mcp-readonly/audit/mcp.log | tail -n 20验证 OAuth session 是否有效curl -i https://mcp.example.com/feishu-oauth/mcp \ -H Authorization: Bearer YOUR_MCP_SESSION调用链里的 Token 归属要拆清楚GPT-6 Pro负责规划、拆任务、读摘要、生成验证清单。Codex负责本地执行规划通道请求使用--profile taotoken时走 TaoToken。MCP 调用链只读工具不调用大模型如果 MCP 内部有二次摘要模型也单独配置供应商不要偷偷混到 Codex 的 provider 里。飞书 OAuth只做准入不参与模型计费。如果 MCP tool 返回 403先看 scope 是否包含pr:read如果返回 401看 session 是否过期如果飞书授权成功但 MCP 拒绝检查FEISHU_ALLOWED_OPEN_IDS是否写成了 union_id 或 user_id而不是 open_id。6. 额度对照把 GPT-6 Pro、Codex、MCP 调用链拆开记账额度优化最怕“只知道总额涨了不知道哪一层涨”。建议按三个消耗方记账消耗方观察位置常见浪费切换动作GPT-6 Pro 规划ChatGPT 连接器调用日志重复读取同一 PR diff、重复规划本地先生成摘要文件MCP 返回摘要与索引Codex 执行~/.codex/sessions/*.jsonl默认 profile 与规划 profile 混用规划跑--profile taotoken执行按需切回 defaultMCP 调用链/srv/mcp-readonly/audit/mcp.log无缓存、无截断、scope 过大只读工具加缓存、diff 截断、白名单 scope统计 Codex session 里的 token 计数时字段名按你的版本调整jq -r select(.typetoken_count) | [.timestamp, .payload.total_token_usage.input_tokens, .payload.total_token_usage.output_tokens] | tsv ~/.codex/sessions/*.jsonl 2/dev/null | tail -n 50统计 MCP 工具调用次数awk {print $NF} /srv/mcp-readonly/audit/mcp.log \ | sort | uniq -c | sort -nr建议每轮规划记录这些字段方便做额度对照日期 PR 编号 diff 原始字节 diff 截断后字节 MCP tool 调用次数 GPT-6 Pro 规划轮次 Codex 执行轮次 输入 token 输出 token 是否命中缓存TaoToken 控制台里可以看 Key、模型与用量入口官网链接放在这里方便对照https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentblog_gpt6pro_codex_mcp_quota 。创建 Key 时用YOUR_API_KEY占位不要把真实 Key 写进config.toml。Base URL 始终是https://taotoken.net/api。额度优化的顺序建议是先截断 diff只让 MCP 返回摘要和风险文件。再缓存 PR 摘要同一 PR 同一 commit 不重复生成。再拆分 Codex profile规划通道走 TaoToken默认执行通道不混用。最后检查 MCP 工具返回体去掉评论全文、base64、长日志。给飞书 OAuth 用户加白名单避免无关账号触发 tool call。把审计日志接到本地看板按 open_id、tool、PR 编号聚合。7. Claude Code 与 CC Switch 旁路settings.json / ANTHROPIC_* 只给 Claude CodeClaude Code 的配置和 Codex 不同。Claude Code 可以用settings.json或ANTHROPIC_*环境变量Codex 继续用config.toml。不要因为两个工具都调模型就把ANTHROPIC_*写进 Codex。Claude Code 的settings.json示例{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_AUTH_TOKEN: YOUR_API_KEY, ANTHROPIC_MODEL: claude-sonnet-4-5 } }启动时指定 settingsclaude --settings ~/.claude/settings.json如果你用 CC Switch 管理多个供应商按“三件套”填供应商名称TaoToken Base URLhttps://taotoken.net/api API KeyYOUR_API_KEY Model按控制台实际可用模型填写CC Switch 只负责切换 Claude Code 的供应商不负责 Codex 的model_provider。Codex 那边仍然是[model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY两边都指向同一个 Base URL但环境变量名、配置文件、profile 命名不要互相抄。否则会出现“Claude Code 能通Codex 报 401”或“Codex 通了MCP 的 OAuth 又 403”的混合故障。8. 文末 CTA按“模型对话 → Coding Plan → 创建 Key → Claude Code 文档”跑通如果你准备把这条链路落地建议按下面顺序操作避免先写 MCP 再回头补 Key先到模型对话页验证模型是否可用、响应是否正常https://taotoken.net/models/detail/chat?utm_sourcetaotoken_aicg_blog_endutm_contentblog_gpt6pro_codex_mcp_cta_chat再看 Coding Plan确认规划通道、Codex 执行、MCP 调用链的用量口径https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentblog_gpt6pro_codex_mcp_cta_coding到控制台创建 API Key用YOUR_API_KEY占位写入本地环境变量不要提交到仓库https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentblog_gpt6pro_codex_mcp_cta_keys最后按 Claude Code 文档配置settings.json与ANTHROPIC_*如果你同时用 Codex则回到~/.codex/config.toml写model_provider taotokenhttps://taotoken.net/doc/ClaudeCodeAnthropic?utm_sourcetaotoken_aicg_blog_endutm_contentblog_gpt6pro_codex_mcp_cta_claudecode把 GPT-6 Pro 读 GitHub PR 的规划通道切到 TaoToken 后关键不是“哪个模型更便宜”而是每一层都有明确的配置文件、明确的只读边界、明确的审计日志。Codex 用config.toml管规划通道Claude Code 用settings.json管旁路MCP Server 用飞书 OAuth 管准入GitHub PR 与脱敏数据由本地命令落盘。这样 GPT-6 Pro 做规划、Codex 做执行、MCP 调用链做只读供给三者的 token 消耗才能被拆开观察和优化。
