LongCat 开源的 VitaBench 2.0，把智能体评测的焦点从“单轮答得准不准”推向了更难的场景：模型是否能在长期、真实、动态的用户互动中持续理解一个人，并在合适的时候表现出个性化与主动性。
这类评测很重要，因为今天很多 Agent 已经不只是回答问题，而是在做日程安排、健康提醒、学习陪伴、消费建议、工作流协同。它们面对的不是静态题库，而是会改变偏好、计划、状态和约束的真实用户。
为什么“长期动态用户建模”比普通问答难得多
传统 LLM 评测常见的是一次性输入：给定问题，模型输出答案，然后看准确率、相关性或安全性。但长期智能体面临的是另一种问题：
- 用户的偏好会变化，例如从“想省钱”变成“愿意为效率付费”；
- 用户的信息分散在多轮对话、历史事件、外部状态里；
- 智能体需要判断什么时候该主动提醒，什么时候不该打扰；
- 同一句请求在不同用户生命周期里可能有完全不同的答案。
VitaBench 2.0 的价值就在于，它把“长期、真实、动态”这些过去很难系统评测的维度放到基准里，评估模型是否能在持续互动中形成稳定、可更新的用户画像，并据此做出个性化决策。
评测重点：不只是记住，而是会更新、会行动
面向长期用户的智能体，能力不能只看“记忆力”。一个能背出用户昨天说过什么的模型，未必能服务好用户。更关键的是三类能力：
- 长期一致性：模型能否跨多轮、跨时间维持对用户偏好和目标的理解。
- 动态更新：当用户出现新偏好、新约束、新计划时，模型能否覆盖旧判断，而不是固执地沿用历史信息。
- 主动性：模型是否能在合适的时机提出建议、提醒或下一步行动，同时避免过度打扰。
这也是 VitaBench 2.0 相比很多静态 benchmark 更贴近真实 Agent 落地的地方。真实产品里的失败，常常不是“回答错一道题”，而是“忘了用户上周改了计划”“在不该推送时推送”“把旧偏好当成最新偏好”。
可以这样实践：用一个最小评测脚本模拟长期用户画像更新
下面这个例子不是 VitaBench 2.0 官方实现，而是一个可改造的最小项目，用来帮助团队在接入长期智能体评测前，先把“动态用户建模”这件事落到代码里。
它模拟三段用户历史：用户先喜欢省钱，后来明确表示愿意为效率付费。评测目标是检查 Agent 在最后决策时是否使用了最新偏好。
运行方式：保存为 mini_long_user_eval.py，直接执行 python mini_long_user_eval.py。你可以把 agent_reply() 替换成真实 LLM API 调用。
from dataclasses import dataclass
from typing import List, Dict
@dataclass
class Event:
day: int
text: str
USER_HISTORY = [
Event(1, '我最近预算比较紧，订机票时尽量选便宜的。'),
Event(12, '下周要参加一个很重要的客户会议，时间比价格更重要。'),
Event(18, '以后商务出行，如果能少转机、少折腾，可以接受贵一点。'),
]
TEST_QUERY = '帮我选一班去上海参加客户会议的航班，A 航班便宜但要中转，B 航班贵 400 元但直飞。'
EXPECTED_SIGNALS = ['直飞', '时间', '少折腾']
STALE_SIGNALS = ['便宜优先', '最便宜', '省钱']
def build_user_profile(events: List[Event]) -> Dict[str, str]:
'''一个极简画像构建器：真实系统可替换为向量记忆、数据库或 LLM 总结。'''
profile = {'travel_preference': 'unknown'}
for event in events:
if '便宜' in event.text or '预算' in event.text:
profile['travel_preference'] = 'price_sensitive'
if '时间比价格更重要' in event.text or '少转机' in event.text or '少折腾' in event.text:
profile['travel_preference'] = 'efficiency_first'
return profile
def agent_reply(profile: Dict[str, str], query: str) -> str:
'''示例 Agent：可以替换为真实模型调用。'''
if profile['travel_preference'] == 'efficiency_first':
return '建议选择 B 航班。虽然贵 400 元，但直飞、更省时间，也符合你最近商务出行少折腾的偏好。'
if profile['travel_preference'] == 'price_sensitive':
return '建议选择 A 航班，因为它更便宜，符合你之前省钱的偏好。'
return '建议比较价格、耗时和中转风险后再决定。'
def score(reply: str) -> Dict[str, object]:
expected_hits = sum(signal in reply for signal in EXPECTED_SIGNALS)
stale_hits = sum(signal in reply for signal in STALE_SIGNALS)
passed = expected_hits >= 2 and stale_hits == 0
return {
'passed': passed,
'expected_hits': expected_hits,
'stale_hits': stale_hits,
'reply': reply,
}
if __name__ == '__main__':
profile = build_user_profile(USER_HISTORY)
reply = agent_reply(profile, TEST_QUERY)
result = score(reply)
print(result)
这个小脚本的意义不在于评分多复杂，而在于把长期智能体评测拆成了三个可观察对象：
- 历史事件：用户过去说过什么；
- 状态更新：系统如何从历史中提取当前偏好；
- 决策输出：Agent 是否依据最新状态行动。
在真实系统里，你可以把这三层替换成：事件日志、记忆系统、RAG、用户画像服务、LLM Planner 或工具调用链路。
接入这类基准时，团队该看哪些指标
如果团队准备用 VitaBench 2.0 这类长期动态基准评测 Agent，不建议只看一个总分。更实用的做法是按失败类型拆开看：
- 遗忘：模型没有使用关键历史信息；
- 陈旧记忆污染：模型使用了已经被新信息覆盖的旧偏好；
- 主动性不足：明明有必要提醒，却只被动回答；
- 过度主动：在没有足够依据时擅自安排、推荐或打扰；
- 个性化幻觉：模型编造用户没有表达过的偏好。
这些失败类型对应的工程修复手段并不一样。遗忘可能需要更好的记忆检索；陈旧污染需要时间衰减或冲突解决；过度主动则往往需要产品策略、权限边界和风险分级。
落地建议：把 benchmark 当成回归测试，而不只是排行榜
VitaBench 2.0 这类基准的启发是：长期 Agent 的质量，需要持续评测，而不是上线前跑一次 demo。
更稳妥的采用方式是：
- 在模型升级、提示词变更、记忆策略调整时跑回归测试；
- 把“最新偏好是否覆盖旧偏好”单独作为测试集；
- 对主动建议设置风险等级，低风险可自动提醒，高风险必须确认；
- 记录 Agent 为什么做出个性化判断，方便调试和审计。
长期动态智能体的难点不是让模型显得聪明，而是让它在几周、几个月的互动里持续可靠。VitaBench 2.0 的意义，正是把这种可靠性变成可以被系统性观察和比较的对象。