260816-Agent-Native 视频生产系统与通用 Agent 工作架构讨论归档

一、总体愿景：从“视频工具”到“Agent-Native Production OS”

最初的问题只是如何使用 Playwright 并行切片渲染 SVG 动画。 但随着讨论深入，目标逐步演化成：

使用代码描述视觉、动画、音乐、剪辑、合成与制作决策， 让 Agents 负责大量策划、生成、分析、修改、审核和调度， 最终由确定性的程序工具完成渲染与媒体输出。

完整系统可以抽象成：

人类意图
   ↓
Production Model / Project Model
   ↓
Agents
   ↓
结构化 IR / Proposal / Decision
   ↓
专业执行器
   ├── Remotion / Chromium
   ├── Blender
   ├── Houdini
   ├── Nuke
   ├── 音频程序
   └── FFmpeg
   ↓
视频 / 音频 / 图片序列 / 项目文件 / 可交付物

这里最重要的转变是： Agent 不应该成为项目状态本身，也不应该成为彼此之间唯一的信息通道。

Agent 应该像一个无状态、可替换、具备某种能力的执行者。 真正稳定的核心是：

• 版本化的世界状态；
• 明确的依赖关系；
• 结构化的 Proposal 与 Decision；
• 可重放的 Event；
• 可追溯的 Artifact；
• 每次任务对应的 Context View。

二、浏览器程序化视频渲染：Playwright 不只是 SVG

2.1 核心思路

Playwright 驱动 Chromium，因此只要 Chromium 可以稳定呈现的内容， 都可以被当作离线视频场景：

• SVG；
• HTML + CSS；
• CSS Animation；
• Web Animations API；
• Canvas 2D；
• WebGL；
• Three.js；
• WebGPU；
• React / Vue / Svelte；
• D3 / ECharts 等数据可视化库；
• DOM、SVG、Canvas、WebGL 的混合场景。

因此更准确的定义不是“SVG 渲染器”，而是：

Chromium / HTML 帧渲染器。

2.2 确定性时间模型

真正重要的不是“播放动画并截图”，而是：

frame N
  ↓
time = N / fps
  ↓
renderAt(time)
  ↓
唯一确定的画面

理想的场景接口类似：

interface FrameContext {
  frame: number;
  fps: number;
  time: number;
  width: number;
  height: number;
}

interface Scene {
  init(): Promise<void>;
  render(ctx: FrameContext): Promise<void>;
  dispose(): Promise<void>;
}

这种方式允许任意帧随机访问，因此特别适合并行：

Worker 0 → frame 0 ~ 999
Worker 1 → frame 1000 ~ 1999
Worker 2 → frame 2000 ~ 2999

2.3 浏览器并行切片

推荐架构是一个 Chromium 进程中建立多个独立 BrowserContext， 每个 Context 对应一个切片任务。

Browser
├── Context 0 → frame 0000 ~ 0999
├── Context 1 → frame 1000 ~ 1999
├── Context 2 → frame 2000 ~ 2999
└── Context 3 → frame 3000 ~ 3999

对于共享时钟机制尤其需要注意： 同一个 BrowserContext 内的多个 Page 可能共享时间控制， 因此不同时间切片更适合使用独立 Context。

2.4 最推荐的动画表达

如果场景代码可控，推荐显式提供：

window.renderAt = function (timeMs) {
  // 根据 timeMs 确定整个场景状态
};

与其依赖真实的 requestAnimationFrame、setTimeout 和真实时间， 不如把动画写成时间或帧编号的纯函数。

这是后续分布式渲染、缓存、重试、并行切片和复现能力的基础。

三、GPU、WebGL、Three.js 与 WebGPU

Playwright 本身并不进行图形渲染。 真正负责渲染的是 Chromium 的图形栈。

Playwright
   ↓
Chromium
   ↓
Blink / Canvas / WebGL / WebGPU
   ↓
ANGLE / GPU API
   ↓
GPU

3.1 GPU 可以加速哪些部分

• Three.js / WebGL rasterization；
• shader；
• WebGPU graphics pipeline；
• WebGPU compute shader；
• 部分 CSS compositing / filter；
• GPU 粒子系统；
• GPU 驱动的 3D 场景。

但以下环节仍可能是瓶颈：

