企业官网建设流程全解析

2026 年的 AI 应用开发，已经不是“调 API、写 prompt”就能撑住的阶段了。项目中只要涉及多步骤决策、外部工具调用、多轮状态维护，LangChain、MCP、LangGraph 这三个关键词就一定会出现。它们的关系并不复杂：LangChain 负责把大模型和工具编排起来，MCP 负责把外部工具接入标准化，LangGraph 负责把多步骤流程变成可控状态图，最后落地的形态就是 Agent。

这篇文章的核心不是讲概念，而是走一遍最小可运行链路：环境配置、定义工具、写 Agent、接 MCP、用 LangGraph 搭一个多步工作流，再把它封装成 API，跑一个批量任务。整个过程会尽量贴工程实践，不绕弯，不堆术语。你跟着做完一遍，至少能知道 Agent 项目从“能跑”到“能交付”之间到底隔了哪些关键节点。

先交代硬件与门槛：如果走纯 API 模式，只需要 Python 3.10+、一个模型 API Key 和网络，完全没有显卡压力；如果要本地模型推理，硬件门槛取决于模型大小，常见的 7B 量化模型建议 8G 以上显存，没有独显也能用 CPU 跑但速度会明显下降。这看起来是现代 AI 项目里非常标准的门槛，但真正卡住人的往往不是显卡，而是依赖环境、状态管理和工具调用接口没有理顺。

1. 核心能力速览

先给一张规格表，方便快速判断这个技术栈适不适合你。

这套组合最明显的优势是“分层清晰”。LangChain 负责模型与工具之间的胶水，MCP 负责统一工具接入格式，LangGraph 负责管理复杂流程的分支和状态。单独拆开每一个都够用，但它们组合起来才是 2026 年 Agent 应用的主流骨架。

2. 四个核心概念：别再搞混 LangChain、MCP、LangGraph 和 Agent

很多人第一次接触这套技术栈时，最常问的问题是“它们之间到底有什么区别”。这里用一个表格先做出区分，然后逐一说清楚。

2.1 LangChain：不是“一个库”，而是一整套编排生态

LangChain 最核心的贡献是让“模型调用”这件事变得更工程化。你可以用统一的接口对接不同模型供应商，可以用 Prompt 模板复用提示词，可以把一个普通函数包装成 Agent 可调用的工具，也可以快速做 RAG 检索。

但在 2026 年这个时间点，LangChain 已经不适合当作“全部答案”。它更准确的定位是“基础工具箱”：模型接口、输出解析、工具包装、记忆管理这些能力，LangChain 都能给。真正复杂的状态流转和分支逻辑，建议交给 LangGraph 处理。

2.2 MCP：把“工具接入”变成标准协议

MCP 全称 Model Context Protocol，解决的是“每一家服务都要写一套自定义工具接入”的问题。它把文件操作、数据库查询、HTTP 请求、浏览器操作、设计工具能力等封装成标准接口，供 Agent 按统一格式调用。

从热门生态来看，MCP 已经延伸到很多方向：游戏引擎工具链、UI 设计工具、数据平台、自动化和办公软件都在接入。它的存在让 Agent 的工具生态从“每个工具一套 SDK”变成了“一套协议访问所有工具”。

2.3 LangGraph：把流程从混沌循环变成可控状态图

普通 Agent 是一个 while 循环：让模型决定下一步调用什么工具，然后重复直到任务完成。这种模式在简单场景下很自然，但一旦需要固定流程、条件分支、人工审核、多角色协作，单纯循环就会变得很难维护。

LangGraph 用图的方式显式定义节点和边。每个节点是一个计算步骤，每条边决定下一步走到哪里，所有中间结果都存在状态对象里。这样 Agent 的每一步都是可观测、可回放、可中断恢复的。

2.4 顺带说清：Computer Use 与 MCP 不是一回事

搜索里经常把 Computer Use 和 MCP 放在一起比较，这里值得说明。Computer Use 是指让模型直接操作计算机界面，比如移动鼠标、点击按钮、输入文字，本质是“模拟人去操作系统”；MCP 则是通过协议直接调用工具的编程接口，比如查询数据库、写文件、调 HTTP API，本质是“让程序之间标准化通信”。

