LLM 与 Agent 应用测试（高频）

• 分层测试思想：从输入到行为的逐层验证
• Prompt 层：提示词正确性、格式、注入防护
• 模型输出层：语义、格式、安全、幻觉

大模型应用测试应分层，以便定位问题。第一层 Prompt 层：验证提示词本身——指令是否清晰、是否包含正确约束、是否防注入/越狱、对同一输入是否稳定。第二层模型输出层：验证 LLM 输出——语义正确性、是否满足格式（JSON/结构）、是否幻觉、是否安全合规、是否切题。第三层 Agent 行为层：验证 Agent 的决策——任务规划是否正确、是否选择了正确的工具、多步编排是否符合预期、状态流转是否正确、是否卡死或循环。第四层工具调用层：验证工具调用本身——参数是否拼装正确、返回是否被正确解析、工具异常（超时/错误）是否被捕获处理、副作用是否按预期。实际测试要分层设计用例：Prompt 层用提示词回归集，输出层用语义/结构断言，行为层用 Harness 对 Agent 的决策做步骤级断言，工具层用 mock 工具验证参数与返回。分层能精确定位"是提示词问题、模型问题还是工程问题"。

得分点是"四层分层的职责边界"与"分层定位问题"。能讲清每层各自测什么、用什么方式测，是这道题的核心，体现系统化测试思维。

• 对抗性问题集构造：诱导编造、无信息问题、矛盾事实
• 引用溯源断言：验证输出引用是否真实存在且内容匹配
• 人工抽检：高风险场景兜底

测试 LLM 幻觉需把自动化与人工结合。对抗性问题集构造：包含"诱导编造"问题（如"文档中未提及的信息请回答"）、无信息问题（训练未覆盖的冷门知识）、事实性矛盾问题（检测是否被误导）、以及带陷阱的引用问题。引用溯源断言：要求模型输出带引用，自动化验证每个引用是否真实存在于给定上下文、引用内容是否真的支持输出断言（防止"引用存在但内容无关"的伪溯源），此方法在 RAG 场景尤其有效。人工抽检：对高风险回答（医疗、法律、金融）与自动化难以判定的开放问题，保留人工抽检，核对事实准确性。三者结合的分层策略：全量跑自动化（对抗问题集 + 引用溯源断言）快速发现明显幻觉，对未通过或高风险样本人工抽检复核，形成"自动化抓主要、人工兜底"的闭环。同时用置信度/忠实度指标（如 NLI 判断输出是否被上下文蕴含）辅助自动化。

得分点是"对抗问题集 + 引用溯源 + 人工抽检三者的分工与结合"。能讲出"伪溯源"（引用存在但内容无关）这一细节，说明深刻理解幻觉检测难点。

• Harness 的组成：可控环境、模拟工具、确定性
• 模拟工具（Mock Tools）：可控返回、可注入错误
• 录制回放：记录真实调用，回放复现

Agent 测试需要 Harness 提供可控、确定性的执行环境。模拟工具（Mock/Stub Tools）：把真实外部依赖（API、数据库、文件系统）替换为可控的模拟工具，可指定返回结果、注入超时/错误，从而验证 Agent 在特定工具行为下的决策。录制回放：把真实运行中 Agent 的工具调用序列与结果录制下来，作为回放数据，在测试中复现同一场景，保证可重复性。步骤级断言：对 Agent 的执行过程逐步骤验证——每一步调用了哪个工具、参数是否正确、顺序是否符合预期、是否按依赖就绪；步骤级断言能发现"规划顺序错误"等终态断言发现不了的问题。终态断言：验证 Agent 的最终结果（任务是否完成、返回是否符合要求、副作用是否如预期）。两者结合：步骤级保证"过程正确"，终态保证"结果正确"。Harness 还应支持注入故障（工具超时、返回错误）以测试异常路径，并记录完整执行轨迹便于断言与诊断。

得分点是"可控 Harness（模拟工具 + 录制回放）"与"步骤级 + 终态双断言"。能讲出"步骤级断言发现排序错误、终态断言验证结果"，是 Agent 测试的核心能力。

• 召回率（Recall@K）与命中率（Hit Rate）
• 排序质量（MRR、NDCG）
• 引用完整性：引用是否真实存在且对应正确内容

