# 1

阅读：
- 主交接：[2026-06-24-on-the-road-workflow-continuation-handoff.md](C:/Users/wangq/Documents/Codex/video-workbench/handoff/2026-06-24-on-the-road-workflow-continuation-handoff.md)
- 新会话索引：[review-context.md](C:/Users/wangq/Documents/Codex/video-workbench/handoff/2026-06-24-on-the-road-workflow-continuation-context/review-context.md)
- 文件清单：[review-file-manifest.json](C:/Users/wangq/Documents/Codex/video-workbench/handoff/2026-06-24-on-the-road-workflow-continuation-context/review-file-manifest.json)

---

目前人物一致性调研已经完成，下一步我计划是修复流程。

GPT在阶段五会输出`镜头清单骨架`，及`核心镜头骨架`，由于前面跑的时候出错，我让它又出了做人物一致性检查的一组单镜。
人物一致性检查的单镜尚未展开；核心单镜已经全部展开并验证。

`video-workbench`收到intake的资料后，流程应该是：
1. `visual-system`下的细化和成果，主要是场景锚板和场景提示词母版；有人物时，去做人物锚板和不同体位的裁切图。
2. 核心单镜展开的试运行
3. 其他单镜展开的试运行
4. 其余单镜的运行

---

本次流程优化，集中在单镜展开的过程。

1. 有单镜骨架的，应该怎么展开，现在的brief、prompt、review是否够用，是否冗余
2. 没单镜骨架的，应该怎么展开，是否在brief、prompt、review基础上补充什么，还是填充brief文档。

即，我们需要一个什么样的文档目录，文档里应该有什么结构，没有单镜骨架（GPT给的）我们应该补什么。

---

此外review阶段经常会调用MCP服务-Minimax，而导致权限不足的失败。后续review默认都用本地能力，不用mcp。

首先，需要你谈谈你的理解，有什么问题？


我的理解是：这次不是继续生图，也不是重做参考图能力验证，而是修复 `slides/sNN/` 的单镜生产单元。

现在的问题核心是旧广跑把流程压得太薄了：有 `sNN-v1-image.png`，但缺少每镜自己的 `brief` 和 `prompt`，导致失败后追不回“这个镜头怎么理解、用了哪些参考、prompt 怎么渲染、是否真的加载了人物图”。所以修复方向应该是：

- `brief`：把 GPT 镜头骨架或 `slides.md` 行信息，转换成本地执行卡。它负责镜头功能、风险等级、人物可见度、参考选择、验收点。  
- `prompt`：必须保留，且是生成前的正式凭证。它负责 `gpt-image-2` 工作流、来源文件、Reference Inputs、最终 rendered prompt、生成路径说明。  
- `review`：不应每镜默认写长报告。核心试跑、人物一致性、失败修复、用户接受节点才写；普通批量镜头可以批量审查 + 表格状态更新。  
- 没有 GPT 单镜展开的镜头，不应重新做一份长篇“导演阐释”。更轻的做法是在 `brief` 里补足执行所需字段：镜头功能、风险分类、风格模块、人物/道具参考、首读顺序、禁区、验收标准。

我认为目录上先保持现有 `slides/sNN/` 模型，不急着加复杂层级：

```text
slides/sNN/
  sNN-v1-brief.md
  sNN-v1-prompt.md
  sNN-v1-image.png
  sNN-v1-review.md   # 只在核心、修复、争议、验收时需要
```

另一个明确修复点：review 默认必须本地化。后续不要默认调用 Minimax MCP 做图片理解；普通 review 用本地文件元数据、人工/本地视觉检查、项目验收表。若以后要自动视觉评估，应另开“本地能力或供应请求”，不能让 MCP 权限失败成为常规流程的一部分。

我现在唯一需要先确认的问题是：没有 GPT 单镜展开的镜头，你倾向于 **只补 `sNN-v1-brief.md`**，还是希望另外创建一个稳定的 `sNN-unit-spec.md`？我的建议是先只补 `brief`，测试通过后再决定是否需要 `unit-spec`。

# 2

同意：先只补 `brief`，测试通过后再决定是否需要 `unit-spec`。
而`brief`的结构，我建议你至少读核心镜头中，一两个镜头的骨架，和对应的brief。
然后再判断brief应该有什么，而且这个结构，应该不考虑镜头骨架是否有，是一个通用的结构。

因为风险点，在核心单镜部分已经验证了。
而其他单镜展开的试运行，比如本次人物一致性，是因为第一次跑项目，不熟悉而已。将来这个在新项目里就不存在；新项目也可能产生另外的`其他单镜展开`。

