nvd11的专栏

Router 决定了“这个活儿该派给谁干”，而 Gateway 保障了“干活的底层通道安全、便宜且永不宕机”。理清这一架构边界，是构建高可用、可扩展的企业级 Multi-Agent 系统的第一步。

本文对比了LangChain管道中RunnableParallel和RunnablePassthrough.assign()的核心差异。RunnableParallel适用于数据重构，可丢弃冗余信息并支持非字典输入转换；而.assign()适合在管道中游增量补充数据，保留原有上下文但需注意链式调用会导致串行执行。架构选型建议：入口层用RunnableParallel结构化输入，业务层用.assign()增量补充，模型前置层再用RunnableParallel清洗数据。RunnableParallel在Lan

本文深入解析LangChain的astream_eventsAPI如何优化LLM应用的用户体验。传统.stream()方法在复杂链路（如RAG系统）中会因阻塞性操作导致首字响应时间过长，造成前端"死寂"等待。astream_events通过流式化中间状态，将管道各节点生命周期作为事件流推送，显著降低感知等待时间。文章对比了手动yield方案的三大缺陷：破坏声明式语法、并发管理复杂和标准化不足，并提供了实战代码演示如何利用astream_events截获和渲染中间状态，实现从"检

本文提出一个基于分类树结构的模型评估架构，将系统分为传统机器学习（ML Models）和检索增强生成代理（RAG Agent）两大评估赛道。ML Models部分详细介绍了简单过滤模型的精确率、召回率和F1 Score评估指标，以及黑盒模型的可解释性方法LIME和SHAP。RAG Agent部分则聚焦于评估知识检索与文本生成的综合性能。该架构为不同场景下的系统评估提供了量化基准和实用工具集，覆盖从传统统计学习到现代生成式AI的全谱系评估需求。

RunnablePassthrough是LangChain LCEL中的关键组件，主要实现数据透传功能。它有两种核心用途：1）在并行处理中保留原始输入，如RAG场景中同时传递检索结果和原始问题；2）通过.assign()方法增量更新字典数据。该组件在构建复杂数据流时尤为重要，能确保信息完整传递，避免手动处理字典的繁琐操作，是LangChain实现高效数据处理的重要工具。

本文解释了LCEL中字典语法的底层机制。当在Chain中使用字典时，系统会自动将其转换为RunnableParallel对象，实现并行执行多个任务。这种隐式转换让代码更简洁，同时保持并行处理的特性。通过验证实验证实，字典语法和显式写法性能相同（耗时1秒），证明字典确实被动态转换为并行执行逻辑。该设计简化了高频的并行操作场景，特别是在构建Prompt输入时，能方便地组合多个数据源。理解这一机制有助于读懂复杂的LCEL代码。

本文深入解析LangChain经典对话组件ConversationBufferMemory与ConversationChain的核心机制。ConversationBufferMemory作为基础记忆组件，完整存储对话历史但存在token爆炸风险；ConversationChain则是预封装的三合一解决方案（LLM+Memory+Prompt），开箱即用但存在实例级状态绑定的并发限制。文章通过代码示例展示了组件使用方法，并对比新旧架构的本质差异：传统方案采用硬编码的有状态实例，而LCEL新方案通过动态注入实现

是 LangChain 中优雅管理状态的瑞士军刀。它通过配置化的方式，将繁琐的历史记录读写逻辑从业务逻辑中剥离出来，极大地简化了代码结构。记忆口诀Config定身份 (session_id)。Factory找仓库 (get_session_history)。Keys做映射 (input/history keys)。

摘要： LangChain开发中，PromptTemplate与ChatPromptTemplate分别适配不同模型范式。前者面向传统文本续写模型（如GPT-3），通过字符串插值生成单一文本；后者专为对话模型（如GPT-4）设计，以结构化消息列表（System/User/Assistant）支持角色交互。关键差异包括数据结构、变量处理方式及适用场景。尽管简单任务可用Python原生字符串替代，PromptTemplate仍提供部分填充、输入验证、序列化等工程化优势。随着对话模型成为主流，ChatPrompt

