面试日记 第 3 天

今天上午，我刷到 Hugging Face 上一篇挺适合拿来讲面试的文章。

文章讲的是 MosaicLeaks。这个问题听起来有点绕，简单说就是：一个 Deep Research Agent 一边读公司内部文档，一边调用外部搜索工具查资料。它最后的回答可能没有直接泄密，但它发出去的一串搜索 query，拼在一起，反而能把内部信息暴露出来。

文中还给了一组挺刺眼的数据：普通 Deep Research Agent 的严格泄露率能到 34.0%，加了隐私感知训练以后可以降到 9.9%。这说明问题不只是“模型嘴严不严”，还包括 Agent 在行动过程中会不会把信息带出去。

我当时第一反应是，这不就是提示词没写好吗？在 System Prompt 里加一句“不要泄露敏感信息”，应该能挡住一部分。

结果下午面试时，面试官也提到了这篇文章。

他问我：“你觉得 Deep Research Agent 为什么会泄密？”

我说：“可能是提示词约束不够，应该加安全规则，告诉它不要把私有信息发出去。”

面试官停了一下，说：“如果它没有把私有信息写进最终答案，只是把内部线索拆进了十几次外部搜索里，你这个提示词还能拦住吗？”

我一下就卡住了。

这句话让我意识到，我把 AI 安全想得太像聊天机器人了。以前我总觉得只要最后输出别乱说，就算安全。但 Agent 真正危险的地方，往往发生在中间过程里：检索、工具调用、外部 API、搜索 query、日志、权限和审计。

面试官把原题抛了出来：

“什么是 AI 护栏（Guardrails）技术？它在生产环境中如何保障 AI 应用的安全？”

我现场能答出“输入过滤”“输出审核”“敏感词拦截”这些词，但讲得很散。尤其是问到 Agent 调工具、私有数据和外部搜索混在一起时，我明显没有形成完整方案。

面试结束后，我回去重新整理了一遍。下面是我的面试复盘。

回答重点

这题先抓一句话：AI 护栏就是在大模型应用里设置一系列安全检查和约束机制，让模型的输入和输出都在可控范围内。

面试里可以用一个很直观的类比：高速公路两边的护栏，不会限制车正常行驶，但能防止车冲出路面。AI 护栏也是一样，它不该让模型什么都不敢答，重点是在遇到异常输入、恶意指令、敏感信息、违规输出时，把风险挡住。

护栏通常分成两道关卡：输入护栏和输出护栏。

输入护栏在请求到达模型之前生效。它要做的事情包括检测并拦截 Prompt 注入攻击，过滤有害内容，验证输入是否符合预期格式，并且对身份证号、手机号、客户信息这类敏感数据做脱敏处理。

输出护栏在模型生成回答之后生效。它会检查输出是否包含有害或不当内容，验证输出格式是否符合预期，比如 JSON 是否合法；还要检测有没有泄露 System Prompt 或敏感信息。遇到不合规内容时，可以改写、拒答，或者直接拦截。

所以，生产环境里的护栏是 AI 应用安全上线的必备组件。没有护栏的 AI 应用，就像没有刹车的汽车，平时看起来跑得挺顺，一旦遇到异常输入、越权请求或者恶意攻击，就很容易失控。

MosaicLeaks 这类问题也能放进这个框架里理解。它没有在最终答案里直接泄密，风险出在 Agent 调用外部搜索前：输入侧和工具调用侧缺少检查，导致内部线索被带进了 query。这个例子正好说明，护栏不能只盯着最终输出。

扩展知识

如果面试官继续追问，第一层通常会问护栏怎么实现。

常见路线有三种。

第一种是基于规则的护栏。比如正则表达式、关键词黑名单、格式校验。这类方案速度很快，单次检查通常在 10 毫秒以内，可控性也强。但缺点也明显，攻击者可以用同义词替换、编码混淆、拆字等方式绕过规则，而且规则列表维护起来很累。

第二种是基于专用模型的护栏。比如 OpenAI 的 Moderation API、Meta 的 Llama Guard 系列，本质上都是让一个专门训练过的分类模型判断内容是否合规。它比规则更能理解语义，能识别一些规则覆盖不到的变体。代价是会增加 20 到 100 毫秒左右的延迟，也会有误判。

第三种是基于 LLM 的护栏。比如让另一个模型审核主模型输出，判断这段回答是否包含医疗建议、是否附带免责声明、是否泄露了敏感信息。它最灵活，适合复杂合规逻辑，但成本也最高，因为每次审核都要多调用一次模型。

