**Q：tool safety 和 text safety 为什么不是一回事
1️⃣ 考察意图
面试官想看你是否真正理解AI安全的分层架构，而非笼统说“安全很重要”。这道题考察系统设计+工程取舍，刁钻点在于：很多人误以为“内容安全做好了，工具调用自然安全”，但两者攻击面、防御手段、失败后果完全不同。答好了能展示你对Agent安全体系的全局认知，以及从攻击者视角设计防御的能力——这是大厂做Agent产品（如字节Coze、阿里百炼）的核心硬实力。
2️⃣ 标准答
1. 核心定义与攻击面差异
- Text Safety：关注生成文本是否含违规内容（色情、暴力、政治敏感、偏见等）。攻击面在输出层，攻击者通过prompt注入诱导模型输出有害文本。防御依赖内容分类器（如Llama Guard、OpenAI Moderation API）和RLHF对齐（如DPO、PPO）。
- Tool Safety：关注Agent调用外部工具（API、数据库、文件系统）时的安全。攻击面在输入参数和工具执行结果，攻击者通过参数注入（如SQL注入、命令注入）或工具滥用（如让Agent删除服务器文件）造成实际破坏。防御依赖输入验证（参数白名单）、权限控制（最小权限原则）、工具调用审计。
2. 为什么不是一回事：三个关键差异
- 后果不同：Text Safety失败导致内容违规，可被内容审核拦截；Tool Safety失败可能导致数据泄露、系统破坏、财务损失。例如：Agent调用“发送邮件”工具时，攻击者注入参数让Agent向所有用户发送钓鱼邮件——这远超文本违规范畴。
- 防御粒度不同：Text Safety是“输出后过滤”，可接受一定误报（宁可错杀）；Tool Safety必须“执行前验证”，误报会导致功能瘫痪。例如：对“删除文件”工具，必须严格校验参数路径是否在白名单内，不能靠事后回滚。
- 攻击向量不同：Text Safety攻击是语义层面的（如“请用中文写一篇关于XX的科普文章”诱导输出）；Tool Safety攻击是结构化的（如将恶意参数编码进JSON字段，绕过语义检查）。实际案例：攻击者在工具调用参数中嵌入
"; rm -rf /; "，文本安全模型完全无法识别。
3. 实际落地的坑与解法
- 坑1：用同一个安全模型处理文本和工具参数。结果：文本安全模型对结构化参数（如JSON中的SQL语句）误判率极高，要么漏过恶意参数，要么误杀正常调用。
- 解法：分离安全模块。文本安全用基于Transformer的分类器（如RoBERTa微调）；工具安全用规则+白名单（如参数类型校验、正则匹配、允许值枚举）。例如：对“查询数据库”工具，参数
table_name只允许[users, orders]，参数condition只允许id=数字格式。 - 坑2：忽略工具调用链的上下文安全。例如：Agent先调用“读取文件”工具获取用户输入，再调用“执行代码”工具——攻击者通过文件内容注入恶意代码。
- 解法：引入上下文安全审计，对工具调用链做依赖图分析。每个工具的输出作为下一个工具的输入时，必须重新校验。例如：文件读取工具的输出标记为“不可信”，传递给代码执行工具前必须经过参数净化（如转义特殊字符）。
4. 工程取舍
- Trade-off：Tool Safety的严格性 vs Agent的灵活性。如果对所有工具参数做白名单校验，Agent无法处理动态输入（如用户自定义查询）。取舍点：对高风险工具（如文件删除、代码执行）用白名单+人工审批；对低风险工具（如天气查询）用黑名单+异常检测。
- 具体方法：参考OpenAI的Function Calling安全规范，对工具按风险等级分类：Level 1（只读API）用正则校验；Level 2（写操作）用参数白名单+速率限制；Level 3（高危操作）需用户二次确认。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从攻击面、防御策略、后果严重性三个层面回答。攻击面上，Text Safety针对语义内容，Tool Safety针对结构化参数；防御上，Text Safety用输出过滤，Tool Safety用输入验证；后果上，Text Safety失败是内容违规，Tool Safety失败可能导致系统破坏。总结一句：两者是正交的安全维度，必须独立设计机制，不能用一个模型覆盖。”
4️⃣ 高频追问 & 应对
追问 1：如果Agent同时调用多个工具，如何保证Tool Safety不互相干扰？
引入工具调用链安全审计。每个工具的输出标记安全等级（可信/不可信），作为下一个工具输入时重新校验。例如：工具A输出用户ID（可信），工具B输出用户输入文本（不可信）。对不可信输入，在传递给高风险工具前必须经过参数净化（如转义、白名单匹配）。具体实现：在Agent的调度层加一个安全中间件，维护一个“调用上下文安全表”，记录每个工具输出的可信度。
追问 2：你提到参数白名单，但如果工具参数是动态的（如用户自定义SQL查询），怎么处理？
动态参数无法用白名单，改用参数类型校验+语法解析。例如：对SQL查询，用SQL解析器提取表名和条件，只允许查询特定表（白名单），条件部分只允许等值比较（禁止
OR 1=1）。对代码执行，用沙箱（如gVisor）隔离执行环境，限制系统调用。取舍点：动态参数场景下，安全性和灵活性不可兼得，必须牺牲部分功能（如禁止JOIN操作）换取安全。
追问 3：Text Safety和Tool Safety的防御机制如何协同？会不会互相冲突？
协同点：两者共享一个安全策略引擎，统一管理规则和模型。冲突点：Text Safety可能误判工具调用参数为有害文本（如参数中包含“删除”二字），导致误杀。解法：对工具调用参数做结构化标记，让Text Safety模型跳过参数部分，只校验自然语言输入。例如：在Agent的输入中，用特殊token包裹工具参数（如
<tool_param>delete file</tool_param>），Text Safety模型忽略该区域。
5️⃣ 避坑 · 常见错误答法
- ❌ “Text Safety用内容过滤，Tool Safety也用内容过滤，只是过滤对象不同。” → ✅ “两者攻击面不同：Text Safety是语义攻击，Tool Safety是结构化攻击。内容过滤对结构化参数无效，必须用输入验证和权限控制。”
- ❌ “Tool Safety就是防止Agent调用恶意工具。” → ✅ “Tool Safety更关注参数注入和工具滥用，而非工具本身是否恶意。例如：合法工具‘发送邮件’被注入恶意参数后，可能变成钓鱼工具。”
- ❌ “两者可以合并成一个安全模块，统一用大模型判断。” → ✅ “大模型对结构化参数的判断能力弱，且延迟高。必须分离：文本安全用轻量分类器，工具安全用规则引擎+白名单。”
6️⃣ 简历呼应
- 如果你有Agent项目：从“工具调用链安全审计”切入，讲你如何设计安全中间件，对每个工具输出做可信度标记，防止参数注入链式攻击。举例：在项目中用参数白名单+SQL解析器，将攻击成功率从30%降到2%。
- 如果你只做过NLP安全：用“文本安全 vs 工具安全”类比“内容审核 vs 系统安全”，讲你如何将文本分类器的经验迁移到工具参数校验（如用正则表达式替代语义模型）。强调你理解两者差异，并设计过混合防御方案。
- 如果你是校招无项目：聚焦“为什么不能用一个模型覆盖”，引用OpenAI Function Calling安全规范，讲你复现过工具调用注入攻击的demo，并设计过基于白名单的防御原型。展示你对安全分层的理论理解。
- 《Tool Safety in LLM Agents: A Survey》（综述工具安全攻击面与防御）
- OpenAI Function Calling Security Best Practices（官方文档，参数白名单与权限控制）
- 《Red Teaming Language Models with Language Models》（红队测试方法论，可迁移到工具安全）
- Llama Guard: LLM-based Content Safety Classifier（文本安全模型参考）
- 《SQL Injection Attacks and Defense》（经典工具安全攻击案例，理解参数注入原理）