KnowU-Bench: Towards Interactive, Proactive, and Personalized Mobile Agent Evaluation

Paper: arXiv:2604.08455 Code: ZJU-REAL/KnowU-Bench Code reference: main @ 0dd79895 (2026-05-04)

1. Motivation (研究动机)

现有 Mobile GUI Agent benchmark 大多只问一个问题：模型能不能按明确指令完成 UI 操作。KnowU-Bench 认为这已经不足以衡量“个人助理”能力，因为真实用户常常给出模糊、上下文相关、需要长期偏好记忆的任务；更进一步，真正的助手还需要判断何时主动介入、何时询问确认、何时在用户拒绝后停止。

Figure 1 解读：左侧展示从 clear instruction 到 vague instruction 后模型性能显著下降，说明 bottleneck 已经从“会不会点 UI”转向“能不能把用户偏好、历史行为和当前场景结合起来”。右侧把 KnowU-Bench 与 prior personalization/proactive benchmarks 区分开：它不是离线 intent prediction，也不是给定静态 preference 后做匹配，而是在真实 Android GUI 环境中同时考察 hidden profile、user logs、online user interaction、proactive consent 与 hybrid evaluation。

本文针对三个具体缺口：第一，PersonalAlign、Me-Agent、FingerTip 20K 等更偏向从静态历史中恢复偏好，缺少任务执行过程中的多轮澄清；第二，ProactiveMobile、PIRA-Bench、Pare 等更多停留在 intent suggestion / API-level execution，未覆盖完整 GUI execution chain；第三，传统 AndroidWorld、MobileWorld 等能验证界面操作，但无法系统衡量 preference elicitation、initiative calibration 和 post-rejection restraint。

这个问题值得研究，是因为个人移动助手的风险不只来自“做错步骤”，还来自“替错用户做了不该做的事”。如果 agent 不知道用户口味、时间、地点、预算和社交关系，它可能在购物、订餐、日程、消息等场景中完成了表面任务，却违背真实偏好；如果 proactive agent 不会克制，它会在无需介入时打扰用户，或在被拒绝后继续操作。

2. Idea (核心思想)

核心 insight 是：personalized / proactive mobile agent evaluation 必须把“隐藏的用户画像”和“可见的行为日志”分开，并放进可交互的真实 GUI 环境中。KnowU-Bench 让 user simulator 持有 structured profile $P$ ，但 GUI agent 只能看到 timestamped interaction log $H$ ，因此模型必须从行为证据中推断偏好，并在不确定时通过 ask_user 主动澄清。

关键创新可以概括为三点：一是构建 containerized Android emulator + FastAPI orchestration 的 online benchmark，使每个 task 都有可复现初始化和 programmatic verification；二是引入由 structured profile 驱动的 LLM user simulator，支持多轮 clarification、accept/reject decision 和 role-specific response；三是把 tasks 分成 general、personalized、proactive 三类，尤其覆盖是否介入、是否请求同意、用户拒绝后是否停止的完整 proactive chain。

与 AndroidWorld / MobileWorld 的根本差异是，KnowU-Bench 不把任务成功定义为固定 UI state matching；与 PersonalAlign / ProactiveMobile 的差异是，它不只做离线偏好恢复或 proactive intent prediction，而要求模型在 live Android GUI 中把 preference inference、dialogue 和 actual execution 串起来，并由 rule-based checker 与 LLM-as-a-judge 共同评分。

3. Method (方法)

3.1 Overall framework: environment, agent, user, evaluator

Figure 2 解读：KnowU-Bench 由四个模块组成：(a) Environment 提供 23 个 Android apps、task initialization、rule-based / LLM-based evaluation；(b) Mobile Agent 接收 system prompt、vague instruction、user history 和 screenshot，输出 click / type / ask_user 等动作；(c) User Agent 持有 hidden user profile 和 user history，负责回答澄清问题或给出 proactive accept/reject；(d) Evaluation 把 rule-based signals 与 LLM-judge score 融合，输出最终分数和 reason。