在实际项目中，两者可以互补：需要操作没有 API 的旧系统时，Computer Use 更合适；目标系统提供 API 时，MCP 更快、更稳定。不要因为名字里都有“工具连接”就把它们混成同一个东西。

2.5 适用场景与使用边界

这套组合真正适合的场景，是“目标明确但路径不固定”的任务。例如：让 Agent 根据用户查询去查数据库、再写一份 Markdown 报告；让 Agent 搜集多个数据源后做对比分析；让 Agent 按照固定的质检流程逐项检查输入内容并输出结构化结果。这些场景里，Agent 需要决策、需要调用多个工具、需要维护中间状态，正是 LangChain + MCP + LangGraph 的强项。

不适合的场景也很明显：如果只是单轮问答、一次性文案生成、简单分类任务，直接用大模型调用接口更轻快，引入全套 Agent 编排反而增加复杂度和延迟。

安全与合规边界一定要前置考虑。当 Agent 被允许调用外部工具时，它就有了“行动能力”。所有工具调用必须限定在合法授权范围内：访问数据库要确认账号权限，抓取网页要遵守目标站点条款，处理用户隐私数据要遵守相关法规。涉及人脸、声音、版权素材的场景，更要确认授权链完整。任何工具接入上线前，都应先在隔离环境做权限测试。

3. 2026 年 LangChain + MCP + LangGraph 环境准备

在写第一行代码之前，先把环境准备好。下面是一个经过整理的通用检查清单，适用于大多数 Windows / macOS / Linux 开发机。

3.1 基础环境清单

3.2 创建虚拟环境并安装核心依赖

建议所有项目都在虚拟环境里运行，避免系统 Python 环境被污染。

# 创建虚拟环境，python 版本需要 3.10+ python -m venv venv # 激活虚拟环境，Windows 用 venv\Scripts\activate，macOS/Linux 用 source venv/bin/activate source venv/bin/activate # 升级 pip pip install --upgrade pip # 安装核心依赖 pip install langchain langgraph mcp openai fastapi uvicorn python-dotenv

如果你在国内网络环境，pip 安装失败时可以使用清华镜像源：

pip install -i https://pypi.tuna.tsinghua.edu.cn/simple langchain langgraph mcp openai fastapi uvicorn python-dotenv

3.3 配置模型访问

新建一个.env文件，保存模型密钥和基础地址。

OPENAI_API_KEY=你的_key_或者_sk-xxx OPENAI_BASE_URL=https://api.openai.com/v1 MODEL_NAME=gpt-4o-mini

如果使用本地模型，可以指向 Ollama 或其他 OpenAI 兼容服务：

OPENAI_API_KEY=ollama OPENAI_BASE_URL=http://127.0.0.1:11434/v1 MODEL_NAME=qwen2.5:7b

这里的关键是保持“OpenAI 兼容接口”这一层抽象。只要模型服务提供 OpenAI 兼容 API，LangChain 就可以用同一套代码切换在线和本地模型。

4. 最小 Agent 启动：先跑通一条主链路

第一次做 Agent 项目，不要一上来就多智能体、图工作流、几十个工具。先把最小链路跑通：一个模型、一个工具、一个 Agent。

4.1 定义一个计算工具并创建 Agent

下面代码中，我定义了add和get_current_time两个工具，然后创建了一个 ReAct 模式的 Agent。ReAct 的意思是模型会先推理（Reason），再决定调用什么工具（Act），然后根据工具结果继续推理。

