176 lines
11 KiB
Markdown
176 lines
11 KiB
Markdown
# 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/<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](<C:\Users\wangq\Documents\Codex\video-workbench\projects\2026-06-23-在路上\slides\s14\s14-v2-image.png>)
|
||
- [s25-v2-image.png](<C:\Users\wangq\Documents\Codex\video-workbench\projects\2026-06-23-在路上\slides\s25\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。
|
||
|
||
|