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

1

阅读交接文档：R6 Notification/Wakeup And S-16 Repair Handoff。

阅读调研报告：test-1-report.md

---

本次计划做第6轮测试，主要目标是将主会话轮询制改为唤醒制的尝试。 首先忽略workflow中的轮询等待心跳这些，而是按照我下面的实验步骤。

s16之前质量有问题，本次R6 测试计划分为两个阶段。 第一阶段测试：

1. 准备好s16的资料。取得主会话（当前会话）的id，生成子会话，取得子会话id；发送s16的重做指令，包括：
   1. 未达成镜头清单骨架中所描述的“横向大远景，路从画面一侧切向远方，人物极小”，与s15太接近，
   2. 子会话重新整理brief和对agent的要求
   3. 主会话id
   4. 做完后回调主会话
2. 预期主会话被激活，做相关的后续处理。我在你做完后检查s16的效果。

第二阶段测试：

1. 准备后续未完成的4个镜头资料（不包括s16，不论s16是否通过）发给新子会话，然后等待子会话回调。
2. 子会话回调后，做后处理。然后等我确认图片质量。

若主会话未被正常激活，我可以看到子会话的进度，我会介入。

谈谈你的思路，有问题提出。先对齐思路。

读完了。最新交接文档就是：

2026-06-24-character-consistency-r6-notification-s16-handoff.md

关键影响：

• R6 的正式入口是 S-16 append-only 重做，建议路径 session-09/，预期版本 s16-v3，但执行前必须扫描确认。
• 主变量是 notification/wakeup，不能用隐藏轮询冒充。
• 子会话必须先写 handoff、过 completion gate，再 send_message_to_thread(parent_thread_id) 回调主会话。
• S-16 必须明确修正：横向大远景、路从画面一侧切向远方、人物极小、明显区别于 S-15。
• prompt 仍必须走 gpt-image-2 Skill Advisor / host-native 流程，并记录 mode、模板/参考路径、实际读取源文件。
• review 默认关闭，不写 s16-v3-review.md。

和你刚才的新两阶段计划相比，唯一需要标记的是：交接文档的 Non-Goals 写了“不拓展到更多 slides，除非用户明确改变 R6 scope”。你刚才已经明确提出第二阶段 4 个镜头，所以我会把第二阶段当作本轮新授权扩展，不是交接文档原始范围。第一阶段仍严格按交接文档跑 S-16。

2

是的，第一阶段是原始计划，只是证明可以实现；第二阶段是扩展计划，证明将来正式运行是否可行。

若没有其他问题，可以开始执行第一阶段了，我可以保证，当前只有你的会话在活动。

3

s16图片通过。现在进入第二阶段测试。

第二阶段已启动并派发，主会话现在停止轮询。

• Phase 2 child thread: 019ef9d0-4914-7ea0-8935-bfd9bfc1aad4
• Session path: projects/2026-06-23-在路上/tasks/2026-06-24-character-consistency/session-10/
• Scope: S-19, S-20, S-22, S-23
• Expected versions if unchanged: s19-v2, s20-v2, s22-v2, s23-v2
• Callback target: current parent thread 019ef9b5-cc39-7a42-91b1-f9b0852dc95e

我也已把 s16-v3 用户通过和 Phase 2 派发状态写入父会话记录。现在等待子会话完成后回调；我不会主动读取或轮询子会话线程。

4

我暂停了子会话，原因是s20的agent卡了40分钟，这个agent试图调用mcp服务minimax去理解图片，多次失败后应该被安全审计杀掉了。 我现在关闭了这个mcp服务。

所以s19图片通过，不用重做了。

我们重新做第二阶段，选择后续新的4个包，发给新的子会话测试。

5

S-20, S-22, S-23, S-24 4个图已经通过。

6

因为本会话经过了信息压缩，我回顾一下我们做了什么： 第一阶段测试：

1. 准备好s16的资料。取得主会话（当前会话）的id，生成子会话，取得子会话id；发送s16的重做指令，包括：
   1. 未达成镜头清单骨架中所描述的“横向大远景，路从画面一侧切向远方，人物极小”，与s15太接近，
   2. 子会话重新整理brief和对agent的要求
   3. 主会话id
   4. 做完后回调主会话
2. 预期主会话被激活，做相关的后续处理。我在你做完后检查s16的效果。

这个测试顺利完成。

第二阶段测试：

1. 准备后续未完成的4个镜头资料（不包括s16，不论s16是否通过）发给新子会话，然后等待子会话回调。
2. 子会话回调后，做后处理。然后等我确认图片质量。

测试失败，S-19, S-20, S-22, S-23 四个镜头，只做了s19。原因是s20的agent卡了40分钟，这个agent试图调用mcp服务minimax去理解图片，多次失败后应该被安全审计杀掉了

第三阶段测试：

