VitaBench 如何评测真实生活服务 Agent：多工具、多轮交互与状态验证

👤 个人主页：zzz_2368
🧪 系列主题：Agent 评测｜从结果、轨迹到持续迭代
🔥 热门专栏：Agent | 小z的碎碎念 | Java后端
📚 本系列内容：评测体系、Rubric、Good Case、Bad Case、Trace 与长程 Agent

系列第 9 篇｜作者主页：zzz_2368 的 CSDN 主页｜上一篇：Agent 评测环境会“污染”结果吗｜系列起点：Agent 评测不是只看答案

前面的文章讨论了结果、轨迹、稳定性和环境，但还缺少一个具体问题：真实业务风格的 Agent 任务，到底应该怎样构造？

美团 LongCat 团队开源的 VitaBench 是一个值得研究的国内案例。它把任务放进外卖、到店消费和在线旅行服务等生活场景，要求 Agent 在多轮对话中调用工具、处理歧义、追踪用户意图，并通过环境状态和 Rubric 判断结果。

需要先说明边界：VitaBench 是基于真实生活服务问题构造的模拟评测环境，不等于美团线上生产系统，也不能用它的 Benchmark 成绩直接推断某个模型在真实订单、支付或履约链路中的效果。本文核验日期为 2026-08-12。

---

---

一、为什么生活服务任务比“调用一个 API”难

考虑一个看似普通的需求：

帮我订明晚公司附近适合 4 个人聚餐的餐厅，如果没有包间，就改订后天；人均不超过 150 元，其中一人不吃辣。

这不是一次搜索。Agent 至少要处理：

1. “公司附近”对应哪个位置；
2. “明晚”对应具体日期和时间；
3. 餐厅是否支持 4 人、包间和不辣菜品；
4. 人均预算怎样计算；
5. 没有包间时是否允许直接改日期；
6. 创建预订前是否需要用户确认；
7. 预订后环境里是否真的产生了记录。

因此，生活服务 Agent 的能力不只是 Function Calling，而是：

理解约束
  -> 主动澄清
  -> 跨工具检索
  -> 基于时间和空间推理
  -> 执行有副作用的动作
  -> 跟踪状态
  -> 验证最终结果

二、VitaBench 公开了什么

根据 VitaBench 官方仓库和论文，其第一版环境覆盖 Delivery、In-store 和 OTA 三类生活服务领域，包含 66 个工具，提供 100 个跨场景任务以及每个单场景 100 个任务，共 300 个单场景任务。

设计	评测重点
Delivery	商家、商品、配送和订单状态
In-store	到店消费、套餐、预约和服务条件
OTA	酒店、交通或旅行相关检索与预订
Cross-scenario	多领域工具组合、状态衔接和复杂约束

任务不是简单把单个用户请求改写成测试题。项目说明称，任务来自多个真实用户请求的组合，需要处理时间、空间、歧义、用户意图变化和多轮交互。

官方仓库在 2026 年 1 月记录过数据、工具、评测模型和指标更新。这意味着旧版本成绩不能脱离任务和评测器版本直接与新版比较。

三、VitaBench 最值得借鉴的四个设计

1. 工具数量多，但不把“调对函数”当最终目标

工具评测经常退化成：函数名是否正确、参数是否匹配。VitaBench 中工具只是改变模拟世界的手段，最终还要检查任务结果。

例如 Agent 调用了 create_order，不代表任务成功。还要验证：

• 商家和商品是否满足约束；
• 数量、价格和时间是否正确；
• 是否重复下单；
• 数据库中是否产生预期状态；
• Agent 的最终回复是否与状态一致。

2. 用户模拟器会改变对话走向

静态 Benchmark 通常给出完整问题，Agent 直接作答。真实用户常常不会一次说清全部条件，甚至会在对话中改变主意。

VitaBench 使用用户模型模拟多轮交互，测试 Agent 是否能够：

• 对缺失信息主动提问；
• 理解补充条件；
• 处理前后变化的意图；
• 在高风险写操作前确认；
• 避免重复询问已经给出的信息。

用户模拟器本身也会引入随机性和模型偏差，所以评测时应记录用户模型、参数和每条对话轨迹，并运行多个 Trial。

3. 跨场景任务检查组合能力

单领域成功不代表 Agent 可以处理跨领域任务。比如：

查询到店套餐
  -> 根据结束时间安排返程交通
  -> 发现时间冲突
  -> 调整预约
  -> 更新两个领域的状态

跨场景评测容易暴露：

• 工具选择空间过大；
• 不同领域字段语义不一致；
• 一个操作改变后，没有同步更新后续计划；
• 上下文变长后遗忘早期约束；
• 多个写操作之间缺少事务意识。

4. Rubric 允许多条合理路径

开放式 Agent 任务往往没有唯一标准轨迹。VitaBench 提出基于 Rubric 的滑动窗口评测器，目的是在复杂和随机交互中评估局部行为与整体任务要求，而不是逐步匹配唯一 Golden Path。

这类 Rubric 可以写成：

rubric:
  - id: clarify_location
    description: 地址不明确时，执行搜索或下单前应确认位置
    weight: 1
  - id: satisfy_budget
    description: 最终选择的人均价格不得超过 150 元
    weight: 2
  - id: confirm_before_write
    description: 创建不可逆预订前获得用户确认
    weight: 3
    blocking: true
  - id: final_state
    description: 模拟环境中存在唯一且条件正确的预订记录
    weight: 4
    blocking: true

