企业官网建设流程全解析

AlphaAvatar v0.6.4 架构升级：统一实时感知、RTC 解耦与在线 ENV Memory

在上一篇文章中，我介绍了开源项目AlphaAvatar的整体目标：构建一个可自托管的实时全模态个人 AI 助手运行时。

它不仅需要支持文本、语音和摄像头输入，还需要具备长期 Memory、Persona、身份识别、工具调用、RAG、DeepResearch、实时状态反馈，以及跨渠道持续工作的能力。

经过最近几个版本的迭代，AlphaAvatar 在 v0.6.4 中完成了一次比较重要的运行时架构升级。

这次更新的核心不是增加一个单独的功能，而是重新整理实时多模态信息在系统内部的流动方式：

外部媒体只接入一次，再由统一的感知运行时提供给 Vision、Persona、Memory 和未来的交互路由模块。

同时，v0.6.4 也加入了第一版在线 ENV Memory，让 AlphaAvatar 可以从持续的视频流中提取环境事件和视觉历史，而不再只依赖文本对话构建记忆。

一、为什么需要重新设计感知架构

在早期实现中，AlphaAvatar 主要基于 LiveKit Agents 构建。

Vision、Persona 和 Memory 等模块如果需要使用视频帧，可能分别订阅或处理 LiveKit 视频轨道。

这种方式在功能较少时比较直接，但随着模块不断增加，会产生几个问题：

• 不同模块重复读取和转换同一份视频流
• 业务插件直接依赖 LiveKit 类型
• Vision、Persona 和 Memory 使用不同的采样逻辑
• 注释、检测结果和原始帧难以统一对齐
• 后续更换 RTC 后端时需要修改大量插件代码
• AvatarEngine承担了过多运行时职责

因此，v0.6.4 将实时媒体输入重新设计成一条共享的感知路径：

RTC / Device Input ↓ EnvObservation + MediaPayload ↓ PerceptionRuntime ├── Typed Streams ├── Shared Timeline └── Consumer-specific Windows ↓ Persona / Vision / Memory / Future Routers

RTC 层只负责接入和转换外部媒体。

进入 AlphaAvatar 后，视频帧、屏幕内容、音频片段、事件和注释都会使用统一的核心数据结构进行表达。

二、更新后的六层架构

目前 AlphaAvatar 的整体结构可以划分为六个主要部分。

1. AlphaAvatar Core

avatar-core提供不依赖具体 RTC 和模型厂商的基础类型，包括：

• EnvObservation
• EnvAnnotation
• MediaPayload
• PayloadView
• PayloadFormat
• 通用视频帧表示
• Typed Perception Streams
• Shared Timeline
• Perception Window Builder

它负责描述“系统观察到了什么”，但不负责决定这些信息具体来自 LiveKit、WebRTC 还是其他设备。

这让 Memory、Persona 和 Vision 可以直接消费统一的环境观察，而不需要了解底层 RTC 实现。

2. AlphaAvatar RTC

RTC 层负责将外部实时媒体转换为 AlphaAvatar Core 能理解的数据。

目前 LiveKit 仍然是默认实现，但 LiveKit 的rtc.VideoFrame等类型只存在于适配器边界，不再直接进入核心 Memory 或 Persona 数据结构。

这里遵循的原则是：

RTC 是适配器，而不是业务逻辑。

未来接入原生 WebRTC、aiortc或其他实时通信后端时，理论上只需要实现新的 RTC Adapter，而不需要重写 Memory、Persona 和 Vision。

3. AlphaAvatar Agent

Agent 层负责编排一次实时助手会话。

当前运行时逐渐拆分为：

• SessionRuntime
• ContextRuntime
• PerceptionRuntime
• IO Runtime
• Agent Runtime
• AvatarEngine

其中，AvatarRuntime负责组合 Session、Context 和 Perception 等会话级运行时组件。

AvatarEngine则更加专注于：

• 会话生命周期
• Prompt 组装
• Status 状态管理
• LLM Turn Flow
• 插件协调

