核心要点
- AISIX 1.0.0 将 AISIX Cloud 中的已保存规则测试与实际请求评分连接起来，帮助团队在依赖一条策略之前评估它的效果。
- 一次有依据的发布，应从代表性样本走向真实流量：验证判断结果，排查检查不可用的原因，再确认防护范围。
- 检查能力取决于请求路径。Files API 流量、模型生成的推理内容，以及 MCP 工具的执行时机，都需要在应用设计中明确处理。
- 配置校验、服务提供方集成和冷却机制的变化，也应纳入同一次应用升级验证。
一个客服助手需要处理三类请求：用户询问如何重置密码，有人要求它忽略原有指令，还有用户在报告疑似攻击时引用了同一句指令。
团队希望第一类正常通过，第二类被拒绝，第三类则需要判断如何处理。启用安全规则只是开始。在依赖它之前，团队需要知道：规则为什么作出这样的判断，遇到真实流量时是否仍然有效，以及它究竟覆盖了助手工作的哪些环节。
AISIX 1.0.0 于 2026 年 9 月 4 日发布，让团队更容易逐一回答这些问题。已保存规则测试、语义评分和更清晰的检查失败归因，为策略发布的不同阶段提供了判断依据。沿着这个客服助手的使用过程，可以更直观地理解这些能力如何配合。
先弄清楚，一条规则为什么这样判断
客服助手首先要区分违规指令与正常对话。语义筛查通过嵌入模型（Embedding Model）比较文本与示例的相似程度，在调用方换一种说法表达相近含义时，补充关键词匹配的能力。
不过，相似度分数需要结合场景解读。它不等于“请求具有恶意的概率”，其含义取决于模型、示例、语言和实际业务流量。因此，阈值应根据团队自己的评估样本来确定。
在 AISIX 中，文本与任一拒绝示例的相似度达到阈值，就会被拒绝；使用允许列表时，如果文本与所有允许示例的相似度都低于阈值，同样会被拒绝。拒绝匹配优先。因此，把阈值调高，对两类列表产生的效果并不相同。
AISIX Cloud 新增的测试面板，让这些判断更容易观察。它会展示已保存语义安全规则的分数、阈值、最接近的示例和判断结果。团队可以分别测试常规问题、违规指令，以及引用攻击语句的问题报告，找出规则判断与业务预期不一致的地方。这些只是建议的评估场景，并不预设模型会给出怎样的分数。
修改后需要先保存再测试，因为面板读取的是已存储配置。测试通过控制面执行，不会验证网关部署状态或规则绑定范围。开源网关没有对应的控制台面板，可以直接从监控模式下的真实流量开始校准。
对于使用 AISIX Cloud 的团队，即使样本测试令人满意，接下来仍需确认：用户真正调用客服助手时，这条规则是否在执行？
把样本中的判断，放回真实请求里验证
要回答这个问题，需要将规则绑定到预期范围，并用 monitor 模式观察请求。校准流程通过真实流量评分，将样本测试中的预期与网关实际执行的检查联系起来。
请求经过检查后，即使被放行，也可以携带 guardrail_scores。对于客服助手日常处理的密码重置问题，团队由此可以查看检查依据，而不必仅凭“拦截计数没有增加”来猜测规则是否覆盖了这些请求。
评分记录通过索引标识最接近的示例，不会把示例原文或被检查文本复制进这条记录。这为分析提供了上下文，也限定了该字段包含的内容。其他内容采集和导出器设置，仍需单独核查数据保留方式。
假设客服助手仍能正常响应，但它依赖的嵌入服务已经不可用。只看请求成功与否，团队无法判断检查是否完成。AISIX 1.0.0 通过 guardrail_bypassed_reason 更一致地记录检查失败后放行的原因，并扩展了绕过检查的指标。无法在运行时构建的规则，也会显示在 /status/config 中。
这些信息对应着不同的处理方式：匹配结果不合理，应检查示例和阈值；检查无法完成，应排查依赖和失败策略；规则没有出现在请求链路中，则需要核查配置与适用范围。单纯调整阈值，解决不了所有问题。
团队检查真实流量中的误报、漏报和失败情况后，再切换到 block 模式，验证正常请求和应被拒绝的请求。AISIX 提供依据，团队决定可以接受怎样的取舍。
至此，团队对已经测试过的对话路径有了把握。但客服助手的工作，往往不止于回答一条消息。
助手开始执行操作时，防护范围也要跟着检查
假设同一个助手还能通过 MCP 工具修改客服工单。适用于模型请求的规则，并不会自动检查这次工具调用：MCP 调用没有模型，因此模型范围的安全规则不适用。
现有的 MCP 安全规则机制还区分了两个时机。输入阶段拦截，可以阻止请求到达上游工具；输出阶段拦截，只能扣留工具执行后的结果，无法撤销已经完成的操作。
对于工单修改，团队因此需要在执行前验证权限和违规参数，再把结果检查作为另一项控制。前面讨论的“规则是否覆盖目标流量”，在这里有了具体的业务后果。
再看文件上传流程。1.0.0 的检查范围不包含 /v1/files 的输入和输出。检查批处理请求的外层结构，不等于检查上传文件中的记录。如果应用要求筛查文件内容，就需要在文件经过网关之前完成相应处理。
对话历史也有自己的边界。调用方重新提交的推理内容，会在支持的路径上接受检查；模型生成的推理内容则不属于输出检查范围。Anthropic 带签名的思考块可以触发拦截动作，但脱敏动作不会改写这些带签名的字节。
沿着助手实际完成业务的过程检查，就容易理解这些区别：消息、工具参数、工具结果和文件进入系统的位置并不相同。团队可以确定每项控制应该放在哪里，并直接验证那个环节，而不是根据一次聊天测试的结果推断整条链路都已受到保护。
将这套验证带进 1.0.0 升级
以应用为单位检查，也为本次发布中的其他变化提供了明确的落点。完整迁移清单应以 1.0.0 升级说明为准，建议在预发布环境优先验证四件事：
- 校验策略配置。 非空的语义示例列表必须提供对应阈值。此前能被接受的部分值现在可能不再通过校验；迁移还可能修复原先被跳过的规则记录，使其开始执行。
- 演练检查不可用的情况。 使用无法读取的内容，验证请求侧和响应侧的失败策略。如果缓冲中的流式输出无法恢复出可检查内容，会采用更严格的“检查失败即拒绝”处理。
- 显式启用冷却机制。 对需要保留 1.0 之前隐式冷却行为的直连模型，设置
cooldown.enabled: true。否则，失败目标不会因为冷却机制而暂时退出候选列表。这应与单次请求的重试和故障切换分开检查。 - 验证客户端和部署脚本。 测试文档列出的流式错误变化，并固定完整镜像版本，不要依赖简写版本标签继续更新。
如果客服助手还需要传递调用方上下文，或使用不同的模型服务提供方，应在同一次升级中检查这些集成。1.0.0 将客户端请求头转发能力扩展到模型流量、MCP 服务器、透传路由和 Realtime。需要确认哪些由调用方控制的值可以到达哪些上游，尤其要对照本版本规则检查凭证转发。
新增的推理强度映射，则允许最终选中的直连模型将应用请求的推理强度转换为上游采用的取值。配置同时包含 medium → high 和 high → max 时，请求中的 medium 只会变成 high，不会继续变成 max。映射采用区分大小写的精确查找；缺失或未配置映射的值保持不变，上游也必须支持映射后的值。
这些集成改进解决的是请求处理问题，与安全规则的判断准确率属于不同层面。将它们与策略变化一起验证，有助于应用负责人区分：业务表现发生变化，究竟来自安全决策，还是来自上游请求或路由行为的调整。
从一个应用开始，形成可重复的发布过程
对于这个客服助手，发布过程已经可以顺着业务推进：先用代表性文本解释规则的判断，再在真实请求中观察这些判断，最后沿着应用读取内容和执行操作的各个环节验证覆盖范围。
AISIX 1.0.0 让这个过程有了更多可检查的依据。可以先选择一个应用和一条能清楚描述预期行为的策略，按照语义安全规则校准指南完成验证，并将这些案例保留为后续变更的回归检查。团队由此能够更有依据地决定：什么时候启用规则，什么时候需要重新评估它。