PRJ-03 WIP
BinCutAgent AI 视频操作系统
ai video operating system, prompt to mp4
一句自然语言，一条 AI 流水线，一支成片视频
- AI Agent
- Rust
- TypeScript
- 音视频
4 阶段
AI Pipeline：Director → Script → Asset → Editing
2 处
HITL 人工审批节点（分镜与脚本阶段可确认 / 拒绝）
5 个
独立服务：gateway / agent / render / harness / mcp
M2 达成
端到端 TimelineDSL 生成 + Temporal 渲染派发（M3 成片管线推进中）
// 01
问题背景
AI 生成视频的痛点不在「调用一次大模型」，而在把分镜、脚本、素材、剪辑、渲染这条多阶段链路工程化：LLM 输出要可校验、流程要可中断可恢复、人要能在关键节点介入。
这条问题域我有一段已落地的对照经验：在电商产品 shatangAI（已上线 shatang.top）中，我用 BullMQ 任务队列与状态机把 6+ 家第三方视频生成服务编排成了可靠的生产系统——但那是「编排别人家的生成能力」，渲染与创作决策都不在自己手里。
BinCutAgent 是向更底层走一步的架构探索：自己拥有从分镜、脚本、素材到渲染的完整链路，按「操作系统」的思路分层——Rust 控流、Pi 控脑、Go 评测、Temporal 卖力、MCP 扩展，每个服务只做一件事，任何一层都能单独替换。如果说 shatangAI 回答了「AI 视频产品如何上线」，BinCutAgent 要回答的是「AI 视频系统应该如何构造」。
// 02
系统架构
前端层
对话 + 画布双形态的创作界面
网关层
Rust Axum 统一入口与实时推送
AI 编排层
TypeScript Agent 跑四阶段 LLM 流水线
渲染与基础设施层
Temporal 调度 + FFmpeg 合成
// 03
关键技术决策
每一条都包含「为什么这样选」与「代价是什么」——这是我理解这个项目的方式。
以 TimelineDSL 作为 AI 与渲染之间的唯一契约
LLM 的输出天然不稳定，直接让它生成 FFmpeg 命令或操作数据库都不可控。定义一份 Zod 描述的 TimelineDSL（轨道 / 片段 / 时间码），Agent 只能产出 DSL，harness 用从 Zod 导出的 JSON Schema 做机器校验，渲染端只认校验通过的 DSL。代价是多了一层 schema 同步成本（pnpm schema:export），但换来「AI 可换、渲染不变」的强类型边界，两侧可独立测试、独立演进。
Temporal 而非自研任务队列承载渲染
视频渲染耗时长、会失败、需要重试与可观测——这正是 Temporal 的主场：Workflow / Activity 语义自带重试、超时、心跳与执行历史，工作流代码可以像写同步函数一样写，省去自研状态机。代价是引入一个重量级基础设施（Temporal Server + Postgres），本地开发门槛变高，用 docker compose 一键起栈来对冲。
Rust Axum 做网关，Redis Streams 做服务间事件总线
网关要同时扛 REST、WebSocket 长连接与事件转发，Axum + Tokio 的性能与类型安全合适。服务间通信用 Redis Streams 而非 Kafka——本系统事件量不大，Streams 的消费者组语义足够，且与缓存共用一套 Redis，少养一个组件；Agent 重启时事件可回放，前端看到的是可恢复的事件流而非卡死。代价是 Streams 没有 Kafka 那样成熟的生态与重放工具，事件模型设计时要更克制。
HITL：把审批做成流水线的一等公民
全自动 AI 剪辑的错误会逐阶段放大——分镜错了脚本必错。在 Director 与 Script 两个高语义阶段后强制暂停，发 hitl_interrupt WebSocket 事件，前端渲染审批卡片；确认经 Gateway → Redis [hitl_resumed] → Agent 恢复执行，拒绝则会话置 failed。代价是牺牲「一句话秒出片」的爽感，换来结果可控。
多语言服务网格而非单语言单体
按语言的生态优势分工：Rust 控流（网关）、TypeScript 控脑（LLM 生态最丰富，Pi Framework 做 Agent 编排）、Go 卖力（渲染 Worker 与校验器，部署简单）。每个服务独立目录 + 独立扩容，用 pnpm workspace / go.work / Cargo workspace 统一管理。代价很明显——跨语言类型契约要靠 packages/types 与 JSON Schema 对齐，本地起全栈要开四个终端。
// 04
我的职责与产出
RESPONSIBILITIES
- 设计系统总体架构与「每服务单一职责」的服务边界
- 实现四阶段 LLM Pipeline 与 TimelineDSL 契约（Zod → JSON Schema 同步）
- 实现 Rust 网关的 REST / WebSocket / Redis Streams 事件通路
- 实现 Go Temporal 渲染 Worker 与 FFmpeg complex_filter 合成逻辑
- 实现 HITL 审批的中断 / 恢复事件流与前端审批卡片交互
- 搭建 docker compose 基础设施（Postgres / Redis / Qdrant / MinIO / Temporal）
OUTCOMES
- Prompt → TimelineDSL → MP4 的端到端链路打通（M0–M2 里程碑完成）
- TimelineDSL 成为跨语言（TS / Go）共享的唯一渲染契约，Agent 与渲染可独立演进
- 渲染任务由 Temporal 托管，重试 / 超时 / 历史开箱即用
- MCP 工具服务（ffmpeg / whisper / opencut）为后续技能扩展预留标准接口
// 05
踩坑与复盘
多语言 + 多服务的架构表达力很强，但对单人项目是双刃剑：联调一次全链路要同时盯四个进程的日志，改一个字段要在三种语言里同步。复盘下来最值得的是 TimelineDSL 这层契约——它把 LLM 的不确定性关进了 schema 的笼子。当前推进到 M3（真实素材管线与成片输出），后续规划 M4 技能系统（自动字幕、B-roll）与 M5 多租户生产化。
// 06
技术栈
- Rust · Axum
- TypeScript
- Next.js 15
- Go
- Temporal
- Redis Streams
- FFmpeg