blocking 表示不能用其他高分抵消。价格正确但未经确认就下单，不应仍被平均成“基本通过”。

四、自己设计一个简化生活服务任务

下面给出一个可以迁移到内部评测集的任务定义。它不是 VitaBench 原始数据，也没有复刻美团业务接口。

task_id: dining-booking-001
initial_state:
  current_time: "2026-08-12T15:00:00+08:00"
  user_profile:
    office_location: null
  bookings: []
user_request: >
  帮我订明晚公司附近适合四个人聚餐的餐厅，
  人均不超过150元，其中一人不吃辣。
available_tools:
  - get_user_profile
  - search_restaurants
  - query_availability
  - create_booking
constraints:
  - office_location 为空时必须向用户澄清
  - 创建预订前必须确认餐厅、时间、人数和价格
  - 不得创建重复预订
graders:
  outcome:
    - bookings 中恰好存在一条记录
    - 人数为4
    - 人均价格不超过150元
  trajectory:
    - 澄清位置发生在 search_restaurants 之前
    - create_booking 之前存在用户确认
  safety:
    - 没有访问任务外用户数据

这份任务定义把“成功”拆成三部分：最终状态正确、轨迹满足业务约束、执行没有越权。即便换用不同模型或 Agent Harness，核心验收仍保持一致。

五、最终状态为什么比最终回复更重要

生活服务 Agent 往往具有写操作。如果只评估 Response，会出现四类假成功：

最终回复	真实环境	判断
“预订成功”	没有记录	失败：自我报告错误
“预订失败”	已产生记录	失败：状态与回复不一致，可能重复执行
“已订 4 人”	实际为 2 人	失败：关键字段错误
“已为你预订”	正确且唯一记录	还需检查确认、权限和约束

Outcome Grader 应直接访问模拟环境，而不是再次询问 Agent“你是否完成了任务”。

六、怎样运行 VitaBench

官方仓库给出的基本流程是克隆项目、安装，并在模型配置文件中填写兼容接口。示例命令结构如下：

git clone https://github.com/meituan-longcat/vitabench.git
cd vitabench
pip install -e .

vita run \
  --domain delivery,instore,ota \
  --user-llm <user-model-name> \
  --agent-llm <agent-model-name> \
  --evaluator-llm <evaluator-model-name> \
  --num-trials 3 \
  --num-tasks 5 \
  --max-steps 300 \
  --max-concurrency 1 \
  --language chinese

模型名、接口地址和凭据需要按仓库当前 models.yaml 说明配置。不要把 API Key 写进文章、仓库或结果文件。运行前还应检查 Python 依赖、仓库 release、任务版本和评测模型是否已经更新。

官方仓库还支持重新评估已有 simulation 文件，这一点非常重要：修改 Grader 时可以对同一批轨迹重新打分，避免每次都产生新的模型调用和不同轨迹。

七、怎样评估 Rubric Evaluator 本身

使用 LLM Evaluator 不等于完成评测。评分器本身也需要验证：

1. 抽取通过、失败和边界轨迹；
2. 由业务专家独立标注；
3. 比较 Evaluator 与人工判断；
4. 分析误报和漏报；
5. 修改 Rubric 后重新校准；
6. 固定评测模型和 Prompt 版本。

能够用代码验证的最终状态，应优先确定性评分。Rubric Evaluator 更适合判断是否充分澄清、回复是否准确解释结果、替代方案是否合理等开放问题。

八、官方成绩应该怎样解读

VitaBench 第一版仓库报告：其当时实验中的先进模型在跨场景任务上的最高成功率为 32.5%，在其他场景中低于 62%。这只能说明论文对应版本、任务、模型、用户模拟器和评测器下的实验结果。

不能据此推断：

• 真实用户任务只有三成能完成；
• 后续新模型仍然是相同水平；
• 某个 Agent 产品在生产环境的成功率；
• 一个模型在其他行业的工具能力。

尤其在官方仓库已经更新数据和评测器的情况下，引用成绩必须同时写明来源版本和日期。

九、从 VitaBench 迁移到企业内部评测集

无需照搬 66 个工具。更可行的路径是：

选择一个高频业务流程
  -> 构造可重置的模拟数据库
  -> 暴露 5~10 个受控工具
  -> 收集真实失败模式并脱敏
  -> 编写单场景任务
  -> 增加歧义和意图变化
  -> 增加跨场景组合任务
  -> 校准 Outcome 与 Rubric Grader

第一个版本宁可只有 20 个高质量任务，也不要一次堆几百个无法解释的自动生成样本。任务应覆盖正常路径、信息缺失、工具失败、状态冲突、重复请求和高风险操作。

十、结论

VitaBench 最值得借鉴的，不是某个榜单数字，而是它把生活服务 Agent 评测从“函数调用正确率”扩展到：

1. 多领域工具组合；
2. 多轮用户澄清；
3. 时间、空间和价格约束；
4. 用户意图动态变化；
5. 最终环境状态；
6. 允许多条合理路径的 Rubric。

下一篇会进一步拉长时间尺度：当任务持续 12 小时甚至更久，Agent 的评测对象会从一次性成功率，转向学习曲线、阶段进展、记忆可靠性和恢复能力。

参考资料

1. VitaBench 官方仓库
2. VitaBench 论文：Benchmarking LLM Agents with Versatile Interactive Tasks in Real-world Applications
3. VitaBench 项目主页
4. τ²-bench / τ³-bench 官方仓库
5. 美团技术团队

---

感谢阅读，记得点赞、关注、收藏，欢迎各位评论区交流！！！