一、自定义中间件

通过实现在代理执行流程中特定节点运行的钩子来构建自定义中间件。
中间件提供了两种类型的钩子来拦截代理执行：

• 节点式钩子 Node-Style hooks
• 缠绕式钩子 Wrap-Sytle hooks

自定义中间件代码实现可使用装饰器和类两种方式。

节点式钩子

在特定执行点顺序运行。用于日志记录、验证和状态更新。可用钩子：

• before_agent Agent开始前（每次调用一次）
• before_model 每次模型调用前
• after_model 每次模型响应后
• after_agent Agent完成后（每次调用一次）

缠绕式钩

当调用处理程序时，拦截执行和控制。用于重试、缓存和转换。你决定调用处理器是零次（短路）、一次（正常流）还是多次（重试逻辑）。可用钩子：

• • wrap_model_call 围绕每个模型调用
• • wrap_tool_call 每次工具调用周边

详情可看官方文档：
https://docs.langchain.com/oss/python/langchain/middleware/custom

1.1 中间件的参数传递机制

1.1.1 ModelRequest/Response

ModelRequest/Response 是单次调用级别的细粒度控制机制：

• • 作用域：仅作用于单次模型或工具调用的生命周期
• • 数据内容：包含当前调用的具体参数（model、messages、tools、config）
• • 类比：类似 HTTP 请求中的 Request 对象，属于瞬态数据
• • 典型来源：@wrap_model_call、@wrap_tool_call、@dynamic_prompt 等包裹式钩子

# ModelRequest 结构示例request = ModelRequest(    model=ChatOpenAI(...),  # 可动态替换的模型实例    messages=[...],         # 本次调用的消息列表（可被修改）    tools=[...],            # 本次可用的工具列表（可被过滤）    runtime=context         # 包含 AgentState 的引用)
``````plaintext
# 典型结构request.model      # 当前要调用的模型实例（可修改）request.tools      # 可用工具列表（可修改）request.messages   # 消息历史request.state      # Agent 的当前状态request.runtime    # 运行时上下文，包含 request.runtime.context 等

关键特性：

• • 可变性：可以在中间件中直接修改 request.model、request.tools 等属性，实现动态路由
• • 信息丰富：携带了完整的执行上下文，便于实现条件逻辑
• • 拦截点：在模型实际调用前，允许审查或修改任何参数

1.1.2 handler: Callable[[ModelRequest], ModelResponse] —— 执行器函数

handler 是实际执行模型调用的函数，它是 LangChain 内部封装的"下一个"执行环节。可以将其理解为：

核心作用：

• • 控制权：可以选择是否调用 handler(request)，甚至多次调用（如重试）
• • 责任链：调用 handler 相当于将请求传递给链条的下一环
• • 不可变性：handler 本身不可修改，但可以通过修改 request 来影响其行为

# handler 本质上等价于：def handler(request: ModelRequest) -> ModelResponse:    # 实际调用 LLM 模型并返回响应    return actual_model_call(request)

1.1.3 AgentState：整个Agent生命周期的全局状态容器

AgentState 具有以下特征：

• • 作用域：贯穿整个 Agent 执行流程，跨多次模型调用
• • 数据内容：完整的对话历史、用户元数据、业务状态字段
• • 类比：类似 Redux Store 或全局上下文，属于持久化数据
• • 典型来源：@before_model、@after_model、@before_agent 等节点式钩子需要跨多次调用持久化数据，或者需要访问完整对话历史

总结：在 @wrap_model_call 和 @wrap_tool_call 等包裹类钩子中，所有 request 字段都可直接赋值修改（框架特批），但 config 除外；在 @before_model、@after_model 等钩子中，只能读取 state，不能访问 request。

参数类型	本质	所属模块	生命周期
ModelRequest	数据类（dataclass）	langchain.agents.middleware.base	单次模型调用
ModelResponse	数据类（dataclass）	langchain.agents.middleware.base	单次模型调用
AgentState	字典结构（TypedDict）	langchain.agents.agent	整个 Agent 会话
handler	函数对象（可调用）	动态传递	单次包装调用

1.2 装饰器dynamic_prompt 动态提示词（wrap_model_call）

