27 · 自动化与 CI/CD 完整指南

Codex GitHub Action、云端自动化和脚本任务的配置、认证、触发与审查流程，帮你安全地把代理接入持续集成。

把 Codex 接进 CI/CD，是「从工具到流水线」的关键一跃。这一篇讲怎么安全地把代理嵌入自动化流程。

「GitHub Action」是常见的落地方式：在 CI 流程里，用一个 Action 把 Codex 调用起来，让它自动执行某类任务——比如自动审查 PR、自动修 lint 报错。

「云端自动化」则是在云端环境里跑 Codex，适合那些不依赖你本机、可以在服务器上定时或触发执行的任务。

「脚本任务」是最灵活的：你可以写个脚本，在脚本里调用 Codex 的「非交互模式」，让它稳定地输出结果。这样 Codex 就成了你脚本流水线里的一环。

「认证」是接入 CI 时最要处理的：CI 环境里没有你的交互式登录，所以要用 token、密钥这类「非交互」的认证方式。

「触发」决定它什么时候跑：是每次 push 就跑、还是开 PR 才跑、还是定时跑。按需配置，别让它在不该跑的时候烧钱。

「审查」依然是底线：自动化跑出来的结果，不能直接放上线，得有人（或某道关卡）审过。自动化是「提效」，不是「免责」。

安全原则总结一句：自动化环境里的权限要「最小化」，token 要「妥善保管」，输出要「可审查」。把这三条守住了，Codex 进 CI 才是安全的。

常见误区：很多新手会把这一篇讲的「基本规则」当成「教条」——什么都严格遵守。其实这些规则的核心是「降低风险、提高效率」，理解了动机，规则就自然内化了，不用死记硬背。

动手试一下：你可以花 5 分钟做一个最小验证——找一个真实的代码任务，让 Codex 跑一遍，看它的行为是不是和这一篇描述的一致。理论与实践对照，才知道「懂」和「会用」是两件事。

延伸阅读：学完这一篇，你可以看本组里的下一篇，把相邻的概念连起来读；也可以跳到更后面的组学 MCP、子代理、Skills 这些更深的能力。知识是网状的，多跳几篇会理解更深。

判断决策树：用三个问题判断该不该用——① 这件事值不值得用 Codex 做？② 用的话该用哪个入口？③ 风险高不高需不需要审批？三个问题的答案一出来，怎么做就清楚了。