• JavaScript 执行；
• DOM layout；
• GPU 到 CPU 的 framebuffer readback；
• 截图；
• PNG 压缩；
• 磁盘 I/O；
• 最终编码。

3.2 高性能方向

第一阶段可以：

Chromium
  ↓
PNG sequence
  ↓
FFmpeg

高性能阶段则更希望走向：

GPU Render
   ↓
Raw RGBA / VideoFrame
   ↓
FFmpeg / WebCodecs
   ↓
Hardware Encoder
   ↓
H.264 / HEVC / AV1

因此 PNG 应该被视为最容易实现的第一代 Frame Sink， 而不是整个系统不可替换的基础协议。

四、除了 Web，还有哪些“代码 → 图片序列 / 视频”的体系

讨论中形成了一个更广泛的渲染后端分类：

4.1 Skia

Skia 很适合作为未来的 Native 2D Renderer： 高性能、可 CPU/GPU 渲染，没有 DOM 和浏览器层的重量。

特别适合：

• 动态图表；
• 字幕；
• Kinetic Typography；
• UI 动画；
• 大量文字和矢量图形。

4.2 Blender

Blender 是极其重要的专业 3D 后端：

Python
  ↓
Meshes / Materials / Lights / Cameras
  ↓
Eevee / Cycles
  ↓
EXR / PNG sequence

适合：

• 产品广告；
• PBR；
• 复杂摄影机；
• 灯光；
• 角色；
• 复杂材质；
• 高质量离线 3D。

4.3 Godot / Unity / Unreal

这些实时引擎适合程序化实时场景、虚拟摄影、粒子和大规模 3D。

其中 Godot 由于开源、脚本化和 Movie Maker 能力， 对自动化视频系统尤其有吸引力。

4.4 wgpu

如果未来需要 Native GPU Backend， Rust + wgpu 是很有潜力的现代路线：

Rust
  ↓
wgpu
  ├── Vulkan
  ├── Metal
  ├── D3D12
  └── OpenGL

但它更适合成为底层 Renderer， 而不适合成为 Agent 直接编写内容的首选 Authoring API。

五、如果大部分视频描述代码由 Agents 生成，应该选择什么框架

5.1 第一推荐：Remotion / React + TypeScript

在“Agent 负责大量代码生成”的前提下， Remotion 成为非常强的第一选择。

原因包括：

• 帧驱动模型清晰；
• React 组件天然是 Agent 可修改的局部单元；
• HTML/CSS/SVG/Canvas/Three.js 生态巨大；
• TypeScript 的错误反馈对自动修复非常友好；
• 场景可以拆成多个小文件；
• 适合自动截图、视觉 QA 和局部 patch。

5.2 但长期不应该让 Remotion 成为顶层协议

更合理的是：

Agent
  ↓
自己的 Video IR / DSL
  ↓
Compiler
  ↓
Remotion
  ↓
Chromium
  ↓
Frames
  ↓
FFmpeg

未来再扩展：

Video IR
├── RemotionRenderer
├── BlenderRenderer
├── ManimRenderer
├── HoudiniRenderer
├── SkiaRenderer
└── WgpuRenderer

5.3 为什么不推荐 Agent 第一阶段直接写 Skia / Vulkan / wgpu

Agent 更擅长高层、语义清晰、声明式、容易验证的表达。

如果直接面对底层坐标和 draw call， 很容易退化成大量脆弱的：

x = 123
y = 581
width = 842
height = 91

因此最好让 Agent 写高层 DSL， 再由 compiler 转换到底层渲染系统。

六、Houdini 与 Nuke：专业程序化影视工具如何进入体系

6.1 Houdini 的定位

Houdini 更像 Procedural Content / Simulation Backend。

适合：

• 粒子；
• 烟雾；
• 火焰；
• 流体；
• 破碎；
• 布料；
• 程序化建筑；
• 地形；
• 大量实例；
• 程序化 motion graphics。

典型流程：

Agent
  ↓
Houdini Graph / VEX / Python
  ↓
Simulation
  ↓
Bake Cache
  ↓
Parallel Render
  ↓
EXR

6.2 Houdini 带来的一个重要概念：Execution Mode

并不是所有场景都能随机访问任意帧。

type SceneExecutionMode =
  | "stateless"
  | "cached"
  | "sequential";

例如：

6.3 Nuke 的定位

