AI Agent · 学习笔记 · 约 9 分钟

Agent 用户画像建模与更新

用户画像的作用，是让 Agent 在下一次理解需求、组织方案和表达结果时，使用已经获得的有效信息。例如，用户明确要求回答简洁，系统就不必每次重新询问；用户这次替家人挑设备，系统也不该把收礼人的需要写成购买者的长期偏好。

画像是否有用，取决于它能否改变合理的决策，而不是标签数量。设计的难点集中在三个地方：记录什么、什么证据足以更新、当前要求与历史默认值如何共存。

从业务决策反推画像字段

不要先造一张包含年龄、职业、兴趣等所有字段的用户表。先列出 Agent 必须做的判断，再问哪些用户信息会影响这些判断。一个代码解释助手可能只需要领域熟悉程度、语言偏好和解释深度，不必了解与任务无关的人口属性。

这些维度并非每个 Agent 都要齐备。能力判断应限定主题，不能因为用户不熟悉一个概念，就把用户整体标为“理解能力低”。“不太喜欢”也不自动等于永久禁止，应结合明确措辞和适用范围确定约束强度。

画像影响的是默认行为。当前用户要求、系统权限与业务约束仍各有自己的效力来源，不能被一个画像分数取代。

将当前、候选和长期信息分开

假设用户以往喜欢详细讲解，这次说“我赶时间，先给步骤”。当前会话应立即改为简洁输出，但这并不证明长期偏好已经改变。三层结构可以表达这种区别：

三层不只是三张表，还需要记录作用域。用户在手机上重视重量，在台式机上重视性能，两者并不冲突。比“当前覆盖长期”更准确的规则是：先判断对象、领域、任务和时间是否重合，再决定覆盖关系。

下面是教学用的偏好记录。强度、置信度和稳定性是不同概念：前者描述偏好的力度，后两者分别描述证据可靠性与跨时间稳定性，不宜压成一个数。

{
  "subject_id": "user-a",
  "domain": "mobile_devices",
  "key": "portability",
  "value": "prefer_lightweight",
  "mode": "soft_preference",
  "scope": "current_purchase",
  "layer": "current",
  "evidence": [
    {"ref": "message-28", "type": "explicit_statement"}
  ],
  "status": "active",
  "review_after": "task_end",
  "version": 1
}

画像应能追溯到原始表达和当时的对象。否则后续很难回答“为什么系统认为我喜欢轻便”。

提取信号时，事实、表达和推断分栏保存

常见来源包括用户明确表达、业务行为、多轮选择过程和外部系统记录。它们都提供证据，但含义不同。

用户说“本次不要黑色”足以产生当前限制，却不足以证明长期讨厌黑色。购买一件低价商品，只能证明发生过一次购买；原因可能是预算、促销或代购。浏览后没有下单，也可能只是暂时离开页面，不能直接标记为不满意。

多轮对话通常比单个点击更能解释偏好。例如，用户先追求性能，后来因为重量放弃某款设备，最终说“每天通勤还是轻一点”。可以记录：本次选择由便携性主导，性能需求作出妥协；不要把最终商品的全部属性都推断成喜好。

外部推荐系统的“高端用户”“价格敏感”标签也应经过语义转换。先确认标签定义、适用商品范围和更新时间，不能只因为来自业务库就把它当作精确事实。

一个实用的提取结果应包含：原始表达、被描述对象、领域、适用时间、候选偏好、支持证据、反证和是否需要确认。模型可以负责抽取这些字段，持久化写入前再由规则检查完整性及允许的状态转换。

实时响应与长期更新使用不同节奏

实时链路负责“这一轮开始就别再犯同样的错”，适合更新当前偏好、禁止项和纠正记录。任务结束后再回看初始要求、修改原因和最终选择，辨认哪些是临时妥协。离线任务负责合并重复证据、检查冲突和发现稳定趋势。

新表达或行为
→ 记录证据并去重
→ 提取当前偏好与候选推断
→ 当前任务即时使用明确要求
→ 任务结束检查选择理由与反证
→ 离线评估稳定性及适用范围
→ 保持候选、升级默认值，或撤销错误判断

这里有两个常见的工程错误。第一，同一条消息被多个异步任务重复消费，使“一次表达”被算成多次证据；可用事件 ID 和提取版本去重。第二，离线任务完成得较晚，用旧画像覆盖了刚收到的纠正；应按版本或事件时间检查更新条件，并保留变更历史。

