在 issue-driven AI engineering 里，最容易混淆的一件事是：到底谁负责调度，谁负责执行？

很多人会本能地把 Codex 或其他 coding agent 当成“全能工程师”：它读 issue、决定优先级、判断风险、改代码、开 PR、甚至继续追踪发布。这种想法很自然，但工程上很危险。

更稳妥的边界是：Codex 应该是 worker，不应该是 scheduler。

Worker 适合一次性、局部、可验证的工作

Codex 擅长的是在一个明确上下文里做局部工程任务。

它可以读一个 issue，理解当前代码，定位相关文件，提出实现方案，改一小组文件，运行测试，然后把证据写出来。这个过程天然像一次 worker run。

worker run 的特点是：

  • 有清晰输入；
  • 有明确边界；
  • 有开始和结束；
  • 可以超时；
  • 可以失败；
  • 可以重跑；
  • 可以被 human review。

这正是 AI coding 工具比较适合的形态。

如果你让 Codex 一直守着仓库、扫描所有 issue、管理并发、处理锁、恢复失败任务、判断哪些 PR 应该进入发布，那它就不再是 worker，而是在承担 scheduler 的职责。

Scheduler 需要的是稳定状态，不是一次聊天上下文

Scheduler 的任务不是“聪明”，而是“可靠”。

一个 scheduler 至少要处理：

  • 哪些 issue 被允许进入自动化；
  • 哪些 issue 仍然需要 triage；
  • 当前哪个 worker claim 了哪个 issue；
  • 一个 issue 是否已经有对应 branch；
  • worker 是否超时；
  • 上一次执行停在了哪里；
  • label 和 comment 是否与真实状态一致；
  • 失败任务是否需要重试或升级给人；
  • PR merged 之后是否还需要 release verification。

这些事情不适合放在一次 AI 对话里。

原因很简单：对话上下文会丢，进程会中断，模型会升级，prompt 会变化，worker 也可能被替换。长期状态应该放在更稳定的系统里：GitHub label、branch、comment、PR、workflow log、本地 state file 或专门的 daemon。

AI 可以参与判断，但不应该成为唯一状态源。

一个清晰的分工

在一个健康的 issue-driven workflow 里，scheduler 和 worker 的职责应该分开。

Scheduler 负责：

  • 扫描 issue；
  • 判断是否 opt-in；
  • 检查风险标签；
  • 分配 workspace；
  • 建立 branch claim；
  • 启动 worker；
  • 记录状态转移；
  • 处理超时和恢复；
  • 把不确定任务交回 human。

Codex worker 负责：

  • 阅读 issue contract；
  • 阅读相关代码；
  • 分析原因；
  • 判断是否触发停工条件；
  • 在授权范围内改代码；
  • 运行测试；
  • 生成 evidence；
  • 准备 PR summary；
  • 报告 blocked 或 needs-human。

这个分工的好处是：worker 可以替换，scheduler 不必重写；scheduler 可以升级，worker prompt 也不必变成一个庞大的状态机。

不要让 worker 偷偷变成 release controller

最需要警惕的是发布边界。

Codex worker 可以开 PR，可以写 release notes，可以给出验证建议。但它不应该因为“测试通过”就把 issue 标记为 done，更不应该默认接管生产发布。

PR open 只是进入 review。PR merged 只是代码进入主干。生产验证是否完成，是另一个边界。

如果 worker 既负责实现，又负责判断任务完成，又负责发布闭环，那么系统会失去审计分层：你很难知道一个状态变化到底是业务判断、工程判断，还是 AI 的自我确认。

最小可行做法

如果你暂时没有 daemon，也可以手动模拟这个边界：

  • human 负责选择 issue；
  • human 判断 automation mode；
  • human 在本地启动 Codex；
  • Codex 只执行这一个 issue；
  • Codex 输出 evidence；
  • human review PR；
  • human 决定是否发布和关闭 issue。

这已经比“在聊天里让 AI 随便改一下”稳定很多。

真正重要的不是第一天就自动化，而是先把职责切开。

当 Codex 是 worker 时，它可以很强。当 Codex 被迫变成 scheduler、reviewer、release controller 和 product owner 时，它反而会变成系统风险。