LangChain实战：构建Agent安全护栏的四层防护体系

从大模型到LangChain：为什么需要应用框架

理解大模型开发的本质其实并不复杂。大语言模型本身就是算法团队训练出来的一种模型，其核心能力在于强大的推理能力——你给它一堆杂乱无序的信息，它能整理成有序的、你想要的结果；你与它对话，它能准确理解你的意图。

这种推理能力源于大语言模型（LLM）在海量文本语料上进行的预训练过程。以GPT系列、Claude、LLaMA等为代表的模型，通过Transformer架构中的自注意力机制，学会了捕捉文本中长距离的语义依赖关系。所谓推理能力，并非传统意义上的逻辑演绎，而是一种基于概率的模式识别与生成能力——模型能够根据上下文预测最可能的下一个token，从而实现信息整理、意图理解、知识问答等任务。这种能力在思维链（Chain-of-Thought）提示下表现尤为突出，模型可以逐步拆解复杂问题并给出结构化的推理过程。

而当前所有大模型开发岗位的核心工作，总结起来就是一句话：如何让大模型的这种能力更好地服务于你的业务。

问题在于，如果开发者需要自己从零编写与大模型通信、处理输入输出、构建对话逻辑的底层代码，往往会陷入一个误区：把大量精力耗费在如何更高效、更稳定地与大模型沟通上，反而偏离了「解决业务痛点」的初衷。

LangChain 正是为了解决这一问题而生。它是一个构建大模型应用的框架，将与大模型通信、碎片化知识注入、对话控制、内容过滤等底层能力封装起来，让开发者能专注于业务本身。LangChain最初由Harrison Chase于2022年底开源，迅速成为大模型应用开发领域最受欢迎的框架之一。它的核心价值在于提供了一套标准化的抽象层：包括模型调用接口（支持OpenAI、Anthropic、本地模型等数十种后端）、Prompt模板管理、文档加载与分割、向量数据库集成、检索增强生成（RAG）管道以及Agent执行引擎。这种抽象使得开发者可以用统一的API对接不同的大模型厂商，避免了因底层API差异而产生的重复适配工作。

LangChain 生态的三层架构

在整个 LangChain 生态中，有一个清晰的分层结构，理解它对掌握 Agent 开发至关重要。

底层：LangGraph

最底层的模块是 LangGraph，它以「图」的形式实现 Agent 的执行流程。如果你直接用 LangGraph 开发，代码量会比 LangChain 更大，但换来的是对业务和实现细节的极致灵活控制。

LangGraph采用有向图（Directed Graph）作为Agent工作流的编排方式，其中节点（Node）代表具体的执行步骤（如调用模型、执行工具、条件判断），边（Edge）定义步骤之间的流转关系。这种图结构天然支持循环、分支、并行等复杂控制流，非常适合需要多轮推理、工具调用和状态管理的Agent场景。LangGraph内置了持久化状态管理机制，每个节点执行后的状态会被记录下来，支持断点恢复和人工干预。这与传统的链式（Chain）执行相比，提供了更强的可控性和可观测性，但也意味着开发者需要显式定义图的拓扑结构，代码量相应增加。

中层：LangChain

LangChain 可以看作是基于 LangGraph 之上的一层封装。它的底层其实就是用 LangGraph 这种图来实现的。相比直接使用 LangGraph，LangChain 搭建 Agent 或 AI 应用的速度更快、编写更灵活。

上层：DeepAgents

最上层是 DeepAgents，它是 harness 架构的一种实现，同样基于 LangChain（底层依然是 LangGraph）构建。DeepAgents 封装度最高、最好用，还额外提供了操作系统文件、调用 skill 等能力，但代价是对业务处理灵活性的削弱。

Harness架构是一种高度抽象的Agent运行时架构，其设计理念是将Agent的核心能力（推理、工具调用、记忆管理）与具体的业务逻辑解耦，通过声明式配置而非命令式编程来定义Agent行为。DeepAgents作为该架构在LangChain生态中的实现，进一步封装了文件系统操作、Skill（技能模块）注册与调用等能力，使得开发者可以用极少的代码快速构建功能完备的Agent。但高度封装意味着框架对执行流程做了大量预设假设，当业务场景超出这些假设时，定制化的难度会显著增加。

