MTA 项目架构笔记：媒体到 Agent 的数据管道

MTA 是什么

MTA = Media to Agent。

一句话概括：把各种形态的媒体内容，变成 AI Agent 能理解和处理的结构化数据。

听起来有点抽象。举个具体的例子：


一段直播录像（视频）
  ↓
语音转文字（音频→文本）
  ↓
主播说了什么、什么时候说了什么
  ↓
Agent 分析：这段讲的是产品介绍，这段是互动环节
  ↓
Agent 决策：根据分析结果执行操作

MTA 就是这条管道的骨架。

为什么需要 MTA

在搭 MTA 之前，我的工作流是：


看到一个直播片段 → 手动看回放 → 记笔记 → 告诉 Agent 去执行

这里面有几个瓶颈：

时间差 — 从看到信息到 Agent 执行，中间隔了"人"这个环节
信息损耗 — 人工转述会有遗漏和偏差
规模限制 — 一天几十个小时的直播内容，看完就不现实
非实时 — 只能事后分析，不能实时感知

MTA 想解决的问题就是：让 Agent 能"看"媒体、"听"媒体，不需要人在中间当翻译。

架构演变

V1：原型（验证可行性）


媒体文件 → 本地 Whisper 转写 → 文本文件 → 手动喂给 Agent

最原始的版本。用 OpenAI Whisper 做语音转写，结果存成 txt，然后手动丢给 LLM。

问题很明显：

转写结果散落在各处，没有统一管理
每次都要手动操作，步骤重复
只能处理音频，不能处理视频流

V2：管道化（打通流程）


媒体源                    处理层                  存储层                  消费层
┌──────┐              ┌──────────┐           ┌──────────┐           ┌──────────┐
│ 视频  │──检测格式──→  │ 语音转写  │──结构化──→│ 数据库   │──检索──→  │ Agent   │
│ 音频  │──提取音轨    │ 说话人分离 │──元数据  │          │          │          │
│ 直播  │              │ NER提取   │          │          │          │          │
└──────┘              └──────────┘           └──────────┘           └──────────┘

把处理流程拆成独立阶段，每个阶段可独立部署、独立替换。

V3（当前）：平台化

第三代还在迭代中，目标是做成通用平台：


输入层             处理引擎            存储与索引           API 层             输出层
┌────┐     ┌──────────────┐     ┌──────────────┐     ┌────────────┐     ┌──────────┐
│RSS  │     │ 语音识别      │     │ 向量数据库    │     │ 搜索 API    │     │ AI Agent │
│API  │────→│ NLP 分析      │────→│ 知识图谱      │────→│ 事件订阅    │────→│ 用户通知  │
│文件  │     │ 实体解析      │     │ 时间线索引    │     │ 分析报告    │     │ Dashboard│
│直播  │     │ 质量评分      │     │              │     │            │     │          │
└────┘     └──────────────┘     └──────────────┘     └────────────┘     └──────────┘

特点：

插件化处理引擎 — 语音识别、NLP、实体提取都是独立模块，可插拔
统一数据模型 — 所有媒体处理后的输出遵循同一份 schema
事件驱动 — 新内容处理完成后主动通知消费者
水平扩展 — 处理引擎可多实例并行（不过单机场景暂时用不上）

核心技术选型

语音转写

引擎	准确性	速度	资源占用	选择
Whisper 本地	高（多语言）	慢	GPU > 6GB	❌ 太重
Whisper API	高	快	无	✅ 主力
Vosk	中	极快	低	❌ 中文一般
FunASM	高	中	中	待评估

目前用云端 Whisper API，本地 RTX4060Ti 跑 whisper.cpp 做离线兜底。

说话人分离

多人对话场景（直播连麦、会议）需要区分谁在说话。

基于频谱分析 — 传统方法，效果好但依赖音频质量
基于模型 — pyannote-audio，效果好但资源消耗大
基于时间戳 — 引入外部标注，对已知场景够用

当前方案：时间戳 + 声纹特征简化版，对直播间场景（主播 + 观众问答）已经够用。

结构化提取

原始转写文本只是一堆字，需要进一步处理才有价值：


原始转写：
"欢迎来到直播间，今天给大家带来一款新茶，铁观音的新工艺
 啊，这个茶汤特别透亮，入口回甘很快"

结构化提取：
{
  "speaker": "主播",
  "segments": [
    {"type": "greeting", "text": "欢迎来到直播间"},
    {"type": "product_intro", "product": "铁观音新工艺",
     "features": ["茶汤透亮", "入口回甘快"]}
  ],
  "call_to_action": false,
  "products_mentioned": ["铁观音新工艺"]
}

提取过程用 LLM 完成（few-shot + schema 约束），准确率大约 85%，对后续决策够用了。

当前状态：V3 后端开发中

项目目前处于 V3 后端开发阶段。V2 管道化的核心流程已经跑通了，当前工作重点：

统一的媒体接入层 — 支持 RSS 订阅源、API 推送、文件上传三种接入方式
处理引擎标准化 — 所有处理模块遵循同一接口，方便替换和组合
结构化存储 — 向量数据库 + 关系型数据库的混合存储方案
事件系统 — 处理完成后的主动通知机制

实际使用场景

场景 1：直播内容分析


输入：铁观音直播间回放（4小时视频）
输出：
- 产品出现的频次和时间点
- 互动高峰时段
- 主播话术分析（什么措辞转化率高）
- 竞品提及分析

场景 2：课程转录


输入：千川投放线下培训录音（1.5小时）
输出：
- 结构化笔记，按知识点分段
- 关键数据指标提取
- 实操步骤拆解
- 自动入库到知识库（ChromaDB）

场景 3：实时监控


输入：直播间实时音频流
输出：
- 关键词命中告警（提到竞品、违规词）
- 互动密度变化检测
- 自动生成跟播建议

踩坑记录

1. 长音频的处理 4 小时直播直接丢给 Whisper 会 OOM。解决方案：按静音段切割 + 流式处理，每次处理 30 秒窗口。

2. 说话人分离的精度 直播间背景音乐干扰严重，传统声纹效果差。妥协方案：大部分场景只标注"主播/非主播"两分类，够用即可。

3. 时间线对齐 视频 + 语音 + 转写文本三个时间轴对齐——这是 V2 阶段最耗时的 debug。最后用了 ffmpeg 的时间基做统一参考系。

4. 存储架构选择 纯向量数据库存结构化数据很别扭（ChromaDB 不适合时间范围查询），纯关系型存 embedding 也很别扭。最终方案：双写——向量库管搜索，PG 管精确查询和时间线。

未来方向

实时流处理 — 从"事后分析"到"实时感知"
多模态融合 — 不只是音频，还有画面分析（直播中的产品展示）
反馈闭环 — Agent 基于分析结果执行操作后，操作效果回流到 MTA，形成学习循环
轻量化部署 — 一套 docker-compose 搞定，别人也能直接用

目录