删除和纠正也要进入更新链。用户撤销某个偏好时，相关缓存、摘要和候选推断应同步失效，不能主表删了，后续又从旧摘要中重新提取回来。

用 4C 整理稳定性证据，不把分数当心理定律

判断“一时兴起”可以检查四类信号：出现次数 Count、持续时间 Continuity、跨场景一致性 Cross-context、用户确认 Confirmation。它们提供一个可解释的证据清单，并不是经过通用验证的心理模型，也不存在适用于所有偏好的固定阈值。

如果需要评分，可将各项映射到同一尺度后加权，但权重必须用实际样本校准。作为纯教学示例，次数项可以采用 C(n) = 1 - exp(-n / τ)，n 是去重后的独立证据数，τ 控制增长速度。它只表达新增重复证据的边际价值递减，不证明用户真实喜欢的概率。

跨场景应记录领域、任务和使用对象，不能仅用会话 ID 近似。确认项则保存用户确认的原话与范围，不应只记“已确认=true”。当用户明确说“以后都先给简要结论”时，可以直接记录该默认值，不必为了凑够次数再多问几次。

对影响较大的推断，确认比增加复杂打分更有效。提示应具体说明系统观察到的现象及将改变的行为，例如：“之后推荐移动设备时，是否默认优先考虑便携？”用户不回答时，不应视为确认。

冲突处理与生命周期

同一范围内，当前明确要求通常优先于历史推断；用户纠正优先于系统猜测；领域偏好优先于泛化默认值。这个顺序用于用户偏好仲裁，不用于突破权限或取代客观事实核验。

例如，长期画像是“回答简洁”，当前输入为“解释完整推导”，本次使用详细解释，长期记录保留。用户进一步说“你之前理解错了，我不是总要简洁”，则应撤销旧泛化，而非仅添加一个与它冲突的新标签。

可使用“候选、活跃、待复核、过期、已撤销”状态，但状态变化不能只靠机械时间衰减。近期兴趣可以设置较短复核周期；明确的长期表达应保留较久；当前任务预算在任务结束后停止默认使用。长期没有再次提及，只说明缺少新证据，不等于偏好已经消失。

出现反证时，先判断是否换了对象或场景。如果只是本次代购，就补充作用域；如果用户明确更改长期习惯，则生成新版本并关闭旧版本效力；证据无法区分时，将推断降为待复核，不要在后台替用户作强结论。

两类业务建模示例

商品选择：品类、使用者与需求规格分开

全局偏好用于默认表达或通用限制；品类偏好记录具体权衡；当前购物需求写清使用者、预算、必要功能、排除项和可妥协项。生成候选前，先将相关画像转为本次需求规格，这样才能解释为什么某个商品被排除。

价格偏好可以参考同品类、相近时间和可比商品集合中的购买价格百分位。它比“高消费”更具体，但促销、商品代际和样本稀疏都会影响结果。没有该品类记录时，相似品类只能给出低置信度参考，不能覆盖用户明确预算。商业推荐也必须遵守硬约束，不能因为存在推广目标就自动放宽预算或禁止项。

人物关系：主体、方向和证据分开

协作助手可用人物 ID、别名与角色解决重名和代词问题。关系需要记录方向：用户信任同事，并不证明同事同样信任用户。事件则分别保存发生时间、参与者、用户陈述、可验证证据、用户感受及尚未证实的解释。

“用户认为同事故意否定方案”是用户视角，不应改写成同事客观上存有恶意。关系变化也应保留时间线：曾经信任、后来因某事件降低信任，与一直关系疏远不同。只有当前任务涉及的人和关系才需要加载；关系画像不能决定对方真实拥有的数据访问权限。

如何验证画像确实帮助了任务

建立包含临时变化、跨品类差异、代购、用户纠正、重复事件和删除请求的测试集。先比较不使用画像、只使用明确偏好、加入候选推断三种策略，再决定复杂建模是否值得。

可观察当前约束遵守率、错误长期升级率、纠正后仍重复使用旧画像的比例、无必要重复询问次数，以及用户主动修改默认值的原因。用户满意度只是结果信号，不能证明某条画像推断正确；还要抽样回看证据与作用域。

运行时只加载会影响当前步骤的字段，并保留画像版本与使用理由。如何将它们组织进模型输入，可继续阅读Agent 上下文编排与记忆召回。