RAG 检索质量测试需要标注数据（每个 query 对应正确答案集合）。度量指标：召回率 Recall@K——Top-K 检索结果中是否包含正确答案的比例；命中率 Hit Rate@K——Top-K 是否命中至少一个正确答案；排序质量 MRR（正确答案排在最前位置的倒数均值）、NDCG（考虑排序位置的归一化增益，对 K 个位置加权）。引用完整性：验证最终回答引用的片段是否真实存在于检索到的文档中、引用内容是否确实支持对应断言（防止"引用存在但内容不相关"），这是检索与生成的衔接质量。测试集构建：收集代表性 query（覆盖不同类型的问题），标注正确答案与期望来源文档。检索质量测试应分别测"纯检索"（不依赖生成）与"检索+生成"的端到端效果，并分析检索失败类型（漏召回、召回错、排序差）以优化检索器。检索质量是 RAG 的上限，检索不佳则生成质量必然受限。

得分点是"Recall@K/HitRate/MRR/NDCG 的度量语义"与"引用完整性"这一得分类衔接点。能讲出引用"存在但内容不相关"的伪溯源问题，是加分项。

• 异常路径类型：工具超时、返回错误、多步失败、循环卡死
• 注入故障的测试方法（模拟工具制造异常）
• 验证 Agent 的容错与恢复行为

Agent 异常路径测试通过注入故障验证其容错能力。工具超时：让模拟工具延迟返回或超时，验证 Agent 是否超时处理（重试、降级、报错），且不会无限等待。返回错误：让工具返回错误码、异常或非法格式，验证 Agent 是否正确解析错误、给出合理反馈、不把错误当成功的继续推进。多步失败：构造中间步骤失败（如第 2 步工具失败），验证 Agent 的回退、重试或终止逻辑，确认不会产生错误的部分结果。循环卡死：设计会导致 Agent 反复调用同一工具或陷入循环的场景，验证是否有循环检测与终止机制（如最大迭代次数、调用次数上限、重复检测），并设置超时兜底。用例设计方法：用模拟工具按"故障注入表"逐项制造异常，在每个异常点上断言 Agent 的行为（重试次数、错误处理、最终状态、是否终止）。同时测试"故障后恢复"（工具恢复后 Agent 能否继续），以及异常情况下 Agent 是否可能产生错误副作用（如重复扣款）。异常路径是 Agent 生产化的关键，需覆盖全面。

得分点是"用模拟工具注入故障 + 验证容错/恢复 + 循环卡死检测"。能讲出"错误不冋继续推进、故障后恢复、异常副作用"这三个层面，体现深度。

• 安全威胁类型：越狱、提示注入、PII 泄漏、违规内容
• 对抗性测试集构建与持续回归
• 安全过滤器的有效性验证

LLM 输出安全测试针对四类威胁：越狱（Jailbreak）——绕过安全对齐的对抗性提示；提示注入（Prompt Injection）——把恶意指令混入输入或外部数据，诱导模型执行非预期操作；PII 泄漏——模型输出中泄露敏感信息（尤其在 RAG 场景语料中）；违规内容——生成仇恨、暴力、违法内容。自动化测试方法：构建对抗性测试集，包含经典的越狱模板、注入攻击样本（如系统提示劫持、间接注入）、PII 探测样本、违规内容样本，持续回归。验证点：模型本身是否拒绝诱导、是否遵循安全护栏、安全过滤器是否拦截违规输出、PII 是否被脱敏。持续回归应纳入 CI：每次模型/提示词/上下文策略变更都跑安全回归集，任何安全指标劣化即阻断。由于对抗手段不断演进，测试集需持续更新（吸收新攻击样本与最新越狱变体），并辅以人工红队（Red Team）探索新攻击面。安全测试的难点是"对抗性逃逸"——普通违规样本被拦截，但变体可绕过，因此需持续对抗升级。

得分点是"四类威胁的区分 + 对抗测试集 + 持续回归门禁 + 对抗升级"。能讲出"过滤器对普通样本有效但变体可逃逸，需持续对抗升级"，体现安全测试的进攻性思维。

• LLM-as-Judge 原理：用另一个 LLM 打分/比对
• 大规模评测的流程与成本控制
• Judge 可靠性验证：与人工标注一致性、偏差