形式化上，论文把 mobile automation 写成 POMDP $(S, O, A, T, R)$ ： $S$ 是环境状态， $O$ 包含 instruction 与 screenshot 等 observation， $A$ 是 mobile UI action space， $T : S \times A \to S$ 是状态转移， $R : S \times A \to {0, 1}$ 表示任务是否完成。这个抽象强调 agent 看到的是部分可观察界面和历史反馈，而不是完整用户偏好。

直觉上，这套设计的关键不是“给模型更多上下文”，而是制造一个更接近真实助理的非对称信息结构：用户画像 $P$ 对 agent 隐藏，只能通过日志 $H$ 和多轮询问间接推断。这样可以区分两种能力：模型是否能从过去行为中抽取偏好，以及当日志不足时是否知道该问什么问题、如何把回答转化为 UI 操作。

3.2 Reproducible Android environment

KnowU-Bench 使用 rooted Pixel 8 AVD 与 FastAPI orchestration server。AndroidController 把模型动作映射成 ADB 操作；每个 task 从固定 emulator snapshot 开始，并重置 backend processes、callback files、interaction history；time-sensitive tasks 会覆盖设备时间。代码中 src/knowu_bench/core/server.py 的 AVD_MAPPING 指向 Pixel_8_API_34_x86_64，ensure_controller() 负责 health check 与 controller 初始化；src/knowu_bench/runtime/controller.py 和 src/knowu_bench/runtime/client.py 负责 action execution、screenshot observation、task score query。

Action space 由 Appendix Table 4 给出，包括 click(x,y)、double_tap(x,y)、long_press(x,y)、drag(start_x,start_y,end_x,end_y)、input_text(text)、scroll(direction)、navigate_home、navigate_back、keyboard_enter、wait、answer(text)、status(goal_status) 和新增的 ask_user(text)。其中 ask_user 是 personalized/proactive task 与传统 GUI task 的关键差异：agent 可以在不确定时请求用户澄清，而不是只能猜测后执行。

Figure 6 解读：这张 appendix pipeline 图把 execution loop 展开：task 先初始化 worker progress 与 Android emulator，agent 根据 instruction、history 和截图产生 action；若 action 是 ask_user，User Agent 根据 hidden profile 生成回复；最后 Hybrid Evaluation 同时读取最终 UI state、database/callback traces 和 dialogue logs。它说明 KnowU-Bench 的评分不只看最后界面，还看中间是否正确询问、是否尊重拒绝、是否满足个性化条件。

3.3 User simulator: hidden profile $P$ and exposed log $H$

每个用户由两类信息组成：structured profile $P$ 和 timestamped interaction log $H$ 。 $P$ 包含 identity、locations、digital_context、habits、preferences、decision_criteria、social_graph 等字段； $H$ 记录过去的 (time, location, action) 条目。关键设计是 $P$ 只给 user simulator $π_{u}$ ，而 $H$ 只给 GUI agent $π$ 。因此 agent 不能直接读取用户画像，只能从行为日志和交互反馈中推断。

当 agent 在第 $t$ 步提出 clarification question $m_{t}$ ，即 $a_{t} = ask_user$ ，user simulator 生成 $r_{t} \sim π_{u} (\cdot ∣ m_{t}, P, S),$ 其中 $S$ 包括当前时间、地点等环境状态。Released code 中 BaseTask.initialize_user_agent_hook() 会构造“你正在扮演手机用户”的 system prompt，并把 task-specific relevant_information 暴露给 controller；默认 user-agent model 在代码中为 USER_AGENT_MODEL 环境变量，否则 fallback 到 gpt-4o-mini，而 .env.example 给的是 gpt-4.1。论文实验 §4.1 则写明 interaction-needed tasks 使用 gpt-4o 作为 $π_{u}$ ，所以复现实验时应显式设置环境变量，而不能依赖 released code 默认值。

3.4 Task taxonomy: general, personalized, proactive