一个重要结论：越往上层，框架封装越完善、越好用；越往底层，对业务细节的控制越灵活。而本文要讲的安全护栏（Guardrails），同时适用于 LangGraph、LangChain 和 DeepAgents 这三个层面。

值得一提的是，在所有 AI Agent 框架中，LangChain 生态对大模型的支持最全面、内部实现细节最完善、对市面上最新技术的涵盖也最广泛。

安全护栏 Guardrails：Agent 的安全把关人

安全护栏（Guardrails），字面意思就是「栅栏」，它在 Agent 对话流程中扮演「安全把关人」的角色。

它主要做三类事情：

1. 输入过滤：当用户输入包含违规内容（如预设的违禁词）时，在消息交给 Agent 之前进行截断。
2. 中间数据脱敏：Agent 执行过程中，可能通过 MCP 工具查询业务数据，返回结果中可能包含用户敏感信息，护栏可以对这些数据做脱敏处理。
3. 输出检测：对模型输出的答案进行检测——无论是模型推理能力不足导致的逻辑不通，还是可能包含的有害内容，都可以进行安全处理。

典型应用场景

• 防止敏感信息泄露
• 阻断提示词注入攻击（Prompt Injection）
• 拦截有害内容进入模型
• 业务合规性检测与输出内容审核

其中，提示词注入（Prompt Injection）是大模型应用面临的最典型安全威胁之一。攻击者通过精心构造的输入文本，试图覆盖或绕过系统预设的System Prompt，从而让模型执行非预期的指令。常见的攻击形式包括：直接注入（在用户输入中嵌入「忽略之前的所有指令」等命令）、间接注入（通过外部数据源如网页、文档中埋入恶意指令，在RAG检索时被模型读取）以及越狱攻击（Jailbreak，通过角色扮演等方式突破模型的安全对齐）。OWASP已将Prompt Injection列为大模型应用的头号安全风险。防御手段除了安全护栏的输入过滤外，还包括输入输出的语义隔离、权限最小化原则以及多层验证机制。

基于中间件的安全护栏实现原理

安全护栏的底层实现，依赖于 LangChain Agent 执行流程中的一系列中间件（Middleware）。

所谓中间件，可以理解为：在你与 Agent 对话的过程中，可以随时插入进去的一段执行代码逻辑。无论是在 Agent 调用前后，还是模型调用前后，都可以插入不同的处理逻辑。

中间件（Middleware）模式源自Web开发领域，最早在Node.js的Express框架和Python的Django/ASGI框架中被广泛采用。其核心思想是将请求处理流程拆解为一系列可组合、可插拔的处理单元，每个单元只关注特定的横切关注点（Cross-cutting Concern），如认证、日志、限流、数据转换等。在LangChain的Agent执行链中，这一模式被巧妙地移植过来：beforeAgent、beforeModel、afterModel等钩子函数构成了一条责任链（Chain of Responsibility），开发者可以在不修改核心Agent逻辑的前提下，灵活地注入安全检查、监控埋点、数据脱敏等功能。这种设计大幅提升了系统的可维护性和可扩展性。

完整的中间件执行链

从用户发起 Request 到得到最终结果，整个 Agent 对话会经过以下中间件节点：

中间件节点	执行时机	作用
beforeAgent	Agent 执行之前	处理前置业务逻辑、输入校验
beforeModel	调用模型之前	信息预处理、敏感词过滤
wrapModelCall	模型调用环节	更贴近模型调用的精细化处理
wrapToolCall	工具调用时	工具权限校验、参数脱敏
afterModel	模型调用完成后	输出内容审核与修正
afterAgent	结果返回用户前	最终安全检查与格式化

正是通过在这些不同节点插入逻辑，安全护栏才能实现从输入到输出的全链路把控。

