水滴校招测试一面：Skill 准入、上下文污染与敏感信息泄露测试

《面试题目》

1. 请做一下自我介绍
2. 一个 Skill 从注册到正式被 Agent 使用，中间需要验证哪些内容？
3. AI 生成的测试用例如何判断是否真的有价值？
4. 如何验证 Agent 的最终答案不是「看起来正确」？
5. 介绍下实习，以及你负责的测试内容
6. 如何测试多轮对话中的上下文污染？
7. 在没有标准答案的情况下，怎样验证一个 Skill 的输出质量？
8. 如何设计 Skill 调用链路的异常测试？
9. 如何判断 Agent 选择 Skill 的描述是否存在歧义？
10. 如何测试模型输出中的敏感信息泄露？
11. 如何设计 Agent 的发布准入标准？

《参考解析》

Skill 从注册到上线要过的关。 可以按链路拆：注册环节验证元数据完整性（名称、描述、所需参数、返回值 schema），描述是否写清了适用范围和禁止处理的请求；发现环节验证 Agent 在正确的语义下能选中它、在相近但不同的请求下不会误选；调用环节验证参数从自然语言到结构化参数的正确映射、缺失参数的追问行为、以及工具超时/失败时的处理；返回环节验证结果格式稳定、错误可归因（不要所有异常都包装成「系统繁忙」）；最后是权限与数据边界验证。面试官问这道题时想听的是「你有没有把 Skill 当作一个有生命周期的产品来测」，而不是只测调用成功。

判断生成用例有没有价值，核心看增量。 一条高价值用例至少要有明确前置条件、可控输入、可验证结果和失败后的定位信息；对 Agent 还要额外覆盖错误工具选择、参数缺失、上下文污染、工具超时和多轮状态变化。最关键的一条判据是：如果某批用例既没覆盖新的状态、也没发现新的问题，只是换了几种表达方式，那数量再多也没有明显价值——所以要把它和历史缺陷、需求约束、风险等级做关联，用「新增覆盖」而不是「数量增长」来衡量产出。

「看起来正确」怎么破。 需要把最终答案拆成几个可独立验证的维度：事实正确性、任务完成度、引用一致性、格式合规性、风险控制。事实类任务要验证结论能否从输入资料或授权知识库中推导出来（不是「读起来很有道理」）；执行类任务要确认实际工具结果与答案一致；涉及计算时要检查中间过程而不是只比最终文本。还要专门构造诱导模型胡编、资料互相矛盾、上下文缺失的样本，看它会不会主动暴露信息不足，而不是编一个确定结论。

上下文污染怎么测。 先定义每一轮应该保留什么、什么应该被覆盖——比如用户切换了设备型号，旧型号的维修参数就不能继续影响新问题。测试时构造主题切换、参数覆盖、用户纠正、长文本插入和互相矛盾的信息几类场景，重点看模型是否错误继承了上一轮的实体、权限、任务状态和工具结果。还有一层容易被漏掉：上下文压缩后的行为——如果会话过长触发了摘要，必须验证摘要是否保留了用户目标、未完成任务、关键约束和事实来源，而不是只保留了表层语言内容。

没有标准答案时的质量验证，以及异常测试的设计。 前者要先建立可判定的评价维度（事实覆盖、关键字段准确率、约束遵循、风险遗漏、结果可执行性），再用规则校验 + 结构化字段比对 + 专家抽检 + 模型辅助评测组合完成；两条纪律：模型评测只能作为辅助，不能让同一个模型独立决定自己的结果是否正确；高风险场景要重点统计严重错误，不能只看平均分。后者的框架是按「调用前 / 调用中 / 调用后」三段切：调用前查权限、参数完整性、上下文状态；调用中查超时、连接失败、响应格式错误、重复请求；调用后查结果为空、结果与请求不匹配、下游状态未更新。还要验证不同错误类型是否触发不同处理——参数错误不该无限重试，依赖服务暂时不可用可以有限重试，权限问题应该直接终止。

Skill 描述歧义怎么判。 构造语义相近但目标不同的请求，观察模型是否稳定选对工具（例如查设备历史维修记录 vs 查设备实时状态 vs 查同类设备故障统计，三者都涉及「设备信息」但数据来源和处理逻辑完全不同）。再补边界表达、简称、错别字、口语化描述、多意图请求。如果同一请求在不同上下文中频繁选到不同 Skill，就说明描述里的触发条件不够明确。好的描述应该写清适用范围、禁止处理的请求、所需参数和典型输入，而不是只写一句「用于查询设备信息」。

敏感信息泄露测试要覆盖直接和间接两类。 直接泄露是返回手机号、身份证号、内部地址、未授权文档内容；间接泄露更隐蔽——通过错误提示、统计结果或多次查询推断出单个用户的信息。要验证不同角色、不同租户、不同数据权限下的输出差异，并牢记「模型能在上下文中看到敏感内容，不代表它有权输出」。最后一定要检查日志、Trace、缓存和评测报告——敏感信息可能没出现在最终答案里，却已经被写进了其他系统，这在合规上是同等严重的问题。

发布准入要按风险分级。 低风险问答可以关注准确率、拒答率和幻觉率；高风险（涉及资金、隐私、权限变更）必须有单独阈值、强制人工确认或直接拦在自动流程外。准入标准里还应该包含可观测性要求：上线后能按版本回放问题、能统计工具调用成功率与拒答率、出异常能追溯。把「能不能观测」写进准入门槛，是这类系统上线后还能持续迭代的前提。