AI 安全工具经常被放进同一个清单：扫描器、提示词过滤器、红队框架、评测集和运行时护栏看起来都在“防风险”，实际工作位置完全不同。寻找开源替代方案之前，必须先说清楚想替代的是哪一种能力。
一个系统可能在模型层生成不当内容，在检索层读取恶意文档，在工具层执行越权操作，也可能因为日志缺失而无法追溯。单一过滤器只能看到其中一部分。
## 扫描器负责发现已知失败模式
garak 会用大量探针向模型或应用发送测试提示，再用检测器判断输出是否暴露特定问题。它适合快速建立红队基线，并保留触发失败的提示和响应。
PyRIT 更强调可扩展的攻击编排，既支持自动扫描，也支持人工参与。测试者可以组合目标、转换、评分器和攻击策略，观察多轮系统如何被诱导偏离预期。
扫描结果不是安全证书。模型输出具有随机性，工具版本和探针库也在变化；一次通过只说明在某组配置下没有触发已测试问题。更有价值的是把失败样本加入持续回归集。
探针还应区分模型和应用。直接测试基础模型，可以理解模型倾向；测试带检索与工具的完整系统，才能看到恶意文档、权限和多轮状态带来的风险。两种结果不能相互替代。
## 护栏负责运行时约束
NeMo Guardrails 等框架可以在输入、对话、检索和输出周围加入可编程规则，例如限制话题、检查事实来源或控制工具调用。OpenAI Guardrails 也把输入检查、输出检查和代理行为约束拆成不同组件。
护栏的优点是能在请求发生时阻止或改写行为，缺点是可能增加延迟、误拦正常请求，或被新的表达方式绕过。规则越多并不一定越安全，冲突规则还可能让系统行为难以解释。
关键动作不应只依赖语言模型判断。转账、删除、发送外部消息等操作需要结构化权限、参数校验、限额和人工确认。护栏是应用控制的一层，不是权限系统的替代品。
护栏本身也要接受对抗测试。输入先被改写、翻译或编码后，检测效果可能下降；多个护栏串联时，还要测它们对上下文和延迟的影响。误拦会促使用户寻找绕过方式，从而制造新的风险路径。
## 评测连接开发与上线
安全评测应从真实使用场景构建。客服系统要测试隐私信息、越权查询和错误承诺；代码代理要测试恶意仓库内容、命令范围和密钥暴露。通用攻击集提供起点，本地失败决定最终覆盖。
每个案例应包含输入、上下文、可用工具、期望行为和可接受替代。只对最终文字打分，会漏掉代理已经调用了错误工具但随后给出正常回答的情况。
上线后还要监测拒绝率、误拦率、异常工具调用、人工升级和新型失败。数据分布改变时，旧评测集会逐渐失效。
## 开源方案的优势与责任
开源工具允许团队检查实现、添加本地探针并在私有环境运行，也方便复现实验。但版本、模型接口和默认评分器都需要固定；公开攻击集还可能被模型训练数据吸收，导致测试分数虚高。
工具本身也需要隔离。红队框架会生成攻击性内容并连接被测系统，测试账户、网络权限和日志存储都应与生产环境分开。不要把自动攻击直接指向未经授权的外部服务。
开源依赖还需要版本与供应链管理。锁定提交或发布版本，审查新增插件的网络和文件权限，并在隔离环境运行不熟悉的探针。能够阅读源代码不代表所有使用者已经阅读过它。
一套务实组合可以是：用风险清单定义场景，用 garak 做宽扫描，用 PyRIT 深挖多轮和代理路径，用护栏处理运行时输入输出，再用结构化权限保护高风险动作。最后把全部失败纳入版本化评测。
开源替代方案真正替代的是昂贵且封闭的部分工具能力，不会替代团队对系统边界的理解。安全来自多层控制和持续证据，而不是安装某个仓库后出现的一枚绿色标记。
## 参考资料