import os from dotenv import load_dotenv from langchain_openai import ChatOpenAI from langchain.agents import create_react_agent, AgentExecutor from langchain.tools import tool from langchain_core.prompts import PromptTemplate load_dotenv() # 初始化模型 llm = ChatOpenAI( model=os.getenv("MODEL_NAME", "gpt-4o-mini"), temperature=0, ) # 定义工具：加法计算 @tool def add(a: int, b: int) -> int: """计算两个整数相加的结果。""" return a + b # 定义工具：获取当前时间 @tool def get_current_time() -> str: """返回当前系统时间，适合回答时间相关问题。""" import datetime return datetime.datetime.now().strftime("%Y-%m-%d %H:%M:%S") tools = [add, get_current_time] # ReAct Agent 提示词模板，这里使用最简模板 prompt = PromptTemplate.from_template("Answer the following questions as best you can. You have access to tools: {tools}. Use the following format:\nQuestion: the input question\nThought: you should always think about what to do\nAction: the action to take, should be one of [{tool_names}]\nAction Input: the input to the action\nObservation: the result of the action\n... (this Thought/Action/Action Input/Observation can repeat N times)\nThought: I now know the final answer\nFinal Answer: the final answer to the original input question\n\nQuestion: {input}\nThought: {agent_scratchpad}") agent = create_react_agent(llm, tools, prompt) agent_executor = AgentExecutor(agent=agent, tools=tools, verbose=True, handle_parsing_errors=True)

4.2 运行 Agent 并观察链路

# 测试 1：纯工具调用 result1 = agent_executor.invoke({"input": "请计算 12345 + 67890 等于多少"}) print("结果1：", result1["output"]) # 测试 2：混合问题 result2 = agent_executor.invoke({"input": "当前时间是什么，并且计算 3 和 5 的和"}) print("结果2：", result2["output"])

预期输出不是最重要的，重要的是verbose=True时打印出的中间过程。你会看到模型先输出 Thought，再输出 Action，再拿到 Observation，最后给出 Final Answer。这代表 Agent 的核心决策循环已经跑通了。

4.3 判断成功与排查方向

如果结果里出现工具返回值，并且 Final Answer 引用该返回值，说明链路成功。如果 Agent 直接给出答案但没有调用工具，可能是模型选择跳过工具，也可能是 prompt 中没有强调“必须使用工具”。如果报Could not parse LLM output，通常是模型输出格式不符合 ReAct 模板，可以开启handle_parsing_errors=True并检查 prompt。

这一步跑通后，再往里面加 MCP 和 LangGraph 就有了稳定的地基。

5. MCP 实战：让 Agent 通过标准协议接入外部工具

MCP 的核心价值在“接入标准”。假设你想让 Agent 读取一个文件、查一次数据库、调一个 HTTP 接口，传统做法是用 LangChain 的@tool一个个封装。工具少还好，工具一旦多了，每个工具的入参、鉴权、错误处理都不一样，代码很快就失控。

MCP 的做法是定一个统一协议：服务端暴露工具，客户端负责发现和调用。Agent 不需要关心工具背后的实现语言和部署位置，只要走 MCP 协议即可。

5.1 用 Python 实现一个最简 MCP Server

可以用mcp官方 Python SDK 写一个最简 Server。下面代码里我创建了一个“加法工具”和“文件读取工具”，用来模拟真实工具服务。

# server.py from mcp.server.fastmcp import FastMCP mcp = FastMCP("demo-tools") @mcp.tool() def add(a: int, b: int) -> int: """计算两个整数相加的结果。""" return a + b @mcp.tool() def read_txt_file(path: str) -> str: """读取指定 txt 文件的文本内容。""" with open(path, "r", encoding="utf-8") as f: return f.read() if __name__ == "__main__": mcp.run(transport="stdio")

运行这个服务：

python server.py

注意，当前示例使用stdio作为传输层，这意味着 MCP Server 由父进程拉起，并通过标准输入输出通信。如果是远程服务，可以改成streamable-http或sse模式，但最终配置方式要根据你使用的 MCP Client SDK 来确定。

5.2 LangChain 接入 MCP 工具

不同版本的 LangChain MCP 适配器 API 略有差异。下面给出一个思路性的通用流程，实际代码以官方文档为准：

1. 启动 MCP Server 进程。
2. 用langchain-mcp-adapters或其他适配器将 MCP 工具转换为 LangChain 工具列表。
3. 将工具列表传给 Agent 或 LangGraph 节点。

