Mem0 Python SDK (v2.2.0)
Mem0 发布 Python SDK v2.2.0。新增功能：在 MemoryClient 与 AsyncMemoryClient 中加入 User Profiles，提供 get_profile()、generate_profile()、get_profile_settings()、update_profile_settings()、sample_profiles() 和 get_profile_job()。Profile 是按项目配置的 JSON Schema 约束、由 LLM 从该用户记忆中填充的结构化 JSON 摘要，生成过程异步；每个 job POST 携带 Idempotency-Key，重试时传同一 idempotency_key 可避免启动第二个 job。修复：Valkey 向量存储 insert() 与 update() 路径对 None 时间戳做防护，改用 .get() 加真值检查，使 None 落到默认值，与 Redis provider 行为一致。
发展脉络
- 首次出现Mem0 Python SDK (v2.2.0)Mem0
- 行业反馈Mem0 Python SDK (v2.2.1)Mem0
- 当前判断记忆正从向量检索的附属能力变成独立的产品接口：画像以 JSON Schema 约束、异步生成、幂等提交，形态更接近数据管道而非单次查询。若这一模式被更多记忆或 Agent 框架跟进，竞争点会从「存得下」转向「画像 schema 与更新策略谁更可控」。目前证据仅来自单一 SDK 发布说明，尚不足以判断采用规模。可验证下一信号：其他记忆或 Agent 框架是否引入同类 profile 接口。Agent Pulse · 分析
Mem0 在 v2.2.0 中把「用户画像」做进 Python SDK：MemoryClient 与 AsyncMemoryClient 新增 get_profile()、generate_profile()、get_profile_settings()、update_profile_settings()、sample_profiles()、get_profile_job()。按发布说明，profile 是由项目级 JSON Schema 约束、由 LLM 从该用户既有记忆填充的结构化 JSON 摘要，生成异步执行；每个 job POST 带 Idempotency-Key，重试时复用同一 key 可避免重复建 job。同版本还修复 Valkey 向量存储 insert()/update() 对 None 时间戳的处理，改为 .get() 加真值检查，使 None 走默认值，与 Redis provider 对齐。
从发布说明看，Mem0 把记忆层从「检索片段」推进到「按 schema 聚合的持久画像」，并把生成做成异步 job 加幂等键，说明画像生成被视为可能失败、需要重试的长耗时操作。工程上值得关注的是 schema 由项目配置、内容由 LLM 填充，因此画像质量与 schema 设计强耦合；Valkey 的 None 时间戳修复也提示多后端行为一致性仍是维护成本来源。可验证下一信号：官方文档是否给出 profile 的 schema 示例与 job 状态语义。
记忆正从向量检索的附属能力变成独立的产品接口：画像以 JSON Schema 约束、异步生成、幂等提交，形态更接近数据管道而非单次查询。若这一模式被更多记忆或 Agent 框架跟进，竞争点会从「存得下」转向「画像 schema 与更新策略谁更可控」。目前证据仅来自单一 SDK 发布说明，尚不足以判断采用规模。可验证下一信号：其他记忆或 Agent 框架是否引入同类 profile 接口。
对使用 Mem0 的团队，画像接口把「用户长期状态」变成可配置 schema 的产物，便于在应用层做个性化与状态注入；异步加幂等键降低了重试导致重复计费或重复 job 的风险。但画像由 LLM 填充，其准确性与成本需自行评估，证据未给出任何性能或成本数据。
若 profile 接口被实际使用，后续可观察的演进方向是 schema 版本迁移、画像过期与重算策略，以及多后端（Redis、Valkey 等）行为对齐。这些均属推断，需以官方文档或后续版本说明为准。