给 Dify 应用加一层 AI 安全护栏：一个中间层的工程设计思路

Kari11

46人浏览 · 2026-06-04 14:44:17

Kari11 · 2026-06-04 14:44:17 发布

很多团队用 Dify 搭 AI 应用时，第一阶段会把注意力放在应用编排上：知识库怎么接，工作流怎么拆，Agent 怎么调工具，模型效果怎么调。

这很正常。Dify 的价值就在于把 AI 应用搭建门槛降下来。

但应用一旦从 Demo 走向生产，另一个问题会冒出来：这个系统的安全边界在哪里？

用户输入可能污染上下文，模型输出可能越过业务边界，知识库可能暴露内部资料，Agent 可能因为一段恶意指令触发错误工具调用。这个时候，仅靠 prompt 约束模型，通常不够稳定。

一种更工程化的做法，是在 Dify 应用链路旁边增加一个 AI 安全护栏中间层。

一、为什么安全护栏更适合做成中间层

安全逻辑如果直接散落在业务代码、prompt、Dify 节点和模型调用里，短期看起来快，长期会变得很难维护。

常见问题是：

每个应用各写一套过滤逻辑，策略无法复用
prompt 里堆了大量安全约束，效果却不可观测
输出异常后只能查业务日志，很难知道是哪条策略没有命中
Agent 工具调用链路变长后，输入风险很难统一管理
不同业务场景的安全边界混在一起，误判和漏判都难排查

把安全护栏抽成中间层，核心目的不是“多加一层系统”，而是把安全策略、检测逻辑、审计日志和处理动作集中管理。

它可以独立于业务应用迭代，也可以服务多个 Dify 应用。

二、一个最小可用架构

可以先从一个最小架构开始：

Client
  -> Guardrail Gateway
  -> Dify App
  -> Model Provider
  -> Guardrail Output Review
  -> Client

再展开一点：

┌────────────┐
│  Client    │
└─────┬──────┘
      │
┌─────▼────────────────┐
│ Guardrail Gateway     │
│ - input detection     │
│ - policy matching     │
│ - request metadata    │
└─────┬────────────────┘
      │
┌─────▼────────────────┐
│ Dify App / Workflow   │
│ - RAG                 │
│ - Agent               │
│ - Tool calling        │
└─────┬────────────────┘
      │
┌─────▼────────────────┐
│ Output Review         │
│ - sensitive data      │
│ - unsafe response     │
│ - business rules      │
└─────┬────────────────┘
      │
┌─────▼────────────────┐
│ Audit & Metrics       │
│ - trace id            │
│ - risk type           │
│ - action              │
│ - latency             │
└──────────────────────┘

这个结构有几个好处。

第一，业务应用不需要理解所有安全规则，只要把请求交给中间层处理。

第二，策略可以集中配置，多个 Dify 应用可以共享底层检测能力。

第三，日志结构更统一，后续做审计、复盘、报表和策略优化会更容易。

三、输入侧：不要等风险进入模型上下文

输入检测应该发生在请求进入 Dify 应用之前。

它要解决的问题是：这条请求是否应该进入后续链路？

可以按风险类型拆成几类：

input_risk:
  - prompt_injection
  - jailbreak
  - sensitive_data
  - privilege_escalation
  - malicious_instruction
  - business_policy_violation

处理动作也不一定只有 block。

更合理的动作集合可能是：

action:
  - allow
  - block
  - mask
  - rewrite
  - require_confirmation
  - route_to_human

比如用户输入里包含手机号，不一定要直接拒绝，可以脱敏后继续；用户试图让模型忽略系统规则，可以直接拦截；用户触发了高风险工具调用，则可以要求二次确认。

这比简单的“命中词表就拒绝”更适合企业应用。

四、输出侧：审查的不只是文本

输出审查很容易被低估。

很多人会把它理解成内容审核，但 LLM 应用里的输出风险更复杂。模型返回的可能是 Markdown、表格、代码、链接、引用来源、工具调用结果，甚至是多轮上下文综合后的结论。

输出审查至少要看几类问题：

是否泄露敏感信息
是否给出业务规则之外的承诺
是否包含不应该出现的链接或操作建议
是否引用了越权资料
是否把不确定结论写成确定结论
是否触发行业场景里的特殊限制

在工程实现上，输出审查最好不要只在最终响应结束后执行。对于流式输出，系统需要在 chunk 级别做增量检测。

伪代码可以这样理解：

async function streamWithGuardrail(modelStream, context) {
  for await (const chunk of modelStream) {
    const decision = await outputGuardrail.check({
      chunk,
      context,
    });

    if (decision.action === "block") {
      yield "当前回答存在风险，已停止输出。";
      break;
    }

    if (decision.action === "mask") {
      yield maskSensitiveContent(chunk);
      continue;
    }

    yield chunk;
  }
}

真实生产环境里还需要考虑缓冲窗口、跨 chunk 实体识别、低延迟返回和误判兜底，但核心思想是：输出审查要进入流式链路，而不是只做最终结果扫描。

五、策略层：规则要跟业务场景绑定

安全策略不能只按“全局规则”设计。

同样一句回答，在不同业务场景里风险不同。客服场景里的错误承诺、知识库场景里的越权引用、Agent 场景里的工具调用风险，本质上不是同一种问题。

一个更可维护的策略结构可以是：

policy:
  app_id: customer_service_bot
  scene: customer_support
  role: external_user
  rules:
    - type: sensitive_data
      direction: output
      action: mask
    - type: unsupported_commitment
      direction: output
      action: block
    - type: prompt_injection
      direction: input
      action: block

这里有几个关键字段：

app_id：区分不同 Dify 应用
scene：区分客服、知识库、Agent、Copilot 等场景
role：区分外部用户、内部员工、管理员等角色
direction：区分输入侧和输出侧
action：定义命中规则后的动作

这样做的好处是，安全策略可以跟应用一起迭代，而不是堆在一个全局黑名单里。

六、日志层：没有审计就没有迭代

安全护栏如果没有日志，就很难长期维护。

一次检测至少应该记录这些字段：

{
  "trace_id": "req_20260604_001",
  "app_id": "knowledge_base_bot",
  "scene": "internal_knowledge_base",
  "direction": "input",
  "risk_type": "prompt_injection",
  "risk_level": "high",
  "action": "block",
  "policy_id": "policy_knowledge_001",
  "latency_ms": 42,
  "created_at": "2026-06-04T10:00:00+08:00"
}