xiaohack's Blog - Langchain
type: channel
link: https://blog.xiaohack.org/tag/Langchain/
items: RAG 文本分块：七种主流策略的原理与适用场景
items: PolarDB一站式记忆管理重磅上线：让记忆成为数据库最有温度的力量
items: 用 LangChain 驱动本地 Ollama 模型
items: 智能体来了：从 0 到 1：智能体应用的搭建
items: 为问答 Agent 添加短期记忆（ConversationBufferMemory）
items: 狂收 26k+ star！全网精选的 Skills 一网打尽！！
items: 循序渐进：构建 AI 智能体（Agent）前需要了解的基础概念
items: 深度实例分析：攻防视角下的AI框架组件中的注入漏洞
items: Ai安全漏洞剖析-CVE-2025-68664
items: LangGraph Server + AsyncPostgresSaver + unicorn 启动

RAG 文本分块：七种主流策略的原理与适用场景
type: item
date: 2026-02-13T21:45:52+08:00
description: 检索是 RAG 系统的搜索引擎，分块则是这个搜索引擎的基础。分块太长、太短、有噪声、切错了位置——随便犯哪个错LLM 都会有问题。行业里有句话流传很广："分块决定了 RAG 质量的 70%。"这个说法不夸张：好的分块让检索器拿到完整、有上下文、真正相关的信息；差的分块把文档打成碎片，上下文断裂，LLM 只能靠"编"来填补空白。什么是分块？RAG 的起点是文档收集与摄取：把所有原始材料（文档、文章、知识库条目）汇聚到一起。在进入检索环节之前，这些文档要经过文本分块处理也就是切分成更小的、有意义的片段。每个分块应当是连贯且自包含的，这样检索器才能在面对查询时快速定位、排序，并返回最相关的信息。分块就是在生成 Embedding 之前，把大段文本拆成更小语义单元的过程。检索器真正搜索的对象而不是整篇文档就是这些分块。分块做得好，文档中的内容就能被干净地捕获，上下文得以保留LLM 能做出有意义的推理。分块做得差，语义被割裂检索充满噪声。向量存储、Embedding 模型、Reranker——这些统统排在分块之后，分块才是真正的起点。固定大小分块这是最简单的方式。按预设的字符数或 Token 数直接切分，比如每 500 个 Token 一块完全不管句子和段落的边界在哪。速度快，行为可预测，处理大规模、结构混乱的数据集时很实用。但缺点也很明显——语义经常被拦腰切断。一个句子在这个分块里开了头，到下一个分块才结束，Embedding 的语义表达力就会打折扣。实践中一般会在相邻分块之间设置一定的重叠来缓解这个问题： from langchain.text_splitter import RecursiveCharacterTextSplitter splitter = RecursiveCharacterTextSplitter( chunk_size=500, chunk_overlap=50 ) chunks = splitter.split_text(long_text)切分文本时，连续的分块之间通常会加入一小段重叠区域来维持上下文的连贯。所谓重叠，就是前一个分块的尾部几句话，在下一个分块的开头再出现一次。这么做是为了防止跨越分块边界的关键信息丢失。没有重叠的话，检索器可能只拿到部分内容LLM 因此漏掉了关键上下文，给出残缺甚至误导性的回答。重叠量一般控制在分块长度的 10% 到 20%，在冗余和效率之间找一个平衡点。固定大小分块适合的场景包括日志文件、邮件、代码仓库，以及结构参差不齐的大型语料库。基于句子的分块这种方式按完整句子来划分文本，而不是按任意长度一刀切。每个分块至少包含一个或多个完整的句子，语法完整，语义连贯。好处是每个分块都是一个有意义的思想单元。检索器向 LLM 返回的信息更精确、更易理解，碎片化回答的风险降低不少。实际使用中通常也会搭配小幅重叠，进一步保证分块之间的衔接。基于段落的分块以完整段落为单位切分，不再拘泥于单个句子或固定 Token 数。这种方式天然保留了文档的结构和行文节奏，检索器更容易抓到完整的想法。每个分块往往对应一个独立的主题或子主题，LLM 处理起来更从容，也更容易给出准确的回答。对长篇文档、研究论文、综述类文章来说，段落级分块效果不错。和句子级分块一样，也可以加重叠来保持连贯。语义分块语义分块的切入点不是长度，而是语义本身。它利用 Embedding 或相似度分数来识别文本中天然的断裂点——主题切换、上下文转折、章节边界。产出的分块语义清晰度更高，边界和语义对齐，检索质量有明显提升，尤其在知识库、技术文档、结构化文章这类内容上效果突出。代价是计算开销更大而且分块长度不一致，后续处理需要额外考虑。 from langchain_experimental.text_splitter import SemanticChunker from sentence_transformers import SentenceTransformer model = SentenceTransformer("all-MiniLM-L6-v2") chunker = SemanticChunker(model, breakpoint_threshold=0.4) chunks = chunker.split_text(long_text)如果文档质量高、主题流转有明确脉络，语义分块往往是精度最高的选择。递归分割递归分割是固定大小和语义分块之间的一个折中方案。核心思路是优先尊重文档结构，只有在必要时才进一步拆分。具体做法是先尝试按标题切分。如果某个章节还是太长，就按段落切。段落还不够就按句子。句子仍然超限，最后才按字符兜底。这样得到的分块既保有语义完整性，尺寸也在可控范围内。 recursive_splitter = Re…

