ChatGPT 和 GPT-4 的成功表明,通过强化训练的大型语言模型可以产生可扩展且强大的 NLP 应用程序。
但是,响应的有用性取决于提示,这导致用户探索提示工程空间。此外,大多数现实世界的 NLP 用例需要比单个 ChatGPT 会话更复杂。这就是像LangChain这样的库可以提供帮助的地方!
LangChain 是一个 Python 库,可帮助您利用大型语言模型来构建自定义 NLP 应用程序。
在本指南中,我们将探讨LangChain是什么以及您可以使用它构建什么。我们还将通过使用LangChain构建一个简单的问答应用程序来弄湿我们的脚。
让我们开始吧!
什么是LangChain?
LangChain 由 Harrison Chase 创建,是一个 Python 库,它为使用 LLM 构建 NLP 应用程序提供开箱即用的支持。您可以连接到各种数据和计算源,并构建在特定于域的数据源、私有存储库等上执行 NLP 任务的应用程序。
您可以使用LangChain构建的有趣应用程序包括(但不限于):
1, LangChain模块概述
接下来,让我们来看看LangChain中的一些模块:

语言大模型LLM
LLM 是 LangChain 的基本组件。它本质上是大型语言模型的包装器,有助于使用特定大型语言模型的功能和能力。
链Chains
如前所述,LLM 是 LangChain 中的基本单元。但是,正如名称LangChain所暗示的那样,您可以根据特定任务将LLM调用链接在一起。
例如,您可能需要从特定 URL 获取数据,汇总返回的文本,并使用生成的摘要回答问题。
链条也可以很简单。您可能需要读入用户输入,然后使用该输入来构造提示。然后可用于生成响应。

提示词Prompts
提示是任何 NLP 应用程序的核心。即使在 ChatGPT 会话中,答案也只与提示一样有用。为此,LangChain提供了提示模板,您可以使用这些模板来格式化输入和许多其他实用程序。
文档加载程序和实用程序
LangChain的Document Loaders和Utils模块分别有助于连接到数据源和计算源。
假设您有一个大型经济学文本语料库,您想在上面构建一个 NLP 应用程序。您的语料库可能是文本文件、PDF 文档、HTML 网页、图像等的混合体。目前,文档加载器利用 Python 库非结构化将这些原始数据源转换为可处理的文本。
utils 模块提供 Bash 和 Python 解释器会话等。这些适用于有助于直接与底层系统交互的应用程序。或者,当我们需要代码片段来计算特定的数学量或解决问题而不是计算一次答案时。
智能体Agent
我们提到过,“链”可以帮助将一系列 LLM 调用链接在一起。但是,在某些任务中,调用的顺序通常不是确定性的。下一步可能取决于用户输入和前面步骤中的响应。
对于此类应用程序,LangChain库提供了“智能体”,这些代理可以根据沿途的输入而不是硬编码的确定性序列来执行操作。
除此之外,LangChain还提供与向量数据库的集成,并具有用于维护LLM调用之间状态的内存功能,等等。
2, 使用LangChain构建问答应用程序
现在我们已经了解了LangChain,让我们通过五个简单的步骤使用LangChain构建一个问答应用程序:
第 1 步 – 设置开发环境
在开始编码之前,让我们先设置开发环境。我假设您的工作环境中已经安装了 Python。
您现在可以使用 pip 安装 LangChain 库:
pip install langchain
由于我们将使用 OpenAI 的语言模型,因此我们还需要安装 OpenAI SDK:
第 2 步 – 将OPENAI_API_KEY设置为环境变量
接下来,登录您的 OpenAI 帐户。导航到帐户设置>查看 API 密钥。生成密钥并复制它。
在 Python 脚本中,使用 os 模块并点击环境变量字典 。将“OPENAI_API_KEY”设置为您刚刚复制的密钥:os.environ
第 3 步 – 使用 LangChain 进行简单的 LLM 调用
现在我们已经安装了所需的库,让我们看看如何使用 LangChain 进行简单的 LLM 调用。
为此,让我们导入 OpenAI 包装器。在此示例中,我们将使用 text-davinci-003 模型:
让我们定义一个问题字符串并生成一个响应:
It is difficult to predict which programming language will be the most popular in 2023. However, the most popular programming languages today are JavaScript, Python, Java, C++, and C#, so these are likely to remain popular for the foreseeable future. Additionally, newer languages such as Rust, Go, and TypeScript are gaining traction and could become popular choices in the future.
第 4 步 – 创建提示模板
让我们在学习一门新编程语言的顶级资源上再问一个问题,比如说 Golang:
虽然这对初学者来说效果很好,但当我们试图策划一个资源列表来学习编程语言和技术堆栈列表时,它很快就会变得重复。
这就是提示模板派上用场的地方。您可以创建可以使用一个或多个输入变量设置格式的模板。
我们可以创建一个简单的模板来获取前 k 个资源来学习任何技术堆栈。在这里,我们使用 and 作为:kthisinput_variables
第 5 步 – 运行我们的第一个 LLM 链
我们现在有一个 LLM 和一个提示模板,我们可以在多个 LLM 调用中重用它们。
让我们继续创建一个 LLMChain:
您现在可以将输入作为字典传入并运行 LLM 链,如下所示:
总结
这就结束了!您知道如何使用 LangChain 构建一个简单的问答应用程序。我希望你已经对LangChain的功能有了初步的了解。下一步,尝试探索LangChain以构建更多有趣的应用程序。祝您编码愉快!
文章来源:wearefram.com

