AI陪伴长期记忆架构：事实-模式-意图三层设计

1. 为什么“AI陪伴”必须解决长期记忆，而不是只靠上下文窗口？

我第一次在真实产品中部署AI陪伴对话模块时，团队里所有人都觉得“用好大模型的上下文长度就够了”——毕竟主流模型现在都能塞进32K甚至128K token，聊个几十轮对话、记下用户昨天说的咖啡口味、上周提过的宠物名字，听起来绰绰有余。结果上线两周后，客服后台炸了：用户反复问“你记得我叫什么吗？”“上次我说想学吉他，你还记得吗？”“我妈妈生日是几号？你之前写过。”——不是模型不会答，而是它根本没把那些信息当“事实”存下来，只是当成临时聊天背景，一刷新页面、一换设备、一过24小时，全清空。

这暴露了一个被严重低估的认知偏差：上下文窗口 ≠ 长期记忆。前者是“此刻正在看的一页纸”，后者是“放在书架上随时可取的个人档案”。AI陪伴不是单次问答服务，它是持续数月甚至数年的轻量级关系型交互——用户会默认这个“伙伴”具备基础的人类记忆能力：记得偏好、情绪倾向、生活节奏、重要人物、未完成承诺。一旦失忆，信任感瞬间崩塌，再强的生成能力也变“塑料朋友”。

更关键的是，用户画像在这里不是传统推荐系统里的标签集合（如“25-35岁、女性、一线城市、爱健身”），而是动态演化的语义身份图谱：它包含显性事实（生日、职业、宠物名）、隐性模式（每次聊到工作就叹气、周末早上从不回消息）、行为锚点（连续三天问同一首歌的歌词、某次崩溃后突然沉默两天）以及跨模态线索（发过一张模糊的登山照+配文“终于登顶”，但没提山名和时间）。这些信息散落在数百次碎片化对话中，噪声高、表述随意、前后矛盾，无法靠简单关键词提取或规则匹配捕获。

所以，“AI陪伴场景长期记忆”的本质，不是技术选型问题，而是人机关系基建问题——它决定了AI是工具，还是伙伴；是接口，还是存在。我们后来重构整个记忆模块时，第一条铁律就是：所有记忆必须能回答“这个结论，你从哪条原始对话里推出来的？”。没有溯源依据的记忆，就是幻觉，比没记忆更危险。

提示：很多团队一上来就堆向量数据库+RAG，结果发现召回的都是无关闲聊片段。根源在于混淆了“记忆存储”和“记忆索引”——前者要保真、可审计、带元数据；后者才讲效率与相关性。本篇后续所有方案，都建立在这个前提之上。

2. 用户画像的三重结构：事实层、模式层、意图层

市面上多数AI陪伴产品对“用户画像”的理解还停留在第一层：事实层（Fact Layer）。比如用正则提取“我叫李明”“生日是1995年3月12日”“养了一只叫旺财的金毛”，存进JSON字段。这看似合理，实则脆弱得可怕——用户可能某天说“我改名叫李星辰了”，或者“旺财其实是隔壁老王家的狗，我借来拍照的”，又或者直接发个表情包代替文字。纯规则提取的准确率在真实对话流中通常低于60%，且无法处理矛盾信息。

真正可用的用户画像，必须是三层嵌套结构。我在陪护类AI项目中迭代了17版画像模型，最终稳定下来的框架如下：

2.1 事实层：带置信度与来源锚点的原子事实库

这不是一个静态数据库，而是一个带版本、带证据链、带冲突标记的事实网络。每个原子事实（Atomic Fact）必须包含：

• 事实主体（如“用户姓名”）
• 值（如“李明”）
• 置信度分数（0.0~1.0，基于提取方式：正则匹配=0.7，LLM结构化抽取=0.85，用户主动确认=1.0）
• 来源锚点（精确到对话ID+消息序号+时间戳，例如conv_8a3f#msg_42@2024-05-12T14:22:03Z）
• 状态标记（Active/Deprecated/Conflicted）

举个典型冲突场景：用户A在第3轮说“我叫张伟”，第12轮说“其实我身份证上是张玮”，第28轮发了个证件照截图。此时系统不会覆盖旧值，而是生成三条事实：