# 伪代码示意，实际 API 需要按你使用的适配器版本调整 # from langchain_mcp_adapters.client import load_mcp_tools # from mcp import ClientSession, StdioServerParameters # 创建会话并加载工具 mcp_tools = await load_mcp_tools( server_params=StdioServerParameters( command="python", args=["server.py"], ) ) # 将 MCP 工具与 LangChain 工具合并 all_tools = mcp_tools

这个阶段最容易踩的坑是“工具名冲突”。MCP Server 里的工具名和本地@tool函数名不能重复，否则 Agent 调用时可能路由错误。

5.3 MCP 使用的合规边界

MCP 让 Agent 拥有了“执行能力”，这既是优势也是风险。接入数据库前，必须用只读账号测试；接入文件系统时，应限定在沙箱目录内；接入 HTTP 服务时，要确认目标服务的鉴权和调用频率限制。生产环境不要直接给 Agent 开放所有系统权限，尽量按最小权限原则配置。

6. LangGraph 实战：把 Agent 变成可控状态工作流

有了最小 Agent，很多人以为就够了。但真实业务里，“连续做三步，其中第二步根据第一步结果走不同分支”是刚需。LangGraph 的价值在于把流程画成图，每个步骤都能被观察和控制。

6.1 一个最简单的 LangGraph 状态图

先看一个最小示例：一个状态对象，经过两个节点，最终输出。

from langgraph.graph import StateGraph, START, END from typing import TypedDict class State(TypedDict): messages: list def node_setup(state: State): return {"messages": state["messages"] + ["已初始化上下文"]} def node_summary(state: State): return {"messages": state["messages"] + ["已生成摘要"]} # 构建图 graph = StateGraph(State) graph.add_node("setup", node_setup) graph.add_node("summary", node_summary) graph.add_edge(START, "setup") graph.add_edge("setup", "summary") graph.add_edge("summary", END) app = graph.compile() # 运行 result = app.invoke({"messages": []}) print(result["messages"])

预期输出是：

['已初始化上下文', '已生成摘要']

这个示例虽然简单，但已经体现了 LangGraph 和普通 Agent 的关键差异：节点顺序是显式的，状态是跨节点传递的，流程是可追踪的。

6.2 用 LangGraph 做“检索 + 工具调用 + 总结”工作流

实际项目中更常见的需求是：用户输入问题，Agent 先决定是否检索资料，再调用工具，最后总结。这个流程如果写成普通 ReAct 循环，每一步模型都有“自由发挥”的空间；用 LangGraph 则可以把步骤固定下来。

from langgraph.graph import StateGraph, START, END from typing import TypedDict, Optional class WorkflowState(TypedDict): question: str search_keyword: Optional[str] search_result: Optional[str] final_answer: str def decide_search(state: WorkflowState): # 这里可以调用模型判断是否需要检索，简化处理：只要包含“资料”就设置关键词 if "资料" in state["question"]: return {"search_keyword": state["question"].replace("资料", "").strip()} return {"search_keyword": None} def search_web(state: WorkflowState): if state["search_keyword"] is None: return {"search_result": "无需检索"} # 实际项目里可以替换为搜索引擎 API 或内部知识库 return {"search_result": f"模拟检索结果：{state['search_keyword']}"} def generate_answer(state: WorkflowState): state["final_answer"] = f"基于检索结果生成回答：{state['search_result']}" return state graph = StateGraph(WorkflowState) graph.add_node("decide", decide_search) graph.add_node("search", search_web) graph.add_node("answer", generate_answer) graph.add_edge(START, "decide") graph.add_conditional_edges( "decide", lambda state: "search" if state["search_keyword"] else "answer", ) graph.add_edge("search", "answer") graph.add_edge("answer", END) app = graph.compile() result = app.invoke({"question": "请帮我查找 Python 资料"}) print(result["final_answer"])

这里的核心在add_conditional_edges：根据decide节点的结果决定走向。没有 LangGraph 时，这种分支逻辑要在代码里手写if/else加循环管理，状态多了之后很难维护。