12 天前
未来打通3D视觉表现和结构设计,可实现真正的高精可视化工业数字孪生。

16 天前
AI 智能体的技能包管理器

3 个月前
AI 研发已从单点 Prompt 优化迭代至Harness 工程底座 + Loop 自治闭环 + SDD 标准化规范的三位一体体系,通过重构人机协作模式,解决大模型落地不稳定、难规模化的痛点,实现企业级 AI 从原型试用走向工程化、自动化、体系化落地。

3 个月前
WorkBuddy有望拿下国内独立桌面自动化办公智能体细分第一。但受企业协同生态、移动端能力等短板限制,无法成为全域企业及全球办公AI赛道第一名,将与钉钉悟空、WPS AI形成差异化竞争格局。

3 个月前
OpenClaw工具与生态完整生命周期判断 本文尝试分短期、中期、长期三段,结合项目现状、风险、护城河客观测算OpenClaw这款智能体工具或者相似工具的发展趋势。 一、短期生命力(1~3年,2026–2029):完全安全、高速增长,是黄金运营窗口期 支撑理由 赛道刚需独一无二,差异化壁垒极强 OpenClaw是极少数本地系统级执行、模型无关、纯自托管的终端Agent运行框架,定位“能操作电脑文件、软件、桌面的AI助手”,区别于LangGraph/CrewAI这类后端开发框架、AutoGPT纯实验型智能体。普通办公、个人自动化、小微企业没有替代同类成熟开源工具,C端+中小企业需求持续释放。 社区与生态飞轮已经跑通 GitHub 30万+星标、近千名全球持续贡献者,日均数百条PR/Issue迭代,更新频率行业第一;创始人Peter全职维护,大厂(英伟达、Kimi、MiniMax)主动适配接入; ClawHub官方技能仓库沉淀数千标准化Skill,国内衍生生态(xia345、各类中文技能站、私有化二次改版)持续扩容,形成标准锁定; MIT宽松开源协议,允许企业二次改造、搭建托管服务,大量服务商入局完善配套生态(部署、安全加固、私有化定制)。 行业周期红利:本地终端Agent处于普及早期 2026被行业定义为桌面Agent落地元年,云端大模型成本持续下行、本地Ollama离线模型普及,完美匹配OpenClaw“本地优先”架构;未来3年,个人自动化、企业内网办公自动化需求只会扩张。 短期仅有的可控风险 Token调用成本偏高、频繁更新易出现版本兼容bug、本地高权限带来安全隐患; 以上问题官方正在持续迭代修复,企业级备份、权限沙箱、日志审计功能已逐步补齐,属于可优化痛点,不会动摇存续根基。 结论:未来1–3年是生态最繁荣、流量最大、变现最顺畅的阶段。 二、中期生命力(3~7年,2029–2033):稳定存续,但竞争加剧、增速放缓 存续核心逻辑 标准化生态具备长期锁定效应 SKILL.md、ClawHub统一技能规范、openclaw CLI命令行已经形成行业事实标准。就算出现竞品,开发者、存量数万套技能、企业定制项目迁移成本极高,生态不会短时间崩塌,会维持稳定使用人群。 分层商业模式支撑项目持续维护 原生项目开源免费,但周边商业化闭环成型:企业私有化部署服务、安全审计、托管云服务、垂直行业技能付费、模型渠道分销,持续产生现金流反哺社区开发,不会出现“没人维护停更”的局面。 使用人群分层留存 C端极客、办公自动化爱好者会长期使用; 中小企业内网自动化、数据处理场景高度依赖本地执行Agent,大厂SaaS Agent无法满足内网隐私需求; 开发者持续基于OpenClaw做二次分支、私有化改版,衍生生态会持续分流、延续整个“龙虾生态”的热度。 中期衰减变量(会降低增速,但不会淘汰项目) 微软、苹果、国产操作系统推出原生系统级AI助手,抢占普通小白用户; 新轻量化终端Agent开源框架分流开发者; 各国监管对本地高权限AI自动化工具出台更严格合规要求,提高企业落地门槛; 结论:3–7年不会消亡,但行业从爆发期进入存量竞争,流量红利收窄,平台需要深耕私有化、企业定制、垂直细分赛道才能持续盈利。 三、长期生命力(7年以上,2033之后):分两种极端走向 走向1:长期持续存活(概率60%),变成基础设施级工具 如果行业发展符合以下趋势,OpenClaw会像现在的Python、Git一样长期存续: 终端自主Agent成为电脑标配生产力工具,本地执行、离线隐私是永久刚需; OpenClaw持续完成企业级、合规化改造,成为政企内网自动化标准选型; 社区形成基金会/商业公司承接维护,摆脱单一创始人依赖,实现长久开源运营。 走向2:逐步边缘化、被新一代架构替代(概率40%) 触发条件: 操作系统底层内置标准化Agent执行层,统一API,第三方独立运行框架失去生存空间; 多模态、具身智能技术迭代,全新架构完全替代“技能+本地脚本执行”模式; 全球监管全面限制本地高权限自主AI工具,商用落地基本锁死,仅小众极客圈子留存。 即便被边缘化,存量存量技能、配套站点、私有部署项目仍会维持5–10年长尾生命周期,不会瞬间彻底消失。 四、关键风险:会大幅缩短生命周期的致命隐患 安全重大事故 若出现大规模Skill供应链投毒、批量本地数据泄露事件,企业端市场会快速萎缩,仅保留个人玩家生态;官方正在完善自动病毒扫描、技能审核机制,风险持续降低。 创始人断更、无承接主体 当前项目由Peter单人主导,若后续精力转移、无商业公司接手维护,迭代速度断崖式下滑,竞争力快速落后竞品;目前已有多家AI服务商、模型厂商深度合作,存在接手预期。 算力成本长期居高不下 如果大模型API按量价格无法大幅下降,普通用户长期使用成本过高,会劝退大众用户,仅留存企业付费群体。 国内政策监管收紧 国内针对本地自主自动化工具出台限制,国内衍生生态、配套导航平台流量大幅下滑,但海外生态不受影响。 五、综合最终总结 0–3年(黄金期):放心投入建站、填充内容、运营变现,生态高速扩张,流量红利充足; 3–7年(平稳期):生态稳定存在,竞争变多,需要走差异化(私有化、离线、海外双语)路线维持竞争力; 7年以上(分化期):要么成为长期基础设施永续存在,要么逐步小众长尾,即便衰退也有数年缓冲时间; 整体安全底线:至少拥有5年以上稳定商业运营周期,足够覆盖站点开发、回本、盈利完整周期;中长期只要避开通用综合赛道,主打本地离线私有化细分,生命周期会进一步拉长。