本文深入解析LangChain中的MessagesPlaceholder组件，它在构建对话式应用时至关重要。现代Chat Model接收结构化消息列表而非单一文本，MessagesPlaceholder作为占位符可将消息对象列表直接嵌入消息队列，保持数据结构完整。文章对比了传统文本拼接与现代结构化消息的差异，并通过代码示例展示其正确用法与常见误区。MessagesPlaceholder主要应用于对话历史管理和Agent推理轨迹场景，必须配合ChatPromptTemplate使用。正确使用该组件可构建结构清

本文深度剖析了LangChain Agent架构从旧范式向新范式的演进。旧范式基于AgentExecutor和create_openai_tools_agent，存在黑盒循环、流式输出困难等缺陷。新范式采用LCEL（LangChain Expression Language）和LangGraph两大技术：LCEL提供原子化组件组合能力，适合简单工具调用；LangGraph通过状态机架构实现完全可控的循环，支持细粒度流式和人工介入。对比显示，新范式在控制流、Prompt设计、调试等方面具有显著优势。迁移建议指

本文深入解析了LangChain LCEL中的RunnableBranch与语义路由机制。首先介绍了RunnableBranch的基础原理，它类似于编程中的if-elif-else结构。然后通过两个实战案例：基于关键词的简单路由和基于LLM的语义路由，展示了如何实现智能的任务分发。语义路由通过LLM先识别意图再进行分发，解决了自然语言的模糊性问题。最后将这一模式延伸到多Agent系统架构，说明其在实际企业应用中的价值，如DevOps助手等场景，实现了关注点分离和系统扩展性。掌握语义路由是构建复杂智能系统的关

本文介绍了LangChain中三种LLM工具调用模式：确定性显式调用（强制执行固定流程）、半动态绑定（LLM决定单次调用）和高度动态Agent（多步循环）。通过代码示例展示了前两种模式的实现，强调应根据业务确定性选择最简单可行的方案。显式调用最稳定但缺乏灵活性，半动态绑定平衡智能与可控性，复杂场景才需Agent。建议优先考虑简单模式以降低复杂度。

LangChain 0.1+架构通过引入Runnable协议统一了核心组件的交互方式，使Prompt、LLM等组件能像Unix管道一样组合。其编排层包含三大原语：Runnable（基础协议）、RunnableLambda（函数封装）和RunnableParallel（并行处理）。Runnable协议要求所有组件实现统一的调用方法（如invoke、stream等），RunnableLambda可将任意Python函数转换为可组合单元，而RunnableParallel支持并行执行多个任务并聚合结果。这种架构特

本文介绍了LangChain Expression Language (LCEL)的核心功能与应用实践。LCEL作为声明式编排协议，通过统一的Runnable接口解决了LLM应用开发中的组件组合、异步处理等痛点。文章首先展示了基础调用范式，包括同步/异步/流式三种调用策略；然后详细解析了结构化输出解析方法，从基础文本到JSON和Pydantic对象的高级处理；最后通过"旅行规划"案例，演示了如何使用RunnableParallel构建并行执行的复杂拓扑结构，实现多步骤LLM任务的自动编排

本文介绍了在受限金融IT环境中构建LLM智能代理的实战方案。针对企业级Copilot API不支持标准Function Calling的问题，提出基于ReAct模式和Model Context Protocol(MCP)的创新架构。通过时序图展示了包含请求接收、路由思考、工具调用和响应持久化的完整流程，详细说明了McpToolConverter协议适配器、ToolCallableAgent抽象基类和GithubReactAgent领域专家的设计实现。该方案采用手动构建工具Prompt和JSON解析的方式，实