from langchain.agents import create_agentfrom langchain.tools import toolfrom langchain.agents.middleware import ModelRequest, ModelResponsefrom langchain.agents.middleware import dynamic_promptfrom typing import TypedDict# 1. 定义一个简单的天气查询工具@tooldefget_weather(city: str) -> str:    """获取指定城市的天气信息。"""    weather_data = {        "北京": "晴朗，气温25°C",        "上海": "多云，气温28°C",        "广州": "小雨，气温30°C"    }    returnf"{city}的天气是：{weather_data.get(city, '未知')}"# 2. 定义上下文结构classContext(TypedDict):    user_role: str# 用户角色# 3. 动态提示函数@dynamic_promptdefrole_based_prompt(request:ModelRequest):    """根据用户角色生成不同提示词"""    user_role = request.runtime.context.get("user_role", "user")    if user_role == "expert":        return"你是一个专业气象分析师，提供详细数据"    elif user_role == "beginner":        return"你是一个友善的导游，用简单语言解释"    else:        return"你是一个简洁的天气助手"# 4. 创建动态 Agentagent_dynamic = create_agent(    model="openai:gpt-4o-mini",    tools=[get_weather],    middleware=[role_based_prompt],  # 注入动态提示    context_schema=Context)print("\n=== 动态 System Prompt（专家角色）===")response2 = agent_dynamic.invoke(    {"messages": [{"role": "user", "content": "北京天气"}]},    context={"user_role": "expert"})print(f"AI: {response2['messages'][-1].content}")print("\n=== 动态 System Prompt（新手角色）===")response3 = agent_dynamic.invoke(    {"messages": [{"role": "user", "content": "北京天气"}]},    context={"user_role": "beginner"})print(f"AI: {response3['messages'][-1].content}")

1.3 使用装饰器实现模型动态切换（wrap_model_call）

from langchain.agents import create_agentfrom langchain.agents.middleware import wrap_model_call, ModelRequest, ModelResponsefrom langchain_openai import ChatOpenAIfrom langchain_core.tools import toolfrom typing importCallable,TypedDict# 定义上下文结构classContext(TypedDict):    user_role: str# 用户角色# 1. 定义两个模型实例small_model = ChatOpenAI(model="gpt-4o-mini")large_model = ChatOpenAI(model="gpt-4o")hard_keywords = ("证明", "推导", "严谨", "规划","复杂", "多步骤", "chain of thought",                     "step-by-step", "reason step by step", "数学", "逻辑证明", "约束求解")# 2. 定义动态模型切换的中间件@wrap_model_callasyncdefdynamic_model_router(    request: ModelRequest,    handler: Callable[[ModelRequest], ModelResponse]) -> ModelResponse:    """    根据对话上下文动态切换模型    """    # 获取当前对话的状态（例如消息列表）    state = request.state    print(f"--- [Middleware] 当前对话状态: {state} ---")    messages = state.get("messages", [])    print(f"--- [Middleware] 当前消息数量: {len(messages)} ---")    # 获取上下文中的用户角色    print(f"打印运行时上下文: {request.runtime.context}")    # === 逻辑判断示例 ===    # 场景 A: 如果对话轮数超过 5 轮，切换到大模型处理复杂上下文    iflen(messages) > 5:        print(f"--- [Middleware] 检测到长对话 ({len(messages)} msgs)，切换至 GPT-4o ---")        # 使用 .override() 方法替换本次调用的模型        request = request.override(model=large_model)    # 场景 B: 如果用户输入包含特定关键词 (仅作演示，实际可用分类器)    elif messages and"复杂分析"in messages[-1].content orany(kw.lower() in messages[-1].content for kw in hard_keywords):         print("--- [Middleware] 检测到复杂任务，切换至 GPT-4o ---")         request = request.override(model=large_model)    else:        print("--- [Middleware] 使用默认小模型 GPT-4o-mini ---")        # 默认使用 create_agent 初始化时传入的模型（即 small_model）    # 继续执行调用    returnawait handler(request)# 3. 定义工具（可选）@tooldefget_weather(city: str):    """查询天气"""    returnf"{city} 的天气是晴天"# 4. 创建 Agent 并注入中间件agent = create_agent(    model=small_model,  # 默认模型    tools=[get_weather],    middleware=[dynamic_model_router],  # <--- 关键：注入动态路由中间件    context_schema=Context    # 上下文类型)# 5. 测试调用print(">>> User: 你好")await agent.ainvoke(    {"messages": [{"role": "user", "content": "你好"}]},    context={"user_role": "expert"})print("\n>>> User: 请进行复杂的市场分析（模拟触发切换）")await agent.ainvoke(    {"messages": [{"role": "user", "content": "请进行复杂的市场分析"}]},    context={"user_role": "expert"})

