1. 项目概述一个开箱即用的LangGraph多智能体脚手架如果你和我一样用LangGraph做过不止一个项目那你肯定对这套流程再熟悉不过了先得搭一个Supervisor监督者来协调任务然后配置好LLM提供商接着给各个智能体之间设计Handoff Tools移交工具以便它们能互相“传话”再考虑状态持久化最后还得封装一个流式响应的HTTP端点。每次开新项目这些基础架构的代码都得重写一遍虽然核心逻辑不同但“脚手架”部分总是大同小异。这种重复劳动让我意识到是时候把这些通用部分打包起来了。于是我动手构建了这个LangGraph Starter Kit。它的目标很简单用一条命令给你一个功能完整、生产就绪的多智能体应用基础框架。你不再需要从零开始搭建那些枯燥的基础设施而是可以直接聚焦在最有价值的部分——你的业务逻辑和智能体设计。这个工具包的核心价值在于“选择”与“集成”。它内置了6种经过验证的智能体协作模式并预置了对5家主流的LLM提供商的支持。你只需要通过一个交互式命令行工具选择你需要的模式和提供商就能立刻获得一个可以运行、可以修改、可以扩展的项目骨架。无论是想快速验证一个想法还是构建一个严肃的生产级应用这个工具包都能为你节省大量前期时间。2. 核心设计思路与架构解析2.1 为什么是“模式”而非“模板”在构建多智能体系统时我们面临的挑战往往不是单个智能体的能力而是如何让多个智能体高效、可靠地协作。不同的业务场景需要不同的协作范式。这个Starter Kit没有提供死板的、一成不变的“项目模板”而是抽象出了6种可复用的协作模式Patterns。这种设计思路的优势在于灵活性和可组合性。每个模式都是一个独立、完整的LangGraph应用它们之间松耦合。你可以直接使用某个模式也可以将其作为组件集成到你更复杂的图中甚至可以轻松地删除不需要的模式。这避免了传统脚手架“大而全”但“僵化”的问题让你能像搭积木一样构建系统。2.2 架构分层与职责分离整个工具包的架构清晰地分为三层确保了代码的整洁和可维护性基础设施层这是工具的基石负责所有与具体业务逻辑无关的通用功能。包括提供商抽象统一了不同LLM API如OpenAI、Anthropic的调用接口让你通过环境变量就能切换模型无需改动代码。持久化引擎内置了基于Postgres通过Docker Compose提供的对话线程状态存储方案确保智能体的记忆和上下文能在多次交互中保持。API服务器基于Fastify框架构建为每一个智能体模式自动生成对应的、支持Server-Sent EventsSSE流式输出的HTTP端点。模式层这是工具包的核心价值所在即上文提到的6种协作模式。每个模式都是一个独立的LangGraphStateGraph实现封装了特定的智能体交互逻辑、工具定义和状态流转规则。应用层这是你作为开发者主要投入精力的地方。你可以基于CLI生成的干净项目或者直接克隆完整工具包后专注于编写你自己的智能体逻辑、自定义工具和业务规则。工具包提供了清晰的扩展接口让你能轻松地将自定义的智能体注册到系统中。这种分层设计使得关注点分离工具包负责搞定所有麻烦的“脏活累活”而你则可以心无旁骛地设计智能体如何思考与协作。3. 六大智能体协作模式深度剖析3.1 Supervisor监督者模式集中式任务调度这是最经典、也最常用的多智能体架构。在这个模式中有一个核心的Supervisor Agent监督者智能体它的角色类似于一个项目经理或调度中心。工作原理用户向系统提出一个复杂请求例如“分析一下最近三天的销售数据并写一份总结报告”。Supervisor首先接收这个请求并对其进行理解和拆解。它可能会判断出这个任务需要两个子智能体协作完成一个数据分析师智能体和一个报告撰写员智能体。Supervisor根据任务类型将相应的子任务分派给最合适的Worker Agent工作者智能体。它会等待工作者智能体返回结果。工作者智能体执行任务如分析数据、撰写段落后将结果返回给Supervisor。Supervisor负责汇总、整合所有工作者的输出最终形成给用户的答复。适用场景任务流程清晰、可预先分解的场景。例如客服工单处理先分类、再查询、最后回复、内容创作先搜集资料、再撰写、最后润色等。实操心得设计Supervisor的system prompt系统提示词至关重要。你需要清晰地定义它的职责“你是一个任务调度员”、它可用的工作者列表及其能力“你有三个下属A擅长分析B擅长写作C擅长校对”以及它的决策规则“如果用户问数据问题找A如果问写作问题找B”。一个定义模糊的Supervisor会导致混乱的任务分派。3.2 Swarm蜂群模式去中心化协同接力与集中式的Supervisor模式相反Swarm模式强调去中心化和自主性。在这个模式中没有唯一的“大脑”智能体之间通过Handoff Tools移交工具直接进行协作。工作原理每个智能体都被赋予特定的专长和一套工具。智能体A开始处理任务。当它执行到某个环节发现自己无法完成或遇到属于其他智能体专长的部分时它会主动调用一个“移交工具”。这个工具会将当前对话状态、上下文和历史信息完整地“移交”给智能体B。智能体B从交接点继续工作以此类推直到任务完成。适用场景处理流程非线性、需要动态决策的开放式任务。例如复杂的问题排查先由诊断智能体检查发现问题后自动移交给修复智能体、创意性脑暴会议不同领域的专家智能体轮流贡献想法等。注意事项Swarm模式对“移交工具”的设计要求很高。工具必须能准确、无损地传递所有必要上下文。否则接手的智能体会像失忆一样导致任务失败。在实践中我通常会将整个对话历史和关键变量序列化后传递。另外要小心设计移交条件避免智能体之间陷入“踢皮球”的循环。3.3 Human-in-the-Loop人在回路模式关键决策的人工审核AI并非全知全能在某些高风险或高价值的操作上必须引入人类的判断。这个模式在LangGraph的执行流程中嵌入了暂停点。工作原理智能体在执行任务过程中当遇到预设的“关键动作”节点时例如“将要执行删除数据库记录的操作”、“将要向外发送一封重要邮件”它会自动暂停。此时Graph的状态会被保存并向外部系统通常是你的API发送一个事件其中包含待审核的action详情和当前上下文。你的后端服务可以将这个审核请求推送到管理界面、发送审批邮件或等待用户在聊天界面点击“确认”。人类审核者做出决定批准或拒绝后将决定反馈回Graph。Graph根据反馈结果继续执行执行该动作或转向其他分支放弃或修改计划。适用场景任何涉及数据修改、资金操作、内容发布、敏感信息处理等需要最终人工把关的流程。实现要点在LangGraph中这通常通过一个特殊的“工具”或“节点”来实现该节点不直接执行动作而是修改状态中的一个标志位如awaiting_human_approval: true并向外抛出事件。你的应用需要监听这个状态变化并实现相应的审批交互界面。3.4 Structured Output结构化输出模式类型安全的AI响应让LLM生成自由文本很简单但让它的输出严格符合你代码期望的格式如特定的JSON结构却常常令人头疼。这个模式利用Zod一个TypeScript模式验证库来确保智能体的输出是类型安全且结构化的。工作原理你使用Zod定义一个精确的数据模式Schema描述你期望AI返回的JSON对象应该有哪些字段每个字段是什么类型字符串、数字、数组等以及任何额外的约束如字符串格式、数值范围。在创建智能体时将这个Zod Schema作为structured output的约束传递给LLM。LangGraph底层会利用LLM提供商对结构化输出的支持如OpenAI的JSON Mode或Anthropic的tool_use在调用时强制要求LLM按照给定Schema生成响应。响应返回后工具包会自动用Zod进行解析和验证。如果格式不符会抛出清晰的错误而不是让一个格式错误的JSON破坏你的下游逻辑。适用场景需要将AI输出直接用于后续自动化流程的场景。例如从用户描述中提取订单信息生成结构化订单对象、将自由格式的反馈分类到预定义的标签中、生成符合API要求的参数对象等。实操心得Zod Schema的定义要尽可能严格和具体。模糊的定义会导致LLM输出不确定。例如与其定义“status: string”不如定义“status: z.enum([‘pending‘ ‘approved‘ ‘rejected‘])”。这大大减少了后续数据清洗的麻烦让你的代码从一开始就建立在可靠的数据契约之上。3.5 Research Agent研究型智能体模式联网搜索与信息整合这个模式封装了一个经典的“研究-撰写”工作流由两个智能体协作完成一个Researcher研究员和一个Writer撰写员并由一个轻量级的Supervisor协调。工作流程用户提出一个需要查询最新信息的问题如“2024年机器学习领域有哪些值得关注的新趋势”。Supervisor将任务分派给Researcher。Researcher智能体配备网页搜索和内容抓取工具。它会执行搜索浏览相关网页提取关键信息和引用来源。Researcher将收集到的、附有引用的资料汇总移交给Writer。Writer智能体根据这些资料组织语言撰写一份结构清晰、引用准确的回答或报告。Supervisor将最终报告返回给用户。技术细节该模式通常集成如Tavily Search API或SerpAPI进行搜索并使用Cheerio或Playwright进行网页内容抓取和解析。抓取的内容会经过清洗和总结再传递给撰写者。适用场景市场调研、竞品分析、时事总结、学术资料搜集等任何需要获取并消化外部最新信息的任务。避坑指南网络搜索和抓取具有不确定性。一定要为这些工具设置超时和重试机制。另外对抓取到的内容进行“相关性过滤”非常重要否则大量无关信息会干扰撰写者。我通常会让Researcher在抓取后先用LLM对内容做一次快速摘要和相关性评分只保留高分内容。3.6 RAG检索增强生成模式基于本地知识库的问答RAG是当前让LLM获取私有、特定领域知识的主流方案。这个模式实现了一个轻量级、内存式的RAG系统无需依赖外部向量数据库如Pinecone、Weaviate开箱即用。核心组件文档加载与分块支持上传文本文件自动将长文档分割成语义上连贯的文本块Chunks。向量化与存储使用本地运行的嵌入模型如all-MiniLM-L6-v2将文本块转换为向量并存储在内存中的向量索引如Faiss或HNSWLib里。语义检索当用户提问时将问题也转换为向量并在索引中执行相似度搜索找出最相关的几个文本块。上下文增强生成将检索到的相关文本块作为上下文与用户问题一起构成提示词Prompt发送给LLM从而生成基于你提供知识的准确回答。模式特点这个实现是“内存式”的意味着向量索引存在于应用进程的内存中。优点是部署简单、零延迟、无需额外服务缺点是文档容量受内存限制且应用重启后索引会消失但可以从文件重新加载。适用场景快速为私有文档产品手册、内部Wiki、会议纪要构建一个问答原型作为大型RAG系统中的一个特定领域检索模块需要离线运行或对延迟极其敏感的场景。经验分享文档分块Chunking的策略对RAG效果影响巨大。简单的按固定字符数分割会切断语义。这个工具包默认采用了更智能的“递归字符文本分割器”它会尝试在段落、句子等自然边界进行分割。对于技术文档你还可以进一步优化尝试按标题层级进行分块。4. 五大LLM提供商集成与配置实战4.1 开箱即用的提供商支持为了让项目能无缝运行工具包预置了对目前主流LLM提供商的支持。你只需要关注两行环境变量LLM_PROVIDERanthropic ANTHROPIC_API_KEYsk-ant-...是的就这么简单。LLM_PROVIDER变量用于切换底层引擎支持以下选项openai(默认): 使用OpenAI API如GPT-4o、GPT-4 Turbo。anthropic: 使用Claude系列模型如Claude 3 Opus/Sonnet/Haiku。google: 使用Google Gemini API如Gemini 1.5 Pro。groq: 利用Groq的LPU推理引擎高速运行Llama、Mixtral等开源模型。ollama: 连接本地运行的Ollama服务使用完全离线的模型如Llama 3、Qwen。4.2 模型选择与覆盖每个提供商都有一个“ sensible default ”合理的默认模型。例如OpenAI的默认可能是gpt-4o-miniAnthropic的默认是claude-3-haiku-20240307。这些默认选择平衡了性能、成本和速度适合大多数开发场景。如果你需要更强的能力或更低的成本可以轻松覆盖默认模型LLM_PROVIDERopenai LLM_MODELgpt-4-turbo # 覆盖默认模型使用指定的模型配置解析与加载工具包内部有一个统一的配置加载模块。它会读取你的.env文件根据LLM_PROVIDER的值动态加载对应的SDK如anthropic-ai/sdk并初始化客户端。所有智能体模式的代码都通过一个统一的接口调用LLM因此切换提供商对业务逻辑是透明的。4.3 本地运行方案Ollama详解对于希望完全在本地开发、调试或处理敏感数据的场景ollama选项提供了绝佳的解决方案。设置步骤安装Ollama前往Ollama官网下载并安装对应操作系统的应用。拉取模型在终端运行ollama pull llama3.2以Llama 3.2为例来下载你需要的模型。启动Ollama服务安装后Ollama服务通常会自动运行。你可以通过ollama serve命令确保服务已启动。配置项目在你的项目.env文件中设置LLM_PROVIDERollama LLM_MODELllama3.2 # 与你拉取的模型名一致 OLLAMA_BASE_URLhttp://localhost:11434 # 默认地址运行项目现在你的所有智能体都将使用本地运行的Llama模型进行推理。优势与局限优势零API费用、数据完全不出本地、网络延迟极低、可完全离线运行。局限模型能力通常弱于顶尖的闭源模型如GPT-4、推理速度取决于本地硬件尤其是GPU、需要管理本地的模型存储。实操心得在本地开发调试智能体工作流时强烈建议先使用Ollama。它能让你快速迭代提示词和Graph逻辑而不用担心API调用成本和速率限制。确定工作流无误后再切换为云提供商进行性能测试和部署。5. 项目初始化与核心开发工作流5.1 两种启动方式CLI快速生成与完整克隆工具包提供了两种入门路径适应不同的需求方式一交互式CLI创建推荐用于新项目在终端中执行npx create-langgraph-app这个命令会启动一个交互式命令行界面。它会依次问你几个问题项目名称你的新项目文件夹叫什么选择LLM提供商从5个提供商中勾选你需要的可多选项目会配置好所有选择。选择智能体模式从6种模式中勾选你需要的可多选。初始化Git仓库是否自动执行git init回答完毕后CLI会自动创建一个新的目录安装所有依赖并生成一个只包含你所选模式和提供商配置的、干净的项目骨架。这是开始一个全新、专注的项目的最佳方式。方式二克隆完整仓库用于学习或需要所有模式如果你希望一次性获得所有6种模式和5种提供商的完整代码用于研究、参考或作为基础进行深度定制可以直接克隆GitHub仓库git clone https://github.com/ac12644/langgraph-starter-kit.git cd langgraph-starter-kit npm install cp .env.example .env # 复制环境变量示例文件 # 编辑 .env 文件填入你的API密钥 npm run dev这种方式让你拥有全部源代码方便你阅读、修改每一个模式的实现细节。5.2 项目结构导览无论通过哪种方式创建你都会得到一个结构清晰的项目。以CLI生成的项目为例核心结构如下my-langgraph-app/ ├── src/ │ ├── agents/ # 智能体定义目录 │ │ ├── supervisor/ # Supervisor模式核心逻辑 │ │ ├── swarm/ # Swarm模式核心逻辑 │ │ └── ... # 其他你选择的模式 │ ├── tools/ # 自定义工具函数目录 │ ├── types/ # TypeScript类型定义 │ ├── index.ts # 应用主入口初始化服务器和Graph │ └── server.ts # Fastify HTTP服务器配置 ├── tests/ # 单元和集成测试 ├── docker-compose.yml # 用于运行Postgres等依赖服务 ├── package.json └── .env # 环境配置文件需自己创建这个结构鼓励你将不同的智能体模式模块化每个模式都有自己的目录包含状态定义、图构建和节点逻辑便于管理和复用。5.3 开发、测试与运行开发模式 运行npm run dev会启动开发服务器。它通常做了以下几件事加载环境变量。初始化LLM客户端。构建你选择的LangGraph图。启动Fastify服务器并为你选择的每个模式注册对应的HTTP POST端点如/api/supervisor。启用热重载当你修改源代码时服务器会自动重启。测试 工具包内置了超过25个测试用例涵盖了各个模式的核心功能。运行npm test可以执行单元测试。这些测试是确保你修改代码后基础功能依然正常的“安全网”。CI配置GitHub Actions也已预先设置好。构建与生产 运行npm run build会将TypeScript代码编译成JavaScript。生产环境运行则使用npm start。Dockerfile和docker-compose.prod.yml文件也为容器化部署做好了准备。6. 如何扩展与自定义你的智能体应用6.1 创建自定义智能体与图工具包的核心扩展点在于src/agents/目录。假设你想添加一个专门处理客服任务的智能体工作流你可以创建一个新文件src/agents/customer-support/index.ts。扩展的关键是使用工具包提供的工厂函数。下面是一个创建自定义Supervisor图的示例// src/agents/customer-support/index.ts import { makeAgent, makeSupervisor } from ‘your-starter-kit/agent-factories‘; // 假设的工具包工厂函数 import { llm } from ‘../config/llm‘; // 统一配置的LLM客户端 import { searchKnowledgeBase, createTicket } from ‘../../tools/support-tools‘; // 你的自定义工具 export function createCustomerSupportApp() { // 1. 创建专门的知识库查询智能体 const researchAgent makeAgent({ name: “support_researcher“, llm, tools: [searchKnowledgeBase], // 赋予它查询工具 system: “你是一个客服知识库专家擅长根据用户问题快速找到相关的解决方案文章。“, }); // 2. 创建工单创建智能体 const ticketingAgent makeAgent({ name: “ticketing_agent“, llm, tools: [createTicket], system: “你是一个工单系统助手负责将复杂或未解决的问题规范地录入工单系统需包含问题摘要、分类和优先级。“, }); // 3. 将智能体组装成一个Supervisor图 return makeSupervisor({ agents: [researchAgent, ticketingAgent], // 注册所有工作者智能体 llm, outputMode: “last_message“, // 输出模式返回最后一条消息 supervisorName: “customer_support_supervisor“, // 你可以自定义Supervisor的提示词指导它如何分派任务 supervisorSystem: 你是客服中心总调度。用户描述问题后你先让‘support_researcher‘在知识库中查找现有解决方案。如果找到直接回复用户如果没找到或问题复杂则让‘ticketing_agent‘创建工单并告知用户工单号。 }); }6.2 注册新应用到服务器创建好图之后需要在服务器中注册它以暴露HTTP API。这通常在src/index.ts或src/server.ts中完成// src/index.ts import { createCustomerSupportApp } from ‘./agents/customer-support‘; // ... 其他导入 async function main() { const app fastify(); const graphRegistry {}; // 假设有一个图注册表 // 注册内置模式... graphRegistry[‘supervisor‘] createSupervisorApp(); graphRegistry[‘swarm‘] createSwarmApp(); // 注册你的自定义应用 graphRegistry[‘customer-support‘] createCustomerSupportApp(); // 为每个注册的图创建流式端点 for (const [path, graph] of Object.entries(graphRegistry)) { app.post(/api/${path}, async (request, reply) { // ... 处理请求调用graph流式返回... }); } await app.listen({ port: 3000 }); }现在访问POST /api/customer-support就可以使用你全新的客服多智能体系统了。6.3 集成自定义工具智能体的能力由其工具决定。工具包支持你轻松集成任何自定义功能。一个工具本质上是一个符合LangGraphTool接口的函数。// src/tools/weather.ts import { tool } from ‘langchain/core/tools‘; import axios from ‘axios‘; export const getWeatherTool tool( async ({ location }: { location: string }) { // 这里是你的业务逻辑例如调用天气API const response await axios.get(https://api.weatherapi.com/v1/current.json?keyYOUR_KEYq${location}); return 地点 ${location} 的天气是${response.data.current.condition.text}温度 ${response.data.current.temp_c}°C。; }, { name: “get_weather“, description: “获取指定城市的当前天气信息。“, schema: z.object({ // 使用Zod定义输入参数 location: z.string().describe(“城市名称例如‘北京‘、‘New York‘“), }), } );然后在创建智能体时将这个工具加入到tools数组中即可。7. 生产级功能与部署指南7.1 内置的生产就绪特性这个工具包不仅仅是原型工具它集成了多项生产环境必需的功能1. 全面的可观测性LangSmith集成只需设置LANGCHAIN_API_KEY和LANGCHAIN_PROJECT环境变量所有智能体的调用链、工具使用、耗时和Token消耗都会被自动记录到LangSmith平台。这对调试复杂的工作流、分析性能和成本至关重要。结构化日志应用内置了结构化的JSON日志方便与ELK、Datadog等日志系统集成。2. 稳健的API与流式响应每个智能体模式都自动配备了支持Server-Sent Events (SSE)的HTTP端点。这意味着前端可以实时接收到智能体思考的“打字机”效果用户体验更好。API服务器基于高性能的Fastify框架并已配置好常见的中间件如CORS、请求日志、速率限制需配置等。3. 状态持久化项目默认集成了基于Postgres的对话线程存储。docker-compose.yml文件可以一键启动一个Postgres容器。LangGraph的检查点Checkpoint机制会将每个用户会话的完整状态智能体的记忆、中间结果保存到数据库。即使服务器重启对话也能从中断处继续。4. 模型上下文服务器MCP工具集成这是一个高级特性它允许你的智能体动态连接并使用外部工具。例如智能体可以按需连接公司的数据库、内部API或日历服务。工具包提供了stdio和HTTP两种MCP服务器连接方式。7.2 部署到云平台工具包包含了针对主流PaaS平台的部署配置Railway 部署 项目根目录的railway.json文件已经配置好了。你只需要将代码推送到GitHub。在Railway官网连接你的仓库。Railway会自动识别配置设置环境变量并完成部署。Render 部署 同样render.yaml文件已就绪。在Render的控制台创建新的Web Service指向你的仓库它就会使用这个蓝图进行部署。通用Docker部署Dockerfile定义了多阶段构建能创建出小巧的生产镜像。结合docker-compose.prod.yml你可以在任何支持Docker的VPS或云服务器上运行docker-compose -f docker-compose.prod.yml up -d这个生产配置通常会包含Nginx反向代理、Postgres数据库等。7.3 安全与运维考量环境变量管理切勿将API密钥等敏感信息提交到代码仓库。.env.example文件列出了所有需要的变量你应该复制它为.env并填写真实值且确保.env在.gitignore中。在生产环境使用平台提供的Secrets管理功能。速率限制与超时虽然工具包内置了基础的HTTP超时设置但在生产环境你需要在API网关或负载均衡器层面配置更严格的速率限制防止滥用。对于LLM调用也要在代码中为每个工具和LLM调用设置合理的超时时间。监控与告警利用LangSmith的监控功能设置告警例如当某个工具的失败率异常升高或单个请求的Token消耗远超平均水平时及时通知团队。8. 常见问题排查与实战技巧8.1 启动与配置问题问题1运行npm run dev时报错 “Cannot find module ‘...‘”排查首先确保已运行npm install安装了所有依赖。如果问题出现在克隆仓库后可能是某些可选依赖未安装。检查package.json中的optionalDependencies或与特定提供商相关的包如anthropic-ai/sdk。解决尝试删除node_modules文件夹和package-lock.json文件然后重新运行npm install。问题2API调用失败提示 “Invalid API Key” 或 “Provider not configured”排查检查你的.env文件是否正确设置且变量名与代码中读取的名称一致注意大小写。确保你已在对应提供商平台创建了API密钥并且密钥有余额或未过期。解决对于Ollama确保服务正在运行 (ollama serve) 且模型已下载 (ollama pull model-name)。对于其他云提供商可以在代码中临时添加console.log(process.env.LLM_PROVIDER)来确认环境变量是否被正确加载。问题3Docker Compose 启动 Postgres 失败排查检查端口冲突。默认的Postgres端口是5432查看你本地是否有其他服务占用了该端口。解决可以修改docker-compose.yml文件将宿主机的映射端口改为其他端口如“5433:5432“。8.2 智能体逻辑与执行问题问题4Supervisor 无法正确分派任务或者总是选择同一个Worker排查这几乎总是由于Supervisor的system prompt设计不佳。它的提示词必须清晰定义每个Worker的职责和擅长领域。解决优化你的提示词。使用更明确的指令例如“你有三个助手翻译员只负责中英互译、总结员只负责将长文本缩短、代码员只负责编写和解释代码。请根据用户问题的性质选择最合适的一个助手来处理。如果问题涉及多个领域请按顺序调用它们。” 你还可以在测试时打开LangSmith追踪查看Supervisor做决策时的完整思考过程。问题5Swarm 模式中智能体间“踢皮球”任务无法完成排查检查每个智能体的“移交工具”调用条件是否设置得当以及移交时传递的上下文是否完整。解决为移交工具添加更严格的触发逻辑。例如只有当智能体明确判断“此问题属于领域X且我的处理已到达瓶颈”时才移交。同时确保移交工具传递了整个state对象而不仅仅是最后一条消息。问题6RAG 检索结果不相关排查问题可能出在多个环节文档分块大小不合适、嵌入模型不匹配、检索时返回的块数量k值不当。解决调整分块大小和重叠尝试不同的chunkSize(如 500, 1000) 和chunkOverlap(如 100, 200)。尝试不同嵌入模型如果你使用Ollama可以尝试nomic-embed-text或mxbai-embed-large等专门为检索优化的模型。优化检索策略尝试“多向量检索”即同时存储文档的摘要和细节或使用“混合搜索”结合关键词BM25和向量相似度进行检索。8.3 性能优化技巧技巧1为不同的智能体分配不同规格的模型不一定所有智能体都需要使用最强大、最贵的模型。你可以在工具包配置的基础上进行微调。例如让负责简单分类或路由的Supervisor使用快速便宜的模型如claude-3-haiku或gpt-4o-mini而让负责复杂分析和创作的Writer使用能力更强的模型如claude-3-opus或gpt-4-turbo。这能在保证效果的同时显著降低成本。技巧2利用流式输出改善用户体验工具包已默认启用SSE流式输出。在前端确保你正确处理了这种数据流。流式输出不仅能实现“打字机”效果还能让用户尽早看到部分结果感知到系统正在工作尤其是在处理耗时较长的任务时。技巧3实现智能体的“短路”逻辑在某些模式下可以提前结束Graph执行以节省时间和Token。例如在Human-in-the-Loop模式中如果人类审核者拒绝了操作Graph应该直接跳转到失败处理节点而不是继续执行后续分支。在RAG模式中如果检索器返回的相关性分数最高的文档块分数仍然低于某个阈值可以直接回复“未在知识库中找到相关信息”而无需调用LLM。这个工具包是我在多次重复搭建LangGraph项目后将那些通用部分提炼、固化的成果。它不能替代你对业务逻辑的深入思考但能为你扫清前进道路上 80% 的基础设施障碍。我最深的体会是一个好的起点能极大激发创造力。当你不再为配置、部署和重复模式烦恼时你就能更专注于设计智能体之间有趣的互动解决更实质性的问题。不妨现在就试试npx create-langgraph-app看看它能如何加速你的下一个AI应用构想。