5 个月前
马斯克旗下 xAI 静默上线 Grok 4.3,API 价格下调约 60%,引发行业连锁降价,大模型商业化进入 “低价普惠” 阶段。

7 个月前
OpenClaw 本质是“开发者基础设施”,而非面向大众的 SaaS 产品。

8 个月前
用 OpenClaw 搭建一个本地 Agent 中枢(完整方案) 不是再做一个 ChatGPT,而是建立一个真正“可控、可组合、可扩展”的本地 AI Agent 中枢。 当越来越多团队开始意识到: 云端 LLM 成本不可控 数据隐私存在风险 单一 Agent 无法解决真实业务 “本地 Agent 中枢” 正在成为一个更现实的选择。 本文将完整讲清楚: ? 如何用 OpenClaw 搭建一个真正可用的本地 Agent 中枢 ? 它适合谁,不适合谁 ? 与 LangGraph / CrewAI 的核心差异 什么是「本地 Agent 中枢」? 先明确一个概念,避免误解。 ❌ 不是: 一个本地 ChatGPT 一个简单的 Prompt 管理器 ✅ 而是: 一个能够统一管理多个 Agent、模型、工具和任务流程的本地系统 一个合格的本地 Agent 中枢,至少要解决 5 件事: 多 Agent 协作(不是单轮对话) 任务调度与状态管理 模型可替换(本地 / API) 工具调用(搜索、代码、文件等) 可长期运行、可追溯 OpenClaw 的定位,正是这个“中枢层”。 为什么选择 OpenClaw? 在进入部署前,必须先回答一个现实问题: 为什么不是 LangGraph / CrewAI / AutoGen? 简要结论(非常重要) 框架 更适合 LangGraph 开发者写 Agent 流程 CrewAI 小规模角色协作 AutoGen 对话驱动实验 OpenClaw 长期运行的 Agent 中枢 OpenClaw 的核心优势 1️⃣ 架构清晰,不是“脚本拼装” 有明确的 Agent 管理层 有任务执行与状态机制 不是写完一次就丢的 Demo 2️⃣ 原生支持多模型策略 本地模型 云 API fallback / 优先级策略 3️⃣ 更接近“生产环境思维” 可持续运行 可复用 Agent 可演进 如果你的目标是: “做一个长期使用的 AI 中枢,而不是一段实验代码” 那 OpenClaw 是目前更合理的选择之一。 整体架构:OpenClaw 本地 Agent 中枢怎么搭? 这是一个最小可用但可扩展的架构方案。 ? 架构拆解 ┌─────────────────────────┐ │ 用户 / 系统 │ └──────────┬──────────────┘ │ ┌──────────▼──────────┐ │ OpenClaw 中枢层 │ │ - Agent Registry │ │ - Task Orchestrator│ │ - Memory / State │ └──────────┬──────────┘ │ ┌─────────▼─────────┐ │ Agent 集群 │ │ - Research Agent │ │ - Coding Agent │ │ - Planning Agent │ │ - Tool Agent │ └─────────┬─────────┘ │ ┌─────────▼─────────┐ │ 模型 & 工具层 │ │ - 本地 LLM │ │ - API LLM │ │ - Search / FS / DB │ └───────────────────┘ 部署准备(实战级) 1️⃣ 基础环境 推荐环境(已验证): Linux / WSL / macOS Docker + Docker Compose Python 3.10+ 2️⃣ 模型选择建议(非常现实) 场景 推荐 本地推理 Qwen / LLaMA 稳定输出 GPT / Claude API 混合方案 本地 + API fallback ? 关键不是模型多,而是“可切换” 核心步骤:搭建 OpenClaw 本地 Agent 中枢 Step 1:部署 OpenClaw 核心 git clone https://github.com/xxx/openclaw cd openclaw docker compose up -d 启动后,你将拥有: Agent 管理入口 任务调度服务 统一配置中心 Step 2:定义你的第一个 Agent 一个 Agent ≠ 一个 Prompt 而是一个职责明确的“角色” 示例: agent: name: research_agent role: 信息调研 model: local_llm tools: - web_search - file_reader 建议起步 Agent: Research Agent(信息收集) Planner Agent(任务拆解) Executor Agent(执行) Step 3:建立 Agent 协作流程 例如一个典型任务: “调研某行业 → 输出分析 → 给出建议” 流程是: Planner 拆解任务 Research Agent 收集信息 Executor Agent 输出结果 中枢保存状态与结果 ? 这一步,才是“中枢”的价值所在 一个真实可用的示例场景 ? 场景:AI 工具评估中枢 你可以搭一个 Agent 中枢来做: 自动收集 AI 工具信息 对比功能 / 定价 输出结构化报告 长期更新 这类系统: 人工成本极高 用 Agent 非常合适 总结:什么时候该用 OpenClaw? 当你意识到:AI 不再是“一次性回答”,而是“持续协作的系统” 那你就已经走在 OpenClaw 这条路上了。 OpenClaw 不是让你“更快用 AI”,而是让你“真正拥有 AI 能力”。