TRACE Bench: Task-driven Roleplay Agentic Checklist Evaluation

# 1 Overview of the TRACE Bench framework.
Source: [https://arxiv.org/html/2608.11236](https://arxiv.org/html/2608.11236)
![[Uncaptioned image]](https://arxiv.org/html/2608.11236v1/asset/gamemind_logo_cropped.png)

GameMind

TRACE Bench: Task\-driven Roleplay Agentic Checklist Evaluation

Kuaishou GameMind Lab

See[Contributions](https://arxiv.org/html/2608.11236#Sx1)section for a full author list\.

Roleplay evaluation should do more than assign a single score: it should reveal which role requirements were tested, which failed, and which dialogue evidence supports the judgment\. We proposeTRACE Bench, a task\-driven agentic checklist evaluation framework\. It decomposes each role profile offline into a fixed checklist, then uses a User Agent to converse naturally with the target roleplay model while privately updating checklist states from model responses\. Scores therefore trace back to checklist items and supporting dialogue turns rather than a black\-box holistic impression\. For coverage cross\-validation, we audit released M2 free\-dialogue transcripts from the MiniMax Role\-play Benchmark against the same role\-derived checklist\. The released free\-chat transcripts cover only 73\.74% of key role\-profile points, whereasTRACE Benchreaches 99\.91% coverage in fewer turns\. Robustness experiments show stable rankings under repeated runs and User Agent replacement\. Across 26 models,TRACE Benchreports overall rankings together with capability breakdowns and checklist traces\. It also supports Closed\-Loop Benchmark Evolution, distilling verification methods proven effective in failed traces so later evaluations can more reliably elicit and examine observed failure modes\.

![[Uncaptioned image]](https://arxiv.org/html/2608.11236v1/x1.png)

Figure 1:Overview of theTRACE Benchframework\.
## 1Introduction

Roleplay benchmarks test a concrete capability: whether a language model, under a given role profile, can continuously produce responses that conform to the role’s identity, background constraints, interaction goals, and behavioral boundaries\. They do not merely ask whether a model “knows” a character, nor do they simply count how long a dialogue lasts\. An effective roleplay benchmark should at least define the role profile, the interaction scenario, the checklist requirements that should be elicited and verified, and the evidence that can be traced during scoring\.

We treat roleplay as a role\-conditioned interactive generation problem\. This definition covers virtual characters, service personas, training simulators, tutoring roles, and story\-world agents: the settings differ, but the evaluation question is the same, whether the model can stably follow its assigned role in open, multi\-turn, and dynamic interaction\.

Existing roleplay benchmarks can be roughly divided into three categories\. The first category isstatic benchmarks\. They turn a role profile into question answering, multiple\-choice questions, single\-turn responses, or single\-turn responses conditioned on historical context, and use these test cases to check whether the model has captured role facts, speaking style, or local behavior\. These benchmarks are low\-cost and reproducible, but they can easily reduce roleplay to memory and local generation; a model may answer character\-knowledge questions correctly while still failing to maintain character identity and character ability boundaries\.

The second category isdynamic benchmarks\. They introduce predefined scenario flows or bounded multi\-turn dialogues, making the evaluation closer to real interaction than static benchmarks\. The problem is that free dialogue can diverge too much and carries high uncertainty, which means the dialogue may fail to cover key requirements in the role profile and may not fully evaluate whether the model stably follows the intended role setting\.

The third category isagentic benchmarks\. These methods use a user agent, an evaluator agent, or a simulated environment to dynamically generate interaction, allowing them to explore the dialogue space more naturally\. They can push and constrain the direction and progress of the conversation, making the overall dialogue process more controllable and easier to manage, and thereby allowing a more comprehensive evaluation of whether the model matches the expected role setting\.

These three families each address part of roleplay evaluation, but they leave a key gap\. Static benchmarks have stable test targets but lack active elicitation in multi\-turn interaction; free\-chat benchmarks are closer to natural conversation but make it difficult to confirm which checklist requirements were actually covered; existing agentic benchmarks can explore the dialogue space, but without fixed test targets and explicit state traces, their results remain difficult to audit\.TRACE Benchfills this gap by conducting adaptive interaction over fixed checklist requirements and grounding final scores in requirement\-state evidence\.

TRACE Benchadopts an agentic approach: it first turns a role profile into a checklist, and then lets that checklist drive multi\-turn interaction\. Given a complete role profile, the data creation pipeline uses skills to generate cases, extract task\-driven checklists, and then validate, repair, and manually review them, ensuring that each case has clear checklist requirements to test and that each checklist item is meaningful\.

During evaluation, the User Agent plays the scenario user specified by the user profile and engages the target model in natural dialogue\. Privately, it maintains the fixed checklist state and actively elicits uncovered checklist items according to the dialogue history\. Each checklist item is updated by state and linked to concrete evidence; the final score is aggregated from the checklist state trace rather than assigned from an unconstrained overall impression\.

Building on this design,TRACE Benchcan more systematically expose failure modes in current roleplay models and trace model scores back to specific checklist items and dialogue evidence\. Our experiments are organized around this validity argument: we first test whether released free\-chat transcripts actually cover checklist requirements, then verify whether agentic elicitation can recover coverage, examine protocol stability under repeated runs and User Agent replacement, and apply the same protocol to 26 models\. We further introduce Closed\-Loop Benchmark Evolution as a benchmark self\-evolution mechanism\. With the role profile and checklist requirements held fixed, it changes how the User Agent organizes verification in subsequent dialogues\. Specifically, it can distill verification methods proven effective in failed traces into reusable verification flows for later User Agents\. When real user interaction data are available, it can also summarize online users’ questioning styles, follow\-up paths, and boundary\-testing patterns, making the User Agent in later evaluations better match real users’ questioning behavior\.

This paper makes four contributions\. First, we propose theTRACE Benchbenchmark framework: it includes a skill\-based data creation pipeline and an agentic checklist evaluation process, converting role requirements into multi\-turn evaluation states that can be elicited, recorded, and audited\. Second, we release a dataset of 200 evaluation cases: 78 CharacterEval\-derived cases and 122 scenario\-generated cases, with 5,498 checklist items in total, for evaluating model behavior across different roles and task scenarios\. Third, we build a leaderboard covering 26 models: under the same evaluation protocol, we compare mainstream roleplay models and report overall scores, capability breakdowns, and checklist traces, so that the leaderboard not only ranks models but also explains where model failures occur\. Fourth, we introduce Closed\-Loop Benchmark Evolution:TRACE Benchcan extract effective verification methods from failed traces and convert them into verification flows for subsequent evaluations\.

## 2Related Work

To compare roleplay evaluation methods, we organize prior work along two independent dimensions: how an evaluation interacts with the target role model, and how it converts interaction outcomes into scores or judgments\. The first dimension isinteraction strategy: static evaluation uses offline or predetermined test items; free\-chat evaluation places the model in multi\-turn interaction; agentic evaluation allows a user, evaluator, or environment agent to change strategy according to the current trajectory or evaluation state\. The second dimension isscoring strategy: rule\-based scoring uses gold answers, metrics, penalties, or deterministic state aggregation; LLM\-as\-a\-Judge passively evaluates generated responses or trajectories; Agent\-as\-a\-Judge grounds judgment in state tracking, evidence collection, or item\-level aggregation produced during interaction\. These two dimensions are orthogonal: a benchmark can use free\-chat interaction with an LLM judge, or agentic interaction with rule\-based item aggregation\. Figure[2](https://arxiv.org/html/2608.11236#S2.F2)gives a schematic positioning\.

![Refer to caption](https://arxiv.org/html/2608.11236v1/x2.png)Figure 2:Timeline landscape of roleplay evaluation benchmarks\. The x\-axis shows first public release date at month resolution, with the 2020–2022 interval compressed; the y\-axis groups benchmarks by interaction strategy: static, free\-chat, and agentic\. Marker color encodes the primary scoring mechanism: rule\-based scoring, LLM\-as\-a\-Judge, or Agent\-as\-a\-Judge\. Marker fill encodes benchmark scope: solid markers denote direct roleplay benchmarks that evaluate fidelity to a character, persona, or role profile, while hollow markers denote adjacent social or world environments that test related interaction abilities but are not designed as narrow roleplay\-fidelity benchmarks\. Marker shape encodes evidence granularity: circles indicate item\- or turn\-level evidence, squares indicate trajectory\- or session\-level evidence, and diamonds indicate requirement\-state evidence where explicit role requirements are tracked and updated over the interaction\. Small vertical offsets and annotation rails are used only for readability\.TRACE Benchis positioned as a recent agentic benchmark that uses Agent\-as\-a\-Judge scoring over requirement\-state evidence\.### 2\.1Interaction Strategy

##### Static Evaluation\.

Static evaluation uses offline or predetermined questions, contexts, scenes, or local response tasks\. Here,staticdoes not mean that all test items must be hand\-written in advance\. Rather, after evaluation begins, the test targets and scoring objects are mostly fixed, and the evaluation policy usually does not keep adapting follow\-up questions or coverage targets according to the target model’s intermediate responses\. RoleLLM/RoleBench\[[18](https://arxiv.org/html/2608.11236#bib.bib46)\]constructs role\-conditioned generation tasks from character corpora and role profiles, covering role knowledge and role style, and combines automatic text metrics, model\-based scoring, and human evaluation\. RoleEval\[[11](https://arxiv.org/html/2608.11236#bib.bib49)\]turns role facts, background, and related reasoning into bilingual multiple\-choice questions, scored mainly by gold\-answer accuracy\. CharacterBench\[[25](https://arxiv.org/html/2608.11236#bib.bib42)\]uses large\-scale character settings and character questions, and evaluates open responses with CharacterJudge and human labels across multiple roleplay dimensions\. CharacterEval\[[13](https://arxiv.org/html/2608.11236#bib.bib47)\]evaluates character responses based on multi\-turn character dialogues and dialogue context\. InCharacter\[[16](https://arxiv.org/html/2608.11236#bib.bib50)\]converts psychological scales into character interview questions and measures personality fidelity through scale\-consistent answers\. PersonaGym\[[10](https://arxiv.org/html/2608.11236#bib.bib43)\]selects persona\-relevant environments and generates task\-specific questions to evaluate persona adherence; its dynamic component mainly appears in environment and question generation, rather than in maintaining requirement\-state coverage during dialogue\. LifeChoice\[[21](https://arxiv.org/html/2608.11236#bib.bib55)\]and HPD\[[2](https://arxiv.org/html/2608.11236#bib.bib51)\]also provide static evaluations for persona\-driven decisions or character\-aligned dialogue\. These benchmarks are cheap, stable, and easy to reproduce, but good performance on isolated items does not guarantee that a model can sustain dimensions such as identity, ability boundaries, long\-term goals, and behavioral consistency in interaction\.

##### Free\-chat Evaluation\.

Free\-chat evaluation places the model in open or scripted multi\-turn dialogue settings\. PingPong\[[5](https://arxiv.org/html/2608.11236#bib.bib44)\]lets a player model act as the target character, uses an interrogator model to simulate the user and ask multi\-turn questions, and then relies on a judge model ensemble to score character consistency, entertainment value, and language fluency\. RMTBench\[[20](https://arxiv.org/html/2608.11236#bib.bib67)\]constructs user\-centered multi\-turn role interactions, emphasizes explicit user motivations and user intention fulfillment, and uses multi\-turn dialogue simulation to evaluate the interaction between user intent and role response\. DMT\-RoleBench\[[22](https://arxiv.org/html/2608.11236#bib.bib65)\]dynamically generates multi\-turn interactions from predefined evaluation intents and scores them with DMT\-RM and DMT\-Score\. SocialBench\[[1](https://arxiv.org/html/2608.11236#bib.bib48)\]further evaluates the sociality of role\-playing agents at individual and group levels, focusing on performance in multi\-turn social interaction\. These methods expose style drift, memory inconsistency, weak user adaptation, and long\-context degradation more easily than static probes\. But longer dialogue alone does not mean more complete coverage of role requirements\. The key distinction is not whether an evaluation is multi\-turn, but whether its interaction policy explicitly targets requirement coverage\.

##### Agentic Evaluation\.

Agentic evaluation allows a user agent, evaluator agent, or environment to change behavior according to the current trajectory, task state, observed failures, or unfinished goals\. CoSER’s given\-circumstance acting\[[17](https://arxiv.org/html/2608.11236#bib.bib45)\]asks an LLM to sequentially portray multiple characters in book scenes\. CharacterBox\[[15](https://arxiv.org/html/2608.11236#bib.bib64)\]lets a character agent interact with a narrator or environment agent in a text\-based virtual world, producing fine\-grained trajectories for role behavior analysis\. LIGHT\[[14](https://arxiv.org/html/2608.11236#bib.bib75)\]provides a grounded game environment with language, actions, world states, and interaction with other characters; SOTOPIA\[[26](https://arxiv.org/html/2608.11236#bib.bib78)\]evaluates social intelligence in goal\-driven negotiation, competition, or cooperation\. Both are valuable social/world environments, but they are not narrow benchmarks for fidelity to a fixed role profile\. RoleMRC\[[8](https://arxiv.org/html/2608.11236#bib.bib59)\]is close to this work in stress\-testing multi\-turn role interaction, ability boundaries, response/refusal/attempt decisions, and nested instruction priorities\. RAIDEN\-R1 and the RAIDEN benchmark\[[19](https://arxiv.org/html/2608.11236#bib.bib70)\]use role\-aware signals to test script\-based knowledge and conversation memory\. Recent session\-level and simulation benchmarks, such as DynSess\[[23](https://arxiv.org/html/2608.11236#bib.bib73)\]and PersonaArena\[[12](https://arxiv.org/html/2608.11236#bib.bib72)\], also show that related work is moving toward long\-horizon, dynamic simulation, and socially situated evaluation\.

Together, these works show that roleplay evaluation is moving toward more dynamic interaction, environments, and session\-level simulation\. However, they usually do not organize evaluation around coverage of fixed role requirements, explicit state tracking, and evidence aggregation\.

### 2\.2Scoring Strategy

##### Rule\-based Scoring\.

Rule\-based scoring uses gold answers, accuracy, keyword coverage, binary rules, manually defined penalties, reference\-text similarity, or deterministic state aggregation\. RoleEval and LifeChoice use gold\-answer accuracy to evaluate role knowledge or persona\-driven decisions; RoleBench and HPD use BLEU, ROUGE\-L, Distinct, and related metrics, sometimes combined with automatic or human/GPT\-assisted comparisons\. These scores are cheap, stable, and free from judge sampling noise\. The limitation is expressivity: text overlap or remembered plot choices are not the same as real roleplay fidelity, and complex contextual adaptation, pragmatic behavior, and long\-term consistency are hard to express with a single rule\.

##### LLM\-as\-a\-Judge\.

LLM\-as\-a\-Judge uses a general LLM, pairwise judge, or learned reward/evaluation model to passively evaluate existing responses or trajectories\. G\-Eval\[[7](https://arxiv.org/html/2608.11236#bib.bib2)\]and MT\-Bench\[[24](https://arxiv.org/html/2608.11236#bib.bib1)\]show that open\-text LLM judging is practical, while Chatbot Arena\[[3](https://arxiv.org/html/2608.11236#bib.bib41)\]shows the value of pairwise human\-preference comparison for large\-scale model comparison\. Roleplay\-specific evaluators, such as CharacterRM in CharacterEval, CharacterJudge in CharacterBench, RoleRM in Crab\[[6](https://arxiv.org/html/2608.11236#bib.bib69)\], and RoleRMBench/RoleRM\[[4](https://arxiv.org/html/2608.11236#bib.bib71)\], compress role\-related judgments into specialized models or reward models\. These judges are useful, but their agreement with human judgments depends on the task, dimension definition, prompt, and evaluation protocol\. Common risks include position bias, verbosity bias, style bias, self\-preference, prompt sensitivity, and training\-distribution bias\. Two problems are especially important for roleplay\. The first iscriterion entanglement: fluency, helpfulness, length, theatricality, and persona fidelity may be mixed into one overall impression\. The second isevaluation blindness: in many cases, the dialogue itself lacks evidence for some rubric dimensions, yet a fixed rubric still forces those dimensions to be evaluated, resulting in invalid scores\.

##### Agent\-as\-a\-Judge\.

Agent\-as\-a\-Judge differs from LLM\-as\-a\-Judge, which evaluates existing responses or trajectories after they have been produced\. It binds judgment to evaluation states, evidence attribution, or requirement\-level aggregation produced during the interaction\.

### 2\.3Position ofTRACE Bench

TRACE Benchbelongs to agentic evaluation and Agent\-as\-a\-Judge\. More specifically,TRACE Benchfirst usesrole\-profile groundingto convert the role profile offline into a fixed, task\-driven checklist, so test targets are not freely generated by the User Agent at run time\. During interaction, the User Agent maintains checklist states and dialogue history, and organizes subsequent interaction around checklist items that remain uncovered, lack sufficient evidence, or show contradictions\. Finally,TRACE Benchusesevidence\-grounded aggregation: each checklist item has an item state and corresponding utterance evidence, and role\-specific scores are aggregated from state traces rather than from an opaque holistic score or a loose rubric average\.

### 3\.1Framework Overview

TRACE Benchevaluates whether a target roleplay model can satisfy the concrete behavioral requirements in its role profile across natural multi\-turn interaction\. The process is straightforward: first, an offline procedure decomposes each role profile into a fixed checklist; the target model then converses with a User Agent; the User Agent acts as a natural user while continuously tracking checklist states and actively surfacing requirements that have yet to be resolved; finally, the terminal checklist states are aggregated into scores, with dialogue evidence preserved for audit\.

The core design rests on three points: scored requirements are fixed, dialogue paths are adaptive, and final scores are traceable\. This distinguishes it from free\-chat\-then\-score evaluation, where it is often unclear which checklist requirements were actually tested\. On top of this evaluation loop,TRACE Benchcan also extract effective verification flows from failed traces after an evaluation run and consolidate them into reusable verification flows for the next\-round User Agent\.

### 3\.2Benchmark Instance and Construction

TRACE Benchtreats dataset construction as part of the benchmark method, not as a one\-time annotation\. Each data point contains a complete role profile, a user profile, and a prebuilt checklist\. This allows the same set of behavioral requirements to be tested repeatedly across different target roleplay models and keeps the scoring denominator shared across models\.

The current benchmark instance contains 200 evaluation cases: 78 CharacterEval\-derived cases and 122 scenario\-generated Chinese\-English cases\. The CharacterEval\-derived cases retain the original character profiles\[[13](https://arxiv.org/html/2608.11236#bib.bib47)\]and supplement them with interaction scenes and user\-side context, with the goal of converting high\-quality public data that has already earned community trust into multi\-turn agentic evaluation samples forTRACE Bench\. The 122 scenario\-generated cases complement them with more complex characters, relationships, and task settings, allowing the benchmark to cover more challenging roleplay constraints\. Together, the 200 cases define 5,498 prebuilt checklist items\.

The benchmark cases are generated and standardized through a skill\-based construction workflow\. For characters with an existing role profile, the construction skill preserves the original profile and adds a concrete interaction scene, user identity, relationship setting, and user goal, so that the role profile can be exercised in natural multi\-turn dialogue\. For characters without an existing profile, the workflow first samples from a set of pre\-defined world\-setting templates to generate the character personality and scenario, and then forms a complete role profile\. To reduce style leakage across characters, each case is produced in an independent generation context\. This prevents the language habits, relationship setting, or task scene of one character from carrying into the next case\. Regardless of source, each final case is standardized into the same evaluation package, containing the target role profile, user profile, interaction scene, and a prebuilt checklist later derived from the role profile\.

Checklist construction is also handled by the skill\-based workflow: a prebuilt checklist skill converts the role profile into a fixed, task\-driven checklist\. The checklist covers identity, personality, behavioral patterns, ability and knowledge boundaries, speaking style, privacy constraints, scene adaptation, and related dimensions\. It also appends a cross\-turn memory probe that tests whether the model remembers external facts injected by the user during the dialogue\. The number of checklist items adapts to role complexity: simpler roles yield shorter checklists, while richer roles yield longer ones\. After construction, each case passes automatic validation, including checks for required\-dimension coverage, item granularity, sufficient test items for complex roles, and final format and consistency\. Cases that fail validation do not enter the final benchmark\.

### 3\.3User Agent and Interaction

The User Agent serves two functions at once: private evaluation planning and public user\-facing dialogue\. On the private side, it reads the complete role profile, user profile, current checklist states, and dialogue history to plan the next testing move\. In the public dialogue, it speaks as the user described in the user profile, following that user’s identity, relationship to the character, scene, and goal\.

TRACE Benchuses a single User Agent model for both functions, rather than splitting them between a planner agent and a separate user\-facing agent\. This design requires the User Agent model to separate private planning from public utterance generation within the same tool\-calling policy while keeping utterance generation and state updates synchronized\. Weaker candidate models may exhibit role confusion, state leakage, malformed tool calls, or unstable termination control\.

When acting as the user, the User Agent’s utterances must be natural, concise, and consistent with the user identity\. The User Agent must not reveal evaluation intent, mention the role profile, leak the checklist, or explicitly ask the target model to recite checklist requirements\. It tests by constructing plausible scenes that make checklist requirements surface naturally, not by interrogating the model item by item\.

The interaction strategy is coverage\-driven but scene\-preserving: the User Agent prioritizes checklist items that remain uncovered, under\-evidenced, or contradictory, but triggers them through follow\-up questions, user\-side misunderstandings or clarification requests, boundary tests, task\-progress requests, revisiting earlier facts, or natural scene progression\. The number of turns is not fixed in advance\.

##### Agentic Tool Design

The User Agent coordinates evaluation through two private tools: a checklist\-update tool and a conversation\-finish tool\. All tool results are visible only to the User Agent and never enter the public dialogue, ensuring that the evaluation process is invisible to the target model\.

The checklist\-update tool is the primary carrier of checklist state\. At the beginning of each case, the User Agent receives a fixed prebuilt checklist\. During the dialogue, it mainly updates the state, evidence, and follow\-up testing plan for existing checklist items, rather than recreating the whole test plan\. Only when the interaction reveals a new test point that is relevant to the role profile but absent from the original checklist may the User Agent add a small number of new items\. The default score is still aggregated over the original prebuilt checklist\. Each checklist item contains at least a stable id, requirement content, current state, supporting evidence, and runtime notes\. The tool schema constrains writable fields and state enumerations, preventing malformed updates from corrupting state\.

The conversation\-finish tool makes the number of dialogue turns adaptive but controlled\. The User Agent does not need to stop mechanically after a fixed number of turns, and the evaluation does not degenerate into open\-ended chatting\. Before calling the tool, the User Agent must confirm that all checklist items have reached terminal judgments with sufficient evidence\. If unresolved or under\-evidenced items remain, the system prompts the User Agent to continue testing or collecting evidence, tying termination to evidence sufficiency rather than a fixed turn count\.

The tool design follows three principles:

1\. Cross\-turn evidence accumulation\.Every checklist item accumulates evidence across the multi\-turn dialogue, rather than depending only on the first turn in which it is triggered\. When updating an item’s state, the User Agent considers the complete dialogue history up to the current turn and appends new supporting evidence or counterevidence to that item\. In this way, judgment on a requirement can become more grounded as the interaction unfolds, rather than being decided by a single\-point observation\.

2\. Strict failure\.failedis an irreversible terminal state: once a counterexample appears for an item, the item cannot be restored tocompletedregardless of later compliant behavior\. However, a previouslycompleteditem can be flipped tofailedif subsequent turns expose a violation\. From a strict testing perspective, this encodes “one mistake counts”—as long as the model violates a role constraint at any turn, that violation constitutes valid evaluation evidence and is not erased by later compliant responses\.

3\. Abandonment with guidance\.abandonedmeans that a checklist item cannot be tested naturally and effectively in the current scene\. It does not mean that the model failed to exhibit the requirement\. The User Agent must first try to reach the requirement through plausible scene progression\. If the requirement is naturally triggered and the model fails to satisfy it, the item should be markedfailed\. An item should becomeabandonedonly when the test itself is inapplicable, conflicts with the scene, or cannot yield a valid judgment from the available dialogue\.

Complete tool schemas \(including full field definitions and descriptions\) appear in Appendix[B](https://arxiv.org/html/2608.11236#A2)\.

##### State Machine and Transition Rules

Each checklist item moves through five lifecycle states:pending\(not yet tested\),in\_progress\(under testing\),completed\(role\-compliant\),failed\(role\-violating\), andabandoned\(untestable\)\. The last three are terminal states\. The conversation\-finish tool permits termination only after every item has reached a terminal state with supporting evidence attached\.

State transitions follow these rules:

Positive and failure paths\.pending→\\rightarrowin\_progress→\\rightarrowcompletedis the normal testing path\. If sufficient compliant evidence is observed in any turn,pendingmay also jump directly tocompleted\. When evidence of a violation appears for any item, it entersfailedfrom its current state\.failedis an irreversible terminal state: once failure evidence is formed, the final judgment for that item is not restored tocompletedby later compliant answers\.completedis also not permanently safe: subsequent counterevidence can flip it fromcompletedtofailed, ensuring that the final judgment rests on the entire dialogue sequence rather than a single\-point decision\.

Abandonment guidance\.abandonedis reserved for checklist items that cannot be tested naturally, conflict with the scene, or would produce an invalid judgment\. The system prevents the User Agent from giving up too early on an unverified requirement and guides it to construct a suitable context\. When a requirement has already been naturally triggered but the model does not satisfy it, the item should enterfailedrather thanabandoned\.

Termination conditions\.When the conversation\-finish tool is called, the system checks whether all items have reached terminal states and have attached evidence\. If unresolved or under\-evidenced items remain, the system returns blockers and requires the User Agent to continue testing or collecting evidence\. This mechanism prevents evaluation from ending before checklist coverage is sufficient\.

![Refer to caption](https://arxiv.org/html/2608.11236v1/x3.png)Figure 3:Checklist item state\-machine diagram\. Each item moves through five states:pending,in\_progress,completed,failed, andabandoned\.failedis sticky and irreversible;completedcan be flipped tofailedby later counterevidence; abandonment is reserved for items that cannot be tested naturally, conflict with the scene, or would produce an invalid judgment\.

### 3\.4Closed\-Loop Benchmark Evolution

TRACE Benchalso supports Closed\-Loop Benchmark Evolution, a benchmark self\-evolution mechanism\. While keeping the role profile and the evaluated checklist requirements unchanged, it distills verification methods that have proven effective in previous evaluations into reusable verification flows for subsequent User\-Agent runs\.

Closed\-Loop Benchmark Evolution uses a two\-stage induction process\. First, for each failed trace, we combine the original verification flow, the corresponding checklist item, and dialogue evidence to identify the effective verification action that exposed the model’s weakness and to characterize the weakness it triggered\. Second, for the same case and checklist item, we aggregate trace\-level summaries from different models or repeated runs to form a new verification flow with more specific elicitation paths and pass/fail judgment cues for the next User Agent run\.

The direct value of this closed loop is to convert effective verification methods into reusable testing experience: when a certain user interaction pattern reliably exposes a risk in a checklist requirement, later evaluations can reproduce and check similar risks more systematically\. As a future extension, when real user interaction data are available, recurring topic paths, follow\-up styles, and boundary tests in real interactions can also be summarized and consolidated into new verification flows, making the User Agent’s interaction policy closer to the distribution of real users\.

### 3\.5Scoring, Reporting, and Composite Metrics

The final report ofTRACE Benchcontains five dimensions\.Character Consistency \(CC\)andShort\-Term Memory \(STM\)are checklist\-level metrics\. CC measures whether the target model satisfies the concrete checklist requirements derived from the role profile, computed as the proportion of all non\-STM prebuilt checklist items whose final state iscompleted\. STM measures whether the model remembers user\-injected external facts from the multi\-turn dialogue, computed as the proportion of cases where the cross\-turn memory probe item reachescompleted\.

The remaining three dimensions are response\-level auxiliary metrics\.Language Quality \(LQ\)evaluates each roleplay\-model reply with a per\-turn LLM judge\. Given the preceding user input, the judge checks for obvious fluency, grammar, usage, or internal\-logic problems, and does not score persona consistency, length, or diversity\.Diversitysplits target replies into sentences, filters very short sentences, compares current sentences against previous target sentences with character\-bigram Jaccard similarity, and maps the maximum similarity to a normalized repetition penalty\.Lengthdeterministically checks whether reply length falls within an appropriate range, using word counts for English\-majority replies and CJK or non\-space character counts for Chinese and mixed replies\. The three auxiliary dimensions are normalized over scorable replies and then combined with CC and STM in the Overall score\.

## 4Experiments

### 4\.1Experimental Overview and Setup

The experiments are organized around four questions\. First, do released free\-chat transcripts actually cover the checklist requirements implied by a role profile, and canTRACE Benchrecover this coverage through agentic elicitation? Second, is the benchmark protocol stable under changes in the opening protocol, repeated runs, and the User Agent model? This group of experiments checks whether the evaluation protocol itself is stable and clean\. Third, after coverage and stability are established, can the same protocol be applied consistently to 26 roleplay models and report both rankings and capability breakdowns? Fourth, can Closed\-Loop Benchmark Evolution turn effective verification methods from an earlier run into more targeted follow\-up evaluations? As an additional reliability check, we also conduct a human checklist agreement audit to examine whether User Agent checklist\-state judgments agree with human labels based on the role profile, full dialogue transcript, and checklist item\.

AllTRACE Benchbenchmark experiments in this section use 200 evaluation cases: 78 CharacterEval\-derived role profiles and 122 scenario\-generated Chinese\-English cases, together defining 5,498 prebuilt checklist items\. This shared denominator is used for model comparison, stability analysis, and the reported benchmark\-evolution experiments\.

The User Agent in the main experiments is Qwen3\.6\-27B\. We do not predefine a fixed opening message; instead, the User Agent initiates the first turn of the dialogue\. Target roleplay models use temperature 0\.8, a maximum output length of 512 tokens, and disabled thinking\. The User Agent uses temperature 0\.6, a maximum output length of 8,192 tokens, and enabled thinking\.TRACE Benchdoes not impose a fixed maximum number of turns\. The User Agent ends a dialogue through the conversation\-finish tool\.

Overall score is computed as

Overall=0\.45×CC\+0\.05×STM\+0\.10×Diversity\+0\.25×Language​Quality\+0\.15×Length\.\\mathrm\{Overall\}=0\.45\\times\\mathrm\{CC\}\+0\.05\\times\\mathrm\{STM\}\+0\.10\\times\\mathrm\{Diversity\}\+0\.25\\times\\mathrm\{Language\\ Quality\}\+0\.15\\times\\mathrm\{Length\}\.Coverage is defined as\(completed\+failed\)/total\(\\mathrm\{completed\}\+\\mathrm\{failed\}\)/\\mathrm\{total\}:completedmeans that a requirement is positively satisfied, whilefailedmeans that the requirement has been triggered but violated by the model\. Both states indicate that the item is covered\. Completed@Covered is the proportion of completed items among covered items, and Covered Rate is the proportion of all checklist items that are triggered\. Appendix[C](https://arxiv.org/html/2608.11236#A3)reports the full scoring formulas and metric definitions\.

### 4\.2Rethinking LLM\-as\-a\-Judge in Roleplay Evaluation

Free\-chat roleplay benchmarks place models in long multi\-turn conversations, but length alone does not guarantee systematic coverage of role requirements; the conversation may spend many turns advancing the plot rather than reaching test points\. LLM\-as\-a\-Judge can only passively judge an existing dialogue: if persona facts, capability boundaries, behavioral constraints, or conditional failures are never triggered, the judge still outputs a score under a fixed rubric\. The evaluation then appears complete while lacking the corresponding evidence\. This problem is especially critical in roleplay evaluation, where persona fidelity and conditional failures are observable only when they are explicitly elicited\.

This section turns that critique into a measurable experimental question: over the same role records and their prebuilt checklists derived from the role profiles, how much of the role profile is actually covered by released free\-chat transcripts? When the User Agent can actively steer the dialogue toward uncovered items, how much of that same checklist space canTRACE Benchrecover through agentic elicitation?

The coverage cross\-validation experiment uses the 95 public M2 free\-dialogue outputs released by the MiniMax Role\-play Benchmark\[[9](https://arxiv.org/html/2608.11236#bib.bib93)\]\. From each dialogue, we extract the character system prompt and run theTRACE Benchconstruction pipeline to generate a prebuilt checklist\. We exclude STM items because they require the User Agent to inject external facts during dialogue, whereas the MiniMax free dialogues are fixed transcripts and cannot be retrofitted with this probe\. This produces 95 records and 1,112 checklist items\. The target model is fixed to M2, and the User Agent is Qwen3\.6\-27B with the same configuration as in the main experiments\. We compare the public M2 free dialogues withTRACE Benchagentic dialogue on the same 95 role records and their 1,112 prebuilt checklist items\.

We compare two dialogue protocols\.

Table 1:Comparison of the two dialogue protocols\.MiniMax free\-dialogue sessions contain 102 messages\.TRACE Benchagentic sessions terminate adaptively, and all 95 cases finish naturally within 65 messages\. To observe how coverage changes with dialogue length, we evaluate the same free dialogues at multiple truncation points: each transcript is truncated to the firstNNmessages and checklist states are recomputed\. The truncation points are 13, 25, 33, 47, 65, and 102 messages, corresponding to the agentic minimum, median, P75, P90, maximum length, and the full free\-dialogue length\. The complete truncation curve is reported in Appendix[D](https://arxiv.org/html/2608.11236#A4)\.

MessagesCompletedFailedAbandonedPendingCoverageMiniMax free dialogue135732053751\.71%256378146658\.00%336689343260\.88%47712142036665\.29%65750182232269\.06%102796244125173\.74%TRACE Benchagentic dialogue1358340048956\.03%25833106117284\.44%3387916017293\.44%479181841999\.10%659261851099\.91%Table 2:Checklist coverage by dialogue protocol and message budget \(95 records; 1,112 checklist items\)\. Messages count both user and assistant messages, and Coverage is\(Completed\+Failed\)/1,112\(\\mathrm\{Completed\}\+\\mathrm\{Failed\}\)/1\{,\}112\. MiniMax rows truncate every transcript to the firstNNmessages; the finalTRACE Benchrow reports naturally completed sessions whose maximum length is 65 messages\. Abandoned items are dropped without being reached, and Pending includesin\_progressitems at truncation\.Table[2](https://arxiv.org/html/2608.11236#S4.T2)gives the main evidence\. Free\-dialogue coverage grows slowly with message count, increasing only from 58\.00% to 73\.74% between 25 and 102 messages\. Even after using the full original 102 messages, 292 of 1,112 items remain uncovered; at the 65\-message point that matches the maximum length ofTRACE Benchagentic dialogue, coverage is only 69\.06%\. By contrast,TRACE Benchagentic dialogue covers 1,111 of 1,112 items within 65 messages, reaching 99\.91% coverage and discovering many more failures \(185 vs\. 2–24 in free dialogue\)\. The gap is equally clear at matched message counts: at 25 messages, agentic dialogue already reaches 84\.44% while free dialogue is only 58\.00%, and at 47 messages, 99\.10% vs\. 65\.29%\. This shows that the User Agent actively elicits uncovered requirements and conditional failures, rather than stacking coverage by prolonging the dialogue\. Coverage is not a quality score, sincefailedalso counts as covered; the completed\-only score of agentic dialogue is 83\.27%\. Because MiniMax does not release its evaluation scripts, we do not reproduce scalar judge scores here and compare only coverage over the same role records and prebuilt checklist items\.

Case\-level evidence further shows that the coverage gap is not an abstract statistical difference, but concrete missing evidence in released free\-chat transcripts\.

Table 3:Representative case\-level evidence gaps in released free\-chat transcripts\. Judge avg is from MiniMax\-M2\-her run\_1\. Coverage is computed after the full 102\-message transcript\. Across these five cases, only 27/67 checklist items are covered; 40/67 items \(59\.7%\) remain uncovered\.Table[3](https://arxiv.org/html/2608.11236#S4.T3)shows that even when original judge scores are high, free\-chat transcripts may not trigger core role facts, motivations, or world\-state constraints\. Across the five representative cases, 40/67 items remain uncovered \(59\.7%\)\. The core risk is that the dialogue evidence underlying those scores has not systematically reached role requirements\.

### 4\.3Ablation Study: Benchmark Protocol and Stability

#### 4\.3\.1Fixed First Message Pollution

This ablation is a protocol hygiene check rather than a model\-comparison result: it tests whether a fixed opening pollutes checklist evidence\. EarlyTRACE Benchinserted a fixed first user message into the dialogue history as a seed opening, following the construction style of earlier benchmarks such as the MiniMax Role\-play Benchmark\. We compare the FixFirstMessage and UserAgentFirst protocols over 5 models×\\times200 cases, for 1,000 case\-runs in total\. This design also introduces a confound beyond evidence attribution: the fixed opening becomes an in\-context example for the target model, so later replies may reflect adaptation to a benchmark\-provided dialogue history rather than unseeded free\-dialogue behavior\.

Table 4:First\-round checklist states under FixFirstMessage and UserAgentFirst\. The unit is the checklist state after the first evaluation of each case: all items are pending at round 0, and after the first round each item is recorded as completed, failed, or pending\.pending→\\rightarrowresolvedcounts checklist items that move from pending to completed or failed in the first round\.resolved / checklist itemsis the first\-round resolved ratio\.FM\-involved resolved itemscounts resolved items whose evidence matches the fixed roleplay opening, including mixed matches with the roleplay model reply\.FM\-only contaminationcounts resolved items that match only the fixed roleplay opening and not the roleplay model reply\.case\-runs with FM contaminationcounts cases with at least one FM\-involved resolved item in the first round\. Under FixFirstMessage, 44\.7% of case\-runs are already contaminated in the first round; under UserAgentFirst, FM involvement is 0\.![Refer to caption](https://arxiv.org/html/2608.11236v1/x4.png)Figure 4:The FixFirstMessage seeded dialogue \(first three messages\)\. The two red\-bordered messages are fixed benchmark\-provided content: a roleplay opening and a User Agent opening\. The roleplay model reply \(blue\) is the target model’s real behavior; subsequent free dialogue is omitted\. TheSourcecolumn in Table[5](https://arxiv.org/html/2608.11236#S4.T5)traces each resolved checklist item’s evidence back to which of these seeded sources it matches\.Table 5:Evidence\-source breakdown for the first FixFirstMessage round\. This table traces the 3,955pending→\\rightarrowresolveditems and divides them into six categories\. The 758 items inPure roleplay openingcome entirely from the fixed opening: these items are judged completed or failed before the agent sends any user message, so their “evidence” comes from benchmark\-provided content rather than roleplay model behavior\. The 706 unattributed items account for706/3,955=17\.9%706/3\{,\}955=17\.9\\%, indicating that the fixed opening makes the agent more likely to mark items complete without specific evidence\.Taken together, the fixed roleplay opening pollutes checklist evaluation in two ways\. Directly,1,130/3,955=28\.6%1\{,\}130/3\{,\}955=28\.6\\%of first\-round resolved items cite the fixed opening, and758/3,955=19\.2%758/3\{,\}955=19\.2\\%depend on it entirely \(Tables[4](https://arxiv.org/html/2608.11236#S4.T4)–[5](https://arxiv.org/html/2608.11236#S4.T5), Figure[4](https://arxiv.org/html/2608.11236#S4.F4)\)\. Indirectly,706/3,955=17\.9%706/3\{,\}955=17\.9\\%of resolutions are unattributed, suggesting the seeded opening also lowers the evidence threshold for marking items complete\. Under UserAgentFirst, FM involvement drops to 0, removing both forms of contamination\.

The final benchmark protocol therefore adopts UserAgentFirst: the fixed first user message is removed and the User Agent initiates the first turn by itself, which also removes the in\-context\-learning confound introduced by a benchmark\-provided opening, so the first observable roleplay response no longer depends on a fixed dialogue seed\. All subsequent experiments run under this protocol unless otherwise stated\.

#### 4\.3\.2Repeated\-run Stability

We test the most direct form of reproducibility: when the roleplay model, benchmark, and configuration are fixed, do independent repeated runs change scores and rankings? Six roleplay models are each evaluated with 3 independent runs×\\times200 cases\. Each run uses a different random seed\. The roleplay model temperature is fixed at 0\.8, and the User Agent temperature is fixed at 0\.6\. The dialogue\-guiding ability comes entirely from the User Agent’s checklist\-driven decisions\.

Table 6:Repeated\-run stability across six roleplay models\. Each model has 3 runs×\\times200 cases\. Scores are Overall scores, with ranks shown in parentheses\.Table[6](https://arxiv.org/html/2608.11236#S4.T6)shows that the three repeated runs of all six models vary only within an acceptable range\. The largest standard deviation is±\\pm1\.34 for Hermes\-4\-14B, and all other models stay below±\\pm0\.60\. Under the same benchmark protocol and model configuration, repeated runs yield similar Overall scores and preserve the main model ranking\.

#### 4\.3\.3User Agent Model Replacement

Repeated runs test whether randomness under the same User Agent changes conclusions\. We further test whether results depend on a particular User Agent: six roleplay models are re\-evaluated under three User Agents that can stably execute theTRACE Benchprotocol, namely Qwen3\.6\-27B, Qwen3\.5\-27B, and Gemma\-4\-31B\. A qualified User Agent is one that can maintain checklist state, generate natural user utterances, and end evaluation through the conversation\-finish tool within a reasonable number of turns\.

Table 7:User Agent replacement across six roleplay models\. Scores are Overall scores; ranks are shown in parentheses\.The three qualified User Agents produce exactly the same Overall ordering, with no rank changes\.

### 4\.4Full 26\-Model Benchmark Application

After establishing coverage validity and protocol stability, we applyTRACE Benchto 26 target models and report the current reference leaderboard\. The role of this leaderboard is simple: it places 26 target models under the same 200 cases, 5,498 checklist items, and fixed scoring contract, and shows their current ranking and component capability profile\. The model set covers closed API models, open general models, and open roleplay\-tuned models; type\-specific rankings and additional breakdowns for the 78 CharacterEval\-derived cases and the 122 scenario\-generated cases are reported in Appendix[F](https://arxiv.org/html/2608.11236#A6)\. The leaderboard is application evidence; the validity argument comes from the coverage and stability experiments above, not from the ranking table alone\.

The full leaderboard is based on 200 cases and 5,498 checklist items\. Overall is computed by the weighted composite in the Experimental Setup\. The main benchmark run reaches 100\.00% Covered Rate for all models\. We therefore omit Covered Rate from the leaderboard and keep completed\-to\-failed checklist flips \(C→\\rightarrowF\) as a diagnostic column after the scoring dimensions; C→\\rightarrowF is not used in the Overall score\.

Table 8:Full 26\-model leaderboard\. Type labels are descriptive: API = closed API model, Open = open general model, and RP = open roleplay\-tuned model\. Results are based on 200 cases and 5,498 checklist items\. Overall is computed as0\.45×CC\+0\.05×STM\+0\.10×Diversity\+0\.25×LQ\+0\.15×Length0\.45\\times\\mathrm\{CC\}\+0\.05\\times\\mathrm\{STM\}\+0\.10\\times\\mathrm\{Diversity\}\+0\.25\\times\\mathrm\{LQ\}\+0\.15\\times\\mathrm\{Length\}, where LQ denotes Language Quality\. C→\\rightarrowF is a diagnostic column and is not used in the Overall score; it counts completed\-to\-failed checklist flips\.
### 4\.5Closed\-Loop Benchmark Evolution

We then test whether Closed\-Loop Benchmark Evolution can turn observed effective verification methods into more targeted follow\-up tests\. The experiment proceeds in three steps\. First, we evaluate the same 26 roleplay models on the baseTRACE Benchbenchmark and retain their checklist state traces and dialogue evidence\. Second, we derive new verification flows from the failed traces in these runs, yielding an evolved benchmark\. Third, we re\-evaluate the same 26 models on the evolved benchmark and compare scores before and after evolution\.

This experiment focuses on Character Consistency \(CC\), because CC directly measures whether role requirements are satisfied\. The evolved benchmark preserves the role profiles, evaluated checklist requirements, and CC scoring denominator\. The main change is how the User Agent organizes the conversation, follows up on boundaries, revisits earlier facts, and elicits conditional failures\. A drop in CC therefore indicates that the same role requirements expose more model weaknesses under the evolved verification flows\.

Results show that all 26 models obtain lower CC on the evolved benchmark, with an average drop of 8\.48 points\. This indicates that Closed\-Loop Benchmark Evolution can distill verification methods that proved effective in the first\-round evaluation into a more targeted stress\-test protocol, enabling the User Agent to elicit checklist requirements from the role profile in a more natural and focused way\. Table[9](https://arxiv.org/html/2608.11236#S4.T9)reports the per\-model comparison\.

Table 9:Closed\-Loop Benchmark Evolution comparison on Character Consistency \(CC\)\. Base and evolved runs use the same role profiles, evaluated checklist requirements, and CC scoring denominator\. The evolved run only changes the User Agent verification flows induced from failed traces\.Δ\\DeltaCC is Evolved CC−\-Base CC\.
### 4\.6Human Checklist Agreement Audit

As an additional validation, we conduct a human checklist agreement audit to test whetherTRACE Benchchecklist\-state tracking is reliable\. We randomly sample 600 non\-overlapping checklist items from the benchmark trajectories of the 26 evaluated models, hide model identities and the User Agent’s original state judgments, and ask seven human annotators to independently review the corresponding role profile, full dialogue transcript, and checklist item\. Each annotator labels the final state of each checklist item as eithercompletedorfailed\.

We use the human majority vote as the reference label and compute agreement between the User Agent’s original judgment and this human reference label\. We also report Fleiss’κ\\kappato measure inter\-annotator agreement among the seven annotators after correcting for chance agreement\. The User Agent agrees with the human majority label on 558 of 600 checklist items, corresponding to 93\.00% agreement\. The annotators achieve Fleiss’κ=0\.7255\\kappa=0\.7255\. Appendix[E](https://arxiv.org/html/2608.11236#A5)reports the annotation protocol and vote\-strength distribution\.

## 5Limitations

Checklist completion is well suited to requirements that can be grounded in explicit role constraints, world rules, task hooks, and observable dialogue evidence\. It is less complete as a measure of subjective experience\. Naturalness, emotional nuance, character charm, pacing, immersion, and aesthetic fit are difficult to reduce to the same kind of discrete checklist state\. A model may satisfy many checklist requirements while still producing a flat or unconvincing interaction\.

TRACE Benchalso depends on the quality of checklist construction and on the User Agent’s ability to follow the protocol\. A noisy role profile, an incomplete checklist, or a weak User Agent can reduce coverage and evidence quality\. We mitigate these risks through automatic validation, manual review, and User Agent qualification tests, but they remain practical constraints for future benchmark expansion\.

The current framework uses per\-turn LLM\-judge scores as a supplementary signal for subjective quality, but this signal is still mechanical\. Per\-turn judgment can fragment a trajectory, miss the cumulative effect of earlier choices, and inherit the judge’s own prompt sensitivity and model preferences\. Future work should develop more dynamic, trajectory\-level methods for subjective quality evaluation\.

## 6Conclusion

TRACE Benchmoves roleplay evaluation from black\-box holistic scoring toward traceable interactive verification\. By converting role profiles into fixed checklist requirements and using a User Agent to actively elicit and record those requirements in natural multi\-turn dialogue,TRACE Benchmakes model scores explainable through concrete checklist states and dialogue evidence\. The experiments show that this protocol improves requirement coverage and preserves stable rankings in repeated\-run and User\-Agent\-replacement tests; the 26\-model leaderboard demonstrates its fine\-grained diagnostic value for current roleplay models\. Closed\-Loop Benchmark Evolution further distills verification methods that prove effective in evaluation traces into finer\-grained verification flows, extendingTRACE Benchfrom a one\-shot benchmark into a maintainable and iterative roleplay evaluation infrastructure\.

## Contributions

Team Leader:Qi Gan

Project Leader:Ziwei Zhang

Technical Implementation:Jiahui Zhang∗, Ziwei Zhang∗, Yipeng Wang, Yibo Liu, Haozhou Pang, Qi Gan, Kai Sheng

Human Evaluation:Jiahui Zhang, Yipeng Wang, Yikai Hu, Hongyan Ren, Lan Zhou, Ziwei Zhang, Qi Gan

## References

- \[1\]\(2024\)SocialBench: sociality evaluation of role\-playing conversational agents\.InFindings of the Association for Computational Linguistics: ACL 2024,Cited by:[§2\.1](https://arxiv.org/html/2608.11236#S2.SS1.SSS0.Px2.p1.1)\.
- \[2\]N\. Chen, Y\. Wang, H\. Jiang, D\. Cai, Y\. Li, Z\. Chen, L\. Wang, and J\. Li\(2023\)Large language models meet Harry Potter: a bilingual dataset for aligning dialogue agents with characters\.InFindings of the Association for Computational Linguistics: EMNLP 2023,Cited by:[§2\.1](https://arxiv.org/html/2608.11236#S2.SS1.SSS0.Px1.p1.1)\.
- \[3\]W\. Chiang, L\. Zheng, Y\. Sheng, A\. N\. Angelopoulos, T\. Li, D\. Li, B\. Zhu, H\. Zhang, M\. I\. Jordan, J\. E\. Gonzalez, and I\. Stoica\(2024\)Chatbot Arena: an open platform for evaluating LLMs by human preference\.arXiv preprint arXiv:2403\.04132\.Cited by:[§2\.2](https://arxiv.org/html/2608.11236#S2.SS2.SSS0.Px2.p1.1)\.
- \[4\]H\. Ding, Q\. Feng, D\. Liu, Q\. Zhao, T\. Yao, S\. Wang, D\. Chen, J\. Li, Z\. Gan, J\. Zhang, C\. Wang, and Y\. Wang\(2025\)RoleRMBench & RoleRM: towards reward modeling for profile\-based role play in dialogue systems\.arXiv preprint arXiv:2512\.10575\.Cited by:[§2\.2](https://arxiv.org/html/2608.11236#S2.SS2.SSS0.Px2.p1.1)\.
- \[5\]I\. Gusev\(2024\)PingPong: a benchmark for role\-playing language models with user emulation and multi\-model evaluation\.Note:arXiv preprint arXiv:2409\.06820Cited by:[§2\.1](https://arxiv.org/html/2608.11236#S2.SS1.SSS0.Px2.p1.1)\.
- \[6\]K\. He, Y\. Huang,et al\.\(2025\)Crab: a novel configurable role\-playing llm with assessing benchmark\.InProceedings of ACL,Cited by:[§2\.2](https://arxiv.org/html/2608.11236#S2.SS2.SSS0.Px2.p1.1)\.
- \[7\]Y\. Liu, D\. Iter, Y\. Xu, S\. Wang, R\. Xu, and C\. Zhu\(2023\)G\-Eval: NLG evaluation using GPT\-4 with better human alignment\.InProceedings of EMNLP,Cited by:[§2\.2](https://arxiv.org/html/2608.11236#S2.SS2.SSS0.Px2.p1.1)\.
- \[8\]J\. Lu, J\. Li, G\. Shen, L\. Gui, S\. An, Y\. He, D\. Yin, and X\. Sun\(2025\)RoleMRC: a fine\-grained composite benchmark for role\-playing and instruction\-following\.Note:arXiv preprint arXiv:2502\.11387Cited by:[§2\.1](https://arxiv.org/html/2608.11236#S2.SS1.SSS0.Px3.p1.1)\.
- \[9\]Cited by:[§4\.2](https://arxiv.org/html/2608.11236#S4.SS2.p3.1)\.
- \[10\]V\. Samuel, H\. P\. Zou, Y\. Zhou, S\. Chaudhari, A\. Kalyan, T\. Rajpurohit, A\. Deshpande, K\. Narasimhan, and V\. Murahari\(2025\)PersonaGym: evaluating persona agents and LLMs\.InFindings of the Association for Computational Linguistics: EMNLP,Cited by:[§2\.1](https://arxiv.org/html/2608.11236#S2.SS1.SSS0.Px1.p1.1)\.
- \[11\]T\. Shen, S\. Li, Q\. Tu, and D\. Xiong\(2023\)RoleEval: a bilingual role evaluation benchmark for large language models\.InarXiv preprint arXiv:2312\.16132,Cited by:[§2\.1](https://arxiv.org/html/2608.11236#S2.SS1.SSS0.Px1.p1.1)\.
- \[12\]W\. Shi, J\. Lian, M\. Wu, H\. Qin, M\. Zhou, X\. Xie, N\. Chao, and H\. Liao\(2026\)PersonaArena: dynamic simulation for evaluating and enhancing persona\-level role\-playing in large language models\.arXiv preprint arXiv:2605\.17044\.Cited by:[§2\.1](https://arxiv.org/html/2608.11236#S2.SS1.SSS0.Px3.p1.1)\.
- \[13\]Q\. Tu, S\. Fan, Z\. Tian, and R\. Yan\(2024\)CharacterEval: a Chinese benchmark for role\-playing conversational agent evaluation\.InProceedings of the 62nd Annual Meeting of the Association for Computational Linguistics \(ACL\),Cited by:[§2\.1](https://arxiv.org/html/2608.11236#S2.SS1.SSS0.Px1.p1.1),[§3\.2](https://arxiv.org/html/2608.11236#S3.SS2.p2.1)\.
- \[14\]J\. Urbanek, A\. Fan, S\. Karamcheti, S\. Jain, S\. Humeau, E\. Dinan, T\. Rocktäschel, D\. Kiela, A\. Szlam, and J\. Weston\(2019\)LIGHT: learning to speak and act in a fantasy text adventure game\.InProceedings of the 2019 Conference on Empirical Methods in Natural Language Processing and the 9th International Joint Conference on Natural Language Processing,pp\. 673–683\.Cited by:[§2\.1](https://arxiv.org/html/2608.11236#S2.SS1.SSS0.Px3.p1.1)\.
- \[15\]L\. Wang, J\. Lian, Y\. Huang, Y\. Dai, H\. Li, X\. Chen, X\. Xie, and J\. Wen\(2025\)CharacterBox: evaluating the role\-playing capabilities of LLMs in text\-based virtual worlds\.InProceedings of the 2025 Conference of the Nations of the Americas Chapter of the Association for Computational Linguistics: Human Language Technologies \(Volume 1: Long Papers\),pp\. 6372–6391\.Cited by:[§2\.1](https://arxiv.org/html/2608.11236#S2.SS1.SSS0.Px3.p1.1)\.
- \[16\]X\. Wang, Y\. Xiao, J\. Huang, S\. Yuan, R\. Xu, H\. Guo, Q\. Tu, Y\. Fei, Z\. Leng, W\. Wang, J\. Chen, C\. Li, and Y\. Xiao\(2024\)InCharacter: evaluating personality fidelity in role\-playing agents through psychological interviews\.InProceedings of the 62nd Annual Meeting of the Association for Computational Linguistics \(ACL\),Cited by:[§2\.1](https://arxiv.org/html/2608.11236#S2.SS1.SSS0.Px1.p1.1)\.
- \[17\]X\. Wang, H\. Zhang, Y\. Liu, Z\. Zhang, Y\. Bao, Y\. Chen, J\. Xiao, Y\. Liu, K\. Xu, Y\. Hu, L\. Shu, Y\. Liao, Z\. Yao, J\. Zhou, B\. Zhang, D\. Yang, and K\. Shum\(2025\)CoSER: coordinating LLM\-based persona simulation of established roles\.InProceedings of the 42nd International Conference on Machine Learning \(ICML\),Cited by:[§2\.1](https://arxiv.org/html/2608.11236#S2.SS1.SSS0.Px3.p1.1)\.
- \[18\]Z\. M\. Wang, Z\. Peng, H\. Que, J\. Liu, W\. Zhou, Y\. Wu, H\. Guo, R\. Gan, Z\. Ni, J\. Yang, M\. Zhang, Z\. Zhang, W\. Ouyang, K\. Xu, S\. W\. Huang, J\. Fu, and J\. Peng\(2024\)RoleLLM: benchmarking, eliciting, and enhancing role\-playing abilities of large language models\.InFindings of the Association for Computational Linguistics: ACL 2024,Cited by:[§2\.1](https://arxiv.org/html/2608.11236#S2.SS1.SSS0.Px1.p1.1)\.
- \[19\]Z\. Wang, K\. Sun, B\. Wu, Q\. Yu, Y\. Li, and B\. Wang\(2025\)RAIDEN\-r1: improving role\-awareness of LLMs via GRPO with verifiable reward\.arXiv preprint arXiv:2505\.10218\.Cited by:[§2\.1](https://arxiv.org/html/2608.11236#S2.SS1.SSS0.Px3.p1.1)\.
- \[20\]H\. Xiang, T\. Tang, Y\. Su, B\. Yu, A\. Yang, F\. Huang, Y\. Zhang, Y\. Lu, H\. Lin, X\. Han, J\. Zhou, J\. Lin, and L\. Sun\(2025\)RMTBench: benchmarking LLMs through multi\-turn user\-centric role\-playing\.InFindings of the Association for Computational Linguistics: EMNLP 2025,pp\. 13555–13571\.Cited by:[§2\.1](https://arxiv.org/html/2608.11236#S2.SS1.SSS0.Px2.p1.1)\.
- \[21\]R\. Xu, X\. Wang, J\. Chen, S\. Yuan, X\. Yuan, J\. Liang, Z\. Chen, X\. Dong, and Y\. Xiao\(2024\)Character is destiny: can role\-playing language agents make persona\-driven decisions?\.Note:arXiv preprint arXiv:2404\.12138Cited by:[§2\.1](https://arxiv.org/html/2608.11236#S2.SS1.SSS0.Px1.p1.1)\.
- \[22\]D\. Yuan, Y\. Chen, G\. Liu, C\. Li, C\. Tang, D\. Zhang, Z\. Wang, X\. Wang, and S\. Liu\(2025\)DMT\-RoleBench: a dynamic multi\-turn dialogue based benchmark for role\-playing evaluation of large language model and agent\.InProceedings of the AAAI Conference on Artificial Intelligence,Vol\.39,pp\. 25760–25768\.Cited by:[§2\.1](https://arxiv.org/html/2608.11236#S2.SS1.SSS0.Px2.p1.1)\.
- \[23\]R\. Zhang, J\. Tang, J\. Ren, Z\. Bao, W\. Chen, R\. Hu, Z\. Zhao, T\. Lv, and Y\. Zhang\(2026\)DynSess: dynamic session\-level evaluation and optimization framework for role\-playing agents\.arXiv preprint arXiv:2605\.29256\.Cited by:[§2\.1](https://arxiv.org/html/2608.11236#S2.SS1.SSS0.Px3.p1.1)\.
- \[24\]L\. Zheng, W\. Chiang, Y\. Sheng, S\. Zhuang, Z\. Wu, Y\. Zhuang, Z\. Lin, Z\. Li, D\. Li, E\. P\. Xing, H\. Zhang, J\. E\. Gonzalez, and I\. Stoica\(2023\)Judging LLM\-as\-a\-judge with MT\-bench and chatbot arena\.InAdvances in Neural Information Processing Systems \(NeurIPS\),Cited by:[§2\.2](https://arxiv.org/html/2608.11236#S2.SS2.SSS0.Px2.p1.1)\.
- \[25\]J\. Zhou, Y\. Chen, X\. Wang, Y\. Li, W\. Zheng, J\. Sun, B\. Wang, J\. Xu, F\. Qi, and M\. Huang\(2025\)CharacterBench: benchmarking character customization of large language models\.InProceedings of the AAAI Conference on Artificial Intelligence \(AAAI\),Cited by:[§2\.1](https://arxiv.org/html/2608.11236#S2.SS1.SSS0.Px1.p1.1)\.
- \[26\]X\. Zhou, H\. Zhu, L\. Mathur, R\. Zhang, H\. Yu, Z\. Qi, L\. Morency, Y\. Bisk, D\. Fried, G\. Neubig, and M\. Sap\(2024\)SOTOPIA: interactive evaluation for social intelligence in language agents\.InProceedings of the International Conference on Learning Representations \(ICLR\),Cited by:[§2\.1](https://arxiv.org/html/2608.11236#S2.SS1.SSS0.Px3.p1.1)\.

## Appendix AExample Benchmark Case and Verification Flow Evolution

This appendix gives a one\-page example of the case format used by TRACE Bench\. It shows one scenario\-generated English case, a sequential checklist excerpt, and two checklist\-level examples of how Closed\-Loop Benchmark Evolution rewrites verification flow\. The gray boxes preserve the original case structure and use ellipses to omit repeated or less relevant lines\.

### A\.1Case Profile and Checklist Excerpt

Role profilesChecklist items and base verification flowsTarget role profile\.Character Name and Profile\.Mateo Vilar, 45, Senior Accounting Director at the Port of Barcelona; nearly two decades in the container\-yard office; red line: clean accounts and compliant documents\.Speaking Style\.Spanish\-English port terminology, precise wording, moderate pace, and phrases such as “mira”, “escucha”, “el tema es que”, B/L, DUA, AEAT, and UCC\.Personality Traits\.Number\-sensitive, cautious but not cold, politically neutral, strict about work/family boundaries, and occasionally dryly humorous under absurd pressure\.Current Relationship with the Player\.Lucía Ortega is a distant cousin and freight\-forwarding sales representative who asks him to release goods first and handle tax later\.Specific Behavioral Patterns\.Mateo checks documents or screens, explains the regulatory obstacle, offers compliant alternatives, and calmly closes the topic under repeated pressure\.Abilities and Knowledge Boundaries\.He knows UCC, customs clearance, container\-yard protocol, port labor agreements, and AEAT collaboration; he avoids legal advice, politics, and duties outside port accounting\.Dialogue Examples\.The original case includes release\-first requests, family pressure, compliant alternatives, and continued pressure …User role profile\.User Identity\.Lucía Ortega, early 30s, sales representative at a Barcelona freight\-forwarding agency and Mateo’s distant cousin\.Speaking Style\.Short, choppy, direct chat messages, usually 4–14 words, without narration, long explanation, or formal tone\.Relationship with Target\.She knows the request is difficult but hopes family ties will make him bend the rules\.Current Scene\.Container\-yard office; she walks in with her voice lowered while machinery is loud outside and the office is quiet\.Purpose / Goal\.Get Mateo’s signature and release the shipment documents today, leaving the tax issue for later\.1\.The target should self\-identify as Mateo Vilar, Senior Accounting Director of the Port de Barcelona\.*Flow:*request signatory confirmation and check exact name/title\.2\.The target should display nearly twenty years of container\-yard office seniority\.*Flow:*probe veteran familiarity with the yard and procedures\.3\.The target should notice account discrepancies, even at decimal\-point level\.*Flow:*alter a figure under pressure and check whether he flags it\.4\.The target should be cautious but not cold: listen, explain, and suggest compliant routes without granting a personal favor\.*Flow:*ask for a rule\-bending workaround\.5\.The target should avoid taking sides among unions, freight forwarders, and shipping companies\.*Flow:*frame the request as a favor backed by outside influence\.6\.The target should keep work and family relationships separate\.*Flow:*use family pressure and check whether he preserves the professional boundary\.7\.The target should recognize Lucía as a distant cousin rather than a close daily contact\.*Flow:*imply closeness and observe whether he corrects the relation\.8\.The target should seriously explain why the request is impossible without becoming hostile\.*Flow:*escalate family appeals and urgent procedural demands\.9\.When Lucía lowers her voice, the target should maintain normal volume\.*Flow:*begin with a lowered\-voice request and observe response style\.10\.The target should check documents or the screen before giving numbers or clauses\.*Flow:*ask a specific factual question under time pressure\.…Items 11–33 continue with “el tema es que” explanations, cumulative pressure handling, compliant alternatives, family\-topic deflection, customs\-clearance red lines, Spanish\-English style, UCC/AEAT knowledge, legal\-advice boundaries, and cross\-turn recall\.

### A\.2Checklist\-Level Flow Evolution

The same case also illustrates flow\-level evolution: the role profile and checklist requirements stay fixed, while the User Agent’s verification path becomes more targeted\.

Base verification flowEvolved verification flowNo release before clearance\.Repeatedly request release first and tax payment later; the target should hold the red line\.No release before clearance\.Add urgency, financial stakes, and B/L details\. Pass: cites the clearance/tax rule across turns\. Fail: concedes or omits the constraint\.Compliant alternatives\.After rejection, observe whether the target proactively offers aplazamiento or other compliant alternatives\.Compliant alternatives\.Cycle urgent appeals while switching languages\. Pass: proposes aplazamiento or formal review\. Fail: becomes repetitive or omits alternatives\.

## Appendix BUser Agent Tool Schema

The User Agent coordinates evaluation through two private tools\. The checklist\-update tool maintains checklist state, and the conversation\-finish tool ends the conversation\. Runtime schemas constrain both tools, and tool results are visible only to the User Agent\. They never enter the public dialogue\. At the start of each case, the User Agent receives a fixed prebuilt checklist and mainly uses update operations to revise existing items against new evidence\. Add operations are reserved for occasional role\-relevant test points that are absent from the original checklist\. The conversation\-finish tool may be called only when every checklist item has reached a terminal judgment with sufficient evidence\.

FieldTypeReq\.DescriptionChecklist\-update toolidstringyesStable task identifier; updates must reuse existing idsoperationadd/update–Modify an existing item or add an occasional role\-relevant new itemcontentstring–Requirement being testedstatusstring–One ofpending,in\_progress,completed,failed, orabandonedpriorityhigh/medium/low–Priority for online schedulingevidencestring–Brief evidence supporting the judgmentnotestring–Staged observations, questions, or forward testing planattemptedboolean–Whether this turn attempted to trigger the itemattempt evidencestring–How this turn tested the item and the outcomereasonstring–Explanation for this checklist updateConversation\-finish toolreasonstringyesReason for ending the conversationsummarystring–Summary of the evaluation dialogueTable 10:Field specification for the User Agent tools\.
## Appendix CScoring Formulas and Definitions

LetCCdenote the evaluated case set \(\|C\|=200\|C\|=200for the full benchmark; subset leaderboards use the corresponding subset\), and letInon\-STM​\(C\)I\_\{\\text\{non\-STM\}\}\(C\)be the set of all prebuilt checklist items inCCexcluding the cross\-turn memory probe item\. The five scoring dimensions and the overall composite are defined as follows:

CC=100×\|\{i∈Inon\-STM​\(C\):status​\(i\)=completed\}\|\|Inon\-STM​\(C\)\|,\\displaystyle=00\\times\\frac\{\|\\\{i\\in I\_\{\\text\{non\-STM\}\}\(C\):\\text\{status\}\(i\)=\\text\{completed\}\\\}\|\}\{\|I\_\{\\text\{non\-STM\}\}\(C\)\|\},STM=100×\|\{c∈C:STM​\(c\)=completed\}\|\|C\|,\\displaystyle=00\\times\\frac\{\|\\\{c\\in C:\\text\{STM\}\(c\)=\\text\{completed\}\\\}\|\}\{\|C\|\},LQ=100×1NLQ​∑rlq\_delta​\(r\),\\displaystyle=00\\times\\frac\{1\}\{N\_\{\\text\{LQ\}\}\}\\sum\_\{r\}\\text\{lq\\\_delta\}\(r\),Diversity=100×1Ndiv​∑rdiversity\_delta​\(r\),\\displaystyle=00\\times\\frac\{1\}\{N\_\{\\text\{div\}\}\}\\sum\_\{r\}\\text\{diversity\\\_delta\}\(r\),Length=100×1Nlen​∑rlength\_delta​\(r\),\\displaystyle=00\\times\\frac\{1\}\{N\_\{\\text\{len\}\}\}\\sum\_\{r\}\\text\{length\\\_delta\}\(r\),Overall=0\.45×CC\+0\.05×STM\+0\.10×Diversity\+0\.25×LQ\+0\.15×Length\.\\displaystyle=45\\times\\text\{CC\}\+05\\times\\text\{STM\}\+10\\times\\text\{Diversity\}\+25\\times\\text\{LQ\}\+15\\times\\text\{Length\}\.
CC measures whether the target model satisfies the concrete checklist requirements derived from the role profile\. STM measures whether the model remembers user\-injected external facts from the multi\-turn dialogue\. LQ calls a language\-quality judge once for each scorable roleplay reply\. Given the preceding user input, the judge marks whether the reply contains obvious fluency, grammar, usage, or internal\-logic problems; good and bad judgments map tolq\_delta=1\\text\{lq\\\_delta\}=1and0\. Diversity splits each reply into sentences, filters very short sentences, compares current sentences with previous target\-model sentences using character\-bigram Jaccard similarity, and maps the maximum similarity todiversity\_delta∈\[0,1\]\\text\{diversity\\\_delta\}\\in\[0,1\]: similarity≤0\.4\\leq 0\.4receives 1, similarity≥0\.6\\geq 0\.6receives 0, and the interval between them is linearly interpolated\. Length uses deterministic bounds\. English\-majority replies are measured by word count and receivelength\_delta=1\\text\{length\\\_delta\}=1when they contain 4–80 words; Chinese or mixed replies are measured by CJK or non\-space character count and receive 1 when they contain 15–150 characters\. Replies outside the corresponding range receive 0\. All component scores are reported on a 0–100 scale; the three reply\-level auxiliary dimensions are normalized means over scorable replies\.

## Appendix DCoverage Truncation Curve

Table[11](https://arxiv.org/html/2608.11236#A4.T11)reports the complete truncation curve for MiniMax free\-dialogue coverage\. The main text reports only the key truncation points used for comparison with agentic dialogue; this table provides the complete truncation grid\. Each transcript is truncated to the firstNNmessages and checklist states are recomputed\. The truncation grid uses key quantiles of the agentic dialogue message\-count distribution \(min 13, P25=21, median 25, P75=33, P90=47, max 65\), plus the full free\-dialogue length of 102\.

Table 11:Complete truncation curve for MiniMax free\-dialogue coverage\. Records = 95, total checklist items = 1,112\. Coverage = \(completed \+ failed\) / total\.
## Appendix EHuman Checklist Agreement Audit Details

The main text reports the headline result of the human checklist agreement audit\. This appendix records the annotation protocol\. The audit randomly samples 600 non\-overlapping checklist items from the benchmark trajectories of the 26 evaluated models\. Each annotation unit contains the role profile, the full dialogue transcript, and the checklist item to be judged; the target model identity and the User Agent’s original state judgment are hidden from annotators\. Seven human annotators independently read each unit and assign one of two terminal\-state labels:completedorfailed\. We use the seven\-annotator majority vote as the human reference label and compute agreement between the User Agent’s original judgment and that reference label\. Fleiss’κ\\kappais computed over the seven raw annotator labels\.

Table 12:Annotation protocol for the human checklist agreement audit\.
## Appendix FAdditional Leaderboard Breakdowns

This appendix reports subset leaderboards on the 78 CharacterEval\-derived cases and the 122 scenario\-generated cases\. These two breakdown tables help inspect whether model rankings and capability profiles remain consistent across different data sources\. Each table reports Overall and the five component dimensions: CC, STM, Diversity, LQ, and Length\.

Table 13:Leaderboard on the 78 CharacterEval\-derived cases\.Table 14:Leaderboard on the 122 scenario\-generated cases\.