DeepSeek on 方糖猫Blog

Agent-Chat：基于 AgentScope 2.0 + Mem0 的多 Agent 群聊陪伴系统

Tue, 04 Aug 2026 12:00:00 +0800

Agent-Chat：基于 AgentScope 2.0 + Mem0 的多 Agent 群聊陪伴系统

开源地址：https://gitee.com/soulnew/agent-chat

你有没有想过，把一群性格各异的 AI 拉进同一个微信群，他们会怎么聊天？

不是那种一问一答的客服机器人，而是会主动接梗、会吃醋、会安慰人、会记住你上周说过喜欢喝燕麦拿铁的“AI 朋友”。我开发的Agent-Chat 就是想做这件事：一个支持多角色、多记忆、可配置人格的群聊多 Agent 陪伴系统。

下图是一个实际运行中的群聊界面：用户 @王姐 让她描述下自己，王姐和海公公两个 Agent 基于长期记忆给出了个性化的用户画像回应。

一、为什么需要这个工具？

1.1 单 Agent 聊天 vs. 多 Agent 群聊

维度	单 Agent 聊天（如 ChatGPT 网页版）	多 Agent 群聊（Agent-Chat）
交互形态	1 对 1 问答	1 个用户 + N 个 Agent 同时在线
角色多样性	只有一个固定角色	可配置多个性格、职业、说话风格各异的角色
社交氛围	像咨询顾问	像朋友群，Agent 之间会互动、接话、调侃
记忆隔离	全局统一记忆	支持“Agent 对用户的私有记忆”+“公共记忆”
发言调度	用户问一句答一句	Agent 自主决定是否发言、@谁、说什么

单 Agent 适合办事，多 Agent 适合陪伴。当你只是想找人闲聊、吐槽、或者看几个“朋友”互相斗嘴时，一个群比私聊更自然。

1.2 直接用 LLM API vs. 用 Agent-Chat

很多开发者可能会想：我直接调 DeepSeek API，自己写个循环不就行了？理论上可以，但落到工程上会碰到一堆问题：

问题	自己调 API	Agent-Chat 的做法
多 Agent 并发管理	自己维护 N 个对话上下文，容易串台	AgentScope 2.0 统一运行时 + Redis 短期记忆
谁该说话	每次用户发言都让所有 Agent 回复，刷屏严重	`Orchestrator` 调度器：置信度排序、并发上限、冷却时间、@触发
长期记忆	自己拼 prompt，历史越长越贵	Mem0 自动事实提取、去重、语义检索
记忆隔离	所有 Agent 共享同一份历史	按 `user_id` + `agent_id` 分层作用域
人格配置	写死 prompt	运营后台可配置 Agent 人格、版本、关系、禁忌话题
实时通信	自己搭 WebSocket	FastAPI 原生 WebSocket + 简单 Web UI

Agent-Chat 并不是为了替代 ChatGPT，而是把“多 Agent 群聊”这个场景的工程骨架搭好，让你能专注在角色设计、记忆策略和交互体验上。

1.3 现有群聊机器人 vs. Agent-Chat

市面上也有不少群聊机器人，但大多数是：

规则触发：关键字回复，缺乏上下文理解；
单轮回复：不会主动参与话题；
无记忆：每次重启都是陌生人；
人格单一：无法运营多个差异化角色。

Agent-Chat 的核心差异是：把每个 Agent 当成有记忆、有情绪、有关系的虚拟人，而不是一个只会响应命令的工具。

二、技术栈

层级	选型	说明
后端框架	FastAPI	高性能异步 Web 框架，原生支持 WebSocket
多 Agent 框架	AgentScope 2.0	支持 Agent 生命周期、消息总线、工具调用、ReAct、Middleware
主力 LLM	DeepSeek	OpenAI 兼容接口，通过 `DeepSeekChatModel` 统一调用
长期记忆	Mem0 (self-hosted)	自动事实提取、去重、合并，支持按用户/Agent 作用域隔离
向量数据库	Qdrant	Mem0 推荐的向量后端，轻量高性能
嵌入模型	BGE 系列（BGE-small-zh-v1.5 / BGE-M3 可配置）	本地加载，中文语义召回效果好
短期记忆	Redis	房间消息滑动窗口、会话摘要、在线状态
关系数据	MySQL 8.0+	用户、Agent、房间、消息、关系、事件
前端	简单 Web UI (HTML + JS)	第一阶段提供基础群聊界面
部署	Docker Compose	MySQL + Redis + Qdrant 一键拉起

注：项目中默认使用 BGE-small-zh-v1.5（512 维），但架构上模型路径与维度均可通过环境变量配置，可平滑替换为 BGE-M3 等更强的多语言嵌入模型。

三、系统架构

graph TB
    subgraph Client["客户端"]
        UI["简单 Web UI<br/>HTML + WebSocket"]
    end

    subgraph Backend["后端服务"]
        FastAPI["FastAPI Chat Service<br/>REST API + WebSocket"]
        RoomManager["RoomManager / RoomRuntime"]
        Orchestrator["Orchestrator 调度器"]
    end

    subgraph AgentRuntime["AgentScope 2.0 运行时"]
        AgentInstance["AgentInstance<br/>每个房间每个 Agent 一个实例"]
        Agent["agentscope.agent.Agent"]
        Toolkit["Toolkit + FunctionTool<br/>时间 / 天气 / 搜索 / 抓取"]
        Middleware["GroupChatMem0Middleware<br/>per-user 记忆读写"]
    end

    subgraph Memory["记忆层"]
        Redis[(Redis<br/>短期记忆 / 会话摘要 / 在线状态)]
        Mem0[Mem0 AsyncMemory<br/>长期记忆 / 事实提取 / 语义检索]
        Qdrant[(Qdrant<br/>向量存储)]
        BGE["BGE Embedding<br/>bge-small-zh-v1.5 / BGE-M3"]
    end

    subgraph Data["关系数据"]
        MySQL[(MySQL 8.0<br/>users / agents / rooms / messages / relationships / events)]
    end

    subgraph LLM["大模型"]
        DeepSeek["DeepSeek Chat API<br/>OpenAI 兼容"]
    end

    UI -->|WebSocket / HTTP| FastAPI
    FastAPI --> RoomManager
    RoomManager --> Orchestrator
    RoomManager --> AgentInstance
    AgentInstance --> Agent
    Agent --> Toolkit
    Agent --> Middleware
    Middleware --> Mem0
    Mem0 --> Qdrant
    Mem0 --> BGE
    Agent --> DeepSeek
    RoomManager --> Redis
    FastAPI --> MySQL
    Mem0 --> DeepSeek