两大类安全防护策略

安全护栏本质上是对信息（尤其是敏感信息和错误信息）进行处理，可分为两大类型。

确定性防护

针对格式固定、可精确识别的内容进行防护，例如身份证号、手机号、银行卡号、信用卡号、邮箱等。这类信息模式确定，可以通过正则匹配等规则进行脱敏、截断或额外处理。

它的局限也很明显：无法处理「隐晦」的风险内容。比如大模型用看似正常的自然语言，引导用户走向错误操作——这种非固定内容，规则匹配无能为力。

模型驱动防护

针对非固定、需要语义理解的内容，借助另一个模型来理解回复结果，进而判断内容是否合规、是否存在风险。这类防护弥补了确定性防护的盲区，能够应对更复杂、更隐蔽的安全威胁。

在实际工程中，模型驱动防护通常采用专门微调过的小型分类模型（如基于BERT的毒性检测模型、OpenAI的Moderation API）而非通用大模型，以兼顾推理速度和检测准确率。这些小模型经过针对性训练，在特定安全检测任务上往往能达到甚至超越大模型的表现，同时延迟更低、成本更小，适合在中间件管道中进行实时检测。

两者结合使用，才能构建起完整的安全防线。

LangChain 内置的两种安全防护能力

LangChain 内部提供了两类开箱即用的安全防护能力，开发者无需从零搭建。

PII 检测（个人身份信息防护）

PII（Personally Identifiable Information，个人身份信息）检测，专门针对身份证号、手机号、银行卡号、信用卡号、邮箱等确定性敏感信息。它既可以对输入中的敏感信息做截断，也可以对模型输出的内容做脱敏处理。

在技术实现上，PII检测通常结合多种方法：基于正则表达式的模式匹配（如手机号的11位数字模式、身份证号的18位校验规则、信用卡号的Luhn算法校验）、基于命名实体识别（NER）的机器学习方法（如使用spaCy、Microsoft Presidio等库识别姓名、地址等非结构化敏感信息），以及基于上下文语义的判断（区分「我的手机号是138...」与「产品编号138...」的不同含义）。LangChain集成的PII检测能力主要基于Microsoft Presidio框架，支持多种语言和实体类型的识别，并提供替换（用占位符替代）、哈希、加密等多种脱敏策略。在生产环境中，PII检测需要在准确率和召回率之间权衡——过于激进的检测会导致正常内容被误拦截，而过于宽松则可能遗漏真实的敏感信息。

Human-in-the-Loop（人工介入审批）

HITL 即人工介入机制。在用户与 Agent 对话、需要调用某些高危工具时，不同用户可能拥有不同的操作权限。通过 HITL，可以在关键操作节点引入人工审批环节，确保敏感操作经过人工确认，本质上这也是一层重要的安全防护。

在企业级AI应用中，HITL不仅是安全机制，更是合规要求。在金融、医疗、法律等高风险行业，监管机构往往要求关键决策必须有人工审核环节。在LangGraph中，HITL的实现依赖于其内置的中断（Interrupt）机制：当Agent执行到预定义的审批节点时，工作流会暂停并将当前状态持久化到数据库（如PostgreSQL、Redis），同时通过Webhook、消息队列或UI界面通知审批人。审批人审核后，通过API恢复工作流的执行。这种异步审批模式需要考虑超时处理、审批人不可用时的降级策略，以及审批记录的可追溯性等工程问题。

总结

从大模型的推理能力，到 LangChain 的三层生态架构，再到基于中间件实现的安全护栏与 HITL 人工审批系统——企业级 Agent 开发的安全体系，正是通过这一套分层、可插拔的机制层层构建起来的。

无论你使用的是灵活的 LangGraph、均衡的 LangChain，还是高度封装的 DeepAgents，Guardrails 的设计理念都具有通用性。掌握确定性防护与模型驱动防护的组合，配合 PII 检测和人工介入机制，才能真正打造出既好用又可靠的企业级 AI 应用。

核心要点