PolarDB一站式记忆管理重磅上线：让记忆成为数据库最有温度的力量
type: item
date: 2026-02-10T13:23:02+08:00
description: 大型语言模型（LLM）在理解和生成上下文连贯的对话方面取得了巨大成功。然而，它们固有的“记忆缺陷”——即有限的上下文窗口——严重制约了其在跨会话、跨应用的长时间交互中保持一致性的能力。一旦对话超出上下文长度，LLM 就会像一个“失忆”的伙伴，忘记用户的偏好、重复提问，甚至与之前确立的事实相矛盾。想象一下这个场景：你告诉一个AI助手你是素食主义者且不吃乳制品。几天后，当你向它寻求晚餐建议时，它却推荐了烤鸡。这种体验无疑会削弱用户对AI的信任和依赖。为此，PolarDB PostgreSQL版（以下简称PolarDB-PG）全新推出一站式记忆管理AI应用，使智能体能够跨会话、跨应用持续保留用户偏好、事实背景与历史交互信息，解决大模型有限上下文窗口和跨会话记忆丢失的核心痛点。1.构建智能体记忆面临的挑战开发、运维效率低：记忆系统构建需要选型或开发记忆引擎，对接各类数据库系统以及模型服务，开发、运维成本高；当前主流记忆框架均为检索式记忆系统，后端需要对接关系库、向量库甚至图库等多种记忆库资源，数据一致性难以保障；对于AI快速驱动业务演进而言，企业客户很难对数据库、记忆引擎、模型服务等底层设施做到完全兜底。记忆生成、检索效果不佳：不少企业客户希望自建记忆系统，但遇到记忆事实、偏好等提取不全导致关键信息遗漏；因记忆系统整体链路长导致记忆检索延迟高，导致交互问答不流畅；对需要用户画像和记忆推理需求场景，因只能提供向量化记忆导致检索结果相关性欠强；因模型算法效果在记忆整体应用中起到十分关键的作用，模型算法与提示词配置的灵活度，也直接决定了方案迭代的速度。系统成本压力大：随用户规模增长，系统在并发度、存储规模等方面缺乏弹性扩缩容能力；硬件、多种数据库系统、记忆引擎等多license系统，系统费用成本叠加；对于持续爆发增长的记忆库，缺乏支撑记忆生命周期管理的有效机制等。2.PolarDB一站式记忆管理系统针对上述挑战，PolarDB-PG推出全新AI应用——一站式长记忆管理系统正式发布上线。PolarDB-PG记忆管理真正融合了图+向量一站式记忆库 + 开放记忆引擎 + 模型算子能力，提供了全面白屏化的参数配置，提示词策略管理以及模型算法混池加速能力，支撑“记忆读写 → 上下文注入 → 模型推理 → 结果反馈”的完整闭环。一期已接入Mem0（发音为 "mem-zero"）记忆引擎，兼容开源 Mem0社区生态，使智能体能够跨会话、跨应用持续保留用户偏好、事实背景与历史交互信息，从而实现真正的个性化和持续学习体验。PolarDB-PG一站式记忆管理系统架构1、记忆引擎目前，PolarDB-PG已支持Mem0框架，全面兼容开源项目Mem0社区生态；支持Mem0（向量基础版）和Mem0g（图增强版）；对开源Mem0系统实现了系列增强，包括：中英文模型接入能力；支持根据userid多图管理功能；支持根据userid向量分区管理功能；同步、异步记忆写出能力；增加sslmode连接参数，支持ssl连接；支持提示词模版的定制优化以及Mem0企业版的部分功能对齐等。后续PolarDB-PG还将和MemOS合作，为AI构建专属的“记忆操作系统”，实现记忆全生命周期的精细化管理与动态调度。2、一站式记忆库PolarDB-PG向量数据库引擎 + 图数据库引擎一站式组合。其中，向量数据库引擎采用经优化的PGVector插件，PGVector在PG社区已经被广泛应用，具备十分良好的AI生态支持。图数据库引擎兼容开源AGE（A Graph Extension，为Apache软件基金会的顶级项目），且经过PolarDB-PG与云原生能力的增强融合以及在大量图客户上的多年应用改进和性能优化，不仅表现成熟稳定，且具备在百亿级规模图场景下仍然保持万级以上QPS和百毫秒以下的查询延迟的极佳表现。记忆库支持云原生集中式版本或分布式版本，无需担心扩展性风险。3、PolarDB模型算子统一采用PolarDB模型算子提供模型部署、推理、调度体系化能力。模型在记忆管理中扮演了核心的角色，其中：大语言模型LLM负责从用户与智能体的对话中自动提取出具有长期价值的关键事实与偏好，同时用于新记忆与已有记忆的融合（增删改）以及基于图的实体三元组信息抽取；嵌入模型EMB负责将关键信息转化为高维向量，实现高效的语义检索；Rerank模型则用于记忆召回后的精排序。模型调用和推理的效率占据了用户体验的关键一环，本方案支持多种形式的模型对接途径，包括：a. 数据库自有模型算子形式；b. 百炼模型服务形式；通过高度优化的链路，大幅提升记忆相关推理效率。4、图形化控制台PolarDB-PG记忆管理在PolarDB系统中属于AI应用的一种形式，提供了全面图形化的管理界面：模型算法与数据库配置记忆提取策略配置记忆图谱可视化…