---

而prompt.md我认为可以认为是brief的一个来附件考虑：
1. 可以直接作为提示词运行，或者附着一些少量的操作描述，而不是内容/业务描述
2. 我可以拿着这个，在其他平台上做交叉验证。

现在的prompt有太多不是prompt，而是规则，项目的内容。

这个也需要你读一两份prompt才能判断。


同意，而且我已经读过对应材料：`S-10 / S-46 / S-51` 的 GPT 核心骨架、对应 `brief`，以及 `S-10 / S-46 / S-47 / S-51` 的 `prompt`。

我的判断是：

`brief` 应该是通用“单镜执行卡”，不区分有没有 GPT 单镜骨架。有没有骨架只影响信息来源深度，不影响文档结构。它应该固定回答：

1. 这个镜头在片子里的功能是什么
2. 第一眼应该读到什么
3. 人物是否出现、出现到什么程度
4. 使用哪个风格模块
5. 使用哪些人物/风格参考，为什么
6. 构图、尺度、光色、禁区是什么
7. 本镜的风险等级和验收点是什么

现有 `brief` 方向是对的，但可以更收紧：不要再重复太多 GPT 骨架里的长段阐释，只保留执行判断。比如 [s46-v1-brief.md](C:/Users/wangq/Documents/Codex/video-workbench/projects/2026-06-23-在路上/slides/s46/s46-v1-brief.md) 已经比原始骨架更接近执行卡，但还可以进一步模板化。

`prompt.md` 我同意应视为 `brief` 的附件，不是另一个项目说明书。现在的 [s46-v1-prompt.md](C:/Users/wangq/Documents/Codex/video-workbench/projects/2026-06-23-在路上/slides/s46/s46-v1-prompt.md) 和 [s51-v1-prompt.md](C:/Users/wangq/Documents/Codex/video-workbench/projects/2026-06-23-在路上/slides/s51/s51-v1-prompt.md) 里面有很多状态、来源、Skill 文件、规则解释，这些更适合留在 `brief`、批次记录或运行日志里。`prompt.md` 应该更像：

- 简短元信息：shot、version、brief 路径、输出路径
- Reference Inputs：实际要挂载/引用的图片及角色
- Operation Notes：少量运行说明，比如是否要加载 `Image 1`
- Final Prompt：可复制到其他平台直接跑的完整提示词
- Negative Prompt / Avoid：可复制的禁区
- Output Intent：目标文件名或交叉验证说明

关键变化是：`prompt.md` 只保留“生成时需要带走的东西”，不承担“解释这个项目为什么这样做”。

我接下来的一个问题是：`brief` 里是否要保留“Source Files Actually Used”这类来源清单？我的建议是保留，但压缩成一小节，列关键源即可；详细溯源放到批次运行日志或 review/context 包里。

# 3

再补充一个关键信息。
再运行过程，生成brief、prompt、review（按需），生图时，会耗费大量Context，导致经常的上下文压缩。

在试运行阶段还好一些，我可以控制开启新会话。但是在连续执行阶段，有问题。

1. 可不可以考虑把生成放到Agent里。这样可以省下主会话的Context，以免信息压缩后的信息丢失。
   所以，这个变成了：构造Agent，传递哪些上下文，它的工作安排，返回少量的状态信息/交接。

2. 即使主会话窗口快满了，亦可以启动子会话，来承接后续的镜头加工，让子会话继续调用Agent实现。

这个算是任务编排的事情。


是的，这已经是任务编排问题，而且我觉得它应该成为流程设计里的核心层，不是后补优化。

我会把它拆成三层：

1. 主会话只做调度和判断  
   维护项目状态、选择批次、决定哪些镜头要跑、检查返回结果、写少量控制文件。主会话不长时间承载每个镜头的完整生成上下文。

2. 子 Agent 做单镜加工  
   每次接收一个很小的 invocation packet：项目规则摘要、`brief` 模板、相关 `slides.md` 行、必要的视觉系统摘要、引用文件路径、输出路径、禁止事项。它生成或更新 `brief`、`prompt`，按授权生图，按需写 `review`，然后返回短状态。

3. 文件系统承接连续性  
   子 Agent 的返回不靠聊天记忆，而靠落盘文件：`sNN-v1-brief.md`、`sNN-v1-prompt.md`、`sNN-v1-image.png`、按需 `sNN-v1-review.md`，以及一个批次级 `run-log / handoff`。主会话被压缩也不影响继续。

我建议后续流程里明确一个 `shot-worker invocation packet`，里面只传“够执行”的上下文，而不是把整个项目文档塞给 Agent。这样可以避免每个镜头都重复消耗主上下文，也避免子 Agent 自由发挥。