LLM-as-Judge 用另一个大模型对被测输出进行打分或比对，适合大规模评测（人工不可行）。流程：定义评分标准（rubric）、构造评测集、让 Judge 对每个样本打分、汇总指标。大规模评测的关键是成本控制（可采样、分组、用便宜模型）与稳定性（固定 seed/温度）。Judge 自身可靠性必须验证，否则评测结果不可信。验证方法：把 Judge 打分与人工标注（gold standard）对比，计算一致性（如 Cohen's Kappa、Spearman 相关）；检查 Judge 的偏差——位置偏差（两个答案顺序影响评分）、长度偏差（偏爱更长/更详细的答案）、自我偏好（Judge 偏爱与自己同源模型的输出）、格式偏差。规避偏差的手段：对称交换顺序多次评测取平均、计算时对长度做归一化、用打分表（rubric）约束、多个 Judge 取一致、关键样本人工复核。Judge 可靠性应作为评测基线定期评估，任何 Judge 或评测集变更都需重新校验。

得分点是"验证 Judge 与人工一致性 + 识别位置/长度/自我偏好偏差"。能讲出"Judge 也有偏差，需验证与规避"，是 LLM 评测的进阶认知。

• 并发与竞态问题：多工具并行调用、结果覆盖、超时竞争
• 竞态测试用例：交错执行、超时与正常返回竞争
• 状态一致性验证

Agent 可能并行调用多个工具，产生并发与竞态问题。测试点：多工具并行调用——验证并行调用是否按预期发起、结果是否正确汇合、共享状态是否被并发修改导致不一致；超时竞争——一个工具超时返回、另一个正常返回，验证 Agent 如何处理"两个结果都到"或"先到先得"的竞争，是否会采用过期/错误结果；结果覆盖——多个异步结果写同一状态时，验证后回来的是否会错误覆盖先到的正确结果（last-write-wins 可能导致错误）。用例设计：用可控的模拟工具制造"延迟不同、返回顺序不同"的组合，验证 Agent 在交错调度下的行为一致性；构造"部分成功部分失败"的并行组，验证 Agent 是否只采用成功结果并正确报告失败；并发控制——验证对同一资源（如库存、余额）的并发操作是否有锁/幂等/去重机制，防止重复扣减。竞态测试常具随机性，需多次运行并用确定性调度（如固定 sleep）复现。并发正确性验证的核心是"无论完成顺序如何，最终状态一致且无副作用错误"。

得分点是"识别结果覆盖/超时竞争/状态一致三类竞态 + 用可控模拟工具制造交错调度"。能讲出幂等性与部分成功处理，体现对并发 Agent 的深刻理解。

• RAGAS 的核心指标：忠实度（Faithfulness）、答案相关性（Answer Relevance）、上下文相关性（Context Relevance）
• 各指标的度量原理
• 落地流程与局限性

RAGAS 是开源 RAG 评估框架，核心指标：忠实度（Faithfulness）——回答中的每个断言是否可从检索到的上下文中得到支持，衡量"有没有编造"；答案相关性（Answer Relevance）——回答是否切题、回答了用户问题，衡量"有没有答非所问"；上下文相关性（Context Relevance）——检索到的上下文与问题是否相关，衡量"检索质量"（与检索层指标互补）。RAGAS 通常用 LLM-as-Judge 自动生成测评（如把回答拆成断言语义决策是否被上下文支持），适用于大规模自动化评测。落地流程：准备问题集与检索上下文、运行 RAG、用 RAGAS 计算各指标、对比不同配置（检索器、chunk 大小、模型）的指标。局限性：依赖 LLM 判定准确率、对长答案与多断言可能漏判、指标间可能不完全独立，因此需与人工抽检结合，并验证 LLM 判定自身可靠。落地时把 RAGAS 指标作为回归门禁，同时保留人工核对关键样本。

得分点是"三个指标各自的语义（忠实=编造、答案相关=切题、上下文相关=检索）"与"落地+局限"。能讲出 RAGAS 依赖 LLM 判定、需与人工结合，是加分项。

• 规划测试：任务分解、步骤排序、依赖关系
• 验证规划正确性：期望规划 vs 实际规划
• 规划错误与执行错误的归因区分

Agent 任务规划测试验证其"想对"（规划）而非仅"做对"（执行）。规划正确性：给定任务，期望 Agent 分解为合理的子步骤、按正确顺序排列、正确处理依赖（如"先查库存再下单"）。验证方法：用 Harness 记录 Agent 的规划/工具调用序列，与期望的"步骤-顺序-依赖"对比。步骤级断言检查每一步是否按顺序、依赖是否前置、是否有冗余或缺失步骤。归因区分是难点：规划错误（Agent 一开始就计划错了，如先下单后查库存）与执行错误（Agent 计划正确但执行时工具调用参数错误/失败）是两类不同问题，修复方式不同。区分方法：步骤级断言定位"错在哪个步骤"，结合"规划轨迹"（Agent 的决策）与"执行结果"（工具返回值）对比——若规划合理但执行失败，是执行错误；若规划本身不合理，是规划错误。测试时应分别记录"规划日志"与"工具调用日志"，便于归因。也需测试规划的回退能力（某步失败后能否重新规划）。