这减少了单个核心类中的职责堆积。

4. AlphaAvatar Plugins

面向个人助手的长期能力通过插件实现，例如：

• Memory
• Persona
• Status
• Character
• Interaction Router
• Reflection
• Planning
• Behavior

插件通过构造函数获得需要的运行时依赖，并通过统一的生命周期方法启动和停止：

awaitplugin.on_session_start()awaitplugin.on_session_stop()

Persona、Memory 和 Vision 不再各自直接管理 RTC 视频订阅，而是作为共享感知数据的独立消费者。

5. Tools Plugins

工具和知识能力仍然保持独立，包括：

• MCP
• RAG
• DeepResearch
• 未来的代码沙箱和个人工作空间集成

工具结果不仅可以用于当前回答，也可以经过 Memory 抽取后成为未来会话可检索的长期上下文。

6. Channels

同一个 AlphaAvatar Runtime 可以连接到不同交互渠道：

• Web
• WhatsApp
• Avatar UI
• 未来的 Discord、Slack、移动端或其他应用

Channel 只负责改变用户访问助手的方式，不应该重新构建一套独立的助手状态。

三、统一的 PerceptionRuntime

PerceptionRuntime是 v0.6.4 的核心变化之一。

它为不同类型的多模态信息提供独立的 Typed Stream：

video stream audio stream screen stream event stream annotation stream

每个消费者拥有独立的读取游标、采样频率和本地缓冲区。

例如：

• Persona 可以持续处理人脸检测和身份匹配
• Vision 可以保留最近的少量帧用于当前 LLM Turn
• Memory 可以定期读取更长的观察窗口
• 未来的 Router 可以根据人物出现、动作、声音或屏幕变化判断是否需要响应

这些消费者不需要采用相同帧率，也不需要互相阻塞。

Shared Timeline 负责对齐 Observation 和 Annotation，Window Builder 则根据不同消费者的需求构建有序的多模态时间窗口。

四、同一份媒体的多种 Payload View

在实时多模态系统中，同一个视频帧可能需要多种表示。

例如：

• Persona 需要原始 JPEG 做人脸检测
• 调试界面需要带人脸框的渲染帧
• ENV Memory 希望优先使用带注释的 JPEG
• Vision 最终可能需要转换成模型接口支持的视频帧类型

因此，MediaPayload可以同时保存：

RAW + VIDEO_FRAME RAW + JPEG ANNOTATED + VIDEO_FRAME ANNOTATED + JPEG

原始帧不会被覆盖。

Persona 可以在完成检测后发布EnvAnnotation，Renderer 再基于原始帧生成带标注的新 Payload View。

其他消费者根据自己的需求选择最合适的表示。

五、在线 ENV Memory

v0.6.4 还加入了第一版在线环境记忆。

传统的 Memory 主要来自文本：

用户对话 ↓ Memory Extraction ↓ 长期记忆

ENV Memory 则来自持续的环境观察：

实时视频观察 ↓ Perception Window ↓ 多模态 ENV Extraction ↓ EnvMemoryDelta ↓ MemoryType.ENV

例如，AlphaAvatar 可以提取这样的环境记忆：

[ENV] 一名可见人物持续坐在室内工作区域，戴着眼镜和耳机。背景中的置物架和垂直灯光在多个观察帧中保持可见。 [/ENV]

或者记录：

• 一个人进入或离开画面
• 一个杯子被移动到桌面另一侧
• 某个植物持续出现在用户附近
• 屏幕正在展示代码调试流程
• 房间内的主要物体或布局发生变化
• 某个人物在一段时间内持续保持特定活动状态

ENV Memory 的目标不是保存全部摄像头视频，也不是给每一帧生成图片描述。

AlphaAvatar 会：

1. 按照 Memory 自己的采样策略读取观察窗口
2. 结合时间顺序和已有 Annotation
3. 提取简洁的环境事件或持续状态
4. 保存结构化 ENV Memory
5. 在后续会话中支持视觉历史检索

原始视频帧只存在于运行时，不会直接写入向量数据库或 Markdown Memory。

