Dify变量注入实现上下文感知的AI问答

Dify变量注入实现上下文感知的AI问答

在智能家居设备日益复杂的今天，确保无线连接的稳定性已成为一大设计挑战。而当我们把视线转向企业级智能系统时，类似的“隐形瓶颈”同样存在：用户明明已经上传了成百上千份文档，AI却总是在答非所问。

“这份报价单里的交付周期是多久？”——问题清晰、意图明确。但AI的回答却是：“企业交付流程通常包括需求确认、资源调配、实施部署……”它没说错，可也完全没用。

这背后的问题，并非模型不够强，也不是知识库不全，而是缺少对“上下文”的理解。真正的智能不是泛化生成，而是精准回应：知道你是谁、你在哪、你能看什么，然后才决定说什么。

Dify 的变量注入机制，正是解决这一痛点的关键钥匙。结合 Anything-LLM 这个轻量但功能完整的RAG平台，我们可以构建出真正具备“上下文感知能力”的AI问答系统——无需修改核心代码，也能让同一个知识库为不同用户呈现不同的“答案世界”。

为什么静态知识库总会“失语”？

设想两个典型场景：

一位独立开发者用docker run启动了一个本地版 Anything-LLM，导入了自己的项目笔记和API文档。他问：“上次讨论的数据库迁移方案是什么？”理想中，AI应该能结合最近对话或文件更新时间给出答案。但现实是，系统只是返回所有包含“数据库迁移”的段落，毫无上下文判断。

再看一个企业级案例：销售、研发、法务共用一套私有化部署的知识平台。当法务人员查询“NDA条款”时，若无权限控制，系统可能返回客户合同中的敏感内容；而销售人员提问技术规范，又可能被一堆合规文档淹没。

这两个场景看似差异巨大，本质却一致：知识是静止的，但问题是动态的。没有运行时上下文，AI就只能做关键词匹配，无法做到“因人施答”。

要打破这个困局，我们需要一种机制，能把“用户身份”、“权限范围”、“会话状态”等外部信息，实时注入到AI推理过程中。这就是变量注入（Variable Injection）的价值所在。

变量注入：让提示词“活”起来

Dify 不只是一个调用大模型的接口封装工具，它本质上是一个支持可视化编排的AI工作流引擎。它的核心优势之一，就是能够将外部传入的数据结构，在执行链路中动态绑定到提示词里。

比如你通过 API 发送如下请求：

{ "inputs": { "query": "这份合同的付款方式是什么？", "user_context": "{\"user_id\": \"U8823\", \"role\": \"sales\", \"spaces\": [\"public\", \"sales\"]}" } }

Dify 能识别这些字段，并在后续节点中使用 Jinja2 模板语法直接引用：

当前用户角色：{{inputs.user_context.role}} 可用知识空间：{{inputs.user_context.spaces | join(', ')}} 原始问题：{{inputs.query}}

更进一步，你可以做条件判断：

{% if inputs.user_context.role == 'legal' %} 请严格依据公司合规政策作答，禁止推测。 {% else %} 可提供一般性解释，但注明“具体以法务最终审核为准”。 {% endif %}

这种能力意味着什么？意味着同一套提示词模板，可以服务多个角色、适应多种权限策略，而无需复制粘贴、硬编码逻辑。

更重要的是，它实现了业务逻辑与AI生成的解耦。前端系统负责认证和上下文准备，Dify 负责注入与调度，Anything-LLM 专注检索与生成——各司其职，灵活可扩展。

架构整合：Dify 作为上下文控制器

Anything-LLM 功能强大，原生支持文档向量化、多模型接入和 Workspace 隔离。但它默认并不接收复杂的运行时上下文。要想实现细粒度的访问控制和个性化响应，必须在其前段加一层“上下文协调层”。

Dify 正好扮演这个角色。整体架构如下：

[用户] ↓ (携带 user_context + query) [Dify 工作流] ↓ (解析变量、构造增强提示) → [调用内置 LLM 或转发至 Anything-LLM] ↓ [Anything-LLM 执行 RAG] ↓ [返回个性化回答]

整个过程无需改动 Anything-LLM 源码，仅需合理配置 Dify 的输入结构和提示工程即可完成升级。

实践路径：四步打造上下文感知系统

第一步：定义标准化上下文输入

在 Dify 中创建工作流时，明确声明所需输入参数。推荐结构如下：

注意：user_context虽为字符串，但内容应为合法 JSON，便于后续解析提取子字段。

第二步：编写上下文驱动的提示词

在 Dify 的 LLM 或检索节点中，设计如下提示模板：

你是一名企业知识助理，请根据用户的权限和角色，准确回答其问题。 【上下文信息】 - 当前用户角色：{{inputs.user_context.role}} - 可访问知识空间：{{inputs.user_context.spaces | join(', ')}} - 对话ID：{{inputs.session_id}} 【指令】 1. 仅允许引用位于上述空间中的文档； 2. 若问题涉及受限内容，请礼貌拒绝并说明原因； 3. 回答应专业简洁，优先引用最新版本文档。 【问题】 {{inputs.query}} 【回答】

这个提示的关键在于：不仅告诉模型“问什么”，还明确了“谁能问”、“能看到什么”。这相当于给AI划了一条行为边界，极大提升了输出的安全性和相关性。

第三步：连接 Anything-LLM 的知识能力

虽然 Dify 自带基础检索功能，但对于复杂文档管理（如PDF批注、网页快照、版本追踪），Anything-LLM 更具优势。因此建议将其作为后端RAG引擎，由 Dify 控制入口。

有两种主流集成方式：