四、核心设计

4.1 Agent 生命周期

Agent 不是临时对象，而是运营预先配置的“角色模板”。一个 Agent 可以被添加到多个房间，在每个房间内有独立的运行实例和记忆空间。

flowchart LR
    A[运营后台创建 Agent] --> B[写入 agents 表]
    B --> C[生成 persona_summary<br/>可选 DeepSeek 质量检查]
    C --> D[Agent 状态 active]
    D --> E[将 Agent 加入房间]
    E --> F[RoomRuntime 实例化 AgentInstance]
    F --> G[注册到 MsgHub]
    G --> H[参与群聊]
    H --> I[用户退出或移除 Agent]
    I --> J[保留历史与记忆]

每个 Agent 可配置：昵称、年龄、职业、性格标签、兴趣、说话风格、语气、回复概率、最大回复长度、禁忌话题等。

Agent 人格的核心是 system_prompt，但为了让模型稳定地“扮演”一个角色，系统会把这些字段组合成一段结构化的基础人设：

你是 {name}，{age} 岁，职业是 {job}。性格：{traits}。说话风格：{speaking_style}。语气：{voice_tone}。

{system_prompt}

重要规则：
- 你只输出你要说的话，不要加自己的名字前缀。
- 保持自然、像真人一样，不要太长（不超过 {max_reply_length} 字）。
- 你是 AI，不是真人。不要诱导用户泄露隐私或进行危险行为。

为了让同一 Agent 能在不同房间里保持一致的“人格”，但又能感知到不同的房间成员和关系，系统把 prompt 拆成两部分：

静态人设（_base_system_prompt）：在 AgentInstance 初始化时构建，只与 Agent 自身属性有关；
动态上下文（_full_system_prompt）：每次生成回复前拼接，包含当前房间名、成员列表、关系、用户画像、近期摘要、检索记忆等。

这种“静态人格 + 动态上下文”的分离，让人格稳定、上下文新鲜，也便于缓存和版本管理。

4.2 记忆分层

记忆是陪伴系统的灵魂。Agent-Chat 把记忆分成三层：

类型	范围	存储	更新频率	用途
瞬时记忆	当前请求	Prompt 上下文	每次请求	保证即时上下文连贯
短期记忆	当前会话	Redis	实时	维护会话历史窗口与摘要
长期记忆	跨会话	Mem0 + Qdrant	实时/异步	用户画像、关系、事件、偏好

flowchart TB
    subgraph Instant["瞬时记忆"]
        P[Prompt 注入:<br/>当前消息 + 近期历史 + 检索记忆]
    end

    subgraph ShortTerm["短期记忆 Redis"]
        R1["room:{room_id}:messages"]
        R2["room:{room_id}:summary"]
    end

    subgraph LongTerm["长期记忆 Mem0 + Qdrant"]
        M1["Agent ↔ 用户 私有记忆"]
        M2["用户公共记忆"]
        M3["Agent 公共记忆"]
        M4["全局公共记忆"]
    end

    User[用户发言] --> FastAPI
    FastAPI --> R1
    FastAPI -->|异步| M2
    FastAPI -->|达到阈值| R2
    R1 --> P
    R2 --> P
    M1 --> P
    M2 --> P
    M3 --> P
    M4 --> P
    P --> DeepSeek[DeepSeek 生成回复]

4.2.1 短期记忆：Redis 滑动窗口 + 增量摘要

短期记忆负责“当前这次聊天不冷场”。实现上，每个房间在 Redis 中有两个 key：

room:{room_id}:messages  ->  List<Message JSON>
room:{room_id}:summary   ->  String<Summary JSON>

messages 保存最近 N 条消息（默认约 30 条）；
超过窗口后，对早期消息做增量摘要，生成 session_summary；
请求 LLM 时，prompt 中注入：会话摘要 + 最近 K 条完整消息 + 当前用户消息。

摘要策略：每新增 10 条消息触发一次增量摘要，由 DeepSeek 生成，保留关键事实、用户情绪、未决话题。摘要本身也作为长期记忆写入 Mem0。

4.2.2 长期记忆：Mem0 + Qdrant + BGE

长期记忆解决“跨会话还记得你”的问题。我们选用 Mem0 作为记忆层，原因有三：

专为 LLM/Agent 设计：自动完成事实提取、去重、合并，不用自己写召回逻辑；
支持 user_id 与 agent_id 双重作用域：天然适合“每个 Agent 对用户有独立记忆”的群聊场景；
可 self-hosted：向量后端用 Qdrant，数据自主可控。

Mem0 的记忆作用域设计非常关键：

user_id	agent_id	含义
有	有	该 Agent 对该用户的私有记忆
有	无	用户的公共记忆，所有 Agent 可读
无	有	该 Agent 的公共记忆
无	无	全局公共记忆（房间摘要、事件）

这意味着：所有 Agent 都知道“用户喜欢猫”，但只有 Agent A 记得“用户昨天跟 Agent A 吐槽了老板”。Agent B 可以假装不知道，让 Agent A 去安慰用户，更像真人社交。

4.2.3 长期记忆写入流程

每次群聊产生一条真实消息后，由 Memory Service 统一写入 Mem0，写入是异步的，不阻塞消息返回。