得分点是"区分规划错误与执行错误"的归因方法，以及"步骤级断言验证顺序与依赖"。能讲出用规划日志与执行日志分离诊断，是加分项。

• 流式输出完整性：token 是否完整、无丢失/重复
• 中断恢复：流中断后客户端行为
• 并发请求：多流是否互不干扰

LLM 流式输出（SSE/WebSocket 逐 token 推送）测试关注：完整性——流式输出最终拼接的完整内容是否与"单次完整返回"一致，token 无丢失、无重复、无乱序；可用"流式拼接结果 vs 非流式结果"比对验证。中断恢复——流传输中断（网络断开、服务端超时）时，客户端能否检测中断、重试或提示，不产生半截错误内容；测试中断时机（不同 token 处）验证恢复行为。并发请求——多个用户同时流式请求，验证各流互不干扰、无串流（A 用户收到 B 的内容）、无资源耗尽。打字机效果断言——验证输出是"逐步递增"的（每次推送内容前缀与之前一致、不覆盖、不倒退），可通过断言"每次收到的内容长度单调递增且是前一次的前缀"来验证；同时验证最终完整内容正确。测试方法：用专门的事件流测试工具捕获 SSE 事件序列，断言事件顺序、内容前缀一致性、最终完整性，并注入中断/延迟模拟异常。流式测试还需关注心跳与超时机制、背压处理。

得分点是"完整性（拼接 vs 非流式）、中断恢复、并发隔离、打字机效果的前缀递增断言"。能给出"内容长度递增且是前缀"的具体断言方式，是加分项。

• "测试测试者"思想：用变异测试验证生成用例能否发现缺陷
• 变异测试原理与变异杀死率
• 评估生成用例的缺陷检测能力

"测试测试者"指用变异测试来衡量 AI 生成的测试用例是否真的有效。原理：对被测代码注入变异体（改变运算符、删除边界、反转条件、改变返回值等），得到一个"与原始代码行为不同"的版本；运行 AI 生成的测试，若测试能"杀死"变异（检测出行为变化、测试失败），说明该测试对该类缺陷敏感；若测试无法杀死变异（变异后测试仍通过），说明测试断言弱、覆盖不到该行为。用变异杀死率（被杀变异数/总变异数）作为用例有效性的量化指标。评估时：对同一被测代码生成多组用例，计算每组变异杀死率，淘汰低杀死率的用例；分析"杀不死的变异类型"（如边界条件、异常分支），针对性补强。变异测试成本较高（每种变异都要重跑测试），可用变异采样与快速变异工具优化。该评估把"AI 生成测试的有效性"从主观判断变为可量化指标，并反馈给生成策略（如提示模型多覆盖边界断言）。变异测试是高价值用例的"质检员"。

得分点是"用变异杀死率量化 AI 测试有效性"与"分析杀不死的变异类型定向补强"。能讲出变异测试成本与优化，说明理解其落地。

• 升级回归测试：基准集上跑新旧对比
• 灰度验证：小流量放量、指标对比、自动回滚
• 差分评测消除随机性

模型/Prompt/上下文策略升级是高风险的，需回归测试与灰度验证。回归测试：在保存的基准集上对"新配置"与"旧配置"分别评测，对比语义、格式、安全、性能指标，用差分评测（同一输入、只变配置）减少随机性；任何关键指标劣化（如安全、忠实度、格式成功率）即阻断。灰度验证：先在线上小流量（shadow 或 1%-5%）放量，对比新旧配置的业务指标（任务成功率、用户反馈、延迟、成本），并用统计显著性判断差异是否真实；灰度期间监控异常（响应变差、安全事件、P99 延迟超限），达到自动回滚阈值即回滚。回滚预案需提前准备（旧配置可快速恢复）。升级流程应为"离线回归 → 灰度放量 → 全量"，每级有明确的门禁与回滚条件。同时把升级前后的评测报告与样本留存，便于事后归因。灰度验证的关键是"指标可观测 + 自动回滚阈值"。

