如果你运营过 AI 中转站，大概率遇到过这种情况：服务本身没问题，额度和密钥也配置好了，但总有人拿着入口反复试探，发送攻击提示、诈骗话术、隐私探测，或者用各种方式绕过上游模型的安全限制。
请求经过的是你的账号、你的额度和你的出口 IP。上游模型偶尔拒答，解决不了谁在持续滥用，也无法告诉你哪些请求正在集中出现。只做关键词过滤，又很容易把安全研究、新闻、小说和真实攻击混在一起。
Sael 的作用，就是在客户端和 AI 服务之间增加一层可配置的文本安全审查。它先判断用户输入属于什么风险，再根据你设置的规则决定放行、拦截和记录。
Sael 适合解决什么问题
Sael 适合放在这些场景前面：
- 对外提供 OpenAI、Anthropic 等兼容接口的 AI 中转站；
- 给多个团队或多个客户共用的模型网关；
- 需要限制网络攻击、诈骗、隐私泄露、自伤等高风险请求的内部 AI 平台；
- 想知道哪些请求被拦截、来自哪里、影响了哪个模型的运营团队。
它不要求客户端重写调用逻辑。客户端把 API 地址改成 Sael 的进网地址，原有的请求格式和调用密钥可以继续使用。
一条请求会经历什么
可以把 Sael 的工作过程看成一条很短的路径：
客户端 → Sael → Jev 分类 → 场景规则 → 放行或拦截 → 上游 AI 服务
具体过程分成四步：
- 提取当前用户输入：Sael 识别常见的 Chat、Responses、Messages 和图片请求，只审查本轮用户提交的文本。
- 交给 Jev 判断风险：Jev 分别判断网络滥用、违法活动、暴力、隐私、欺诈、自伤、审查绕过等风险；色情和血腥内容还会返回程度等级。
- 套用场景规则：你可以按接口、模型、风险项和分数阈值配置不同场景，条件支持“满足任一”或“满足全部”。
- 执行处理动作：命中阻塞规则就返回兼容 API 格式的 403；命中记录规则则继续转发，同时把结果留在控制台里。
没有适用场景的请求不会调用 Jev，直接透传。审核成本会集中在需要关注的流量上。
Jev 分类为什么比关键词更适合做入口审查
关键词只能告诉你“某个词出现了”，不能判断这句话到底在做什么。
例如，“如何修复 SQL 注入”与“如何利用某网站的 SQL 注入”可能包含相似词汇，处理动作却完全不同。Sael 让 Jev 分别回答“是否在请求可执行的攻击帮助”“是否在请求防御或解释”，再由场景阈值决定是否拦截。
Sael 内置的审核项覆盖网络滥用、违法活动、暴力伤害、未成年人安全、仇恨与骚扰、隐私泄露、欺诈与欺骗、自伤风险、审查绕过、色情程度和血腥程度。前九项返回概率，后两项返回 0 到 3 的程度等级。概率 0.5 表示判断不确定，不代表风险程度为中等。
场景：把风险判断变成可执行规则
Sael 把每条规则称为一个“场景”。一个场景可以设置：
- 哪些接口生效；
- 哪些模型生效；
- 关注哪些风险项和阈值；
- 多个条件满足任一还是全部才算命中；
- 命中后阻塞，还是只记录并继续服务；
- 是否在重复违规后冻结当前会话。
场景配置
上图中的场景只对选定模型生效，网络滥用分数超过阈值后执行阻塞性审查。场景按顺序执行，排在前面的规则优先。保存前可以在“试算”里输入文本，先看它会命中哪些条件，再决定是否启用。
阻塞审核和记录审核
Sael 提供两种使用方式：
- 阻塞审核：等待 Jev 返回结果，命中后不把请求交给上游。适合网络攻击、诈骗、未成年人安全等明确需要拦截的场景。
- 记录审核：请求和审核同时进行，用户可以继续使用服务，运营者在后台看到命中结果。适合刚上线时观察误报，或者只想收集风险趋势的场景。
命中后冻结会话适合处理连续重试。它只针对具体调用者和会话生效，不会因为一个请求命中就把整个 API Key 或整个 IP 一起封掉。
总览：先看风险有没有集中出现
总览页面把请求量、命中与拦截、审核耗时和 Jev 异常放在同一组统计里，可以按时间、端点和模型观察风险变化。
截图使用仓库里的示例数据，数字用于展示页面结构，不代表某个线上实例的真实流量。
记录：定位一次具体的异常请求
记录页面会展示一次异常请求的端点、模型、来源 IP、会话、去敏后的文本预览、命中的风险分数和请求参数。正常请求只进入聚合统计，不会被保存成一条条完整聊天记录。
记录里的文本在保存前会做去敏，方便运营者定位问题，同时减少长期保存正常聊天内容的需要。
部署和接入
Sael 提供 Docker Compose 部署方式。准备好 Docker Compose、一个可访问的 Jev 服务和上游 AI 服务后，复制 .env.example 为 .env，填写管理员密码、PostgreSQL、Redis 和凭据加密密钥，再执行 docker compose up --build -d --wait。
默认有两个入口：
| 入口 | 地址 | 用途 |
|---|---|---|
| 运维控制台 | http://localhost:8080 | 配置上游、Jev、场景和审查开关 |
| 客户端进网 | http://localhost:8081 | 接收和转发 AI API 请求 |
登录后按这个顺序配置：
- 填写上游 AI 服务地址；
- 填写 Jev 地址、模型、API Key 和超时；
- 创建场景并用试算验证；
- 打开全局审查；
- 把客户端 API 根地址改成 http://localhost:8081/v1。
控制台和进网端口默认只绑定本机。对外提供服务时，建议通过反向代理暴露进网端口，管理端口留在内网。
使用前需要知道的边界
Sael 当前审查的是进站的用户输入。上游生成的回答会继续转发，未包含输出侧安全审核。
当 Jev 不可用、输入超过送审上限，或者后台审核并发已满时，当前实现优先保证主服务可用，请求会放行并留下异常记录。生产环境需要关注 Jev 失败率、审核耗时和拦截趋势。
Sael 会在记录落库前对常见邮箱、手机号、令牌、JWT 和敏感键值做去敏，但这不等于能识别所有个人信息。Jev 和上游服务仍会收到原始请求，数据保留和第三方服务权限需要结合自己的合规要求配置。
结语
AI 中转站的安全问题，靠上游模型自己拒答很难管理，靠关键词过滤又很难长期维护。Sael 把分类、规则、拦截和记录放在同一个入口，让运营者可以先观察，再调阈值，最后决定哪些风险必须挡住。
如果你正在搭建 AI 中转站，或者已经有一套兼容 OpenAI 的网关，Sael 可以作为一层独立的文本安全审查服务接进去。