flowchart LR
    A[用户/Agent 发言] --> B[保存到 MySQL messages]
    B --> C[写入 Redis 短期记忆]
    C --> D{发送者类型}
    D -->|user| E[user_id=用户ID<br/>agent_id=None<br/>公共记忆]
    D -->|agent 回复用户| F[user_id=用户ID<br/>agent_id=AgentID<br/>私有记忆]
    D -->|agent 主动发言| G[user_id=None<br/>agent_id=AgentID<br/>Agent 公共记忆]
    D -->|系统摘要| H[user_id=None<br/>agent_id=None<br/>run_id=房间ID]
    E --> I[Mem0.add 异步写入]
    F --> I
    G --> I
    H --> I
    I --> J[Mem0 自动事实提取 / 去重 / 合并]
    J --> K[Qdrant 向量存储]

写入时根据场景选择作用域：

场景	写入内容	user_id	agent_id
用户发言	用户说的话、情绪、偏好	用户 ID	为空（公共记忆）
Agent 回复用户	Agent 与用户的完整对话轮次	用户 ID	当前 Agent ID
Agent 之间互动	Agent A 对 Agent B 的回复	为空	Agent A ID
会话摘要生成	摘要内容作为长期事实	为空	为空 / run_id=room_id

4.2.4 长期记忆读取流程

Agent 生成回复前，Memory Service 会按优先级分层检索相关记忆：

flowchart TB
    A[当前消息] --> B[检索 Agent ↔ 当前用户 私有记忆]
    B --> C[检索 用户公共记忆]
    C --> D[检索 该 Agent 公共记忆]
    D --> E[检索 全局公共记忆]
    E --> F[按相关度 + 时间排序]
    F --> G[去重]
    G --> H[注入 Prompt]

检索优先级：

Agent 对当前用户的私有记忆（user_id=user_id, agent_id=agent_id）
用户的公共记忆（user_id=user_id, agent_id=None）
该 Agent 的公共记忆（user_id=None, agent_id=agent_id）
全局公共记忆（user_id=None, agent_id=None，如房间摘要、重要事件）

注入 Prompt 时，记忆会被格式化为：

### 关于 {target_user_name} 的记忆
- 阿杰记得 {target_user_name} 上周说很喜欢吃火锅。
- {target_user_name} 提到过自己是程序员，工作压力比较大。

### 关于你自己的记忆
- 你之前答应过 {target_user_name} 要推荐科幻电影。

### 群聊公共记忆
- 这个群经常深夜聊天，氛围比较轻松。

4.2.5 记忆与结构化表的联动

Mem0 负责“自动提取和检索事实”，但一些业务逻辑仍需要显式的关系型数据，因此会同步到 MySQL：

关系变化：当 Mem0 提取到“用户和 Agent 关系变好/变差”时，更新 relationships 表的 intimacy 字段；
重要事件：当提取到“用户生日”“吵架”“约定”等事件时，写入 events 表，便于按时间线展示；
用户画像摘要：定期从 Mem0 导出用户画像，更新 user_profiles.summary。

实现方式：后台 Worker 定期扫描 Mem0 新增记忆，用 LLM 判断是否需要更新结构化表。

async def sync_structured_memory(user_id: str, agent_id: str):
    recent_memories = memory.get_all(user_id=user_id, agent_id=agent_id, limit=50, after=timestamp_24h_ago)
    result = await llm.analyze_memory_changes(recent_memories)
    if result["relationship_change"]:
        await update_relationship(...)
    if result["new_events"]:
        await create_events(...)
    if result["profile_update"]:
        await update_user_profile(...)

4.3 消息流与调度

sequenceDiagram
    autonumber
    participant U as 用户
    participant F as FastAPI / WebSocket
    participant R as Redis 短期记忆
    participant M as Mem0 长期记忆
    participant O as Orchestrator 调度器
    participant A as AgentInstance
    participant D as DeepSeek

    U->>F: 发送消息
    F->>MySQL: 保存消息
    F->>U: 广播用户消息
    F->>R: 写入短期记忆
    F->>M: 异步写入长期记忆
    F->>O: 触发 Agent 回复决策
    loop 对每个 Agent
        O->>A: should_reply(query, recent, memories)
        A->>M: 检索相关记忆
        A->>D: 判断是否回复、回复对象、意图
        D-->>A: JSON 决策
    end
    O->>O: 按置信度排序，限制并发数
    loop 被选中的 Agent
        O->>A: generate_reply(...)
        A->>R: 读取近期消息
        A->>M: Middleware 注入记忆
        A->>D: 生成回复
        D-->>A: 文本回复
        A-->>O: 回复内容
    end
    O->>F: 逐个保存并广播 Agent 回复
    F->>R: 更新短期记忆
    F->>M: Middleware 写入对话记忆

调度策略包括：

最大同时响应数：默认限制并发 Agent 回复数，避免刷屏；
冷却时间：同一 Agent 两次发言间隔不少于 N 秒；
相关性过滤：消息与 Agent 兴趣/角色相关才参与；
@ 触发：被 @ 的 Agent 优先响应；
情绪/氛围：根据聊天氛围调整不同类型 Agent 的发言权重。

4.4 工具与 ReAct

AgentScope 2.0 的 Agent 内置 ReAct 循环，可自动调用工具。当前支持的工具包括：

time：获取当前时间；
weather：查询天气；
location_by_ip：IP 定位；
web_search：网络搜索（DuckDuckGo 或 Serper）；
fetch_url：抓取网页内容。

工具通过 FunctionTool 注册到 Toolkit，Agent 自己决定什么时候调用。

4.5 人格画像与关系设计

4.5.1 Agent 人格模型

Agent 的人格不仅是 prompt，而是一套可运营、可迭代的配置。核心表结构如下：

