基于LangChain.js与MCP协议构建AI智能体：从本地开发到Azure部署实战

1. 项目概述一个基于LangChain.js与MCP的汉堡店AI点餐代理如果你正在寻找一个能完整展示如何将大型语言模型LLM与真实世界API连接起来的实战项目那么这个由Azure-Samples开源的“mcp-agent-langchainjs”仓库绝对值得你花时间深入研究。它不是一个简单的“Hello World”示例而是一个麻雀虽小、五脏俱全的端到端E2E微服务应用核心目标是演示如何利用Model Context Protocol和LangChain.js构建一个能真正理解用户意图、调用工具、完成复杂任务比如点汉堡的AI智能体。想象一下你有一个汉堡店的在线API提供了浏览菜单、下单、查询订单状态等功能。传统上你需要为每个功能编写特定的前端界面或脚本。但现在你可以训练一个AI代理让它像一位真正的服务员一样通过自然语言与顾客对话“有什么辣的汉堡推荐吗”、“我要两个经典芝士堡多加培根”、“看看我最近的订单”。这个代理能理解这些请求自动调用背后对应的API工具并给出人类可读的回复。这个项目就完整实现了这个场景并且采用了100%无服务器架构部署在Azure上从聊天界面、代理逻辑、业务API到工具暴露层每一环都清晰可辨。对于前端、全栈开发者或者任何对AI应用落地感兴趣的朋友来说这个项目是一个绝佳的学习样板。它没有停留在理论层面而是提供了从本地开发、调试到一键云部署的完整路径。无论你是想学习LangChain.js的智能体Agent工作流还是想了解新兴的MCP协议如何标准化AI与工具的交互亦或是想实践如何在Azure上构建一个成本可控的Serverless AI应用这里都有你需要的代码和设计思路。2. 架构深度解析为什么选择微服务与MCP在动手写代码之前理解这个项目的架构设计至关重要。它没有把所有逻辑塞进一个“大泥球”应用里而是采用了清晰的微服务划分。这种设计并非为了炫技而是为了解决AI应用开发中几个核心的复杂性问题关注点分离、独立扩展和工具协议标准化。2.1 核心组件分工与通信流整个系统可以看作一个“对话驱动”的流水线。当用户在Web聊天界面输入“点一个牛肉汉堡”时请求的旅程是这样的前端界面Agent Web App这是一个基于Web的聊天应用负责收集用户输入并美观地展示对话历史。它本身不处理AI逻辑只是一个“传话筒”和“展示窗”。代理服务Agent API这是整个系统的大脑一个部署在Azure Functions上的无服务器API。它接收前端的消息核心工作是运行一个LangChain.js智能体。这个智能体内置了推理能力它会分析用户消息判断意图例如“用户想点餐”然后决定需要调用哪个工具例如“place_order”工具。工具层Burger MCP Server这是关键创新点。代理服务不直接去调用汉堡店的后端API而是通过MCP与一个专门的MCP服务器通信。这个MCP服务器将汉堡店API的所有功能如get_burgersplace_order包装成了一组标准化的“工具”。LangChain智能体看到的是一组定义清晰的工具函数它只需要发出调用指令MCP客户端会负责与MCP服务器通信并返回结果。业务后端Burger API这是真实的汉堡店业务逻辑也是一个Azure Functions API。它处理具体的数据库操作如读写Cosmos DB中的订单数据。MCP服务器在内部调用这个API来完成实际工作。数据可视化Burger Web App这是一个独立的看板应用可以实时可视化系统中的订单状态主要用于演示和监控。为什么这么设计解耦AI与业务逻辑AI代理LangChain不需要关心汉堡API是用什么语言写的、接口细节是什么。它只与标准的MCP工具交互。这意味着你可以更换背后的业务API比如换成披萨店API只要MCP服务器提供的工具名称和参数不变AI代理的代码就完全不用改。工具发现与标准化MCP协议提供了标准的工具发现机制。像GitHub Copilot、Claude Desktop这类MCP客户端可以自动连接并识别这个Burger MCP服务器提供了哪些工具从而让这些AI助手也能直接使用你的服务。这极大地扩展了AI代理的能力边界。2.2 技术栈选型背后的考量LangChain.js作为当前JavaScript/TypeScript生态中最成熟的AI应用框架它提供了构建智能体所需的核心抽象工具调用Tool Calling、思维链ReAct等。其丰富的生态系统和活跃的社区是项目稳定的保障。Model Context Protocol这是一个由Anthropic等公司推动的开放协议旨在标准化AI模型与外部工具/数据源之间的通信。选择MCP而非直接封装API是面向未来的决策。它让你的工具不仅能被自己的代理使用还能轻松接入日益增长的MCP兼容生态。Azure Functions Static Web Apps典型的Serverless组合。Functions用于托管有状态、需要计算的API和代理服务按需执行成本极低。Static Web Apps用于托管纯前端的React/Vue应用全球分发访问速度快。这种架构天生具备弹性伸缩能力非常适合初期用户量不确定的AI应用。Azure Cosmos DB作为全局分布的多模型数据库其无模式Schema-less的JSON文档存储特性非常适合存储结构灵活的订单和菜单数据。更重要的是它的Serverless容量模式可以与Functions无缝搭配实现真正的“用多少付多少”。Azure Developer CLI项目采用azd进行一键式部署这是微软为提升开发者体验推出的利器。它将资源编排Bicep、代码部署、环境管理统一起来避免了手动在Azure Portal上点击数十次配置的繁琐让基础设施即代码IaC变得触手可及。实操心得在项目初期就采用清晰的微服务边界和MCP协议虽然增加了初始的复杂度但为后续的维护和扩展带来了巨大便利。例如当你想为代理增加一个“查询天气来决定推荐冷饮还是热饮”的功能时你只需要新增一个Weather MCP Server并在代理的工具列表中注册它即可原有代码几乎无需改动。3. 环境准备与本地运行全指南“Talk is cheap, show me the code.” 最好的学习方式就是让项目在本地跑起来。这个项目提供了多种开箱即用的方式对新手极其友好。3.1 三种开发环境选择GitHub Codespaces推荐给初学者或快速体验者这是最无痛的方式。直接在项目页面点击“Open in Codespaces”GitHub会在云端为你准备好一个配置了Node.js、依赖项甚至预装好Azure CLI的完整VS Code环境。你无需在本地安装任何东西打开浏览器就能开始开发和调试。这对于验证项目是否适合自己或者在不污染本地环境的情况下进行实验是首选方案。VS Code Dev Containers如果你习惯使用本地的VS Code但希望环境是隔离且可复现的这是最佳选择。它利用Docker容器在本地创建一个与Codespaces一致的开发环境。你需要预先安装Docker和VS Code的“Dev Containers”扩展。这种方式既能享受本地IDE的性能和插件生态又能保证环境一致性。纯本地环境适合那些喜欢完全控制环境或者需要在特定系统配置下进行深度开发的开发者。你需要手动安装以下工具Node.js (22)这是运行所有JavaScript/TypeScript服务的基石。Azure Developer CLI (azd)用于后续的部署。通过winget install Microsoft.Azure.DeveloperCli或brew install azure/azd/azd安装。Git用于克隆代码。PowerShell 7 (仅Windows)运行azd命令所需。建议使用Windows Terminal。3.2 本地运行无需云端资源你完全可以在不连接任何Azure服务的情况下在本地运行整个应用栈。项目贴心地支持使用本地LLM通过Ollama来驱动AI代理真正做到“零云成本”体验。步骤一安装并配置OllamaOllama是一个简化本地大模型运行的工具。# 前往 https://ollama.com 下载并安装Ollama # 拉取一个合适的模型例如轻量级的Qwen2.5 ollama pull qwen2.5:7b注意事项模型大小与你的机器内存直接相关。qwen2.5:7b约需8GB内存如果你的机器内存充足比如32GB可以尝试llama3.2:11b以获得更好的推理能力。记住模型能力越强代理处理复杂指令如多轮对话、条件筛选的表现就越好。步骤二配置环境变量在项目根目录创建一个名为.env的文件内容如下AZURE_OPENAI_API_ENDPOINThttp://localhost:11434/v1 AZURE_OPENAI_MODELqwen2.5:7b AZURE_OPENAI_API_KEYnot-needed-for-ollama这里的关键是将API端点指向本地Ollama服务默认端口11434并指定你刚拉取的模型名称。API密钥可以随意填写因为Ollama本地服务通常不需要鉴权。步骤三启动所有服务在项目根目录下运行npm install # 安装所有工作区的依赖 npm start # 并发启动所有服务这个过程会启动前面提到的五个核心服务。耐心等待终端输出 All services ready 。此时你可以访问代理聊天界面http://localhost:4280– 在这里与你的AI服务员对话。汉堡订单看板http://localhost:5173– 查看所有已下的订单初始为空。MCP服务器状态http://localhost:3000– 可以访问其根路径查看基础信息。步骤四开始你的第一次AI点餐在http://localhost:4280的聊天框中尝试输入“菜单里有什么汉堡”“给我推荐一个辣的汉堡。”“我要点一个经典芝士堡多加酸黄瓜和培根。” 观察右侧的“Agent Thoughts”面板你会看到LangChain智能体一步步的思考过程“用户想点餐 - 我需要调用get_burgers工具来获取菜单 - 调用place_order工具下单”。这就是智能体工作的可视化。踩坑记录第一次运行npm start时可能会因为端口占用而失败。确保本地3000、4280、5173、7071、7072这几个端口空闲。如果遇到“EADDRINUSE”错误可以使用lsof -ti:端口号 | xargs kill -9Mac/Linux或netstat -ano | findstr :端口号后taskkill /PID PID号 /FWindows来结束占用进程。4. 核心实现LangChain.js智能体与MCP工具调用理解了架构并让项目跑起来后我们来深入最核心的部分LangChain.js智能体是如何与MCP工具协同工作的。这是将AI从“聊天机器人”升级为“能干事儿的智能体”的关键。4.1 构建LangChain智能体智能体的核心代码位于packages/agent-api/src目录下。其创建过程可以概括为以下几个步骤初始化LLM首先需要创建一个LLM实例。在云端部署时它连接的是Azure OpenAI或OpenAI在本地运行时它连接的是我们配置的Ollama。import { ChatOpenAI } from langchain/openai; const llm new ChatOpenAI({ modelName: process.env.AZURE_OPENAI_MODEL, azureOpenAIApiKey: process.env.AZURE_OPENAI_API_KEY, azureOpenAIEndpoint: process.env.AZURE_OPENAI_API_ENDPOINT, // ... 其他配置如温度temperature控制创造性 });创建MCP工具集这是与MCP服务器交互的桥梁。项目使用了modelcontextprotocol/sdk和LangChain的适配器。import { Client } from modelcontextprotocol/sdk/client/index.js; import { McpTools } from ./mcp-tools.js; // 自定义的封装类 // 创建MCP客户端并连接到MCP服务器 const client new Client({ name: burger-agent }, { version: 1.0.0 }); await client.connect(new StdioClientTransport({ command: node, args: [...] })); // 或HTTP传输 // 将MCP客户端暴露的工具转换为LangChain能识别的Tool对象 const tools await McpTools.fromClient(client);McpTools.fromClient方法内部会调用MCP的tools/list协议获取服务器提供的所有工具及其参数Schema然后动态创建出一组LangChain Tool对象。组装智能体使用LangChain的createReactAgent助手将LLM和工具组合起来。ReActReasoning Acting是一个经典的智能体框架让模型学会“思考一步执行一步”。import { createReactAgent } from langchain/langgraph/prebuilt; const agentExecutor createReactAgent({ llm, tools, // 可以传入自定义的提示词System Prompt来指导代理的行为 // 例如“你是一个友好的汉堡店助手帮助用户浏览菜单和下单...” });执行与流式响应当API收到用户消息时它会调用agentExecutor.invoke()。为了提供更好的用户体验项目实现了流式响应将智能体的“思考过程”和“最终回答”逐步返回给前端。const stream await agentExecutor.stream({ input: userMessage }, { configurable: { thread_id: sessionId } }); for await (const chunk of stream) { // chunk可能包含agent思考、工具调用、工具结果、最终回答 sendToFrontend(chunk); // 通过Server-Sent Events (SSE)发送到前端 }4.2 MCP服务器的实现剖析MCP服务器packages/burger-mcp的角色是“翻译官”它将业务API的RESTful接口“翻译”成MCP协议定义的工具。其核心是实现MCP服务器接口并注册工具处理函数。import { Server } from modelcontextprotocol/sdk/server/index.js; import { StdioServerTransport } from modelcontextprotocol/sdk/server/stdio.js; const server new Server( { name: burger-mcp, version: 1.0.0 }, { capabilities: { tools: {} } } // 声明本服务器提供工具能力 ); // 注册工具获取所有汉堡 server.setRequestHandler(ListToolsRequestSchema, async () { return { tools: [ { name: get_burgers, description: Get a list of all burgers in the menu, inputSchema: { type: object, properties: {}, // 此工具无需参数 }, }, // ... 注册其他工具如 place_order ], }; }); // 处理工具调用请求 server.setRequestHandler(CallToolRequestSchema, async (request) { switch (request.params.name) { case get_burgers: // 在这里调用真正的汉堡APIhttp://localhost:7071/api/burgers const burgers await fetchBurgerApi(/burgers); return { content: [{ type: text, text: JSON.stringify(burgers) }] }; case place_order: const { userId, items, nickname } request.params.arguments; // 验证参数调用下单API const order await fetchBurgerApi(/orders, { method: POST, body: { userId, items, nickname } }); return { content: [{ type: text, text: Order placed successfully! Order ID: ${order.id} }] }; default: throw new Error(Unknown tool: ${request.params.name}); } }); // 启动服务器通过stdio或HTTP await server.connect(new StdioServerTransport());关键点MCP服务器本身不包含复杂的业务逻辑它只是一个代理层。真正的数据操作读写数据库发生在packages/burger-api这个独立的Functions应用中。这种分离确保了业务逻辑的纯粹性和可测试性。4.3 工具调用流程的完整拆解让我们通过一个具体的用户请求“点一个牛肉汉堡”来追踪一次完整的工具调用用户输入消息从前端发送到Agent API。意图识别LangChain智能体基于配置的LLM分析输入判断用户意图是“下单”并且识别出实体“牛肉汉堡”。工具选择与调用智能体从工具列表中选择了place_order工具。它根据工具的Schema需要userId,items等参数来构造调用。这里有一个隐含步骤智能体可能需要先调用get_burgers来查找“牛肉汉堡”对应的产品ID。MCP协议通信LangChain的MCP工具适配器将调用请求封装成MCP协议格式通过HTTP或stdio传输发送给Burger MCP Server。工具执行MCP服务器收到callTool请求解析出工具名和参数然后代表智能体去调用真正的Burger APIPOST /api/orders。业务处理Burger API收到请求验证数据在Cosmos DB中创建一条新订单记录并返回订单ID。结果返回结果沿着原路返回Burger API-Burger MCP Server-MCP Client-LangChain Tool-LangChain Agent。生成回复智能体收到工具执行结果“订单创建成功ID: 123”将其作为上下文生成最终的自然语言回复“好的已为您下单牛肉汉堡订单号是123请稍等。”流式输出整个思考、调用、回复的过程被拆分成多个chunk通过SSE流式传输回前端用户可以看到代理“正在思考”、“调用工具”、“生成回答”的实时效果。实操心得调试MCP工具调用时MCP Inspector是一个神器。运行npx -y modelcontextprotocol/inspector在浏览器中打开它连接到你的MCP服务器如http://localhost:3000/mcp你就可以手动测试每一个工具查看输入输出这比看日志要直观得多。它能帮你快速定位是工具定义有问题、参数不对还是底层API调用失败。5. 部署到Azure从本地到生产的一键之旅在本地玩转之后你可能想把它部署到云端提供一个可公开访问的演示或者作为更复杂项目的基础。项目使用Azure Developer CLI (azd) 提供了极其顺畅的部署体验。5.1 部署前置条件与资源规划在运行azd up之前需要做好几项准备Azure账户拥有一个有效的Azure账户。新用户可以申请 免费账户 其中包含一定额度的免费信用点足够运行这个示例一段时间。账户权限你的账户需要具备创建和管理资源的权限例如“所有者”、“参与者”或“用户访问管理员”。通常订阅的所有者角色即可。资源命名与位置azd up会提示你输入环境名称如my-burger-agent和位置如eastus。环境名称会作为所有创建资源名称的前缀请使用小写字母和数字。位置选择离你或你的目标用户近的区域通常eastus或westeurope是不错的选择。成本预估这是一个无服务器架构在无人访问时成本几乎为零。主要潜在成本来自Azure OpenAI Service如果你使用GPT-4等高级模型按Token计费。示例中默认使用GPT-4o-mini成本极低。Azure Cosmos DBServerless模式按请求单元RU和存储量计费。对于演示级别的流量每月费用可能只有几美元。 你可以使用项目提供的 Azure定价计算器链接 进行更精确的估算。5.2 一步步执行部署部署过程几乎是自动化的但理解每一步在做什么很重要# 1. 克隆你的仓库如果是Fork的 git clone your-forked-repo-url cd mcp-agent-langchainjs # 2. 登录Azure azd auth login # 这会打开浏览器完成Azure账户认证。 # 3. 一键部署 azd up执行azd up后会发生以下事情引导CLI会询问订阅、环境名、位置。资源预配CLI读取infra/目录下的Bicep模板在Azure上创建所有必要资源资源组、Azure OpenAI资源、Cosmos DB数据库、多个Azure Functions应用、Static Web Apps等。应用部署将各个packages/下的代码分别构建并部署到对应的Functions或Static Web Apps。环境配置将数据库连接字符串、API密钥等敏感信息安全地配置为各个Function App的应用设置。输出结果部署完成后终端会打印出所有服务的访问URL例如代理Web应用的URL。针对学生或免费账户的特殊配置如果你使用的是Azure for Students或免费试用订阅其附带的Azure OpenAI资源有容量限制。在运行azd up之前需要先设置一个环境变量azd env set AZURE_OPENAI_MODEL_CAPACITY 1这确保Bicep模板会创建符合免费层限制的资源规格。但这样创建的Azure OpenAI资源可能无法使用。因此你还需要配置使用外部的OpenAI兼容端点如Groq、Together AI或本地Ollama的云端代理azd env set AZURE_OPENAI_ALT_ENDPOINT https://api.openai.com/v1 azd env set AZURE_OPENAI_API_KEY your_openai_api_key_here azd env set AZURE_OPENAI_MODEL gpt-4o-mini5.3 部署后的验证与监控部署成功后访问azd up输出的代理Web App URL。尝试进行与本地相同的对话。现在你的AI代理正在Azure的全球基础设施上运行查看实时订单访问Burger Web App的URL你可以看到一个订单看板所有通过代理下的订单都会实时显示在这里。检查Function日志在Azure Portal中进入部署的Function App名称类似xxx-agent-api在“监控”部分可以查看日志流观察智能体的每一次调用和MCP工具的交互详情。清理资源当你不再需要这个演示环境时务必运行以下命令来删除所有资源避免产生意外费用azd down --purge这个命令会删除整个资源组及其内部所有资源。避坑指南部署中最常见的错误是配额不足。例如在某些订阅中Azure OpenAI资源的部署需要申请审批。如果azd up失败请仔细查看错误信息。通常你需要去Azure Portal的“订阅” - “使用情况配额”页面找到“Azure OpenAI”服务申请增加配额或启用该服务。另一个常见问题是Cosmos DB账户名全局冲突如果提示“名称已存在”只需在azd up时换一个不同的环境名即可。6. 扩展与自定义打造你自己的AI代理这个汉堡店代理是一个完美的起点你可以基于它构建属于自己的AI应用。以下是几个扩展方向6.1 添加新的MCP工具假设你想让代理也能推荐饮料。你需要创建或扩展现有MCP服务器在packages/burger-mcp/src/tools/下新增一个工具定义例如get_drink_recommendation。// 在 tools/list 处理函数中注册新工具 { name: get_drink_recommendation, description: Get a recommended drink based on the burger ordered or weather, inputSchema: { type: object, properties: { burgerType: { type: string, description: Type of burger ordered }, weather: { type: string, enum: [hot, cold, rainy], description: Current weather } }, required: [burgerType] } }实现工具处理逻辑在callTool处理函数中添加对新工具名的判断并实现你的推荐逻辑可以调用一个饮料API或者只是简单的规则匹配。更新代理配置由于MCP工具是动态发现的Agent API中的McpTools.fromClient会自动获取到这个新工具无需修改代理代码。智能体在下一次运行时就能“看到”并使用这个新工具。6.2 集成其他MCP服务器MCP的魅力在于可组合性。你可以让代理同时连接多个MCP服务器。例如你可以保留现有的burger-mcp服务器处理点餐。新增一个weather-mcp服务器提供查询天气的工具。新增一个calendar-mcp服务器提供查询用户日程的工具。然后在Agent API中初始化多个MCP客户端连接到不同的服务器并将它们提供的所有工具合并后传给LangChain智能体。这样你的代理就能实现更复杂的任务“如果明天是晴天中午12点我没事就帮我订一个汉堡外卖到公司。”6.3 自定义智能体行为通过修改Agent API中的提示词System Prompt你可以塑造代理的“性格”和回复风格。const systemPrompt You are Burgy, the enthusiastic and slightly cheesy assistant for ByteBurgers, a futuristic burger joint. You love burgers and are here to help customers browse our menu, place orders, and check on their status. Always be friendly, use burger-related puns occasionally, and if youre not sure about something, ask for clarification. Never make up information about burgers or prices—always use the tools provided to get the real data.;将这个提示词传入createReactAgent的配置中可以显著改变代理的对话风格。6.4 前端界面定制packages/agent-webapp是一个基于现代前端框架如React、Vue或Svelte具体看项目实现的应用。你可以轻松地修改其UI组件、颜色主题或者增加新的功能比如语音输入、订单历史图表等。由于它通过API与后端通信只要接口不变前端可以自由重构。7. 常见问题与故障排除实录在实际操作中你可能会遇到一些问题。这里记录了一些常见情况及解决方法。7.1 本地运行问题问题现象可能原因解决方案npm install失败网络问题或Node.js版本过低确保Node.js 22。尝试使用npm install --registryhttps://registry.npmmirror.com国内镜像或检查网络连接。npm start时某个服务启动失败端口被占用本地有其他程序占用了3000、4280等端口。使用lsof -ti:3000Ollama模型加载慢或无响应模型文件过大或内存不足。尝试更小的模型如qwen2.5:3b。确保Ollama服务已启动ollama serve。检查任务管理器确保内存充足。代理回答“我不知道”或胡言乱语本地模型能力不足或提示词未生效。1. 尝试更好的模型如llama3.2。2. 检查.env文件中的模型名是否与Ollama拉取的完全一致。3. 在Agent API中检查并强化System Prompt。MCP Inspector 连接失败MCP服务器未启动或URL错误。确保npm start已成功启动所有服务且burger-mcp服务在运行。检查Inspector中配置的URL是否为http://localhost:3000/mcp如果是HTTP传输。7.2 部署到Azure问题问题现象可能原因解决方案azd up失败提示“配额不足”订阅对某些资源如特定区域的VM、OpenAI服务有数量或能力限制。1. 在Azure Portal中申请提高配额。2. 换一个Azure区域如从eastus换到westus2重新部署。3. 对于学生订阅务必先设置AZURE_OPENAI_MODEL_CAPACITY1并使用外部OpenAI端点。azd up失败提示“资源名称无效或已存在”环境名或某些资源名称全局不唯一。使用更独特、全小写的环境名重新运行azd up。部署成功后Web应用打开报错或白屏前端静态资源构建失败或API后端未启动。1. 去Azure Portal查看Static Web App和Function App的部署日志寻找错误信息。2. 检查Function App的“配置”中环境变量如数据库连接字符串是否正确注入。3. 使用azd monitor命令查看实时日志。代理能聊天但无法下单/获取菜单MCP服务器或Burger API部署/连接有问题。1. 检查burger-mcp和burger-api这两个Function App是否正常运行在Azure Portal中查看状态。2. 查看agent-api的日志看它在调用MCP工具时是否报错如网络超时。3. 确认Cosmos DB连接字符串正确且数据库/容器已自动创建。7.3 MCP与代理逻辑问题问题现象可能原因解决方案代理不调用工具直接基于知识库回答LLM的System Prompt可能未明确指示其使用工具或者工具描述不够清晰。1. 强化System Prompt“你必须使用提供的工具来获取实时信息不要依赖内部知识。” 2. 在MCP服务器中优化工具的描述description使其更精确地匹配用户可能的问题。工具调用参数错误LLM未能正确理解用户意图并映射到工具参数。1. 在工具Schema中提供更详细的参数描述和示例。2. 考虑在Agent逻辑中加入“参数澄清”步骤当LLM提供的参数不完整时让代理主动反问用户。GitHub Copilot不识别本地MCP工具VS Code的MCP配置文件路径或内容有误。确保项目根目录下的.vscode/mcp.json文件配置正确并且Copilot Chat已启用。尝试在VS Code中重新加载窗口CtrlShiftP - “Developer: Reload Window”。在Copilot Chat中可以尝试用#burger-mcp前缀来提示它使用特定工具。这个项目就像一个功能齐全的“乐高套装”为你提供了构建生产级AI代理所需的所有模块。从本地开发到云部署从核心的LangChain.js智能体到前沿的MCP协议集成它覆盖了现代AI应用开发的完整链路。通过拆解、运行并扩展它你不仅能掌握这些具体的技术更能建立起如何将AI能力与真实业务系统连接起来的系统性思维。