293 lines
19 KiB
Markdown
293 lines
19 KiB
Markdown
# 1
|
||
|
||
我们以`在路上`项目为测试案例，进行了6轮测试，从质量把控到编排计划，最后完成了订阅制（通知唤醒）。
|
||
阅读：[2026-06-25-character-consistency-r7-governance-simplification-handoff.md](C:/Users/wangq/Documents/Codex/video-workbench/handoff/2026-06-25-character-consistency-r7-governance-simplification-handoff.md)
|
||
|
||
现在这套流程，已经可以跑出来令人满意的结果，且主会话、子会话和Agent之间的工作也正常。
|
||
|
||
但是作为生产过程使用，还是“治理”过重，大量的Tokens被放在了交接、审计、日志上。
|
||
必须要简化过程性文档，减少审计，才能作为生产流程。
|
||
这不是一个开发项目，不需要那么严谨性；即使生产流程中稍有偏差，导致结果有偏差，我在使用结果时发现有问题，重做即可。
|
||
对于`在路上`这个视频项目，重点是保证生产的内容线，brief、prompt及生图；过程记录，都可以从简。
|
||
|
||
谈谈你的想法，有问题提出。
|
||
|
||
我判断：现在该砍的不是三层结构，而是“证明这三层结构真的工作”的测试期文档。主会话 -> 子会话 -> 单 slide Agent 这条线已经验证过，生产期应该默认信任它，只在异常时退回审计模式。
|
||
|
||
我建议把 R7 定成三个层级：
|
||
|
||
1. **内容线必须保留**
|
||
`brief`、`prompt`、生成图、`slides/slides.md` 状态表。这是生产资产。
|
||
|
||
2. **机制线只保留收据**
|
||
`task-log.md` 一包两行：dispatch 一行、callback 一行。`child-session-handoff.md` 控制在一个短表内：scope、versions、status、image paths、warnings、needs_user。Agent `return` 也从报告降级成 receipt，不写长过程。
|
||
|
||
3. **审计线默认关闭**
|
||
`worker-launch-ledger`、完整文件清单、父会话复核、长时间线、review 文件，都只在 `blocked / failed / warning / 用户要求审计 / 机制改动测试` 时出现。干净完成时，父会话不打开 prompt / return / ledger 细节。
|
||
|
||
我会保留少数硬约束：append-only 版本、禁止覆盖、每个 slide/version 一个 owner、callback target、handoff 先于 callback、completion gate、每张完成图的路径。这些不是治理负担，是防止重做时找不到东西、覆盖掉东西、或者两个 Agent 写同一版本。
|
||
|
||
我倾向的 R7 方案是：**先改生产轻模板，再跑 S-26/S-27/S-28 小包验证**。不建议先直接跑，因为现在模板仍会诱导 Agent 写测试期报告；R7 的目标正是改变默认写法。也不建议引入 JSON/schema/tooling，那会把“轻治理”变成新的治理工程。
|
||
|
||
我有一个关键问题需要先定：
|
||
|
||
**production-light 的默认 review 要不要彻底设为 `none`？**
|
||
|
||
我的推荐是：默认 `review: none`，只做机械 completion gate；视觉质量由你看图后决定，拒绝就 append 下一版。核心身份图、封面级图、或你明确要求 sampling/review 的包，再打开 local review。这样最符合“偏了就重做”的生产逻辑。
|
||
|
||
# 2
|
||
|
||
是的，在生产环节，默认 review 彻底设为 `none`。简化各种handoff，将出图直接改为通过，默认不需要每张图获得用户的review。包括slides，和sessions这些计划状态管理，能简化也可以简化。
|
||
|
||
需要保留两条线：
|
||
1. 测试/审计线
|
||
2. 生产线
|
||
|
||
每次视频，在初期的都会先跑测试/审计线，核心镜头达成了预期后，才进入生产线。我们这次之所以跑7轮测试，更多是在打造环境、流程上。
|
||
|
||
实际上将来的项目，在环境/流程稳定下，应该跑一两轮测试，核心镜头出来，就直接进入正式生产了。
|
||
|
||
同意：**先改生产轻模板，再跑 S-26/S-27/S-28 小包验证**
|
||
|
||
# 3
|
||
|
||
子会话跑3个出图大约需要20~30分钟。
|
||
**我们先讨论，不修改任何文档。**
|
||
|
||
workflow下的文档，现在是两个阶段放在一起。分开放是否更好？
|
||
编排会话（主会话）需要加载两套机制的上下文，分开的话，通过用户引导“现在是审计/测试阶段”或者“现在是正式生产”，再去加载对应阶段的workflow。
|
||
|
||
你觉得呢？
|
||
|
||
我觉得**分开更好**，但不建议分成两套彼此完整的 workflow。更好的结构是：
|
||
|
||
`一个入口/路由文件 + 一个共享底座 + 两个阶段文件`
|
||
|
||
大致是：
|
||
|
||
```text
|
||
docs/workflows/slide-task-orchestration.md # 入口，只负责判断当前阶段和加载哪份
|
||
docs/workflows/slide-task-shared-contract.md # 两条线都必须遵守的底线
|
||
docs/workflows/slide-task-test-audit.md # 测试/审计线
|
||
docs/workflows/slide-task-production-light.md # 正式生产线
|
||
docs/workflows/slide-task-templates.md # 可再拆或按章节区分
|
||
```
|
||
|
||
原因很直接：主会话不应该每次都加载两套机制。正式生产时，它只需要知道“现在是 production-light”，然后加载共享底线 + 生产线规则；测试阶段才加载审计线。这样可以减少 token，也减少 Agent 被审计语言污染的概率。
|
||
|
||
但我不建议把两套机制完全独立复制。因为有些规则必须是共同底线：append-only、不覆盖、单 slide/version 一个 owner、可见参考图、gpt-image-2 Advisor、callback-only、异常才审计。这些如果分别写在两套文档里，迟早会漂移。所以应该抽成 `shared-contract`，两条线都引用它。
|
||
|
||
我会这样定义加载策略：
|
||
|
||
- 用户说“现在是测试/审计阶段”：主会话加载入口 + shared + test/audit。
|
||
- 用户说“现在是正式生产”：主会话加载入口 + shared + production-light。
|
||
- 子会话只加载对应阶段，不加载另一阶段。
|
||
- slide Agent 原则上不加载 workflow 全文，只吃 packet + brief + 必要 shared 摘要。
|
||
- 如果 production-light 出现 blocked/failed/warning，再临时切入 test/audit 进行局部诊断。
|
||
|
||
这里有一个关键点：`slide-task-orchestration.md` 不应该继续承载大量规则，它应该退化成“路由器”。它回答三个问题就够了：当前是什么阶段、必须读哪些文件、什么情况切换阶段。真正的流程细节放到阶段文件里。
|
||
|
||
我倾向的结论是：**分开，而且以 production-light 为默认最短路径；test/audit 是显式进入的诊断路径。** 这样更符合你说的生产现实：先用一两轮把核心镜头和环境跑稳，然后正式生产只追求内容线，不再用审计线拖慢每包出图。
|
||
|
||
我现在唯一的问题是：你希望“阶段选择”主要由用户自然语言触发，还是在每个任务计划里必须有一个明确字段，比如 `Line: production-light` / `Line: test-audit`？
|
||
|
||
# 4
|
||
|
||
**我们先讨论，不修改任何文档。**
|
||
|
||
> 你希望“阶段选择”主要由用户自然语言触发，还是在每个任务计划里必须有一个明确字段，比如 `Line: production-light` / `Line: test-audit`？
|
||
|
||
我是这样理解的：
|
||
1. project.md 应该就记录着项目的阶段，是测试还是正式运行。创建的时候默认是测试；用户正式授权则为正式运行。这样默认加载根据project的实际阶段。
|
||
2. 除非，在正式运行阶段，用户发现局部有问题，需要用测试流程；则授权某个会话为按照测试阶段，这样多加载一套也没大问题。
|
||
|
||
---
|
||
|
||
另外，现在主会话-子会话-Agent的三级目录，是因为会话窗口的限制，如果会话窗口够大，我们都不需要子会话。
|
||
|
||
这个三层机制本身也会造成大量的冗余，主会话对项目理解一次，子会话对具体任务理解一次，Agent还要理解；此外，准备发送的指令这些也都有损耗。
|
||
而且这一套是之前，轮询制下设计的。
|
||
是否可以考虑去掉Agent，直接由子会话生prompt，生图，可以减少大量的中间产物。
|
||
|
||
这个我正在监测子会话的Context用量。
|
||
|
||
---
|
||
|
||
先谈谈你的理解。
|
||
|
||
我的理解是：你现在不是只想“少写文档”，而是在重新定义**生产运行时的最短执行路径**。
|
||
|
||
我同意你对阶段状态的理解：
|
||
|
||
`project.md` 应该记录项目当前默认阶段。新项目默认 `test/audit`，等核心镜头、视觉系统、参考图路线跑通后，由用户明确授权切到 `production-light`。之后主会话默认按项目阶段加载 workflow，不需要每次靠用户重复说明。
|
||
|
||
局部问题则用 override：项目整体仍是 `production-light`，但某个 slide、某个 session、某次 repair 可以临时声明 `test/audit`。这样只有异常局部多加载审计线，不污染整个生产流程。
|
||
|
||
关于去掉 Agent，我也认为值得认真考虑，而且很可能是生产线的正确方向。
|
||
|
||
三级结构最初解决的是几个问题：上下文窗口、单 slide ownership、防重复 worker、可追溯审计、轮询下的状态检查。但现在条件变了：callback-only 已经跑通，production-light 不再需要逐图 review，也不需要证明每个 Agent 的完整生命周期。那 Agent 层的收益下降，成本变得明显：每张图都要重建一次理解、写 packet/return、重复解释 style/character/context。
|
||
|
||
所以我会把“阶段”和“执行拓扑”拆开：
|
||
|
||
```text
|
||
test/audit 默认拓扑：
|
||
主会话 -> 子会话 -> 单 slide Agent
|
||
|
||
production-light 默认拓扑：
|
||
主会话 -> 子会话直接生产
|
||
```
|
||
|
||
正式生产里，子会话可以直接做这几件事：读一次项目上下文，按 scope 顺序处理 2-3 张图，写 brief、prompt、image，更新 `slides/slides.md`，写一个短 handoff，然后 callback。这样可以去掉 packets、returns、worker ledger，甚至多数 session 内部过程文件都可以省掉。
|
||
|
||
但我不会把 Agent 从系统里删除。它应该变成一个**测试/审计工具**或**异常处理工具**：
|
||
|
||
- 核心镜头测试时用 Agent。
|
||
- 出现漂移、覆盖风险、重复版本、工具异常时用 Agent。
|
||
- 特别复杂或身份敏感的单镜头，可以用 Agent 隔离。
|
||
- 如果将来要并行生产，也可能重新启用 Agent。
|
||
|
||
也就是说，Agent 不再是生产默认路径，而是“需要隔离/审计时才启用”。
|
||
|
||
我觉得下一步判断点就是你正在监测的 context 用量。如果一个子会话直接处理 3 张图，context、耗时、质量都可接受，那 production-light 可以改成两层。如果 3 张图后子会话已经接近临界，或者 prompt 质量明显漂移，那就保留三层或限制 direct child 的包大小。
|
||
|
||
我现在的倾向结论：
|
||
|
||
```text
|
||
项目阶段由 project.md 决定。
|
||
production-light 默认只加载生产 workflow。
|
||
production-light 默认两层：主会话 -> 子会话。
|
||
test/audit 默认三层：主会话 -> 子会话 -> Agent。
|
||
Agent 从生产默认机制降级为审计/异常/高风险隔离机制。
|
||
```
|
||
|
||
这样比单纯“少写 handoff”更彻底：它减少的是一次出图链路里的重复理解和重复指令成本。
|
||
|
||
# 5
|
||
|
||
我们的简化版任务测试顺利完成了。图片质量现在都没问题，都通过了。
|
||
|
||
---
|
||
|
||
因为我们这次派发的3张图任务，子会话还是用了智能体来完成，在消减了文档之后，时间和context都比原来减少了。三个任务跑下来25m48s，134ktokens。
|
||
|
||
Agent还说：
|
||
> Return receipt is written. Before I close, I’m running the final verification pass required for completion claims: owned files present, review absent, image readable, and return content recorded.
|
||
|
||
所以这个完整性检查工作，我觉得在子会话里也可以省去。
|
||
现在做了7轮测试，跑了几十个图的情况下，完整性检查变成负担了。
|
||
|
||
---
|
||
|
||
综上，我觉得可以直接调整相应的规则，分阶段，启动Agent的能力保留，但不是默认，默认为子会话自己做完，去掉完整性检查等等。
|
||
这些之后，我们再做一组测试：发新的三个镜头包，到新的子会话，需要记录子会话id。
|
||
这个，我可以看到没有Agent的情况下的真实时间与Tokens用量。
|
||
然后判断，是否可以续发镜头。
|
||
|
||
你觉得呢。
|
||
|
||
我同意你的判断，方向可以再压一层。
|
||
|
||
这次 R7 已经证明两件事：文档消减后，三图包能稳定跑完；但即便消减，`子会话 -> Agent` 这一层仍然带来显著重复理解和收据成本。25m48s / 134k tokens 对三张图来说已经比以前好，但还不是 production-light 的极限。
|
||
|
||
我建议下一版规则这样定：
|
||
|
||
`production-light` 默认拓扑改成：
|
||
|
||
```text
|
||
主会话 -> 子会话直接生产
|
||
```
|
||
|
||
子会话自己负责一个小包，比如 3 张图：读项目阶段、读必要 visual-system、扫描版本、写 brief/prompt、生成图、更新 `slides.md`、写一个极短 handoff、callback。默认不启动 Agent，不写 packet，不写 return receipt，不跑 final verification pass。
|
||
|
||
保留的最低安全动作只剩三项：
|
||
|
||
1. 写前扫描版本，避免覆盖。
|
||
2. 每张图生成后能拿到项目内 image path。
|
||
3. callback 里报：scope、versions、image paths、blocked/needs_user。
|
||
|
||
其它都默认省掉：完整性检查、worker lifecycle、return receipt、ledger、review、hash、父侧审计。生产里缺了文件或图片打不开，后面使用时自然会暴露，重做即可。
|
||
|
||
`test/audit` 则保留现在较完整的三层机制：
|
||
|
||
```text
|
||
主会话 -> 子会话 -> Agent
|
||
```
|
||
|
||
它用于核心镜头测试、流程故障、身份漂移、局部重做诊断、或者用户显式要求审计。Agent 能力不删，只从默认生产路径里拿掉。
|
||
|
||
下一组测试我也同意：新建一个干净子会话，发新的三个镜头包，明确要求“不启动 Agent，由子会话直接完成”。主会话只记录子会话 ID、scope、开始时间；等 callback 后记录耗时、tokens、版本和图片路径。然后你用真实数据判断是否继续给同一个子会话续发。
|
||
|
||
我唯一保留的底线是：**不要把写前版本扫描也删掉**。这是很低成本的防覆盖动作，和治理不是一类东西。除此之外，production-light 可以大胆减。
|
||
|
||
# 6
|
||
|
||
同意：**不要把写前版本扫描也删掉**
|
||
|
||
你现在发一组新的包给新子线程吧。
|
||
|
||
# 7
|
||
这次我看到了子会话的工作过程，是先出每个图的brief和prompt，然后再一个个生图。这是一个更合理的过程，因为图是连续的，这样对“剧情”的理解更通透。这3个图也都通过。
|
||
|
||
速度明显提升，现在3个图总共10m32s（之前1个都在10m左右），Tokens总共114k。
|
||
这个方向没任何问题。
|
||
|
||
我们的第二组测试也完毕了，这个完全可以作为正式的生产来用。
|
||
|
||
补充一下，发起子会话，主会话是有命名能力的，以后都是“子会话：xxxx”，这样我在界面上看到的，可以直接区分。
|
||
|
||
现在可以进行文档/规则的修复了。
|
||
|
||
已完成文档/规则修复，当前生产线已经落成默认规则：`project.md` 记录项目阶段；`在路上` 已切到 `production-light`；正式生产默认是命名子会话 `子会话：...`，子会话直接完成 brief、prompt、生图、`slides.md` 更新和 compact handoff；默认 `review: none`；默认不启用 Agent/SubAgent；默认不写 packet/return；默认不跑最终完整性审计。写前版本扫描、append-only、禁止覆盖仍保留。
|
||
|
||
主要改动落在：
|
||
- [AGENTS.md](C:/Users/wangq/Documents/Codex/video-workbench/AGENTS.md)
|
||
- [VIDEO_WORKBENCH.md](C:/Users/wangq/Documents/Codex/video-workbench/VIDEO_WORKBENCH.md)
|
||
- [slide-task-orchestration.md](C:/Users/wangq/Documents/Codex/video-workbench/docs/workflows/slide-task-orchestration.md)
|
||
- [slide-task-templates.md](C:/Users/wangq/Documents/Codex/video-workbench/docs/workflows/slide-task-templates.md)
|
||
- [project.md](C:/Users/wangq/Documents/Codex/video-workbench/projects/2026-06-23-在路上/project.md)
|
||
- [execution-plan.md](C:/Users/wangq/Documents/Codex/video-workbench/projects/2026-06-23-在路上/execution-plan.md)
|
||
- [slides.md](C:/Users/wangq/Documents/Codex/video-workbench/projects/2026-06-23-在路上/slides/slides.md)
|
||
- [task-plan.md](C:/Users/wangq/Documents/Codex/video-workbench/projects/2026-06-23-在路上/tasks/2026-06-24-character-consistency/task-plan.md)
|
||
- [task-log.md](C:/Users/wangq/Documents/Codex/video-workbench/projects/2026-06-23-在路上/tasks/2026-06-24-character-consistency/task-log.md)
|
||
|
||
也记录了两组测试结论：`session-12` 的 25m48s / 134K tokens，以及 `session-13` 直连子会话无 Agent 的 10m32s / 114K tokens，并把后者设为正式生产默认。
|
||
|
||
验证做了两项：`git diff --check` 没有空白错误，只有 Git 的 CRLF 归一化提示；针对 production-light 相关旧词做了搜索，剩余的 `completion gate` / `return receipt` 都在历史记录、测试/审计语境，或“生产线不要做”的规则里。工作区还保留 session-12/session-13 生成的未跟踪 brief/prompt/image/handoff 产物，我没有回退或整理这些子会话输出。
|
||
|
||
# 8
|
||
|
||
因为context超限，`上下文已自动压缩`。
|
||
|
||
这是我们这个会话，我记录的交流历史`C:\Users\wangq\Documents\Codex\knowledge-vault\discussions\creative\在路上\在路上-video7-测试流程运行7.md`，每一个大标题“#”代表一个新回合。
|
||
|
||
这次的改动大，看看是否需要再检查一遍，若缺信息可以问我要。
|
||
|
||
---
|
||
|
||
准备一个交接文档，我下个新会话，会做一些清理和讨论工作：
|
||
关闭测试，进入正式运行。
|
||
正式运行，我可能会直接进入交流，要求生图。
|
||
这个时候，主会话应该加载哪些，加载顺序是什么，我们的工作范围（镜头范围）如何界定。
|
||
|
||
交接文档之后，我会对全体做一次提交。
|
||
|
||
已准备好新的正式生产交接文档：
|
||
|
||
[2026-06-25-on-the-road-formal-production-handoff.md](C:/Users/wangq/Documents/Codex/video-workbench/handoff/2026-06-25-on-the-road-formal-production-handoff.md)
|
||
|
||
我也把它加入了 [project.md](C:/Users/wangq/Documents/Codex/video-workbench/projects/2026-06-23-在路上/project.md) 的 `Next Action` 入口，避免新会话继续沿用 R6/R7 测试 handoff。
|
||
|
||
这份 handoff 重点写清了：
|
||
|
||
- 新会话加载顺序：讨论/清理模式、可能生图模式、实际镜头范围模式分开加载。
|
||
- 正式运行默认：`production-light`、命名子会话 `子会话：...`、直连子会话、无 Agent、无 review、无 packet/return、无最终完整性审计。
|
||
- 用户直接说“生图”时的处理方式。
|
||
- 当前默认下一组范围：`S-32/S-34/S-35`，并说明 `S-32/S-34` 只能 append-only 出新版本，不能复用 broad-run v1 作为正式结果，除非你明确接受。
|
||
- 镜头范围界定规则：accepted / production-pass 默认关闭；generated 未接受、broad-run 候选、not started、rejected、incomplete 默认开放。
|
||
- 清理议题：旧 `slides.md` 中部分 `generated` 状态和用户接受记录不完全一致，下一会话可以先规范这些状态。
|
||
|
||
我复核了你记录的讨论文件末尾几轮，没有发现需要额外向你确认的信息。`git diff --check` 没有空白错误，只出现 Git 的 CRLF 归一化提示。工作区仍有 session-12/session-13 的未跟踪产物，这些是子会话生成的 brief/prompt/image/handoff，我没有改动或清理它们。
|
||
|
||
|
||
|