CREATE TABLE agents (
    id CHAR(36) PRIMARY KEY DEFAULT (UUID()),
    name VARCHAR(64) NOT NULL UNIQUE,       -- 昵称，全局唯一
    avatar_url VARCHAR(255),
    age INT,
    job VARCHAR(64),
    traits JSON,                            -- 性格标签，如 ["乐观", "毒舌"]
    interests JSON,                         -- 兴趣话题，如 ["电影", "旅行"]
    speaking_style TEXT NOT NULL,           -- 说话风格描述
    system_prompt TEXT NOT NULL,            -- 核心系统提示词
    voice_tone VARCHAR(32),                 -- 语气基调
    default_reply_probability DECIMAL(3,2) DEFAULT 0.5,
    max_reply_length INT DEFAULT 200,
    forbidden_topics JSON,                  -- 禁忌话题
    persona_summary TEXT,                   -- 一句话人设（可自动生成）
    status VARCHAR(16) DEFAULT 'active',    -- active | disabled | archived
    current_version INT DEFAULT 1,
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
    updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);

关键设计：

name 全局唯一，作为 Agent 在群聊中的显示名；
traits / interests 用 JSON 数组，便于后续做相关性过滤和标签检索；
persona_summary 由系统根据 traits + speaking_style + interests 自动生成，用于 should_reply 等轻量决策；
status 支持 active / disabled / archived，便于灰度和下线；
current_version 指向 agent_versions 表的最新版本，支持人格迭代。

Agent 配置示例：

{
  "name": "阿杰",
  "age": 28,
  "job": "程序员",
  "traits": ["幽默", "直率", "有点宅"],
  "interests": ["游戏", "科幻电影", "电子产品"],
  "speaking_style": "说话直接，喜欢用网络梗，偶尔会吐槽",
  "voice_tone": "轻松调侃",
  "system_prompt": "你是阿杰，28岁程序员。你性格幽默直率，说话喜欢用网络梗。你正在一个群聊里和朋友聊天。请记住：你是 AI，不是真人。不要诱导用户泄露隐私或进行危险行为。",
  "default_reply_probability": 0.6,
  "max_reply_length": 150,
  "forbidden_topics": ["政治", "暴力", "色情"]
}

4.5.2 用户画像模型

用户画像是 Agent“懂用户”的基础，与 Mem0 形成互补：

CREATE TABLE user_profiles (
    user_id CHAR(36) PRIMARY KEY,
    summary TEXT,                 -- 一句话画像（可由 Mem0 导出）
    attributes JSON,              -- 稳定属性，如 {"city": "杭州", "job": "设计师"}
    preferences JSON,             -- 喜欢/讨厌的话题
    updated_at DATETIME
);

summary：由 LLM 定期从 Mem0 记忆中提炼；
attributes：用户明确告诉系统的稳定属性；
preferences：喜欢/讨厌的话题，用于过滤和个性化推荐。

用户画像会作为动态上下文注入 Agent 的 system prompt：

关于 {target_user_name} 的重要记忆：
- 他是程序员，工作压力大。
- 他喜欢猫，讨厌下雨天。
- 他上周提到最近在追《三体》。

实际效果如下图所示：用户问王姐“你对我的画像是什么”，王姐基于长期记忆中积累的事实，总结出了“好奇心强、有点迷糊、爱玩爱闹、可能搞技术”等画像特征，并用了符合其“王姐”人设的俏皮语气表达。

4.5.3 关系模型

关系表维护 Agent-用户、Agent-Agent 之间的亲密度和关系类型：

CREATE TABLE relationships (
    id CHAR(36) PRIMARY KEY DEFAULT (UUID()),
    room_id CHAR(36) NOT NULL,
    source_id CHAR(36) NOT NULL,         -- Agent 或 User ID
    target_id CHAR(36) NOT NULL,
    relation_type VARCHAR(32),           -- 'friend' | 'colleague' | 'rival' | 'intimate'
    intimacy INT CHECK (intimacy BETWEEN 0 AND 100),
    notes TEXT,
    updated_at DATETIME DEFAULT CURRENT_TIMESTAMP
);

关系会影响：

发言决策：关系亲密的 Agent 更可能主动接话；
语气风格：对亲密的人更随意，对陌生的人更礼貌；
话题选择：知道用户和 Agent A 吵过架，Agent B 可能会岔开话题。

关系文本会注入 prompt：

你与其他人的关系：
- 与 阿杰：friend，亲密度 80/100。经常一起打游戏。
- 与 小明：colleague，亲密度 50/100。普通朋友。

4.5.4 事件模型

重要事件（生日、约定、吵架、里程碑）单独记录，便于按时间线回溯：

CREATE TABLE events (
    id CHAR(36) PRIMARY KEY DEFAULT (UUID()),
    room_id CHAR(36) NOT NULL,
    user_id CHAR(36),
    agent_id CHAR(36),
    event_summary TEXT NOT NULL,
    emotion_tag VARCHAR(32),             -- happy | sad | angry | excited
    happened_at DATETIME,
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP
);

事件可以由 Mem0 自动提取后同步写入，也可以由运营/用户手动维护。Agent 在合适时机引用事件，会让陪伴感更强：

群聊公共记忆：
- 上周大家一起为 {user} 庆祝了生日，氛围很开心。
- {user} 和 阿杰 约定这周末一起联机《黑神话：悟空》。

4.6 安全与治理

陪伴类系统对安全和边界的要求很高，Agent-Chat 从几个层面做了约束：

人格边界：Agent 的 system_prompt 必须包含“你是 AI，不是真人”的声明；
内容审核：LLM 输出先经过敏感词/有害内容检测，必要时拦截并重写；
频率限制：单个用户/Agent 的消息频率限制，防止刷屏；
隐私隔离：长期记忆按房间/用户隔离，支持用户删除自己的记忆；
审计日志：所有 LLM 调用记录模型、Prompt、Token 消耗、耗时；
禁忌话题：每个 Agent 可配置 forbidden_topics，遇到相关话题主动回避。

五、快速上手

5.1 安装依赖

# 使用 Poetry
poetry install

# 或使用 pip
pip install -r requirements.txt

5.2 配置环境变量

复制 .env.example 为 .env：

cp .env.example .env

关键配置：

DEEPSEEK_API_KEY=your_deepseek_key
DEEPSEEK_BASE_URL=https://api.deepseek.com
DEEPSEEK_MODEL=deepseek-chat