得分点是"离线回归 + 灰度放量 + 自动回滚门槛"的升级流程，以及"差分评测降低随机性"。能讲出灰度阶段的指标对比与自动回滚，体现工程化。

• 端到端任务成功率：用户任务最终完成的比例
• 用户反馈率：好评/差评、纠错、满意度
• 安全拦截率：违规/注入被拦截、PII 泄漏率

AI 应用质量指标从业务、体验、安全三个维度度量。端到端任务成功率：用户发起的任务（查询、下单、生成）最终成功完成的比例，衡量"能不能用"；需区分"工具调用成功"与"业务结果成功"（工具成功但答案错误不算真正成功）。用户反馈率：用户对结果的反馈（好评/差评、点踩、纠错、追问）比例，衡量"可不可用"；如"答案被修改率"（用户修正 AI 输出的比例）能反映准确性。安全拦截率：安全过滤器的拦截效果——违规内容被拦截的比例、提示注入被拒绝的比例、PII 泄漏率、越狱成功率；衡量"安不安全"。落地时指标应分层监控：数据层（输入/输出异常）、模型层（任务成功率、格式成功率）、体验层（反馈率、修改率）、安全层（拦截率、泄漏率）。指标需设置基线并持续监控，异常时告警。还要区分"线上真实指标"与"离线评测指标"——线上指标反映真实使用，离线指标用于回归对比。质量度量应闭环到优化（哪类失败率最高就优先优化哪类）。

得分点是"任务成功率/反馈率/安全拦截率的分层度量"与"区分工具成功与业务成功"。能讲出用户修改率等体验指标，体现真实业务视角。

• 工具调用正确性：参数拼装、返回解析
• 多步流程编排：依赖、回退、顺序
• 安全边界：注入、越权

Agent 测试三大维度逐层验证。第一层工具调用正确性：验证 Agent 调用工具时参数是否拼装正确（类型、字段、格式、是否传错参数）、返回结果是否被正确解析（schema、错误码、空值），以及工具返回的异常是否被处理。用例：构造边界参数、错误返回，断言调用参数与解析结果。第二层多步流程编排：验证多步任务的依赖（先决条件是否满足再执行下步）、顺序、回退（某步失败后重新规划或回滚）、以及是否循环。用例：用模拟工具验证步骤顺序、依赖前置、失败回退。第三层安全边界：验证 Agent 是否被提示注入诱导执行越权操作（如注入内容要求调用管理员工具、读取敏感数据）、工具调用是否越权（参数被篡改访问未授权资源）、是否遵循权限边界。用例：注入恶意指令、测试越权访问、验证权限校验。三层需分别建立测试集与断言：工具层用 mock 工具断言参数/解析，编排层用步骤级断言验证顺序与回退，安全层用对抗性输入验证权限与注入防护。三层覆盖"调得对、排得对、不越界"。

得分点是"三层维度的职责划分与各自验证方法"及"调得对、排得对、不越界"的总结。能逐层给出具体用例类型，体现系统性。

• token 成本与输入/输出长度、模型档位的关系
• 缓存策略（Prompt 缓存、语义缓存）对成本与延迟的影响
• 延迟与成本的权衡

LLM 应用的 token 成本与延迟直接影响线上成本与体验，需专项测试。输入输出长度：token 成本通常按输入+输出 token 计费，输入长度（system prompt、上下文、RAG 内容）与输出长度（回答篇幅）直接决定成本；测试应测量各场景的 token 消耗，识别"上下文膨胀"（RAG 内容过多导致成本飙升）与"输出过长"（提示词未约束篇幅）。模型档位：不同模型（旗舰 vs 轻量）价格与质量不同，测试应验证"用轻量模型在质量达标前提下能否降本"，衡量性价比。缓存策略：Prompt 缓存（相同前缀复用）与语义缓存（相同/相似问题命中缓存）能显著降低 token 成本与延迟；测试应验证缓存命中率、缓存收益、缓存失效时的正确性（不返回过期错误结果）。延迟测试：测量各档位模型的 P50/P99 延迟、不同输入长度下的延迟曲线，并评估缓存对延迟的改善。成本测试应建立"每请求平均成本"与"每完成一个任务成本"指标，结合压测评估容量与成本上限，并做成本-延迟-质量三者权衡。可持续监控 token 成本，设置预算告警。

得分点是"token 成本与长度/档位/缓存的关系"与"成本-延迟-质量权衡"。能讲出上下文膨胀与缓存命中率，体现对成本优化的理解。