Nuke 更像 Pixel Compositing / Finishing Backend。

典型流程：

Blender EXR
Houdini EXR
Remotion RGBA
Live Action
Masks
Depth
Motion Vectors
     ↓
    Nuke
     ↓
Final EXR
     ↓
FFmpeg

Nuke 适合：

• Alpha compositing；
• keying；
• roto；
• tracking；
• color correction；
• glow；
• defocus；
• grain；
• motion blur；
• deep compositing；
• 多 pass CG 合成。

6.4 专业后期 Agent 团队

                  Director Agent
                       │
                 Scene Planner
                       │
       ┌───────────────┼───────────────┐
       ▼               ▼               ▼
 Motion Agent      3D Agent         FX Agent
  Remotion          Blender          Houdini
       │               │               │
       └───────────────┼───────────────┘
                       ▼
                Compositor Agent
                     Nuke
                       │
                       ▼
                   FFmpeg
                       │
                       ▼
                    Master

七、Agent 如何重塑视频前期策划

一个重要结论是： 前期策划可能比后期更早被 Agents 深度改变。

因为传统前期大量工作本质上是：

• 理解目标；
• 研究上下文；
• 提出方向；
• 逐渐减少自由度；
• 将抽象创意编译成镜头；
• 评估制作成本和风险；
• 同步不同部门。

7.1 前期本质：Constraint Compiler

模糊的人类意图
      ↓
Intent
      ↓
Research
      ↓
Concept Search
      ↓
Narrative
      ↓
Beat Graph
      ↓
Shot IR
      ↓
Production Simulation
      ↓
可执行制作蓝图

7.2 Intent Agent

第一阶段不应该马上“写脚本”， 而应该把用户的模糊表达结构化成：

• 商业目标；
• 受众；
• 核心信息；
• 情绪目标；
• 平台；
• 时长；
• 禁止事项；
• 成功标准。

7.3 Research Agents

并行建立 Creative Evidence Base：

• 品牌研究；
• 受众研究；
• 竞品研究；
• 文化语境；
• 视觉趋势；
• 产品事实；
• 平台特征。

7.4 Concept Space Search

Agent 不应该只“生成 200 个创意”， 而应该有结构地探索创意空间。

例如：

Narrative
├── story
├── metaphor
├── documentary
├── product demo
└── abstract

Energy
├── contemplative
├── controlled
└── explosive

Visual
├── live action
├── graphics
├── CG
└── mixed

7.5 Beat Graph 优先于完整 Script

先表达：

0-3s   建立疑问
3-8s   产品第一次出现
8-15s  证明性能
15-22s 扩展场景
22-27s Hero Shot
27-30s Brand + Claim

然后才生成 Voiceover、Dialogue、Graphics。

7.6 Shot IR

传统 Storyboard 是“图片 + 备注”， Agent-native 系统更应该有结构化 Shot IR。

{
  "shot": "S03_SH07",
  "duration": 2.4,
  "purpose": "prove cushioning response",
  "camera": {
    "shotSize": "ECU",
    "height": "ground",
    "movement": "tracking"
  },
  "requiredElements": [
    "shoe outsole visible",
    "ground deformation visible"
  ]
}

7.7 Production Engineer Agent

专门回答： 这个创意现实中怎么拍？

分析：

• 场景数量；
• 演员；
• 设备；
• 灯光；
• 时间；
• 天气；
• 交通；
• 服化道；
• VFX；
• 预算和风险。

并且不是简单“删掉太贵的镜头”， 而是寻找语义等价但制作成本更低的实现方式。

7.8 Human Approval Gate

Brief
 ↓
Agent Exploration
 ↓
[GATE 1: Creative Direction]
 ↓
Story / Script
 ↓
[GATE 2: Story]
 ↓
Storyboard / Previs
 ↓
[GATE 3: Visual]
 ↓
Production Engineering
 ↓
[GATE 4: Greenlight]
 ↓
Shoot

Gate 通过后，上游决策应被冻结或显式版本化， 防止 Agent 不断“优化”导致整个项目漂移。

八、音乐：Agent 输出文本，程序输出音乐

与黑盒 text-to-music 不同， 更可控的路线是：

音乐意图
   ↓
Agents
   ↓
Music IR
   ↓
乐谱 / MIDI / Event / Synth Definitions
   ↓