KnowU-Bench 含 42 个 general tasks、86 个 personalized tasks、64 个 proactive tasks。每个 task 初始化时给 agent 一个 instruction $g$ ；personalized/proactive task 还给 exposed logs $H$ 和当前状态 $S$ 。用户角色包括 Researcher、Developer、Student、Grandma 四类，released code 中对应 src/knowu_bench/user_profile/*.yaml 与 src/knowu_bench/user_logs/*.json。

模型动作由下式描述： $a_{t} \sim π (a ∣ g, o_{t}, h_{< t}, H, S, r_{t}), a_{t} \in A .$ 这里 $o_{t}$ 是当前截图， $h_{< t}$ 是历史交互， $r_{t}$ 是最近一次 ask_user 的回复。General tasks 测试明确 GUI execution；personalized tasks 测试在 vague instruction 下从日志和澄清中满足偏好；proactive tasks 测试 routine-like 场景中的 act / silent / stop 决策。

Figure 7 解读：general case 中 agent 只需完成明确 GUI 操作，例如打开 Contacts、选择联系人并拨号。它主要验证 grounding、navigation 和 app-state checking，而不要求 preference inference。

Figure 8 解读：personalized case 中任务看似只是“发状态”，但正确内容依赖用户习惯、语气和历史偏好。绿色路径代表 agent 成功把 vague instruction 映射成符合用户偏好的实际操作；这类任务正是传统 GUI benchmark 难以覆盖的部分。

Figure 9 解读：proactive case 不再由用户明确要求执行，而是要根据时间、地点、routine 和当前上下文判断是否应该主动提醒或行动。评价重点从“能否完成动作”扩展到“是否应该行动”。

3.5 Hybrid evaluation: deterministic checks + LLM-as-a-judge

KnowU-Bench 使用 hybrid evaluation。Rule-based component 读取 app state、local storage、backend database、callback files 和 trajectory logs，保证硬约束可复现；LLM-as-a-judge component 根据 task-specific weighted rubric 判断 preference alignment、trade-off quality、communication style、contextual appropriateness、clarification quality 等语义维度。最终分数为： $S_{i} = λ_{i} S_{r u l e} + (1 - λ_{i}) S_{ll m}, λ_{i} \in [0, 1] .$ 对 fully deterministic tasks， $λ_{i} = 1$ ；对 pure semantic tasks， $λ_{i} = 0$ ；对 personalized tasks， $λ_{i}$ 按 preference-dependent requirements 的占比设置。Released code 中 scripts/calc_paper_metrics.py 使用 SUCCESS_THRESHOLD = 0.99 统计 success，并把 general / preference / routine tags 映射成论文里的 general / personalized / proactive；compute_proactive_policy_success() 进一步区分 reject、should-act、should-stay-silent 等 proactive policy buckets。

论文实验设置与 released code 默认配置差异：论文 §4.1 说明 interaction-needed tasks 使用 gpt-4o 作为 user simulator，但 released code 的 BaseTask.initialize_user_agent_hook() 默认 fallback 是 gpt-4o-mini，.env.example 示例是 gpt-4.1。因此 note 中所有评测解释按论文设定理解；若复现，应在 .env 中显式设置 USER_AGENT_MODEL=gpt-4o，否则 user simulator 可能与论文不同。

3.6 Implementation-style pseudocode based on released code

Code reference: main @ 0dd79895 (2026-05-04) — pseudocode and mapping based on this commit

def run_single_task(env, agent, task_name, max_step, traj_logger):
    task_goal = env.get_task_goal(task_type=task_name)
    obs = env.initialize_task(task_name=task_name)
    agent.initialize(task_goal)
    actions = []
 
    for step in range(1, max_step + 1):
        prediction, action = agent.predict({
            "screenshot": obs.screenshot,
            "tool_call": obs.tool_call,
            "ask_user_response": obs.ask_user_response,
        })
        actions.append(action.model_dump(exclude_none=True))
        traj_logger.log_traj(task_name, task_goal, step, prediction, action)
 
        if action.action_type in {"env_fail", "finished", "unknown"}:
            break
        obs = env.execute_action(action)
        if action.action_type == "answer":
            break
 
    score, reason = env.get_task_score(task_type=task_name)
    traj_logger.log_score(task_name, score, reason, actions)
    env.tear_down(task_name)
    return step, score

def initialize_user_simulator(task, controller):
    relevant_information = getattr(
        task,
        "relevant_information",
        "No more task-related information can be provided.",
    )
    controller.user_sys_prompt = (
        "You are acting as a mobile phone user. "
        "A mobile GUI agent is executing a task on your phone. "
        f"Task-related information: {relevant_information}"
    )
    controller.model_config = ModelConfig(
        model_name=os.getenv("USER_AGENT_MODEL", "gpt-4o-mini"),
        api_key=os.getenv("USER_AGENT_API_KEY", ""),
        url=os.getenv("USER_AGENT_BASE_URL", "https://api.openai.com/v1"),
    )

def switch_memory_interface(client, mode="all", source="noise", top_k=10):
    # mode="all": expose full timestamped user history H
    # mode="rag": expose retrieved snippets only
    return client.switch_suite_family(
        target_family="knowu_bench",
        user_log_mode=mode,
        rag_top_k=top_k,
        rag_backend="embedding",
        user_log_source=source,
    )

def hybrid_score(rule_score, llm_score, lambda_i):
    if lambda_i == 1.0:
        return rule_score
    if lambda_i == 0.0:
        return llm_score
    return lambda_i * rule_score + (1.0 - lambda_i) * llm_score

def proactive_policy_success(user_decision, habit_should_act, trajectory):
    if user_decision == "reject":
        # after rejection, only non-engagement / answer-style stopping actions are allowed
        return not any(is_stop_violation_action(a) for a in trajectory.after_reject())
    if habit_should_act is True:
        return any(is_substantive_answer(a) or is_engagement_action(a) for a in trajectory)
    if habit_should_act is False:
        return not any(is_engagement_action(a) for a in trajectory)
    return None

Paper Concept	Source File	Key Class/Function
Android emulator / FastAPI orchestration	`src/knowu_bench/core/server.py`	`FastAPI`, `ensure_controller`, `initialize_suite_family`, `AVD_MAPPING`
ADB-backed action execution and snapshots	`src/knowu_bench/runtime/controller.py`	`AndroidController`, `execute_action`, `load_snapshot`, app helpers
Client-side task lifecycle	`src/knowu_bench/runtime/client.py`	`AndroidEnvClient`, `switch_suite_family`, `execute_action`, `get_task_score`
Evaluation loop	`src/knowu_bench/core/runner.py`	`_execute_single_task`, `_init_env`, `run_agent_with_evaluation`
User simulator initialization	`src/knowu_bench/tasks/base.py`	`BaseTask.initialize_user_agent_hook`, `BaseTask.initialize_task`, `BaseTask.is_successful`
Profile-expanded task registry	`src/knowu_bench/tasks/registry.py`	`TaskRegistry._scan_and_register_tasks`, `_get_user_profiles`, `_register_task_instance`
Paper metric aggregation	`scripts/calc_paper_metrics.py`	`infer_split`, `summarize_split`, `compute_proactive_policy_success`
Difficulty-sliced metrics	`scripts/calc_split_difficulty_metrics.py`	`infer_difficulty`, `init_metrics`, `format_output`
Evaluation launch config	`scripts/run_eval.sh`, `scripts/run_claude_pref_routine.sh`	`MAX_ROUND=50`, `USER_LOG_SOURCE=noise`, `USER_LOG_MODE=all`, `RAG_TOP_K=10`, `RAG_BACKEND=embedding`

4. Experimental Setup (实验设置)

4.1 Benchmark scale and data

KnowU-Bench 包含 192 个 tasks：42 general tasks、86 personalized tasks、64 proactive tasks。App coverage 为 23 个 Android apps；Appendix C/Table 5 显示它在 MobileWorld 基础上扩展到更多 commerce / daily service 场景，例如新增 shopping app jingdian，以及 food delivery apps chilemei、tuantuan，使 cross-platform preference following 可被评估。Released README 的 snapshot 还显示当前 checkout 注册 192 tasks、94 个 agent-user-interaction tasks、4 个 user profiles（developer、grandma、student、user）。

4.2 Baselines

论文评测 11 个模型，分三组：GUI-specific models 包括 MAI-UI-8B、UI-Venus-1.5-8B、GUI-Owl-1.5-8B；general open-source models 包括 Qwen3-VL-8B、Qwen3-VL-32B、Qwen3.5-9B、Qwen3.5-122B-A10B、Qwen3.5-397B-A17B；closed-source models 包括 Gemini 3.1 Pro Preview、Claude Sonnet 4.6、Seed 2.0 Pro。

4.3 Metrics

General 与 proactive columns 使用 Success Rate (SR)。Personalized tasks 同时报告 strict SR 和 Average Score，因为很多任务可能部分满足用户偏好但没有完全成功。Figure 3 还报告 role-wise average score、Efficiency（定义为 $50/ Avg. Steps$ ）、Average Queries、Interaction Efficiency (IE)，以及 proactive 的 Act、Silent、Stop 三类 policy-aware rates。Judge sensitivity 使用 26 条固定 task trajectories，与 4 位 human experts 的平均评分比较，并报告 mean absolute error。

4.4 Evaluation configuration and reproducibility

这不是训练论文，没有报告 GPU type/count、learning rate、batch size 或 training steps；核心配置是 evaluation runtime。论文 §4.1 采用 all + noisy 作为默认 user-log setting：full history (all) 暴露完整日志，rag 暴露 retrieved log snippets；clean 只保留 preference-related entries，noisy 加入 irrelevant entries。Interaction-needed tasks 使用 gpt-4o 作为 user simulator $π_{u}$ 。

Released code 的实际 launch defaults 需要从脚本而不是 base defaults 读取：scripts/run_eval.sh 默认 TASK_TAGS=routine,preference,general、MAX_ROUND=50、MAX_CONCURRENCY=8、STEP_WAIT_TIME=10、USER_LOG_SOURCE=noise、USER_LOG_MODE=all、RAG_TOP_K=10、RAG_BACKEND=embedding；scripts/run_claude_pref_routine.sh 默认只跑 routine,preference，MAX_CONCURRENCY=4、STEP_WAIT_TIME=4，同样使用 noise/all/embedding。Docker image 默认为 ghcr.io/yaosqz/knowu-bench:latest，Android device family 为 rooted Pixel 8 AVD。

5. Experimental Results (实验结果)

5.1 Main results on KnowU-Bench

Table 2 的核心结论是 difficulty progression：general easy split 上 MAI-UI-8B 和 Seed 2.0 Pro 都达到 100.0% SR，说明明确 GUI instruction 的执行已不是最主要瓶颈；但 hard personalized split 上 Claude Sonnet 4.6 只有 44.2% SR，所有 open-source models 都低于 12%；proactive tasks 的排名又不同，说明 initiative calibration 不是 preference disambiguation 的简单延伸。

Model	Overall SR	Gen easy	Gen hard	Pers easy SR/Score	Pers hard SR/Score	Pro easy	Pro hard
UI-Venus-1.5-8B	26.0	72.2	25.0	18.6 / 0.48	7.0 / 0.40	34.4	31.3
Qwen3-VL-8B	21.9	72.2	4.2	7.0 / 0.27	7.0 / 0.25	46.9	21.9
GUI-Owl-1.5-8B	22.4	77.8	33.3	9.3 / 0.42	2.4 / 0.34	28.1	21.9
MAI-UI-8B	26.0	100.0	29.2	16.3 / 0.40	11.9 / 0.31	17.9	22.2
Qwen3.5-122B-A10B	27.1	94.4	25.0	30.2 / 0.69	9.5 / 0.60	25.0	12.5
Qwen3-VL-32B	29.2	77.8	25.0	18.6 / 0.44	2.4 / 0.26	50.0	34.4
Qwen3.5-9B	33.3	83.3	12.5	9.3 / 0.17	0.0 / 0.18	65.6	65.6
Qwen3.5-397B-A17B	37.5	83.3	20.8	25.6 / 0.59	2.3 / 0.48	68.8	56.3
Gemini 3.1 Pro Preview	44.3	94.4	66.7	34.9 / 0.78	20.9 / 0.75	50.0	38.9
Seed 2.0 Pro	51.6	100.0	62.5	32.6 / 0.65	27.9 / 0.57	62.5	62.5
Claude Sonnet 4.6	60.4	94.4	70.8	44.2 / 0.78	44.2 / 0.80	84.4	53.1

5.2 Role, interaction, and proactive behavior

Figure 3 解读：Figure 3(a) 显示角色差异显著，Claude Sonnet 4.6 在四类角色上保持 71.7%–79.4%，而 Seed 2.0 Pro 在 Researcher 上达到 71.3%、在 Grandma 上降到 48.5%。Figure 3(b) 表明“多问问题”不等于更好个性化：Claude Sonnet 4.6 只平均问 0.4 个问题，却达到 44.2% SR 和 78.9% average score；Seed 2.0 Pro 问得更多但效果更弱。Figure 3(c) 说明 proactive capability 必须拆成 Act、Silent、Stop：Claude Sonnet 4.6 的 Act 为 70.8%，Qwen3.5-397B-A17B Silent 为 73.7%、Stop 为 75.0%，但 Act 只有 31.8%；Qwen3.5-122B-A10B Stop 达 83.3%，但 Act/Silent 弱。

5.3 Memory ablation

Table 3 比较 personalized + proactive tasks 上的四种 memory settings。结论不是“RAG 一定更好”，而是 memory interface 与模型相关：Qwen3-VL-8B 从 full-log clean 的 13.6% 提升到 RAG-log clean 的 20.4%；UI-Venus-1.5-8B 更适合 full log；MAI-UI-8B 在 RAG noisy 下掉到 9.3%，说明 noisy retrieval 可能放大脆弱模型的偏好利用错误。

Model	Full Log Clean	Full Log Noisy	RAG Log Clean	RAG Log Noisy
MAI-UI-8B	11.1	13.6	12.3	9.3
Qwen3-VL-8B	13.6	17.2	20.4	19.8
UI-Venus-1.5-8B	15.6	20.3	13.7	19.6

5.4 Judge sensitivity and failure modes

Figure 4 解读：论文固定 26 条 task trajectories，与 4 位 human experts 的平均评分比较。Hybrid judge 相比 pure rule-based evaluator 更贴近对角线、MAE 更低，说明 deterministic rules 能保证硬约束可验证，而 LLM-as-a-judge 能补足 preference satisfaction、communication style 等难以手写规则的语义评价。

Figure 5 解读：personalized failures 中 Clarify 占 66.7%，Partial 占 27.1%，GUI 仅 4.2%，Preference misidentification 2.1%；这说明主要瓶颈不是点错界面，而是不知道如何询问与组合多重偏好。Proactive failures 中 Intervention 占 60.0%，Passive 20.0%，GUI 15.0%，Rejection 5.0%；Intervention + Passive 合计 80.0%，说明 proactive setting 的核心是 initiative calibration，且当前模型更容易 over-act。

5.5 Qualitative success and failure cases

Figure 10 解读：这是 personalized GUI navigation 的成功轨迹：agent 需要从用户历史中推断目标商品/偏好，再跨多个页面完成搜索、选择和下单相关操作。它展示了 preference inference 与 GUI grounding 必须同时正确。

Figure 11 解读：这是 proactive GUI navigation 的正例：agent 不是被明确要求执行，而是在 routine/context 满足时主动进入相应 app 完成动作。该类任务需要触发判断、执行路径和最终状态验证三者同时成立。

Figure 12 解读：insufficient clarification 展示模型没有问出足够关键的偏好问题就开始行动，导致最后状态不满足用户真实需求。这对应 Figure 5(a) 中最大失败类别 Clarify。

Figure 13 解读：partial preference satisfaction 表示模型捕捉到了部分偏好，但没有组合所有 constraints。例如商品、地点、时间、预算、社交对象中只满足一部分，导致 average score 可能不低但 strict SR 失败。

Figure 14 解读：preference misidentification 是更直接的偏好误读：agent 从日志中推断出错误偏好，或把一个角色/场景下的偏好迁移到不该迁移的任务中。相比 Clarify，它不是没问够，而是已有证据被错误解释。

Figure 15 解读：unwarranted intervention 对应 proactive Intervention failure：agent 在没有 routine 触发或没有充分理由时主动行动。对个人助理来说，这比普通 GUI error 更敏感，因为它会制造打扰和越权感。

Figure 16 解读：false passivity 是相反错误：上下文已经满足 proactive trigger，但 agent 保持沉默。它说明 safer proactive agent 不能简单通过“不行动”优化安全性，否则会丧失主动助理价值。

Figure 17 解读：post-rejection violation 展示用户拒绝后 agent 仍继续执行或没有及时停止。KnowU-Bench 把这类行为单独纳入 Stop metric，是因为尊重拒绝是 proactive assistance 的底线约束。

5.6 Limitations and conclusion

作者在结论中强调，KnowU-Bench 主要揭示的是从 competent GUI operator 到 trustworthy personal assistant 的差距。当前最强模型仍在 personalized decision making 与 proactive routine scenarios 上明显落后：它们可以导航界面，但尚不能稳定判断“对哪个用户、在什么时候、应该做什么”。未来方向包括更好的 long-term memory access、更强 ambiguity-resolution policy、更安全的 proactive decision boundary，以及 rejection-aware action policy。

Paper Notes

探索

KnowU-Bench: Towards Interactive, Proactive, and Personalized Mobile Agent Evaluation

KnowU-Bench: Towards Interactive, Proactive, and Personalized Mobile Agent Evaluation

1. Motivation (研究动机)

2. Idea (核心思想)

3. Method (方法)

3.1 Overall framework: environment, agent, user, evaluator

3.2 Reproducible Android environment

3.3 User simulator: hidden profile $P$ and exposed log $H$

3.4 Task taxonomy: general, personalized, proactive

3.5 Hybrid evaluation: deterministic checks + LLM-as-a-judge

3.6 Implementation-style pseudocode based on released code

4. Experimental Setup (实验设置)

4.1 Benchmark scale and data

4.2 Baselines

4.3 Metrics

4.4 Evaluation configuration and reproducibility

5. Experimental Results (实验结果)

5.1 Main results on KnowU-Bench

5.2 Role, interaction, and proactive behavior

5.3 Memory ablation

5.4 Judge sensitivity and failure modes

5.5 Qualitative success and failure cases

5.6 Limitations and conclusion

目录

Paper Notes

探索

KnowU-Bench: Towards Interactive, Proactive, and Personalized Mobile Agent Evaluation

KnowU-Bench: Towards Interactive, Proactive, and Personalized Mobile Agent Evaluation

1. Motivation (研究动机)

2. Idea (核心思想)

3. Method (方法)

3.1 Overall framework: environment, agent, user, evaluator

3.2 Reproducible Android environment

3.3 User simulator: hidden profile P and exposed log H

3.4 Task taxonomy: general, personalized, proactive

3.5 Hybrid evaluation: deterministic checks + LLM-as-a-judge

3.6 Implementation-style pseudocode based on released code

4. Experimental Setup (实验设置)

4.1 Benchmark scale and data

4.2 Baselines

4.3 Metrics

4.4 Evaluation configuration and reproducibility

5. Experimental Results (实验结果)

5.1 Main results on KnowU-Bench

5.2 Role, interaction, and proactive behavior

5.3 Memory ablation

5.4 Judge sensitivity and failure modes

5.5 Qualitative success and failure cases

5.6 Limitations and conclusion

目录

3.3 User simulator: hidden profile $P$ and exposed log $H$