LongCat 开源 VitaBench 2.0，把智能体评测的重心从“单轮答得好不好”推向“长期相处中是否真正理解用户”。它面向真实生活场景，关注长期、动态用户建模，系统评测大语言模型在持续互动里的个性化与主动性能力。
为什么长期动态用户建模更难
很多智能体 demo 看起来很聪明，因为它们只需要处理一次明确请求：写邮件、查日程、总结文档、生成计划。但真实用户不是静态 prompt。用户偏好会变化，生活状态会变化，任务优先级也会变化。
长期动态智能体至少要面对三类问题：
- 记忆不是越多越好：模型需要区分稳定偏好、临时上下文和过期信息。
- 个性化不能只靠称呼用户名字：真正的个性化是能在建议、排序、提醒、措辞中体现用户习惯。
- 主动性需要边界：智能体要知道什么时候该提醒、追问、建议，也要避免过度打扰。
VitaBench 2.0 的价值正在这里：它不是只看模型在孤立任务上的能力，而是把评测放进长期、真实、动态的用户互动过程里。
从“答题模型”到“相处模型”
传统 LLM 基准常常把模型当成答题器：输入一段问题，输出一个答案，然后评分。长期智能体更像一个持续运行的产品系统：它要读历史、更新用户画像、判断当前上下文，再决定要不要行动。
一个长期动态用户评测通常需要观察这些能力：
- 跨轮一致性：前面已经知道的偏好，后面是否还能正确使用。
- 变化识别：用户偏好改变后，模型是否能停止沿用旧结论。
- 主动建议：模型是否能基于长期上下文提出有用建议，而不是被动等待命令。
- 场景真实性：评测任务是否贴近真实生活互动，而不是人为拼接的短题。
VitaBench 2.0 被定位为真实生活场景下面向长期动态用户建模的智能体评测基准，因此对做个人助理、陪伴式产品、日程规划、健康管理、学习助手的团队尤其有参考意义。
可以这样实践：做一个最小长期用户模拟器
下面这个例子不是 VitaBench 2.0 官方接口，而是一个可改造的最小实验脚手架，用来帮助团队在接入正式基准前先检查自己的智能体是否能处理“用户偏好变化”。
保存为 long_user_eval.py 后运行。你可以把 toy_agent 替换成自己的 Agent 调用逻辑，例如接入内部服务、LLM API 或记忆系统。
from dataclasses import dataclass
from typing import Callable, List
@dataclass
class Turn:
user: str
expected_hint: str
SCENARIO: List[Turn] = [
Turn(
user="我最近晚上不想喝咖啡，容易睡不着。",
expected_hint="avoid_evening_coffee",
),
Turn(
user="帮我安排今晚 8 点后的饮品建议。",
expected_hint="avoid_evening_coffee",
),
Turn(
user="最近医生说我可以少量喝低因咖啡，但还是别太晚。",
expected_hint="allow_decaf_not_late",
),
Turn(
user="今晚 10 点我还要加班，推荐点东西。",
expected_hint="avoid_late_caffeine",
),
]
def toy_agent(history: List[str], user_input: str) -> str:
"""示例 Agent：真实项目中替换为你的模型、记忆和工具调用。"""
context = "\n".join(history + [user_input])
if "10 点" in user_input and "别太晚" in context:
return "建议喝无咖啡因花草茶或温水。低因咖啡也不适合 10 点后喝。"
if "低因咖啡" in context and "8 点" in user_input:
return "可以考虑少量低因咖啡，但如果接近睡前，花草茶更稳妥。"
if "不想喝咖啡" in context or "睡不着" in context:
return "今晚 8 点后建议避开咖啡，可以选择花草茶、热牛奶或温水。"
return "可以喝咖啡或茶。"
def score_response(response: str, expected_hint: str) -> int:
rules = {
"avoid_evening_coffee": ["避开咖啡", "花草茶", "温水"],
"allow_decaf_not_late": ["低因咖啡", "接近睡前", "花草茶"],
"avoid_late_caffeine": ["无咖啡因", "不适合 10 点后", "花草茶"],
}
keywords = rules[expected_hint]
return sum(1 for word in keywords if word in response)
def run_eval(agent: Callable[[List[str], str], str]) -> None:
history: List[str] = []
total = 0
for index, turn in enumerate(SCENARIO, start=1):
response = agent(history, turn.user)
score = score_response(response, turn.expected_hint)
total += score
history.extend([f"User: {turn.user}", f"Agent: {response}"])
print(f"Turn {index}")
print(f"User: {turn.user}")
print(f"Agent: {response}")
print(f"Score: {score}\n")
print(f"Total score: {total}")
if __name__ == "__main__":
run_eval(toy_agent)
运行：
python long_user_eval.py
这个脚手架很小，但它逼着系统回答几个关键问题：历史是否进入了决策？新偏好是否覆盖旧偏好？主动建议是否有边界？这些问题正是长期动态智能体评测绕不开的核心。
接入长期评测时别只盯总分
如果团队准备用 VitaBench 2.0 这类基准评估智能体，建议把结果拆开看，而不是只看一个排行榜数字。
可以重点记录：
- 短期任务成功率：当前轮请求是否被正确完成。
- 长期偏好命中率：历史偏好是否在合适场景被使用。
- 偏好更新延迟：用户改变想法后，系统多久停止使用旧信息。
- 主动行为准确率：主动提醒、建议、追问是否真的有帮助。
- 误触发率：系统是否在不该主动时主动。
一个实用的内部评测表可以长这样：
agent_eval:
benchmark: "VitaBench 2.0 style long-term dynamic user modeling"
dimensions:
- name: "personalization"
metric: "preference_hit_rate"
target: ">= 0.80"
- name: "adaptation"
metric: "stale_memory_error_rate"
target: "<= 0.10"
- name: "proactivity"
metric: "useful_proactive_action_rate"
target: ">= 0.60"
- name: "safety_boundary"
metric: "unwanted_interruption_rate"
target: "<= 0.05"
notes:
- "把稳定偏好、临时状态、过期信息分开记录"
- "人工抽样检查主动建议，避免只依赖关键词评分"
这段 YAML 不是官方配置，而是团队可以改造的评测记录模板。真正落地时，应把维度映射到自己的产品行为和日志字段。
采用建议：把长期能力当成系统工程
VitaBench 2.0 提醒开发者：长期智能体不是给模型塞一个更长上下文就结束了。它需要记忆策略、用户建模、行为边界、评测数据和回归测试一起工作。
落地时可以按这个清单推进：
- 明确哪些用户信息允许长期保存，哪些只应在会话内使用。
- 给记忆加时间戳、来源和置信度，避免陈旧偏好长期污染决策。
- 把主动行为单独评测，不要混在普通问答准确率里。
- 对偏好变化设计回归用例，例如“曾经喜欢 A，现在明确不喜欢 A”。
- 用真实生活场景构造测试，而不是只写抽象指令。
长期动态评测的难点在于，它评的不是一次输出，而是一段关系。VitaBench 2.0 的出现，让智能体团队有了更明确的参照：模型不仅要会回答，还要能在变化中记住该记的、忘掉该忘的，并在合适的时候行动。