如果你需要多轮对话能力，LangGraph 还支持Checkpointer保存状态。这样 Agent 请求中断后可以恢复上下文，而不是每次重新构建历史。

6.3 LangGraph 增加外部能力的思路

关于“LangGraph 怎么增加 skill”，本质上是两类操作：增加工具节点，或增加普通计算节点。工具节点可以加载前面定义的 MCP 工具，普通计算节点则做数据清洗、格式转换、人工审核等业务逻辑。模型不是所有步骤都必须参与，只有需要“理解力”的节点才接入 LLM，这样既能节省 Token 又能提高流程稳定性。

7. API 化与批量任务：从脚本走向服务

Agent 脚本跑通了还不够，工程落地时通常需要暴露 HTTP 接口，并支持批量执行。

7.1 用 FastAPI 封装 Agent 接口

下面用 FastAPI 写一个最简封装，把 Agent 或 LangGraph 工作流暴露为 HTTP 服务。

# api.py import os from dotenv import load_dotenv from fastapi import FastAPI from pydantic import BaseModel from langchain_openai import ChatOpenAI from langchain.agents import create_react_agent, AgentExecutor from langchain.tools import tool load_dotenv() app = FastAPI(title="Agent API") # 初始化模型和 Agent llm = ChatOpenAI(model=os.getenv("MODEL_NAME", "gpt-4o-mini"), temperature=0) @tool def add(a: int, b: int) -> int: """计算两个整数相加的结果。""" return a + b # 简化示例：这里省略 ReAct prompt 详细配置，实际开发建议模块化 # from langchain.agents import initialize_agent # agent_executor = initialize_agent(tools=[add], llm=llm, agent="zero-shot-react-description") class AgentRequest(BaseModel): prompt: str @app.post("/agent/run") def run_agent(req: AgentRequest): # 实际调用 agent_executor，这里用简化逻辑说明结构 result = {"output": f"模拟 Agent 输出：{req.prompt}"} return {"status": "ok", "result": result["output"]} # 健康检查 @app.get("/health") def health(): return {"status": "alive"}

启动服务：

uvicorn api:app --host 127.0.0.1 --port 8000

注意，上面的示例中 Agent 部分做了简化标注。实际项目应该把 Agent 初始化逻辑提取成独立模块，API 层只负责请求校验和结果返回，避免每个请求都重复创建模型实例。

7.2 curl 测试接口

服务启动后，用 curl 验证接口是否通：

curl -X POST http://127.0.0.1:8000/agent/run \ -H "Content-Type: application/json" \ -d '{"prompt": "请计算 2 和 3 的和"}'

7.3 批量任务：循环、并发与失败重试

批量任务的实现不需要一开始就上 Celery。先用简单的顺序循环或线程池，确认逻辑稳定后再升级队列。

import json import time import requests # 读取任务配置 with open("batch_config.json", "r", encoding="utf-8") as f: config = json.load(f) prompts = config["prompts"] output_dir = config["output_dir"] for idx, prompt in enumerate(prompts): try: resp = requests.post(config["api_url"], json={"prompt": prompt}, timeout=120) resp.raise_for_status() data = resp.json() with open(f"{output_dir}/result_{idx}.json", "w", encoding="utf-8") as f: json.dump(data, f, ensure_ascii=False, indent=2) print(f"[OK] {idx}: {prompt[:20]}") except Exception as e: print(f"[FAIL] {idx}: {e}") # 简单重试一次 time.sleep(2)

配置文件示例：

{ "api_url": "http://127.0.0.1:8000/agent/run", "prompts": [ "计算 1 加 1", "计算 10 加 20", "计算 100 加 200" ], "output_dir": "./outputs" }

批量任务最容易出现的问题是“单条失败拖垮整个批”。建议每个任务独立捕获异常、独立写结果文件，并记录失败原因。任务量大时再加上最大重试次数、超时控制和并发数上限。

7.4 接口安全提醒

