1. 只读 MCP Server GPT-6 Pro周额度为什么总在规划阶段烧完当 Codex 被要求把服务器封装成 MCP Server并通过飞书 OAuth 做鉴权只开放只读、最小权限再交给 ChatGPT 网页版 GPT-6 Pro 调用时最先暴露的问题通常不是 MCP 连接失败而是 Codex 的周额度在“读数据 做规划”这一段被快速消耗。原因并不神秘Codex 如果既负责扫描仓库、拉取 GitHub PR、归纳生产指标又负责输出落地计划那么每一次探索都会把大段上下文重新送进模型而 GPT-6 Pro 本来更适合做跨源材料归纳、方案权衡和计划压缩。把只读读取链路拆出去让 GPT-6 Pro 通过 MCP 拿到结构化事实Codex 只接收压缩后的计划并执行才是周额度可控的关键。在开始之前先把供应商入口固定下来去 TaoToken 官网领取 Key地址是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentreadonly_mcp_quota Base URL 统一使用 https://taotoken.net/api Key 占位符写成YOUR_API_KEY。这篇文章不复述站外笔记而是把一套可跟做的链路拆成四块Server 权限表、MCP 调用日志、Codex/Claude Code 配置、额度对照。你最终能得到一个只读、最小权限、飞书 OAuth 鉴权的 MCP Server让 ChatGPT 网页版 GPT-6 Pro 读取真实生产数据和 GitHub PR 记录做分析与规划同时把 Codex 的周额度从“探索型消耗”转移到“执行型消耗”。这里有一个前提必须说清楚MCP Server 不要直连 Oracle、MySQL 生产库也不要让 Agent 自己执行 SQL。只读 Server 应该只暴露经过脱敏、聚合、限流的只读接口例如离线快照、只读副本、GitHub API、CI 状态 API。所有 SQL、部署命令、合并动作都由读者在本地或受控终端执行MCP 调用链只负责把事实读出来不负责改状态。这样才能既省额度又不把权限放大。2. 先把权限钉死只读 MCP Server 的权限表与飞书 OAuth 鉴权只读 MCP Server 的第一原则不是“能读多少”而是“只能读什么”。建议先用一张权限表把工具边界固定下来再写代码。下面是一份可以直接照着改的权限表模板工具名用途输入参数返回字段权限等级禁止行为get_pull_requests读取 GitHub PR 列表repo、state、limit编号、标题、作者、状态、标签、变更文件数read:pr不返回完整 diff不合并不评论get_pull_request_detail读取单个 PR 摘要repo、number标题、描述、审查状态、检查结果read:pr不写 review不触发 workflowget_ci_status读取 CI 状态repo、branch、limit状态、耗时、失败任务名read:ci不重跑任务不改配置get_issue_digest读取 issue 摘要repo、labels、limit标题、标签、评论数、最近更新时间read:issue不关闭 issue不指派人员get_metric_snapshot读取离线指标快照service、window聚合指标、环比、样本量read:metric不查生产库不返回用户明细get_release_notes读取发布记录tag、limit版本、变更摘要、风险标签read:release不触发发布不回滚get_feishu_doc_digest读取飞书文档摘要doc_token标题、目录、摘要read:doc不导出全文不改文档这张表要落在 MCP Server 的 tool 注册逻辑里。每个 tool 都要有独立的 scope 校验不能用一个“大权限”通行证覆盖所有工具。飞书 OAuth 鉴权建议走标准 OAuth 2.0 授权码流程audience 指向你的 MCP Server 标识required claims 至少包含open_id和tenant_key。下面是一个配置示例具体字段以飞书开放平台当前文档为准mcp_server: name: readonly-prod-insight transport: http auth: type: oauth2 provider: feishu issuer: https://open.feishu.cn authorization_endpoint: https://open.feishu.cn/open-apis/authen/v1/index token_endpoint: https://open.feishu.cn/open-apis/authen/v2/oauth/token jwks_uri: https://open.feishu.cn/open-apis/authen/v1/keys scopes: - contact:user.base:readonly - drive:drive:readonly - wiki:wiki:readonly audience: readonly-prod-insight required_claims: - open_id - tenant_key safety: readonly: true deny_sql_exec: true deny_shell: true max_rows: 200 timeout_ms: 8000飞书 OAuth 鉴权失败时最常见的三类报错是invalid_token、insufficient_scope、audience_mismatch。排查顺序应该是先看 token 是否过期再看 scope 是否覆盖当前 tool最后看 audience 是否与 MCP Server 注册值一致。不要把tenant_access_token和user_access_token混用如果工具需要读取个人可见的飞书文档通常需要用户授权链路而不是应用身份直接读。只读 Server 宁愿少读一点也不要为了“方便”把应用权限放大到可写。另外Server 侧要记录每一次 MCP 调用的日志。日志不是简单打印而是为后面的额度对照服务。建议至少包含request_id、caller、tool、repo或service、status、latency_ms、token_in、token_out、provider、api_key_alias。这样你才能知道 GPT-6 Pro 到底读了多少、Codex 到底省了多少、MCP 调用链里哪一段最贵。3. 把 Codex 的供应商切到 TaoTokenconfig.toml 与 MCP 调用链Codex 侧的配置目标和 Claude Code 不一样。Codex 使用config.toml不要把ANTHROPIC_*那一套环境变量套到 Codex 上否则会出现鉴权失败或供应商不识别。正确做法是在 Codex 配置中新增一个model_providers把base_url指到 TaoToken 的 API 入口再用独立环境变量注入 Key。# ~/.codex/config.toml model gpt-6-pro model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY wire_api chat [profiles.readonly-plan] model gpt-6-pro model_provider taotoken approval_policy never sandbox_mode read-only环境变量这样写export TAOTOKEN_API_KEYYOUR_API_KEY如果你还没有 Key可以从 TaoToken 官网进入控制台创建入口是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentreadonly_mcp_codex_config 。创建后按项目或按用途拆 Key例如codex-exec、gpt6-pro-plan、mcp-readonly。拆 Key 的意义不是形式主义而是后面做额度对照时你能一眼看出Codex 周额度降了是不是因为规划流量转到了gpt6-pro-planMCP 调用链贵了是不是因为某个 tool 返回字段太多。MCP Server 本身可以独立运行不要求 Codex 去调用它。推荐的链路是Codex 使用 TaoToken 作为模型供应商只负责接收计划、改代码、跑本地验证。MCP Server 以只读方式暴露 GitHub PR、CI、issue、指标快照、飞书文档摘要。ChatGPT 网页版 GPT-6 Pro 通过 MCP 插件或连接器读取这些工具生成分析和规划。规划结果以 Markdown 或 JSON 摘要回到 CodexCodex 再执行落地。这样做的好处是GPT-6 Pro 承担了“跨源阅读 归纳 计划生成”Codex 不再需要把大量原始 PR、CI 日志、飞书文档塞进自己的上下文。Codex 的周额度自然更多花在真正需要执行和验证的步骤上。4. MCP Server 侧飞书 OAuth 校验与调用日志怎么写MCP Server 的鉴权中间件建议做四件事校验 OAuth token、解析 scope、匹配 tool 权限、写调用日志。下面是一段伪代码级的 Node.js 示例重点是结构不是某个框架的固定写法// mcp/readonly-prod-insight/auth.js export async function authorizeMcpRequest(req, toolName) { const authHeader req.headers.authorization || ; const token authHeader.replace(/^Bearer\s/i, ); if (!token) { return { ok: false, code: 401, message: missing_token }; } const claims await verifyFeishuOAuthToken(token, { issuer: https://open.feishu.cn, audience: readonly-prod-insight, }); if (!claims.open_id || !claims.tenant_key) { return { ok: false, code: 403, message: missing_required_claim }; } const requiredScope TOOL_SCOPE_MAP[toolName]; if (!requiredScope || !claims.scope?.includes(requiredScope)) { return { ok: false, code: 403, message: insufficient_scope }; } return { ok: true, claims }; } export const TOOL_SCOPE_MAP { get_pull_requests: read:pr, get_pull_request_detail: read:pr, get_ci_status: read:ci, get_issue_digest: read:issue, get_metric_snapshot: read:metric, get_release_notes: read:release, get_feishu_doc_digest: read:doc, };每个 tool 的实现里只允许调用白名单数据源。GitHub 走官方 API 或企业内部只读代理指标走离线快照表飞书文档走摘要接口。不要在这个进程里拼接 SQL 去查生产库更不要暴露exec_sql、run_shell、write_file这类工具。如果读者需要查库应该在本地终端手动执行 SQL再把结果粘贴回对话而不是让 MCP Server 代查。调用日志建议输出 JSONL方便后续用jq、ClickHouse、BigQuery 或本地脚本做额度对照{ts:2026-02-11T08:31:20Z,request_id:mcp_7f3a,caller:gpt-6-pro-web,tool:get_pull_requests,repo:org/payment,state:open,limit:20,status:ok,latency_ms:176,token_in:640,token_out:315,provider:taotoken,api_key_alias:mcp-readonly} {ts:2026-02-11T08:31:24Z,request_id:mcp_7f3b,caller:gpt-6-pro-web,tool:get_ci_status,repo:org/payment,branch:release/2026.02,status:ok,latency_ms:210,token_in:380,token_out:190,provider:taotoken,api_key_alias:mcp-readonly} {ts:2026-02-11T08:31:29Z,request_id:mcp_7f3c,caller:gpt-6-pro-web,tool:get_metric_snapshot,service:checkout,window:7d,status:ok,latency_ms:142,token_in:296,token_out:168,provider:taotoken,api_key_alias:mcp-readonly} {ts:2026-02-11T08:31:35Z,request_id:mcp_7f3d,caller:gpt-6-pro-web,tool:get_release_notes,tag:v2026.02.11,status:ok,latency_ms:133,token_in:255,token_out:140,provider:taotoken,api_key_alias:mcp-readonly}有了这些日志你才能回答三个问题GPT-6 Pro 到底调了哪些 tool每个 tool 返回了多少 tokenCodex 侧是否还在重复读取原始数据如果 Codex 周额度没有下降通常说明规划链路没有真正切走或者 MCP 返回字段太胖GPT-6 Pro 又把大段原文塞回了 Codex。5. GPT-6 Pro 网页版接入MCP 插件连接与只读验证ChatGPT 网页版接入 MCP Server 时核心动作是把 MCP Server 的 HTTPS 地址、鉴权方式和工具列表登记进去。不同版本入口名称可能不同但验证步骤是稳定的在 MCP 连接器中新增 ServerURL 填你的只读 Server 地址例如https://mcp.example.com/readonly-prod-insight。鉴权方式选择 OAuth 2.0授权地址和 token 地址填飞书开放平台对应端点scope 只勾选只读权限。连接成功后先调用get_pull_requests参数repoorg/payment、stateopen、limit5。再调用get_ci_status确认失败任务名可读但不会触发重跑。最后调用get_metric_snapshot确认只返回聚合指标不返回用户明细。故意调用一个不存在的写工具比如merge_pr确认返回tool_not_found或permission_denied。只读验证的标准不是“能连上”而是“写不动”。如果 GPT-6 Pro 能通过 MCP 触发任何合并、发布、改配置、重跑 CI、删文档的动作说明权限表没有落地。此时应该回到第 2 节的权限表把写工具从注册表中删掉而不是靠提示词约束模型“不要写”。提示词不是权限系统scope 和工具白名单才是。GPT-6 Pro 侧的任务提示词也应该围绕只读事实来写。例如你是一个只读分析助手。你可以通过 MCP 工具读取 GitHub PR、CI 状态、issue 摘要、指标快照和飞书文档摘要。 你的输出必须分为三部分 1. 事实摘要只引用 MCP 返回字段不编造数据。 2. 风险判断指出与发布、性能、权限相关的风险。 3. 给 Codex 的执行计划按文件、命令、验证步骤列出不要直接执行命令。 禁止请求写操作禁止假设能访问生产库。这样 GPT-6 Pro 输出的是结构化计划Codex 拿到后只需要执行和验证。Codex 的上下文不再被原始 PR 列表、CI 日志、飞书文档占满周额度消耗会更容易控制。6. Claude Code 与 CC Switch本地联调的 settings.json 三件套虽然主链路是 Codex GPT-6 Pro MCP但很多团队会同时用 Claude Code 做本地联调或对照验证。Claude Code 的配置走settings.json和ANTHROPIC_*环境变量不要和 Codex 的config.toml混用。{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_AUTH_TOKEN: YOUR_API_KEY, ANTHROPIC_MODEL: claude-sonnet-4-20250514, ANTHROPIC_SMALL_FAST_MODEL: claude-haiku-4-20250514 }, permissions: { allow: [Read, Glob, Grep], deny: [Bash] } }如果你使用 CC Switch 管理多套配置可以把它理解成三件套供应商文件、项目 profile、环境变量注入。第一件是供应商定义第二件是项目级 profile第三件是 shell 里的 Key 和 profile 选择。供应商文件示例{ name: taotoken, baseUrl: https://taotoken.net/api, apiKey: YOUR_API_KEY, models: { default: claude-sonnet-4-20250514, fast: claude-haiku-4-20250514 } }项目 profile 示例{ name: readonly-mcp, provider: taotoken, env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_AUTH_TOKEN: YOUR_API_KEY }, mcp: { readonly_prod_insight: { url: https://mcp.example.com/readonly-prod-insight, auth: oauth2 } } }环境变量注入示例export TAOTOKEN_API_KEYYOUR_API_KEY export CC_SWITCH_PROFILEreadonly-mcp这样你在本地切换 Claude Code 配置时不会把 Codex 的config.toml改乱。需要再次强调Claude Code 用ANTHROPIC_*Codex 用config.toml和自定义env_key。两套配置可以同时指向https://taotoken.net/api但环境变量命名和配置文件不要交叉套用。7. 额度对照Codex 周额度到底省在哪省 Codex 周额度不靠一句“用 GPT-6 Pro 分担”而靠 Token 消耗方的重新分配。下面这张对照表可以直接作为你的观测模板环节改造前改造后观测字段数据探索Codex 多轮读取 PR、CI、issue上下文反复膨胀GPT-6 Pro 通过 MCP 只读拉取返回结构化摘要mcp.call_count、token_in、token_out方案规划Codex 在长上下文里做归纳消耗周额度GPT-6 Pro 生成计划摘要Codex 只读计划provider、model、request_id落地执行Codex 执行并再次读取原始数据Codex 只接收文件、命令、验证步骤codex.session_tokens权限审计分散在各工具日志MCP 调用日志 TaoToken Key 分账api_key_alias、tool、status成本归属难以判断谁消耗了什么按codex-exec、gpt6-pro-plan、mcp-readonly拆 Key控制台用量与日志对账具体节省比例取决于你的仓库规模、PR 数量、CI 日志长度和规划轮次不要拍脑袋写固定倍数。更可靠的做法是连续记录 7 天第一天只记录不改链路第二天切 MCP 只读读取第三天把 GPT-6 Pro 计划摘要接回 Codex第四天开始按 Key 分账。对比codex.session_tokens、mcp-readonly调用次数、gpt6-pro-plantoken 量你就能看到周额度到底是被哪一段吃掉的。如果你还没有创建分账 Key可以从 TaoToken 官网控制台进入入口是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentreadonly_mcp_keys_split 。创建YOUR_API_KEY时按用途命名不要把所有链路塞进同一个 Key。MCP Server 只拿mcp-readonlyCodex 只拿codex-execGPT-6 Pro 规划链路只拿gpt6-pro-plan。这样即使某个 tool 返回字段过多你也能在日志里定位到具体调用。8. 排障清单401、403、tool 不存在、周额度异常401 missing_token 或 invalid_token检查请求头是否携带Authorization: Bearer token检查飞书 OAuth token 是否过期检查 audience 是否等于 MCP Server 注册值。不要用应用 access token 冒充用户 token。403 insufficient_scope检查当前 tool 需要的 scope 是否在 token 中。例如get_metric_snapshot需要read:metric如果 token 只有read:pr就应该拒绝。不要为了临时跑通把 scope 改成*。MCP tool not found检查 tool 是否注册到 MCP Server 的工具列表检查名称大小写是否一致。写工具应该根本不存在而不是返回“无权限”。Codex 周额度仍然很高检查 Codex 是否还在直接读取原始 PR、CI 日志、飞书文档。如果规划提示词仍要求 Codex “先自己看一遍仓库”那 MCP 只读链路就没有真正分担。把探索动作移到 GPT-6 Pro把执行动作留给 Codex。MCP 调用延迟高检查 tool 是否单次返回过多字段。只读 Server 应该限制max_rows、timeout_ms、返回字段白名单。PR 列表不要返回完整 diffCI 日志不要返回全量文本指标不要返回用户明细。Base URL 配错Codexconfig.toml和 Claude Codesettings.json里都使用https://taotoken.net/api不要额外拼/v1或其他路径除非对应工具文档明确要求。Key 统一用YOUR_API_KEY占位实际值只放在环境变量或本机配置里。9. 文末 CTA从模型对话到 Coding Plan再到创建 Key 与 Claude Code 文档如果你准备把这套只读 MCP Server GPT-6 Pro 规划链路跑起来建议按下面顺序走先到模型对话里验证 GPT-6 Pro 对结构化事实的归纳效果https://taotoken.net/models/detail/chat?utm_sourcetaotoken_aicg_blog_endutm_contentreadonly_mcp_cta_chat如果你的团队需要把 Codex、Claude Code、MCP 调用链统一管理查看 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentreadonly_mcp_cta_plan创建分账 Key把codex-exec、gpt6-pro-plan、mcp-readonly拆开https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentreadonly_mcp_cta_keys如果你还要用 Claude Code 做本地联调按文档配置settings.json和ANTHROPIC_*https://taotoken.net/doc/ClaudeCodeAnthropic?utm_sourcetaotoken_aicg_blog_endutm_contentreadonly_mcp_cta_doc最后再提醒一次只读 MCP Server 的价值不是“让模型什么都能读”而是让 GPT-6 Pro 在最小权限内读该读的让 Codex 不再为探索型上下文买单。Server 权限表、MCP 调用日志、额度对照这三份产出才是把 Codex 周额度省下来的可复现依据。 只读 Server 的 MCP 权限给 GPT-6 Pro，TaoToken 省 Codex 周额度
1. 只读 MCP Server GPT-6 Pro周额度为什么总在规划阶段烧完当 Codex 被要求把服务器封装成 MCP Server并通过飞书 OAuth 做鉴权只开放只读、最小权限再交给 ChatGPT 网页版 GPT-6 Pro 调用时最先暴露的问题通常不是 MCP 连接失败而是 Codex 的周额度在“读数据 做规划”这一段被快速消耗。原因并不神秘Codex 如果既负责扫描仓库、拉取 GitHub PR、归纳生产指标又负责输出落地计划那么每一次探索都会把大段上下文重新送进模型而 GPT-6 Pro 本来更适合做跨源材料归纳、方案权衡和计划压缩。把只读读取链路拆出去让 GPT-6 Pro 通过 MCP 拿到结构化事实Codex 只接收压缩后的计划并执行才是周额度可控的关键。在开始之前先把供应商入口固定下来去 TaoToken 官网领取 Key地址是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentreadonly_mcp_quota Base URL 统一使用 https://taotoken.net/api Key 占位符写成YOUR_API_KEY。这篇文章不复述站外笔记而是把一套可跟做的链路拆成四块Server 权限表、MCP 调用日志、Codex/Claude Code 配置、额度对照。你最终能得到一个只读、最小权限、飞书 OAuth 鉴权的 MCP Server让 ChatGPT 网页版 GPT-6 Pro 读取真实生产数据和 GitHub PR 记录做分析与规划同时把 Codex 的周额度从“探索型消耗”转移到“执行型消耗”。这里有一个前提必须说清楚MCP Server 不要直连 Oracle、MySQL 生产库也不要让 Agent 自己执行 SQL。只读 Server 应该只暴露经过脱敏、聚合、限流的只读接口例如离线快照、只读副本、GitHub API、CI 状态 API。所有 SQL、部署命令、合并动作都由读者在本地或受控终端执行MCP 调用链只负责把事实读出来不负责改状态。这样才能既省额度又不把权限放大。2. 先把权限钉死只读 MCP Server 的权限表与飞书 OAuth 鉴权只读 MCP Server 的第一原则不是“能读多少”而是“只能读什么”。建议先用一张权限表把工具边界固定下来再写代码。下面是一份可以直接照着改的权限表模板工具名用途输入参数返回字段权限等级禁止行为get_pull_requests读取 GitHub PR 列表repo、state、limit编号、标题、作者、状态、标签、变更文件数read:pr不返回完整 diff不合并不评论get_pull_request_detail读取单个 PR 摘要repo、number标题、描述、审查状态、检查结果read:pr不写 review不触发 workflowget_ci_status读取 CI 状态repo、branch、limit状态、耗时、失败任务名read:ci不重跑任务不改配置get_issue_digest读取 issue 摘要repo、labels、limit标题、标签、评论数、最近更新时间read:issue不关闭 issue不指派人员get_metric_snapshot读取离线指标快照service、window聚合指标、环比、样本量read:metric不查生产库不返回用户明细get_release_notes读取发布记录tag、limit版本、变更摘要、风险标签read:release不触发发布不回滚get_feishu_doc_digest读取飞书文档摘要doc_token标题、目录、摘要read:doc不导出全文不改文档这张表要落在 MCP Server 的 tool 注册逻辑里。每个 tool 都要有独立的 scope 校验不能用一个“大权限”通行证覆盖所有工具。飞书 OAuth 鉴权建议走标准 OAuth 2.0 授权码流程audience 指向你的 MCP Server 标识required claims 至少包含open_id和tenant_key。下面是一个配置示例具体字段以飞书开放平台当前文档为准mcp_server: name: readonly-prod-insight transport: http auth: type: oauth2 provider: feishu issuer: https://open.feishu.cn authorization_endpoint: https://open.feishu.cn/open-apis/authen/v1/index token_endpoint: https://open.feishu.cn/open-apis/authen/v2/oauth/token jwks_uri: https://open.feishu.cn/open-apis/authen/v1/keys scopes: - contact:user.base:readonly - drive:drive:readonly - wiki:wiki:readonly audience: readonly-prod-insight required_claims: - open_id - tenant_key safety: readonly: true deny_sql_exec: true deny_shell: true max_rows: 200 timeout_ms: 8000飞书 OAuth 鉴权失败时最常见的三类报错是invalid_token、insufficient_scope、audience_mismatch。排查顺序应该是先看 token 是否过期再看 scope 是否覆盖当前 tool最后看 audience 是否与 MCP Server 注册值一致。不要把tenant_access_token和user_access_token混用如果工具需要读取个人可见的飞书文档通常需要用户授权链路而不是应用身份直接读。只读 Server 宁愿少读一点也不要为了“方便”把应用权限放大到可写。另外Server 侧要记录每一次 MCP 调用的日志。日志不是简单打印而是为后面的额度对照服务。建议至少包含request_id、caller、tool、repo或service、status、latency_ms、token_in、token_out、provider、api_key_alias。这样你才能知道 GPT-6 Pro 到底读了多少、Codex 到底省了多少、MCP 调用链里哪一段最贵。3. 把 Codex 的供应商切到 TaoTokenconfig.toml 与 MCP 调用链Codex 侧的配置目标和 Claude Code 不一样。Codex 使用config.toml不要把ANTHROPIC_*那一套环境变量套到 Codex 上否则会出现鉴权失败或供应商不识别。正确做法是在 Codex 配置中新增一个model_providers把base_url指到 TaoToken 的 API 入口再用独立环境变量注入 Key。# ~/.codex/config.toml model gpt-6-pro model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY wire_api chat [profiles.readonly-plan] model gpt-6-pro model_provider taotoken approval_policy never sandbox_mode read-only环境变量这样写export TAOTOKEN_API_KEYYOUR_API_KEY如果你还没有 Key可以从 TaoToken 官网进入控制台创建入口是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentreadonly_mcp_codex_config 。创建后按项目或按用途拆 Key例如codex-exec、gpt6-pro-plan、mcp-readonly。拆 Key 的意义不是形式主义而是后面做额度对照时你能一眼看出Codex 周额度降了是不是因为规划流量转到了gpt6-pro-planMCP 调用链贵了是不是因为某个 tool 返回字段太多。MCP Server 本身可以独立运行不要求 Codex 去调用它。推荐的链路是Codex 使用 TaoToken 作为模型供应商只负责接收计划、改代码、跑本地验证。MCP Server 以只读方式暴露 GitHub PR、CI、issue、指标快照、飞书文档摘要。ChatGPT 网页版 GPT-6 Pro 通过 MCP 插件或连接器读取这些工具生成分析和规划。规划结果以 Markdown 或 JSON 摘要回到 CodexCodex 再执行落地。这样做的好处是GPT-6 Pro 承担了“跨源阅读 归纳 计划生成”Codex 不再需要把大量原始 PR、CI 日志、飞书文档塞进自己的上下文。Codex 的周额度自然更多花在真正需要执行和验证的步骤上。4. MCP Server 侧飞书 OAuth 校验与调用日志怎么写MCP Server 的鉴权中间件建议做四件事校验 OAuth token、解析 scope、匹配 tool 权限、写调用日志。下面是一段伪代码级的 Node.js 示例重点是结构不是某个框架的固定写法// mcp/readonly-prod-insight/auth.js export async function authorizeMcpRequest(req, toolName) { const authHeader req.headers.authorization || ; const token authHeader.replace(/^Bearer\s/i, ); if (!token) { return { ok: false, code: 401, message: missing_token }; } const claims await verifyFeishuOAuthToken(token, { issuer: https://open.feishu.cn, audience: readonly-prod-insight, }); if (!claims.open_id || !claims.tenant_key) { return { ok: false, code: 403, message: missing_required_claim }; } const requiredScope TOOL_SCOPE_MAP[toolName]; if (!requiredScope || !claims.scope?.includes(requiredScope)) { return { ok: false, code: 403, message: insufficient_scope }; } return { ok: true, claims }; } export const TOOL_SCOPE_MAP { get_pull_requests: read:pr, get_pull_request_detail: read:pr, get_ci_status: read:ci, get_issue_digest: read:issue, get_metric_snapshot: read:metric, get_release_notes: read:release, get_feishu_doc_digest: read:doc, };每个 tool 的实现里只允许调用白名单数据源。GitHub 走官方 API 或企业内部只读代理指标走离线快照表飞书文档走摘要接口。不要在这个进程里拼接 SQL 去查生产库更不要暴露exec_sql、run_shell、write_file这类工具。如果读者需要查库应该在本地终端手动执行 SQL再把结果粘贴回对话而不是让 MCP Server 代查。调用日志建议输出 JSONL方便后续用jq、ClickHouse、BigQuery 或本地脚本做额度对照{ts:2026-02-11T08:31:20Z,request_id:mcp_7f3a,caller:gpt-6-pro-web,tool:get_pull_requests,repo:org/payment,state:open,limit:20,status:ok,latency_ms:176,token_in:640,token_out:315,provider:taotoken,api_key_alias:mcp-readonly} {ts:2026-02-11T08:31:24Z,request_id:mcp_7f3b,caller:gpt-6-pro-web,tool:get_ci_status,repo:org/payment,branch:release/2026.02,status:ok,latency_ms:210,token_in:380,token_out:190,provider:taotoken,api_key_alias:mcp-readonly} {ts:2026-02-11T08:31:29Z,request_id:mcp_7f3c,caller:gpt-6-pro-web,tool:get_metric_snapshot,service:checkout,window:7d,status:ok,latency_ms:142,token_in:296,token_out:168,provider:taotoken,api_key_alias:mcp-readonly} {ts:2026-02-11T08:31:35Z,request_id:mcp_7f3d,caller:gpt-6-pro-web,tool:get_release_notes,tag:v2026.02.11,status:ok,latency_ms:133,token_in:255,token_out:140,provider:taotoken,api_key_alias:mcp-readonly}有了这些日志你才能回答三个问题GPT-6 Pro 到底调了哪些 tool每个 tool 返回了多少 tokenCodex 侧是否还在重复读取原始数据如果 Codex 周额度没有下降通常说明规划链路没有真正切走或者 MCP 返回字段太胖GPT-6 Pro 又把大段原文塞回了 Codex。5. GPT-6 Pro 网页版接入MCP 插件连接与只读验证ChatGPT 网页版接入 MCP Server 时核心动作是把 MCP Server 的 HTTPS 地址、鉴权方式和工具列表登记进去。不同版本入口名称可能不同但验证步骤是稳定的在 MCP 连接器中新增 ServerURL 填你的只读 Server 地址例如https://mcp.example.com/readonly-prod-insight。鉴权方式选择 OAuth 2.0授权地址和 token 地址填飞书开放平台对应端点scope 只勾选只读权限。连接成功后先调用get_pull_requests参数repoorg/payment、stateopen、limit5。再调用get_ci_status确认失败任务名可读但不会触发重跑。最后调用get_metric_snapshot确认只返回聚合指标不返回用户明细。故意调用一个不存在的写工具比如merge_pr确认返回tool_not_found或permission_denied。只读验证的标准不是“能连上”而是“写不动”。如果 GPT-6 Pro 能通过 MCP 触发任何合并、发布、改配置、重跑 CI、删文档的动作说明权限表没有落地。此时应该回到第 2 节的权限表把写工具从注册表中删掉而不是靠提示词约束模型“不要写”。提示词不是权限系统scope 和工具白名单才是。GPT-6 Pro 侧的任务提示词也应该围绕只读事实来写。例如你是一个只读分析助手。你可以通过 MCP 工具读取 GitHub PR、CI 状态、issue 摘要、指标快照和飞书文档摘要。 你的输出必须分为三部分 1. 事实摘要只引用 MCP 返回字段不编造数据。 2. 风险判断指出与发布、性能、权限相关的风险。 3. 给 Codex 的执行计划按文件、命令、验证步骤列出不要直接执行命令。 禁止请求写操作禁止假设能访问生产库。这样 GPT-6 Pro 输出的是结构化计划Codex 拿到后只需要执行和验证。Codex 的上下文不再被原始 PR 列表、CI 日志、飞书文档占满周额度消耗会更容易控制。6. Claude Code 与 CC Switch本地联调的 settings.json 三件套虽然主链路是 Codex GPT-6 Pro MCP但很多团队会同时用 Claude Code 做本地联调或对照验证。Claude Code 的配置走settings.json和ANTHROPIC_*环境变量不要和 Codex 的config.toml混用。{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_AUTH_TOKEN: YOUR_API_KEY, ANTHROPIC_MODEL: claude-sonnet-4-20250514, ANTHROPIC_SMALL_FAST_MODEL: claude-haiku-4-20250514 }, permissions: { allow: [Read, Glob, Grep], deny: [Bash] } }如果你使用 CC Switch 管理多套配置可以把它理解成三件套供应商文件、项目 profile、环境变量注入。第一件是供应商定义第二件是项目级 profile第三件是 shell 里的 Key 和 profile 选择。供应商文件示例{ name: taotoken, baseUrl: https://taotoken.net/api, apiKey: YOUR_API_KEY, models: { default: claude-sonnet-4-20250514, fast: claude-haiku-4-20250514 } }项目 profile 示例{ name: readonly-mcp, provider: taotoken, env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_AUTH_TOKEN: YOUR_API_KEY }, mcp: { readonly_prod_insight: { url: https://mcp.example.com/readonly-prod-insight, auth: oauth2 } } }环境变量注入示例export TAOTOKEN_API_KEYYOUR_API_KEY export CC_SWITCH_PROFILEreadonly-mcp这样你在本地切换 Claude Code 配置时不会把 Codex 的config.toml改乱。需要再次强调Claude Code 用ANTHROPIC_*Codex 用config.toml和自定义env_key。两套配置可以同时指向https://taotoken.net/api但环境变量命名和配置文件不要交叉套用。7. 额度对照Codex 周额度到底省在哪省 Codex 周额度不靠一句“用 GPT-6 Pro 分担”而靠 Token 消耗方的重新分配。下面这张对照表可以直接作为你的观测模板环节改造前改造后观测字段数据探索Codex 多轮读取 PR、CI、issue上下文反复膨胀GPT-6 Pro 通过 MCP 只读拉取返回结构化摘要mcp.call_count、token_in、token_out方案规划Codex 在长上下文里做归纳消耗周额度GPT-6 Pro 生成计划摘要Codex 只读计划provider、model、request_id落地执行Codex 执行并再次读取原始数据Codex 只接收文件、命令、验证步骤codex.session_tokens权限审计分散在各工具日志MCP 调用日志 TaoToken Key 分账api_key_alias、tool、status成本归属难以判断谁消耗了什么按codex-exec、gpt6-pro-plan、mcp-readonly拆 Key控制台用量与日志对账具体节省比例取决于你的仓库规模、PR 数量、CI 日志长度和规划轮次不要拍脑袋写固定倍数。更可靠的做法是连续记录 7 天第一天只记录不改链路第二天切 MCP 只读读取第三天把 GPT-6 Pro 计划摘要接回 Codex第四天开始按 Key 分账。对比codex.session_tokens、mcp-readonly调用次数、gpt6-pro-plantoken 量你就能看到周额度到底是被哪一段吃掉的。如果你还没有创建分账 Key可以从 TaoToken 官网控制台进入入口是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentreadonly_mcp_keys_split 。创建YOUR_API_KEY时按用途命名不要把所有链路塞进同一个 Key。MCP Server 只拿mcp-readonlyCodex 只拿codex-execGPT-6 Pro 规划链路只拿gpt6-pro-plan。这样即使某个 tool 返回字段过多你也能在日志里定位到具体调用。8. 排障清单401、403、tool 不存在、周额度异常401 missing_token 或 invalid_token检查请求头是否携带Authorization: Bearer token检查飞书 OAuth token 是否过期检查 audience 是否等于 MCP Server 注册值。不要用应用 access token 冒充用户 token。403 insufficient_scope检查当前 tool 需要的 scope 是否在 token 中。例如get_metric_snapshot需要read:metric如果 token 只有read:pr就应该拒绝。不要为了临时跑通把 scope 改成*。MCP tool not found检查 tool 是否注册到 MCP Server 的工具列表检查名称大小写是否一致。写工具应该根本不存在而不是返回“无权限”。Codex 周额度仍然很高检查 Codex 是否还在直接读取原始 PR、CI 日志、飞书文档。如果规划提示词仍要求 Codex “先自己看一遍仓库”那 MCP 只读链路就没有真正分担。把探索动作移到 GPT-6 Pro把执行动作留给 Codex。MCP 调用延迟高检查 tool 是否单次返回过多字段。只读 Server 应该限制max_rows、timeout_ms、返回字段白名单。PR 列表不要返回完整 diffCI 日志不要返回全量文本指标不要返回用户明细。Base URL 配错Codexconfig.toml和 Claude Codesettings.json里都使用https://taotoken.net/api不要额外拼/v1或其他路径除非对应工具文档明确要求。Key 统一用YOUR_API_KEY占位实际值只放在环境变量或本机配置里。9. 文末 CTA从模型对话到 Coding Plan再到创建 Key 与 Claude Code 文档如果你准备把这套只读 MCP Server GPT-6 Pro 规划链路跑起来建议按下面顺序走先到模型对话里验证 GPT-6 Pro 对结构化事实的归纳效果https://taotoken.net/models/detail/chat?utm_sourcetaotoken_aicg_blog_endutm_contentreadonly_mcp_cta_chat如果你的团队需要把 Codex、Claude Code、MCP 调用链统一管理查看 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentreadonly_mcp_cta_plan创建分账 Key把codex-exec、gpt6-pro-plan、mcp-readonly拆开https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentreadonly_mcp_cta_keys如果你还要用 Claude Code 做本地联调按文档配置settings.json和ANTHROPIC_*https://taotoken.net/doc/ClaudeCodeAnthropic?utm_sourcetaotoken_aicg_blog_endutm_contentreadonly_mcp_cta_doc最后再提醒一次只读 MCP Server 的价值不是“让模型什么都能读”而是让 GPT-6 Pro 在最小权限内读该读的让 Codex 不再为探索型上下文买单。Server 权限表、MCP 调用日志、额度对照这三份产出才是把 Codex 周额度省下来的可复现依据。