关键点：这不应该走形式化 CCPE 角色扮演，除非你要正式 CCPE 参与者输出。这里更像本地执行 worker：真实子会话/Agent 承载，产物落盘，主会话只验收和调度。

我需要先确认一个编排边界：你希望这个 Agent 默认一次处理 **一个镜头**，还是一次处理 **一个小批次，比如 3-5 个同类镜头**？我的建议是默认一个镜头；等模板稳定后，再允许低风险环境镜头批处理。

# 4

是的，这不是CCPE的事，是我们本地。CCPE只做通用的专家智能体。
我们这套流程，显然别的项目是不适用的。得我们自己打造。

Agent默认一次处理 **一个镜头**，而且后续我也不希望它做批次。宁肯系统开销大些，也避免会话污染，职责不清晰。

批次，是在会话/子会话级别进行维护的。比如：
* 会话编排管理，计划共几次会话，每个会话做哪些镜头，然后启动会话1
* 会话1，启动了5次Agent，分别完成了5个镜头的工作。然后自行启动会话2：
* 会话2，启动了4次Agent，分别完成了4个
* ……

我理解的会话编排就是主会话，可以完全“不干事”，只是发起子会话；子会话调度Agent，Agent干具体事。

比如以`人物一致性检查的单镜`为例，编排会话（主会话）决定启动两个子会话：
* 子会话1，调度Agent完成前三个
* 子会话2，调度Agent完成后两个

这里，子会话现在完全做成顺序的，不要并行。这样：
* 一系统开销（线程）可控
* 过程可控
* 质量/结果可控

对于我这样的构想，你的建议？

# 5

你的构想是对的，我建议保留这三级，不要压扁：

1. **编排主会话**
   只负责“怎么拆会话、先后顺序、当前批次边界、启动哪个子会话”。它不写单镜 `brief/prompt`，也不生图。主会话接近项目经理/调度器。

2. **执行子会话**
   每个子会话负责一个小范围，例如人物一致性测试里的 `s05/s21/s14`。它顺序启动 3 次单镜 Agent，检查每次产物是否落盘，然后写交接给下一个子会话。子会话是“批次维护者”，但不亲自做镜头内容。

3. **单镜 Agent**
   一次只处理一个镜头。输入固定 packet，输出固定文件和短状态。它不理解全项目，只理解“这个镜头该怎么从现有文件生成 `brief`、`prompt`、按授权生图、按需 review”。

我强烈支持“不并行、不批处理”的限制。这里省线程不是第一目标，避免污染才是。单镜 Agent 的上下文一旦混入多个镜头，很容易把人物参考、风格模块、验收点互相串味，尤其是 S14/S25/S33 这种近脸镜头。

我建议把这个固化成一个本地编排协议，而不是 CCPE：

```text
main orchestration session
  -> child session 01
      -> shot worker s05
      -> shot worker s21
      -> shot worker s14
      -> write child-session handoff
  -> child session 02
      -> shot worker s25
      -> shot worker s33
      -> write child-session handoff
```

每个单镜 Agent 的输入 packet 应该很小：

```text
- workspace rules summary
- project id
- target shot id
- source row from slides.md
- optional GPT single-shot skeleton path
- required brief template
- style master path
- character registry path
- output paths
- allowed actions: brief only / prompt only / generate / review
- local-only review rule: no Minimax MCP
```

每个 Agent 的返回也要短：

```text
shot: s05
status: brief_created | prompt_created | image_generated | review_needed | blocked
files_written:
  - ...
needs_user_decision: ...
handoff_note: ...
```

我建议下一步设计时，把重点放在两个协议文件：`child-session-plan` 和 `shot-agent-packet`。前者解决“一个子会话做哪几个镜头、怎么顺序推进”；后者解决“一个 Agent 到底拿什么、产出什么、不能做什么”。

# 6

我同意重点放在两个协议文件：`child-session-plan` 和 `shot-agent-packet`

但是这个packet 应该很小，我不确定。
主要就是，谁来生成brief，这个需要较完整的/较多的项目上下文，才能写出有用的。
brief交给子会话，那么Agent就可以小；brief交给Agent写，它也需要足够的上下文。

我的建议是：**brief 交给子会话写，Agent 不写 brief，至少第一版这样。**

原因很直接：`brief` 是“理解项目后做执行判断”，不是机械填表。它需要看：

- `visual-system.md`
- `style-prompt-master.md`
- `character-reference-registry.md`
- `slides.md` 当前行
- GPT 单镜骨架或镜头清单骨架
- 已接受核心镜头的做法
- 当前阶段目标，比如人物一致性测试

