Agent个性化偏好理解：从长期行为建模到评估优化

我研究Agent系统的时间越长，越觉得大多数Agent像一条只有七秒记忆的鱼：你在一个会话里告诉它"以后发邮件都抄送给我助理"，它这一轮做得很好，但第二天又忘了。这也正是AAAI'26那篇关于Agent个性化偏好理解的Oral让我眼前一亮的原因——它明确把"用户长期行为"纳入Agent的推理闭环，并且给出了可评估、可优化的完整思路，而不是继续在上下文窗口里堆tokens。

这篇分享，我打算从一个实际做Agent研发的视角，拆解这类系统到底难在哪、该怎么评估、又该从哪些方向优化。无论你是做Agent框架、做推荐系统，还是单纯在调教自己的AI助手，这篇应该都能给你一些能落地的判断标准。

1. 从"任务型对话"到"行为型人格"：Agent个性化理解的问题边界

1.1 单轮聪明的假象：上下文窗口再大也装不下人生

先说一个最反直觉的事实：很多Agent产品看起来单轮对话很聪明，是因为它每次都能把当前问题处理得很好，但你一旦跨出这个会话窗口，它就完全"失忆"了。有人会说，加大上下文窗口不就行了？现在模型已经支持百万级token了，把用户一年的聊天记录、点击日志、购买记录都塞进Prompt里，不是很直观吗？

问题在于，长期行为不是"更多文本"，而是"结构化的事件流"。你点过什么、搜过什么、取消过什么、在哪个时间点拒绝了什么，这些事件如果全部平铺到上下文里，模型的注意力会被大量无关细节稀释。而且成本不是线性增长的，一个活跃用户一天可能产生几千条行为记录，一年就是上百万条事件，逐个传给大模型既慢又贵，更重要的是，真正影响偏好判断的往往是少数几个"关键转折点"，而不是全部数据。

我习惯用一个类比来理解这个困境：一个律师接手老客户，不能只看最近三天的邮件，而是要翻过去五年的案卷。但律师不会把五年卷宗全部打印出来堆在桌上，他会先做案卷摘要、按主题分类、标出关键时间点，再根据当前案件调取相关材料。Agent做长期行为理解，本质上也是同一套操作：压缩、索引、按需提取。AAAI'26这项工作想要解决的核心，正是这个"案卷管理"过程中的评估与优化问题，而不是简单地把更多历史记录喂给模型。

1.2 个性化偏好的三层结构：显性偏好、隐性偏好、情境偏好

聊偏好之前，我们先定义清楚"偏好"是什么。很多团队在做的所谓个性化，其实只是统计用户点击了哪个品类，然后加大类似内容的推荐权重。但Agent需要理解的偏好，至少包含三个层次。

第一层是显性偏好。用户主动表达出来的规则和要求，比如"我不吃香菜""汇报邮件控制在三行以内""我喜欢用表格而不是幻灯片"。这种偏好最容易被提取，也最容易被验证，但恰恰是这个最简单的问题，很多Agent产品都做不好，因为它们从不把用户的指令沉淀成长期规则。

第二层是隐性偏好。用户没有明说，但从行为模式中可以推断出来。比如一个用户连续三周都在周日晚上九点左右打开日历规划下周日程，说明他养成了"周日晚上做周计划"的习惯。再比如用户总是把某个同事的邮件标记为已读但不回复，说明这个同事的信息优先级很低。隐性偏好是长期行为建模最核心也是最难的部分，因为需要跨时间点关联事件，而不是单看一次行为。

第三层是情境偏好。同一个用户在不同情境下可能有完全不同的偏好。工作日下午两点和他沟通项目进展，他希望回复越快越好；但晚上十点如果你还给他推送工作消息，他会非常反感。情境偏好意味着"偏好"不是一个绝对标签，而是一个条件化函数，输入是当前场景，输出是应该遵循的规则。AAAI'26这篇Oral里一个很重要的观点，就是评估Agent的偏好理解时，必须把这三层拆开来看。如果你只测"模型能不能猜中用户喜欢什么"，而不区分它是靠显性规则、行为习惯还是场景推断出来的，那这个评估结果会非常误导人。

2. "懂我"如何度量：长期行为偏好理解评估框架的设计思路

2.1 传统推荐评估指标的局限

做推荐系统的同行听到"个性化偏好"，本能地会搬出AUC、Recall@K、NDCG这套指标。这套指标的核心假设是：用户有一个"下一个要点击/购买的商品"，你只要把预测排序做对就行。