1. 继续准备4个镜头发给新子会话，等待回调
2. 子会话回调后，做后处理。

测试完成，S-20, S-22, S-23, S-24四个镜头图片通过，回调顺利。

---

基于以上，你看看有没有你遗漏的。 下一步，我们将修改workflow的规则，从轮询制改为订阅制（通知唤醒） 你判断下，需要修改哪些内容。

你的复盘基本完整。我补充 3 个容易遗漏的点：

1. 第一阶段不只是回调成功，还验证了“回调后父会话只读本地 handoff/文件证据做后处理”，没有恢复广泛轮询。
2. 第二阶段失败要记录为两件事：s19-v2 已通过；s20-v2/s22-v2/s23-v2 是不完整历史证据，不能补写或原地续做。
3. 第三阶段成功的关键差异是 session-11 把 MiniMax/MCP/外部图像理解写成了 worker stop condition，而不是只靠“默认不调用”的软规则。

我建议按“订阅制默认，轮询降级为显式例外”修改，范围如下：

1. AGENTS.md
   把 Production orchestration defaults 里的 sleep/poll 规则替换成 callback-only：父会话发送任务后停止等待；子会话完成 gate 后写 handoff，再用 send_message_to_thread 回调父会话。原 wait schedule 改成 legacy/fallback，仅在用户明确要求或回调机制不可用时使用。

2. slide-task-orchestration.md
   这是主 workflow 规则，必须改。新增“Notification / Wakeup Contract”：父线程 id、callback required、handoff-before-callback、callback payload、父会话只在回调后读 handoff。保留 child capacity 规则，但不再把等待/轮询作为生产默认。

3. slide-task-templates.md
   模板要补字段，否则后续子会话会漏协议。
   Child Session Plan 增加 Parent Callback Contract。
   Child Session Handoff 增加 Callback Status。
   callback payload 固定为：status、completion gate、resolved versions、handoff path、image paths、problems/decisions needed。

4. slide-task-templates.md
   Slide Agent Packet 的 stop/completion 规则要硬化：禁止 MiniMax MCP、external image understanding、external review、web search、CCPE、GPT V2，除非任务显式授权。第二阶段失败说明这不能只写在 review rule 里。

5. VIDEO_WORKBENCH.md
   更新高层角色描述：main session 不再“等待并读取 handoff”，而是“发送任务、记录回调目标、被唤醒后读取 handoff”。同时把 external vision 禁令从 review 场景扩展到“图像理解/生成辅助/审查”全链路。

我不建议改当前项目状态文件作为 workflow 规则来源；task-log.md/project.md/execution-plan.md/slides.md 已经记录 R6 结果，适合作为证据，不适合作为默认协议入口。

推荐方案是：callback-only 成为生产默认；manual/user intervention 是回调丢失时的异常路径；自动轮询不再是默认兜底。 这样最贴合这次 R6 的实验目标，也避免“订阅制”名义下又保留一套隐形轮询。

请确认是否按这个方案改，我收到确认后开始修改这些规则文件。

7

slide-task-templates.md
Slide Agent Packet 的 stop/completion 规则硬化 这一条不同意，我将MiniMax MCP已经关掉了，不影响后续；在后续实际应用中，还是有可能会用到其他的。 不用增加硬化规则。

其他没有问题，按这个修订。

8

接下来我还会做R7的试运行。 主因是，现在的这套机制运行起来已经没有问题，但是“治理”过重，有大量的日志、审计、交接。 作为我参与的测试、试运行，这个没问题，需要回溯问题的能力，但是作为正式运行，有大量的tokens被用在了生产之外。

下一轮，主要目标是为这个正式运行，做治理的简化。

你写一份交接文档。之后，我会手动提交所有的文档。在新会化里开启R7。

已写好 R7 交接文档：

2026-06-25-character-consistency-r7-governance-simplification-handoff.md

内容重点：

• R6 三阶段结果和当前状态。
• callback-only 已经证明可用，不再默认轮询。
• R7 目标是建立 production-light mode，减少正式生产中的日志、审计、长交接和父会话复核。
• 明确保留你的意见：不增加 MiniMax MCP / 外部视觉工具的全局硬禁用规则。
• 建议 R7 新会话先确认：先改 docs 再跑，还是先跑一个小包再从结果修订 docs。
• 默认建议试运行范围写成 S-26/S-27/S-28，4 镜头压力选项是 S-26/S-27/S-28/S-29，但要求新会话不能静默选择，必须先与你确认。

校验：交接中引用的核心文件都存在；关键词检查覆盖了 R7、callback、polling fallback、production-light、MiniMax 边界和候选镜头范围。lifecycle-status-guard-scan 的脚本因当前可见 Python 缺 yaml 且 shell 里没有 conda 未能运行，我改做了手动状态词检索。新 handoff 当前是未跟踪文件，未 staging、未 commit。