# 1 阅读交接文档：[2026-06-24-character-consistency-workflow-review-handoff.md](C:/Users/wangq/Documents/Codex/video-workbench/handoff/2026-06-24-character-consistency-workflow-review-handoff.md) 我下面准备开始人物一致性的骨架展开，并做流程试运行测试。 人物一致性单镜骨架文件：`C:\Users\wangq\Documents\Codex\video-workbench\projects\2026-06-23-在路上\intake\阶段五-人物一致性单镜.md` 前面的会话做了第一个s05，发现了一些问题。 现在汲取这些教训，我们准备开始新一轮的测试，分两步： 1. 接下来一个镜头，S-21 交给子会话，让它完成全部从brief ~ 生图。同时记录子会话id。完成后暂停，等我确认。 你要验证/检查的点： * 子会话是否启动了Agent S-21 * 是否完成了任务 * 明确不要review的话，是否生成了review * 是否调用advisor来生成提示词 * 提示词中是否有明确且正确的人物风格（锚板/裁切）的使用 * 是否正确使用或借鉴了的style母版 我来看生成的图是否可用。 2. 步骤1正常的话。接下来两个镜头，S-14、S-25，继续发给步骤1的子会话。 你的检查点： * 子会话是否继续工作 * 是否继续调用了两次Agent S-14和Agent S-25。 * 三个镜头，需要三个Agent工作。而不是续着其中某个。 * 生成了结果图，Prompt是否使用advisor来生成，Prompt中是否有正确的人物、风格锚板的使用 我来看生成的两个图是否可用 注意这里不要用前一轮的那个child-session id `019ef77d-552b-7343-abe4-88921b35d7ea`。 Codex有两种子会话机制，我们需要先确定哪一种更适合当前的子会话形式。 作废前面那个child-session，重新开。 先对齐思路。 对齐后，我建议这轮用 `multi_agent_v1.spawn_agent/send_input` 这套子 agent 机制，不用 Codex 线程级 `create_thread/fork_thread`。 理由：这次要验证的是三层编排： ```text main session -> 新 child session -> child session 启动单镜 slide-agent -> slide-agent 完成 brief / prompt / image / return ``` `multi_agent_v1` 正好能记录 child agent id、slide-agent id，并且理论上支持 descendant agent；Codex 线程级机制更适合用户侧栏里的长期/独立线程，但会多出一个线程层，反而不利于判断“child session 是否自己启动了 Agent S-21”。 执行思路： 1. 不沿用旧 id `019ef77d-552b-7343-abe4-88921b35d7ea`。 新开一个 child session，建议记录为新的 `session-02`，并在任务记录里标明 `session-01` 作废/仅保留为上一轮证据。 2. S-21 第一轮只交给新 child session。 它必须自己启动 `Agent S-21`，并记录 slide-agent id。若 child session 不能启动 slide-agent，就写明 `runtime fallback required` 并停止，不由主会话悄悄接手。 3. 本轮把 review 显式关掉。 Packet 里写清楚：`Review Rule: disabled; do not write s21-v1-review.md`。这样才能测试“明确不要 review 时，是否仍生成了 review”。你的人工看图就是这一轮的视觉判断。 4. S-21 的 prompt 必须走 `gpt-image-2` Advisor / host-native workflow。 Prompt 里要记录 mode check、Skill/template/reference basis、source files read；不能主会话自由手写 prompt。 5. S-21 的参考选择我会要求： `Image 1` 优先用 `character-anchor-v2-walk-side-reference-crop-tight.png`，用于侧背动态、背包、外套、步态；必要时辅以 `character-slice-walk-side-v2-from-anchor.png`。风格必须使用 D 模块：夜路小火、小范围暖光、火是方向不是露营。 6. S-21 完成后暂停。 我检查并报告：新 child id、S-21 agent id、是否完成、是否误写 review、是否调用 Advisor、prompt 是否正确使用人物参考和 D 风格母版、图像路径。然后等你看图确认。 如果 S-21 正常，再把 S-14、S-25 继续发给同一个新 child session，并要求它分别启动两个新的 slide-agent：`Agent S-14` 和 `Agent S-25`。三个镜头必须对应三个单镜 agent，不能让一个 agent 续做多个镜头。 # 2 现在不执行，先讨论机制漏洞。 这里还需要注意的，S-05执行的时候把我的原来的图覆盖掉了。这个上一个回合你也没检查出来。 S05实际上已经跑过一次，有原始的image，但是缺prompt、brief。 第一轮相当不规范。 从我角度出发，可以覆盖。第一轮的内容可以作废。 但是这里有个隐患，s05再跑一遍地话，会不会还覆盖。所以我觉得这个需要先讨论确认下机制。 现在的tasks和slides那边，会不会是脱节的两套。 是的，这里确实有机制漏洞，而且 `S-05` 已经暴露出来了。 根因不是“能不能覆盖”，而是现在的路径语义不够硬： `slides/s05/s05-v1-image.png` 同时被当成了“第一次 broad-run 候选图”和“人物一致性重跑结果图”。所以重跑 `s05-v1` 时，文件名没有变，旧图就被新图覆盖了。上一轮检查只验证了“新图是否生成并复制成功”，没有做“复制前该路径是否已有资产、是否允许覆盖”的 preflight，这是漏检。 `tasks/` 和 `slides/` 现在确实有脱节风险，但它们不应该是两套真相。合理分工应该是： `slides/sNN/` 是 durable artifact source of truth：brief、prompt、image、review 都在这里，版本号代表一次具体产物链。 `tasks//` 是 orchestration source of truth：谁启动了谁、哪个 agent id、运行模式、是否允许 review、是否允许 generation、返回文件、检查结果。它只能链接 `slides/` 产物，不能让任务记录暗示一个不存在或被覆盖的 slide 版本。 下一轮机制我建议先定死三条： 1. **同名版本默认不可覆盖** 只要 `slides/s21/s21-v1-image.png` 已存在，新测试就不能再写 `s21-v1-image.png`。即使旧图作废，也不要无声覆盖。新一轮应写 `s21-v2-brief.md / s21-v2-prompt.md / s21-v2-image.png`。 2. **旧 broad-run 候选标记为 superseded，而不是伪造补齐** `s05/s14/s21/s25` 这些旧 `v1` 有图但缺 brief/prompt，不能后来补一个 `v1-prompt` 假装它就是当时生成用的 prompt。最多写“v1 broad-run candidate: missing trace, superseded / invalid for identity consistency”。重跑从 `v2` 开始。 3. **每个 slide-agent packet 必须声明写入策略** 例如： `Output version: v2` `Overwrite allowed: no` `If any output file already exists: block and return` `Review allowed: no` 这样你要检查“明确不要 review 是否还生成 review”时，就有可判定的合同。 所以对下一步 `S-21`，我现在不会让它写 `s21-v1-*`。因为 `s21-v1-image.png` 已经是 broad-run 候选，哪怕它不规范，也是一份历史证据。新测试应该是 `s21-v2-*`，任务记录写明：`v1` 是无 reference-lock / no prompt trace 的旧候选，`v2` 是本次 child-session-owned slide-agent 测试产物。 # 3 你这个更合理，不覆盖第一轮的产物。第一轮没有执行完，所以有些目录是空的。 所以对于Task执行，不关心具体版本`vx`，而都是新加，这样才合理。 那么从这里可以看到，这个workflow是有漏洞的，应该先补docs的规则，再调本地的。然后再跑这个s-21 # 4 所以这个说明得按Codex支持的另一种子会话通道，对吧。 第二步测试已完成，但流程结论不是干净通过。 产物层面： - `s14-v2` 和 `s25-v2` 的 prompt / image / return 都已生成。 - 没有生成 `s14-v2-review.md` / `s25-v2-review.md`，review 抑制正确。 - 两个 prompt 都记录了 `gpt-image-2` Advisor / host-native，且使用了可见人物参考图和 style 母版： - S-14：style B，高位观察；side/front 人物裁切参考。 - S-25：style A，按 dust/detail 改写；side/front/body 人物参考。 机制层面有漏洞： - 同一个 child thread `019ef7d2-1a7f-7a90-8c04-0098239dfe0f` 确实继续工作了。 - Child handoff 记录的 worker 是： - `Agent S-14`: `019ef803-95d7-7411-8d3c-c7f2f68a32e7` - `Agent S-25`: `019ef803-e757-7041-8f4a-fc9dfce23bbd` - 但主会话检查到额外重复启动了一个 `Agent S-14`: `019ef803-328a-7e40-a0b0-0333c6b5fc6c`。 - 所以实际不是三镜头三 Agent，而是 `S-21 + S-14 + 重复S-14 + S-25`，共 4 个 worker。S-14 的 return/image source 还指向重复 S-14 的 generated-images 目录，provenance 混杂。 我已把这个缺陷写入 `task-log.md`、`task-plan.md` 和 `slides.md`，避免后面误判为 workflow pass。 你可以看这两个结果图： - [s14-v2-image.png]() - [s25-v2-image.png]() # 5 两个图我看了，都可以接受。 本轮测试工作完全结束。 我整理下： 1. 这次启动的brief子会话，跑了两个做图子会话，工作完成时brief子会话的Context占用高达83%。 1. 要修改项目的Task分配，每个子会话只分配两个镜头人物 2. docs下的workflow暂时继续保留3个，因为这个是通用的 2. 将来启动子会话，要用child session，会在窗口中多出来了用户可以看见的对话，需要记录session id 3. 子会话中启动Agent，要用SubAgent，这个是子会话内部的，用户看不见 4. 质量部分的问题，基本上都修复了，使用advisor出提示词，使用style和人物锚板/切图这些 你看有遗漏没，还需要修复哪些文件，做个整理。 # 6 整理一份交接文档，我还要做流程上的第三次测试，这次测试重点将放在session/subagent机制上。 已整理第三次测试交接文档： [2026-06-24-character-consistency-session-subagent-third-test-handoff.md](C:/Users/wangq/Documents/Codex/video-workbench/handoff/2026-06-24-character-consistency-session-subagent-third-test-handoff.md) 里面重点固定了几件事：第三轮建议用新的 `session-04`；用户可见 child session 只做 brief / orchestration；每个镜头由 child session 内部启动一次性 `SubAgent`；每个 `slide_id + version` 必须只有一个 owning worker；增加 `worker-launch-ledger.md` 来记录启动、目标文件、防覆盖和返回一致性。 我也把第二轮遗留问题写进去了：`s14-v2` 有重复 `Agent S-14`，所以第二轮图片可接受，但机制不能算干净通过。第三轮完成时父会话需要同时查 child handoff、ledger、return、文件数量和线程可见性，不能只信子会话自报。 验证过：新文件可按 UTF-8 读出，关键项 `session-04`、`SubAgent`、`worker-launch-ledger`、防覆盖、Advisor 都已写入。没有启动新测试，也没有提交 git。