很多人第一次看到Codex里的Scheduled Tasks会把它理解成定时运行一个Prompt。比如每天检查一次项目、定时整理Commit、自动扫描测试失败。但真正把Scheduled Tasks放进代码项目以后最容易踩坑的其实不是“几点运行”而是任务到底在哪里运行现在针对Git项目Codex的Scheduled Task可以直接在本地项目目录中执行也可以使用独立Worktree隔离执行。官方也明确建议如果自动任务可能产生代码修改Worktree能够避免Scheduled Task与开发者正在进行的本地工作互相冲突。所以真正需要理解的是Scheduled Task ↓ Execution Environment ↓ Local Project / Worktree ↓ Tools ↓ Changes ↓ VerificationScheduled Tasks不是普通提醒而是一种自动执行工作流。一、先理解Scheduled Task到底在自动什么普通Codex任务通常是打开项目 ↓ 输入任务 ↓ Codex执行 ↓ 查看结果Scheduled Task则把第一步变成自动触发Schedule ↓ Prompt ↓ Codex启动 ↓ 读取项目 ↓ 执行任务 ↓ 生成结果比如每天上午检查CI失败每晚扫描TODO每周整理Release Notes定期检查依赖变化每天汇总最近Commit。官方目前允许创建Scheduled Task时指定项目、Prompt、运行频率以及执行环境。问题也正是在这里出现如果这个任务会修改代码它应该直接修改你现在正在工作的目录吗这就是Local和Worktree的核心区别。二、Local Project是什么Local最容易理解。假设你的项目目录是/my-project你平时就在这里写代码 修改文件 运行测试 Git commitScheduled Task选择Local以后它运行时使用的也是这个项目环境。可以理解成Developer ↓ /my-project ↑ Scheduled Task双方操作的是同一个工作目录。它的最大优势就是环境最直接。Agent可以看到你当前目录里的真实状态。包括已经安装好的依赖本地配置当前文件甚至还没有提交的修改。对于一些只读任务这非常方便。例如分析最近Commit检查测试结果生成项目摘要扫描TODO因为任务只是读取项目并不会大量修改代码。这种情况下Local通常足够。三、Local真正危险的是“共享状态”问题出现在Scheduled Task开始写文件以后。假设你上午正在修改src/auth.ts此时一个定时任务自动启动每天10:00 ↓ 检查认证模块 ↓ 自动修复问题Agent也修改src/auth.ts现在就出现了Human Change Agent Change ↓ Same Workspace可能产生覆盖冲突Diff混乱测试状态变化Agent基于半完成代码继续执行。最麻烦的一种情况是开发者当前修改还没有Commit。Agent看到的是Repository Uncommitted Changes它甚至可能把你的临时修改理解成项目原本状态。于是任务输入实际上已经发生变化。这就是共享Workspace最典型的问题Shared Mutable State。四、Worktree解决的就是这个问题Git Worktree可以让同一个Repository同时拥有多个独立Working Tree。概念上可以理解成Repository ├── Main Workspace │ └── Developer │ └── Worktree └── Codex开发者继续修改自己的目录。Codex在另一份独立Working Tree执行。官方目前也把Worktree作为Codex并行任务和Scheduled Tasks的重要隔离机制对于Git RepositoryScheduled Tasks可以运行在专门的后台Worktree中从而避免自动任务干扰当前正在进行的本地修改。这里最关键的不是多复制了一份代码。真正重要的是Execution Isolation。五、什么时候优先选Local并不是Scheduled Task全部都应该使用Worktree。Local有非常明确的适用场景。1. 任务主要是读取例如总结昨日Commit检查项目TODO生成代码质量报告这种任务几乎不会修改代码。使用Local简单直接。2. 必须依赖当前本地状态有些任务就是需要读取当前未提交修改比如每天下班前总结我今天修改了什么。这时候如果使用独立WorktreeAgent看到的反而可能不是你当前真实工作状态。Local更加合理。3. 本地环境非常复杂例如项目依赖本地数据库特殊环境变量本地Service复杂开发工具链。如果新的Worktree需要大量初始化成本Local有时候会更省事。所以可以简单记成Read Current State ↓ Local六、什么时候应该优先选Worktree一旦任务会修改代码Worktree的价值就明显提高。例如自动修复Lint自动补测试处理简单Bug更新依赖定期重构某类代码这类任务如果直接运行Local相当于后台Agent会自动进入你正在工作的目录写代码。风险明显更高。使用Worktree以后Main Workspace ↓ Developer继续工作同时Background Worktree ↓ Scheduled Task执行两边可以相互隔离。因此一个很实用的判断方式是只读任务 → Local 写代码任务 → 优先Worktree当然不是绝对规则但作为默认策略非常实用。七、Worktree也不是完全“零成本”Worktree虽然解决隔离问题但也带来新的工程成本。其中最明显的是Environment Setup。创建一个新的Worktree以后它拥有代码文件。但不一定自动拥有完整运行环境。例如node_modules可能不存在。Python虚拟环境可能需要重新配置。某些.env文件可能没有进入Git。还有本地数据库缓存生成文件私有证书。也可能不存在。所以Git Worktree ≠ 完整可执行环境这也是为什么Codex的本地环境支持配置Setup Script用来准备Worktree所需要的环境。例如逻辑可能是Create Worktree ↓ Install Dependencies ↓ Load Environment ↓ Run Task如果没有这一层常见结果就是Local里运行正常Worktree里全部报错。八、Scheduled Task最容易出现的错误Prompt写得太宽比如创建一个任务每天检查项目并优化代码。看起来很合理。实际上非常危险。因为“优化代码”没有边界。Agent可能今天改auth明天改database后天又去refactor utils于是Scheduled Task从Automation慢慢变成Unbounded Agent。自动任务尤其需要明确Scope比如改成每天检查src/api目录中的ESLint错误仅修复能够通过现有测试验证的问题不修改公共接口。现在边界就清楚很多。九、一个好的Scheduled Task至少要有5个部分我建议自动任务不要只写一句Prompt。最好至少定义Goal Scope Action Verification Stop Condition例如Goal检查新增代码中的Lint问题。Scope只允许修改src/Action修复明确且低风险的Lint错误。Verification运行npm run lint npm testStop Condition如果测试失败或者需要修改公共API停止并报告。于是完整逻辑变成Find ↓ Analyze ↓ Modify ↓ Verify ↓ Stop / Report而不是Find ↓ 随便改这才是真正适合自动执行的任务。十、Scheduled Task一定要考虑Verification人工启动Codex时我们会自然查看结果。但Scheduled Task最大的不同是执行发生时人可能根本不在电脑前。所以Verification必须提前写进任务。例如自动补测试不要只写给没有测试的代码补测试。应该变成发现缺失测试 ↓ 创建测试 ↓ 运行相关测试 ↓ 确认通过 ↓ 报告修改文件如果测试失败不要继续扩大修改范围 ↓ 保留Evidence ↓ 报告失败所以Scheduled Task真正重要的不是自动运行。而是自动运行 自动验证。十一、自动任务不能把“Done”定义得太简单Agent执行结束并不等于任务完成。例如文件修改成功不代表功能正确所以可以把自动任务的完成条件分成三层。Execution Done代码修改完成。Verification Done测试通过。Acceptance Done结果符合任务目标。完整状态应该是Execute ↓ Test ↓ Validate ↓ Done如果没有VerificationScheduled Task只是Scheduled Modification。而不是Scheduled Engineering Workflow。十二、频繁Scheduled Task还要注意Worktree数量Worktree还有一个很实际的问题。如果任务频率很高每小时运行一次并且每次都创建独立Worktree时间长了可能累积很多工作树和任务记录。OpenAI官方文档也专门提醒频繁运行的Scheduled Tasks如果使用Worktree可能随着时间产生较多Worktree需要定期管理和归档已经不需要的运行。所以不是Worktree越多越安全而应该根据任务生命周期设计。例如每天一次通常问题不大。每小时一次就应该考虑是否真的需要Worktree是不是只读任务运行结果是否需要长期保存否则自动化系统自身就会产生新的维护成本。十三、Scheduled Tasks更适合哪些任务一个任务越符合下面几个条件就越适合自动化。重复每天或者每周都做。边界明确输入范围和修改范围清晰。验证明确可以用测试或者规则判断成功。风险较低失败不会产生严重后果。例如Lint检查测试扫描Commit摘要Release Notes依赖变化分析都比较适合。反过来重新设计认证架构大规模重构核心模块修改生产数据库就不应该因为“Scheduled Tasks可以运行”而直接自动化。十四、Skills和Scheduled Tasks放在一起会更有价值如果一个任务经常重复真正成熟的做法不是每一个Scheduled Task里面写几十行Prompt。而是把稳定流程抽成Skill。例如创建ci-failure-reviewSkill里面定义读取CI ↓ 分类错误 ↓ 定位代码 ↓ 运行相关测试 ↓ 输出报告Scheduled Task只需要负责什么时候运行 调用哪个Workflow于是系统变成Schedule ↓ Skill ↓ Execution ↓ Verification官方当前Scheduled Tasks也支持配合Skills使用。这时候Scheduled Task解决When。Skill解决How。两个概念就彻底分开了。十五、Local、Worktree到底怎么选可以直接使用下面这套判断。任务是否需要修改代码如果否优先考虑Local继续判断是否必须读取当前未提交修改如果是Local更加合适。如果是继续问开发者是否可能同时修改这个项目如果是优先Worktree然后检查依赖 环境变量 Setup Script 测试环境能否在Worktree里正常工作。最终可以抽象成Read Current State → Local Modify Shared Repo → Worktree Need Current Uncommitted State → Local Background Code Changes → Worktree十六、一套可以直接使用的Scheduled Task检查表创建任务前先检查① Goal 这个任务到底要完成什么② Scope 允许读取和修改哪些目录③ Environment Local还是Worktree④ Dependencies 新Worktree能否正常运行项目⑤ Permission 任务需要哪些文件、Shell和网络权限⑥ Verification 修改以后运行什么测试⑦ Stop Condition 什么情况下必须停止⑧ Evidence 运行结束以后留下什么结果真正可靠的Scheduled Task应该形成Schedule ↓ Environment ↓ Execute ↓ Verify ↓ Evidence最后Scheduled Tasks真正有价值的地方并不是Codex终于可以定时运行Prompt了。而是一些边界清楚、可以验证的软件工程任务开始能够从人工触发变成后台持续执行。但自动执行同时意味着Agent可能在你没有看着的时候读取项目执行命令修改文件运行测试。因此Execution Environment就变得非常重要。Local的优势是简单直接能够看到当前真实状态。Worktree的优势是隔离并行不会轻易污染开发者正在进行的工作。所以不要简单理解成Local 初级 Worktree 高级真正应该根据任务状态判断当前状态是否需要共享 ↓ 修改是否需要隔离 ↓ 环境能否独立运行 ↓ 结果能否自动验证当Scheduled Task真正进入开发工作流以后我们需要设计的就不只是什么时候运行。而是整个Automation Execution Boundary。这也是Codex从“人工调用的AI工具”走向“可以持续运行的工程执行系统”以后一个越来越重要的能力。持续更新Codex、大模型开发相关技术内容。长期使用各类代码大模型整理了稳定的AI会员订阅渠道。
很多人第一次看到Codex里的Scheduled Tasks会把它理解成定时运行一个Prompt。比如每天检查一次项目、定时整理Commit、自动扫描测试失败。但真正把Scheduled Tasks放进代码项目以后最容易踩坑的其实不是“几点运行”而是任务到底在哪里运行现在针对Git项目Codex的Scheduled Task可以直接在本地项目目录中执行也可以使用独立Worktree隔离执行。官方也明确建议如果自动任务可能产生代码修改Worktree能够避免Scheduled Task与开发者正在进行的本地工作互相冲突。所以真正需要理解的是Scheduled Task ↓ Execution Environment ↓ Local Project / Worktree ↓ Tools ↓ Changes ↓ VerificationScheduled Tasks不是普通提醒而是一种自动执行工作流。一、先理解Scheduled Task到底在自动什么普通Codex任务通常是打开项目 ↓ 输入任务 ↓ Codex执行 ↓ 查看结果Scheduled Task则把第一步变成自动触发Schedule ↓ Prompt ↓ Codex启动 ↓ 读取项目 ↓ 执行任务 ↓ 生成结果比如每天上午检查CI失败每晚扫描TODO每周整理Release Notes定期检查依赖变化每天汇总最近Commit。官方目前允许创建Scheduled Task时指定项目、Prompt、运行频率以及执行环境。问题也正是在这里出现如果这个任务会修改代码它应该直接修改你现在正在工作的目录吗这就是Local和Worktree的核心区别。二、Local Project是什么Local最容易理解。假设你的项目目录是/my-project你平时就在这里写代码 修改文件 运行测试 Git commitScheduled Task选择Local以后它运行时使用的也是这个项目环境。可以理解成Developer ↓ /my-project ↑ Scheduled Task双方操作的是同一个工作目录。它的最大优势就是环境最直接。Agent可以看到你当前目录里的真实状态。包括已经安装好的依赖本地配置当前文件甚至还没有提交的修改。对于一些只读任务这非常方便。例如分析最近Commit检查测试结果生成项目摘要扫描TODO因为任务只是读取项目并不会大量修改代码。这种情况下Local通常足够。三、Local真正危险的是“共享状态”问题出现在Scheduled Task开始写文件以后。假设你上午正在修改src/auth.ts此时一个定时任务自动启动每天10:00 ↓ 检查认证模块 ↓ 自动修复问题Agent也修改src/auth.ts现在就出现了Human Change Agent Change ↓ Same Workspace可能产生覆盖冲突Diff混乱测试状态变化Agent基于半完成代码继续执行。最麻烦的一种情况是开发者当前修改还没有Commit。Agent看到的是Repository Uncommitted Changes它甚至可能把你的临时修改理解成项目原本状态。于是任务输入实际上已经发生变化。这就是共享Workspace最典型的问题Shared Mutable State。四、Worktree解决的就是这个问题Git Worktree可以让同一个Repository同时拥有多个独立Working Tree。概念上可以理解成Repository ├── Main Workspace │ └── Developer │ └── Worktree └── Codex开发者继续修改自己的目录。Codex在另一份独立Working Tree执行。官方目前也把Worktree作为Codex并行任务和Scheduled Tasks的重要隔离机制对于Git RepositoryScheduled Tasks可以运行在专门的后台Worktree中从而避免自动任务干扰当前正在进行的本地修改。这里最关键的不是多复制了一份代码。真正重要的是Execution Isolation。五、什么时候优先选Local并不是Scheduled Task全部都应该使用Worktree。Local有非常明确的适用场景。1. 任务主要是读取例如总结昨日Commit检查项目TODO生成代码质量报告这种任务几乎不会修改代码。使用Local简单直接。2. 必须依赖当前本地状态有些任务就是需要读取当前未提交修改比如每天下班前总结我今天修改了什么。这时候如果使用独立WorktreeAgent看到的反而可能不是你当前真实工作状态。Local更加合理。3. 本地环境非常复杂例如项目依赖本地数据库特殊环境变量本地Service复杂开发工具链。如果新的Worktree需要大量初始化成本Local有时候会更省事。所以可以简单记成Read Current State ↓ Local六、什么时候应该优先选Worktree一旦任务会修改代码Worktree的价值就明显提高。例如自动修复Lint自动补测试处理简单Bug更新依赖定期重构某类代码这类任务如果直接运行Local相当于后台Agent会自动进入你正在工作的目录写代码。风险明显更高。使用Worktree以后Main Workspace ↓ Developer继续工作同时Background Worktree ↓ Scheduled Task执行两边可以相互隔离。因此一个很实用的判断方式是只读任务 → Local 写代码任务 → 优先Worktree当然不是绝对规则但作为默认策略非常实用。七、Worktree也不是完全“零成本”Worktree虽然解决隔离问题但也带来新的工程成本。其中最明显的是Environment Setup。创建一个新的Worktree以后它拥有代码文件。但不一定自动拥有完整运行环境。例如node_modules可能不存在。Python虚拟环境可能需要重新配置。某些.env文件可能没有进入Git。还有本地数据库缓存生成文件私有证书。也可能不存在。所以Git Worktree ≠ 完整可执行环境这也是为什么Codex的本地环境支持配置Setup Script用来准备Worktree所需要的环境。例如逻辑可能是Create Worktree ↓ Install Dependencies ↓ Load Environment ↓ Run Task如果没有这一层常见结果就是Local里运行正常Worktree里全部报错。八、Scheduled Task最容易出现的错误Prompt写得太宽比如创建一个任务每天检查项目并优化代码。看起来很合理。实际上非常危险。因为“优化代码”没有边界。Agent可能今天改auth明天改database后天又去refactor utils于是Scheduled Task从Automation慢慢变成Unbounded Agent。自动任务尤其需要明确Scope比如改成每天检查src/api目录中的ESLint错误仅修复能够通过现有测试验证的问题不修改公共接口。现在边界就清楚很多。九、一个好的Scheduled Task至少要有5个部分我建议自动任务不要只写一句Prompt。最好至少定义Goal Scope Action Verification Stop Condition例如Goal检查新增代码中的Lint问题。Scope只允许修改src/Action修复明确且低风险的Lint错误。Verification运行npm run lint npm testStop Condition如果测试失败或者需要修改公共API停止并报告。于是完整逻辑变成Find ↓ Analyze ↓ Modify ↓ Verify ↓ Stop / Report而不是Find ↓ 随便改这才是真正适合自动执行的任务。十、Scheduled Task一定要考虑Verification人工启动Codex时我们会自然查看结果。但Scheduled Task最大的不同是执行发生时人可能根本不在电脑前。所以Verification必须提前写进任务。例如自动补测试不要只写给没有测试的代码补测试。应该变成发现缺失测试 ↓ 创建测试 ↓ 运行相关测试 ↓ 确认通过 ↓ 报告修改文件如果测试失败不要继续扩大修改范围 ↓ 保留Evidence ↓ 报告失败所以Scheduled Task真正重要的不是自动运行。而是自动运行 自动验证。十一、自动任务不能把“Done”定义得太简单Agent执行结束并不等于任务完成。例如文件修改成功不代表功能正确所以可以把自动任务的完成条件分成三层。Execution Done代码修改完成。Verification Done测试通过。Acceptance Done结果符合任务目标。完整状态应该是Execute ↓ Test ↓ Validate ↓ Done如果没有VerificationScheduled Task只是Scheduled Modification。而不是Scheduled Engineering Workflow。十二、频繁Scheduled Task还要注意Worktree数量Worktree还有一个很实际的问题。如果任务频率很高每小时运行一次并且每次都创建独立Worktree时间长了可能累积很多工作树和任务记录。OpenAI官方文档也专门提醒频繁运行的Scheduled Tasks如果使用Worktree可能随着时间产生较多Worktree需要定期管理和归档已经不需要的运行。所以不是Worktree越多越安全而应该根据任务生命周期设计。例如每天一次通常问题不大。每小时一次就应该考虑是否真的需要Worktree是不是只读任务运行结果是否需要长期保存否则自动化系统自身就会产生新的维护成本。十三、Scheduled Tasks更适合哪些任务一个任务越符合下面几个条件就越适合自动化。重复每天或者每周都做。边界明确输入范围和修改范围清晰。验证明确可以用测试或者规则判断成功。风险较低失败不会产生严重后果。例如Lint检查测试扫描Commit摘要Release Notes依赖变化分析都比较适合。反过来重新设计认证架构大规模重构核心模块修改生产数据库就不应该因为“Scheduled Tasks可以运行”而直接自动化。十四、Skills和Scheduled Tasks放在一起会更有价值如果一个任务经常重复真正成熟的做法不是每一个Scheduled Task里面写几十行Prompt。而是把稳定流程抽成Skill。例如创建ci-failure-reviewSkill里面定义读取CI ↓ 分类错误 ↓ 定位代码 ↓ 运行相关测试 ↓ 输出报告Scheduled Task只需要负责什么时候运行 调用哪个Workflow于是系统变成Schedule ↓ Skill ↓ Execution ↓ Verification官方当前Scheduled Tasks也支持配合Skills使用。这时候Scheduled Task解决When。Skill解决How。两个概念就彻底分开了。十五、Local、Worktree到底怎么选可以直接使用下面这套判断。任务是否需要修改代码如果否优先考虑Local继续判断是否必须读取当前未提交修改如果是Local更加合适。如果是继续问开发者是否可能同时修改这个项目如果是优先Worktree然后检查依赖 环境变量 Setup Script 测试环境能否在Worktree里正常工作。最终可以抽象成Read Current State → Local Modify Shared Repo → Worktree Need Current Uncommitted State → Local Background Code Changes → Worktree十六、一套可以直接使用的Scheduled Task检查表创建任务前先检查① Goal 这个任务到底要完成什么② Scope 允许读取和修改哪些目录③ Environment Local还是Worktree④ Dependencies 新Worktree能否正常运行项目⑤ Permission 任务需要哪些文件、Shell和网络权限⑥ Verification 修改以后运行什么测试⑦ Stop Condition 什么情况下必须停止⑧ Evidence 运行结束以后留下什么结果真正可靠的Scheduled Task应该形成Schedule ↓ Environment ↓ Execute ↓ Verify ↓ Evidence最后Scheduled Tasks真正有价值的地方并不是Codex终于可以定时运行Prompt了。而是一些边界清楚、可以验证的软件工程任务开始能够从人工触发变成后台持续执行。但自动执行同时意味着Agent可能在你没有看着的时候读取项目执行命令修改文件运行测试。因此Execution Environment就变得非常重要。Local的优势是简单直接能够看到当前真实状态。Worktree的优势是隔离并行不会轻易污染开发者正在进行的工作。所以不要简单理解成Local 初级 Worktree 高级真正应该根据任务状态判断当前状态是否需要共享 ↓ 修改是否需要隔离 ↓ 环境能否独立运行 ↓ 结果能否自动验证当Scheduled Task真正进入开发工作流以后我们需要设计的就不只是什么时候运行。而是整个Automation Execution Boundary。这也是Codex从“人工调用的AI工具”走向“可以持续运行的工程执行系统”以后一个越来越重要的能力。持续更新Codex、大模型开发相关技术内容。长期使用各类代码大模型整理了稳定的AI会员订阅渠道。