这类上下文如果塞进每个单镜 Agent，packet 就不小了，而且每个 Agent 都会重复解释项目，判断口径容易漂。

所以我建议分成：

```text
child session:
  读取较完整上下文
  为每个镜头生成/修订 brief
  启动 shot agent

shot agent:
  只读 brief + 必要规则摘要
  生成 prompt
  按授权生图
  按需写 review
  返回短状态
```

这样 `brief` 是子会话的“项目理解产物”，`prompt` 是 Agent 的“执行附件”。这也符合你刚才说的：`prompt.md` 不应该装太多项目内容。

`shot-agent-packet` 就可以小很多：

```text
- target shot id
- brief path
- style master path
- character registry path
- output prompt/image/review paths
- allowed actions
- generation/reference rule
- local-only review rule
```

子会话的 packet 可以大一点，叫 `child-session-plan` 或 `child-session-context`，因为它的职责就是维护本轮几个镜头的上下文一致性。上下文压力转移到子会话是可以接受的；关键是它一次只管 2-5 个镜头，并且顺序启动单镜 Agent。

我会避免让 Agent 同时承担“理解项目”和“执行生成”。那会把 worker 变成小主会话，边界又糊了。

# 7

我同意你的判断，这样子会话是否能承接5个镜头，而不爆上下文窗口，我们得测试了。
所以，先按子会话每次承接3个镜头，这样公共信息可以复用2次。

另外，将来我只会与主会话交流。以免产生干扰。

---

基于以上，我觉得你可以先出一个计划。
核心原则是：
* 我们这个不是开发项目，在保证质量的情况下，避免过度治理，只记录最小审计/日志。
* 我/专家有生物限制，不能参与到所有的检查，非核心不要让我参与检查，太费力了。

计划中要规定目录、文件，文档结构。

然后再基于这个Plan调整。

下面是计划草案，不落盘，先用于对齐。

**推荐方案**
我建议采用：**主会话编排 → 子会话写 brief 并调度 → 单镜 Agent 写 prompt / 生图 / 按需 review**。

不建议让 Agent 写 brief。`brief` 需要项目理解，应该由子会话承接公共上下文后生成。Agent 只处理一个镜头，拿 `brief` 当输入，避免每次重复读全项目，也避免把多个镜头混在一个 worker 里。

**目录结构**
新增项目本地运行目录，不放到根 `handoff/`，也不放 `investigations/`：

```text
projects/<project-id>/
  runs/
    <run-id>/
      run-plan.md
      run-log.md
      session-01/
        child-session-plan.md
        child-session-handoff.md
        packets/
          s05-v1-shot-agent-packet.md
        returns/
          s05-v1-shot-agent-return.md
      session-02/
        ...
  slides/
    s05/
      s05-v1-brief.md
      s05-v1-prompt.md
      s05-v1-image.png
      s05-v1-review.md   # 按需
```

`runs/` 只记录最小编排证据；真正单镜产物仍放 `slides/sNN/`。

**主会话职责**
主会话只和你交流，不做单镜内容生产。

主会话负责：

- 维护总计划：哪些镜头、拆成几个子会话、每个子会话最多 3 镜。
- 写或更新 `run-plan.md`。
- 顺序启动子会话，不并行。
- 读子会话 `child-session-handoff.md`，决定是否继续下一子会话。
- 只在核心问题、阻塞、质量失控、规则变更时找你确认。

**子会话职责**
子会话是小批次维护者，但不并行，不跨批次。

每个子会话负责最多 3 个镜头，例如人物一致性试运行：

```text
session-01: s05 -> s21 -> s14
session-02: s25 -> s33
```

子会话负责：

- 读取较完整公共上下文。
- 为每个镜头写 `sNN-v1-brief.md`。
- 为每个镜头生成一个小 packet。
- 顺序启动单镜 Agent。
- 检查 Agent 返回和落盘文件。
- 写 `child-session-handoff.md`，只给下一会话和主会话必要状态。

**单镜 Agent 职责**
Agent 一次只处理一个镜头。

Agent 输入：

```text
- target shot id
- brief path
- style master path
- character registry path
- prompt/image/review output paths
- reference image roles if generation is allowed
- allowed actions
- local-only review rule
```

Agent 输出：

```text
- sNN-v1-prompt.md
- sNN-v1-image.png, if generation authorized
- sNN-v1-review.md, only when required
- short return file
```

Agent 不写 `brief`，不处理第二个镜头，不做批次判断。