但Agent面对的任务完全不是这样。Agent需要根据偏好去规划、决策、生成，甚至主动执行。举个例子，一个智能助手帮用户安排一天的工作会议，如果它把会议都安排在用户习惯的"深度工作时间段"之前，这算不算正确？用推荐指标根本没法衡量，因为不存在一个"标准答案"物品。再比如Agent帮用户回复一封商务邮件，它知道用户不喜欢寒暄、习惯直入主题，所以生成了一封简洁回复。这个结果好不好？AUC衡量不了，只能看用户会不会保存、要不要修改、之后还会不会用这个功能。

所以评估Agent的偏好理解，不能只问"预测准不准"，还要问"用没用上""用对没有""给用户的感受如何"。AAAI'26的研究里提了一个分类评估的思路，我觉得非常值得借鉴：把偏好理解拆成三个不同能力的测试项，而不是笼统地算一个综合分数。

2.2 分类评估矩阵：行为预测、偏好归因、生成对齐

我把这个评估框架展开成一张表，你也可以把它当成自己项目的验收标准。

行为预测任务最接近传统推荐，但它有个问题：用户行为里有大量随机噪声，预测准确率的天花板很低。你不能因为预测命中率只有35%就说Agent不懂用户。所以这项测试更适合用来做"自监督预训练"，而不是最终验收。

偏好归因任务才是Agent偏好理解的核心，因为它考察的是"可解释的偏好使用"。如果Agent最终说"我建议你周三下午不安排会议，因为你过去三周周三下午都在深度工作"，那它就是一条可验证的归因。评估时，我们可以故意给Agent两个相互矛盾的偏好，比如"用户曾经说每周五下午不想开会"和"用户周五下午主动约了重要客户"，看Agent能不能识别出冲突并按情境优先级处理。

生成对齐任务是最贴近用户体验的。做法很直接：同一个任务，给用户两版Agent回复，一版用了长期偏好，一版没有，让用户打分或者直接观察用户更愿意编辑哪个版本。我强烈建议在项目早期就把这个任务做成固定评测集，它能最真实地反映"用户感觉Agent懂不懂我"。

2.3 长期行为中的时间衰减与鲁棒性测试

长期行为评估里还有一个特别容易忽略的东西：时间。用户不是一成不变的，去年喜欢熬夜打游戏的人，今年可能因为体检结果开始晨跑。如果你的Agent一直按照旧偏好行事，用户会觉得"它不知道我已经变了"。

所以评估必须带时间切片设计。具体做法是把历史数据切成D1、D2、D3三个时间段，用D1和D2训练或初始化Agent，然后看它在D3上的表现。更精细的做法是设置"偏好翻转点"，比如模拟用户在第30天突然改变了某种行为模式，看模型多久能识别出这个变化、多久能放弃旧偏好。一个健康的长期偏好系统应该具备"合理遗忘"的能力，而不是把所有历史行为一视同仁地加权。

鲁棒性测试同样不能少，我总结了三类必须覆盖的边界场景。第一，新用户场景，用户只有几条行为记录，模型不能乱猜，要承认证据不足。第二，噪声场景，用户误点了一个从不看的频道，模型不能因此把频道偏好写进画像。第三，误导场景，用户故意说反话或者测试你，模型要有能力保持主见，不能用户说什么就改什么。这些场景用精准率、召回率都不足以刻画，更需要统计"严重错误率"，比如把因歧义造成的偏好改写定义为严重错误。

2.4 评估数据集构造：合成数据为什么不能少，真实数据为什么更要小

没有数据，评估框架就是空中楼阁。但长期行为数据非常敏感，直接拿真实用户行为去评测，既涉及隐私合规，又很难获得足够的用户授权。我的经验是：合成数据和真实数据必须双轨并行，而且各有不可替代的角色。

合成数据的做法是用"用户代理"（user simulator）生成一批虚拟用户。每个虚拟用户会定义自己的偏好配置，比如"小王每天早晨看行业新闻，通勤时听播客，上午集中处理邮件，下午参加跨部门会议，对沟通风格偏好简洁"。然后按这个配置生成几个月的行为轨迹，让Agent从轨迹中反推偏好，最后和真实配置做对比。这类数据的价值在于你手里有"标准答案"，可以精准测试归因能力、时间衰减处理能力和冲突识别能力，而且可以无限量生成，成本极低。

