把拒答逻辑从模型权重里剥离，才能让安全策略动起来

红队测试组待过的人，对「对齐税」的痛点有切身体会。最常见的问题出在拒答逻辑上：把安全边界直接烧进模型权重，结果模型一旦遇到技术词汇——比如问「如何配置防火墙规则防止 SQL 注入」——就会先卡住几秒，吐出一段「我无法提供协助」的固定回复。这不是安全设计，而是让模型变成了一个不会思考的哑巴。

目前业界普遍在 RLHF 阶段将安全规则硬编码到参数里。但这种方法有两个致命弱点：一是策略调整后需要全量微调，成本高昂；二是不同场景的容忍度差异巨大——比如代码助手需要允许修改危险函数，而客服机器人则不能允许泄露用户隐私。两者无法用同一套权重同时满足。

更合理的解决方案是将安全拒答从推理链路中解耦。我们的实践是将网关单独部署为 Sidecar，确保延迟控制在 P99 小于 15ms。这样模型迭代就不需要为了改一条拒答策略重新跑全量 SFT。

一些厂商把 Chain-of-Thought（CoT）当作黑盒，甚至加密后不让用户查看。但在合规审计面前，这种做法无法通过验证。我们采用的方法是：

1. 强制结构化输出：模型必须将推理步骤以 JSON Schema 格式输出，字段固定为 step_id、tool_call、risk_level 和 confidence。这样每一步的安全风险都能被量化。

1. 前置风险熔断：在 tool_call 生成前，策略引擎会同步拦截高危操作（例如 rm -rf / 或 DELETE FROM users），并在 CoT 流中注入 <blocked> 标记。模型在下一轮推理时会自动调整方案，避免重复触发被阻止的操作。

1. 全链路不可篡改日志：每次推理的完整 CoT、策略引擎的判定依据以及人工复核记录，都会存入带 Merkle Tree 的 ClickHouse 数据库。这样做的目的是确保事后可复现、可追责。

{
  "step_id": 3,
  "thought": "用户要求删除生产库表，风险等级 Critical",
  "tool_call": null,
  "risk_level": "Critical",
  "policy_decision": "BLOCKED",
  "policy_rule": "db.write.production.delete.forbidden",
  "fallback_action": "引导用户走归档流程或联系 DBA"
}

Prompt Injection 的核心问题在于控制权的争夺。指望模型在参数层面区分指令和数据，本质上是不现实的。工程上唯一可行的方法是采用权限最小化和数据流向标记：

• 所有外部输入（用户对话、RAG 检索结果、工具返回）必须标记为 source: untrusted。
• 系统提示词和开发者指令则标记为 source: trusted。
• 下游执行层（代码解释器、数据库驱动、HTTP 客户端）仅执行来自 trusted 源的指令，而 untrusted 数据只能作为参数值，绝不允许拼接进命令结构。

这种设计类似于 Web 安全中的参数化查询，通过架构层面的物理隔离，比任何基于指令的微调都更有效。

安全策略不应依赖于一年一次的大考核，而应纳入 CI/CD 流程中的一个 Stage。具体做法是：

• 构建一个持续扩充的攻击语料库，涵盖 Prompt Injection、越狱、数据窃取和链式思维泄露等场景。
• 每次模型版本发布、策略规则变更或工具集更新时，自动触发全量回归测试。
• 关键指标包括：拒答率（安全类）、误拒率（正常业务）、绕过成功率 和 平均检测延迟。
• 设定指标回滚阈值，并将其纳入发布 Gate，一旦超标则直接阻断发布。

在一次发布前夕，自动化红队发现了一种新型编码绕过手法：攻击者将「忽略之前指令」藏在 Base64 里，通过工具返回注入到二轮上下文中。策略引擎当时未能检测到，但由于有完整的 CoT 审计日志，复盘仅用了 20 分钟便定位到解码器的漏洞。