六、ENV Memory 与 Graph-aware Memory

v0.6.3 已经加入了 Graph-aware Memory 基础：

• 多对象 Memory 所有权
• Graph Node Mention
• Graph Node 和 Graph Link
• Session-scoped Local Key
• GraphLookup
• LanceDB Graph Node 索引
• Alias-ready Retrieval

v0.6.4 的 ENV Memory 会继续复用这套结构。

一条环境记忆可以关联具体观察实体，例如：

person face speaker object plant vehicle device screen document room location

Memory 文本仍然是信息的主要来源，Graph Node 只作为稀疏的检索锚点。

例如，一条关于人物、耳机和置物架的 ENV Memory，可以分别生成对应的实体节点，而不是把所有内容合并成一个抽象概念节点。

这样后续可以逐步支持：

• 查找某个物体曾经出现在哪里
• 检索某个人物出现过的环境事件
• 查询某个屏幕或文档的历史观察
• 根据时间、地点、人物和物体组合检索视觉历史

七、异步 Vision 和 Persona

Avatar Vision 现在也通过 PerceptionRuntime 异步消费视频观察。

它在后台维护一个有界缓冲区，inject_into_chat_ctx()只需要从本地缓冲区选择合适的帧，而不需要在 LLM 推理准备阶段同步读取视频流。

这样可以降低当前 Turn 的额外等待时间。

Persona FaceStream 同样改为消费共享观察：

PerceptionRuntime ↓ Persona FaceStream ↓ Face Detection / Embedding ↓ EnvAnnotation ↓ Annotated Payload View

FaceStream 的启动和停止由 Persona 自己的插件生命周期管理，不再由AvatarEngine直接调用。

八、为什么这些能力不全部交给模型

随着多模态模型能力增强，未来模型本身可能承担更多：

• 上下文压缩
• 工具规划
• 视觉理解
• Memory 选择
• 用户状态理解

但个人 AI 助手仍然需要一个显式、可控、用户所有的运行时层。

它负责：

• 长期数据存储
• 隐私边界
• 身份管理
• 工具权限
• 模型切换
• Provider 路由
• 调试和追踪
• Memory 编辑和删除
• 跨渠道状态连续性
• Replay 和 Evaluation

模型可以随时替换，但用户的 Memory、Persona、工具和历史状态不应该完全锁定在某个模型厂商的内部黑盒中。

九、当前限制和下一步计划

v0.6.4 完成的是第一版统一实时感知和 ENV Memory 基础，仍然有很多工作需要继续推进：

• 音频 ENV Memory
• Screen ENV Memory
• 更细粒度的物体、事件、身份和时间检索
• 长时间窗口中的事件合并和去重
• 多用户人脸与说话人对齐
• Interaction Router
• Reflection 和 Planning
• 更多 RTC Adapter
• Memory 和 Persona 的用户检查与编辑界面
• 完整的 Session Replay 和评估工具

总结

AlphaAvatar v0.6.4 的意义不只是增加了一个视觉记忆功能。

它重新定义了多模态信息在系统中的流动方式：

外部实时媒体 ↓ 统一环境观察 ↓ 共享感知运行时 ↓ 不同插件独立消费和增强 ↓ 当前交互 + 长期记忆 + 未来行为

这让 AlphaAvatar 从一个主要围绕 LiveKit Agent 构建的实时助手，进一步向可复用、可扩展、可自托管的全模态个人 AI 助手运行时演进。

长期目标仍然是：

构建一个能够持续观察、理解、记忆、检索，并在时间维度上主动行动的个人 AI Runtime。

项目地址

GitHub: https://github.com/AlphaAvatar/AlphaAvatar Documentation: https://docs.alphaavatar.io Website: https://alphaavatar.ai Demo: https://www.alphaavatar.ai/demo Discord: https://discord.gg/RVBWbb8Xy

欢迎关注 realtime agent、多模态 Memory、Voice AI、数字人、MCP、RAG、Persona 或自托管 AI 的开发者一起交流和参与贡献。