真实数据的价值不在量，而在"生态效度"。合成数据再逼真，也无法完全模拟真人那种矛盾、犹豫、说一套做一套的复杂性。所以真实数据建议做成小规模、高标注质量的数据集，几条就够了，但每条行为轨迹都要有用户注释，解释"为什么当时那样做"。这类数据集适合用来验证Agent在真实世界是否真的提升了用户满意度，哪怕只有几十个用户深度配合，也足够暴露大批离线评测发现不了的问题。

3. 让Agent记住重点并动态运用偏好：三个层面的优化路线

3.1 记忆压缩层：把行为序列变成可更新的偏好画像

评估框架建立之后，解决"怎么优化"就有方向了。我倾向于把优化分成三个层面的工作：记忆压缩层、记忆提取层和对齐层。每一层解决一个独立的问题，也对应一类不同的技术选型。

记忆压缩层要解决的核心问题是：原始行为序列太稠密、太长，不能直接存，必须压缩成一个可更新的偏好画像。业界常见的做法是"摘要+抽取+向量化"三件套。

第一步是用LLM对每天的行为做结构化摘要。不要让它写散文，而是要固定输出一个JSON，包含时间、活跃状态、关键事件、涉及的对象、用户的情绪倾向。这一步的Prompt同样很重要，我会在Prompt里明确说"只记录可能影响长期偏好的事件，过滤一次性噪音"。

第二步是从多日摘要中抽取稳定的偏好候选。比如发现用户连续五天都在上午十点打开日报阅读，就生成一条候选偏好："用户习惯在上午十点左右阅读行业日报"。候选偏好需要带置信度、首次出现时间、最近确认时间、触发条件和行为来源。

第三步是把偏好候选向量化存储，并建立索引。向量化的目的不是替代前两步，而是为了让提取阶段可以快速找到与当前任务相关的偏好片段。注意不要只存一个整体向量，最好一个偏好一个向量，这样提取时不会互相干扰。

这里最关键的工程细节是增量更新。用户每天都会产生新行为，你不应该每天全量重算一遍画像。要设计一个"偏好增量合并"机制：新的一天结束后，先提取当天摘要，跟已有画像做相似度匹配，如果匹配到已有偏好，就更新它的置信度和最近确认时间；如果没有匹配，就创建一个新候选；如果某条偏好很长时间没有被触发，就衰减它的权重，直到淘汰。这种设计既能控制存储成本，也能自然实现"合理遗忘"。

3.2 记忆提取层：在Agent决策时找到相关的偏好片段

有画像只是第一步，更重要的是Agent在做具体决策时能准确提取出相关的偏好。这层做不好，画像就是一坨死数据。

提取阶段最朴素的做法是embedding相似度检索：把当前用户问题编码成向量，跟偏好向量做余弦相似度，取top-k塞进Prompt。但实测下来，只做相似度检索很容易出错，因为用户当前的问题可能同时涉及多个维度的偏好，而相似度检索往往偏好近期高频的向量，会忽略那些低频但关键的长久规则。

我建议在检索层额外增加三个信号：

第一，相关性打分。不能只看语义相似度，还要看偏好类型是否匹配当前任务类型。如果当前任务是发邮件，那么"邮件风格偏好"的权重就应该高于"购物偏好"。

第二，时间衰减权重。对用户没有主动确认过的偏好，越久远权重越低；但对用户明确表达过的规则，哪怕时间久远也应该保守保留，甚至可以做一个"长期有效"标志位。

第三，行为重要性权重。用户主动反馈、拒绝、修改生成结果，这些行为权重应该高于静默浏览和点击。比如用户说"以后不要给我推这类视频了"，这比看了三个同类视频要重要得多。

提取之后还有一个容易被忽略的点：要把"证据链"和"不确定性"一起提供给Agent。不要把一条孤立的偏好文本扔给模型，而要附带来源时间和置信度。比如告诉Agent："用户偏好'邮件尽量简短'，来源：用户于5月12日在设置中明确说明，置信度：高。"如果检索到的两条偏好相互冲突，也要显式告知模型，让它根据时间先后和情境权重自己判断。这样做的好处是，Agent在遇到模糊情况时至少知道自己的判断依据是什么，后续也方便做偏好溯源。

3.3 对齐层：用反馈信号优化偏好策略

第三个优化层面是训练对齐。很多人以为只要把偏好写进Prompt，模型就会自然遵守，但在复杂任务里，模型会因为主要指令太强而忽略次要偏好。我们需要用人类反馈继续训练模型，让它学会在"完成主任务"和"遵循用户偏好"之间找到平衡。

