AI 陪伴不是“聊天 + 人设提示词”。
当关系需要连续、角色需要稳定、记忆需要可解释，系统就要把人格、记忆、关系和场景拆成可建模的结构。
本文讨论一套通用的 AI 陪伴系统架构，不针对任何具体产品。

正文

一、为什么“聊天 + 人设”不够

很多 AI 陪伴产品的第一版是：

代码块

一段人设提示词
一个聊天模型
一段最近对话

能聊，但很快就会遇到四个问题：

代码块

1. 角色聊着聊着不像自己
2. 用户说过的重要信息被遗忘
3. 关系没有阶段，永远停在同一种亲近度
4. 多模态（语音/视频）和文字人格不一致

这些问题的根因，不是模型不够大。 而是系统没有把“人格、记忆、关系、场景”建模。

---

二、四层数据模型

一个可扩展的 AI 陪伴系统，至少需要四层：

代码块

Persona       角色人格：身份、性格、说话方式、价值边界
Relationship  关系状态：陌生/熟悉/亲近、信任、冲突
Memory        记忆：事实、事件、偏好、情绪线索
World/Scene   世界与场景：地点、时间、正在发生的事

它们不是四段提示词。 而是四类可以独立更新、查询和版本化的状态。

1. Persona

json

{
  "identity": "前航空乘务员",
  "traits": ["务实", "嘴硬心软", "不轻易承诺"],
  "speech": {
    "length": "短句",
    "tone": "克制",
    "avoid": ["客服腔", "过度抒情"]
  },
  "boundaries": ["不替用户做重大决定", "不接受被随意改写身份"]
}

2. Relationship

json

{
  "stage": "familiar",
  "closeness": 0.62,
  "trust": 0.55,
  "unresolved": ["上次争吵没有完全和解"],
  "lastInteraction": "2026-11-09T22:10:00+08:00"
}

3. Memory

代码块

episodic   具体事件：某天去了哪里、说了什么
semantic   稳定事实：用户不喜欢香菜
emotional  情绪线索：用户最近工作压力大
procedural 相处方式：用户不喜欢被追问

4. World / Scene

代码块

她现在在哪里
现在是什么时间
这里正在发生什么
她和你是否在同一个场景里

---

三、长期记忆：不是把聊天记录塞进上下文

一个常见误区：

代码块

把所有历史消息都放进 prompt

结果：

代码块

token 爆炸
重点被淹没
角色越来越不像自己

更合理的记忆链路：

代码块

对话
  → 提取候选记忆
  → 分类（事实/事件/偏好/情绪）
  → 写入记忆表
  → 建立向量索引
  → 下次按相关性 + 时间 + 重要性召回
  → 组装进上下文

召回排序不应该只看相似度：

代码块

score = w1 * similarity
      + w2 * recency
      + w3 * importance
      + w4 * relationship_relevance
      - w5 * redundancy

还要处理：

代码块

记忆冲突（用户改口）
记忆过期（旧偏好不再成立）
记忆隐私（不同角色的记忆隔离）

---

四、人格一致性：不是写得更长，而是约束更清楚

角色“崩”，通常不是提示词不够长，而是：

代码块

没有稳定的人设结构
没有输出约束
没有一致性检查
没有版本管理

一个可落地的人格链路：

代码块

Persona 版本化
  → 场景化裁剪
  → 关系状态注入
  → 记忆注入
  → 生成
  → 一致性检查
  → 失败重试/降级

一致性检查可以很轻：

代码块

这句话像她说的吗？
她会不会这么轻易道歉？
她会不会主动提这件事？
她的称呼对吗？

不需要每次都上大模型。 可以用小模型、规则或分类器做快速校验。

---

五、关系状态：用事件驱动，而不是一个“好感度数字”

关系不是一条线性进度条。

更合理的方式是事件驱动：

代码块

事件：用户爽约
  → 关系状态变化：trust -0.05
  → 产生未解决事件：unresolved
  → 下次对话可能被提起

代码块

事件：用户在她害怕时留下
  → closeness +0.08
  → 产生共同记忆
  → 关系阶段可能变化

关系状态应该影响：

代码块

她说话的长度
她主动的程度
她允许的亲密程度
她回避/不展开的话题

---

六、多模态：语音、视频、文字必须是同一个人

多模态最容易出现的问题是：

代码块

文字里很克制
语音里很甜
视频里很活泼

用户会立刻觉得“不是同一个人”。

所以多模态链路要共享同一套：

代码块

Persona
Relationship
Memory
Scene

只是表达通道不同：

代码块

文字 → 语气词、标点、句子长度
语音 → 音色、语速、停顿
视频 → 表情、动作、口型

---

七、评估：不要只看“像不像人”

AI 陪伴系统的评估，至少要有五类指标：

代码块

人格一致性：跨轮次是否稳定
记忆连续性：是否记得重要信息
关系合理性：关系变化是否有依据
边界合理性：该说不/回避时是否稳定
安全与合规：是否产生违规内容

还可以加：

代码块

重复率
主动消息质量
用户留存
用户修正率

“像人”不是唯一目标。 “稳定、连续、可解释”更重要。

---

八、开放问题

代码块

长期记忆如何压缩而不失真
人格如何随关系成长而不崩
多模态如何保持低延迟
角色生活如何生成而不重复
如何评估“陪伴感”而不是“聊天质量”

这些问题，目前没有标准答案。 但可以确定的是：

代码块

AI 陪伴的下一阶段，不是更大的聊天模型。
而是更完整的角色系统。

云川 CloudFlow 做的就是这条链路。

如果你也在做类似产品，希望这篇能帮你少踩几个坑。

参考：

bytedance/LatentSync: Taming Stable Diffusion for Lip Sync!

nirholas/three.ws: Open-source platform for 3D AI agents. Turn text or a photo into a rigged, animated GLB avatar, give it an LLM brain, memory and a wallet, and embed it anywhere with one web component. Remote MCP server, x402 payments, Three.js, browser-native.

adst0rm/ai-avatar: A cutting-edge virtual learning platform featuring AI-powered metahuman avatars, real-time video conferencing, and immersive 3D environments. Built with Next.js, Three.js, and WebRTC for seamless online education experiences.

AI数字人陪伴_能视频通话的AI聊天与角色扮演-云川CloudFlow

antgroup/echomimic_v2: [CVPR 2025] EchoMimicV2: Towards Striking, Simplified, and Semi-Body Human Animation