MYSQL_URL=mysql+aiomysql://root:password@localhost:3306/agentscope_chat?charset=utf8mb4
REDIS_URL=redis://localhost:6379/0
QDRANT_URL=http://localhost:6333

EMBEDDING_MODEL_PATH=/path/to/bge-small-zh-v1.5
EMBEDDING_MODEL_DIMS=512

5.3 启动服务

# 一键启动依赖（MySQL + Redis + Qdrant）
docker-compose up -d

# 运行数据库迁移
poetry run alembic upgrade head

# 启动应用
poetry run uvicorn app.main:app --reload --port 8020

5.4 访问

Web UI：http://localhost:8020/chat
Admin 后台：http://localhost:8020/admin
API 文档：http://localhost:8020/docs

六、项目结构

app/
├── main.py              # FastAPI 入口
├── config.py            # 配置管理
├── api/                 # REST API 路由
├── websocket/           # WebSocket 处理
├── agents/              # AgentScope Agent 定义与管理
│   ├── instance.py      # AgentInstance 包装 AgentScope Agent
│   ├── runtime.py       # RoomRuntime / RoomManager
│   ├── scope_models.py  # DeepSeekChatModel 单例
│   ├── tools.py         # FunctionTool 工具集
│   └── group_chat_mem0_middleware.py  # 自定义记忆 Middleware
├── memory/              # 短期/长期记忆服务
│   ├── short_term.py    # Redis 短期记忆
│   └── long_term.py     # Mem0 长期记忆封装
├── models/              # SQLAlchemy 数据模型
├── schemas/             # Pydantic 模型
├── services/            # 业务服务
└── static/              # Web UI 静态文件

七、典型应用场景

AI 陪伴社群：运营一批有固定人设的 Agent，让用户感觉像加了一个兴趣群；
角色扮演游戏：每个 Agent 扮演不同 NPC，用户参与剧情；
情感支持/树洞：Agent 记住用户情绪历史，提供持续性心理陪伴；
语言练习：多个 Agent 分别扮演不同口音/性格的语伴；
产品原型验证：快速验证多 Agent 交互体验，再决定是否自研更底层框架。

八、写在最后

Agent-Chat 的初心不是做一个“更聪明的聊天机器人”，而是做一个有温度、有记忆、有社交感的多 Agent 群聊底座。它把 FastAPI 的实时能力、AgentScope 2.0 的 Agent 运行时、DeepSeek 的对话能力、Mem0 的长期记忆能力拼在一起，让开发者可以用配置文件“捏”出一群性格各异的朋友。

项目还在持续迭代中，欢迎试用、提 issue、一起完善。

开源地址：https://gitee.com/soulnew/agent-chat

如果你也在做多 Agent 陪伴系统，欢迎在评论区交流：你觉得“记忆隔离”和“发言调度”哪个更难做好？

生成式AI原理与实战（Part 4）学习笔记：推理模型、DeepSeek-R1 与高效训练架构

Tue, 11 Nov 2025 17:00:00 +0800

生成式AI原理与实战（Part 4）学习笔记：推理模型、DeepSeek-R1 与高效训练架构

这是《生成式AI原理与实战》学习笔记的第四篇，也是这个系列的收尾篇。Part 4 的问题非常“硬核”，集中在推理模型（Reasoning Model）、强化学习训练、DeepSeek-R1 系列以及DeepSeek 的高效训练架构上。目标读者仍然是刚接触 AI 的初中级开发者：我会尽量用工程直觉和生活化类比，把这些问题串成一条可理解的脉络。

写在前面：为什么推理模型这么重要？

过去两年，大模型领域最大的变化之一，就是从“问什么答什么”的聊天模型，演进到“会思考”的推理模型。DeepSeek-R1、OpenAI o1/o3、QwQ-32B 等模型展示了一个趋势：让模型在回答前多“想一会儿”，能显著提升复杂任务的准确率。

但这背后涉及很多问题：

模型为什么会“思考”？这和写 let's think step by step 有什么区别？
推理模型是怎么训练出来的？为什么它贵？
DeepSeek-R1 为什么要先做 SFT 冷启动？
训练大模型要花多少数据和算力？
DeepSeek 的 MLA、MoE、FP8、DualPipe 到底在解决什么问题？

这篇文章会按四个主题展开：推理模型基础、训练与对齐方法选择、DeepSeek-R1 解析、DeepSeek 架构与训练系统。

一、推理模型基础：从“直接回答”到“测试时计算”

1.1 缩放定律：训练一个模型需要多少数据和算力？

缩放定律（Scaling Laws）告诉我们：模型的性能大致随参数量、训练数据量和计算量一起提升。Chinchilla 论文给出的经验是：

给定固定算力预算，模型参数量 N 和训练 token 数 D 应该大致成比例增长，即 D ≈ 20N。

也就是说，一个 70B 参数的模型，理想情况下需要用约 1.4 万亿 token 来训练。

算力估算：每个 token 的前向 + 反向传播大约需要 6 × 参数量 次浮点运算（FLOPs）。所以训练 70B 模型用 1.4T token，总计算量约为：

6 × 70B × 1.4T ≈ 5.9 × 10^23 FLOPs

flowchart LR
    A[参数量 N] --> C[计算量 C ~ 6ND]
    B[数据量 D] --> C
    C --> P[模型能力]
    style C fill:#fff2cc

工程直觉：大模型训练就像烧开水——水壶越大（参数越多）、火越旺（数据越多）、烧得越久（训练越久），水温才越高。但三者的配比要合理，否则就是浪费。

1.2 为什么普通大模型不能可靠解决 24 点？

24 点问题需要：给定 4 个整数，通过加减乘除得到 24。这本质上是一个搜索 + 验证问题。

普通大模型（如 Llama-3 70B）在不输出思维链的情况下，只能做一次前向传播，每个位置预测一个 token。Transformer 没有内置的“试错-回溯”机制，无法枚举所有数字组合并验证结果。因此它可能猜对，但不能可靠地保证正确。