离线音频 Renderer
   ↓
Stems
   ↓
Mix
   ↓
Master WAV
   ↓
FFmpeg

8.1 Music IR

MIDI 不应该成为 Agent 的最高层接口。 更上层应该表达：

• 结构；
• 情绪；
• 能量；
• 和声；
• 旋律；
• 节奏；
• 配器；
• 演奏法；
• 同步点。

tempo:
  bpm: 108

structure:
  - id: intro
    bars: 8
    energy: 0.2

  - id: build
    bars: 8
    energy:
      from: 0.5
      to: 0.85

  - id: climax
    bars: 16
    energy: 1.0

8.2 候选程序音乐技术

8.3 音乐 Agent 分工

                 Music Director
                       │
       ┌───────────────┼───────────────┐
       ▼               ▼               ▼
 Composer Agent    Rhythm Agent    Sound Agent
       │               │               │
   melody/harmony     groove        timbre/synth
       └───────────────┼───────────────┘
                       ▼
               Arrangement Agent
                       │
                    Music IR
                       │
               Performance Agent
                       │
                     Events
                       │
                  Audio Renderer
                       │
                     Stems
                       │
                    Mix Agent
                       │
                   Master WAV

8.4 与视频共享 Timeline

这部分极有潜力：

sync_points:
  - time: 8.4
    type: cut

  - time: 20.0
    type: narrative_transition

  - time: 31.96
    type: hero_reveal
    importance: critical

音乐和剪辑可以共同优化： 某个视觉切点可以微移， 某个音乐 downbeat 也可以调整， 最终选择整体损失最小的组合。

九、实拍素材理解、粗剪与精剪

9.1 最重要的结论

不要把几十 GB 视频直接交给 Agent， 也不要把视频压成一段自然语言摘要。

应该建立： Text-first, Vision-on-demand 的 Footage IR。

9.2 媒体分析 Pipeline

Camera Originals
      │
      ├── ffprobe metadata
      ├── analysis proxy
      ├── audio proxy
      ├── shot detection
      ├── transcript
      ├── word timing
      ├── keyframes
      ├── visual descriptions
      └── embeddings
              ↓
          Footage IR

9.3 Asset / Shot / Semantic Segment

Asset
  └── Shot
       └── Semantic Segment

一个 30 分钟采访文件可能只有一个视觉 Shot， 但包含几十个语义段落， 因此不能只依赖镜头检测。

9.4 Transcript

对访谈、纪录片、播客类素材， 最好拥有：

• speaker；
• 句子级 timestamp；
• 词级 timestamp；
• 可选 forced alignment。

9.5 Shot Card

shot: SH027

source:
  asset: CAM_B_0012
  in: 42.183
  out: 49.742

visual:
  subject: female presenter
  action:
    - enters from frame left
    - sits at desk

camera:
  framing: medium-wide
  movement: static

quality:
  focus: good
  exposure: good

edit:
  action_start: 43.02
  action_complete: 46.71
  stable_tail: 2.4s

keyframes:
  - 42.5
  - 44.8
  - 47.0
  - 49.2

9.6 Keyframe 是视觉逃生通道

Agent 主要读文本
      │
      ├── 信息充分 → 直接决策
      │
      └── 信息不足
             ↓
       getFrames(...)
             ↓
      查看少量关键帧

必要时再取一个几秒钟的低码率 proxy clip。

9.7 Agent 不应该直接输出 FFmpeg

应该：

Editorial Agent
    ↓
Edit Decision IR
    ↓
Validator
    ↓
OTIO / Timeline
    ↓
FFmpeg Compiler
    ↓
FFmpeg

示例：

{
  "timeline": [
    {
      "clip": "C001",
      "source": "CAM_A_0042",
      "source_in": 124.82,
      "source_out": 128.17,
      "role": "dialogue"
    },
    {
      "clip": "C002",
      "source": "CAM_B_0012",
      "source_in": 43.12,
      "source_out": 46.82,
      "role": "broll"
    }
  ]
}

9.8 粗剪与精剪的分层

粗剪主要是语义选择，精剪主要是局部时间与画面优化。

粗剪：

• 选什么台词；
• 选哪些 B-roll；
• 故事结构；
• 大致时长；
• 节奏结构。

精剪：