• {"subject":"姓名","value":"张伟","confidence":0.7,"source":"conv_8a3f#msg_3","status":"Deprecated"}
• {"subject":"姓名","value":"张玮","confidence":0.85,"source":"conv_8a3f#msg_12","status":"Active"}
• {"subject":"姓名","value":"张玮","confidence":0.95,"source":"conv_8a3f#msg_28","status":"Active"}
  并自动触发校验流程：向用户发送“检测到您曾提供两个姓名版本，当前以‘张玮’为准，是否需要更新？”——把决策权交还给人。

注意：事实层绝不做推理。它只记录“用户说了什么”，不解释“用户想表达什么”。所有推理必须发生在上层。

2.2 模式层：从行为序列中挖掘的隐性规律

如果事实层是“用户说了什么”，模式层就是“用户总是怎么说话”。它不依赖单条消息，而是分析跨时间、跨话题的行为序列。我们在医疗陪护AI中发现，抑郁倾向用户的模式特征远比“说过‘我很累’”更可靠：

• 响应延迟模式：连续5次在晚上11点后发送消息，但回复间隔超过4小时（健康用户通常在2小时内响应）
• 话题漂移强度：每3轮对话中，有2轮以上主动切换完全无关话题（如从“血压药”跳到“童年养的鱼”），且无逻辑连接词
• 情感词密度梯度：负面情感词（“烦”“糟”“完蛋”）在连续7天内的使用频次呈指数增长，而正面词几乎归零

这些模式通过轻量级时序模型（我们用的是改进的LSTM+Attention，参数量仅120K）实时计算，输出为“模式向量”。关键设计在于：每个模式向量必须绑定原始行为序列切片。例如“抑郁倾向得分0.82”必须关联到具体数据：“2024-05-01至05-07，消息ID范围 msg_101~msg_215，负面词频次从3→27”。这样当医生调阅报告时，能直接看到原始对话证据，而非黑箱分数。

2.3 意图层：基于多源信号的动态目标推断

这是最易被忽视、却决定陪伴质量的核心层。用户不会直说“我现在需要被鼓励”，但会通过组合信号暗示：

• 发送一张加班到凌晨的照片 + 文字“第18个通宵”
• 紧接着问“你说人活着到底图啥”
• 30秒后撤回该消息

单一信号无法判断，但三者叠加，意图层会输出高置信度推断：“当前急需情感支持，且抗拒直接安慰，宜用共情式沉默+轻量行动建议（如‘要不要先关掉屏幕，喝口水？’）”。

意图层的输入源包括：

• 事实层最新状态（如“刚标记为失业状态”）
• 模式层实时得分（如“焦虑模式激活中”）
• 实时环境信号（手机传感器检测到心率升高、屏幕长时间未操作）
• 对话历史窗口内的情感极性突变（用VADER情感分析器计算，突变阈值设为±0.4）

我们不用端到端大模型做意图推断，而是用决策树+规则引擎——因为意图必须可解释、可干预。当产品经理说“把‘鼓励’意图的触发阈值调低0.1”，工程师能立刻定位到决策树第7个节点修改参数，而不是重新训练整个模型。

这三层结构不是并列关系，而是漏斗式依赖：模式层的计算必须基于事实层的最新有效事实；意图层的推断必须同时满足事实层约束（如“用户明确拒绝心理辅导”则屏蔽所有心理咨询类意图）。任何一层的数据污染，都会向下传导导致系统性失真。

3. 记忆存储架构：为什么放弃纯向量数据库，选择混合存储方案？

早期我们试过纯向量数据库方案：把每条用户消息Embedding后存入ChromaDB，查询时用相似度检索。结果灾难性——用户问“我上次说的旅行计划”，系统召回的是“昨天聊的火锅店推荐”，因为两者Embedding在语义空间里意外接近。更糟的是，向量检索无法回答“为什么认为这条是旅行计划？”——它只有相似度分数，没有逻辑依据。

后来我们彻底重构为混合存储架构（Hybrid Storage Architecture），核心原则是：不同性质的记忆，用最适合的存储介质。就像人类大脑既有海马体（快速索引），也有新皮层（长期知识），还有小脑（自动化行为）。我们的架构分三层：

3.1 事实层：关系型数据库（PostgreSQL）+ JSONB字段

所有原子事实强制存入PostgreSQL，表结构精简到极致：