摘要： 本文记录了一次基于LLM的智能体(Agent)系统生产环境故障排查过程。系统在多轮对话中出现重复提问和幻觉问题，表现为Agent在调用工具前自行编造虚假回复。通过LangSmith Trace分析发现两大根源：1)历史记录重复存储导致LLM输入重复；2)Main Agent过度预测输出工具结果。修复方案包括：1)在ChatService中实现历史记录去重逻辑；2)强化System Prompt明确工具使用规范；3)代码层拦截混合输出，确保仅返回工具执行结果。此次排查突显了可观测性在LLM应用开发中的

本文详细介绍了基于LangChain构建的GithubAgent智能代理，该代理通过连接MCP Server实现了自动工具发现、规则注入和智能工具调用三大核心功能。文章从架构层面解析了GithubAgent的工作流程，包括初始化阶段的握手连接、工具绑定，以及核心的思考-行动-观察(ReAct)循环机制。重点阐述了5个核心方法：工具发现(_fetch_mcp_tools)、智能适配(_convert_mcp_tools)、规则注入(_extract_instructions)、主循环(_agent_loop)

本文深入解析LangChain框架中BaseMessageChunk与AIMessageChunk的设计差异。BaseMessageChunk作为抽象基类，定义了流式传输的核心属性，但不具备具体业务语义；而AIMessageChunk则针对AI回复场景进行了语义封装。文章指出：类型标注时应使用基类保持通用性，实例化时则需使用具体子类确保语义明确。这种"抽象使用、具体创建"的设计模式，体现了面向对象编程的多态性和封装原则，是构建高效、可维护LLM应用的关键所在。

本文介绍了一个基于LangChain框架、Google Gemini大模型和CloudSQL PostgreSQL（含pgvector插件）构建的RAG系统。系统采用规范化数据库设计，包含主题分类、文档元数据和向量存储表。数据处理流程包括：1)下载PDF文档；2)通过DataProcessingService协调文本加载、分块、向量生成(Gemini API)和存储；3)使用pgvector存储768维向量。核心模块展示了文档下载、分块处理和数据库交互的实现细节，实现了从原始文档到向量化知识库的完整转换流程

本文对比了RAG问答系统的两种文档检索展示方案：显式检索(RAG Chain)和工具调用代理(Tool Calling Agent)。显式检索实现简单但缺乏灵活性，而工具调用代理虽复杂但支持智能决策和多步推理。项目最终采用方案2，通过三层架构实现：外层封装处理结果组装，中间层管理工具路由，底层负责推理生成。核心代码解析展示了如何从检索服务获取格式化文档片段，并通过代理执行流程提取答案和来源文档，确保引用准确性同时保留智能特性。该方案有效平衡了系统可信度与灵活性需求。

AI Agent通过Tool Calling赋予大语言模型(LLM)连接外部世界的能力。本文解析了两种实现方式：早期不稳定的Prompt Engineering和现代标准化的Function Calling。后者通过JSON Schema定义工具，LLM生成结构化指令，由外部程序执行具体操作。文章详细展示了工作流程、数据结构，并提供了LangChain实现的代码示例，说明如何让LLM识别数学计算需求、调用乘法工具并返回结果。随着技术发展，AI正从单一工具调用向自主规划的多轮Agent交互演进。

本文详细介绍了如何利用LangChain构建一个RAG系统，使用《爱比克泰德金言录》作为示例文本。文章分为两个主要部分：索引构建和检索生成。索引阶段包含数据准备（过滤无关内容）、文档加载（使用TextLoader）和文本切分（使用RecursiveCharacterTextSplitter）三个步骤，重点讲解了每个步骤的代码实现和关键参数设置。通过流程图展示了RAG系统的工作流程，包括向量存储构建和检索问答过程。文中还提供了真实调试输出和深度代码解析，帮助理解每个函数的作用和参数意义。