• 上下文窗口超限：长对话溢出导致截断或报错
• 记忆裁剪：摘要、丢弃、窗口滑动的策略
• 关键信息丢失验证：裁剪后是否丢失关键约束

Agent 长对话会累积上下文，可能超出模型上下文窗口，需记忆裁剪策略，测试需验证其正确性。上下文窗口超限：验证超长对话时系统是否优雅处理——是截断（保留头部还是尾部）、报错、还是自动压缩，不产生崩溃或错误输出。记忆裁剪策略：常见有摘要（把早期对话压缩成摘要）、窗口滑动（只保留最近 N 轮）、关键信息抽取（保留实体/约束）。测试：验证裁剪后对话仍可继续、语义不严重断裂。关键信息丢失是核心风险——裁剪可能丢失用户早期给出的关键约束（如"必须用人民币结算"、"不要引用某来源"），导致后续行为错误；测试应在长对话中注入关键约束，验证经过多轮与裁剪后约束是否仍生效。恢复策略：验证能否从摘要/备份中恢复被裁剪的上下文（如用户要求时重新展开），以及裁剪后是否需要重新确认关键信息。测试方法：构造超长对话（多层轮次、大量上下文），验证溢出处理、裁剪后关键信息保留率、恢复策略可用性，并监控"上下文使用率"告警。配合一致性测试（裁剪前后关键行为是否一致）。

得分点是"识别关键信息丢失这一核心风险"与"验证恢复策略"。能讲出在长对话中注入约束并验证裁剪后仍生效，是加分项。

• JSON 输出稳定性：能否稳定输出合法 JSON
• 语言混用：多语言输出混杂、术语不一致
• 特殊字符：转义、Unicode、换行、引号

LLM 输出的格式与语言稳定性是集成关键，因为下游依赖结构解析。JSON 输出稳定性：LLM 可能输出非法 JSON（多逗号、注释、markdown 代码块包裹、字段缺失），测试应验证在各种输入下能否稳定输出合法且符合 schema 的 JSON；常用手段是使用 JSON mode / 结构化输出约束，并做"解析失败重试"与"兜底解析"。语言混用：多语言场景下模型可能混淆语言（中文回答混入英文、术语翻译不一致），测试应验证输出语言与用户输入语言一致、术语翻译稳定。特殊字符：JSON 中的引号、换行、反斜杠、Unicode、emoji 可能破坏结构，测试应构造含特殊字符的输入（如用户文本含引号换行），验证输出被正确转义、可解析、不丢失。回归保障：建立"格式稳定性回归集"，覆盖各种输入，断言输出可解析、schema 正确、语言正确、无非法字符；每次 Prompt/模型变更都跑该回归集，防止格式退化。结构化输出应优先使用框架提供的 schema 约束，降低格式不稳定风险。

得分点是"JSON 稳定性 + 语言混用 + 特殊字符转义"三个维度与"回归集保障"。能讲出 JSON mode 约束与重试兜底，体现实际集成的痛点。

• 跨轮指代消解：后续轮次引用前文实体
• 上下文累积：状态在轮次间正确保持
• 状态重置：新会话/重置时状态正确清空

Agent 多轮对话依赖状态保持。跨轮指代消解：用户后轮用"它""那个""刚才说的"指代前文实体，测试应验证 Agent 能正确解析指代并应用于当前操作（如先问"查一下 A 的数据"，再问"它的趋势"，Agent 应知道"它"指 A）。上下文累积：多轮中累积的约束、偏好、已确认信息应在后续轮次正确生效（如前轮说"用美元"，后轮操作应沿用美元）。状态重置：新会话或用户重置时，旧状态应被正确清空，不残留到新会话（避免串话）；测试验证状态边界的隔离。长会话状态漂移：随轮次增多，早期信息可能被弱化或丢失（与上下文裁剪相关），导致行为漂移；检测方法：构造长会话，在早期注入关键约束，验证经过多轮后行为是否仍一致，用"关键约束跟踪"（在早期与后期分别触发相关操作，对比行为一致性）检测漂移。用例设计：跨轮指代用例（连续多轮引用同一实体）、累积约束用例（多轮累积后验证全生效）、状态重置用例（新会话验证无残留）、长会话漂移用例（早期约束晚期验证）。还要验证状态在并发/中断场景下的保持。

得分点是"跨轮指代、状态累积、状态重置、长会话漂移"四类用例与"关键约束跟踪"检测漂移。能讲出状态隔离与并发保持，体现完整。