1. 从每天重复交代开始Codex Skill 到底解决什么问题如果你用 Codex 写过一段时间代码大概率经历过这种循环第一次让它审查改动你得说“先看 diff 再总结别把无关文件算进来”第二次让它写提交信息又得补一句“标题短一点正文分条”第三次让它整理接口文档还得重新交代“先讲用途再列参数最后给错误码”。每次都不算麻烦但每次都要重来一遍累积起来就是纯消耗。Codex Skill 就是冲着这个场景来的。它把一类重复任务的说明、流程、参考资料和可选脚本沉淀成一份“可复用工作手册”让 Codex 在遇到同类任务时直接按固定方法做事。它不是给模型换脑子也不是把复杂工作变成无脑按钮而是把你已经摸索出来的好方法整理成文件下次不用从头发明。这篇文章聚焦的是 Codex Skill 与 AGENTS.md 的协作机制在本地项目里把重复 Prompt 沉淀为可复用工作流同时把 AGENTS.md 里的模型接入配置改到 TaoToken 统一 Key/API 通道。适合谁适合已经在用 Codex 或类似编码 Agent、手里有一堆重复提示词、想让团队规范落地的开发者。读完你能拿到可复制的 AGENTS.md 片段、MCP 配置示例以及验证 Skill 触发是否生效的具体步骤。先厘清几个容易混的概念。AGENTS.md 像项目总规章告诉 Codex 在这个仓库里测试怎么跑、代码风格是什么、提交前注意什么Skill 像某项工作的操作手册指导 Codex 完成一类具体任务MCP Server 像外接工具接口让 Codex 连接文件、数据库、浏览器等外部能力脚本则是确定性强的自动化小工具。它们不是互相替代而是分工不同。Skill 管流程MCP 管连接脚本管稳定执行AGENTS.md 管项目级约束。我试过把“代码审查”这件事拆成 Skill 之后最大的变化不是结果变神奇了而是每次不用再重复那七八条要求。Codex 会先读 Skill 说明再按步骤走输出格式也稳定下来。下面就从实际配置开始一步步把这件事落到你的本地项目里。2. TaoToken 前置准备统一 Key 与 API 通道在写 Skill 和改 AGENTS.md 之前先把模型接入通道统一掉。很多人的 AGENTS.md 里散落着不同来源的 Base URL 和 Key换一个模型就要改一处团队协作时更是各写各的。把接入配置收敛到 TaoToken 一个通道后面 Skill 里引用模型时就不用关心底层是谁。TaoToken 的定位是统一的模型 API 通道官网在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 入口是 https://taotoken.net/api 。你需要先拿到一个 API Key然后把它写进项目配置或环境变量。注意Key 不要写进 Skill 文件也不要提交到仓库这是后面安全边界里会反复强调的点。具体操作路径打开控制台 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 在 API Keys 页面创建一个新 Key复制保存。如果你还没决定用哪个模型可以先到模型对话页面 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite 试一下对话效果确认通道可用。长期做编码和 Agent 任务的话可以看 Coding Plan https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 。拿到 Key 之后建议用环境变量管理而不是硬编码。Linux/macOS 下可以这样export TAOTOKEN_API_KEYsk-你的key export TAOTOKEN_BASE_URLhttps://taotoken.net/apiWindows PowerShell$env:TAOTOKEN_API_KEYsk-你的key $env:TAOTOKEN_BASE_URLhttps://taotoken.net/api如果你用的是 Claude Code 这类工具它有自己的配置入口可以参考 https://taotoken.net/claude-code-anthropic?utm_sourcetaotoken_aicg_blog_endutm_contentclaudecodeutm_campaignrewrite 里的说明把 Base URL 指向 TaoToken 的 API 地址Key 用刚创建的那个。这一步做完后面 AGENTS.md 和 Skill 里就只需要引用环境变量名不再出现具体 Key。为什么要先做这一步因为 Skill 和 AGENTS.md 会频繁引用模型配置。如果配置散落各处你改一次通道就要翻好几个文件还容易漏。统一到 TaoToken 之后换模型、换 Key、加团队新人都只动一处。这也是把“重复提示词”沉淀为“可复用工作流”的前置条件——工作流要稳定底层通道先得稳定。3. 可复制配置AGENTS.md 片段与 MCP 配置示例这一节给可直接复制的配置。先看 AGENTS.md。它的作用是项目级约束告诉 Codex 在这个仓库里总体要遵守什么。下面是一个精简但可用的片段你可以放在项目根目录的 AGENTS.md 里# AGENTS.md ## 模型接入 - 统一使用 TaoToken 通道 - Base URL: https://taotoken.net/api - API Key: 从环境变量 TAOTOKEN_API_KEY 读取禁止硬编码 - 默认模型: 通过环境变量 TAOTOKEN_MODEL 指定 ## 项目约定 - 提交前必须运行 npm run lint 和 npm test - 代码风格遵循仓库内 .eslintrc 配置 - 不要修改与当前任务无关的文件 - 涉及删除、发布、改生产配置的操作必须先向用户确认 ## Skill 使用 - 代码审查任务优先加载 skills/code-review/SKILL.md - 提交信息任务优先加载 skills/commit-message/SKILL.md - 技术博客任务优先加载 skills/tech-blog/SKILL.md注意这里没有出现具体 Key只写了环境变量名。这是刻意的AGENTS.md 会被提交到仓库Key 不能进去。接下来是 Skill 文件本身。以代码审查为例放在skills/code-review/SKILL.md--- name: code-review description: Use this skill when the user asks to review code changes, find bugs, or check a diff. --- # Code Review Skill ## 触发场景 当用户要求 review、审查代码、找 bug、检查 diff 时使用。 ## 执行步骤 1. 先读 diff理解改动意图 2. 检查边界情况和异常处理 3. 检查安全风险注入、越权、密钥泄露 4. 检查可读性和命名 5. 检查测试覆盖是否足够 6. 不要重构与任务无关的部分 ## 输出格式 ### 问题 - 文件:行号 - 问题描述 - 严重程度高/中/低 ### 建议 - 具体修改建议 ### 是否需要改代码 - 是/否并说明原因再看 MCP 配置。MCP Server 让 Codex 能连接外部能力比如文件系统或某个业务接口。下面是一个 MCP 配置示例通常放在项目的.mcp.json或工具指定的配置文件中{ mcpServers: { filesystem: { command: npx, args: [-y, modelcontextprotocol/server-filesystem, ./], env: { TAOTOKEN_API_KEY: ${TAOTOKEN_API_KEY}, TAOTOKEN_BASE_URL: https://taotoken.net/api } } } }如果你用的是 Cline 或类似支持 MCP 的客户端配置结构可能略有不同但核心三件套不变Base URL 指向https://taotoken.net/apiKey 从环境变量读取Model ID 通过TAOTOKEN_MODEL指定。这三件套在 AGENTS.md、Skill、MCP 配置里要保持一致否则会出现“配置写了但没生效”的情况。还有一个常见场景是 Codex 的auth.json。如果你用 Codex CLI它可能通过~/.codex/auth.json管理凭据。这个文件同样不要写死 Key而是引用环境变量或由工具在启动时注入。具体格式以你当前 Codex 版本为准但原则一样Base URL 用 TaoToken 的 API 地址Key 走环境变量Model ID 单独配置。配置写完先别急着跑复杂任务。下一步用最小请求验证通道和 Skill 是否真的生效。4. 验证请求确认 Skill 触发与调用生效配置写完不等于生效。这一节给具体验证步骤从通道到 Skill 逐层确认。第一步验证 TaoToken 通道本身可用。用 curl 发一个最小请求curl -s https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: $TAOTOKEN_MODEL, messages: [{role: user, content: 回复 ok}], max_tokens: 10 }如果返回里有choices字段和内容说明通道和 Key 没问题。如果返回 401说明 Key 无效或没读到环境变量如果返回local proxy failed之类说明 Base URL 写错了或网络层有问题。这一步先排除通道问题再往下查 Skill。第二步验证 AGENTS.md 被读取。在项目里让 Codex 做一个简单任务比如“总结当前仓库的测试命令”。如果它回答里出现了 AGENTS.md 中写的npm run lint和npm test说明项目级约束生效了。如果它答得泛泛说明 AGENTS.md 没被加载检查文件是否在项目根目录、命名是否正确。第三步验证 Skill 触发。给 Codex 一个明确的代码审查任务比如“审查我最近的改动找 bug”。观察它的输出结构如果按 Skill 里定义的“问题 / 建议 / 是否需要改代码”三段输出说明 Skill 被加载了。如果它只是随便说几句说明触发条件没匹配上。常见原因是 Skill 的description写得太窄或太宽或者文件路径不在 AGENTS.md 声明的目录里。第四步验证 MCP 连接。如果配置了 filesystem MCP让 Codex 读一个项目里的文件比如“读一下 README.md 的前 20 行”。如果它能读到内容说明 MCP 生效如果报连接错误检查command和args是否正确、npx是否可用、环境变量是否传入。第五步做一次端到端验证。让 Codex 完成一个完整任务读 diff、按 Skill 审查、输出结构化结果、必要时调用 MCP 读文件。整个过程如果顺畅说明 AGENTS.md、Skill、MCP、TaoToken 通道四层都通了。任何一层出问题都会在输出里露出痕迹按上面的顺序逐层排查即可。验证通过后建议把这次成功的任务记录保存下来作为 Skill 的参考样例。下次迭代 Skill 时有真实样例比凭空改描述靠谱得多。5. 本篇常见错排查401、local proxy failed、reading choices、OAuth配置和验证过程中最容易撞上几类报错。这一节按真实报错对照排查。401 Unauthorized。最常见的原因是 Key 没读到。先确认环境变量在当前 shell 里存在echo $TAOTOKEN_API_KEY如果输出为空说明没 export 或 export 在了别的 shell。另一个原因是 Key 复制时带了空格或换行重新复制一次。还有一种情况是 AGENTS.md 或 MCP 配置里写了${TAOTOKEN_API_KEY}但工具不支持这种占位符需要改成工具实际支持的写法。local proxy failed。这个报错通常指向 Base URL 或网络层。先确认 Base URL 是https://taotoken.net/api没有多余路径或拼写错误。然后确认当前网络能访问该地址。如果用了本地代理工具检查代理是否把该地址排除或错误拦截。注意这里不涉及任何网络访问方式建议只检查配置本身是否正确。reading choices 相关报错。这类报错通常出现在解析响应时说明请求发出去了但返回结构不符合预期。常见原因是 Model ID 写错或者请求体里model字段为空。检查TAOTOKEN_MODEL是否设置以及请求 JSON 里model是否正确引用。另一个原因是把非 chat 接口的返回当成了 chat 接口解析确认请求路径是/v1/chat/completions。OAuth 相关报错。如果你用的是 Claude Code 或类似工具它可能默认走 OAuth 流程。当你把 Base URL 改到 TaoToken 后OAuth 流程可能不再适用需要改用 API Key 方式。参考 https://taotoken.net/claude-code-anthropic?utm_sourcetaotoken_aicg_blog_endutm_contentclaudecodeutm_campaignrewrite 里的接入说明把认证方式从 OAuth 切到 API Key。切换后如果还报 OAuth 错误检查工具配置里是否残留旧的认证字段。Skill 不触发。如果通道正常但 Skill 没生效先检查 Skill 文件的description是否覆盖了你的触发词。比如你写“审查代码”但 description 里只写了“review diff”那“审查代码”可能匹配不上。把常见同义词都写进去。另一个原因是 Skill 文件路径不在 AGENTS.md 声明的目录里或者文件名大小写不对。MCP 连接失败。先单独在终端跑 MCP Server 的启动命令看是否能正常启动。如果命令本身报错说明依赖没装或路径不对。如果命令能跑但 Codex 连不上检查配置文件路径是否是工具读取的那个以及 JSON 格式是否合法。排查的核心思路是分层先确认通道再确认 AGENTS.md再确认 Skill最后确认 MCP。每层都有独立的验证方法不要跳层猜。6. 把重复 Prompt 沉淀为工作流从今天开始回到最初的问题Codex Skill 是什么它是把重复提示词沉淀为可复用工作流的机制。AGENTS.md 管项目级约束Skill 管任务级流程MCP 管外部连接TaoToken 管统一通道。四者配合你就不用每天给同一位“新同事”重新做入职培训。具体怎么开始从一个小任务入手比如提交信息助手。把你过去写得最顺的那次提示词找出来提炼成步骤和输出格式写成 SKILL.md。然后在 AGENTS.md 里声明它的路径。接着用真实任务跑三次看输出是否稳定。不稳定就改 description 或步骤稳定了就保留。接入配置方面把 Base URL 统一到https://taotoken.net/apiKey 走环境变量Model ID 单独配置。需要创建 Key 就去 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 接入细节看 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 。想先试模型效果就去 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite 长期做编码和 Agent 任务可以看 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 。最后提醒一句安全边界不要把 Key 写进 Skill 或 AGENTS.md不要让 Skill 鼓励 Codex 在证据不足时给确定结论涉及删除、发布、改生产配置的操作必须人工确认。Skill 的目标是让流程更清楚不是让人退出判断现场。从一个小 Skill 开始跑通验证再逐步扩展比一上来追求“大而全”靠谱得多。