1. 为什么我要把 OA 工时填报交给 Codex Chrome 插件每个月最后一周我都要做同一件事打开工作计划表逐条核对任务登录 OA创建任务登记工时再回头检查有没有漏填。动作本身不难难的是脑子里那套隐性规则一直在运转——哪些任务只是计划不能填、哪些日期已经填过要跳过、系统弹提示时是继续还是停、月底发现少几天要不要找相近任务补上。这些判断都不复杂但它们持续消耗注意力而且一旦分神就容易出错。Codex Chrome 插件让 Codex 可以直接在 Chrome 里工作使用真实浏览器页面和已登录会话。对我来说这个能力的意义不是AI 终于能点网页了而是它让很多原来只能手工处理的企业后台流程有了被重新设计的可能。OA 系统依赖浏览器登录态、公司 SSO、页面权限和复杂前端组件直接写脚本或调接口都不一定现实而 Chrome 插件恰好补上了进入真实工作现场这一环。不过这里有个前提任何 Agent 操作都会消耗 token。它不是免费的后台脚本也不是可以无限试错的廉价劳动力。所以真正值得做的不是让 Agent 反复替你执行零散动作而是把高频、重复、规则清晰的工作流沉淀下来让每一次 token 消耗都在积累流程资产。这篇文章要做的就是先给出 config.toml 与 settings.json 骨架把 TaoToken 统一 Key/API 通道接入 Codex再演示将填报动作沉淀为可复用 Skill 的完整链路目标是一次配置后稳定跑通工时自动填报。2. TaoToken 前置统一 Key 与 API 通道在动手写配置之前先把通道这件事理清楚。Codex 本身支持自定义模型提供方而 TaoToken 提供的是统一的 Key 与 API 通道你只需要一个 Key就能在 Codex、Claude Code、以及各种兼容 OpenAI 协议的工具之间复用同一套接入方式。官网地址是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 入口是 https://taotoken.net/api 。你需要提前准备的东西只有三样一个 TaoToken 账号、一个 API Key、以及本机已经装好的 Codex CLI 或 Codex 桌面端。Key 的创建入口在控制台的 API Keys 页面建议单独建一个给 Codex 用的 Key方便后续按项目排查用量。注意Key 只显示一次创建后立刻复制到本地配置文件不要贴在聊天记录或截图里。拿到 Key 之后先确认通道连通性再动 Codex 的配置。这一步能帮你把Key 问题和配置问题分开后面排障会省很多时间。curl https://taotoken.net/api/v1/models \ -H Authorization: Bearer $TAOTOKEN_API_KEY如果返回模型列表说明 Key 和通道都正常。如果返回 401先检查 Key 是否复制完整如果返回超时检查本机网络出口是否允许访问该域名。3. 可复制配置config.toml 与 settings.json 骨架Codex 的配置分两层一层是模型提供方配置通常放在~/.codex/config.toml另一层是编辑器或插件侧的 settings.json用来声明 Codex Chrome 插件的行为。下面这份骨架可以直接复制把TAOTOKEN_API_KEY替换成你自己的 Key 即可。# ~/.codex/config.toml model gpt-5-codex model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api/v1 env_key TAOTOKEN_API_KEY wire_api chat [profiles.oa] model gpt-5-codex model_provider taotoken approval_policy on-request sandbox_mode workspace-write这里有几个参数值得单独说。base_url指向 TaoToken 的 API 入口注意结尾是/v1不要多写也不要少写。env_key表示 Key 从环境变量读取比直接写死在文件里安全。wire_api chat对应 OpenAI 兼容的 chat 接口Codex 会按这个协议发请求。approval_policy on-request让 Codex 在需要执行敏感操作时先问你这对 OA 这种涉及提交动作的场景很关键。环境变量这样设置# macOS / Linux export TAOTOKEN_API_KEYsk-你的Key # Windows PowerShell $env:TAOTOKEN_API_KEYsk-你的Key接下来是 Codex Chrome 插件侧的 settings.json。这个文件一般放在项目根目录的.codex/下或者插件指定的配置目录里。{ codex.chrome.enabled: true, codex.chrome.profile: oa-work, codex.chrome.allowedOrigins: [ https://oa.example.com ], codex.chrome.requireApprovalForSubmit: true, codex.chrome.skillDir: .codex/skills, codex.chrome.maxStepsPerRun: 40 }allowedOrigins限定插件只能在你指定的 OA 域名下操作避免误触其他站点。requireApprovalForSubmit打开后任何提交类动作都会先弹确认这是保留人的确认权最直接的方式。skillDir指向 Skill 目录后面沉淀规则就靠它。maxStepsPerRun是单次运行的最大步数防止 Agent 在异常页面上无限循环烧 token。4. Skill 目录结构与规则沉淀Skill 的本质是一套针对某类任务的工作流说明。它记录的不是某一次操作而是下一次遇到类似任务时应该默认遵守的规则。目录结构建议这样组织.codex/ └── skills/ └── oa-timesheet/ ├── SKILL.md ├── rules.yaml └── examples/ └── 2026-05-sample.mdSKILL.md是主入口写清楚这个 Skill 的适用场景和整体流程。rules.yaml把判断规则结构化方便 Codex 逐条读取。examples/放历史样例让 Codex 在生成填报内容时有参照。先看SKILL.md# OA 工时填报 Skill ## 适用场景 每月末根据工作计划文件在 OA 系统登记工时。 ## 执行前提 - 使用 Codex Chrome 插件复用已登录会话 - 任务来源以最新版工作计划文件为准 - 提交前必须经过用户确认 ## 流程 1. 读取工作计划文件提取任务与日期 2. 打开 OA 工时页面比对已填记录 3. 对未填日期生成填报草稿 4. 列出缺失日期询问用户是否补齐 5. 用户确认后逐条提交再看rules.yaml把之前散落在脑子里的判断显性化rules: - id: source_of_truth desc: 任务来源以最新版工作计划文件为准 - id: no_forecast desc: 预测任务不提前处理等实际计划 - id: no_date_expand desc: 工时日期不能随意扩展以来源数据为准 - id: skip_filled desc: 同人同日已填报则跳过 - id: weekend_keep desc: 周末若来源数据明确写了则保留 - id: missing_confirm desc: 发现缺失日期先提示用户确认不自动编内容这份 rules.yaml 就是整个工作流重构的核心。原来逻辑散落在人的脑子里现在被抽取出来变成了一个可以复用、可以修改、可以演进的模块。Skill 的价值不是写一份说明书而是把一次次人工纠偏沉淀成下一次自动执行时的默认能力。5. 验证请求与成功结果配置写完先做一次最小验证确认 Codex 能通过 TaoToken 通道正常对话。启动 Codex 后执行codex --profile oa 读取 .codex/skills/oa-timesheet/SKILL.md告诉我这个 Skill 的适用场景如果返回了 Skill 的适用场景描述说明模型通道和 Skill 加载都正常。这一步不涉及浏览器操作纯粹验证配置链路。接着验证 Chrome 插件能否接管页面。在 Codex 里发起codex --profile oa 打开 https://oa.example.com/timesheet告诉我当前页面标题和已填工时的日期列表预期结果是 Codex 通过 Chrome 插件读取到真实页面返回页面标题和已填日期。如果这一步成功说明登录态复用和页面读取都通了。最后跑一次完整的填报演练但先不提交codex --profile oa 根据 .codex/skills/oa-timesheet/ 的规则比对工作计划文件和 OA 已填记录列出需要填报的日期草稿不要提交成功的结果应该是Codex 输出一份日期与任务对照的草稿并明确列出缺失日期等待你确认。到这一步整条链路就打通了——配置、通道、Skill、浏览器操作、确认点全部就位。6. 本篇常见错排查报错一401 Unauthorized。多数是 Key 没读到。先确认TAOTOKEN_API_KEY在当前 shell 里能echo出来再确认 config.toml 里的env_key拼写和变量名完全一致。如果是在 IDE 里启动 Codex注意 IDE 可能没继承你终端的环境变量需要在 IDE 的启动配置里单独设置。报错二404 Not Found。检查base_url是否写成了https://taotoken.net/api而漏了/v1。Codex 会在这个地址后面拼接/chat/completions少一段路径就会 404。报错三插件读不到页面。先确认allowedOrigins里的域名和实际 OA 地址完全一致包括协议和端口。如果 OA 用了子域名要把子域名也加进去。另外确认 Chrome 里已经登录 OA插件复用的是当前会话没登录自然读不到。报错四Skill 没被加载。检查skillDir是相对项目根目录还是绝对路径两种写法 Codex 的处理方式不同。建议先用绝对路径验证确认能加载后再改成相对路径。另外SKILL.md的文件名大小写敏感必须是全大写。报错五Agent 在页面上反复循环。多半是页面元素定位失败Agent 在重试。先把maxStepsPerRun调小比如改成 10让它快速失败而不是烧 token。然后手动打开页面确认 DOM 结构必要时在 Skill 里补充页面元素的选择器说明。报错六提交动作没弹确认。检查requireApprovalForSubmit是否被其他配置覆盖。有些项目级配置会覆盖全局配置确认当前 profile 下这个值是 true。7. 把配置变成长期能力这套流程跑通之后你会发现真正有价值的不是AI 帮我填了一次工时而是规则被写下来了、异常被分类了、确认点被设计出来了、错误被转化成 Skill 更新了。下一次执行会继承这一次的经验流程资产在累积。如果你还在排障阶段建议先去 API Keys 页面确认 Key 状态再对照接入文档检查配置API Keys 入口在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。想先验证模型对话是否正常可以直接用模型对话页面试一条请求https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。如果你打算把这类编码和 Agent 工作流长期跑下去Coding Plan 会更适合https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。我自己的习惯是每跑完一个月就把新遇到的异常规则补进 rules.yaml把典型样例丢进 examples/。Skill 不是一次写完的它是跟着你的工作流一起进化的。