最常用的训练方法是DPO或者RLHF。在偏好理解这个场景下，我建议这样做数据：构造一批任务，每个任务让模型生成两个回复，一个充分遵循了用户长期偏好但任务完成度稍低，另一个任务完成度很高但完全忽略了用户风格。然后让用户或者标注员选择更喜欢哪一个。选择结果用来做偏好对齐训练。

但这里有个很关键的原则：偏好必须是"条件化的"。你不能训练模型在任何情况下都遵循某条偏好。比如用户喜欢"回复极简风格"，但如果在法庭等正式场合，极简反而显得敷衍。所以训练样本要覆盖不同情境，让模型学会"在大多数日常沟通中遵循极简偏好，但在高语境敏感度场景下自动调整"。这对数据构造的要求更高，需要标注者在每条样本里写明"当前情境约束"。

损失函数的设计也可以参考多目标优化的思路。行为预测任务可以用交叉熵，偏好一致性可以用KL散度或对比损失，任务有用性可以用人工评分的奖励模型来衡。最后加权组合。我在实际试验中会觉得"偏好一致性"权重不能设太高，否则模型会变得矫枉过正，用户说了一句抱怨就当成全局指令，反而让对话变得呆板。

4. 落地长期偏好理解：工程实现中的真实约束与避坑清单

4.1 数据流水线最先做，模型第二

说实话，评估框架和模型优化在论文里很漂亮，但真正决定一个Agent个性化系统能不能落地的，往往是最不起眼的数据流水线。我见过太多团队一开始就急着调模型，结果数据没有标准化，后面每一步都在打补丁。

长期行为数据的收集，我强烈建议从第一天就定义统一的事件格式。不要太复杂，但必须包含足够的上下文，下面这个格式是我经过多个项目验证后比较顺手的：

json复制{
  "user_id": "u_8a2c1",
  "agent_id": "a_scheduler",
  "timestamp": 1736910000000,
  "event_type": "click",
  "entity_id": "article_12345",
  "content": "深度工作技巧：如何提升专注力",
  "metadata": {
    "device": "mobile",
    "session_id": "s_001",
    "user_action": "open",
    "importance": "low"
  }
}

几个关键点说一下。event_type一定要归一化，不能时而叫"click"，时而叫"点击"，否则下游清洗非常痛苦。entity_id和content要分离，实体ID用于关联知识图谱，文本内容用于语义向量化。metadata里建议放设备、场景、用户操作等级等信息，这些是判断情境偏好的重要线索。

另外从信息密度角度来看，我建议优先收集"高表现力行为"，而不是所有行为。高表现力行为指那些能反映用户意图的操作，比如用户删除了一条建议、拒绝了Agent的推荐、手动修改了生成结果的某句话、主动设置了一条规则。这些行为虽然数量少，但信息价值远高于普通的浏览点击。一个只采集"高表现力行为"的流水线，比一个采集全量但不做筛选的流水线更实用，因为Agent可以先把高表现力事件作为强意图标签，再用普通行为作为弱信号做增强训练。

4.2 离线评估跑通了，在线还是翻车？

这是长年做Agent系统最头疼的问题：离线评估什么都好，一上线用户就反馈"这个Agent好像从来不记得我说过什么"。原因通常有三类，我都踩过。

第一类是离线数据集与真实用户分布不一致。离线评测用的是公域数据集或者采样的历史数据，但真实用户里可能有大量新用户、低频用户、非母语用户，行为模式完全不在训练分布里。解决办法是在离线评测集里额外保留一个"低活跃用户子集"，专门看模型在小样本条件下是否保持稳定。

第二类是时间泄漏。这是最隐蔽的坑，你以为自己用了用户前三个月的行为去预测下一个月，但如果特征工程里不小心用到了未来统计量，比如"全时段的平均阅读时长"而不是"截至当前天的滚动平均阅读时长"，那评估结果就是虚高的。做长期行为建模，必须养成"每个特征都要显式标注截止时间"的习惯。

第三类是只测平均值，不测长尾。长期偏好往往在特定场景下才发挥作用，比如出差时的酒店偏好、开会时的文档格式偏好。如果你的评测集主要覆盖日常场景，这些长尾偏好根本不会被触发。我建议每次上线前做一次"偏好触发清单测试"：把系统已经学到的每条偏好都设计一个对应任务，看Agent是否在正确时机调用了它。实测下来说难听点，覆盖率不足六成的情况很常见。

在线验证阶段也不能省，我推荐"偏好转弯"的实验设计。第一个阶段两周，Agent不启用长期偏好，只做任务型响应；第二个阶段两周，Agent启用长期偏好。对比两个阶段的用户行为变化，像主动修改率、反馈率、任务完成率、留存率，而不要直接问用户"你觉得它懂你吗"，用户自我报告和实际行为经常不一致。

