Compare commits
4 Commits
fe82c68368
...
main
| Author | SHA1 | Date | |
|---|---|---|---|
|
bd0a477f60 | ||
|
|
ef579f9a37 | ||
|
|
bf7ff0784f | ||
|
|
956e41f87a |
92
Openclaw-Herems/01-Video-Summary.md
Normal file
92
Openclaw-Herems/01-Video-Summary.md
Normal file
@@ -0,0 +1,92 @@
|
|||||||
|
# 【城】开源 Agent 之王 Hermes，到底厉害在哪？-哔哩哔哩
|
||||||
|
|
||||||
|
> 来源: Bilibili | https://b23.tv/JlH5es4
|
||||||
|
|
||||||
|
## 视频总结
|
||||||
|
|
||||||
|
### 核心主题：Hermes Agent 的真正厉害之处不是模型，而是学习方式
|
||||||
|
|
||||||
|
**背景介绍：**
|
||||||
|
- Hermes Agent 开发商是 Nous Research（非追逐热点的AI创业公司，做开源模型起家，Free series 在开源圈响当当）
|
||||||
|
- 团队规模不大（10来个人到30人），创始人 TecNio 是独立研究员，open hermes 模型开发者
|
||||||
|
- 在推出 Hermes 之前，Nous Research 花了两年多时间做模型
|
||||||
|
|
||||||
|
### Hermes vs OpenClaw（龙虾）核心差异
|
||||||
|
|
||||||
|
**设计理念完全不同：**
|
||||||
|
- **OpenClaw（龙虾）**：你是决策链的中心 agent，需要你告诉他做什么，你定义了它才能去做。适合企业级部署，需要完整审计和合规能力，需要精细控制每一条指令。
|
||||||
|
- **Hermes**：核心理念是"进化游戏"，你不用告诉他每一步怎么去做，它会自己学。从你的交互中自己学习，越用越聪明。
|
||||||
|
|
||||||
|
**核心口号：The agent that grows with you（会和你一起成长）**
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Self Improving Loop（三层递进的循环）
|
||||||
|
|
||||||
|
**第一层：记忆积累（持久记忆系统）**
|
||||||
|
- 底层用 SQLite + FTS5 支持全文检索
|
||||||
|
- LLM Summarization 自动压缩历史对话
|
||||||
|
- Honcho Dialectic User Profile 机制：渐进式建立用户画像，不是一次性记住，而是在多次交互中慢慢拼凑出用户偏好
|
||||||
|
- 用户不用每次都重新解释
|
||||||
|
|
||||||
|
**第二层：技能生成（自动技能创建）**
|
||||||
|
- 最骚的功能：完成复杂任务后自动生成 SK.md 文件记录这次是怎么解决的
|
||||||
|
- 格式兼容 Agent Skill 开放标准，可以共享
|
||||||
|
- 不用用户手动安装配置技能
|
||||||
|
|
||||||
|
**第三层：持续进化（自动优化）**
|
||||||
|
- 把重复或相近的 skill 自动融合，避免技能库拥挤
|
||||||
|
- 每次完成任务后会复盘更快更省 token 的路径
|
||||||
|
- 自动更新旧的技能让它越跑越顺
|
||||||
|
|
||||||
|
**进化曲线：**
|
||||||
|
- 第一周：像一个刚入职的新人，你说什么他就做什么
|
||||||
|
- 第一个月：记住工作习惯，可以做提前量
|
||||||
|
- 第三个月：对你的了解程度可能超过你的同事，一个眼神就知道你想干什么
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 四大维度对照
|
||||||
|
|
||||||
|
| 维度 | OpenClaw（龙虾） | Hermes |
|
||||||
|
|------|-----------------|--------|
|
||||||
|
| **记忆机制** | 纯 markdown 文件存储，需要手动编辑 | 全自动压缩、提炼、建立用户画像 |
|
||||||
|
| **技能获取** | 用户手动去安装、配置插件市场数千个技能 | 自动生成，用户不用动手 |
|
||||||
|
| **部署成本** | 主要本地运行，serverless 需自己搞 | 支持 docker/SSH/serverless，$5 VPS 就能跑 |
|
||||||
|
| **安全模型** | DM Ping 验证 + 显示 allow list，每条消息验证，敏感操作审批 | 默认沙盒隔离容器执行 + 零遥测，不收集不上传数据 |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 技术架构（三层）
|
||||||
|
|
||||||
|
从外往里说：
|
||||||
|
1. **用户交互层**（Surfaces）：CLI、Telegram、Discord 等
|
||||||
|
2. **Agent Core**（AIAgent 核心循环）：理解 → 规划 → 执行
|
||||||
|
3. **Execution 执行层**：工具调用、系统交互
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 如何选择？
|
||||||
|
|
||||||
|
**适合 Hermes 的场景：**
|
||||||
|
- 需要"长气的AI朋友"，记忆力超棒
|
||||||
|
- 预算敏感，想要低成本部署（几十块 ECS）
|
||||||
|
- 不想折腾配置，希望 agent 自己学会事情
|
||||||
|
|
||||||
|
**适合 OpenClaw 的场景：**
|
||||||
|
- 企业级部署
|
||||||
|
- 需要完整审计和合规能力
|
||||||
|
- 需要精细控制每一条指令
|
||||||
|
- agent 的每一个动作都需要审批
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 一句话总结
|
||||||
|
|
||||||
|
> **OpenClaw 是你告诉他做什么，Hermes 是它学会你自己想做什么**
|
||||||
|
>
|
||||||
|
> 这是一个你想让 AI 以什么方式陪伴你的问题。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
*总结时间: 2026-05-06*
|
||||||
331
Openclaw-Herems/02-Hermes-Harness.md
Normal file
331
Openclaw-Herems/02-Hermes-Harness.md
Normal file
@@ -0,0 +1,331 @@
|
|||||||
|
# Hermes Agent：Harness 完整架构与创新模式
|
||||||
|
|
||||||
|
> 资料来源：Hermes Agent 官方文档、Pyshine Orange Book、dev.to 技术深度解析、Nous Research GitHub 及 ArXiv 相关研究
|
||||||
|
> 整理时间：2026-05-06
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 一、总体架构
|
||||||
|
|
||||||
|
### 1.1 核心理念：从 Harness 到 Agent
|
||||||
|
|
||||||
|
Hermes Agent 源自 Nous Research 的 **Harness 工程框架**，完成了一次从"开发者工具"到"自主智能体平台"的根本性转变。这不是简单的重命名，而是 AI 工程第三范式转移的体现：
|
||||||
|
|
||||||
|
| 范式 | 核心 | 特点 |
|
||||||
|
|------|------|------|
|
||||||
|
| Prompt Engineering | 优化提示词 | 手工调试，易出错 |
|
||||||
|
| Context Engineering | 管理上下文 | 复杂，仍是被动的 |
|
||||||
|
| **Harness Engineering** | **自我进化的控制基础设施** | 主动学习，持续改进 |
|
||||||
|
|
||||||
|
**核心洞察**：模型提供智能，但 **Harness 提供控制**。没有 Harness，将 LLM 部署到生产环境就像"把喷气发动机直接连到方向盘上"——有动力但无控制系统。
|
||||||
|
|
||||||
|
### 1.2 三层架构概览
|
||||||
|
|
||||||
|
```
|
||||||
|
┌────────────────────────────────────────────────────────────┐
|
||||||
|
│ ENTRY POINTS │
|
||||||
|
│ CLI / TUI / Gateway (TG, Discord, Slack) / Cron / Batch │
|
||||||
|
└─────────────────────┬──────────────────────────────────────┘
|
||||||
|
│ 每个入口构建一个 AIAgent
|
||||||
|
▼
|
||||||
|
┌────────────────────────────────────────────────────────────┐
|
||||||
|
│ AIAgent (核心循环 ~13,700 行) │
|
||||||
|
│ build_system_prompt → call model → dispatch tools → loop │
|
||||||
|
└──────┬─────────────┬──────────────┬───────────┬───────────┘
|
||||||
|
│ │ │ │
|
||||||
|
▼ ▼ ▼ ▼
|
||||||
|
┌──────────┐ ┌──────────┐ ┌────────────┐ ┌─────────────┐
|
||||||
|
│ Tools │ │ Skills │ │ Memory │ │ Providers │
|
||||||
|
│ Registry │ │ Loader │ │ Manager │ │ (model API) │
|
||||||
|
└──────────┘ └──────────┘ └────────────┘ └─────────────┘
|
||||||
|
│
|
||||||
|
┌────────────────────────────────────────────────┘
|
||||||
|
▼
|
||||||
|
┌────────────────────────────────────────────────────────────┐
|
||||||
|
│ Execution Environments: local / Docker / SSH / Modal │
|
||||||
|
└────────────────────────────────────────────────────────────┘
|
||||||
|
```
|
||||||
|
|
||||||
|
**三层语义**：
|
||||||
|
- **第一层（Surfaces）**：人/系统如何与 Agent 对话（CLI、聊天平台、Cron）
|
||||||
|
- **第二层（Agent Core）**：循环 + 四个可插拔子系统（工具、技能、记忆、模型）
|
||||||
|
- **第三层（Execution）**：Shell/代码执行的实际运行环境
|
||||||
|
|
||||||
|
### 1.3 核心组件
|
||||||
|
|
||||||
|
| 组件 | 文件 | 功能 |
|
||||||
|
|------|------|------|
|
||||||
|
| AIAgent | `run_agent.py` | 核心对话循环，同步编排引擎 |
|
||||||
|
| HermesCLI | `cli.py` | 交互式终端 UI |
|
||||||
|
| Gateway | `gateway/run.py` | 消息平台网关 |
|
||||||
|
| Tool Registry | `tools/registry.py` | 61 个注册工具，52 个工具集 |
|
||||||
|
| SessionDB | `hermes_state.py` | SQLite + FTS5 全文本搜索 |
|
||||||
|
| Prompt Builder | `agent/prompt_builder.py` | 系统提示组装 |
|
||||||
|
| Skill Manager | `agent/skill_commands.py` | 技能生命周期管理 |
|
||||||
|
|
||||||
|
### 1.4 Agent 循环（核心执行流程）
|
||||||
|
|
||||||
|
```
|
||||||
|
1. 接收输入 ── CLI / gateway / cron / ACP / web
|
||||||
|
2. 构建系统提示 ── persona + memory + skills + tools（会话期间仅一次）
|
||||||
|
3. 解析 Provider ── 选择哪个 API key + endpoint
|
||||||
|
4. 调用模型 ── 支持 4 种 API 模式：
|
||||||
|
chat_completions | codex_responses | anthropic_messages | bedrock_converse
|
||||||
|
5. 解析响应：
|
||||||
|
├─ 存在 tool_calls → 分发到 registry → 追加结果 → 回到步骤 4
|
||||||
|
└─ 否则 → 最终回复 → 展示 → 持久化 → 完成
|
||||||
|
6. 持久化 ── SQLite SessionDB（WAL 模式 + FTS5 索引）
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 二、Harness 的定义与作用
|
||||||
|
|
||||||
|
### 2.1 什么是 Harness？
|
||||||
|
|
||||||
|
Harness 是围绕模型的基础设施层，它将 LLM 转化为**可控的、可审计的、可投入生产使用的智能体**。具体包括：
|
||||||
|
|
||||||
|
| Harness 职责 | Hermes 实现 |
|
||||||
|
|-------------|------------|
|
||||||
|
| **工具中介** (Tool Mediation) | 61 个内置工具 + 动态 MCP 集成 |
|
||||||
|
| **上下文管理** (Context Management) | 三层记忆 + FTS5 检索 + 上下文压缩 |
|
||||||
|
| **委托分发** (Delegation) | 最多 3 个并发子 Agent |
|
||||||
|
| **安全控制** (Safety Control) | 四层防护：Tirith 扫描 / Regex 检测 / LLM 风险评级 / 审批范围 |
|
||||||
|
| **编排调度** (Orchestration) | AIAgent 单一类服务所有入口 |
|
||||||
|
|
||||||
|
### 2.2 五大子系统
|
||||||
|
|
||||||
|
```
|
||||||
|
Central Orchestration Core
|
||||||
|
│
|
||||||
|
┌────┼────┬────┬────┐
|
||||||
|
▼ ▼ ▼ ▼ ▼
|
||||||
|
┌────┐┌────┐┌────┐┌────┐┌──────┐
|
||||||
|
│Skill││Memory│ │Tool│ │Gateway││Learning│
|
||||||
|
│System││System│ │Eco-│ │Layer │ │ Loop │
|
||||||
|
│ │ │ │ │system│ │ │ │ │
|
||||||
|
└────┘└────┘└────┘└────┘└──────┘
|
||||||
|
```
|
||||||
|
|
||||||
|
### 2.3 从 Harness 进化到 Hermes 的五层映射
|
||||||
|
|
||||||
|
| Harness 层 | → | Hermes 进化 |
|
||||||
|
|-----------|---|------------|
|
||||||
|
| 指令层 | → | **技能系统**：静态提示模板 → 动态可进化技能 |
|
||||||
|
| 约束层 | → | **工具权限**：刚性执行边界 → 粒度化权限模型 |
|
||||||
|
| 反馈层 | → | **学习循环**：Harness 将反馈当日志 → Hermes 闭合循环 |
|
||||||
|
| 记忆层 | → | **三层记忆**：临时上下文 → Session/Persistent/Skill 三层结构 |
|
||||||
|
| 编排层 | → | **子 Agent 委托**：单线程 → 最多 3 个并发子 Agent |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 三、创新点（核心差异化）
|
||||||
|
|
||||||
|
### 3.1 学习循环飞轮（最核心创新）
|
||||||
|
|
||||||
|
Hermes 区别于其他 Agent 框架的根本在于**五步学习循环**，形成自我强化飞轮：
|
||||||
|
|
||||||
|
```
|
||||||
|
┌─────────────┐
|
||||||
|
│ 1. 记忆管理 │ ── 评估对话，筛选值得保留的信息
|
||||||
|
└──────┬──────┘
|
||||||
|
▼
|
||||||
|
┌─────────────┐
|
||||||
|
│ 2. 技能创建 │ ── 重复模式 → 自动蒸馏为新 Skill
|
||||||
|
└──────┬──────┘
|
||||||
|
▼
|
||||||
|
┌─────────────┐
|
||||||
|
│ 3. 技能自改进│ ── 达尔文压力：表现好的技能存活并传播
|
||||||
|
└──────┬──────┘
|
||||||
|
▼
|
||||||
|
┌─────────────┐
|
||||||
|
│ 4. FTS5 召回│ ── 全量历史语义检索，不只依赖当前上下文
|
||||||
|
└──────┬──────┘
|
||||||
|
▼
|
||||||
|
┌─────────────┐
|
||||||
|
│ 5. 用户建模 │ ── 通过 Honcho 构建用户画像（风格/专业/偏好）
|
||||||
|
└──────┬──────┘
|
||||||
|
│
|
||||||
|
└────── "更好记忆 → 更好技能 → 更好结果 → 更丰富反馈 → 更精确用户模型 → 更相关记忆"飞轮闭环
|
||||||
|
```
|
||||||
|
|
||||||
|
**关键**：Agent 通过 `skill_manage` 工具自己编写 Skills，自己编辑 MEMORY.md——不是人类在改代码，而是 Agent 在自我进化。
|
||||||
|
|
||||||
|
### 3.2 三层记忆架构（类人认知）
|
||||||
|
|
||||||
|
| 层级 | 类型 | 内容 | 存储 | 回答问题 |
|
||||||
|
|------|------|------|------|---------|
|
||||||
|
| Session Memory | 情景记忆 | 单次对话全内容、工具调用结果、推理步骤 | SQLite | "这次对话发生了什么？" |
|
||||||
|
| Persistent Memory | 语义记忆 | 身份、关系、长期知识 | MEMORY.md + USER.md（纯文本） | "我是谁？用户是谁？" |
|
||||||
|
| Skill Memory | 程序记忆 | 如何执行任务的步骤 | `~/.hermes/skills/` 的 Markdown | "我怎么做这件事？" |
|
||||||
|
|
||||||
|
这三重结构**直接对应人类认知架构**（情景/语义/程序记忆），是有意为之的设计哲学，而非偶然。
|
||||||
|
|
||||||
|
### 3.3 技能系统（Skills as Runbooks）
|
||||||
|
|
||||||
|
Skills 不是代码，也不是配置，而是**Agent 可读取和增长的 Markdown 运行手册**：
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
---
|
||||||
|
name: article-summarizer
|
||||||
|
description: 以结构化格式总结文章
|
||||||
|
triggers:
|
||||||
|
- summarize
|
||||||
|
- tl;dr
|
||||||
|
tools:
|
||||||
|
- web_search
|
||||||
|
- web_scraper
|
||||||
|
- file_write
|
||||||
|
---
|
||||||
|
|
||||||
|
# Article Summarizer
|
||||||
|
|
||||||
|
你是一个善于提炼文章为清晰结构化摘要的专家。
|
||||||
|
|
||||||
|
## Instructions
|
||||||
|
1. 使用 web_search 或 web_scraper 获取文章内容
|
||||||
|
2. 识别核心论点、支撑论据和结论
|
||||||
|
3. 格式化摘要为：
|
||||||
|
- **论点**：一句话核心论点
|
||||||
|
- **关键点**：3-5 个要点
|
||||||
|
- **结论**：影响和收获
|
||||||
|
4. 如有需要保存摘要
|
||||||
|
```
|
||||||
|
|
||||||
|
**三种来源**：
|
||||||
|
1. **内置技能（40+）**：开箱即用
|
||||||
|
2. **Agent 自创技能**：重复模式 → 自动蒸馏 → 存放本地 → 可继续改进
|
||||||
|
3. **社区 Skills Hub**：遵循 agentskills.io 标准，可分享安装
|
||||||
|
|
||||||
|
### 3.4 渐进式加载（Progressive Disclosure）
|
||||||
|
|
||||||
|
Hermes 不一次性加载所有技能、记忆和工具文档，而是分层加载：
|
||||||
|
|
||||||
|
| 层级 | 内容 | 时机 |
|
||||||
|
|------|------|------|
|
||||||
|
| Level 0 | Skills 索引（名称+描述） | 始终在系统提示中 |
|
||||||
|
| Level 1 | 实际技能内容 | Agent 真正需要时才注入 |
|
||||||
|
| Level 2 | 引用的外部文件 | 技能自己请求时才加载 |
|
||||||
|
|
||||||
|
这就是为什么 Hermes 可以携带 47 个工具和数十个技能，而不会超出上下文限制。
|
||||||
|
|
||||||
|
### 3.5 平台无关核心（One Agent, Many Surfaces）
|
||||||
|
|
||||||
|
单个 `AIAgent` 类服务所有入口，平台差异只存在于薄薄的适配层：
|
||||||
|
|
||||||
|
| 入口 | 说明 |
|
||||||
|
|------|------|
|
||||||
|
| CLI / TUI | 交互式终端 |
|
||||||
|
| Gateway | 20 个消息平台（Telegram/Discord/Slack/WhatsApp/飞书/微信等） |
|
||||||
|
| ACP | VS Code / Zed / JetBrains IDE 集成 |
|
||||||
|
| Cron | 定时任务（JSON 配置，支持绑定技能） |
|
||||||
|
| Batch Runner | 批量轨迹生成（训练数据管道） |
|
||||||
|
| Web UI | 网页界面 |
|
||||||
|
| API Server | REST API |
|
||||||
|
|
||||||
|
跨平台对话连续性：用户可以在 Telegram 开始对话，切换到 Discord 继续，全程共享同一上下文。
|
||||||
|
|
||||||
|
### 3.6 自注册模式（Self-Registration）
|
||||||
|
|
||||||
|
工具和插件在**导入时**通过 `registry.register(...)` 自注册，而不是维护中心列表：
|
||||||
|
- 新增工具 = 新增一个 `.py` 文件，无需修改其他代码
|
||||||
|
- MCP 服务器即插即用
|
||||||
|
- 插件通过 `~/.hermes/plugins/` 自动发现
|
||||||
|
|
||||||
|
### 3.7 提示缓存友好设计（Prompt Stability）
|
||||||
|
|
||||||
|
系统提示在会话启动时组装，**会话期间不改变**。原因：
|
||||||
|
- Anthropic / OpenAI 的提示缓存要求稳定前缀才能命中
|
||||||
|
- 会话中改变工具集、重新加载记忆会破坏缓存，成本可能增加 **10 倍**
|
||||||
|
- 新记忆在磁盘写入，但系统提示不变——下次会话生效
|
||||||
|
|
||||||
|
### 3.8 四层安全防护
|
||||||
|
|
||||||
|
```
|
||||||
|
第1层：Tirith（Rust 外部扫描器）
|
||||||
|
└─ 同形异义词 URL、终端注入（ANSI 转义隐藏命令）
|
||||||
|
|
||||||
|
第2层：Regex 危险命令检测
|
||||||
|
└─ 归一化后检测（忽略大小写/空格），防止 RM -RF 绕过
|
||||||
|
|
||||||
|
第3层：Smart Approval（LLM 风险评级）
|
||||||
|
└─ 低风险自动批准，中/高风险需人工确认
|
||||||
|
|
||||||
|
第4层：Approval Scopes（信任累积）
|
||||||
|
└─ Once / Session / Permanent 三级，逐步建立信任
|
||||||
|
```
|
||||||
|
|
||||||
|
### 3.9 执行环境抽象
|
||||||
|
|
||||||
|
同一工具可在不同执行环境中运行，Agent 本身无感知：
|
||||||
|
|
||||||
|
| 环境 | 用途 | 隔离级别 |
|
||||||
|
|------|------|---------|
|
||||||
|
| local | 开发笔记本，最快，零隔离 | 无 |
|
||||||
|
| docker | 共享开发机，每个会话一个容器 | 容器级 |
|
||||||
|
| ssh | 远程 VM | VM 级 |
|
||||||
|
| daytona / modal | Serverless 沙箱，按需启动 | 强隔离 |
|
||||||
|
| singularity | HPC 集群 | 集群级 |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 四、设计原则汇总
|
||||||
|
|
||||||
|
| 原则 | 实践 |
|
||||||
|
|------|------|
|
||||||
|
| **提示稳定性** | 系统提示会话期间不变，不破坏缓存 |
|
||||||
|
| **可观察执行** | 每个工具调用通过 callbacks 对用户可见 |
|
||||||
|
| **可中断** | API 调用和工具执行可在中途取消 |
|
||||||
|
| **平台无关核心** | 一个 AIAgent 服务所有入口，平台差异在适配层 |
|
||||||
|
| **松耦合** | MCP、插件、记忆提供者使用注册模式，不硬依赖 |
|
||||||
|
| **Profile 隔离** | 每个 profile（`-p <name>`）拥有独立 HERMES_HOME、配置、记忆、会话和 Gateway PID |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 五、技术规格速览
|
||||||
|
|
||||||
|
| 指标 | 数值 |
|
||||||
|
|------|------|
|
||||||
|
| GitHub Stars | 47K+（42天内） |
|
||||||
|
| AIAgent 代码行数 | ~13,700 行 |
|
||||||
|
| HermesCLI 代码行数 | ~11,500 行 |
|
||||||
|
| GatewayRunner 代码行数 | ~12,200 行 |
|
||||||
|
| 内置工具数 | 61 个 |
|
||||||
|
| 工具集数 | 52 个 |
|
||||||
|
| 消息平台适配器 | 20 个 |
|
||||||
|
| 支持 Provider | 18+（OpenRouter/OpenAI/Anthropic/Ollama 等） |
|
||||||
|
| 记忆存储 | SQLite（WAL+FTS5）|
|
||||||
|
| 技能存储 | `~/.hermes/skills/`（Markdown + YAML frontmatter）|
|
||||||
|
| MCP 集成 | 支持，可连接 6,000+ 外部应用 |
|
||||||
|
| 并发子 Agent | 最多 3 个 |
|
||||||
|
| 测试覆盖 | 3,000+ 测试用例 |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 六、与其他框架的对比
|
||||||
|
|
||||||
|
| 维度 | **Hermes Agent** | OpenClaw | Claude Code |
|
||||||
|
|------|-----------------|----------|-------------|
|
||||||
|
| 架构哲学 | 自我进化 + 记忆连续性 | 模块化 + 可组合性 | Anthropic 生态深度集成 |
|
||||||
|
| 记忆模型 | 三层（Session/Persistent/Skill）+ Honcho 用户建模 | 可配置记忆后端，无结构化分层 | Session 级上下文 + CLAUDE.md |
|
||||||
|
| 技能系统 | 最成熟（内置+自创+社区），支持自动蒸馏 | 插件系统，无自动技能蒸馏 | 紧耦合生态，无社区分享 |
|
||||||
|
| 工具生态 | 40+ 内置 + 6,000+ MCP | 可比内置规模，MCP 较小 | 主要终端+文件系统，MCP 较新 |
|
||||||
|
| 多平台 | **14 平台 + 跨平台连续性** | 支持但连续性较弱 | 主要 CLI，网页访问通过 API |
|
||||||
|
| 自我改进 | **飞轮学习循环**，真正的自动进化 | 实验性功能，未生产就绪 | 依赖 CLAUDE.md 手工更新 |
|
||||||
|
| 最适合场景 | 需要随时间变强的 Agent，跨平台使用 | 追求模块化定制的用户 | Anthropic 生态深度用户 |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 七、关键洞察总结
|
||||||
|
|
||||||
|
> **Hermes 的核心创新不是某一个功能，而是一个范式**：将 Agent 视为一个认知系统，而非一个 API 包装器。
|
||||||
|
|
||||||
|
1. **Harness 是控制层**：模型是引擎，Harness 是控制系统。没有 Harness 的 LLM 生产部署是危险的。
|
||||||
|
2. **记忆即知识**：三层记忆架构（情景/语义/程序）使 Agent 拥有真实的跨会话连续性。
|
||||||
|
3. **技能即进化**：Agent 自己编写 Skills，不是人类工程师在维护——这是真正的自我改进。
|
||||||
|
4. **平台无关是工程纪律**：一个核心，多个表面，所有平台差异在适配层消失。
|
||||||
|
5. **提示缓存是经济问题**：Mid-session 的"聪明"改动可能让你的 API 成本增加 10 倍。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
*整理自：Hermes Agent 官方架构文档（hermes-agent.nousresearch.com）、PyShine Orange Book、dev.to 技术深度解析、ArXiv 研究论文 "Architectural Design Decisions in AI Agent Harnesses"（2604.18071v1）等多个来源。*
|
||||||
282
Openclaw-Herems/03-OpenClaw-Architecture.md
Normal file
282
Openclaw-Herems/03-OpenClaw-Architecture.md
Normal file
@@ -0,0 +1,282 @@
|
|||||||
|
# OpenClaw 架构与创新分析
|
||||||
|
|
||||||
|
> 来源: OpenClaw 官方文档 | https://docs.openclaw.ai
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 一、总体架构
|
||||||
|
|
||||||
|
OpenClaw 采用 **Gateway 中心化架构**，是一个多智能体（Multi-Agent）运行框架。
|
||||||
|
|
||||||
|
### 核心组件
|
||||||
|
|
||||||
|
```
|
||||||
|
┌─────────────────────────────────────────────────────┐
|
||||||
|
│ Gateway │
|
||||||
|
│ (WebSocket + HTTP API + OpenAI兼容端点) │
|
||||||
|
├─────────────────────────────────────────────────────┤
|
||||||
|
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
|
||||||
|
│ │ Agent 1 │ │ Agent 2 │ │ Agent N │ │
|
||||||
|
│ │ (main) │ │ │ │ │ │
|
||||||
|
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ │
|
||||||
|
│ │ │ │ │
|
||||||
|
│ ┌────┴─────────────┴─────────────┴────┐ │
|
||||||
|
│ │ Workspace + Sessions │ │
|
||||||
|
│ │ AGENTS.md / SOUL.md / USER.md │ │
|
||||||
|
│ │ Skills / Memory / Tools │ │
|
||||||
|
│ └───────────────────────────────────────┘ │
|
||||||
|
├─────────────────────────────────────────────────────┤
|
||||||
|
│ Channels (飞书/Discord/Telegram等) │
|
||||||
|
└─────────────────────────────────────────────────────┘
|
||||||
|
```
|
||||||
|
|
||||||
|
### Gateway 核心特性
|
||||||
|
|
||||||
|
- **单一进程**：常驻运行，负责路由、控制平面、频道连接
|
||||||
|
- **多协议端口**：WebSocket 控制/RPC + HTTP API + OpenAI 兼容端点
|
||||||
|
- **默认绑定 loopback**：安全优先
|
||||||
|
- **热重载支持**：hybrid 模式（hot-apply when safe, restart when required）
|
||||||
|
|
||||||
|
### OpenAI 兼容端点
|
||||||
|
|
||||||
|
```
|
||||||
|
GET /v1/models # 返回 openclaw/openclaw/default
|
||||||
|
POST /v1/chat/completions # 标准聊天补全
|
||||||
|
POST /v1/embeddings # 向量嵌入
|
||||||
|
POST /v1/responses # Agent 原生响应格式
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 二、Agent 架构
|
||||||
|
|
||||||
|
### 什么是 Agent
|
||||||
|
|
||||||
|
一个 **Agent** 是完整的人设范围，包含：
|
||||||
|
|
||||||
|
- **Workspace**：文件、AGENTS.md/SOUL.md/USER.md、本地笔记、规则
|
||||||
|
- **State Directory (agentDir)**：`~/.openclaw/agents/<agentId>/agent`，存放 auth profiles、model registry、per-agent config
|
||||||
|
- **Session Store**：聊天历史 + 路由状态
|
||||||
|
|
||||||
|
### Workspace 文件结构
|
||||||
|
|
||||||
|
```
|
||||||
|
~/.openclaw/workspace/
|
||||||
|
├── AGENTS.md # 操作指令
|
||||||
|
├── SOUL.md # 人设和语气
|
||||||
|
├── USER.md # 用户信息
|
||||||
|
├── IDENTITY.md # 名称、emoji
|
||||||
|
├── TOOLS.md # 本地工具约定
|
||||||
|
├── HEARTBEAT.md # 心跳检查清单
|
||||||
|
├── MEMORY.md # 长期记忆（仅主会话加载）
|
||||||
|
├── memory/
|
||||||
|
│ └── YYYY-MM-DD.md # 每日记忆日志
|
||||||
|
└── skills/ # 工作区技能（最高优先级）
|
||||||
|
```
|
||||||
|
|
||||||
|
### 单 Agent vs 多 Agent
|
||||||
|
|
||||||
|
**单 Agent 模式（默认）**：
|
||||||
|
- `agentId` 默认为 `main`
|
||||||
|
- Workspace: `~/.openclaw/workspace`
|
||||||
|
- State: `~/.openclaw/agents/main/agent`
|
||||||
|
|
||||||
|
**多 Agent 模式**：
|
||||||
|
- 每个 agent 完全隔离（独立 workspace、auth、sessions）
|
||||||
|
- 通过 **Binding** 系统路由消息
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 三、Binding 系统（消息路由）
|
||||||
|
|
||||||
|
Bindings 是**确定性**的，**最特定匹配优先**：
|
||||||
|
|
||||||
|
| 优先级 | 匹配类型 |
|
||||||
|
|--------|----------|
|
||||||
|
| 1 | peer match（精确 DM/群组 ID） |
|
||||||
|
| 2 | parentPeer match（线程继承） |
|
||||||
|
| 3 | guildId + roles（Discord 角色路由） |
|
||||||
|
| 4 | guildId |
|
||||||
|
| 5 | teamId（Slack） |
|
||||||
|
| 6 | accountId match for channel |
|
||||||
|
| 7 | Channel-level match |
|
||||||
|
| 8 | Default agent |
|
||||||
|
|
||||||
|
### Binding 示例
|
||||||
|
|
||||||
|
```json5
|
||||||
|
{
|
||||||
|
bindings: [
|
||||||
|
{ agentId: "alex", match: { channel: "whatsapp", peer: { kind: "direct", id: "+15551230001" } } },
|
||||||
|
{ agentId: "mia", match: { channel: "telegram" } },
|
||||||
|
]
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 四、Skills 系统
|
||||||
|
|
||||||
|
### 加载优先级
|
||||||
|
|
||||||
|
1. **Workspace skills**（`workspace/skills/`）— 最高优先级
|
||||||
|
2. **Agent skills**（`~/.openclaw/agents/<agentId>/skills/`）
|
||||||
|
3. **Managed skills**（`~/.openclaw/skills/`）
|
||||||
|
4. **Bundled skills**
|
||||||
|
|
||||||
|
### Skill 结构
|
||||||
|
|
||||||
|
每个 Skill 是一个文件夹，包含：
|
||||||
|
- `SKILL.md` — 描述和指令
|
||||||
|
- 工具脚本/CLI
|
||||||
|
|
||||||
|
### 共享技能配置
|
||||||
|
|
||||||
|
```json5
|
||||||
|
{
|
||||||
|
agents: {
|
||||||
|
defaults: {
|
||||||
|
skills: ["skill-a", "skill-b"] // 共享基线
|
||||||
|
},
|
||||||
|
list: [
|
||||||
|
{
|
||||||
|
id: "main",
|
||||||
|
skills: ["skill-c", "skill-d"] // 替换基线
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 五、记忆系统 (Memory)
|
||||||
|
|
||||||
|
### QMD 后端
|
||||||
|
|
||||||
|
OpenClaw 使用 **QMD** 作为记忆后端，支持：
|
||||||
|
- 跨会话语义搜索
|
||||||
|
- 自动记忆刷新
|
||||||
|
- 额外集合支持
|
||||||
|
|
||||||
|
### 记忆文件
|
||||||
|
|
||||||
|
- **MEMORY.md**：精选长期记忆（仅主私有会话加载）
|
||||||
|
- **memory/YYYY-MM-DD.md**：每日记忆日志
|
||||||
|
|
||||||
|
### 跨 Agent 记忆共享
|
||||||
|
|
||||||
|
```json5
|
||||||
|
{
|
||||||
|
agents: {
|
||||||
|
defaults: {
|
||||||
|
memorySearch: {
|
||||||
|
qmd: {
|
||||||
|
extraCollections: [{ path: "~/agents/family/sessions", name: "family-sessions" }]
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 六、工具系统 (Tools)
|
||||||
|
|
||||||
|
### 内置工具
|
||||||
|
|
||||||
|
- `read` / `write` / `edit` — 文件操作
|
||||||
|
- `exec` — 执行 shell 命令
|
||||||
|
- `sessions_list` / `sessions_history` / `sessions_send` — 会话管理
|
||||||
|
- `subagents` — 子 agent 管理
|
||||||
|
- `gateway` / `config.*` — 配置管理
|
||||||
|
- `web_search` / `web_fetch` — 网页搜索
|
||||||
|
- `image_generate` — 图片生成
|
||||||
|
|
||||||
|
### 工具策略（Per-Agent）
|
||||||
|
|
||||||
|
```json5
|
||||||
|
{
|
||||||
|
agents: {
|
||||||
|
list: [{
|
||||||
|
id: "family",
|
||||||
|
tools: {
|
||||||
|
allow: ["exec", "read", "sessions_list"],
|
||||||
|
deny: ["write", "edit", "browser"]
|
||||||
|
}
|
||||||
|
}]
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 七、安全模型
|
||||||
|
|
||||||
|
### 认证方式
|
||||||
|
|
||||||
|
- **Token/Password**：共享密钥认证
|
||||||
|
- **Trusted-Proxy**：反向代理后的信任模式
|
||||||
|
- **OAuth**：第三方登录
|
||||||
|
|
||||||
|
### 安全特性
|
||||||
|
|
||||||
|
1. **默认 loopback 绑定**：不允许外部直接访问
|
||||||
|
2. **Tool Policy**：每个 agent 可配置 allow/deny 列表
|
||||||
|
3. **Sandboxing**：可配置工作区沙盒隔离
|
||||||
|
4. **Session 隔离**：不同 agent 的 sessions 完全隔离
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 八、创新点总结
|
||||||
|
|
||||||
|
### 1. Binding 驱动的多 Agent 路由
|
||||||
|
|
||||||
|
不同于简单的角色分配，OpenClaw 的 Binding 系统支持：
|
||||||
|
- 精确的 peer/guild/role 匹配
|
||||||
|
- 最特定匹配优先的确定性路由
|
||||||
|
- 跨渠道的统一管理
|
||||||
|
|
||||||
|
### 2. Workspace 隔离 + 灵活共享
|
||||||
|
|
||||||
|
- 每个 agent 有独立 workspace
|
||||||
|
- 通过 extraCollections 实现受控的记忆共享
|
||||||
|
- Skills 支持层级覆盖
|
||||||
|
|
||||||
|
### 3. OpenAI 兼容 API
|
||||||
|
|
||||||
|
原生支持 `/v1/models`、`/v1/chat/completions`、`/v1/embeddings`，便于：
|
||||||
|
- 集成到 LobeChat、Open WebUI 等
|
||||||
|
- RAG 和记忆 pipelines
|
||||||
|
- Agent 原生客户端
|
||||||
|
|
||||||
|
### 4. 分布式记忆（QMD）
|
||||||
|
|
||||||
|
- 跨会话语义搜索
|
||||||
|
- 自动压缩和刷新
|
||||||
|
- 可配置的额外集合
|
||||||
|
|
||||||
|
### 5. 灵活的 Tool Policy
|
||||||
|
|
||||||
|
- 每个 agent 独立配置
|
||||||
|
- 细粒度 allow/deny 控制
|
||||||
|
- 沙盒模式可选
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 九、与 Hermes 的核心区别
|
||||||
|
|
||||||
|
| 维度 | OpenClaw | Hermes |
|
||||||
|
|------|-----------|--------|
|
||||||
|
| **架构** | Gateway 中心化 | AIAgent 核心循环 |
|
||||||
|
| **记忆** | 手动编辑 markdown / QMD 自动搜索 | 全自动压缩+提炼+用户画像 |
|
||||||
|
| **技能** | 手动安装市场技能 | 自动生成 SK.md |
|
||||||
|
| **路由** | Binding 系统 | 无（单 agent） |
|
||||||
|
| **安全** | Tool Policy + 审批 | 沙盒+零遥测 |
|
||||||
|
| **定位** | 企业级/可审计 | 个人/长气AI朋友 |
|
||||||
|
| **设计哲学** | 你告诉它做什么 | 它学会你想做什么 |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
*总结时间: 2026-05-06*
|
||||||
509
Openclaw-Herems/04-Comparison.md
Normal file
509
Openclaw-Herems/04-Comparison.md
Normal file
@@ -0,0 +1,509 @@
|
|||||||
|
# OpenClaw vs Hermes 架构深度对比分析
|
||||||
|
|
||||||
|
> 资料来源：视频总结、官方文档、技术深度解析
|
||||||
|
> 整理时间：2026-05-06
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 一、核心理念对比
|
||||||
|
|
||||||
|
| 维度 | OpenClaw | Hermes |
|
||||||
|
|------|----------|--------|
|
||||||
|
| **定位** | 企业级多智能体框架 | 自主进化的个人 AI 伙伴 |
|
||||||
|
| **核心口号** | 模块化 + 可组合性 | The agent that grows with you |
|
||||||
|
| **设计哲学** | 你告诉它做什么 | 它学会你自己想做什么 |
|
||||||
|
| **适用人群** | 需要精细控制的开发者/企业 | 想要省心、越用越聪明的个人用户 |
|
||||||
|
|
||||||
|
**一句话本质差异**：
|
||||||
|
> OpenClaw 是一个**可控的 Agent 运行时**，Hermes 是一个**会自我进化的认知系统**。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 二、架构对比
|
||||||
|
|
||||||
|
### 2.1 OpenClaw：Gateway 中心化架构
|
||||||
|
|
||||||
|
```
|
||||||
|
┌─────────────────────────────────────────────────────┐
|
||||||
|
│ Gateway │
|
||||||
|
│ (WebSocket + HTTP API + OpenAI兼容) │
|
||||||
|
├─────────────────────────────────────────────────────┤
|
||||||
|
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
|
||||||
|
│ │ Agent 1 │ │ Agent 2 │ │ Agent N │ │
|
||||||
|
│ │ (main) │ │ │ │ │ │
|
||||||
|
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ │
|
||||||
|
│ │ │ │ │
|
||||||
|
│ ┌────┴─────────────┴─────────────┴────┐ │
|
||||||
|
│ │ Workspace + Sessions │ │
|
||||||
|
│ │ AGENTS.md / SOUL.md / USER.md │ │
|
||||||
|
│ │ Skills / Memory / Tools │ │
|
||||||
|
│ └───────────────────────────────────────┘ │
|
||||||
|
├─────────────────────────────────────────────────────┤
|
||||||
|
│ Channels (飞书/Discord/Telegram等) │
|
||||||
|
└─────────────────────────────────────────────────────┘
|
||||||
|
```
|
||||||
|
|
||||||
|
**特点**：
|
||||||
|
- 单一 Gateway 进程常驻运行
|
||||||
|
- 多 Agent 通过 Binding 系统路由
|
||||||
|
- Workspace 文件驱动人设和行为
|
||||||
|
- 工具通过 Skills 系统扩展
|
||||||
|
|
||||||
|
### 2.2 Hermes：AIAgent 核心循环架构
|
||||||
|
|
||||||
|
```
|
||||||
|
┌────────────────────────────────────────────────────────────┐
|
||||||
|
│ ENTRY POINTS │
|
||||||
|
│ CLI / TUI / Gateway (14+平台) / Cron / Batch / ACP │
|
||||||
|
└─────────────────────┬──────────────────────────────────────┘
|
||||||
|
│ 每个入口构建一个 AIAgent
|
||||||
|
▼
|
||||||
|
┌────────────────────────────────────────────────────────────┐
|
||||||
|
│ AIAgent (核心循环 ~13,700 行) │
|
||||||
|
│ build_system_prompt → call model → dispatch tools → loop │
|
||||||
|
└──────┬─────────────┬──────────────┬───────────┬───────────┘
|
||||||
|
│ │ │ │
|
||||||
|
▼ ▼ ▼ ▼
|
||||||
|
┌──────────┐ ┌──────────┐ ┌────────────┐ ┌─────────────┐
|
||||||
|
│ Tools │ │ Skills │ │ Memory │ │ Providers │
|
||||||
|
│ Registry │ │ Loader │ │ Manager │ │ (model API) │
|
||||||
|
└──────────┘ └──────────┘ └────────────┘ └─────────────┘
|
||||||
|
│
|
||||||
|
┌────────────────────────────────────────────────┘
|
||||||
|
▼
|
||||||
|
┌────────────────────────────────────────────────────────────┐
|
||||||
|
│ Execution Environments: local / Docker / SSH / Modal │
|
||||||
|
└────────────────────────────────────────────────────────────┘
|
||||||
|
```
|
||||||
|
|
||||||
|
**特点**：
|
||||||
|
- 单一 AIAgent 类服务所有入口
|
||||||
|
- Harness 工程框架提供控制层
|
||||||
|
- 五步学习循环驱动自我进化
|
||||||
|
- 平台差异在薄适配层消失
|
||||||
|
|
||||||
|
### 2.3 架构哲学差异
|
||||||
|
|
||||||
|
| 方面 | OpenClaw | Hermes |
|
||||||
|
|------|----------|--------|
|
||||||
|
| **核心抽象** | Gateway（路由中枢） | AIAgent（认知引擎） |
|
||||||
|
| **控制方式** | 显式配置 + Binding 路由 | Harness 控制层 + 自我学习 |
|
||||||
|
| **多 Agent** | 支持，通过 Binding 系统 | 支持，最多 3 个并发子 Agent |
|
||||||
|
| **平台差异** | Channel 适配器 | 薄适配层，跨平台上下文连续 |
|
||||||
|
| **扩展方式** | Skills 系统（手动安装） | 自注册 + MCP 即插即用 |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 三、记忆系统对比
|
||||||
|
|
||||||
|
### 3.1 OpenClaw：文件驱动 + QMD 搜索
|
||||||
|
|
||||||
|
**存储方式**：
|
||||||
|
- `MEMORY.md`：精选长期记忆（手动编辑）
|
||||||
|
- `memory/YYYY-MM-DD.md`：每日记忆日志
|
||||||
|
- `AGENTS.md`/`SOUL.md`/`USER.md`：人设和上下文
|
||||||
|
|
||||||
|
**记忆特点**：
|
||||||
|
- 用户手动维护，需要主动更新
|
||||||
|
- QMD 后端支持跨会话语义搜索
|
||||||
|
- 仅主会话加载 MEMORY.md（隐私保护）
|
||||||
|
|
||||||
|
**记忆流程**：
|
||||||
|
```
|
||||||
|
用户编辑文件 → 重启会话 → 记忆生效
|
||||||
|
```
|
||||||
|
|
||||||
|
### 3.2 Hermes：三层认知架构 + 自动压缩
|
||||||
|
|
||||||
|
**三层记忆**：
|
||||||
|
|
||||||
|
| 层级 | 类型 | 内容 | 存储 | 作用 |
|
||||||
|
|------|------|------|------|------|
|
||||||
|
| Session Memory | 情景记忆 | 单次对话全内容 | SQLite | "这次对话发生了什么？" |
|
||||||
|
| Persistent Memory | 语义记忆 | 身份、关系、长期知识 | MEMORY.md + USER.md | "我是谁？用户是谁？" |
|
||||||
|
| Skill Memory | 程序记忆 | 如何执行任务的步骤 | `~/.hermes/skills/` | "我怎么做这件事？" |
|
||||||
|
|
||||||
|
**Honcho 用户画像**：
|
||||||
|
- 渐进式建立用户偏好
|
||||||
|
- 在多次交互中拼凑出风格、专业、偏好
|
||||||
|
- 不用每次都重新解释
|
||||||
|
|
||||||
|
**自动压缩**：
|
||||||
|
- LLM Summarization 自动压缩历史对话
|
||||||
|
- SQLite + FTS5 全文本检索
|
||||||
|
- 评估对话，筛选值得保留的信息
|
||||||
|
|
||||||
|
### 3.3 记忆系统对比
|
||||||
|
|
||||||
|
| 维度 | OpenClaw | Hermes |
|
||||||
|
|------|----------|--------|
|
||||||
|
| **存储方式** | 纯 Markdown 文件 | SQLite + FTS5 + Markdown |
|
||||||
|
| **更新方式** | 手动编辑文件 | 自动压缩 + LLM 提炼 |
|
||||||
|
| **用户画像** | 无 | Honcho 渐进建模 |
|
||||||
|
| **检索能力** | QMD 语义搜索 | FTS5 全文本搜索 |
|
||||||
|
| **上下文窗口** | 依赖模型上下文 | 渐进式加载（Level 0/1/2）|
|
||||||
|
|
||||||
|
**核心差异**：
|
||||||
|
> OpenClaw 的记忆是**静态的**，需要用户维护。
|
||||||
|
> Hermes 的记忆是**动态的**，Agent 自己管理。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 四、技能系统对比
|
||||||
|
|
||||||
|
### 4.1 OpenClaw：市场驱动
|
||||||
|
|
||||||
|
**技能来源**：
|
||||||
|
- ClawHub 市场（数千个技能）
|
||||||
|
- Workspace skills（最高优先级）
|
||||||
|
- Agent skills
|
||||||
|
- Managed skills
|
||||||
|
- Bundled skills
|
||||||
|
|
||||||
|
**使用方式**：
|
||||||
|
```json5
|
||||||
|
{
|
||||||
|
agents: {
|
||||||
|
defaults: {
|
||||||
|
skills: ["skill-a", "skill-b"] // 手动配置
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
**特点**：
|
||||||
|
- 需要用户手动安装和配置
|
||||||
|
- 按优先级覆盖（workspace > agent > managed > bundled）
|
||||||
|
- 技能是文件夹 + SK.md 的结构
|
||||||
|
|
||||||
|
### 4.2 Hermes：自动进化
|
||||||
|
|
||||||
|
**技能来源**：
|
||||||
|
1. **内置技能（40+）**：开箱即用
|
||||||
|
2. **Agent 自创技能**：重复模式 → 自动蒸馏
|
||||||
|
3. **社区 Skills Hub**：遵循 agentskills.io 标准
|
||||||
|
|
||||||
|
**自动生成示例**：
|
||||||
|
```yaml
|
||||||
|
---
|
||||||
|
name: article-summarizer
|
||||||
|
description: 以结构化格式总结文章
|
||||||
|
triggers:
|
||||||
|
- summarize
|
||||||
|
- tl;dr
|
||||||
|
tools:
|
||||||
|
- web_search
|
||||||
|
- web_scraper
|
||||||
|
- file_write
|
||||||
|
---
|
||||||
|
|
||||||
|
# Article Summarizer
|
||||||
|
|
||||||
|
你是一个善于提炼文章为清晰结构化摘要的专家。
|
||||||
|
...
|
||||||
|
```
|
||||||
|
|
||||||
|
**进化机制**：
|
||||||
|
- 重复任务 → 自动蒸馏为新 Skill
|
||||||
|
- 表现好的技能存活并传播
|
||||||
|
- 自动更新旧技能让它越跑越顺
|
||||||
|
|
||||||
|
### 4.3 技能系统对比
|
||||||
|
|
||||||
|
| 维度 | OpenClaw | Hermes |
|
||||||
|
|------|----------|--------|
|
||||||
|
| **获取方式** | 手动从市场安装 | 自动生成 + 市场 |
|
||||||
|
| **维护者** | 用户/开发者 | Agent 自己 |
|
||||||
|
| **数量** | 数千个（市场） | 40+ 内置 + 自动生成 |
|
||||||
|
| **进化能力** | 无 | 达尔文压力（优胜劣汰）|
|
||||||
|
| **格式** | SK.md + 工具脚本 | SK.md + YAML frontmatter |
|
||||||
|
| **分享** | ClawHub | agentskills.io |
|
||||||
|
|
||||||
|
**核心差异**：
|
||||||
|
> OpenClaw 技能是**资源**，需要管理和维护。
|
||||||
|
> Hermes 技能是**能力**，会自动生长和进化。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 五、学习循环对比
|
||||||
|
|
||||||
|
### 5.1 OpenClaw：无自动学习
|
||||||
|
|
||||||
|
**当前状态**：
|
||||||
|
- 无内置的自我改进机制
|
||||||
|
- 实验性功能，未生产就绪
|
||||||
|
- 依赖用户手动更新 MEMORY.md
|
||||||
|
|
||||||
|
**用户流程**：
|
||||||
|
```
|
||||||
|
发现问题 → 思考解决方案 → 编辑文件 → 重启会话
|
||||||
|
```
|
||||||
|
|
||||||
|
### 5.2 Hermes：五步学习飞轮
|
||||||
|
|
||||||
|
```
|
||||||
|
┌─────────────┐
|
||||||
|
│ 1. 记忆管理 │ ── 评估对话，筛选值得保留的信息
|
||||||
|
└──────┬──────┘
|
||||||
|
▼
|
||||||
|
┌─────────────┐
|
||||||
|
│ 2. 技能创建 │ ── 重复模式 → 自动蒸馏为新 Skill
|
||||||
|
└──────┬──────┘
|
||||||
|
▼
|
||||||
|
┌─────────────┐
|
||||||
|
│ 3. 技能自改进│ ── 达尔文压力：表现好的技能存活并传播
|
||||||
|
└──────┬──────┘
|
||||||
|
▼
|
||||||
|
┌─────────────┐
|
||||||
|
│ 4. FTS5 召回│ ── 全量历史语义检索，不只依赖当前上下文
|
||||||
|
└──────┬──────┘
|
||||||
|
▼
|
||||||
|
┌─────────────┐
|
||||||
|
│ 5. 用户建模 │ ── 通过 Honcho 构建用户画像
|
||||||
|
└─────────────┘
|
||||||
|
```
|
||||||
|
|
||||||
|
**飞轮闭环**：
|
||||||
|
```
|
||||||
|
更好记忆 → 更好技能 → 更好结果 → 更丰富反馈 → 更精确用户模型 → 更相关记忆
|
||||||
|
```
|
||||||
|
|
||||||
|
**关键创新**：
|
||||||
|
- Agent 通过 `skill_manage` 工具自己编写 Skills
|
||||||
|
- Agent 自己编辑 MEMORY.md
|
||||||
|
- 不是人类在改代码，而是 Agent 在自我进化
|
||||||
|
|
||||||
|
### 5.3 学习能力对比
|
||||||
|
|
||||||
|
| 维度 | OpenClaw | Hermes |
|
||||||
|
|------|----------|--------|
|
||||||
|
| **自动学习** | ❌ 无 | ✅ 五步学习飞轮 |
|
||||||
|
| **技能进化** | ❌ 无 | ✅ 达尔文压力 |
|
||||||
|
| **用户建模** | ❌ 无 | ✅ Honcho 画像 |
|
||||||
|
| **反馈闭环** | ❌ 无 | ✅ 闭合循环 |
|
||||||
|
| **进化曲线** | 静态 | 第一周→一个月→三个月 |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 六、安全模型对比
|
||||||
|
|
||||||
|
### 6.1 OpenClaw：多层防护
|
||||||
|
|
||||||
|
**认证方式**：
|
||||||
|
- Token/Password：共享密钥认证
|
||||||
|
- Trusted-Proxy：反向代理信任模式
|
||||||
|
- OAuth：第三方登录
|
||||||
|
|
||||||
|
**安全特性**：
|
||||||
|
1. 默认 loopback 绑定（不允许外部访问）
|
||||||
|
2. Tool Policy（每个 agent 独立 allow/deny）
|
||||||
|
3. DM Ping 验证
|
||||||
|
4. 显示 allow list，每条消息验证
|
||||||
|
5. 敏感操作审批
|
||||||
|
|
||||||
|
**工具策略示例**：
|
||||||
|
```json5
|
||||||
|
{
|
||||||
|
agents: [{
|
||||||
|
id: "family",
|
||||||
|
tools: {
|
||||||
|
allow: ["exec", "read", "sessions_list"],
|
||||||
|
deny: ["write", "edit", "browser"]
|
||||||
|
}
|
||||||
|
}]
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
### 6.2 Hermes：四层防护
|
||||||
|
|
||||||
|
```
|
||||||
|
第1层：Tirith（Rust 外部扫描器）
|
||||||
|
└─ 同形异义词 URL、终端注入（ANSI 转义隐藏命令）
|
||||||
|
|
||||||
|
第2层：Regex 危险命令检测
|
||||||
|
└─ 归一化后检测（忽略大小写/空格），防止 RM -RF 绕过
|
||||||
|
|
||||||
|
第3层：Smart Approval（LLM 风险评级）
|
||||||
|
└─ 低风险自动批准，中/高风险需人工确认
|
||||||
|
|
||||||
|
第4层：Approval Scopes（信任累积）
|
||||||
|
└─ Once / Session / Permanent 三级，逐步建立信任
|
||||||
|
```
|
||||||
|
|
||||||
|
**额外特性**：
|
||||||
|
- 沙盒隔离容器执行（Docker/SSH/Modal）
|
||||||
|
- 零遥测：不收集、不上传数据
|
||||||
|
- 四层防护可独立工作
|
||||||
|
|
||||||
|
### 6.3 安全模型对比
|
||||||
|
|
||||||
|
| 维度 | OpenClaw | Hermes |
|
||||||
|
|------|----------|--------|
|
||||||
|
| **隔离方式** | Workspace 沙盒 + Tool Policy | 容器级隔离（Docker/SSH）|
|
||||||
|
| **危险检测** | Tool Policy + DM Ping | 四层防护（Tirith/Regex/LLM/Scopes）|
|
||||||
|
| **数据收集** | 未明确 | 零遥测 |
|
||||||
|
| **审批粒度** | 显示 allow list | Once/Session/Permanent 三级 |
|
||||||
|
| **默认安全** | loopback 绑定 | 沙盒隔离 |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 七、平台支持对比
|
||||||
|
|
||||||
|
### 7.1 OpenClaw
|
||||||
|
|
||||||
|
**支持的渠道**：
|
||||||
|
- 飞书（Feishu）
|
||||||
|
- Discord
|
||||||
|
- Telegram
|
||||||
|
- 其他主流消息平台
|
||||||
|
|
||||||
|
**跨平台能力**：
|
||||||
|
- 支持多渠道接入
|
||||||
|
- 通过 Binding 系统路由
|
||||||
|
- 但跨平台连续性较弱
|
||||||
|
|
||||||
|
### 7.2 Hermes
|
||||||
|
|
||||||
|
**支持的渠道（14+）**：
|
||||||
|
- CLI / TUI
|
||||||
|
- Telegram / Discord / Slack / WhatsApp
|
||||||
|
- 飞书 / WeChat
|
||||||
|
- VS Code / Zed / JetBrains（ACP）
|
||||||
|
- Web UI / REST API
|
||||||
|
|
||||||
|
**跨平台连续性**：
|
||||||
|
- 单个 AIAgent 服务所有入口
|
||||||
|
- 用户可以在 Telegram 开始，Discord 继续
|
||||||
|
- 全程共享同一上下文
|
||||||
|
|
||||||
|
### 7.3 平台支持对比
|
||||||
|
|
||||||
|
| 维度 | OpenClaw | Hermes |
|
||||||
|
|------|----------|--------|
|
||||||
|
| **渠道数量** | 多个主流渠道 | 14+ 平台 |
|
||||||
|
| **IDE 集成** | 无 | VS Code / Zed / JetBrains |
|
||||||
|
| **跨平台连续性** | 较弱 | 强（共享上下文）|
|
||||||
|
| **定时任务** | Cron/Heartbeat | Cron（JSON 配置 + 技能绑定）|
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 八、执行环境对比
|
||||||
|
|
||||||
|
### 8.1 OpenClaw
|
||||||
|
|
||||||
|
**执行方式**：
|
||||||
|
- 直接 shell 执行
|
||||||
|
- Workspace 沙盒隔离（可选）
|
||||||
|
|
||||||
|
### 8.2 Hermes
|
||||||
|
|
||||||
|
**多种执行环境**：
|
||||||
|
|
||||||
|
| 环境 | 用途 | 隔离级别 |
|
||||||
|
|------|------|---------|
|
||||||
|
| local | 开发笔记本，最快 | 无 |
|
||||||
|
| docker | 共享开发机 | 容器级 |
|
||||||
|
| ssh | 远程 VM | VM 级 |
|
||||||
|
| daytona / modal | Serverless 沙箱 | 强隔离 |
|
||||||
|
| singularity | HPC 集群 | 集群级 |
|
||||||
|
|
||||||
|
**特点**：同一工具可在不同执行环境中运行，Agent 本身无感知。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 九、技术规格对比
|
||||||
|
|
||||||
|
| 指标 | OpenClaw | Hermes |
|
||||||
|
|------|----------|--------|
|
||||||
|
| **GitHub Stars** | 未披露 | 47K+（42天内） |
|
||||||
|
| **核心代码** | 模块化设计 | ~13,700 行 AIAgent |
|
||||||
|
| **内置工具** | 数十个 | 61 个 |
|
||||||
|
| **工具集** | MCP 集成 | 52 个工具集 |
|
||||||
|
| **技能数量** | 数千个市场 | 40+ 内置 + 自动生成 |
|
||||||
|
| **消息平台** | 多个主流 | 14+ 平台 |
|
||||||
|
| **模型支持** | 自定义 + OpenAI 兼容 | 18+ Provider |
|
||||||
|
| **记忆存储** | Markdown + QMD | SQLite（WAL+FTS5）|
|
||||||
|
| **并发子 Agent** | 多 Agent 模式 | 最多 3 个 |
|
||||||
|
| **最低部署成本** | 本地运行 | $5 VPS |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 十、选择指南
|
||||||
|
|
||||||
|
### 10.1 选 OpenClaw 如果：
|
||||||
|
|
||||||
|
- ✅ 企业级部署，需要完整审计和合规
|
||||||
|
- ✅ 需要精细控制每一条指令
|
||||||
|
- ✅ 需要多 Agent 协作和复杂路由
|
||||||
|
- ✅ 追求模块化定制
|
||||||
|
- ✅ 需要飞书/Discord 等渠道集成
|
||||||
|
- ✅ 开发者，有能力维护配置文件
|
||||||
|
|
||||||
|
### 10.2 选 Hermes 如果：
|
||||||
|
|
||||||
|
- ✅ 需要"长气的 AI 朋友"，记忆力超棒
|
||||||
|
- ✅ 预算敏感，想要低成本部署（几十块 ECS）
|
||||||
|
- ✅ 不想折腾配置，希望 Agent 自己学会事情
|
||||||
|
- ✅ 需要跨平台连续性（Telegram→Discord→WeChat）
|
||||||
|
- ✅ 追求自动进化，不想手动维护
|
||||||
|
- ✅ 个人使用，想要越用越聪明
|
||||||
|
|
||||||
|
### 10.3 一句话总结
|
||||||
|
|
||||||
|
> **OpenClaw 是你告诉他做什么，Hermes 是它学会你自己想做什么。**
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 十一、架构启示
|
||||||
|
|
||||||
|
### 11.1 Harness 工程范式
|
||||||
|
|
||||||
|
Hermes 提出的 **Harness Engineering** 代表了 AI 工程的第三范式：
|
||||||
|
|
||||||
|
| 范式 | 核心 | 特点 |
|
||||||
|
|------|------|------|
|
||||||
|
| Prompt Engineering | 优化提示词 | 手工调试，易出错 |
|
||||||
|
| Context Engineering | 管理上下文 | 复杂，仍是被动的 |
|
||||||
|
| **Harness Engineering** | **自我进化的控制基础设施** | 主动学习，持续改进 |
|
||||||
|
|
||||||
|
**核心洞察**：
|
||||||
|
> 模型提供智能，Harness 提供控制。没有 Harness 的 LLM 生产部署就像"把喷气发动机直接连到方向盘上"——有动力但无控制系统。
|
||||||
|
|
||||||
|
### 11.2 OpenClaw 的优势
|
||||||
|
|
||||||
|
尽管 Hermes 在学习能力上领先，OpenClaw 仍有独特价值：
|
||||||
|
|
||||||
|
1. **Gateway 中心化**：更适合企业级部署和审计
|
||||||
|
2. **多 Agent 路由**：Binding 系统支持复杂场景
|
||||||
|
3. **飞书深度集成**：原生支持飞书渠道
|
||||||
|
4. **工具策略**：细粒度的权限控制
|
||||||
|
5. **OpenAI 兼容**：便于集成现有生态
|
||||||
|
|
||||||
|
### 11.3 融合可能
|
||||||
|
|
||||||
|
两者可以互补：
|
||||||
|
- OpenClaw 作为**控制平面**（路由、渠道、多 Agent）
|
||||||
|
- Hermes 作为**认知引擎**（记忆、技能、学习）
|
||||||
|
|
||||||
|
这可能是未来 Agent 框架的方向。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 十二、结论
|
||||||
|
|
||||||
|
OpenClaw 和 Hermes 代表了两种截然不同的 Agent 设计哲学：
|
||||||
|
|
||||||
|
| 哲学 | OpenClaw | Hermes |
|
||||||
|
|------|----------|--------|
|
||||||
|
| **控制** | 人类控制 Agent | Agent 自我进化 |
|
||||||
|
| **记忆** | 静态文件 | 动态三层认知 |
|
||||||
|
| **技能** | 资源管理 | 能力生长 |
|
||||||
|
| **安全** | 规则驱动 | 沙箱 + 零信任 |
|
||||||
|
| **适用** | 企业/开发者 | 个人用户 |
|
||||||
|
|
||||||
|
**没有绝对的好坏**，只有场景的匹配。选择哪个，取决于你想要 AI 以什么方式陪伴你。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
*整理自：视频总结、OpenClaw 官方文档、Hermes Agent 架构文档等多个来源*
|
||||||
|
*总结时间: 2026-05-06*
|
||||||
92
Video-Generation/01-Video-Summary.md
Normal file
92
Video-Generation/01-Video-Summary.md
Normal file
@@ -0,0 +1,92 @@
|
|||||||
|
# 【【城】10 分钟看懂 Seedance：AI 是怎么凭空生成一段逼真视频的？-哔哩哔哩】
|
||||||
|
|
||||||
|
> 来源: Bilibili（https://b23.tv/oKTaPQw）| 时长: 10:26 | 总结时间: 2026-05-06
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 总结
|
||||||
|
|
||||||
|
这是一期技术科普视频，UP 主（城）用浅显的语言拆解了字节跳动 **Seedance 2.0**（集梦 AI 视频生成大模型）背后的工作原理，以及它相比传统 AI 视频模型的突破点。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 一、扩散模型（Diffusion）的基本原理
|
||||||
|
|
||||||
|
AI 生成视频的核心引擎是**扩散模型**，其工作机制分两个对称阶段：
|
||||||
|
|
||||||
|
### 1. 前向加噪（训练阶段）
|
||||||
|
|
||||||
|
给海量的真实视频/图片不断叠加高斯噪声，像素矩阵从有序逐渐变成纯随机乱码。AI 在这个过程中学会"噪声是如何被添加进去的"——即像素分布与噪声之间的映射关系，掌握了物体边缘概率梯度、光影变化统计规律等。
|
||||||
|
|
||||||
|
### 2. 反向去噪（生成阶段）
|
||||||
|
|
||||||
|
从一张纯随机噪声画布出发，用户输入文字指令后：
|
||||||
|
- 文本编码器将文字转化为数学向量
|
||||||
|
- AI 预测当前乱码中有多少像素是"多余的噪声"
|
||||||
|
- 每秒进行多次减法迭代，逐步剔除不符合描述的随机值
|
||||||
|
- 最终还原出符合要求的高清画面
|
||||||
|
|
||||||
|
### 3. 视频生成的难点
|
||||||
|
|
||||||
|
视频由连续帧组成，不仅要在单帧的空间维度上去噪，还需在时间维度上计算——Seedance 2.0 引入了**时空注意力机制**，生成后续帧时会参考前一帧的像素分布，确保物体位置、光影、形状在帧间连续变化。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 二、传统 AI 视频的两大致命缺陷
|
||||||
|
|
||||||
|
| 问题 | 原因 | 表现 |
|
||||||
|
|------|------|------|
|
||||||
|
| **连贯性缺陷** | 传统 diffusion 本质为静态图片设计，逐帧计算，缺乏全局动作的长期记忆，微小误差随视频时长累积 | 脸崩、背景物体消失/变形、穿模 |
|
||||||
|
| **多模态融合缺失** | 画面与音频由独立模型串行生成，运行在不同潜空间，无实时参数交换 | 口型与声音对不上，物体撞击与音效无法微秒级对齐 |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 三、Seedance 2.0 的核心技术突破
|
||||||
|
|
||||||
|
### 1. 双分支并行架构（解决音画同步问题）
|
||||||
|
|
||||||
|
- **画面分支**：负责像素的扩散还原
|
||||||
|
- **音频分支**：负责声波频率的扩散还原
|
||||||
|
|
||||||
|
关键点：两个分支运行在**同一时空潜空间**内，从去噪第一步起，每帧像素分布都实时参与音频波形概率计算，反之亦然（如计算出嘴唇张开的像素特征 → 音频分支同步预测对应声谱）。从根本上实现了**原声多模态生成**，音画绝对同步。
|
||||||
|
|
||||||
|
### 2. 时空耦合影视场建模（解决画面崩坏问题）
|
||||||
|
|
||||||
|
不单独处理每一张图片，而是将整个视频视为连续的四维坐标体（长、宽、高 + 时间）。
|
||||||
|
|
||||||
|
生成像素前，模型先通过**全局约束函数**计算全局约束条件：
|
||||||
|
- **运动矢量场**：物体在时间轴上的精确运动轨迹
|
||||||
|
- **全局光场参数**：光影随时间变化的物理规律
|
||||||
|
|
||||||
|
配合**双通路交叉注意力机制**，每轮去噪迭代同时进行：
|
||||||
|
- **帧内校验**：单张画面纹理材质符合高分辨率标准
|
||||||
|
- **帧间校验**：两帧像素偏移符合物理逻辑
|
||||||
|
|
||||||
|
结果：从根源消除了人变形、物体瞬移、场景穿模等现象，具备工业级稳定性。
|
||||||
|
|
||||||
|
### 3. 完整的四步生成流程
|
||||||
|
|
||||||
|
1. **特征提取与对齐**：多模态编码器将文字、参考图人物特征、参考视频动作、音频节奏全部转化为统一维度的数学向量，锁定人物 ID、动作坐标、镜头速度等约束条件
|
||||||
|
2. **全局时空约束网格预构建**：预先设定人物位移路径、光影折射变化、音频波峰时间戳，从根本上杜绝形变和跳变
|
||||||
|
3. **双分支并行去噪**：画面分支先生成低分辨率轮廓再逐步增加细节，音频分支同步计算声谱并实时注入像素计算过程，两分支每一步都在互相校验
|
||||||
|
4. **全局一致性计算 + 超分辨率映射**：对比首尾帧人物特征值，利用帧间蒸馏技术将低分辨率潜空间数据映射到高像素空间，补充皮肤纹理、衣服褶皱、光影折射等高频细节
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 四、Seedance 2.0 的标志性能力
|
||||||
|
|
||||||
|
- **全模态条件注入**：支持文本、图片、视频、音频四种模态混合输入；锁定角色参考图的身份特征向量后，无论镜头如何切换，AI 在每一帧都会不断比对这组固定参数，从根源解决多镜头人物变脸问题
|
||||||
|
- **智能叙事分镜**：接收到长文本后，模型先进行语义逻辑拆解，根据影视工业参数自动规划远景/中景/特写的切换逻辑，在同一全局时空蓝图下生成镜头，保证镜头间场景纵深、光影、角色动作的统计一致性
|
||||||
|
- **真实世界物理分布学习**：通过海量实拍视频训练，模型掌握了光线在不同介质的反射/折射率、物体受重力影响的运动矢量、生物组织形变模态等，生成流体、烟雾、肌肉牵引等细节严格遵循物理世界逻辑
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 五、局限与展望
|
||||||
|
|
||||||
|
Seedance 2.0 并非万能，在**超长视频生成**和**极端复杂的多人物交互场景**上仍有优化空间。但它真正将 AI 视频从"玩具"拉高到了"工业生产力"的水准。
|
||||||
|
|
||||||
|
> 视频结尾金句："技术进步永远在把创作的门槛不断拉低。以前创作的门槛是技术和设备，而现在创作唯一的门槛只有你的想象力。"
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
*总结时间: 2026-05-06*
|
||||||
268
Video-Generation/02-Algorithm-History.md
Normal file
268
Video-Generation/02-Algorithm-History.md
Normal file
@@ -0,0 +1,268 @@
|
|||||||
|
# AI 生成图片/视频：算法发展史
|
||||||
|
|
||||||
|
> 整理时间: 2026-05-06
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 一、生成模型的基石问题
|
||||||
|
|
||||||
|
让 AI「凭空」生成图片或视频，本质上是在解决一个核心问题：**如何从随机噪声中还原出有意义的信号？**
|
||||||
|
|
||||||
|
这个问题的解决路径经历了多条技术路线的迭代，每条路线都在不断解决前人的缺陷。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 二、VAE（变分自编码器）— 潜空间的开创者
|
||||||
|
|
||||||
|
### 背景
|
||||||
|
|
||||||
|
2013 年，Kingma & Welling 提出了 VAE。核心思路是：让模型学习一个光滑的**潜空间**（latent space），在这个空间里，任意两点之间的插值都能产生有意义的过渡图像。
|
||||||
|
|
||||||
|
### 算法原理
|
||||||
|
|
||||||
|
- **编码器**：将图片压缩成一个低维潜向量
|
||||||
|
- **潜空间约束**：强迫潜向量服从标准正态分布（KL 散度正则化）
|
||||||
|
- **解码器**：从潜向量还原图片
|
||||||
|
|
||||||
|
### 前人问题 vs 解决
|
||||||
|
|
||||||
|
| 问题 | VAE 的解法 |
|
||||||
|
|------|-----------|
|
||||||
|
| 传统自编码器潜空间不光滑 | KL 散度约束使潜空间连续 |
|
||||||
|
| 无法生成新图片 | 从正态分布采样潜向量即可生成 |
|
||||||
|
|
||||||
|
### 遗留问题
|
||||||
|
|
||||||
|
- 重建图片**模糊**（收敛到均值）
|
||||||
|
- 后续出现了 β-VAE、PixelVAE 等改进版本
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 三、GAN（生成对抗网络）— 对抗博弈的诞生
|
||||||
|
|
||||||
|
### 背景
|
||||||
|
|
||||||
|
2014 年，Ian Goodfellow 提出了 GAN，被认为是生成式 AI 的重大突破。
|
||||||
|
|
||||||
|
### 算法原理
|
||||||
|
|
||||||
|
- **生成器（G）**：从随机噪声生成假图片
|
||||||
|
- **判别器（D）**：判断图片是真实还是生成
|
||||||
|
- 两者对抗训练：D 越来越强，G 也越来越能骗过 D
|
||||||
|
|
||||||
|
### 关键里程碑
|
||||||
|
|
||||||
|
| 年份 | 模型 | 贡献 |
|
||||||
|
|------|------|------|
|
||||||
|
| 2015 | DCGAN | 首次将卷积层用于 GAN，生成质量大幅提升 |
|
||||||
|
| 2017 | WGAN/WGAN-GP | 解决训练不稳定、模式崩溃（mode collapse）问题 |
|
||||||
|
| 2017 | Progressive GAN | 渐进式增大分辨率，从 1024×1024 生成高清人脸 |
|
||||||
|
| 2018 | StyleGAN | 引入风格迁移机制，潜空间可操控性大幅提升 |
|
||||||
|
| 2020 | StyleGAN2 | 改进架构，消除伪影，成为人脸生成的标准 |
|
||||||
|
|
||||||
|
### 前人问题 vs 解决
|
||||||
|
|
||||||
|
| 问题 | GAN 的解法 |
|
||||||
|
|------|-----------|
|
||||||
|
| VAE 生成的图片模糊 | GAN 的对抗训练生成更清晰、更锐利的图片 |
|
||||||
|
| 潜空间不可操控 | StyleGAN 的风格向量支持独立控制不同层级的特征 |
|
||||||
|
|
||||||
|
### 遗留问题
|
||||||
|
|
||||||
|
- **模式崩溃（Mode Collapse）**：生成器只学会生成几种模式，缺乏多样性
|
||||||
|
- **训练不稳定**：需要精心平衡 G 和 D 的训练节奏
|
||||||
|
- **无显式似然**：无法计算生成图片的概率
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 四、Normalizing Flows（可逆流模型）
|
||||||
|
|
||||||
|
### 背景
|
||||||
|
|
||||||
|
2014 年 RealNVP（Dinh et al.），2018 年 Glow 进一步发展。
|
||||||
|
|
||||||
|
### 算法原理
|
||||||
|
|
||||||
|
通过一系列**可逆变换**（invertible transformations），将简单分布转换为复杂分布。每一步都可精确计算 log-likelihood。
|
||||||
|
|
||||||
|
### 优势
|
||||||
|
|
||||||
|
- 精确的密度估计
|
||||||
|
- 可逆推理
|
||||||
|
|
||||||
|
### 劣势
|
||||||
|
|
||||||
|
- 计算开销大，必须满足严格的可逆性约束
|
||||||
|
- 逐渐被扩散模型超越
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 五、自回归模型（Autoregressive Models）— 离散 token 的力量
|
||||||
|
|
||||||
|
### 背景
|
||||||
|
|
||||||
|
PixelCNN（2016）开始用自回归方式逐像素生成图片，但速度极慢。
|
||||||
|
|
||||||
|
### 关键突破：离散潜空间
|
||||||
|
|
||||||
|
2019 年 VQ-VAE 引入**离散token化**：
|
||||||
|
- 图片被编码成离散的 token 序列
|
||||||
|
- 自回归模型在 token 序列上生成
|
||||||
|
|
||||||
|
2020 年 VQ-GAN 在此基础上加入 GAN 损失，生成质量大幅提升。
|
||||||
|
|
||||||
|
### 前人问题 vs 解决
|
||||||
|
|
||||||
|
| 问题 | VQ-VAE/VQ-GAN 的解法 |
|
||||||
|
|------|---------------------|
|
||||||
|
| 连续潜空间计算复杂 | 离散 token 化使计算更高效 |
|
||||||
|
| 生成质量不足 | GAN 判别器提升局部纹理质量 |
|
||||||
|
|
||||||
|
### 代表作
|
||||||
|
|
||||||
|
| 年份 | 模型 | 贡献 |
|
||||||
|
|------|------|------|
|
||||||
|
| 2021 | DALL·E | 12 亿参数 Transformer，CLIP 重排序，震撼业界 |
|
||||||
|
| 2022 | Parti | Transformer 完全自回归，ViT-VQGAN tokenizer |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 六、Diffusion Model（扩散模型）— 当下的主流范式
|
||||||
|
|
||||||
|
### 核心原理
|
||||||
|
|
||||||
|
扩散模型分为两个对称过程：
|
||||||
|
|
||||||
|
**前向过程（Forward / 加噪）**：
|
||||||
|
- 对真实图片逐步添加高斯噪声
|
||||||
|
- 经过 T 步，变成纯噪声
|
||||||
|
- 模型在这个过程中学会"噪声是如何被添加的"
|
||||||
|
|
||||||
|
**反向过程（Reverse / 去噪）**：
|
||||||
|
- 从纯噪声出发
|
||||||
|
- 模型逐步预测并去除噪声
|
||||||
|
- 最终还原出清晰图片
|
||||||
|
|
||||||
|
### DDPM（2020）— 理论基础
|
||||||
|
|
||||||
|
Jonathan Ho 等人证明了 DDPM 可以生成高质量图片，核心是学习一个去噪网络。
|
||||||
|
|
||||||
|
### 关键突破时间线
|
||||||
|
|
||||||
|
| 年份 | 突破 | 意义 |
|
||||||
|
|------|------|------|
|
||||||
|
| 2021 | **Classifier-Free Guidance** | 无需单独训练分类器即可实现条件生成（文字控制），大幅提升文字-图片对齐 |
|
||||||
|
| 2021 | **Latent Diffusion（LDM / Stable Diffusion）** | Rombach et al. 将扩散过程搬到潜空间（VAE 压缩），大幅降低计算开销 |
|
||||||
|
| 2022 | **DiT（Diffusion Transformer）** | 用 Transformer 替代 U-Net 作为去噪网络，证实了 scaling law |
|
||||||
|
| 2022 | **DALL·E 2（CLIP + Diffusion）** | CLIP 语义空间 + 扩散模型，组合式生成能力大幅提升 |
|
||||||
|
|
||||||
|
### 前人问题 vs 解决
|
||||||
|
|
||||||
|
| 问题 | Diffusion 的解法 |
|
||||||
|
|------|----------------|
|
||||||
|
| GAN 训练不稳定、模式崩溃 | 扩散模型的训练目标简单（预测噪声），极其稳定 |
|
||||||
|
| 自回归模型慢 | 一次生成整张图（并行去噪），速度远快于逐像素自回归 |
|
||||||
|
| GAN 潜空间难操控 | 扩散模型的引导机制（classifier guidance）精确控制生成方向 |
|
||||||
|
|
||||||
|
### 为什么 Diffusion 超越了 GAN？
|
||||||
|
|
||||||
|
1. **训练稳定性**：GAN 的对抗博弈容易崩溃，扩散模型的噪声预测是凸优化问题，天然稳定
|
||||||
|
2. **可扩展性**：DiT 证明了扩散模型同样遵循 scaling law，参数量越大效果越好
|
||||||
|
3. **多模态条件控制**：classifier-free guidance 让文字条件控制变得简单可靠
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 七、Transformer 统一一切：DiT → 视频生成
|
||||||
|
|
||||||
|
### ViT（Vision Transformer，2020）
|
||||||
|
|
||||||
|
将 Transformer 引入图像领域，把图片切成 16×16 的 patch，作为 token 输入 Transformer。
|
||||||
|
|
||||||
|
### DiT（2022）
|
||||||
|
|
||||||
|
将 ViT 的 patch 思想与扩散模型结合：
|
||||||
|
- 图片被切成 patch，patch 被嵌入为 token
|
||||||
|
- 在潜空间中对噪声 patch 进行 Transformer 处理
|
||||||
|
- 证实了 scale 法则：大模型 + 大数据 = 更好的生成效果
|
||||||
|
|
||||||
|
### 视频生成的关键：时空 patch
|
||||||
|
|
||||||
|
视频生成的突破在于将 2D patch 扩展到 3D 时空 patch：
|
||||||
|
- **Sora（2024）**：将视频切成 spatiotemporal patches，在 DiT 架构下生成视频
|
||||||
|
- 每一帧既考虑空间关系（物体形状、光影），也考虑时间关系（运动轨迹）
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 八、视频生成：从伪影到工业级
|
||||||
|
|
||||||
|
### 早期方案（2022-2023）
|
||||||
|
|
||||||
|
| 模型 | 方法 |
|
||||||
|
|------|------|
|
||||||
|
| Imagen Video（Google） | 级联扩散模型，从低分辨率到高分辨率逐步生成 |
|
||||||
|
| Make-A-Video | 用伪卷积层（pseudo-convolution）扩展 2D 扩散到时间维度 |
|
||||||
|
| Stable Video Diffusion | 开源视频扩散模型，社区广泛使用 |
|
||||||
|
|
||||||
|
### 当前状态（2024-2025）
|
||||||
|
|
||||||
|
- **Sora**：DiT 架构 + 时空 patch，成为视频生成的世界模拟器基准
|
||||||
|
- **Seedance（字节）**：双分支音画同步 + 时空耦合建模
|
||||||
|
- **Kling（快手）**：注重物理真实感的视频生成
|
||||||
|
- **Runway Gen-3 / Pika 2.0**：面向创作者的短视频生成工具
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 九、最新技术：Flow Matching & 单步生成
|
||||||
|
|
||||||
|
### Rectified Flow / Flow Matching（2022-2023）
|
||||||
|
|
||||||
|
传统扩散模型需要多步迭代（通常 20-50 步），速度慢。
|
||||||
|
|
||||||
|
Rectified Flow 将前向和反向路径变成**直线插值**，大幅简化采样轨迹。
|
||||||
|
|
||||||
|
### Consistency Models & Lightning
|
||||||
|
|
||||||
|
- **Consistency Models**：学习一步从噪声直接到生成
|
||||||
|
- **SDXL Turbo / LCM（Latent Consistency Models）**：实现了单步或极少步（如 1-4 步）生成，质量接近多步模型
|
||||||
|
|
||||||
|
### 前人问题 vs 解决
|
||||||
|
|
||||||
|
| 问题 | Flow Matching / 单步生成的解法 |
|
||||||
|
|------|------------------------------|
|
||||||
|
| 多步去噪速度慢 | 直线轨迹 → 更少采样步骤 |
|
||||||
|
| 单步生成质量差 | Consistency Models 通过蒸馏保留质量 |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 十、总结：技术演进脉络
|
||||||
|
|
||||||
|
```
|
||||||
|
2013 VAE ── 生成式潜空间
|
||||||
|
↓
|
||||||
|
2014 GAN ── 对抗博弈，清晰图片
|
||||||
|
↓ （同一时期）
|
||||||
|
2014 Normalizing Flows ── 精确密度估计
|
||||||
|
↓
|
||||||
|
2016-2020 Autoregressive ── Transformer + VQ-VAE
|
||||||
|
↓
|
||||||
|
2020 DDPM ── 扩散模型理论基础
|
||||||
|
2021 LDM ── 潜空间扩散，效率突破
|
||||||
|
↓
|
||||||
|
2022 DiT ── Transformer + Diffusion，scale 法则
|
||||||
|
↓
|
||||||
|
2024 Sora ── 时空 patch，视频生成
|
||||||
|
↓
|
||||||
|
2024-2025 Flow Matching + 单步生成 ── 速度革命
|
||||||
|
```
|
||||||
|
|
||||||
|
### 核心范式转移
|
||||||
|
|
||||||
|
1. **GAN → Diffusion**：训练稳定性和可控性
|
||||||
|
2. **U-Net → Transformer**：Scaling law 成为可能
|
||||||
|
3. **像素空间 → 潜空间**：效率提升 100 倍以上
|
||||||
|
4. **静态图片 → 视频**：时空建模成为新的核心挑战
|
||||||
|
5. **纯视觉 → 多模态（音视频）**：Seedance 等开始音画联合生成
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
*本文档综合了 GAN、VAE、Normalizing Flow、Autoregressive、Diffusion、Transformer 等技术路线的发展历程，参考了 DDPM、LDM、DiT、Sora 等关键论文及行业资料。*
|
||||||
229
Video-Generation/03-Seedance-Tech.md
Normal file
229
Video-Generation/03-Seedance-Tech.md
Normal file
@@ -0,0 +1,229 @@
|
|||||||
|
# Seedance 2.0 技术报告：架构、算法原理与改进
|
||||||
|
|
||||||
|
> 整理时间: 2026-05-06
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 一、Seedance 2.0 概述
|
||||||
|
|
||||||
|
Seedance 2.0 是字节跳动推出的第二代 AI 视频生成大模型，于 2026 年 2 月正式发布。发布后在 Arena.AI 盲测平台上以 Elo 1450 / 1449 的分数排名第一，超越了 Sora、Veo 等竞品。
|
||||||
|
|
||||||
|
核心定位：**原生音视频联合生成** + **工业级物理真实性** + **多镜头叙事能力**。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 二、核心架构：双分支扩散 Transformer（DB-DiT）
|
||||||
|
|
||||||
|
### 2.1 设计动机
|
||||||
|
|
||||||
|
传统 AI 视频模型的致命问题：
|
||||||
|
- **音画不同步**：画面和音频由独立模型分别生成，串行运行在不同潜空间
|
||||||
|
- **时序一致性差**：缺乏全局动作的长期记忆，微小误差随时间累积导致崩坏
|
||||||
|
|
||||||
|
Seedance 2.0 的核心创新是 **DB-DiT（Dual-Branch Diffusion Transformer）**，从架构层面解决这两个问题。
|
||||||
|
|
||||||
|
### 2.2 双分支结构
|
||||||
|
|
||||||
|
```
|
||||||
|
输入（文字 + 参考图 + 参考视频 + 音频）
|
||||||
|
↓
|
||||||
|
┌─────────────────────────────────────┐
|
||||||
|
│ DB-DiT 双分支扩散 Transformer │
|
||||||
|
├──────────────────┬──────────────────┤
|
||||||
|
│ 画面分支 │ 音频分支 │
|
||||||
|
│ (Visual) │ (Audio) │
|
||||||
|
│ │ │
|
||||||
|
│ 3D Patches │ 声波频率扩散还原 │
|
||||||
|
│ 时空注意力 │ 时域注意力 │
|
||||||
|
│ 帧内 + 帧间校验 │ 音谱计算 │
|
||||||
|
├──────────────────┴──────────────────┤
|
||||||
|
│ 跨模态注意力桥（Cross-modal │
|
||||||
|
│ Attention Bridge） │
|
||||||
|
│ 帧级音画同步 │
|
||||||
|
└─────────────────────────────────────┘
|
||||||
|
↓
|
||||||
|
输出（像素画面 + 音频波形，完全同步）
|
||||||
|
```
|
||||||
|
|
||||||
|
**画面分支**：将视频切分为 3D spatiotemporal patches，处理空间 + 时间维度上的去噪还原。
|
||||||
|
|
||||||
|
**音频分支**：对声波频率进行扩散还原，与画面分支并行运行在同一时空潜空间内。
|
||||||
|
|
||||||
|
**跨模态注意力桥**：这是关键创新——画面分支每帧的像素分布，实时参与音频波形的概率计算；反之亦然。例如：当画面分支计算出嘴唇张开的像素特征时，音频分支同步预测对应的声谱特征。
|
||||||
|
|
||||||
|
### 2.3 MM-RoPE（多模态旋转位置编码）
|
||||||
|
|
||||||
|
MM-RoPE 是一种联合编码空间、时间、音频三个维度的位置信息的位置编码机制。
|
||||||
|
|
||||||
|
传统 RoPE（Rotary Position Encoding）只能编码一维位置。MM-RoPE 将其扩展为三维：
|
||||||
|
- **空间位置**：patch 在单帧内的 (x, y) 坐标
|
||||||
|
- **时间位置**：帧在视频中的 t 坐标
|
||||||
|
- **音频时域**：音频波形在时间轴上的位置
|
||||||
|
|
||||||
|
三个维度的位置向量通过旋转矩阵联合编码，确保模型在生成每一帧时都能感知到它在空间、时间、音轨上的精确位置关系。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 三、关键技术改进
|
||||||
|
|
||||||
|
### 3.1 原生音视频联合生成（从源头解决音画同步）
|
||||||
|
|
||||||
|
| 对比项 | 传统方案（串行生成） | Seedance 2.0（并行生成） |
|
||||||
|
|--------|-------------------|----------------------|
|
||||||
|
| 生成顺序 | 先生成视频，再生成音频 | 同一模型同时生成视频+音频 |
|
||||||
|
| 潜空间 | 两个独立模型，两个潜空间 | 同一 DB-DiT，单一时空潜空间 |
|
||||||
|
| 同步方式 | 后期对齐 | 从去噪第一步就互相校验 |
|
||||||
|
| 同步精度 | 秒级误差 | 微秒级帧级同步 |
|
||||||
|
|
||||||
|
### 3.2 时空耦合影视场建模
|
||||||
|
|
||||||
|
Seedance 不单独处理每一帧，而是将整个视频视为一个四维连续体（长、宽、高 + 时间）。
|
||||||
|
|
||||||
|
在生成像素之前，模型先通过**全局约束函数**计算以下条件：
|
||||||
|
|
||||||
|
**运动矢量场（Motion Vector Field）**
|
||||||
|
- 描述物体在时间轴上的精确运动轨迹
|
||||||
|
- 确保物体不会瞬移、穿模
|
||||||
|
|
||||||
|
**全局光场参数（Global Light Field）**
|
||||||
|
- 光影随时间变化的物理规律
|
||||||
|
- 确保打光的一致性和物理正确性
|
||||||
|
|
||||||
|
**双通路交叉注意力机制（Dual-Path Cross-Attention）**
|
||||||
|
- 每轮去噪迭代同时进行：
|
||||||
|
- **帧内校验**：单张画面纹理材质符合高分辨率标准
|
||||||
|
- **帧间校验**：两帧像素偏移符合物理逻辑
|
||||||
|
- 结果：从根源消除人变形、物体瞬移、场景穿模
|
||||||
|
|
||||||
|
### 3.3 真实世界物理分布学习
|
||||||
|
|
||||||
|
Seedance 2.0 通过海量实拍视频训练，掌握了：
|
||||||
|
- 光线在不同介质的反射/折射率
|
||||||
|
- 物体受重力影响的运动矢量
|
||||||
|
- 生物组织形变模态（皮肤、肌肉、头发）
|
||||||
|
- 流体、烟雾、粒子等自然现象的物理规律
|
||||||
|
|
||||||
|
因此生成流体、烟雾、碰撞等细节时，严格遵循物理世界逻辑。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 四、全模态条件注入
|
||||||
|
|
||||||
|
Seedance 2.0 支持**文本、图片、视频、音频四种模态**混合输入：
|
||||||
|
|
||||||
|
1. **身份参考（ID Reference）**：锁定参考图中人物的特征向量，无论镜头如何切换，AI 在每一帧都会持续比对这组固定参数，从根源解决多镜头人物变脸问题
|
||||||
|
2. **动作参考**：给定参考视频中的动作，迁移到目标角色
|
||||||
|
3. **音频驱动**：给定音频，可以驱动口型和表情同步
|
||||||
|
4. **多模态联合编码器**：将文字、图像、视频动作、音频节奏全部转化为统一维度的数学向量，锁定人物 ID、动作坐标、镜头速度等约束条件
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 五、四步生成流程
|
||||||
|
|
||||||
|
### Step 1：特征提取与对齐
|
||||||
|
|
||||||
|
多模态编码器将所有输入转化为统一维度的数学向量。
|
||||||
|
|
||||||
|
### Step 2：全局时空约束网格预构建
|
||||||
|
|
||||||
|
预先设定人物位移路径、光影折射变化、音频波峰时间戳，从根本上杜绝形变和跳变。
|
||||||
|
|
||||||
|
### Step 3：双分支并行去噪
|
||||||
|
|
||||||
|
- **画面分支**：先生成低分辨率轮廓，逐步增加细节
|
||||||
|
- **音频分支**：同步计算声谱，实时注入像素计算过程
|
||||||
|
- 两分支每一步都在互相校验
|
||||||
|
|
||||||
|
### Step 4：全局一致性计算 + 超分辨率映射
|
||||||
|
|
||||||
|
- 对比首尾帧人物特征值
|
||||||
|
- 利用**帧间蒸馏技术**将低分辨率潜空间数据映射到高像素空间
|
||||||
|
- 补充皮肤纹理、衣服褶皱、光影折射等高频细节
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 六、训练与推理优化
|
||||||
|
|
||||||
|
### 6.1 多阶段蒸馏 + 对抗蒸馏（10 倍加速）
|
||||||
|
|
||||||
|
Seedance 2.0 采用多阶段蒸馏策略：
|
||||||
|
- **多阶段蒸馏**：从教师模型到学生模型，逐步压缩步数
|
||||||
|
- **对抗蒸馏**：引入判别器，保证压缩后质量不下降
|
||||||
|
|
||||||
|
最终实现 **10 倍推理加速**，生成 5 秒视频仅需约 60 秒。
|
||||||
|
|
||||||
|
### 6.2 RLHF 三模型奖励系统
|
||||||
|
|
||||||
|
| 奖励模型 | 职责 |
|
||||||
|
|---------|------|
|
||||||
|
| **Base Reward** | 基础视频质量（清晰度、美学） |
|
||||||
|
| **Motion Reward** | 动作流畅度、物理合理性 |
|
||||||
|
| **Aesthetics Reward** | 构图、色彩、电影感 |
|
||||||
|
|
||||||
|
三套奖励信号联合优化，覆盖视频质量的不同维度。
|
||||||
|
|
||||||
|
### 6.3 FlashAttention-3 优化
|
||||||
|
|
||||||
|
利用 FlashAttention-3 对注意力计算进行硬件级优化，降低显存占用和计算延迟。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 七、性能与评测
|
||||||
|
|
||||||
|
### Arena.AI 盲测结果
|
||||||
|
|
||||||
|
Seedance 2.0 在 Arena.AI 平台达到 **Elo 1450 / 1449**，排名第一，超越 Sora、Veo 等主要竞品。
|
||||||
|
|
||||||
|
### 工业级可用率
|
||||||
|
|
||||||
|
| 指标 | Seedance 2.0 | 行业平均 |
|
||||||
|
|------|-------------|---------|
|
||||||
|
| 可用率 | **~90%** | ~20% |
|
||||||
|
|
||||||
|
可用率指生成结果无需重大修改即可使用的比例，这是工业生产力的关键指标。
|
||||||
|
|
||||||
|
### 规格参数
|
||||||
|
|
||||||
|
- **最长时长**：60 秒
|
||||||
|
- **最高分辨率**：2K
|
||||||
|
- **多语言唇形同步**：支持 8+ 语言
|
||||||
|
- **多镜头叙事**：支持自动分镜规划
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 八、局限性
|
||||||
|
|
||||||
|
Seedance 2.0 并非完美，仍有以下优化空间：
|
||||||
|
|
||||||
|
1. **视频延长质量下降**：当需要延长现有视频时，质量弱于 Veo 3.1
|
||||||
|
2. **群体运动协调**：多人物复杂交互场景仍有欠缺
|
||||||
|
3. **多人唇形同步**：同时保持多人唇形与音频同步仍有挑战
|
||||||
|
4. **高频视觉噪声**：某些情况下会产生高频纹理伪影
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 九、与 Sora 的核心差异
|
||||||
|
|
||||||
|
| 维度 | Sora | Seedance 2.0 |
|
||||||
|
|------|------|-------------|
|
||||||
|
| **架构** | 单分支 DiT | 双分支 DB-DiT（音画并行） |
|
||||||
|
| **音频** | 纯视觉生成，无音频 | 原生音视频联合生成 |
|
||||||
|
| **位置编码** | 标准 RoPE | MM-RoPE（三维联合） |
|
||||||
|
| **物理真实性** | World Simulator 概念 | 影视场建模 + 物理分布学习 |
|
||||||
|
| **多模态参考** | 图片/视频参考 | 图片 + 视频 + 音频混合参考 |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 十、总结
|
||||||
|
|
||||||
|
Seedance 2.0 的核心技术贡献可以归结为三点：
|
||||||
|
|
||||||
|
1. **DB-DiT 双分支架构**：从架构层面解决了音画同步问题，两个分支在同一潜空间并行去噪，从第一步起就互相校验
|
||||||
|
2. **时空耦合影视场建模**：将整个视频视为四维连续体，通过全局约束函数和双通路交叉注意力，确保帧间物理一致性
|
||||||
|
3. **MM-RoPE 三维位置编码**：联合编码空间、时间、音频时域的位置信息，为跨模态同步提供精确的位置感知能力
|
||||||
|
|
||||||
|
这三点分别对应了 AI 视频生成的三个核心挑战：**音画同步、物理一致性、多模态融合**。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
*本报告综合了 Seedance 2.0 官方技术报告（alphaxiv.org）、机器之心翻译版本（blog.qiaomu.ai）、阿里云技术解读等来源。*
|
||||||
401
Video-Generation/04-Final-Report.md
Normal file
401
Video-Generation/04-Final-Report.md
Normal file
@@ -0,0 +1,401 @@
|
|||||||
|
# AI 视频生成技术综合报告：算法发展与 Seedance 2.0 深度解析
|
||||||
|
|
||||||
|
> 整理时间: 2026-05-06
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 前言
|
||||||
|
|
||||||
|
本报告综合了四个部分的研究成果：
|
||||||
|
1. **视频内容总结** — B站科普视频《10 分钟看懂 Seedance》
|
||||||
|
2. **算法发展史** — 从 VAE、GAN 到 Diffusion、DiT 的演进脉络
|
||||||
|
3. **Seedance 2.0 技术报告** — 字节跳动 AI 视频生成模型的技术架构与改进
|
||||||
|
4. **综合分析** — 将上述内容串联，形成完整的技术图景
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 第一部分：视频内容总结
|
||||||
|
|
||||||
|
> 来源: B站 UP 主「城」| 视频标题：《10 分钟看懂 Seedance：AI 是怎么凭空生成一段逼真视频的？》
|
||||||
|
|
||||||
|
## 核心观点
|
||||||
|
|
||||||
|
这是一期面向大众的技术科普视频，用浅显的语言拆解了 Seedance 2.0 的工作原理及其相比传统 AI 视频模型的突破点。
|
||||||
|
|
||||||
|
### 扩散模型的基本原理
|
||||||
|
|
||||||
|
AI 生成视频的核心引擎是**扩散模型**（Diffusion Model），分为两个阶段：
|
||||||
|
|
||||||
|
**前向加噪（训练阶段）**：给海量真实视频/图片不断叠加高斯噪声，像素从有序逐渐变成纯随机乱码。AI 在这个过程中学会"噪声是如何被添加的"——即像素分布与噪声之间的映射关系。
|
||||||
|
|
||||||
|
**反向去噪（生成阶段）**：从纯随机噪声出发，用户输入文字指令后，AI 预测当前乱码中有多少像素是"多余的噪声"，每秒进行多次减法迭代，逐步剔除不符合描述的随机值，最终还原出符合要求的高清画面。
|
||||||
|
|
||||||
|
### 视频生成的特殊难点
|
||||||
|
|
||||||
|
视频由连续帧组成，不仅要在单帧的空间维度上去噪，还需在**时间维度**上计算——Seedance 2.0 引入了**时空注意力机制**，确保物体位置、光影、形状在帧间连续变化。
|
||||||
|
|
||||||
|
### 传统 AI 视频的两大致命缺陷
|
||||||
|
|
||||||
|
| 问题 | 原因 | 表现 |
|
||||||
|
|------|------|------|
|
||||||
|
| **连贯性缺陷** | 传统 diffusion 本质为静态图片设计，逐帧计算，缺乏全局动作的长期记忆 | 脸崩、背景物体消失/变形、穿模 |
|
||||||
|
| **多模态融合缺失** | 画面与音频由独立模型串行生成，运行在不同潜空间，无实时参数交换 | 口型与声音对不上 |
|
||||||
|
|
||||||
|
### Seedance 2.0 的三大核心突破
|
||||||
|
|
||||||
|
1. **双分支并行架构**：画面分支与音频分支在同一时空潜空间内并行去噪，从去噪第一步起就互相校验，从根本上实现音画绝对同步
|
||||||
|
2. **时空耦合影视场建模**：将整个视频视为四维连续体，通过运动矢量场和全局光场参数，确保帧间物理一致性
|
||||||
|
3. **全模态条件注入**：支持文本、图片、视频、音频四种模态混合输入，锁定身份特征向量，解决多镜头变脸问题
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 第二部分：AI 生成图片/视频的算法发展史
|
||||||
|
|
||||||
|
## 一、生成模型的基石问题
|
||||||
|
|
||||||
|
让 AI「凭空」生成图片或视频，本质上是解决一个核心问题：**如何从随机噪声中还原出有意义的信号？**
|
||||||
|
|
||||||
|
## 二、VAE（变分自编码器，2013）— 潜空间的开创者
|
||||||
|
|
||||||
|
**核心原理**：让模型学习一个光滑的潜空间（latent space），任意两点之间的插值都能产生有意义的过渡图像。
|
||||||
|
|
||||||
|
**关键机制**：
|
||||||
|
- 编码器将图片压缩为低维潜向量
|
||||||
|
- KL 散度约束强迫潜向量服从正态分布
|
||||||
|
- 解码器从潜向量还原图片
|
||||||
|
|
||||||
|
**解决了什么**：传统自编码器潜空间不光滑、无法生成新图片。
|
||||||
|
|
||||||
|
**遗留问题**：重建图片模糊（收敛到均值）。
|
||||||
|
|
||||||
|
## 三、GAN（生成对抗网络，2014）— 对抗博弈的诞生
|
||||||
|
|
||||||
|
**核心原理**：生成器（G）从随机噪声生成假图片，判别器（D）判断图片真假，两者对抗训练。
|
||||||
|
|
||||||
|
**关键里程碑**：
|
||||||
|
- 2015 DCGAN：首次将卷积层用于 GAN
|
||||||
|
- 2017 WGAN：解决训练不稳定、模式崩溃
|
||||||
|
- 2017 Progressive GAN：渐进式增大分辨率，生成 1024×1024 高清人脸
|
||||||
|
- 2018 StyleGAN：风格迁移机制，潜空间可操控
|
||||||
|
- 2020 StyleGAN2：消除伪影，成为人脸生成标准
|
||||||
|
|
||||||
|
**解决了什么**：VAE 生成的图片模糊，GAN 的对抗训练生成更清晰锐利的图片。
|
||||||
|
|
||||||
|
**遗留问题**：模式崩溃（mode collapse）、训练不稳定、无显式似然。
|
||||||
|
|
||||||
|
## 四、Normalizing Flows（可逆流模型，2014-2018）
|
||||||
|
|
||||||
|
**核心原理**：通过可逆变换将简单分布转换为复杂分布，每步可精确计算 log-likelihood。
|
||||||
|
|
||||||
|
**地位**：精确密度估计，但计算开销大，逐渐被扩散模型超越。
|
||||||
|
|
||||||
|
## 五、自回归模型（2016-2022）— 离散 token 的力量
|
||||||
|
|
||||||
|
**关键突破（2019 VQ-VAE）**：引入离散 token 化——图片被编码成离散的 token 序列，自回归模型在 token 序列上生成。
|
||||||
|
|
||||||
|
**2020 VQ-GAN**：加入 GAN 损失提升局部纹理质量。
|
||||||
|
|
||||||
|
**代表作**：
|
||||||
|
- 2021 DALL·E：12 亿参数 Transformer + CLIP 重排序
|
||||||
|
- 2022 Parti：Transformer 完全自回归，ViT-VQGAN tokenizer
|
||||||
|
|
||||||
|
**解决了什么**：连续潜空间计算复杂、生成质量不足。
|
||||||
|
|
||||||
|
## 六、Diffusion Model（扩散模型，2020-至今）— 当下的主流范式
|
||||||
|
|
||||||
|
**核心原理**：
|
||||||
|
- **前向过程**：对真实图片逐步添加高斯噪声，直到变成纯噪声
|
||||||
|
- **反向过程**：从纯噪声出发，模型逐步预测并去除噪声，还原出清晰图片
|
||||||
|
|
||||||
|
**关键突破时间线**：
|
||||||
|
| 年份 | 突破 | 意义 |
|
||||||
|
|------|------|------|
|
||||||
|
| 2020 | DDPM | 理论基础，证明可生成高质量图片 |
|
||||||
|
| 2021 | Classifier-Free Guidance | 无需单独分类器即可实现文字条件控制 |
|
||||||
|
| 2021 | Latent Diffusion（LDM） | 将扩散过程搬到潜空间，大幅降低计算开销 |
|
||||||
|
| 2022 | DiT（Diffusion Transformer） | 用 Transformer 替代 U-Net，证实 scaling law |
|
||||||
|
| 2022 | DALL·E 2 | CLIP 语义空间 + 扩散模型 |
|
||||||
|
|
||||||
|
**为什么 Diffusion 超越了 GAN？**
|
||||||
|
1. 训练目标简单（预测噪声），极其稳定，不像 GAN 那样容易崩溃
|
||||||
|
2. DiT 证明了扩散模型同样遵循 scaling law
|
||||||
|
3. Classifier-free guidance 让多模态控制变得简单可靠
|
||||||
|
|
||||||
|
## 七、Transformer 统一一切：DiT → 视频生成
|
||||||
|
|
||||||
|
**ViT（2020）**：将 Transformer 引入图像，把图片切成 16×16 的 patch 作为 token。
|
||||||
|
|
||||||
|
**DiT（2022）**：将 ViT 的 patch 思想与扩散模型结合，证实了 scale 法则。
|
||||||
|
|
||||||
|
**视频生成的关键**：将 2D patch 扩展到 3D 时空 patch——**Sora（2024）** 将视频切成 spatiotemporal patches，成为视频生成的世界模拟器基准。
|
||||||
|
|
||||||
|
## 八、视频生成发展脉络（2022-2025）
|
||||||
|
|
||||||
|
| 模型 | 方法 |
|
||||||
|
|------|------|
|
||||||
|
| Imagen Video（Google） | 级联扩散模型，从低分辨率到高分辨率逐步生成 |
|
||||||
|
| Make-A-Video | 用伪卷积层扩展 2D 扩散到时间维度 |
|
||||||
|
| Stable Video Diffusion | 开源视频扩散模型 |
|
||||||
|
| **Sora（2024）** | DiT 架构 + 时空 patch |
|
||||||
|
| **Seedance（字节）** | 双分支音画同步 + 时空耦合建模 |
|
||||||
|
| Kling（快手） | 注重物理真实感 |
|
||||||
|
| Runway Gen-3 / Pika 2.0 | 面向创作者的短视频生成工具 |
|
||||||
|
|
||||||
|
## 九、最新技术：Flow Matching & 单步生成
|
||||||
|
|
||||||
|
**Rectified Flow / Flow Matching（2022-2023）**：将前向和反向路径变成直线插值，大幅简化采样轨迹。
|
||||||
|
|
||||||
|
**Consistency Models / SDXL Turbo / LCM**：实现单步或 1-4 步生成，通过蒸馏保留质量。
|
||||||
|
|
||||||
|
## 十、算法演进脉络总结
|
||||||
|
|
||||||
|
```
|
||||||
|
2013 VAE ── 生成式潜空间
|
||||||
|
↓
|
||||||
|
2014 GAN ── 对抗博弈，清晰图片
|
||||||
|
↓
|
||||||
|
2014 Normalizing Flows ── 精确密度估计
|
||||||
|
↓
|
||||||
|
2016-2020 Autoregressive ── Transformer + VQ-VAE
|
||||||
|
↓
|
||||||
|
2020 DDPM ── 扩散模型理论基础
|
||||||
|
2021 LDM ── 潜空间扩散，效率突破
|
||||||
|
↓
|
||||||
|
2022 DiT ── Transformer + Diffusion，scale 法则
|
||||||
|
↓
|
||||||
|
2024 Sora ── 时空 patch，视频生成
|
||||||
|
↓
|
||||||
|
2024-2025 Flow Matching + 单步生成 ── 速度革命
|
||||||
|
↓
|
||||||
|
2026 Seedance 2.0 ── 原生音视频联合生成
|
||||||
|
```
|
||||||
|
|
||||||
|
### 五大核心范式转移
|
||||||
|
|
||||||
|
1. **GAN → Diffusion**：训练稳定性和可控性
|
||||||
|
2. **U-Net → Transformer**：Scaling law 成为可能
|
||||||
|
3. **像素空间 → 潜空间**：效率提升 100 倍以上
|
||||||
|
4. **静态图片 → 视频**：时空建模成为新的核心挑战
|
||||||
|
5. **纯视觉 → 多模态（音视频）**：Seedance 等开始音画联合生成
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 第三部分：Seedance 2.0 技术深度解析
|
||||||
|
|
||||||
|
## 一、概述
|
||||||
|
|
||||||
|
Seedance 2.0 是字节跳动推出的第二代 AI 视频生成大模型，2026 年 2 月发布，在 Arena.AI 盲测平台上以 Elo 1450/1449 排名第一，超越 Sora、Veo 等竞品。
|
||||||
|
|
||||||
|
核心定位：**原生音视频联合生成** + **工业级物理真实性** + **多镜头叙事能力**。
|
||||||
|
|
||||||
|
## 二、核心架构：DB-DiT（双分支扩散 Transformer）
|
||||||
|
|
||||||
|
### 设计动机
|
||||||
|
|
||||||
|
传统 AI 视频模型有两个致命问题：
|
||||||
|
- **音画不同步**：画面和音频由独立模型分别生成，串行运行在不同潜空间
|
||||||
|
- **时序一致性差**：缺乏全局动作的长期记忆，微小误差随时间累积导致崩坏
|
||||||
|
|
||||||
|
### DB-DiT 双分支结构
|
||||||
|
|
||||||
|
```
|
||||||
|
输入（文字 + 参考图 + 参考视频 + 音频）
|
||||||
|
↓
|
||||||
|
┌─────────────────────────────────────┐
|
||||||
|
│ DB-DiT 双分支扩散 Transformer │
|
||||||
|
├──────────────────┬──────────────────┤
|
||||||
|
│ 画面分支 │ 音频分支 │
|
||||||
|
│ 3D Patches │ 声波频率扩散还原 │
|
||||||
|
│ 时空注意力 │ 时域注意力 │
|
||||||
|
│ 帧内+帧间校验 │ 音谱计算 │
|
||||||
|
├──────────────────┴──────────────────┤
|
||||||
|
│ 跨模态注意力桥（Cross-modal │
|
||||||
|
│ Attention Bridge） │
|
||||||
|
└─────────────────────────────────────┘
|
||||||
|
↓
|
||||||
|
输出（像素画面 + 音频波形，完全同步）
|
||||||
|
```
|
||||||
|
|
||||||
|
**画面分支**：将视频切分为 3D spatiotemporal patches，在空间 + 时间维度上去噪还原。
|
||||||
|
|
||||||
|
**音频分支**：对声波频率进行扩散还原，与画面分支并行运行在同一时空潜空间内。
|
||||||
|
|
||||||
|
**跨模态注意力桥（关键创新）**：画面分支每帧的像素分布，实时参与音频波形的概率计算；反之亦然。例如：当画面分支计算出嘴唇张开的像素特征时，音频分支同步预测对应的声谱特征。
|
||||||
|
|
||||||
|
### MM-RoPE（多模态旋转位置编码）
|
||||||
|
|
||||||
|
MM-RoPE 将 RoPE 从一维扩展为三维，联合编码：
|
||||||
|
- **空间位置**：patch 在单帧内的 (x, y) 坐标
|
||||||
|
- **时间位置**：帧在视频中的 t 坐标
|
||||||
|
- **音频时域**：音频波形在时间轴上的位置
|
||||||
|
|
||||||
|
三个维度的位置向量通过旋转矩阵联合编码，确保模型精确感知每个元素在空间、时间、音轨上的位置关系。
|
||||||
|
|
||||||
|
## 三、关键技术改进
|
||||||
|
|
||||||
|
### 3.1 原生音视频联合生成
|
||||||
|
|
||||||
|
| 对比项 | 传统方案（串行生成） | Seedance 2.0（并行生成） |
|
||||||
|
|--------|-------------------|----------------------|
|
||||||
|
| 生成顺序 | 先生成视频，再生成音频 | 同一模型同时生成视频+音频 |
|
||||||
|
| 潜空间 | 两个独立模型，两个潜空间 | 同一 DB-DiT，单一时空潜空间 |
|
||||||
|
| 同步方式 | 后期对齐 | 从去噪第一步就互相校验 |
|
||||||
|
| 同步精度 | 秒级误差 | 微秒级帧级同步 |
|
||||||
|
|
||||||
|
### 3.2 时空耦合影视场建模
|
||||||
|
|
||||||
|
不单独处理每一帧，而是将整个视频视为四维连续体（长、宽、高 + 时间）。
|
||||||
|
|
||||||
|
**全局约束函数**：
|
||||||
|
- **运动矢量场**：描述物体在时间轴上的精确运动轨迹，确保物体不会瞬移、穿模
|
||||||
|
- **全局光场参数**：描述光影随时间变化的物理规律，确保打光一致性
|
||||||
|
|
||||||
|
**双通路交叉注意力机制**：
|
||||||
|
- 每轮去噪迭代同时进行帧内校验（纹理材质）和帧间校验（像素偏移物理逻辑）
|
||||||
|
- 从根源消除人变形、物体瞬移、场景穿模
|
||||||
|
|
||||||
|
### 3.3 真实世界物理分布学习
|
||||||
|
|
||||||
|
通过海量实拍视频训练，掌握了：
|
||||||
|
- 光线在不同介质的反射/折射率
|
||||||
|
- 物体受重力影响的运动矢量
|
||||||
|
- 生物组织形变模态（皮肤、肌肉、头发）
|
||||||
|
- 流体、烟雾、粒子等自然现象的物理规律
|
||||||
|
|
||||||
|
### 3.4 全模态条件注入
|
||||||
|
|
||||||
|
支持文本、图片、视频、音频四种模态混合输入：
|
||||||
|
- **身份参考（ID Reference）**：锁定参考图中人物的特征向量，解决多镜头人物变脸问题
|
||||||
|
- **动作参考**：将参考视频中的动作迁移到目标角色
|
||||||
|
- **音频驱动**：给定音频，驱动口型和表情同步
|
||||||
|
|
||||||
|
## 四、四步生成流程
|
||||||
|
|
||||||
|
1. **特征提取与对齐**：多模态编码器将所有输入转化为统一维度的数学向量
|
||||||
|
2. **全局时空约束网格预构建**：预先设定人物位移路径、光影折射变化、音频波峰时间戳
|
||||||
|
3. **双分支并行去噪**：画面分支生成低分辨率轮廓逐步增加细节，音频分支同步计算声谱，两分支每步互相校验
|
||||||
|
4. **全局一致性计算 + 超分辨率映射**：利用帧间蒸馏技术将低分辨率潜空间数据映射到高像素空间，补充高频细节
|
||||||
|
|
||||||
|
## 五、训练与推理优化
|
||||||
|
|
||||||
|
### 多阶段蒸馏 + 对抗蒸馏（10 倍加速）
|
||||||
|
|
||||||
|
- 多阶段蒸馏：从教师模型到学生模型，逐步压缩步数
|
||||||
|
- 对抗蒸馏：引入判别器，保证压缩后质量不下降
|
||||||
|
- 生成 5 秒视频仅需约 60 秒
|
||||||
|
|
||||||
|
### RLHF 三模型奖励系统
|
||||||
|
|
||||||
|
| 奖励模型 | 职责 |
|
||||||
|
|---------|------|
|
||||||
|
| Base Reward | 基础视频质量（清晰度、美学） |
|
||||||
|
| Motion Reward | 动作流畅度、物理合理性 |
|
||||||
|
| Aesthetics Reward | 构图、色彩、电影感 |
|
||||||
|
|
||||||
|
### FlashAttention-3 优化
|
||||||
|
|
||||||
|
对注意力计算进行硬件级优化，降低显存占用和计算延迟。
|
||||||
|
|
||||||
|
## 六、性能评测
|
||||||
|
|
||||||
|
- **Arena.AI Elo**：1450/1449，排名第一
|
||||||
|
- **可用率**：~90%（行业平均 ~20%）
|
||||||
|
- **最长时长**：60 秒
|
||||||
|
- **最高分辨率**：2K
|
||||||
|
- **多语言唇形同步**：支持 8+ 语言
|
||||||
|
|
||||||
|
## 七、局限性
|
||||||
|
|
||||||
|
1. 视频延长质量弱于 Veo 3.1
|
||||||
|
2. 多人物复杂交互场景仍有欠缺
|
||||||
|
3. 多人唇形同步有挑战
|
||||||
|
4. 某些情况下产生高频纹理伪影
|
||||||
|
|
||||||
|
## 八、与 Sora 的核心差异
|
||||||
|
|
||||||
|
| 维度 | Sora | Seedance 2.0 |
|
||||||
|
|------|------|-------------|
|
||||||
|
| 架构 | 单分支 DiT | 双分支 DB-DiT（音画并行） |
|
||||||
|
| 音频 | 纯视觉，无音频 | 原生音视频联合生成 |
|
||||||
|
| 位置编码 | 标准 RoPE | MM-RoPE（三维联合） |
|
||||||
|
| 物理真实性 | World Simulator 概念 | 影视场建模 + 物理分布学习 |
|
||||||
|
| 多模态参考 | 图片/视频参考 | 图片 + 视频 + 音频混合参考 |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 第四部分：综合分析
|
||||||
|
|
||||||
|
## 一、从算法演进看 Seedance 2.0 的历史地位
|
||||||
|
|
||||||
|
Seedance 2.0 并不是一次偶然的技术突破，而是 AI 生成技术沿着以下路径演进的必然产物：
|
||||||
|
|
||||||
|
1. **VAE（2013）**证明了潜空间学习的可行性
|
||||||
|
2. **GAN（2014）**证明了对抗训练能生成清晰图片，但存在模式崩溃和训练不稳定的问题
|
||||||
|
3. **Diffusion（2020）**解决了 GAN 的训练稳定性问题，并迅速成为主流范式
|
||||||
|
4. **LDM（2021）**将扩散过程搬到潜空间，让计算效率提升 100 倍以上
|
||||||
|
5. **DiT（2022）**用 Transformer 替代 U-Net，证实了 scaling law，让视频生成成为可能
|
||||||
|
6. **Sora（2024）**证明了 DiT + 时空 patch 可以作为视频生成的世界模拟器
|
||||||
|
7. **Seedance 2.0（2026）**在 Sora 的基础上，解决了 Sora 无法解决的三个问题：**音画同步、物理一致性、多模态融合**
|
||||||
|
|
||||||
|
## 二、Seedance 2.0 的三大核心创新
|
||||||
|
|
||||||
|
### 创新一：DB-DiT 双分支架构
|
||||||
|
|
||||||
|
Sora 等现有视频生成模型都是**单分支**的——即只处理视觉信息。如果要生成音频，通常需要额外的 TTS（文字转语音）或 SFX（音效）模型，音画之间只能后期对齐。
|
||||||
|
|
||||||
|
DB-DiT 的关键洞察是：**音频和画面在时间轴上是强耦合的**。当一个人说话时，嘴唇的运动和声带的振动必须在同一时刻发生，任何后期对齐都会产生可感知的延迟。
|
||||||
|
|
||||||
|
DB-DiT 将这个耦合关系编码到模型架构中——画面分支和音频分支在同一时空潜空间内并行运行，从去噪的第一步起就互相校验。这是架构层面的创新，不是简单的后处理。
|
||||||
|
|
||||||
|
### 创新二：时空耦合影视场建模
|
||||||
|
|
||||||
|
传统扩散模型在生成视频时，本质上还是在**逐帧生成**——每一帧都是从噪声出发，在空间维度上去噪。时间维度的连贯性只是通过注意力机制部分保证，但无法从全局视角约束整个视频的时空一致性。
|
||||||
|
|
||||||
|
Seedance 2.0 的影视场建模，相当于在生成之前先构建一个**全局约束网格**——人物的位移路径、光影的变化规律、音频波峰的时间戳，都预先设定好了。生成过程不是"碰运气"，而是在约束框架内的精确填充。
|
||||||
|
|
||||||
|
这使得 Seedance 2.0 具备工业级稳定性，**可用率达到 90%**，而行业平均只有 20%。
|
||||||
|
|
||||||
|
### 创新三：MM-RoPE 三维位置编码
|
||||||
|
|
||||||
|
标准 RoPE 只能编码一维位置（序列中的位置）。MM-RoPE 将其扩展为三维——空间、时间、音频时域各一个维度，通过旋转矩阵联合编码。
|
||||||
|
|
||||||
|
这个创新的意义在于：它为跨模态同步提供了**精确的位置感知能力**。当模型知道第 N 帧在时间轴上的位置，同时也知道对应的音频波形在时间轴上的位置，它就能精确计算两者的对齐关系。
|
||||||
|
|
||||||
|
## 三、AI 视频生成的下一步
|
||||||
|
|
||||||
|
Seedance 2.0 解决了当前的主要矛盾，但仍有局限：
|
||||||
|
|
||||||
|
1. **超长视频生成**：60 秒已是当前极限，更长的视频需要在连贯性和计算成本之间找到新的平衡
|
||||||
|
2. **多人复杂交互**：群体运动的协调是多模态模型共同的挑战
|
||||||
|
3. **实时生成**：目前的生成速度（5 秒视频需 60 秒）距离实时还有差距
|
||||||
|
|
||||||
|
未来方向可能包括：
|
||||||
|
- **更高效的蒸馏方法**：将步数进一步压缩到 1-2 步
|
||||||
|
- **更强的物理引擎集成**：将物理仿真引擎嵌入生成过程
|
||||||
|
- **多语言原生支持**：不仅是唇形同步，而是整个语义理解的多语言原生
|
||||||
|
|
||||||
|
## 四、技术进步的终极意义
|
||||||
|
|
||||||
|
视频结尾的金句值得引用：
|
||||||
|
|
||||||
|
> "技术进步永远在把创作的门槛不断拉低。以前创作的门槛是技术和设备，而现在创作唯一的门槛只有你的想象力。"
|
||||||
|
|
||||||
|
从 GAN 到 Diffusion，从 DiT 到 Seedance，AI 视频生成技术的演进，本质上是在不断降低创作的门槛——让更多人可以用想象力驱动内容生产，而不需要掌握复杂的技术工具。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 附录：文件清单
|
||||||
|
|
||||||
|
本报告涉及的源文件：
|
||||||
|
|
||||||
|
| 文件名 | 内容 |
|
||||||
|
|--------|------|
|
||||||
|
| `01-Video-Summary.md` | B站视频内容总结 |
|
||||||
|
| `02-Algorithm-History.md` | AI 生成图片/视频的算法发展史 |
|
||||||
|
| `03-Seedance-Tech.md` | Seedance 2.0 技术深度解析 |
|
||||||
|
| `04-Final-Report.md` | 本综合报告 |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
*报告生成时间: 2026-05-06*
|
||||||
|
*数据来源: B站科普视频、arXiv 技术报告、阿里云/机器之心技术解读*
|
||||||
Reference in New Issue
Block a user