本文介绍如何通过环境变量实现LangSmith的零代码自动追踪功能。核心原理是利用LangChain内置支持，只需设置LANGCHAIN_TRACING_V2=true环境变量即可自动记录所有Chain、LLM等组件的运行细节。配置包括开启追踪开关、API密钥、区域端点和项目名称。通过示例脚本演示，普通LangChain代码无需修改即可自动生成追踪报告。用户可在LangSmith控制台查看完整的调用链路、Prompt内容、Token消耗等详细信息，便于分析性能、调试和成本优化。这种方法实现了业务逻辑与监控的

本文介绍了如何使用LangSmith平台对LLM模型（如Gemini、DeepSeek、GPT）进行自动化评估和对比。主要内容包括：1) 注册账号并获取API Key，注意区分US和EU节点；2) 环境配置，安装必要依赖并设置环境变量；3) 实战代码示例，展示如何创建数据集、初始化模型并进行对比评估；4) 结果查看方法，通过可视化界面分析模型在准确性、响应速度等方面的表现差异。该方案将主观的模型评估转化为可量化的数据对比，为模型选择提供客观依据。

摘要 LangChain是一个基于大型语言模型（LLM）的开发框架，通过六大核心模块简化LLM应用构建。 Model I/O：标准化模型交互流程，包括提示模板、LLM调用和输出解析。 Retrieval：支持RAG（检索增强生成），从文档加载、分块到向量检索。 Chains：通过LCEL（LangChain表达式语言）串联组件，实现复杂任务流水线。 Memory：管理多轮对话状态，支持会话历史存储。 Agents：让LLM自主决策工具调用，完成动态任务。 Tools：提供可集成的功能函数（如搜索、计算等）。

本文介绍了大型语言模型（LLM）的两类核心模型：Base LLM（基座模型）和Instruction-Tuned LLM（指令微调模型），并对比了Prompt Engineering、RAG（检索增强生成）和微调三大技术的优缺点。Base LLM专注于文本补全，而指令微调模型能理解意图并回答问题。Prompt Engineering适用于快速验证想法，RAG解决知识时效性和幻觉问题，微调则优化格式稳定性和成本。最佳实践建议从Prompt开始，逐步结合RAG和微调，以平衡性能与成本。

本文详细解析了大型语言模型文本生成中的三个关键参数：Temperature、Top-k和Top-p。Temperature控制概率分布的平滑度，低温(＜1)使输出更确定，高温(＞1)增加随机性。Top-k采样固定保留前k个候选词，但存在无法适应预测置信度变化的缺陷。Top-p采样则动态保留累积概率达到阈值p的最小候选集，能更好地处理模型确定性和不确定性情况。实践建议优先使用Top-p(0.9-0.95)配合Temperature调整：低温(0-0.3)适合精准任务，较高温(0.7-1.0)适合创意场景。To

本文概述了大型语言模型（LLM）生成文本的核心流程。LLM采用自回归方式，通过三个阶段的循环生成文本：编码（将文本转为数值向量）、预测（计算下一个token的概率分布）、解码（选择token并转回文本）。详细步骤包括：输入处理（分词和嵌入）、模型推理（自注意力机制和前馈网络计算）、输出解码（通过softmax和采样策略确定token）。整个过程循环进行，直到生成结束符。流程图展示了从输入到输出的完整循环过程，关键步骤包括tokenization、inference、sampling和自回归循环。

本文档详细解析了如何为无状态的大型语言模型（LLM）实现对话记忆功能。通过分层架构设计，系统采用四步流程：API接收请求、加载历史记录、构建上下文和调用LLM。核心优化在于数据库层面的查询限制（使用limit参数）和业务逻辑层的参数化配置，有效避免了内存爆炸和性能问题。这种设计既保证了对话连贯性，又确保了系统的高效性和可维护性，为LLM提供了可靠的"记忆"能力。