• 切点提前几帧还是延后几帧；
• 动作 continuity；
• 视线方向；
• 运动方向；
• 人物表情；
• J-cut / L-cut；
• 局部节奏。

到精剪阶段只需要查看切点附近有限窗口， 而不需要重新理解几十小时原始素材。

十、Agent 之间的高频交互应该怎么做

10.1 不应该让 Agents 主要依靠自然语言互聊

推荐：

Agents 共享的是结构化状态、事件、产物和引用， 而不是一个无限增长的群聊历史。

10.2 四类不同信息

1. Durable State：长期项目事实；
2. Events：世界发生了什么；
3. Messages / Tasks：暂时协作和调度；
4. Artifacts：视频、图片、音频、代码、模型等大型产物。

10.3 Versioned Immutable State

Entity SH017
├── Revision A
├── Revision B
└── Revision C ← HEAD

不覆盖旧版本。 Revision 可以使用 canonical JSON 的 hash 标识。

10.4 Event Log

状态回答“现在是什么”，事件回答“为什么变成这样”。

{
  "type": "timeline.clip.updated",
  "target": "CLIP_017",
  "before": "revision:82af",
  "after": "revision:92cd",
  "agent": "editor-agent",
  "reason": "Removed 12-frame pause"
}

Event Log 最好 append-only。

10.5 消息传引用，不传巨大内容

{
  "type": "review.request",
  "target": {
    "type": "timeline",
    "id": "rough-cut",
    "revision": "a91f"
  }
}

接收方自己读取对应 revision。

10.6 Claim 与 Fact 分离

Agent 的判断不能直接静默变成事实。

{
  "subject": "SHOT_72",
  "predicate": "contains_person",
  "object": "Alice",
  "confidence": 0.83,
  "author": "visual-agent",
  "evidence": [
    "frame:CAM_B_0032@83.124"
  ]
}

10.7 Claim / Proposal / Decision / Preference / Constraint 要区分

这些语义完全不同：

• Claim：我认为某事实可能成立；
• Proposal：我建议改变状态；
• Decision：已经选择某方案；
• Preference：某人更喜欢什么；
• Constraint：系统必须满足什么。

10.8 Authority

不应该所有 Agent 都能修改所有领域。

例如：

Editor Agent
  read: Footage / Story
  propose: Timeline
  commit: no

Music Agent
  read: Timeline
  propose: Music
  modify Timeline: no

Human Director
  approve: Creative Direction

10.9 Proposal → Validate → Commit

Agent
  ↓
Proposal
  ↓
Schema Validation
  ↓
Semantic Validation
  ↓
Review
  ↓
Commit
  ↓
New Revision

10.10 Dependency Graph

这是多 Agent 大规模运行时最关键的基础设施之一。

Creative Intent
      ↓
Script
      ↓
Shot IR
      ↓
Storyboard
      ↓
Timeline
      ↓
Music

当上游变化时，只 invalidate 真正受影响的下游节点。

十一、Production OS：面向影视生产的基础架构

11.1 总体结构

11.2 推荐的核心基础设施

第一阶段建议：

• PostgreSQL；
• Artifact Store；
• Temporal 或其他 Durable Workflow 系统；
• Agent Runtime；
• Schema Registry；
• Dependency Graph；
• Media Intelligence Worker；
• FFmpeg Worker；
• Chromium / Remotion Worker。

11.3 为什么不是一开始就上很多微服务

推荐：

模块化单体 + 独立 Worker。

例如：

production-os/
├── apps/
│   ├── api/
│   └── studio/
│
├── packages/
│   ├── domain/
│   ├── schemas/
│   ├── project-store/
│   ├── agent-runtime/
│   ├── workflow/
│   ├── artifact-store/
│   ├── dependency-graph/
│   └── timeline/
│
├── workers/
│   ├── media/
│   ├── ffmpeg/
│   ├── chromium/
│   └── blender/
│
└── python/
    ├── media_intelligence/
    └── render_adapters/

11.4 Artifact Store

大型对象全部离开数据库：

• MOV；
• MP4；
• WAV；
• EXR；
• PNG；
• Proxy；
• Blend；
• Houdini Cache；
• Nuke Script；
• 生成代码；
• 模型产物。

数据库只保存 hash、URI、大小、类型、来源和派生关系。

11.5 Render Manifest