实际生产里，这三种方式通常组合使用。规则层先挡住明显违规内容，专用模型处理需要语义理解的场景，LLM 审核只放在高风险场景里。

主流护栏框架也可以顺带讲几个。

NVIDIA NeMo Guardrails 用 Colang 2.0 定义对话流规则，可以做主题限制、事实核查和内容审核，适合需要精细控制对话流程的复杂 Agent 场景。

Guardrails AI 更偏输出校验，可以用类似 Pydantic 的 Validator 约束输出结构，内置毒性检测、PII 识别、事实一致性等验证器。它适合对输出格式要求很严的场景，比如必须输出合法 JSON 或特定 schema。

LLM Guard 是开源的生产级扫描工具，专注 PII 检测、毒性过滤、密钥泄露扫描，模型无关，也支持自部署。它适合需要快速上线一层安全防护的生产应用。

Meta 的 Llama Guard 4 是开源的多模态安全分类模型，基于 Llama 4 Scout 裁剪微调，原生支持文本和图像安全分类，也采用了更标准化的风险分类体系。需要本地化部署安全审核时，可以作为一个选项。

接着要讲性能权衡。

加护栏一定会增加延迟和成本。比较常见的做法是分级处理：所有请求先过轻量规则检查，几毫秒就能完成；被规则层标记为可疑的请求，再触发专用模型检查；高风险场景才启用 LLM 审核。

这样大部分正常请求不会明显变慢，异常请求会多走几层检查。

另一个关键指标是误拦率。护栏设得太紧，正常用户的合理请求会被拦下来；设得太松，恶意请求又能溜进去。所以生产环境要持续监控误拦率和漏放率，根据线上数据调整规则、阈值和白名单。

行业场景也会影响护栏规则。金融行业不能随便给具体投资建议，交易相关操作通常要人工审批。医疗行业不能直接给诊断结论，涉及用药信息要提示咨询医生，并标注信息来源。教育行业要避免直接代写作业，更适合引导学生思考。

所以面试里最后可以补一句：护栏没有一套通用方案能一招通吃，必须根据业务场景定制。

面试官追问

追问：护栏本身会不会成为系统瓶颈？高并发场景下你怎么保证护栏不拖慢整体响应？

回答：会。规则引擎一般不会成为瓶颈，几毫秒就能完成。主要延迟来自专用模型检测和 LLM 审核。高并发场景下可以做分级检查，正常请求只走轻量规则，可疑请求再进入模型检测；输出护栏可以做流式检测，模型每吐出一段就检测一段，不用等完整输出。护栏模型本身也要支持水平扩缩容，不能和主模型挤在同一个瓶颈上。

追问：如果护栏误拦了正常用户的请求，你怎么发现和处理？

回答：要建立反馈闭环。每次拦截都要记录日志，包括原始输入、触发规则、拦截原因和最终处理方式。产品侧可以提供申诉入口，运营侧定期抽样审查拦截日志，统计误拦率。发现某类误拦偏高，就调整对应规则阈值，补充白名单或改模型分类策略。这个过程要形成“监控、发现、调整、验证”的循环。

追问：你觉得护栏应该放在客户端还是服务端？

回答：安全相关的护栏必须放在服务端。客户端校验可以提升体验，比如提前提示格式错误，但它很容易被绕过。攻击者可以直接调用 API，跳过前端逻辑。生产环境里，护栏应该作为 API Gateway 的一部分，或者作为独立中间件服务部署，所有到达模型的请求都必须经过这道关卡。

追问：MosaicLeaks 这种 query 泄露，应该归到输入护栏还是输出护栏？

回答：更接近输入护栏的扩展场景，也可以理解成工具调用前的输入检查。外部搜索 query 是发给外部服务的输入，如果里面夹带了内部文档信息，就已经发生风险了。传统“输入护栏 / 输出护栏”讲的是用户到模型、模型到用户；Agent 系统里还要把工具调用参数也纳入护栏范围。

所以这题最后可以这样收。

AI 护栏是在大模型应用里设置的一系列安全检查和约束机制。基础上分输入护栏和输出护栏，生产里还要结合规则、专用模型和 LLM 审核，并持续监控误拦率、漏放率和性能成本。

这题我后来重新整理了一遍，发现完整答案其实要讲输入护栏、输出护栏、三种实现路线、主流框架、性能权衡和行业合规。

篇幅有限，更多 AI 安全和 Agent 工程相关面试题，可以进入面试鸭进行查阅。