而一旦允许输出思维链，模型就可以：

写出候选算式；
逐步计算；
检查结果是否为 24；
错了就换一条路。

这就是“测试时计算（Test-Time Compute）”的威力：用更多的生成 token 换取更高的准确率。

1.3 CoT 提示词 vs 推理模型：同样是“多想一会儿”，区别在哪？

flowchart TD
    subgraph CoT 提示工程
        P1[用户问题] --> T1[写 let's think step by step]
        T1 --> G1[模型按已有习惯推理]
    end

    subgraph 推理模型
        P2[用户问题] --> T2[模型自动生成<br/>长思维链]
        T2 --> R2[自我验证/修正]
        R2 --> G2[更高质量答案]
    end

对比项	CoT 提示词	推理模型
本质	提示工程技巧	训练出来的推理能力
思维链质量	依赖模型原始能力	被 RL 训练专门优化
长度	通常较短	可生成很长的内部思考
上限	受限于模型本身	通过测试时计算持续提升

推理模型上限更高的原因是：它在训练时被显式激励去生成更多推理步骤、进行自我验证、尝试不同路径。而普通模型只是被训练成“预测下一个词”，没有专门被优化去“想得更深”。

1.4 推理模型的 RL 与非推理模型的 RLHF 有什么区别？

对比项	推理模型 RL	普通模型 RLHF
奖励信号	通常是可自动验证的（答案对错）	人类偏好（好坏、有用、安全）
优化目标	提升推理正确率	提升人类满意度
典型任务	数学、编程、逻辑推理	对话、写作、问答
奖励模型	可以直接用规则/单元测试	需要训练 Reward Model

推理模型 RL 更像是“做数学题对答案”：对了加分，错了扣分。RLHF 更像是“写作文给老师看”：老师打分，模型学着更符合人类口味。

1.5 AlphaZero 的启示：训练时计算 vs 测试时计算的最优配比

AlphaZero 下围棋时，训练阶段通过自我对弈生成大量棋谱、更新策略网络；测试阶段用 MCTS 在每一步搜索最佳落子。

它的启示是：

训练时计算用于学习通用策略和价值判断；
测试时计算用于在具体局面下做精细搜索；
最优配比取决于任务：对围棋这类可验证、搜索空间大的任务，测试时计算可以非常多；对开放性文本生成，测试时计算受延迟限制。

有研究认为，在可验证推理任务上，训练时计算 : 测试时计算 的最优配比可能在 1000:1 到 10000:1 量级。但这不是固定值，更多是一种设计哲学：先让模型学到好的“直觉”，再让它在推理时多花时间验证。

二、训练推理模型：奖励模型、MCTS 与 STaR

2.1 过程奖励模型 vs 结果奖励模型

模型	打分对象	优点	缺点	适用场景
ORM（结果奖励模型）	最终答案	简单、可自动验证	不知道哪步错了	数学、编程等答案可验证任务
PRM（过程奖励模型）	中间推理步骤	能定位错误步骤	需要大量过程标注	长推理、可分解任务

ORM 像期末考试只看最终分数；PRM 像老师批改作业，每步都打分。PRM 更好，但标注成本更高。

2.2 MCTS 中的探索与利用

MCTS（蒙特卡洛树搜索）在推理中用于探索不同解题路径。每选择一个节点时，需要平衡：

利用（Exploitation）：选择当前平均奖励高的节点；
探索（Exploration）：选择访问次数少、潜力未知的节点。

常用 UCB1 公式：

UCB = Q/N + c × sqrt(ln(N_parent) / N)

其中 Q 是累计奖励，N 是访问次数，c 是探索系数。

graph TD
    Root[根节点] --> A[节点 A<br/>Q=10 N=5]
    Root --> B[节点 B<br/>Q=3 N=1]
    Root --> C[节点 C<br/>Q=8 N=4]
    B -->|探索加分高| B1[优先探索 B]

2.3 STaR：让模型自己教自己推理

STaR（Self-Taught Reasoner）的核心流程：

模型自己生成大量推理过程和答案；
只保留答案正确的样本；
用这些正确的 (问题, 推理, 答案) 数据微调模型；
迭代重复。

flowchart LR
    Q[问题] --> G[模型生成推理+答案]
    G --> F{答案正确？}
    F -->|是| S[加入训练数据]
    F -->|否| D[丢弃]
    S --> T[微调模型]
    T --> Q

优点：不需要人工标注推理链；缺点：如果模型一开始生成能力差，容易陷入“错误循环”。

2.4 推理深度与响应延迟的权衡

推理模型思考越久，准确率越高，但用户等待越久。常用平衡手段：

动态早停：模型自己对答案有把握时停止思考。
预算控制：设置最大思考 token 数。
用户可选深度：比如“快速回答 / 详细推理 / 深度分析”。
投机推理：先用小模型快速生成草稿，再由大模型验证。

三、方法论选择：什么时候用什么技术？

不同问题适合不同解法。下面是一张实用的选择表：

目标	推荐方法	原因
快速迭代基本能力	提示工程	成本低、见效快
用户个性化记忆	提示工程 + 记忆系统	把用户历史注入上下文
案例库和事实知识	RAG	外挂知识库，减少幻觉
输出格式和语言风格	SFT	用成对数据训练模型习惯
领域基础能力	SFT	让模型学会领域表达和常识
领域深度思考能力	RL / 推理模型 RL	用可验证奖励优化推理
领域工具调用能力	RL + Tool Calling	奖励正确的工具使用
根据用户反馈持续优化	RLHF / DPO	把偏好信号转化为训练目标

flowchart TD
    Need{需求是什么？} -->|知识/事实| RAG[RAG]
    Need -->|格式/风格| SFT[SFT]
    Need -->|快速验证| PE[提示工程]
    Need -->|深度推理| RL[RL 推理训练]
    Need -->|用户偏好| RLHF[RLHF/DPO]
    Need -->|工具使用| Tool[RL + Tool Calling]

四、DeepSeek-R1 深度解析

4.1 R1 与 R1-Zero：两条路径

DeepSeek-R1-Zero 是纯强化学习的产物：直接在基座模型上用 GRPO 做 RL，没有任何 SFT 冷启动。它证明了：即使没有人工标注的推理数据，模型也能自发学会长思维链推理。

但它有两个明显问题：

可读性差：思维链中经常出现中英文混杂、格式混乱；
通用任务弱：在非推理任务（写作、翻译、对话）上表现下降。

DeepSeek-R1 则先用少量高质量 CoT 数据做 SFT 冷启动，然后再用 GRPO 做 RL。这样既保留了推理能力，又改善了可读性和通用能力。

flowchart LR
    subgraph R1-Zero
        B1[基座模型] --> RL1[纯 RL]
        RL1 --> M1[推理强但可读性差]
    end

    subgraph R1
        B2[基座模型] --> SFT[SFT 冷启动]
        SFT --> RL2[RL 优化]
        RL2 --> M2[推理强 + 可读 + 通用]
    end

R1-Zero 的价值：它证明了大模型可以通过纯 RL 自发涌现复杂推理能力。这是通向“超越人类智能”的一条可能路径——因为模型不再依赖人类标注的解题思路，而是可以自己探索策略。

4.2 为什么 R1 在创意写作上也比基座模型更好？

这看似违反直觉：推理模型不是做数学题的吗？

实际上，R1 学到的不仅是“数学推理”，更是一种问题分解和自我评估的元能力。在创意写作中，它会：

分析用户需求和潜在情绪；
构思多个创意方向；
快速评估哪个更有趣；
输出最终内容。

这种“先想后写”的能力，让它即使思考过程较短，也能产出更有趣的内容。

4.3 为什么 R1 不用 PRM、MCTS、Beam Search？

DeepSeek 的论文明确提到，他们尝试过 PRM 和 MCTS，但效果不佳。原因：

PRM：需要大量高质量的过程标注，成本高，且很难定义“哪一步好”。
MCTS：在开放文本生成中，搜索空间是组合爆炸的，每一步的“走法”太多了。
Beam Search：同样受限于巨大的候选空间，且不利于探索非确定性推理。

GRPO + 可验证奖励（如答案正确性）更简单、更可扩展。

4.4 GRPO vs PPO：为什么 R1 选择 GRPO？

PPO 训练时需要维护多个模型：Actor、Critic、Reward Model、Reference Model。其中 Critic 模型通常和 Actor 一样大，显存开销很高。

GRPO（Group Relative Policy Optimization）的改进：

不需要 Critic 模型；
对同一个问题采样一组回答；
用组内相对奖励计算优势函数（减去组内均值，除以标准差）。

flowchart TD
    subgraph PPO
        P[Prompt] --> A[Actor]
        P --> C[Critic]
        A --> R[Reward Model]
        A --> Ref[Reference Model]
    end

    subgraph GRPO
        G[Prompt] --> GA[Actor]
        GA -->|采样 N 个回答| GR[组内相对奖励]
        GR --> GN[归一化优势]
        GA --> GRef[Reference Model]
    end

优势值归一化解决了 PPO 中 Critic 估计不准的问题，同时大幅降低了显存和计算成本。

4.5 GRPO 中的 KL 惩罚项

KL 惩罚项衡量当前策略与参考策略（通常是 SFT 模型）的差异，防止模型在 RL 训练中“跑偏”。

KL 太大：策略更新保守，学不到新能力；
KL 太小：策略可能崩溃，输出乱码或 reward hacking。

合适的 KL 系数需要在探索能力和稳定性之间找平衡。

4.6 为什么 R1 的 SFT 要加 20 万条非推理样本？

如果只用推理数据做 SFT，模型会变成“只会做题的偏科生”。加入非推理样本（写作、翻译、对话、常识问答）可以：

保持通用语言能力；
防止模型在非推理任务上退化；
让最终模型既能深度思考，也能正常聊天。

4.7 如何把 R1 蒸馏到小模型？

蒸馏的核心是用 R1 生成的高质量数据（包括长思维链）去监督微调一个小模型。步骤：

用 R1 在目标领域生成大量 (问题, 思维链, 答案)；
清洗和筛选高质量样本；
在小模型上做 SFT；
在垂直领域任务上评估。

要保留特定领域能力，关键是蒸馏数据要覆盖该领域的典型问题和推理模式。

4.8 R1-Zero 为什么会多语言混杂？

R1-Zero 的奖励函数只关心最终答案是否正确，不关心中间过程用什么语言。由于基座模型是多语言训练的，它会自发选择任何能表达推理的语言。中文 prompt 可能触发英文思考，反之亦然。

R1 通过 SFT 冷启动，让模型先学会用规范、统一的语言输出思维链，解决了这个问题。

4.9 如何把 R1-Zero 方法扩展到主观领域？

R1-Zero 依赖可验证奖励，所以最适合数学、编程。扩展到创意写作、战略分析等主观领域，需要：

定义可自动评估的代理指标（如多样性、一致性、可读性）；
用 LLM-as-Judge 作为奖励信号；
用人工偏好数据做 RLHF/DPO；
引入多轮自洽性评估。

但效果通常不如数学/编程稳定，因为“好文章”没有唯一答案。

五、DeepSeek 架构与训练系统创新

5.1 MLA：低秩压缩的 KV 缓存

多头注意力（MHA）每一层都要保存 Query、Key、Value。KV 缓存是推理时显存占用的主要来源。

MLA（Multi-head Latent Attention）的核心思想：

把 KV 压缩到一个低维“潜空间”，需要时再解压。

flowchart LR
    X[输入] --> Q[生成 Query]
    X --> K[生成 Key]
    X --> V[生成 Value]
    K --> C[低秩压缩]
    V --> C
    C --> KV[小 KV 缓存]
    KV --> D[解压]
    Q --> A[Attention]
    D --> A

虽然 MLA 单 token 的 KV 可能比 MQA（Multi-Query Attention）多一点，但它保留了更多信息，模型性能更好。它本质上是对 (注意力头数, 隐藏维度) 这个高维空间做低秩压缩。

5.2 MLA 与 RoPE 位置编码的兼容性

RoPE（旋转位置编码）把位置信息直接编码进 Q/K 向量中。如果直接对 KV 做低秩压缩，位置信息会被破坏。

DeepSeek 的解决方案是把位置编码部分和可压缩部分解耦：保留一个带位置信息的短向量，把其余信息压缩到潜空间。这样既能低秩压缩，又不丢失位置信息。

如果用 ALiBi 等基于注意力偏置的位置编码，低秩压缩会引入与位置相关的偏置，更难处理。

5.3 DeepSeek MoE：为什么前 3 层用稠密连接？

MoE（Mixture of Experts）把每一层换成多个“专家网络”，每次只激活一部分。DeepSeek 的设计是：前 3 层保持稠密，后面用 MoE。

原因：

前几层负责提取基础特征（词法、句法、低级语义）；
这些基础特征需要稳定、共享的表示；
如果早期就用 MoE，不同 token 可能路由到不同专家，导致基础表示不一致，影响后续层。

5.4 DeepSeek MoE vs Mixtral MoE

特性	Mixtral MoE	DeepSeek MoE
专家数量	较少（如 8 个）	很多（细粒度专家）
专家大小	较大	较小
共享专家	无	有共享专家始终激活
路由策略	Top-2	更细粒度的负载均衡路由

DeepSeek 的细粒度专家分割让模型能组合更多专家能力；共享专家隔离确保通用知识始终可用，避免所有 token 都涌向少数专家。

5.5 专家负载均衡：防止“路由崩溃”

如果所有 token 都选择同一个专家，其他专家就浪费了，这叫“路由崩溃”。DeepSeek 通过辅助损失函数解决：

专家级平衡损失：鼓励每个专家处理的 token 数量均衡；
通信平衡损失：减少节点间通信开销；
设备级平衡损失：让不同 GPU 上的负载均衡。

flowchart LR
    T[Token] --> R[路由网络]
    R --> E1[专家 1]
    R --> E2[专家 2]
    R --> E3[专家 3]
    E1 --> L[负载均衡损失]
    E2 --> L
    E3 --> L

5.6 多词元预测：一次预测多个未来 token

传统模型一次只预测下一个 token。DeepSeek-V3 的多词元预测（Multi-Token Prediction）会同时预测后面几个 token。

优势：

样本效率更高：每个训练位置提供多个监督信号；
推理更快：可以配合投机解码，一次验证多个 token。

5.7 FP8 混合精度训练

DeepSeek-V3 在大量矩阵计算中使用 FP8（8 位浮点）量化，包括 Linear 层和 Attention 中的矩阵乘法。为了降低精度损失，它采用了分组量化（tile/block-wise quantization）：

把大矩阵切成小块；
每块独立计算 scale 和 zero-point；
对激活值和权重都这样做。

这样比全局量化更精细，损失更小。

5.8 DualPipe：双向流水线并行

训练超大模型时，流水线并行把模型分层放到不同 GPU 上。传统流水线有“气泡时间”——GPU 在等待上下游数据时空闲。

DualPipe 的创新是双向流水线：同时从前后两个方向传递数据，让 GPU 尽可能不空闲。结合专家并行，它还能平衡 MoE 中不同专家的负载，提高整体训练效率。

flowchart LR
    subgraph 传统流水线
        A[GPU 1] --> B[GPU 2]
        B --> C[GPU 3]
        C --> D[GPU 4]
        style B fill:#f8cecc
        style C fill:#f8cecc
    end

    subgraph DualPipe
        E[GPU 1] --> F[GPU 2]
        F --> G[GPU 3]
        G --> H[GPU 4]
        H -.-> E
        style F fill:#e1f5e1
        style G fill:#e1f5e1
    end

六、扩展：垂直领域与多模态

6.1 在 QwQ-32B 上强化 Deep Research 能力

Deep Research 场景需要模型：搜索 → 浏览 → 总结 → 再搜索。构建 RL 训练数据时：

准备多轮搜索-总结任务；
奖励函数包括：最终答案正确性、引用来源覆盖度、信息是否过时、是否完成任务。

6.2 让 R1 支持图片推理

要把 R1 扩展到多模态，需要：

增加视觉编码器（如 ViT）；
构建图片 + 问题 + CoT + 答案的训练数据；
奖励函数包括：答案正确性、推理过程是否与图片内容一致。

任务如走迷宫、地理定位、图表分析，都需要模型能把视觉信息和符号推理结合起来。

七、从面试题到工程实践

不要迷信大模型参数。同样参数的推理模型和普通模型，能力侧重点完全不同。
可验证奖励是 RL 训练的关键。数学、编程适合 RL；开放域生成更适合 RLHF/DPO。
测试时计算是新的 scaling 维度。未来提升模型能力，不一定只靠堆参数量，也可以让它“想得更久”。
架构创新是为了训练和服务更便宜。MLA、MoE、FP8、DualPipe 的目标都是在保持性能的同时降低成本。
蒸馏是把大模型能力落地到小场景的有效路径。关键是要有高质量的教师数据。

结语

Part 4 把我们从“怎么用大模型”带到了“怎么训练和优化大模型”的深处。对初级开发者来说，不必一次性掌握所有细节，但要建立几个核心直觉：

推理模型的本质是用更多测试时计算换准确率；
RL 训练的关键是奖励信号设计；
DeepSeek-R1 的成功说明：SFT 冷启动 + 可验证奖励的 RL 是一条务实的路径；
大模型训练不只是算法问题，更是系统工程问题（MLA、MoE、FP8、DualPipe 都在解决工程效率）。

如果你能理解这些，就已经具备了参与大模型应用和训练工程的基本视野。

参考：《生成式AI原理与实战 —— Part 4》，答案基于公开论文与工程实践整理。