**brief 结构**
`brief` 是通用单镜执行卡，不区分有没有 GPT 单镜骨架。

建议结构：

```text
# S-NN Shot Brief V1

## Status
## Source Basis
## Shot Function
## First Read
## Risk Class
## Reference Plan
## Visual Requirements
## Character Handling
## Composition / Scale
## Light / Color / Texture
## Forbidden Drift
## Acceptance Checklist
## Prompt Handoff
```

`Source Basis` 保留简短来源即可，不做长审计。详细上下文在 `run-log.md` 或交接包里。

**prompt 结构**
`prompt.md` 是 `brief` 的附件，应可复制到其他平台交叉验证。

建议结构：

```text
# S-NN Shot Prompt V1

## Status
## Based On Brief
## Reference Inputs
## Operation Notes
## Final Prompt
## Negative / Avoid
## Output Intent
```

不再塞大量项目规则、Skill 文件解释、完整来源审计、生成后 review 结论。生成结果和状态进 `return`、`run-log` 或按需 `review`。

**review 结构**
`review` 默认不生成长报告，只在这些情况需要：

- 核心镜头试跑。
- 人物一致性或身份风险镜头。
- 失败修复。
- 用户明确要求验收记录。
- Agent 判断有阻塞或不确定。

默认 review 规则：本地能力优先，不调用 Minimax MCP。外部视觉分析只有在你明确授权时才用。

**关键待定点**
有一个规则需要你确认：当前仓库规则要求“prompt 保存后等用户批准才生图”。如果要让连续执行不打扰你，需要把它改成“你批准 `run-plan.md` 后，该 run 内列明的非核心镜头视为已授权生成；核心/修复/高风险镜头仍单独停下”。我建议采用这个 run-level 授权，否则 Agent 编排省不了你的检查成本。


# 8

调整：
* `runs/` -> `tasks/`，所有run改成task，下面子目录结构不变。
* 可以把这Agent套分为两种：
  1. 直接跑Prompt和生成图片
  2. 分开，先出prompt。然后我可能会重新发起一次task，再跑生成图片。我可以对Prompt做抽样检查——到ChatGPT上试跑。

> 当前仓库规则要求“prompt 保存后等用户批准才生图”。如果要让连续执行不打扰你，需要把它改成“你批准 `run-plan.md` 后，该 run 内列明的非核心镜头视为已授权生成；核心/修复/高风险镜头仍单独停下”。我建议采用这个 run-level 授权，否则 Agent 编排省不了你的检查成本。

这个，在主会话中，我来下具体指令：
1. Agent的运行方式
2. 镜头范围

对应的规则按照这个进行更新。

还有其他问题么？
没有的话，可以写这个plan。
这里应该会有Agnent，docs/等不同文件的修改吧，Plan中应该有一个文件、文件夹更新/新增的列表。
`review 结构`、`Prompt结构`和`brief结构`，及tasks规则应该落到docs里，对吧。


# 9

plan中：

子会话、Agent中应强调对`visual-system`的使用情况，这个是视频生成保持风格或人物统一的核心：
* 有人物时，需要图生图
* 风格使用风格母版提示词

Agent应强调使用`image-2`skill的advisor模式。

这些都是之前犯错的地方。


# 10

这次是做视频的子会话及配套镜头Agent。
将来可能还会有做PPT的，因为需要读取的知识库不一样；本次这个没有额外知识库，但是PPT的会有，`docs/cases/`

这个是本次Plan中记录预留接口；还是将来，做到PPT，再调整？


可以，后续已经可以按这个体系做 5 镜人物一致性测试了。我准备了交接说明：

[2026-06-24-character-consistency-slide-task-handoff.md](C:/Users/wangq/Documents/Codex/video-workbench/handoff/2026-06-24-character-consistency-slide-task-handoff.md)

里面明确了下一会话要读的文件、任务目录、`video-slide-production` profile、`prompt only / prompt and generate` 两种模式、`session-01: s05/s21/s14` 与 `session-02: s25/s33` 的拆分，以及 `visual-system`、`style-prompt-master.md`、`character-reference-registry.md`、`gpt-image-2` Advisor、local-only review 的硬规则。

我没有创建实际 `tasks/2026-06-24-character-consistency/` 目录，也没有启动测试任务。下一步需要你在主会话里给出具体模式和范围后再开始。

验证过：
- 交接文件存在。
- 关键规则可检索到。
- 交接文件里没有 `shot-agent` 或 `runs/` 旧术语残留。
- 当前未提交变更包括 `AGENTS.md`、`VIDEO_WORKBENCH.md`、`docs/workflows/` 和这份新 handoff。