企业官网建设流程全解析

• AI 技能
• AI 插件

本指南以 AAS（agentic-awesome-skills）仓库中codex-delegate技能的 references/multi-task-queues.md 为核心，讲解如何把单任务委派循环扩展为可信的多任务队列：涉及跨层代码移除、多文件迁移、重构清扫等场景。读完你将掌握顺序执行的纪律、跨任务约束的显式传递方法、进度文件的维护规范、收尾一致性校验清单，以及"何时停下询问"的边界判断——这些能力直接决定一个委派队列是高质量落地还是产生一堆错误方向的提交。

codex-delegate是 AAS 技能库中agent-orchestration类目下的一个委派技能（见 SKILL.md），其核心模型是：编排者（orchestrator）写 brief 并拥有判断权，OpenAI Codex CLI 作为实现者（implementer）在自己的沙箱中动手，编排者负责复核与提交。它的单任务循环是"写 brief → 派发 → 等待 → 评审 → 落地"五步；多任务队列就是把这个循环按依赖顺序重复执行，同时加上记账与收尾校验的纪律。

一、多任务队列的价值定位：排序与记账，而非并行

单任务循环扩展到队列，正是委派收益最大的地方——一次跨多层的移除、一次触碰许多文件的迁移、一次重构清扫，都天然是队列形态。但文档开宗明义地给出了一条核心判断：

让队列值得信赖的纪律是排序（sequencing）和记账（bookkeeping），而不是并行（parallelism）。

这句话是整个队列编排的方法论基石：把任务按依赖关系排好序、把每个任务的进展与决策记录下来，比同时扇出多个任务更能保证最终结果的正确性与可追溯性。

二、顺序执行：一个任务，一个提交

面对整个队列，最自然的冲动是"一次全部扇出"，但文档明确要求克制：

逐个运行任务，按依赖顺序执行；每落地一个（评审 + 门禁 + 提交）之后，再派发下一个。理由有三：

1. 后任务假设先前任务已经落地。任务 3 的 brief 里写"上一步新增的 X 已存在"，只有当上一步真的提交了，这个前提才成立。
2. 每个任务一个提交，保证历史可审查、任何单步都可回滚。
3. 每次评审都是诚实的。每次派发前工作树是干净的，意味着下一个任务的touchedFiles只显示它自己的改动，而不是前面任务堆积的混合改动。

并行只有在任务真正相互独立且改动不同文件时才偶尔值得——但它牺牲了"每任务干净工作树"这一特性，也让评审变得更难。因此默认顺序执行。

这与 writing-the-brief.md 中"一个 brief 一个任务（One task per brief）"的原则互为表里：一个 brief → 一次 Codex 运行 → 一个提交，保持评审与回滚的干净边界，也让后一个任务可以安全地假设前一个任务已落地。

三、向前携带已定约束：补齐 Codex 的"无记忆"短板

实现过程会暴露原计划中不存在的事实：某个 helper 被命名了、某个 fixture 落在特定位置、某个接口被选定。当后续任务依赖这些事实时，必须把它们折叠进该任务的 brief，作为一行显式约束。

原因很直接：Codex 在全新进程中运行，没有对先前运行的任何记忆，也没有共享上下文（参见 SKILL.md 中"Codex sees only the text you send"的说明）。任务 2 中浮现的约束，若不在任务 5 的 brief 中重述，就不会成立。这正是"brief 自包含"原则在队列层面的延伸——每个 brief 都要能脱离对话历史独立执行，而队列约束传递就是这种自包含性的跨任务版本。

四、维护一个进度文件：跨上下文限制的持久记录

任何超过两三个任务、尤其是人类会中途离开的长时间运行，都必须在工作目录旁维护一个单一进度文件。它是能够存续于你自己的上下文限制之外的持久记录，让人类随时可以一眼赶上进度。

文档给出的有效结构包含四部分：

关键纪律：每个任务落地时就更新进度文件，而不是最后统一批量更新——如果运行被打断，文件仍然保持准确。

这也呼应了 review-and-land.md 的"Surface, don't absorb"原则：多任务运行时，把需要上报的设计决策与 nitpick 写进进度文件而不是让它们随对话滚动流逝。

五、收尾一致性校验：整体不等于各步之和

每任务评审只能证明每个步骤在孤立状态下正确，并不能证明这些步骤相互一致。因此在最后一个任务完成后，必须校验整体：