1.4 persist_session（会话持久化）

中间件类型

after_model - 会话持久化包装器

概述

本示例展示如何使用 persist_session 中间件来实现会话的自动持久化。这是一个简化的接口，用于快速为 Agent 添加持久化能力。

核心特性

1. 自动保存：在 Agent 执行过程中自动保存会话状态
2. 简单易用：作为中间件直接集成

预期结果

每次对话后，会话状态会被保存到指定目录。

# ==================== persist_session 轻量包装器实现 ====================from langchain.agents.middleware import AgentMiddleware, AgentStateimport osimport jsonimport timefrom typing importDict, AnyclassPersistSessionMiddleware(AgentMiddleware):    def__init__(self, path: str):        super().__init__()        self.path = path        ifnot os.path.exists(path):            os.makedirs(path)    defafter_model(self, state: AgentState, runtime) -> None:        """在模型调用后保存会话"""        # 使用当前时间戳作为简单的会话标识或检查点        timestamp = int(time.time())        print(f"打印state以供调试: {state}")        messages = state.get("messages", [])        ifnot messages:            return        # 仅保存最后一条 AI 消息作为演示，或者保存整个历史        filename = os.path.join(self.path, f"state_{timestamp}.json")        # 简化的序列化        serialized_msgs = []        for msg in messages:            msg_data = {                "role": msg.type,                "content": msg.content            }            ifhasattr(msg, 'tool_calls') and msg.tool_calls:                 msg_data['tool_calls'] = msg.tool_calls            serialized_msgs.append(msg_data)        try:            withopen(filename, "w", encoding="utf-8") as f:                json.dump(serialized_msgs, f, ensure_ascii=False, indent=2)            print(f" [persist_session] 会话状态已保存: {filename}")        except Exception as e:            print(f" [persist_session] 保存失败: {e}")defpersist_session(path: str = "./sessions"):    """    persist_session 轻量包装器    Args:        path: 会话持久化保存的目录路径    """    return PersistSessionMiddleware(path)# ==================== 使用示例 ====================from langchain.agents import create_agentfrom langchain_openai import ChatOpenAIfrom langchain_core.messages import HumanMessage# 1. 创建 Agent# 这里我们使用 persist_session 包装器agent = create_agent(    model=ChatOpenAI(model="gpt-4o-mini"),    tools=[],    middleware=[persist_session(path="./my_agent_sessions")])# 2. 运行测试print(">>> 开始 persist_session 演示...")# 第一次交互print("\n>>> User: 这是一个测试消息，请保存。")# 异步调用await agent.ainvoke({"messages": [HumanMessage(content="这是一个测试消息，请保存。")]})

state: AgentState结构展示

{    "messages":[        {            "content":"这是一个测试消息，请保存。",            "additional_kwargs":{},            "response_metadata":{},            "id":"f410d2b9-3ffe-44aa-90a5-9297c7f050ef"        },        {            "content":"抱歉，我无法保存消息或数据。但我可以帮助回答问题或提供信息。如果你有其他需要，随时告诉我！",            "additional_kwargs":{                "refusal":null            },            "response_metadata":{                "token_usage":{                    "completion_tokens":28,                    "prompt_tokens":14,                    "total_tokens":42,                    "completion_tokens_details":{                        "accepted_prediction_tokens":0,                        "audio_tokens":0,                        "reasoning_tokens":0,                        "rejected_prediction_tokens":0                    },                    "prompt_tokens_details":{                        "audio_tokens":0,                        "cached_tokens":0                    }                },                "model_provider":"openai",                "model_name":"gpt-4o-mini-2024-07-18",                "system_fingerprint":"fp_67cf3fed12",                "id":"chatcmpl-CiG1NlFAgsemI2AYyXuMQOMA4HCdw",                "service_tier":"default",                "finish_reason":"stop",                "logprobs":null            },            "id":"lc_run--26def695-569e-479c-8fcb-2f133d47da6b-0",            "usage_metadata":{                "input_tokens":14,                "output_tokens":28,                "total_tokens":42,                "input_token_details":{                    "audio":0,                    "cache_read":0                },                "output_token_details":{                    "audio":0,                    "reasoning":0                }            }        }    ]}