方式A：通过 Webhook 直接调用 API

在 Dify 添加 HTTP 请求节点，向 Anything-LLM 的聊天接口发起 POST：

import requests import json ANYTHING_LLM_API = "http://localhost:3001/api/workspace/sales-team/chat" HEADERS = {"Content-Type": "application/json"} payload = { "message": inputs["query"], "sessionId": inputs["session_id"], "metadata": { "user_role": json.loads(inputs["user_context"]).get("role"), "allowed_spaces": json.loads(inputs["user_context"]).get("spaces") } } resp = requests.post(ANYTHING_LLM_API, json=payload, headers=HEADERS)

⚠️ 注意：Anything-LLM 原生 API 对metadata字段的支持有限，需配合自定义插件或中间件才能实现基于元数据的过滤。

方式B：中间件拦截 + 查询重写（推荐）

更可靠的做法是在两者之间部署一个轻量中间层，负责解析上下文并改写查询。

示例（FastAPI 实现）：

from fastapi import Request, Response from starlette.middleware.base import BaseHTTPMiddleware import json class ContextRewriter(BaseHTTPMiddleware): async def dispatch(self, request: Request, call_next): body = await request.body() data = json.loads(body.decode('utf-8')) context_str = data.get("inputs", {}).get("user_context") if context_str: ctx = json.loads(context_str) spaces = ",".join(ctx.get("spaces", ["public"])) original_query = data["inputs"]["query"] # 注入空间标记 augmented_query = f"[SPACE:{spaces}] {original_query}" data["inputs"]["query"] = augmented_query # 更新 body request._body = json.dumps(data).encode('utf-8') response = await call_next(request) return response

随后在 Anything-LLM 的提示词中识别[SPACE:...]标记：

请根据以下规则回答问题： - 若查询包含 [SPACE:xxx] 标记，则仅可引用属于这些空间的文档； - 不得推测未提及空间的内容。 问题：{{query}}

再配合向量数据库（如 ChromaDB）的元数据过滤条件：

collection.query( query_texts=["付款方式"], where={"namespace": {"$in": ["public", "sales"]}} # 来自 allowed_spaces )

即可实现精确的权限隔离检索。

场景落地：从个人到企业的平滑演进

这套架构的魅力在于，它既能满足极简需求，又能支撑复杂业务，且升级路径清晰。

场景一：个人开发者搭建专属AI助手

小王用 Docker 快速启动本地 Anything-LLM，希望实现“按项目隔离”的问答体验。

解决方案很简单：

• 在 Dify 中固定注入如下上下文：
  json {"project": "mobile-app-v2", "mode": "development"}
• 提示词中加入引导语：
  你正在协助开发“mobile-app-v2”项目，请优先参考与此相关的技术文档。 若无明确关联，请说明“该问题超出当前项目范围”。

无需任何后端开发，就能让AI“记住”当前工作上下文，避免信息干扰。

场景二：企业级多部门知识平台

某金融公司部署了私有化版 Anything-LLM，各部门拥有独立 Workspace。现在希望通过统一入口实现“千人千面”的问答服务。

实现步骤：

1. 用户登录后，SSO 系统生成user_context并传递给 Dify：
   json { "user_id": "F1003", "department": "compliance", "allowed_spaces": ["public", "compliance", "legal-review"] }
2. Dify 解析该上下文，注入提示词并转发请求；
3. 中间件将allowed_spaces编码为[SPACE:compliance,public]插入查询；
4. Anything-LLM 结合 Workspace 隔离机制，仅检索授权文档。

结果：同一个知识库，销售看到的是客户模板，研发看到的是接口文档，法务只能查合规条款——一人一世界，问答即安全。

关键工程考量与最佳实践

要让这套系统稳定运行，还需关注以下几个细节。

✅ 安全性：防注入、防越权

• 对user_context做白名单校验，禁止任意字段传入（如_internal、__proto__）；
• 在中间件中验证allowed_spaces是否属于该用户合法权限集；
• 避免将完整文档内容通过变量注入，只传递标识符或摘要信息。

✅ 性能：控制上下文体积

• JSON 上下文建议不超过 1KB；
• 使用短标签代替长描述（如"dept": "sales"而非"department": "销售部"）；
• 开启 Dify 缓存机制，避免重复解析相同上下文。

✅ 可观测性：调试与审计

• 启用 Dify 的执行日志，记录每次变量注入的实际值；
• 在返回结果中附加debug_info字段（生产环境可关闭），显示本次使用的上下文；
• 记录session_id与用户行为轨迹，用于后续分析和问题追溯。

✅ 兼容性：版本与协议匹配

• 确保使用的 Anything-LLM 版本支持自定义元数据传递（建议 v0.3.0+）；
• 若使用 Ollama、OpenAI 等外部模型，确认上下文长度未超限（通常 ≤ 128K）；
• 对接 SSO 系统时，统一用户 ID 格式，避免映射错误。

结语：上下文，才是AI系统的操作系统

今天的 AI 应用正经历一场静默革命：从“通用智能”走向“情境智能”。我们不再追求一个“什么都知道”的机器人，而是需要一个“懂场合、知分寸、守边界”的助手。

Dify 的变量注入机制，以极简方式实现了上下文的动态注入；Anything-LLM 则以其优雅的设计，成为承载个性化知识服务的理想容器。两者结合，既适合个人用户一键搭建专属AI助手，也能支撑企业级知识平台的安全运营。

在这个信息过载的时代，我们需要的不是更多的答案，而是正确的答案出现在正确的人面前。而这，正是上下文感知AI的意义所在。