小鹏 AI 安全一面：Agent 的 Guardrail、对抗性测试与敏感信息处理

《面试题目》

1. 说一下你对这个岗位的理解，以及有什么问题？
2. 自我介绍
3. 你实习做的 Agent 有没有针对可靠性输出做过对抗性测试，还有构造一些越界或者边界数据集？
4. 讲一下你的 Agent 的 Guardrail 怎么做的？
5. 你是怎么保证校验类规则可靠性的？
6. 你的业务准确率中剩下的错误部分主要集中在哪些方面？
7. 针对输入到 Agent 中的敏感类信息你是怎么处理的？
8. 讲一下你对开发和安全的理解，你更倾向于什么？

《参考解析》

对抗性测试必须有数据集和方法论，不能只答「测过」。 面试官问的是「有没有构造越界或边界数据集」，所以要说清数据是怎么来的、覆盖了哪些维度。可用的分类：提示注入与越狱（直接注入、间接注入——藏在被检索文档或工具返回结果里的指令）、越界请求（超出授权范围的数据访问、越权操作）、边界输入（超长文本、空输入、多语言混杂、编码混淆、Unicode 同形字）、以及业务维度上的高危样本（涉及资金、权限、隐私的操作）。生成方式包括：对历史线上 case 做变异、用模型批量生成对抗样本再人工筛选、以及从公开红队数据集适配业务。评测要能报出「多少个用例、发现了多少问题、修复后回归通过率」，否则等于没做。

Guardrail 的分层实现。 一个完整的护栏不是一层，而是几层的组合，回答时按「事前—事中—事后」讲更清楚：输入侧做敏感信息识别与脱敏、注入检测、以及范围校验（只允许模型处理它有权处理的数据）；决策侧用工具白名单/参数 schema 约束模型能做什么，参数在服务端二次校验（模型生成的参数是不可信输入），高风险操作要求额外确认或走独立审批；输出侧做内容过滤、事实性与引用校验、以及泄露检测（即使模型能看见敏感内容，也不代表它有权输出）。此外还要有运行时的观测与熔断：给工具调用记审计（谁调的、参数摘要、耗时、结果），对异常调用模式做限流和熔断；不可恢复的错误直接终止并转人工，而不是让 Agent 自己重试。

校验类规则的可靠性怎么保证。 核心思路是「规则本身也要被测试」。可用的手段：一是给规则定义明确的输入输出契约，并用单元测试覆盖正例、反例和边界，把规则当代码而不是当配置；二是处理规则之间的冲突与优先级（两条规则同时命中时谁生效要写死），并检测互斥规则；三是设逃生舱与降级——规则误判时要有可识别的信号（比如误杀率指标）和人工覆盖通道；四是版本化与灰度，规则变更要有回归集验证，不能上线即全量；五是定期用线上样本反哺评测集，因为攻击手法和业务边界都在变。面试官问「剩下的错误集中在哪些方面」时，建议按错误类型分类回答并给占比（事实错误/意图识别错误/工具调用错误/权限违规/格式不合规/拒答不当/上下文遗忘），这比笼统说「还有提升空间」有说服力得多。

敏感信息处理的实际做法。 输入侧做检测和最小化——不是「看到敏感信息就整段拒绝」，而是识别类型（手机号、身份证、内部地址、未授权文档内容）后做脱敏或替换，只把任务必需的部分交给模型；同时要在全链路上考虑：日志、Trace、缓存、评测报告都可能泄漏，敏感内容即使没出现在最终答案里，被写进日志同样是事故。权限上要验证不同角色、不同租户下的输出差异，并防止通过错误提示、统计结果或多轮查询间接推断出个体信息（这类间接泄漏最容易被忽略）。落地上还要注意数据留存策略和访问审计。

「开发还是安全二选一」怎么答。 这是动机题，关键是给出一致的逻辑而不是讨好式的答案。比较稳的说法是：你更享受做开发，但做的是安全方向的开发——因为把安全能力做成可复用的机制（护栏框架、评测流水线、检测规则引擎）比单点应急更有价值；再举一个你为此写过的具体东西。纯说「我热爱安全」而举不出亲手做过的事，反而容易被追问穿。