1. 在最终工作树上完整运行一次测试/构建——不只是最后任务的那一小片改动。
2. 做一次针对队列主题的全仓检查：例如移除操作之后，grep 整个仓库树查找任何残留引用；重命名之后，确认没有遗漏的旧名称。
3. 对 schema 类工作：从干净状态重放所有新增迁移，检查是否存在 drift（漂移）。
4. 然后 push 并打开或更新 PR，PR 描述要如实反映实际交付的内容。

这一步与 review-and-land.md 中"复跑门禁、检查测试是否被削弱、做实现者清扫（implementer sweep）"的评审纪律配套：门禁通过是必要但不充分的条件，收尾一致性校验是门禁之外的全局防线。

六、何时停下询问：三个明确的停止条件

人类选择队列模式，意味着凡是按约定计划自然派生的事情都不必询问——这正是队列的意义。但以下三种情况必须停下并上报：

• 某任务无法在其 brief 范围内正确完成（范围变更是人类的决定，不是你的，也不是 Codex 的）；
• 评审发现了质疑计划本身（而非仅质疑实现）的问题；
• 门禁揭示了会影响已"完成"任务的问题。

此时应报告：当前进展到哪一步、已提交了什么、开放问题是什么——然后等待。文档给出的警示一针见血：

一个悄悄绕过错误假设的队列，会产生大量方向错误的提交。

这与 SKILL.md 中的授权模型完全一致：人类 opt-in 之后，提交"已复核且门禁通过"的工作是约定契约；但契约有两条边界——surface, don't absorb（上报 Codex 的设计决策与未要求但可辩护的转向，而不是默默吸收）与stop for scope changes（正确完成需要超出 brief 时，询问，不要自行扩大授权）。

七、与单任务循环的衔接：队列中的每个任务仍走完整五步

需要强调：队列中的每一个任务仍然是完整的单任务循环，与 SKILL.md 中定义的五步完全一致：

1. 写 brief——目标、当前状态、要改什么、不要碰什么、项目真实的门禁命令（从仓库的CLAUDE.md/AGENTS.md/Makefile中现查，绝不假设），以及报告契约；并明确告诉 Codex 它不会提交（由编排者提交）。
2. 派发——用捆绑的relay.mjs包装codex exec，捕获运行并产出结构化result.json。常用方式：node "<skill-dir>/scripts/relay.mjs" --brief brief.txt --cd /path/to/repo；续跑上一会话用--session <threadId>（来自上次result.json），无 thread id 时回退--resume-last，需要看门狗时加--timeout 2h（详见 dispatch-and-poll.md）。
3. 等待完成——relay 阻塞直到 Codex 结束；以result.json写出且进程退出为准，不信任任何进度条。
4. 评审，不轻信自述——自己复跑门禁、对照 brief 读 diff（touchedFiles是起点）、有guard-skills（如clean-code-guard、test-guard）时在 diff 上运行对应守卫技能。
5. 落地——门禁通过且 diff 经得起推敲后，由编排者自己提交，Codex 从不提交（沙箱无法可靠写入.git，且提交本应是完成验证一方的职责）。

队列就是对这个循环的按依赖序重复，外加本指南的进度记账与收尾校验。此技能在仓库中还有一份对应副本位于 plugins/agentic-awesome-skills/skills/codex-delegate，两处文档一致。

八、实践建议小结

• 默认顺序，明确例外：只有改动不同文件的真正独立任务才考虑并行，且要接受"干净树每任务"特性的代价。
• 把约束写进 brief，而不是寄托于记忆：Codex 无跨任务记忆，任务 2 的决策必须在任务 5 的 brief 里显式重述。
• 进度文件与任务同步更新：超过两三个任务就维护；状态表、评审笔记、Needs your eyes、结束清单四件套缺一不可。
• 收尾必做整体校验：全量测试/构建 + 主题性全仓扫描（移除 grep 残留、重命名查遗漏）+ schema 干净重放查 drift，再 push 与开 PR。
• 守住停止边界：brief 范围内无法完成、计划本身被质疑、门禁波及已完成任务——三种情况立即停下上报并等待。

按这套纪律运行的队列，才能在人类逐步放手的长任务中持续产出方向正确、可审查、可回滚的提交。

• AI 技能
• AI 插件