{
  "renderer": "blender",
  "scene_revision": "81ae",
  "assets": {
    "model": "sha256:...",
    "texture": "sha256:..."
  },
  "frame_range": [100, 180],
  "resolution": [3840, 2160],
  "seed": 8172
}

Manifest 本身可以 hash， 从而实现确定性渲染缓存。

11.6 Agent Runtime

Task
  ↓
Context Builder
  ↓
LLM / Agent
  ↓
Tool Gateway
  ↓
Validator
  ↓
Proposal

Agent 本身应尽量无状态， 不长期拥有项目记忆。

11.7 Context Builder

世界状态可能极大， 但 Agent 每次只需要任务相关的一个切片：

{
  "task": "Build rough cut for beat 4",
  "creative_intent": {},
  "beat": {},
  "timeline_neighborhood": {},
  "dialogue_candidates": [],
  "broll_candidates": [],
  "constraints": {},
  "recent_decisions": []
}

11.8 Schema Registry

所有 IR 都应该显式版本化：

schemas/
├── creative/intent.v1.json
├── production/shot.v4.json
├── footage/segment.v3.json
├── editorial/edit-decision.v5.json
└── music/music.v2.json

Agent 输出先做 schema validation， 再做业务语义校验。

11.9 Sandbox

Agent 未来可能生成：

• TypeScript；
• Python；
• Blender Python；
• Houdini Python / VEX；
• Nuke Python；
• Csound；
• FFmpeg filter graph。

因此必须通过隔离环境执行：

Agent Code
   ↓
Job Package
   ↓
Isolated Container
   ├── filesystem restriction
   ├── network restriction
   ├── CPU/GPU limit
   └── timeout
   ↓
Artifact Output

十二、抽掉影视领域以后：通用 Agent 工作架构最核心的基础抽象

这是讨论最终最重要的收敛之一。

最不应该成为系统核心抽象的，恰恰是 Agent。

Agent 是执行者。 世界模型才是长期稳定的核心。

12.1 Entity

世界中长期存在、可稳定引用的对象。

例如：

• Project；
• Document；
• Customer；
• Shot；
• Order；
• Codebase；
• Task。

12.2 Revision

Entity 在某个时刻的不可变版本。

Entity A
├── Revision 1
├── Revision 2
└── Revision 3 ← HEAD

它提供：

• 历史；
• diff；
• rollback；
• 并发编辑；
• 缓存；
• 复现；
• provenance。

12.3 Artifact

大型或外部结果：

• 文件；
• 图片；
• 视频；
• 代码包；
• 模型；
• 数据库快照。

状态只保存引用， 不复制 Artifact 内容。

12.4 Claim / Fact

Agent 经常输出的是不确定判断， 因此必须显式表达：

• subject；
• predicate；
• object；
• confidence；
• evidence；
• author。

12.5 Goal / Intent / Constraint / Preference

不要把“为什么做”和“不能做什么”都藏进 prompt。

需要区分：

• Goal：希望达到什么；
• Intent：为什么做；
• Constraint：必须满足的硬条件；
• Preference：软偏好；
• Success Criterion：何时算成功。

12.6 Action / Proposal

Agent 不直接修改世界， 而是提出：

Current State
    ↓
Agent
    ↓
Proposal / Patch
    ↓
Validate
    ↓
Commit

12.7 Event

用于记录：

• 发生了什么；
• 谁做的；
• 由什么触发；
• 之前是什么；
• 之后是什么。

12.8 Dependency

让系统能够增量更新，而不是全量重跑。

A
├── B
│   ├── C
│   └── D
└── E

A 改变后， 系统计算真正需要 invalidate 的子树。

12.9 Context View

Agent 每一次执行看到的世界切片。

World State
    ↓
Context Compiler
    ↓
Context View
    ↓
Agent

Context View 应该本身可版本化和可追溯。

这样系统才能回答： 这个 Agent 当时为什么会做出这个决定？

因为可以恢复： 它当时看到的是 ContextView@XYZ。

12.10 Task / Workflow

Task 是一次待完成工作。 Workflow 是多个 Task、等待、重试、审批组成的长期过程。

12.11 Capability

不要写：

把任务发给 Agent B

而应该写：

required_capability = "legal-review"

执行者可以是：