4.3 隐私与可解释性的平衡

长期行为是所有用户数据里最敏感的一类，因为它拼起来几乎就是一个人生活的完整画像。做这个方向就必须把隐私设计当成一等公民，而不是上线前补个免责声明。

工程层面的基础要求是：支持用户一键删除所有行为记录，支持用户导出历史数据，支持用户暂停行为采集。看起来很简单，但很多系统因为数据散落在多个服务间，根本做不到完整删除。我建议在设计事件Schema第一天就加上数据生命周期字段，包括保留期限、数据类别、是否允许用于训练。这样后续做合规审计的时候不会想哭。

可解释性上，我强烈推荐给Agent的每条偏好输出加一个"偏好溯源"字段。当Agent说"我建议你这样安排"时，它应该能附带一句"因为你过去三周都这样做"。这类溯源信息可以展示给用户，也可以只在日志里记录，用于调试和审计。好的偏好理解系统不一定要向用户解释所有细节，但必须能够向开发者解释自己为什么做某个决策。如果做不到，那就说明系统内部存在严重的"理解但不可控"问题。

4.4 工程选型的小建议

关于模型选型和基础设施，我不打算在这里铺开太多，但有几个基于实践的结论可以给出来。

第一，向量检索库选型时不要只盯着性能，还要看它支不支持混合检索（向量+标量过滤）。偏好提取经常需要按时间范围、偏好类型、置信度等条件过滤，纯向量检索不够用。Milvus、Qdrant、Elasticsearch都能做混合检索，具体选哪个根据团队运维习惯来。

第二，索引构建的更新频率不要追求实时。长期偏好本来就带有一定稳定性，实时更新反而会被瞬时噪声干扰。设定为每4到6小时批量刷新画像，是比较平衡的选择。当然，如果用户当晚明确修改了一条偏好，这个改动应该立即生效，那是另一个通道。

第三，LLM调用环节要控制延迟。偏好检索本身是轻量级的，真正耗时的是把检索结果和Prompt一起发给大模型。如果检索不够精准，塞进太多无关偏好，既浪费时间又可能干扰主任务。通常一条Agent决策带上3到5条高质量偏好片段就够了，超过这个数量效果不升反降。

5. 这类工作做久了，我最深的几个体会

先说结论：长期行为偏好理解不是一个"模型问题"，而是一个"数据+评估问题"。我在这个方向上折腾了比较长时间，最颠覆我早期认知的一点是，用户偏好的价值密度极低，一年行为记录里真正对决策有用的可能只有几十条，但正是这几十条决定了用户愿不愿意长期把Agent当成"自己人"。所以做优化时不要试图记住所有事情，要逼自己回答一个问题：我究竟要记住哪几件事？

在实际系统里，我通常会引导团队先做"单偏好深度理解"而不是"全偏好平均覆盖"。挑一个用户最痛的高价值场景，比如邮件风格或者日程规划，把这一条偏好的提取、存储、触发、评估、对齐全部跑通，经验复用到其他偏好上会快很多。相反，一开始就搭一个巨大的通用画像系统，最后往往是每个偏好都只理解了个皮毛。

评估体系也要尽早建立，最好在写第一行模型代码之前就先把"何谓懂用户"的指标定义完。你可以先人工定义十个关键测试案例，后面再慢慢扩展，但绝不能没有。因为长期行为建模的可调参数太多了，如果没有一个稳定可信的评估基准，你根本不知道一次模型升级到底是变好了还是变坏了。

最后我想分享一个很容易被忽略但很重要的设计原则：好Agent需要承认"我不知道"。长期行为建模追求的是尽可能理解用户，但在数据不足、场景模糊、偏好冲突的情况下，更可信的做法是向用户确认："我注意到你以前通常这样做，今天还是这个安排吗？"而不是强行假装很懂。我在测试中发现，用户对Agent"知道自己不知道"的信任度，比Agent永远给出自信猜测要高出不少。所以当你构建偏好体系时，请务必给Agent留一条"向用户确认"的退路。

这个方向后续还有很大的扩展空间，比如多用户场景下的偏好协商、跨设备和跨模态的行为统一建模，甚至让Agent自己主动向用户提出"我发现你最近有了新习惯，要不要更新偏好设置"。每一步都很难，但也正因为难，这个方向才值得做。希望这篇分享能给你提供一个相对清晰的评估和优化脚手架，让你在构建自己的个性化Agent时少踩几个坑。