用 LangChain 驱动本地 Ollama 模型
type: item
date: 2026-02-10T09:39:12+08:00
description: 这两年，大模型几乎成了开发者的“标配工具”：写代码、查资料、做总结、当智能助手。但你有没有认真想过一个问题：我们真的必须把所有请求都发到云端 API 吗？随着模型体积持续下降、硬件性能快速提升，以及 Ollama 这类工具逐渐成熟，本地运行大模型，已经从早期的“极客尝鲜”，演进为一种可以在真实项目中落地的工程方案。这篇文章，我们就来完整走一遍：如何使用 LangChain，基于最新 Runnable API，调用本地启动的 Ollama 模型，构建一个真正可用的本地大模型应用。一、为什么选择 LangChain + Ollama？先给结论：Ollama 解决“模型怎么跑”，LangChain 解决“能力怎么用”。这是目前本地大模型场景中，最自然、最稳定的一种组合方式。1️⃣ Ollama：本地大模型的“Docker”你可以把 Ollama 理解为：专门为大模型设计的一层运行时基础设施。它解决的问题非常聚焦：统一模型的下载、管理与启动对外提供标准化 HTTP API（默认端口 11434）支持 LLaMA、Qwen、Mistral、DeepSeek 等主流模型Mac / Linux / Windows 全平台可用天然适合 Docker / 私有化部署一句话总结：Ollama 把“跑模型”这件事，做成了基础设施能力。2️⃣ LangChain：AI 应用的“控制中心”如果你只是想“问一句、回一句”，直接调 Ollama API 当然也没问题。但一旦进入真实工程场景，需求会迅速复杂化：Prompt 如何复用、版本化？对话上下文如何管理？如何组合多步推理？后续怎么接 RAG、Agent、工具调用？这些正是 LangChain 擅长的事情：Prompt 模板与结构化输入Runnable / LCEL 编排能力对话历史（Memory）管理Tool、RAG、Agent 的统一抽象可自然演进到 LangGraph所以一个非常自然的分工是：LangChain 负责“编排与逻辑”，Ollama 负责“模型与算力”。二、准备工作：本地启动 Ollama 模型1️⃣ 使用 Docker 部署 Ollama（推荐）docker run \ -d \ --restart=always \ --name ollama \ --gpus=all \ -p 11434:11434 \ -v /home/data/ollama:/root/.ollama \ ollama/ollama如果你对部署细节感兴趣，可以参考我之前的文章：《如何使用 Ollama 打造你的本地 AI 助手》《为本地部署的大模型添加 API Key 认证：Nginx 实现方案》2️⃣ 拉取并运行模型以 qwen3:8b 为例：ollama pull qwen3:8b简单测试：ollama run qwen3:8b如果可以正常对话，说明模型已经在本地成功运行。三、LangChain 接入本地 Ollama（OpenAI 协议）接下来进入核心部分：如何用 LangChain 调用本地 Ollama？1️⃣ 安装依赖pip install langchain langchain-openai这里我们使用 OpenAI 兼容协议，这是目前最稳定、生态最完整的一种方式。2️⃣ 创建 Ollama LLM（ChatOpenAI）from langchain_openai import ChatOpenAI llm = ChatOpenAI( name="ollama-ai", model="qwen3:8b", base_url="http://localhost:11434/v1", api_key="your api key", temperature=0.7, timeout=300, )几个关键点说明：model 必须与 Ollama 中的模型名称一致base_url 指向 Ollama，并注意使用 /v1 后缀这里使用的是 OpenAI 标准协议，不是 Ollama 私有 API3️⃣ 最简单的一次调用response = llm.invoke("用一句话解释什么是 LangChain") print(response)到这里，你已经完成了：LangChain → 本地 Ollama → 本地大模型这条完整调用链。四、进阶用法：Prompt + Runnable（LCEL）在真实项目中，几乎不会直接“裸调”模型。1️⃣ PromptTemplatefrom langchain_core.prompts import PromptTemplate prompt = PromptTemplate( input_variables=["question"], template="你是一个资深后端工…

智能体来了：从 0 到 1：智能体应用的搭建
type: item
date: 2026-01-30T19:56:36+08:00
description: 摘要随着 2026 AI 元年智能体规模化落地趋势的凸显，从 0 到 1 搭建适配场景的智能体应用成为企业与开发者的核心需求。本文聚焦智能体应用搭建的全流程，明确以“感知-决策-执行”闭环为核心的搭建逻辑，系统拆解需求定位、技术选型、模块构建、测试迭代四大核心步骤，梳理数据安全、成本控制、人机协同等关键注意事项，为不同场景下的智能体搭建提供可落地的实操指南，助力实现技术能力与场景需求的精准匹配。目录一、搭建核心逻辑：以场景为锚点，构建闭环能力二、全流程搭建步骤：从需求到落地的四阶段拆解2.1 需求拆解与场景定位2.2 技术选型与框架选择2.3 核心功能模块搭建2.4 测试验证与迭代优化三、关键注意事项：保障搭建质量与落地效果3.1 数据安全与合规管控3.2 成本适配与轻量化部署3.3 人机协同边界的明确四、智能体应用搭建 QA 问答五、结语六、参考文献一、搭建核心逻辑：以场景为锚点，构建闭环能力从 0 到 1 搭建智能体应用，核心逻辑是围绕具体场景需求，构建“感知-决策-执行-优化”的完整能力闭环，而非单纯堆砌技术模块。这一逻辑的核心是“场景适配优先”——智能体的价值最终体现在对具体场景的赋能效果上，因此搭建全流程需以场景痛点为锚点，确保每一步构建都服务于问题解决。从本质来看，智能体应用搭建的核心价值在于打破传统 AI 工具的功能局限：通过整合感知、决策、执行能力，让智能体从“被动响应工具”升级为“主动解决问题的数字助手”，既降低人工干预的频次与成本，又能实现技术能力在同类场景中的规模化复用，为企业智能化转型提供轻量化、可落地的解决方案。二、全流程搭建步骤：从需求到落地的四阶段拆解智能体应用搭建需遵循“需求-技术-构建-验证”的线性逻辑，拆解为四大核心阶段，确保每一步衔接顺畅、目标明确，避免因流程缺失导致落地失败。2.1 需求拆解与场景定位需求拆解与场景定位是搭建的基础，直接决定后续技术选型与模块设计的方向，核心要完成“目标明确-流程梳理-边界界定”三件事。首先，明确核心应用目标：需精准定位智能体的核心功能，例如客户服务场景的“7×24 小时问答与问题闭环”、工业场景的“设备故障预测与维护提醒”，避免功能泛化导致资源浪费。其次，梳理场景全流程：拆解目标场景中的核心环节与关键节点，例如“用户咨询-需求识别-数据检索-答案生成-反馈收集”，明确智能体的输入（如用户指令、设备数据）、输出（如回答内容、维护指令）及各环节的触发条件。最后，界定能力边界：明确智能体可自主完成的任务与需人工介入的场景，例如复杂问题的转接、高风险决策的审核，避免因能力边界模糊导致用户体验下降。2.2 技术选型与框架选择技术选型需遵循“适配性优先、低成本起步”原则，核心围绕“框架-数据-算力”三大核心要素展开。在框架选择上，优先选用支持多工具联动、可扩展性强的开源框架，例如 LangChain、AutoGPT 适合文本类智能体搭建，AgentGPT 适合轻量化场景快速落地，工业智能体可选择适配工业协议的专用框架，降低开发门槛与后续迭代成本。在数据准备上，需搭建“采集-存储-预处理”全链路模块：采集场景相关的结构化（如用户画像、设备参数）与非结构化数据（如文本咨询、设备图像），选择安全合规的存储方案（如企业私有云、加密数据库），通过数据清洗、标注、脱敏等预处理，提升数据质量。在算力配置上，根据场景需求灵活选择部署方式：轻量化场景（如小型客服智能体）可采用云服务器按需付费；复杂场景（如多模态工业智能体）可结合本地算力与边缘计算，平衡性能与成本。2.3 核心功能模块搭建核心功能模块搭建需围绕“感知-决策-执行”闭环展开，三大模块相互联动，构成智能体的核心能力。感知模块负责“信息输入与解析”，需支持多类型信息接收，例如文本、语音、图像、传感器数据等，通过 OCR 识别、语音转文字、多模态语义理解等技术，实现信息的精准提取与意图识别，为后续决策提供基础。决策模块是智能体的“核心大脑”，需结合规则引擎与大模型能力：规则引擎用于处理明确的标准化场景（如固定流程的业务办理），大模型用于处理复杂的非标准化场景（如模糊需求解读、多路径选择），通过两者协同实现自主决策，例如根据用户咨询意图匹配对应的服务流程。执行模块负责“动作落地”，需对接场景相关的工具与系统，例如客服智能体对接 CRM 系统实现客户信息调取，工业智能体对接 MES 系统下发维护指令，通过标准化接口确保指令精准执行，同时反馈执行结果。2.4 测试验证与迭代优化测试验证与迭代优化是确保智能体落地效果的关键，需分阶段开展“功能-性能-场景”全维度测试。功能测试阶段，模拟真实场景下的各类输入，验证智能体的响应准确性、流程完整性，例如客服智能体测试不同咨询问题的解答准确率，工业智能体测试设备数据异常的识别精度，排查功能漏洞…

为问答 Agent 添加短期记忆（ConversationBufferMemory）
type: item
date: 2026-01-29T17:04:56+08:00
description: 在构建问答Agent时，多轮对话的上下文记忆是核心需求——让Agent能记住历史对话内容，结合「历史问题+历史回答+当前问题」给出连贯回复，而非孤立回答每个问题。LangChain中的ConversationBufferMemory是轻量、易用的短期记忆组件，核心作用是按顺序缓存对话历史，并将历史内容注入到模型的输入提示中，实现问答Agent的短期记忆能力，适合中小长度的多轮对话场景。本文将基于LangChain框架，从核心原理、完整可运行代码、关键细节、进阶优化四个维度，教你为问答Agent集成ConversationBufferMemory，支持OpenAI/国产大模型（通义千问/文心一言），代码可直接复用。一、核心概念铺垫1.1 ConversationBufferMemory 核心作用以键值对形式按时间顺序存储对话历史（问题+回答）；支持将对话历史格式化为字符串/消息对象，注入到LLM的输入提示中；提供清空记忆、获取记忆、修改记忆的便捷方法；轻量无依赖，无需额外存储，对话历史保存在内存中（会话结束即销毁，符合「短期记忆」定位）。1.2 核心搭配ConversationBufferMemory通常与ConversationChain（通用对话链）/RetrievalQA（知识库问答链）搭配使用，本文先实现基础问答Agent（基于ConversationChain），后续补充带知识库的问答Agent优化方案。1.3 关键参数参数名作用常用值memory_key记忆在提示模板中的变量名（需与提示模板一致）chat_history（推荐）return_messages记忆返回格式：True返回消息对象（HumanMessage/AIMessage），False返回拼接字符串False（基础场景）/True（复杂场景）input_key输入问题的变量名input（默认，无需修改）output_key输出回答的变量名output（默认，无需修改）二、环境准备安装LangChain核心依赖+大模型适配依赖（以OpenAI/通义千问为例，二选一即可）：# 核心依赖：LangChain核心+社区组件 pip install langchain-core langchain-community -i https://pypi.tuna.tsinghua.edu.cn/simple # 可选1：OpenAI模型依赖（GPT-3.5/GPT-4） pip install langchain-openai -i https://pypi.tuna.tsinghua.edu.cn/simple # 可选2：国产大模型依赖（通义千问/文心一言/智谱清言） pip install langchain-qianfan langchain-dashscope -i https://pypi.tuna.tsinghua.edu.cn/simple三、完整实现：基础问答Agent+短期记忆3.1 方案1：基于OpenAI模型（GPT-3.5/GPT-4）# 1. 导入核心模块 from langchain_openai import ChatOpenAI from langchain.chains import ConversationChain from langchain.memory import ConversationBufferMemory from langchain.prompts import PromptTemplate import os # 2. 配置环境（OpenAI API密钥） # 国内用户需配置代理：os.environ["HTTP_PROXY"] = "http://127.0.0.1:7890" os.environ["OPENAI_API_KEY"] = "你的OpenAI API密钥" # 3. 初始化LLM模型 llm = ChatOpenAI( model="gpt-3.5-turbo", # 推荐gpt-3.5-turbo，性价比高 temperature=0.1, # 越低回答越稳定，适合问答场景 max_tokens=2048 ) # 4. 初始化ConversationBufferMemory（核心：短期记忆） memory = ConversationBufferMemory( memory_key="chat_history", # 记忆变量名，需与提示模板中的{chat_history}一致 return_messages=False, # 返回字符串格式的对话历史，适合基础场景 input_key="input" # 输入问题的变量名，默认input即可 ) # 5. 自定义带记忆的提示模板（必须包…

狂收 26k+ star！全网精选的 Skills 一网打尽！！
type: item
date: 2026-01-29T11:50:04+08:00
description: 大家好，我是R哥。最近 Agent Skills 大火了，大家都在用 Skills 提升效率，很多 MCP 的功能已经被 Skills 代替了，MCP 已经失去了当初的光芒。在《Claude Skills 彻底爆了，从实现原理到 Claude Code、CodeX、OpenCode 实战，一网打尽！》这篇文章中，我介绍了 Skills 的原理、创建及使用，今天我再来详细分享下市面上的 Skills。现在市面上充斥着各种 Skills 导航站，GitHub 上各种 Skills 仓库也是层出不穷，功能也是五花八门。最近我就在 GitHub 上发现了一个非常不错的 Skills 仓库：Awesome Claude Skills，地址如下：https://github.com/ComposioHQ/awesome-claude-skills目前该仓库已经狂收 26000+ 个 Star，收集了目前市面上主流的 Claude Skills，分类非常详细，涵盖了文档处理、开发与代码工具、数据与分析、商业与营销、沟通与写作、创意与媒体、效率与组织、协作与项目管理、安全与系统等多个方面。我整理并翻译了该仓库的完整内容，大家可以收藏一下。Awesome Claude Skills文档处理Skill作用地址docx用追踪修改、批注和格式化功能，轻松创建、编辑和分析 Word 文档。https://github.com/anthropics/skills/tree/main/skills/docxpdf提取文本、表格、元数据，合并与标注 PDF 文件。https://github.com/anthropics/skills/tree/main/skills/pdfpptx读取、生成和调整幻灯片、布局与模板。https://github.com/anthropics/skills/tree/main/skills/pptxxlsx电子表格操作：公式、图表、数据转换。https://github.com/anthropics/skills/tree/main/skills/xlsxMarkdown to EPUB Converter将 Markdown 文档和聊天摘要转换为专业的 EPUB 电子书文件。https://github.com/smerchek/claude-epub-skill开发与代码工具Skill作用地址artifacts-builder一套利用现代前端 Web 技术（如 React、Tailwind CSS、shadcn/ui）构建复杂多组件 Claude.ai HTML 资产的工具集。https://github.com/anthropics/skills/tree/main/skills/web-artifacts-builderaws-skills结合 CDK 最佳实践的 AWS 开发，包含成本优化的 MCP 服务器和无服务器/事件驱动架构模式。https://github.com/zxkane/aws-skillsChangelog Generator通过分析 Git 提交历史，自动将技术性提交转换为用户友好的发布说明，生成面向用户的变更日志。https://github.com/ComposioHQ/awesome-claude-skills/blob/master/changelog-generatorClaude Code Terminal Title给每个 Claude-Code 终端窗口动态设置标题，清晰展示当前正在执行的任务，再也不用担心搞混哪个窗口在干啥了。https://github.com/bluzername/claude-code-terminal-titleD3.js Visualization教会 Claude 生成 D3 图表和交互式数据可视化。https://github.com/chrisvoncsefalvay/claude-d3js-skillFFUF Web Fuzzing集成 ffuf 网络模糊测试工具，让 Claude 能执行模糊测试并分析漏洞结果。https://github.com/jthack/ffuf_claude_skillfinishing-a-development-branch通过清晰的选项引导开发任务的收尾，并处理选定的工作流程。https://github.com/obra/superpowers/tree/main/skills/finishing-a-development-branchiOS Simulator让 Claude 能够与 iOS 模拟器交互，方便测试和调试 iOS 应用。https://github.com/conorluddy/ios-si…

循序渐进：构建 AI 智能体（Agent）前需要了解的基础概念
type: item
date: 2026-01-27T09:31:36+08:00
description: 在 AI 技术日新月异的今天，AI Agent（智能体）正逐渐从概念走向落地。它不仅能进行对话，更具备了思考、规划和执行任务的能力。然而，构建一个成熟的 Agent 系统，并非简单的 API 调用，而是多种核心技术协同工作的结果。在深入开发之前，理清这些基础概念，有助于我们更好地理解 AI 系统的底层运行逻辑。一、 智能的内核：大语言模型与交互边界1. LLM（大语言模型）：通识大脑LLM 是 Agent 的核心引擎。它拥有强大的语言理解能力，但它是一个“静态大脑”，其知识停留在训练截止的那一刻，无法感知企业内部的私有数据。2. Context Window（上下文窗口）：短期记忆这是模型单次交互能处理的信息上限。局限： 即使窗口再大，也不能盲目塞入所有数据。正如在数学题中加入无关的干扰信息会降低准确率一样，过长的背景会导致模型“注意力不集中”，甚至产生幻觉。3. Prompt Engineering（提示工程）：沟通的艺术Zero-shot（零样本）： 不给示例，直接下指令。这要求指令必须高度具体（如：从“写个政策”优化为“写个 200 字符合 GDPR 标准的隐私政策”）。Few-shot（少样本）： 提供几个理想的问答示例，这能有效地规范 AI 输出的语气（Tone）和特定格式。Chain of Thought（思维链）： 引导 AI 展示推理步骤，强制模型分配更多计算资源在逻辑推导上，从而处理复杂问题。二、 知识的扩展：从“翻书”到“记忆”为了让 AI 访问私有数据，我们需要构建一套“外挂硬盘”。4. 向量数据库 vs 传统数据库传统的 SQL 数据库是基于值或关键词的匹配（如 LIKE %vacation%）。而向量数据库（如 ChromaDB, Pinecone）则是基于含义（Meaning）的匹配。即使搜索词不一致，只要语义接近，系统就能精准定位。5. Embeddings 与数据预处理数据切分（Chunking）： 我们不能将 500GB 的文档直接塞给 AI。必须将其切成小块。重叠（Overlap）： 在切分时，通常会保留一定的文字重叠。这能防止上下文在切分处丢失，从而大幅提升检索的准确性。Embeddings： 将切分好的文本块转化为高维数字向量，让计算机能够以数学方式计算语义的相关性。6. RAG（检索增强生成）：知识的补丁RAG 是目前解决 AI 幻觉的最优方案。它通过“检索 -> 增强 -> 生成”的流程，让 AI 像是在参加开卷考试：先去数据库里“翻书”找到事实，再根据事实组织答案。三、 行动的逻辑：框架、编排与协议7. LangChain：开发的“胶水”层LangChain 是一个强大的抽象层，旨在简化开发流程。核心价值： 它像管道一样将模型、提示词模板和向量库连接起来。有了它，你从 OpenAI 切换到 Google Gemini 可能只需要更改一行代码，极大地提高了系统的灵活性。8. LangGraph：有状态的“总导演”当任务需要循环和决策时，简单的线性管道就不够用了。节点与边： LangGraph 通过节点（步骤）和边（路径）构建工作流。共享状态（State）： 这是它的核心。它维护着一个在各节点间传递的“字典”，记录着当前的文档、评分等信息。基于这个状态，系统可以执行复杂逻辑：例如“如果合规分数低于 75 分，则循环回退到搜索节点重新查阅”。9. MCP（模型上下文协议）：标准化的“USB 接口”这是连接外部工具（如 GitHub、数据库）的通用标准。它让 AI 具备了“即插即用”的能力，开发者无需为每个工具编写特定的硬编码集成，只需符合 MCP 协议，Agent 就能自主调用。四、 总结：各组件是如何协同工作的？构建一个完整的 AI 系统，本质上是让这些组件各司其职、形成闭环：准备： 文档经过切分与重叠处理，通过 Embeddings 存入向量数据库。触发： 用户提问，LangChain 调度 RAG 流程，根据语义意图找回知识。决策： LangGraph 根据当前状态判断：是直接回答，还是需要循环修正？执行： 如果需要实时数据，通过 MCP 协议调用外部工具。产出： LLM 结合所有事实与逻辑推理，输出最终方案。理清了这些基石，你就已经掌握了从“对话机器人”跨越到“全能 Agent”的底层蓝图。本文由mdnice多平台发布

深度实例分析：攻防视角下的AI框架组件中的注入漏洞
type: item
date: 2026-01-24T19:48:06+08:00
description: 深度实例分析：攻防视角下的AI框架组件中的注入漏洞在从事了一段时间对AI框架组件的安全审计研究后，也挖掘到了很多相似的注入漏洞RCE，对于目前的AI框架组件（PandasAI，LlamaIndx，Langchain...）对于该类型漏洞的通病结合实战实例以及学术界的研究做了系统性的归纳，站在AI框架的顶层角度对该类AI框架组件中的注入漏洞进行研究分析，供师傅们交流指点...1 漏洞根源传统的注入攻击本质上是攻击者通过操纵结构化查询语言的语法和语义来实现恶意操作。这种攻击依赖于输入验证的缺失，导致用户输入直接拼接到预定义的SQL语句中，形成无效或恶意查询，从而绕过授权、泄露数据或执行系统命令。然而，在AI集成框架（如LangChain、LlamaIndex、PandasAI）中的RCE漏洞，则源于一个更复杂的动态过程：Natural Language向Untrusted Code的转化过程中的逻辑失控。这种失控不是简单的语法操纵，而是源于AI系统的“意图推断”和“代码生成”机制的固有不确定性，导致从人类可读的prompt到可执行Python代码的“黑箱”转化中，安全边界被模糊化。2 AI应用框架执行流程一个典型的AI框架集成应用执行流如下： 用户通过自然语言接口（如Web聊天框或API端点）提交查询提示（Prompt），这个提示通常封装为一个结构化的输入 框架（如LangChain、LlamaIndex或PandasAI）接收此输入后，会在系统提示（System Prompt）指导下调用LLM模型（如OpenAI的GPT系列），系统提示旨在强化安全边界，例如“仅生成安全的Pandas代码，不要执行系统命令”。LLM基于其训练数据和概率分布，生成一个中间输出——通常是伪代码或自然语言描述的代码片段 框架的解析器（Parser）将此输出转化为可执行的Python代码字符串 最后在执行阶段，框架依赖动态解释器（如exec()或eval()）在受限命名空间中运行此代码，捕获stdout或返回值作为观察结果 3 注入RCE漏洞主要分布3.1 Data Analysis Agents这类接口是目前RCE漏洞最密集的区域。以create_pandas_dataframe_agent或SQLAgent为代表，其核心逻辑是利用LLM的编程能力来处理结构化数据。开发者通常为LLM提供一个功能完备的Python运行环境，并预装Pandas、Numpy等库，意图让LLM通过编写数据清洗或统计代码来回答用户问题。然而，从攻防视角看，这本质上构建了一个 “自然语言控制的动态脚本生成器” 。由于框架底层往往直接调用exec()或eval()来运行LLM生成的代码，攻击者只需通过Prompt Hijacking，诱导LLM在生成的脚本中插入os.system或subprocess指令，即可绕过数据分析的初衷，直接在宿主机上执行任意系统命令。import pandas as pd import os from typing import Any def execute_llm_generated_code(code_string: str, dataframe: pd.DataFrame) -> Any: # 框架中会注入dataframe到本地作用域，这里简化 local_vars = {'df': dataframe, 'pd': pd, 'np': __import__('numpy')} exec(code_string, {}, local_vars) # 假设LLM生成了一个返回结果的变量 if 'result' in local_vars: return local_vars['result'] return None execute_llm_generated_code(malicious_code, df) if os.path.exists("/tmp/rce_proof.txt"): with open("/tmp/rce_proof.txt", "r") as f: print(f"RCE 验证文件内容 3.2 REPL Tools为了赋予Ai应用解决复杂逻辑（如数学运算、逻辑推理）的能力，许多框架内置了交互式解释器工具（如Python REPL、Shell Tool）。这些工具被设计为框架的“插件”或“技能”，允许代理（Agent）在发现自身能力不足时自动调用。风险在于这些执行器的“默认高权限”与“缺乏沙箱化”。在许多开源实现中，代码执行器并未在受限的容器环境中运行，而是直接继承了应用主进程的权限。这意味着，一旦LLM被恶意提示词引导进入“代码编写模式”，它所产生的代码将直接在服务器后端运行。import subprocess impo…

Ai安全漏洞剖析-CVE-2025-68664
type: item
date: 2026-01-24T19:33:20+08:00
description: 一、漏洞简介CVE编号: CVE-2025-68664漏洞类型: 序列化注入漏洞 (Serialization Injection)CVSS评分: 9.3 (严重)影响组件: LangChain 框架的 dumps() 和 dumpd() 函数漏洞概述：LangChain 是一个用于构建基于ai大语言模型(LLM)应用程序的框架。在受影响版本中，dumps() 和 dumpd() 函数在序列化自由格式字典时，未对包含 "lc" 键的字典进行适当的转义处理。"lc" 键是 LangChain 内部用于标识序列化对象的特殊标记。当用户控制的数据包含此键结构时，在反序列化过程中可能被错误地识别为合法的 LangChain 对象，而非普通用户数据，从而导致序列化注入漏洞。二、影响版本# 受影响版本langchain >= 1.0.0 且 < 1.2.5langchain < 0.3.81### 已修复版本langchain >= 0.3.81langchain >= 1.2.5三、漏洞原理分析3.1 序列化机制分析3.1.1 dumps() 函数实现# langchain_core/load/dump.py3.1.2 dumpd() 函数实现3.2 反序列化机制分析3.2.1 Reviver 类实现# langchain_core/load/load.py关键逻辑:1. Reviver.\_\_call\_\_() 作为 json.loads() 的 object\_hook 被调用2. 对于每个字典，检查是否包含 {"lc": 1} 键3. 如果包含，根据 "type" 字段进行相应处理4. 对于 {"type": "constructor"}，会：- 解析 "id" 获取模块路径和类名- 动态导入模块- 获取类并验证是否为 Serializable 子类- 使用 "kwargs" 实例化对象3.3 漏洞触发流程# 正常流程（预期行为）用户数据字典 → dumps() → JSON字符串 → loads() → 用户数据字典#### 漏洞流程（攻击场景）恶意字典（包含"lc"键） → dumps() → JSON字符串（保留"lc"键）→ loads() → Reviver检查"lc"键 → 误识别为LangChain对象 → 实例化恶意对象3.4 漏洞根源核心问题: dumps() 和 dumpd() 在序列化普通字典时，未对包含 "lc" 键的字典进行转义或标记，导致用户控制的字典在反序列化时被误认为是 LangChain 序列化对象。具体表现:1. 序列化阶段：普通字典中的 "lc" 键被原样保留2. 反序列化阶段：Reviver 仅通过 {"lc": 1} 判断是否为 LangChain 对象，无法区分用户数据和真实序列化对象3.5 攻击向量分析攻击者可以构造如下恶意字典：malicious\_dict = { "lc": 1, "type": "constructor", "id": \["langchain\_core", "messages", "HumanMessage"\], "kwargs": { "content": "恶意内容" } } 当这个字典被 dumps() 序列化后，再通过 loads() 反序列化时：1. Reviver 检测到 {"lc": 1} 和 {"type": "constructor"}2. 解析 "id" 并导入 langchain\_core.messages.HumanMessage3. 使用 "kwargs" 实例化 HumanMessage 对象4. 返回实例化的对象，而非原始字典**潜在风险**:- 如果攻击者能够控制 "id" 字段，可能实例化任意 Serializable 子类- 通过 "kwargs" 可以控制对象初始化参数- 如果后续代码对反序列化对象有特殊处理，可进一步导致其他安全问题四、环境搭建4.1 环境要求- Python 3.8+- pip4.2 安装受影响版本# 安装受影响版本1.x.x（如 1.2.4）pip install langchain==1.2.4 langchain-core==1.2.4# 或者安装其他版本 0.3.x（如0.3.80）pip install langchain=0.3.84.3 验证安装import langchain_coreprint(langchain_core.__version__) # 应显示 1.2.4 或 0.3.80五、漏洞复现5.1 编写脚本``!/usr/bin/env python3"""CVE-2025-68664 漏洞复现脚本演示序列化注入漏洞"""from langchain_core.lo…

LangGraph Server + AsyncPostgresSaver + unicorn 启动
type: item
date: 2026-01-23T18:19:32+08:00
description: 使用 django 的 command 启动 langGraph Server, 但要求基于 AsyncPostgresSaver,没有找到相关的可用的代码, 这里记录下 直接抛出代码""" Run the LangGraph Agent Server """ import asyncio import uvicorn from django.core.management.base import BaseCommand from django.conf import settings from fastapi import FastAPI from fastapi.middleware.cors import CORSMiddleware from langserve import add_routes from langchain_core.globals import set_verbose from psycopg_pool import AsyncConnectionPool from langgraph.checkpoint.postgres.aio import AsyncPostgresSaver from apps.ai.graph.app import AsyncGraphApp class Command(BaseCommand): """ Run the LangGraph Agent Server """ help = "Starts the LangGraph Agent Server" def add_arguments(self, parser): parser.add_argument("--host", type=str, default="0.0.0.0") parser.add_argument("--port", type=int, default=2028) def handle(self, *args, **options): asyncio.run(self.handle_async(*args, **options)) async def handle_async(self, *args, **options): """启动 Agent Server""" host = options["host"] port = options["port"] self.stdout.write(f"Starting Agent Server at http://{host}:{port}...") # Get the LangGraph application checkpointer = await self.get_checkpointer() graph_app = AsyncGraphApp().compile(checkpointer=checkpointer).app print(f"graph_app----------------->: {graph_app}") # Initialize FastAPI app app = FastAPI( title="Baby Consultant Agent", version="1.0", description="A LangGraph-based agent for baby consultation", ) # Set CORS app.add_middleware( CORSMiddleware, allow_origins=["*"], allow_credentials=True, allow_methods=["*"], allow_headers=["*"], ) set_verbose(True) # Add routes using LangServe # This exposes the graph at /agent/invoke, /agent/stream, etc. add_routes( app, graph_app, path="/agent", ) # Run with Uvicorn config = uvicorn.Config(app, host=host, port=port) # 基于当前的Async Running Loop 启动unicorn server = uvicorn.Server(config) await server.serve() async def get_checkpointer(self): """获取 Checkpointer""" # 1. 显式创建连接池 (让它在应用生命周期内一直存活) connection_kwargs = { "autocommit…