• 某个 LLM；
• 规则引擎；
• 脚本；
• 人工；
• 一个服务；
• 一个 worker pool。

12.12 Authority / Policy

谁能：

• 读取；
• propose；
• commit；
• approve；
• invalidate；
• 执行外部工具。

都应该成为正式的系统语义。

十三、一个通用 Agent Kernel 的最小循环

这里 Agent 只是环中的一个节点， 并不是系统本身。

十四、最终形成的核心原则

1. 代码视频最重要的是确定性时间模型，而不是截图工具本身。
2. 统一时间、生命周期、资产和协议，不要强行统一所有绘图模型。
3. FFmpeg 更适合作为合成与最终编码执行器，而不是 Agent 的直接输出语言。
4. Agent 应该输出 IR、Patch、Proposal，而不是直接修改生产状态。
5. Agent 应尽量无状态，长期记忆进入 Project / World Model。
6. 大型 Artifact 用引用传递，不在 Agent 间复制。
7. Claim、Fact、Proposal、Decision、Preference、Constraint 必须语义区分。
8. 版本应不可变，正式状态通过 HEAD 指向某个 Revision。
9. Event Log 应 append-only，保存因果历史。
10. Dependency Graph 决定系统能否扩展到大量 Agent。
11. Agent 不应该读整个世界，而应该读 Context View。
12. Human Approval Gate 应成为 Kernel 的正式机制。
13. Agent 之间最好通过共享 Blackboard / Project Graph 协作，而不是无限群聊。
14. 不同专业软件应该成为能力后端，而不是让一个工具解决所有问题。
15. 前期、实拍、后期、音乐应该共享同一个 Production Model 和 Timeline 语义。

十五、建议的实际实施路线

阶段一：建立 Agent Kernel

先实现：

• Entity；
• Revision；
• Artifact；
• Event；
• Proposal；
• Decision / Approval；
• Dependency；
• Task；
• Context View；
• Schema Registry。

阶段二：做一个最小但完整的视频 Vertical Slice

上传实拍素材
   ↓
生成 Proxy
   ↓
ASR / Shot Index / Keyframes
   ↓
Footage IR
   ↓
Agent 粗剪
   ↓
Edit IR / OTIO
   ↓
FFmpeg
   ↓
Rough Cut
   ↓
用户修改
   ↓
Proposal
   ↓
新 Timeline Revision
   ↓
重新输出

这条闭环一旦可靠， 整个系统的核心基础基本就被验证了。

阶段三：加入 Agent 生成的视频场景

Video IR
  ↓
Remotion / Chromium
  ↓
Frames
  ↓
FFmpeg

阶段四：加入 Blender

作为第一个专业非 Web 3D Backend。

阶段五：加入音乐

Music Intent
  ↓
Music IR
  ↓
Csound / SuperCollider / MIDI / Sampler
  ↓
Stems
  ↓
Mix
  ↓
FFmpeg

阶段六：加入前期策划

Brief
 ↓
Intent
 ↓
Research
 ↓
Concept
 ↓
Beat Graph
 ↓
Shot IR
 ↓
Previs
 ↓
Production Plan

阶段七：加入 Houdini / Nuke

到这一阶段， 系统已经开始具备完整的专业影视制作管线形态。

十六、最终可以形成的统一 Production Model

这个模型最有价值的地方在于： 前期、实拍、后期、音乐、VFX 不再是完全割裂的工具链， 而是同一个版本化 Production Model 的不同投影。

十七、最核心的架构哲学

不要设计一个“Agents 相互聊天的系统”， 而要设计一个“多个智能执行者共同修改一个版本化世界的系统”。

如果只保留五个最不能设计错的抽象， 它们是：

1. Entity / Revision：世界状态和历史；
2. Proposal / Commit：智能执行者如何安全改变世界；
3. Event：历史、因果、审计和重放；
4. Dependency：增量计算与大规模协作；
5. Context View：Agent 在复杂世界中如何保持可靠。

在它们之上， Agent 可以随时更换模型、策略、角色、工具甚至被人工替代。

在它们之下， Remotion、Blender、Houdini、Nuke、Csound、SuperCollider、FFmpeg、 数据库、工作流系统和 GPU Worker 都只是能力实现。

这也是整个讨论最终从“一个视频渲染方案” 逐渐演化为“通用 Agent 工作基础设施”的根本原因。