本文介绍了从initialize_agent升级到create_agent解决Gemini Agent处理大型代码PR时prompt过大的问题。旧架构存在token超限、处理失败等问题，而新架构采用LCEL数据流图，直接处理system prompt并智能管理token。关键改进包括：简化API调用、优化token管理、增强错误隔离能力。测试显示新架构可处理50+个文件（旧架构仅5-10个），并成功完成大型PR审查。配套优化还包括自定义Gemini模型改用REST协议、实现异步批处理接口等，显著提升了系统性

本文详细复盘了py-github-agent项目中Code Review Agent功能的构建过程。系统采用分层架构，通过API路由接收PR请求，由CodeReviewService驱动LangChain Agent执行审查任务。核心难点在于高效获取PR的全量信息，GitHub Service通过异步并发请求优化性能，支持获取文件变更前后的完整内容。系统采用ReAct模式运行，Agent通过工具调用GitHub API获取代码上下文，并交由LLM生成审查报告。文档不仅包含核心代码实现，还深入解析了设计决策与

AI架构中的Agent与MCP对比 Agent是具备自主决策能力的智能系统（"大脑"），负责推理、规划和执行任务。MCP则是标准化通信协议（"神经系统"），专注于提供上下文和工具连接。关键区别在于：Agent是主动决策者，具有高级智能；MCP是被动接口，仅规范通信标准。两者协同工作时，Agent通过MCP发现和调用工具，专注于智能决策，而MCP处理具体操作。这种架构实现了决策层与执行层的解耦，使系统更模块化。正确理解两者的定位和关系对构建高效AI系统至关重要。

本文档介绍了如何构建一个能与GitHub交互的AI Agent系统。系统采用模块化设计，包含工具层（调用GitHub API）、模型层（封装Gemini LLM）、代理组装层（结合LLM和工具）和服务层（提供API接口）。关键技术点包括：使用BaseTool定义GitHub操作工具、通过CustomGeminiChatModel封装LLM、创建AgentExecutor实现思考-行动循环，以及统一Runnable接口实现灵活调用。该架构具有高度模块化和可扩展性，只需添加新工具即可扩展功能，为开发者提供了与G

本文解析了Agent如何通过ReAct模式自主调用list_repository_files工具获取GitHub仓库信息。该过程包含四个角色：用户提出问题、LLM（Google Gemini）进行推理、工具执行代码、AgentExecutor协调交互。流程分为三个阶段：1）LLM分析问题并生成指令；2）AgentExecutor拦截指令并调用工具执行；3）将结果反馈给LLM生成最终答案。代码实现体现在工具定义、Agent组装和执行驱动三个模块，通过精心设计的Prompt让LLM指挥程序执行任务，完成&quo

本文记录了py-github-agent项目中解决Google Gemini模型astream方法无法实现"打字机"效果的问题。诊断发现，自定义封装类CustomGeminiChatModel未实现_astream方法导致一次性输出。通过添加_astream方法并包装返回值后，发现Gemini API在REST模式下固有行为是逐句而非逐词流式输出。测试表明，代码封装正确，问题根源在于不同LLM服务商对流式传输的实现策略差异：DeepSeek支持逐词流，而Gemini仅支持逐句流。最终确认

本文介绍了LangChain中invoke和_generate两个关键方法的区别与用途。invoke是面向模型使用者的统一公共API，支持标准调用、组合操作和高级功能；而_generate是面向模型开发者的内部抽象方法，用于实现底层模型调用逻辑。两者的关系类似汽车方向盘和发动机，invoke提供统一接口，_generate实现核心功能。这种设计实现了接口统一和实现解耦，使LangChain既易用又易于扩展。使用者应通过invoke调用模型，开发者则需实现_generate来创建自定义模型。

langchain 是一个用于构建基于大语言模型(LLM)的应用程序的框架。它提供了一些工具和组件，可以帮助开发者更轻松地创建和管理与LLM交互的应用程序。