FastAPI 服务启动后默认没有鉴权。如果只是本机调试，绑定127.0.0.1就够了；如果要部署到服务器，至少加 API Key 校验，并把服务放在内网网关之后。Agent 拥有工具调用能力，接口暴露在公网等于把工具权限暴露在公网，这是一条必须守住的底线。

8. 资源占用与性能观察

LangChain + MCP + LangGraph 这套技术栈的资源消耗和传统 Web 服务不同，瓶颈往往不是 CPU 或显存，而是 Token 消耗和工具调用耗时。

8.1 不同运行模式的资源观察重点

如果走本地模型路线，推荐先量化再部署。常见 7B 模型 4bit 量化后占用约 4-6G 显存，有条件可以先用小模型验证整个链路，再切到更大模型。显存占用需要以实际模型版本和推理参数为准，不同量化方式差异很大。

8.2 上下文长度是隐藏成本

Agent 每次调用模型时，都要把历史消息、系统提示词、工具定义、工具返回结果拼进上下文。上下文越长，Token 消耗越大，响应越慢。建议对工具返回结果做截断，只返回必要字段；多轮对话时定期裁剪历史消息，或者用摘要替代完整历史。

8.3 LangGraph 状态大小控制

LangGraph 把所有节点中间结果都放到状态对象里，状态字段设计得越宽，内存压力和后续检索成本越高。建议只保存下一步需要的字段，不要把大段原始数据堆在状态中。可以定期清理messages历史或写入外部存储。

9. 常见问题与排查方法

排查口诀是：先看日志，再拆链路，最后查依赖。Agent 项目里大量问题不是模型不够聪明，而是工具返回格式没处理好、状态字段对不上、依赖版本不一致。

10. 最佳实践与使用建议

第一，先把最小链路跑通再扩展。第一次实验建议只用一个模型、两个工具、一个 Agent，确认模型能正确调用工具后，再引入 MCP 和 LangGraph。

第二，工具函数要“单一职责”。一个工具只做一件事，描述里写清楚“什么时候用、参数代表什么、返回值是什么”。模型是靠描述决定是否调用工具的，描述写得不清晰，Agent 就会选择跳过。

第三，把配置和密钥外置。模型名、API Key、数据库地址都不要写死在代码里，用.env或配置中心管理。密钥文件加入.gitignore。

第四，给批量任务加日志、超时和失败重试。上线前先跑一个 3-5 条的小批量样本，确认输出格式稳定，再跑全量。

第五，关注状态管理和上下文成本。LangGraph 的状态字段尽量精简，历史消息按策略裁剪，工具返回体做截断。Token 消耗要提前预估，不要等月底账单出来再吃惊。

第六，从开发第一天就考虑合规。Agent 的所有工具调用都应该有权限边界和审计日志。谁在什么时间调用了哪个工具，执行了哪些操作，这些记录既是排查问题的依据，也是合规审计的底稿。

11. 总结与下一步

这套技术栈里最值得优先尝试的是“最小 Agent + MCP Server + LangGraph 工作流”三件套。你先用 LangChain 跑通模型调工具，再用 MCP 把外部能力接入标准化，最后用 LangGraph 把流程固定成可控状态图，整个过程约两小时就能完成首轮验证。

最先要验证的是两件事：工具是否真的被模型调用，状态流转是否符合预期。如果这两个环节稳定，后面的 API 封装和批量任务只是工程量问题，不算技术风险。

最容易踩的坑分别是依赖版本不齐、工具函数 schema 写错、线程阻塞导致接口超时。这三类问题都不会直接报出“你这里写错了”，而是以启动失败、解析失败或超时的形式出现，排查时要有耐心。

后续可以继续扩展的方向包括：接入 RAG 增强知识库能力、做多智能体协作流程、加上 LangSmith 或 Langfuse 做可观测性、把批量任务升级为独立消息队列。也可以尝试把当前链路接到本地模型上，对比 Token 成本和响应速度，找到适合自己业务的性价比方案。

建议收藏备用。工具链还在快速演进，但只要掌握了“模型 + 工具 + 状态图”这个核心骨架，后续版本怎么变，你都能很快跟上。