knowledge-vault/discussions/creative/在路上/在路上-video7-测试流程运行2.md

1

阅读交接文档：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。

理由：这次要验证的是三层编排：

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/<task-id>/ 是 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

里面重点固定了几件事：第三轮建议用新的 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。