自定义中间件的开发是一个系统工程，需要从需求分析到最终部署的完整流程管理。在需求分析阶段，开发者需要深入理解中间件将要解决的问题域。这不仅仅是技术问题，更是业务问题。开发者需要与业务专家沟通，了解真实的使用场景和期望效果。同时，还需要识别与其他中间件的依赖关系，避免功能冲突和重复开发。设计阶段是整个开发过程中最关键的阶段。优秀的中间件设计应该具备良好的可扩展性和可维护性。这需要考虑类的层次结构、接口的定义、状态管理方案等。设计文档应该详细说明中间件的工作原理、数据流、处理逻辑等，为后续的开发提供清晰的指导。

二、中间件编排黄金法则

2.1 执行顺序设计的哲学思考

middlewares = [    SecurityGuardrail(),                                 # 1. before_agent: 安全检查    RBACMiddleware(),                                    # 2. before_agent & before_model: 权限验证（注入 user_info）    dynamic_system_prompt,                               # 3. @wrap_model_call: 动态提示词注入    dynamic_model_router,                                # 4. @wrap_model_call: 智能模型切换    custom_context_middleware,                           # 5. @wrap_model_call: 上下文管理和清理    ResponseValidator(),                                 # 6. after_model: 响应验证    AuditLogger(),                                       # 7. after_model: 审计日志    ToolMiddleware,                                      # 8. wrap_tool_call: 工具调用拦截和控制]

钩子类型	执行顺序	控制粒度	最佳实践
before_agent	正序	调用级	安全/初始化优先
before_model	正序	单次调用	预算/合规前置
wrap_model_call	嵌套	调用全过程	路由/重试/缓存核心
after_model	逆序	单次调用	验证/日志后置
wrap_tool_call	嵌套	工具执行	参数校验/重试保护

中间件的执行顺序不是简单的排列组合，而是基于系统架构哲学的深度思考。洋葱模型的应用体现了"分层治理"的思想：外层负责安全防护，中层处理业务逻辑，内层保证核心功能，中心提供基础服务。

这种分层的价值在于每一层都有其特定的职责和优先级。安全检查必须在最外层进行，因为任何安全问题都不应该进入到业务处理层面。业务逻辑应该在中间层处理，这样可以确保核心功能的纯粹性。监控和日志记录应该在最内层进行，这样可以不干扰主要的业务逻辑。

提前失败原则是执行顺序设计中的重要原则。通过在最早的可执行点检测问题，可以避免后续的无谓计算。这不仅提高了效率，更重要的是提高了系统的可靠性。当系统发现输入有问题时，应该立即拒绝处理，而不是继续进行复杂的计算后发现问题。

缓存优先原则体现了效率优化的思想。对于相同的请求，系统应该尽量返回缓存的结果，而不是重新计算。这不仅减少了计算资源的消耗，更重要的是提高了响应速度。

2.2 安全优先原则的深度实施

编排黄金法则

1. 安全类永远优先

• • 安全 > 业务 > 成本 > 监控

2. 写操作按依赖排序

• • 如果 B 依赖 A 的写入结果，则 A 必须在 B 之前

3. 中断操作置后

• • 中断类中间件应放在同类型最后

4. 性能开销降序排列

• • 轻量级 → 重量级（快速失败）

核心原则：“先安全，后业务；先读再写，轻量在前；同类型按声明，不同类型按层级”

安全优先不是一句口号，而是需要在系统架构的每个层面得到体现的设计原则。在中间件编排中，安全检查必须前置，这是因为安全问题的代价往往比其他问题要高得多。

分层安全检查是实施安全优先原则的有效方法。身份认证是最外层的安全检查，它确保只有合法用户才能访问系统。输入验证是第二层安全检查，它确保用户输入的内容不包含恶意代码或不当内容。业务授权是第三层安全检查，它确保用户只能执行其权限范围内的操作。合规检查是最内层的安全检查，它确保整个操作符合相关法规要求。

这种分层的安全检查体系不仅提高了系统的安全性，也提高了系统的可维护性。每层的安全检查都相对独立，可以单独进行测试、维护和更新。

2.3 依赖关系管理的复杂性

在复杂的系统中，中间件之间的依赖关系可能非常复杂。正确管理这些依赖关系是保证系统正常运行的关键。

依赖类型分析帮助我们理解不同类型依赖的特点和处理方式：

• • 顺序依赖：最基本的依赖类型，要求特定的执行顺序
• • 条件依赖：更加复杂，要求根据中间结果来决定后续的执行路径
• • 数据依赖：确保下游中间件能够获得上游中间件的输出作为输入

依赖排序策略则提供了处理复杂依赖关系的指导原则：

• • 无依赖的中间件：可以首先执行
• • 单向依赖：按照依赖关系排序
• • 条件依赖：需要特殊的处理逻辑
• • 聚合依赖：需要等待所有相关的中间件完成

2.4 冲突解决机制的设计

在多中间件协作的环境中，冲突是不可避免的。设计良好的冲突解决机制可以保证系统的稳定运行。

资源冲突是最常见的冲突类型。当多个中间件需要同时访问某个资源时，系统需要确保资源的正确分配和使用：

• • 锁机制：可以保证资源的独占访问，但可能会降低系统的并发性能
• • 队列管理：可以提供更公平的资源分配，但可能会增加系统的延迟

结果冲突则涉及多个中间件产生不同结果的情况：

• • 权重决策机制：根据预定义的规则来选择最终结果
• • 投票机制：通过多个中间件的投票来决定最终结果
• • 最终决策者：在某些情况下，可能需要指定最终决策者来处理冲突

三、实际应用场景与最佳实践

3.1 客服机器人中间件方案的深度实践

客服机器人是中间件技术应用最成熟的领域之一。一个设计良好的客服机器人中间件系统不仅能够提高客户满意度，还能显著降低运营成本。

在典型的客服机器人架构中，用户识别中间件扮演着"门卫"的角色。当客户首次接触系统时，这个中间件需要快速识别客户的重要程度、历史问题、个人偏好等信息。VIP 客户可能需要转接到专业客服或使用更高级的服务，而普通客户则可以通过标准的自动化流程得到服务。这种差异化的处理不仅提高了服务效率，也提升了客户体验。

意图理解中间件是整个系统的"大脑"。它需要从客户的自然语言表达中提取真实的意图和情感。这不仅仅是简单的关键词匹配，而是需要理解语言的深层含义。例如，当客户说"这个产品太贵了"时，系统需要理解这可能是价格敏感的信号，或者是在寻求折扣信息，或者是在比较不同产品。

知识检索中间件就像是一个智能图书管理员。它需要从庞大的知识库中快速找到最相关的信息。知识库可能包含产品信息、政策条款、使用指南、故障排除等多个方面的内容。中间件需要根据客户的意图和问题的上下文，从知识库中选择最合适的信息进行回答。

3.2 企业知识助手中间件方案

企业知识助手是一个更加复杂的系统，它需要处理企业内部的各种知识资产，包括文档、数据库、专业知识等。

文档解析中间件负责处理各种格式的企业文档，包括 Word、PDF、Excel 等。这个中间件需要能够提取文档的结构化信息和非结构化内容。对于技术文档，它需要提取技术细节和实施步骤；对于政策文档，它需要提取关键条款和适用范围；对于流程文档，它需要提取操作步骤和责任分工。

知识抽取中间件则负责从解析后的文档中提取有价值的知识点。这个过程涉及到自然语言处理、知识图谱构建、语义分析等高级技术。系统需要理解文档的内容，识别重要的概念、关系、事实等，并将其组织成结构化的知识表示。

语义索引中间件建立企业知识的语义化检索索引。这不仅仅是为了提高检索的准确性，更是为了支持复杂的知识推理和发现。系统需要理解知识之间的关联关系，支持基于语义相似度的检索，以及基于知识图谱的推理查询。

3.3 代码助手中间件方案

代码助手是中间件技术的前沿应用领域，它需要结合软件工程的最佳实践和 AI 技术的最新进展。

代码理解中间件需要具备强大的代码分析能力。它需要理解代码的结构、逻辑、意图和功能。这涉及到语法分析、语义分析、控制流分析、数据流分析等多个层面。系统不仅要理解代码的表面结构，还要理解代码的深层逻辑和设计意图。

语义分析中间件则专注于理解代码的语义含义。它需要识别函数的用途、变量的含义、类的关系、模块的依赖等。这种分析不仅要准确，还要深入。系统需要能够理解设计模式、算法原理、最佳实践等软件工程概念。

最佳实践中间件基于软件工程的最佳实践，为开发者提供改进建议。这包括代码重构建议、性能优化建议、安全性改进建议、测试覆盖率改进建议等。这些建议不是简单的规则匹配，而是基于深度分析和专业知识的智能推荐。

3.4 最佳实践总结与思考

通过这些实际应用场景的深入分析，我们可以总结出中间件系统设计的几个重要原则：

模块化设计是基础。每个中间件都应该有明确的职责边界和功能范围，避免功能重叠和相互干扰。同时，中间件之间应该有清晰的接口定义，保证系统的可维护性。

性能优先是要求。中间件不应该成为系统的性能瓶颈，需要通过各种优化技术来提高处理效率和减少资源消耗。

安全可靠是底线。特别是对于生产环境中的中间件，必须具备完善的错误处理、安全防护和监控机制。

易于扩展是目标。系统设计应该支持新中间件的动态添加和现有中间件的功能升级，保持系统的长期生命力。

四、中间件总结

LangChain 1.0 中间件体系代表了 AI Agent 开发的一个重要发展阶段。它不仅仅是一套技术组件，更是构建可靠、可控、高效 AI 系统的完整方法论。

通过模块化设计，中间件系统实现了功能的解耦和重用。每个中间件都有明确的职责边界，可以独立开发和测试，也可以灵活组合使用。这种设计使得系统具备了良好的可维护性和扩展性。

通过分层架构，中间件系统实现了关注点的分离。安全检查、业务处理、监控记录等功能分别在不同的层次进行处理，避免了功能耦合带来的复杂性。

通过生命周期管理，中间件系统实现了完整的请求处理流程。从输入验证到输出生成，每个环节都有专门的中间件负责，确保了系统的稳定性和可靠性。

通过性能监控，中间件系统具备了自我感知和自我优化的能力。系统可以实时监控自身的运行状态，发现性能瓶颈，进行自动调优。

通过成本控制，中间件系统实现了经济效益的最优化。通过智能的监控和优化机制，系统可以在保证服务质量的前提下，最小化运营成本。

更重要的是，中间件体系体现了一种工程化的思维方式。它将复杂的 AI 问题分解为一系列可控的工程问题，通过标准化、模块化、自动化的方法来解决这些问题。这种思维方式不仅适用于 AI 系统开发，也为其他复杂系统的构建提供了有价值的参考。

随着 AI 技术的不断发展和应用场景的不断扩展，中间件体系也将持续演进和完善。未来的中间件系统可能会引入更多的智能化技术，如机器学习优化、自适应调优、预测性处理等。但无论如何发展，其核心思想——模块化、分层管理、生命周期控制、性能监控和成本优化——将始终是构建可靠 AI 系统的重要基石。

对于每一个致力于 AI Agent 开发的工程师和技术管理者来说，深入理解和掌握中间件技术不仅是技术需要，更是行业发展的必然要求。只有具备了这种系统性的思维和工程化的能力，才能在这个快速发展的领域中保持竞争力，创造出真正有价值的 AI 解决方案。

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】