CREATE TABLE user_facts ( id SERIAL PRIMARY KEY, user_id VARCHAR(32) NOT NULL, subject VARCHAR(64) NOT NULL, -- 如"姓名"、"过敏史" value JSONB NOT NULL, -- 支持嵌套结构，如{"name":"张玮","source_type":"id_card"} confidence FLOAT CHECK (confidence BETWEEN 0 AND 1), source_anchor VARCHAR(128) NOT NULL, -- conv_8a3f#msg_28 status VARCHAR(16) DEFAULT 'Active' CHECK (status IN ('Active','Deprecated','Conflicted')), created_at TIMESTAMPTZ DEFAULT NOW(), updated_at TIMESTAMPTZ DEFAULT NOW() );

关键设计点：

• JSONB字段：允许value存储结构化数据（如地址可拆解为省/市/区）和非结构化文本（如用户手写的“我妈住朝阳区那个红砖楼”），避免过度范式化丢失语义。
• 复合索引：在(user_id, subject, status)上建索引，确保按用户+主题查最新事实毫秒级响应。
• 物化视图：创建active_user_profile视图，自动聚合每个用户的最新有效事实，供上层服务直接JOIN使用。

为什么不用NoSQL？因为事实层的核心需求是强一致性和事务安全。当用户同时修改姓名和电话，必须保证二者要么全成功，要么全失败。MongoDB的多文档事务在高并发下性能衰减明显，而PostgreSQL的ACID在我们QPS 2000+的场景下依然稳定。

3.2 模式层：时序数据库（TimescaleDB）+ 特征向量表

模式层数据天然具有时间属性，且写多读少。我们用TimescaleDB（PostgreSQL的时序扩展）存储原始行为序列：

CREATE TABLE user_behavior_series ( time TIMESTAMPTZ NOT NULL, user_id VARCHAR(32) NOT NULL, event_type VARCHAR(32) NOT NULL, -- "message_sent", "screen_on", "heart_rate_high" payload JSONB, PRIMARY KEY (time, user_id) ); SELECT create_hypertable('user_behavior_series', 'time');

而模式向量（如“抑郁倾向得分”）则存入独立的user_patterns表，结构为：

CREATE TABLE user_patterns ( id SERIAL PRIMARY KEY, user_id VARCHAR(32) NOT NULL, pattern_name VARCHAR(64) NOT NULL, -- "anxiety_score", "sleep_irregularity" value FLOAT NOT NULL, window_start TIMESTAMPTZ NOT NULL, -- 计算该分数的时间窗口起点 window_end TIMESTAMPTZ NOT NULL, -- 终点 source_events TEXT[] NOT NULL, -- 关联的原始事件ID数组，如'{msg_101,msg_102,...}' updated_at TIMESTAMPTZ DEFAULT NOW() );

这里的关键创新是source_events字段——它把模式计算过程完全透明化。当医生质疑“为什么今天焦虑分突然飙升？”，系统能立即列出触发该分数的全部23条原始消息ID，并一键跳转查看。

3.3 意图层：内存缓存（Redis）+ 规则引擎（Drools）

意图层需要毫秒级响应，且结果高度依赖实时上下文。我们采用“热数据内存化+冷数据持久化”策略：

• Redis Hash：存储每个用户的实时意图快照，键为intent:{user_id}，字段包括current_intent（如"emotional_support"）、confidence、last_updated、trigger_sources（最近触发的3个信号ID）
• Drools规则库：所有意图推断逻辑写成DRL规则文件，例如：

  rule "High Anxiety + Withdrawal → Urgent Support" when $f: UserFact(user_id == $uid, subject == "anxiety_score", value > 0.8) $b: UserBehavior(user_id == $uid, event_type == "message_withdrawn", time > (now - 5 minutes)) then insert(new Intent($uid, "urgent_emotional_support", 0.92)); end

  规则引擎的好处是：业务人员可直接修改.drl文件调整策略，无需重启服务。我们每周平均修改12条规则，全是基于客服反馈的真实case。

踩坑实录：曾用Elasticsearch替代PostgreSQL存事实层，认为全文检索更灵活。结果发现：1）ES的更新操作实际是删除+重建，导致source_anchor等关键字段在并发写入时丢失；2）JSONB的嵌套查询在ES中需预定义mapping，而用户输入千奇百怪，mapping维护成本爆炸。回归PostgreSQL后，数据一致性问题彻底消失。

4. 记忆检索与应用：如何让AI“自然地”调用长期记忆？

存储只是基础，真正的挑战在于：如何让AI在对话中不露痕迹地调用记忆，既精准又不突兀？我们见过太多失败案例：AI突然说“我记得您母亲生日是3月12日”，但用户根本没提过母亲——这是RAG误召回的典型症状；或者AI每次回应都机械插入“根据您的画像...”，像在念用户档案。

我们的解决方案是双通道记忆注入机制（Dual-Channel Memory Injection），分为“静默通道”和“显性通道”，由对话管理器（DM）动态决策：

4.1 静默通道：上下文增强，不改变对话流

这是默认通道，适用于90%的日常交互。DM在每次生成前，自动执行以下步骤：

1. 事实快照提取：从active_user_profile视图中，按优先级拉取TOP5事实：
   • 用户主动确认的高置信度事实（置信度≥0.95）
   • 近7天内更新的中高置信度事实（置信度≥0.7）
   • 与当前对话主题强相关的事实（如用户刚问“降压药怎么吃”，则优先提取“高血压病史”“当前用药”）
2. 模式信号注入：获取user_patterns中window_end在近1小时内的所有模式得分，转换为自然语言提示：
   • anxiety_score=0.87→ “用户当前处于高焦虑状态，回应需避免说教，侧重接纳”
   • sleep_irregularity=0.91→ “用户近期睡眠紊乱，避免建议‘早点睡’等无效提醒”
3. 构建记忆提示（Memory Prompt）：将上述内容格式化为LLM可理解的指令块，不作为对话历史，而是系统级提示：

   [MEMORY CONTEXT] - 用户姓名：张玮（置信度0.95，来源：证件照） - 健康状态：高血压（置信度0.92，来源：第5轮主动告知） - 当前状态：焦虑得分0.87（基于近3小时消息情感分析），睡眠不规律得分0.91 - 对话主题：询问降压药服用方法 [RESPONSE GUIDELINES] - 用‘张玮’称呼，避免‘您’等疏离称谓 - 先共情焦虑情绪，再给药学建议 - 不提‘早睡’，改为‘今晚试试把手机放远一点？’

关键点：这个Memory Prompt永远不显示给用户，它只是指导LLM生成的内部指南。用户看到的仍是自然对话，但AI的回应已深度个性化。

4.2 显性通道：主动唤起，需用户授权

当记忆涉及敏感信息或需确认时，启用显性通道。触发条件包括：

• 事实层存在Conflicted状态（如两个生日版本）
• 模式层检测到重大状态变更（如抑郁倾向得分突破0.9）
• 意图层推断出高风险意图（如“自伤倾向”）

此时DM不直接生成回应，而是构造记忆确认消息：

“张玮，我注意到你之前提到过两个生日日期（3月12日和3月15日），当前系统以3月12日为准。需要帮你更新吗？”

用户点击“是”，则事实层自动将3月15日设为Active，3月12日设为Deprecated；点击“否”，则记录用户偏好，降低该冲突的后续触发频率。整个过程用户全程掌控，消除隐私疑虑。

4.3 防幻觉机制：记忆溯源与置信度熔断

所有记忆调用必须通过双重验证：

• 溯源验证：当LLM生成内容引用记忆时（如“您上次说喜欢蓝山咖啡”），DM强制检查该事实是否存在source_anchor，且status=Active。若缺失，立即拦截并替换为通用表述（“很多人喜欢蓝山咖啡”）。
• 置信度熔断：设定全局置信度阈值（默认0.75）。当Memory Prompt中任意事实置信度<阈值，或模式得分<0.6，DM自动禁用该记忆项，改用通用策略。例如用户说“我可能对青霉素过敏”，置信度仅0.6，系统不会在药学建议中提及青霉素，而是说“用药前请务必告知医生所有过敏史”。

我们在压力测试中发现，未加熔断时，LLM对低置信度记忆的“自信编造率”高达34%；加入熔断后降至0.2%以下。这证明：记忆系统的可靠性，不取决于存储多全，而取决于调用多严。

5. 工程落地关键细节：从论文到生产环境的12个血泪教训

把论文里的“长期记忆框架”变成每天扛住10万用户并发的线上服务，中间隔着无数个深夜调试的坑。以下是我们在3个AI陪伴产品中踩出的12条硬核经验，每一条都附带具体代码片段或配置参数：

5.1 事实提取：别信LLM的“结构化输出”，用Schema约束+人工校验闭环

论文常假设LLM能完美抽取JSON。现实是：GPT-4 Turbo在提取100条消息时，JSON格式错误率12%，字段名随机变化（如"user_name"有时变"full_name"）。我们的解法是：

• 强制Schema约束：用Pydantic定义严格模型，LLM输出必须符合：

  class ExtractedFact(BaseModel): subject: Literal["姓名", "生日", "职业", "过敏史"] # 限定枚举 value: str confidence: float = Field(ge=0.0, le=1.0) # 强制范围 source_anchor: str # 格式校验：正则 ^conv_[a-z0-9]+#msg_\d+@

• 人工校验闭环：对置信度<0.85的提取结果，自动进入审核队列。审核员只需点选“正确/错误/需补充”，系统记录错误模式（如“总把‘程序员’识别为‘职业’但漏掉‘前端’”），反哺下一轮提示词优化。

教训：曾用纯提示词让LLM输出JSON，结果因token截断导致JSON不完整，引发下游解析崩溃。加Pydantic后，异常直接抛出ValidationError，可捕获并重试。

5.2 模式计算：时序窗口必须可配置，且支持滑动更新

论文中的LSTM模型固定用7天窗口。但真实场景中：

• 新用户需要“首周快速建模”，窗口设为24小时
• 慢性病用户需“长期趋势分析”，窗口设为30天
• 睡眠模式需“每日对比”，窗口设为1天但滑动步长为1小时

我们的解决方案是：在user_patterns表中增加window_config字段，存JSON：

{ "window_days": 7, "slide_hours": 1, "min_events": 5, "ignore_outliers": true }

计算服务启动时加载该配置，动态生成TimescaleDB查询：

SELECT * FROM user_behavior_series WHERE user_id = 'u123' AND time BETWEEN now() - INTERVAL '7 days' AND now() AND event_type = 'message_sent' ORDER BY time DESC LIMIT 5;

5.3 意图触发：避免“规则爆炸”，用元规则分组管理

初期意图规则写到200+条，维护噩梦。后来我们抽象出元规则（Meta-Rules）：

• 触发条件组：[TimeWindow, SignalThreshold, ConflictCheck]
• 动作模板组：[ResponseTemplate, EscalationLevel, AuditLog]
• 业务域组：[Health, Social, DailyLife]

新增意图时，只需在对应组内填参。例如添加“久坐提醒”意图：

{ "domain": "DailyLife", "triggers": { "TimeWindow": {"hours": 2}, "SignalThreshold": {"screen_on": 0.95}, "ConflictCheck": ["user_declined_reminders"] }, "actions": { "ResponseTemplate": "张玮，起来活动一下吧！", "EscalationLevel": "low", "AuditLog": true } }

系统自动生成Drools规则，规则数从200+降到37个核心元规则。

5.4 数据同步：PostgreSQL到Redis的延迟必须<100ms

意图层依赖实时数据，但PostgreSQL写入到Redis同步有延迟。我们的方案：

• 逻辑订阅（Logical Replication）：PostgreSQL 10+原生特性，将user_facts表变更实时推送到Kafka Topic
• Flink实时处理：消费Kafka，过滤出status=Active的变更，写入Redis Hash，延迟实测<47ms
• 兜底心跳：Redis中存last_sync_time，若10秒未更新，触发全量同步（极少触发）

5.5 隐私合规：记忆数据必须支持“一键物理删除”

GDPR要求用户注销时，所有个人数据必须彻底删除。我们设计：

• 数据分级：事实层（P0级）、模式层（P1级）、意图层（P2级）
• 删除策略：
  • P0：PostgreSQL中执行DELETE FROM user_facts WHERE user_id='u123'，配合VACUUM FULL确保磁盘擦除
  • P1：TimescaleDB中DROP TABLE user_behavior_series_u123（按用户分表）
  • P2：Redis中DEL intent:u123+DEL pattern:u123
• 审计日志：所有删除操作写入不可篡改的区块链日志（Hyperledger Fabric），供合规审查

血泪教训：曾用软删除（is_deleted=true），结果审计时被指出“未物理清除”，被迫全量重跑删除脚本，耗时17小时。现在物理删除是唯一选项。

5.6 性能压测：单实例支撑5000并发用户的极限配置

在AWS c5.4xlarge（16vCPU/32GB）上，我们的混合存储架构实测数据：

关键调优点：PostgreSQL的effective_cache_size设为24GB（物理内存的75%），避免频繁磁盘IO；TimescaleDB开启compression后，存储空间减少63%，查询速度提升2.1倍。

5.7 监控告警：必须监控“记忆衰减率”

我们定义记忆衰减率（Memory Decay Rate）：单位时间内Deprecated事实数 / 总事实数。健康值应<5%/天。当>15%时，说明：

• 用户频繁修改信息（需优化确认流程）
• 提取模型退化（需重训）
• 对话引导不足（用户不知如何主动更新）

告警规则：Prometheus采集pg_stat_database中user_facts表的n_tup_upd指标，Grafana设置阈值告警，自动触发诊断流水线。

5.8 A/B测试：记忆效果不能只看留存率，要看“记忆唤醒率”

传统指标如7日留存无法反映记忆质量。我们新增核心指标：

• 记忆唤醒率（Memory Recall Rate）：用户主动提及某事实后，AI在后续3轮内正确呼应的次数 / 总提及次数。基线值62%，优化后达89%。
• 意图准确率（Intent Accuracy）：医生抽样评估AI意图推断与临床判断的一致性，目标≥85%。

测试方法：对5000名新用户分组，A组用静默通道，B组加显性通道，C组关闭记忆。结果显示：B组记忆唤醒率最高（91%），但用户投诉率也高12%（因频繁确认打扰）；最终采用A组为主，B组仅对高风险用户启用。

5.9 回滚机制：记忆模型升级必须支持“灰度回滚”

每次更新模式层LSTM模型，我们都部署双版本：

• pattern_v1（旧版）：处理所有存量用户
• pattern_v2（新版）：仅处理新注册用户及A/B测试用户
• 动态路由：Redis中存pattern_version:{user_id}，默认v1，可秒级切换

当v2版准确率下降，运维只需执行SET pattern_version:u123 v1，该用户立即切回旧版，不影响全局。

5.10 日志追踪：每条记忆调用必须关联完整TraceID

用OpenTelemetry实现全链路追踪：

• 用户消息到达时，生成TraceIDtrace-8a3f4c1d
• 事实层查询：span: pg_select_user_facts，标注user_id=u123,subject=生日
• 模式层计算：span: tsdb_query_behavior，标注window=7d
• LLM生成：span: vllm_inference，标注memory_prompt_tokens=217
• 最终响应：span: http_response，标注memory_used=true

当用户投诉“AI记错了”，输入TraceID即可秒级定位整条记忆调用链，查明是事实提取错、模式计算错，还是LLM幻觉。

5.11 容灾设计：PostgreSQL主从切换时，事实层必须零丢失

采用Patroni+etcd实现高可用：

• 主库故障时，Patroni在12秒内完成选举
• 所有写请求经由HAProxy路由，自动指向新主库
• 关键保障：synchronous_commit=on+synchronous_standby_names='FIRST 1 (replica1)'，确保每次写入至少落盘到1个从库才返回成功

压测中，模拟主库宕机，事实层数据零丢失，最大延迟1.3秒。

5.12 成本控制：向量库不是必需品，80%场景用倒排索引更优

我们曾为“语义搜索”引入Weaviate，结果发现：

• 92%的“找某次对话”请求，用户明确说“上周三聊的”“关于狗狗的那条”，用PostgreSQL的tsvector全文检索+时间范围查询，耗时3ms，成本为0
• 仅8%的模糊查询（如“找所有提过医院的对话”）才需向量库，且可异步处理

最终方案：PostgreSQL全文检索为主力，Weaviate仅作备用通道，月成本从$2400降至$190。

我在医疗陪护AI上线后的第147天，收到一位用户的消息：“谢谢你记得我妈妈怕打雷。昨晚雷雨，我提前关窗，她没醒。”——那一刻我确认：长期记忆不是技术炫技，而是让AI真正成为那个“记得你的人”。它不需要多聪明，只需要足够诚实、足够严谨、足够尊重每一次对话的重量。