本文深入探讨了动态工具选择在大模型应用中的重要性，指出静态全量绑定工具的弊端，并详细介绍了三种动态工具选择策略：向量语义检索、LLM二阶路由和规则+语义混合。文章强调了工具描述质量对选择准确率的影响，并提出了多轮对话中工具重选的必要性。最后，分享了生产环境中常见的四个坑及修复方法，为程序员提供了一套完整的动态工具选择解决方案。

很多同学刚开始搭 Agent 时，第一反应是「把所有工具都塞进去」。20个工具全绑上 LLM，然后让模型自己选。结果上线后发现：token 消耗暴涨三倍，模型选错工具的概率超过 30%，偶尔还会出现「幻觉调用」——工具压根不存在，模型自己编了一个名字出来。

根本原因就是没搞懂动态工具选择的底层逻辑。工具列表不是越多越好，关键是在对的时机，把对的工具，用对的方式塞给模型。

1、 为什么「把所有工具都绑上去」是一个坑

先说一个真实项目的数据对比：

方案	工具数量	单次调用 token 消耗	工具选错率	延迟
全量绑定（静态）	50个	~8000 tokens	28%	3.2s
动态选择（语义检索）	50个→3个	~1200 tokens	6%	1.1s
动态选择（LLM路由）	50个→5个	~2400 tokens	4%	1.8s

token 消耗降了 6 倍，选错率降了 4-5 倍。

为什么差距这么大？

原因一：上下文窗口污染

每个工具定义大约需要 100-300 tokens 来描述（名称 + 参数 + 说明）。50个工具就是 5000-15000 tokens 的「噪音」塞进 system prompt。模型在里面找对的工具，就像让人在杂乱的仓库里找一把螺丝刀——找到的概率和找错的概率都会上升。

原因二：工具间干扰

功能相近的工具会互相干扰模型的判断。比如你有 search_web、search_database、search_knowledge_base 三个工具，全部塞进去时，模型经常犹豫、选错，甚至同时调用两个。

原因三：成本是实打实的

GPT-4o 的 token 价格是 $5/百万 tokens（input）。一天 10 万次调用，静态方案每次 8000 tokens vs 动态方案每次 1200 tokens，一个月省下来的成本能买台服务器。

结论：动态工具选择不是「优化」，是生产环境的基本功。

---

2 、三种动态工具选择策略：钱、速度、准确率的三角博弈

动态工具选择本质上是一个「预筛选」问题——在真正调用 LLM 之前，先把候选工具集从 N 个缩减到 3-5 个。有三种主流策略：

策略一：向量语义检索（最省钱）

把工具描述文本做成向量，每次请求进来时，用用户 query 的向量做相似度搜索，取 Top-K 个工具传给 LLM。

用户 query: "帮我查一下上海今天的天气"
       ↓ embedding
query向量: [0.2, -0.8, 0.5, ...]
       ↓ 相似度搜索
候选工具:
  1. weather_query    相似度: 0.92
  2. location_search  相似度: 0.61
  3. web_search       相似度: 0.48
       ↓
传给 LLM 的工具: [weather_query, location_search, web_search]

优点：纯本地计算，延迟低（<50ms），无额外 LLM 调用
缺点：依赖工具描述的质量，描述写得烂就检索不准

策略二：LLM 二阶路由（最准确）

用一个轻量级 LLM（比如 GPT-4o-mini 或本地 Qwen-7B）做第一层路由，输出工具 ID 列表，再把这些工具传给主 LLM。

用户 query → 路由 LLM（小模型） → ["weather_query", "location_search"] → 主 LLM（大模型）

优点：准确率最高，小模型能理解复杂意图
缺点：多一次 LLM 调用，延迟增加 200-500ms，有成本

策略三：规则+语义混合（最稳健）

先用规则/关键词做硬过滤（比如识别到「天气」就强制包含 weather 相关工具），再用语义检索补充 2-3 个候选工具。

用户 query
    ↓
规则匹配 → 命中"天气": 强制包含 [weather_query]
    ↓
语义检索 → Top-2: [location_search, web_search]
    ↓
合并去重 → [weather_query, location_search, web_search]
    ↓
传给 LLM

优点：高频场景 0 错误率，兜底稳健
缺点：规则维护成本，新工具要手动添加规则

怎么选？

• 工具数量 < 20 个，且描述清晰 → 方案一
• 工具数量 20-100 个，业务复杂 → 方案三（混合）
• 工具数量 > 100 个，或语义模糊 → 方案二

---

3、方案一实战：向量检索动态工具选择（LangGraph TypeScript）

这里用 LangGraph + OpenAI Embeddings 实现完整的向量动态工具选择。

Step 1：定义工具注册表和向量索引

import { tool } from "@langchain/core/tools";
import { OpenAIEmbeddings } from "@langchain/openai";
import { z } from "zod";

// 定义工具集
const allTools = [
  tool(
    async ({ city }) => `${city} 今天晴，26°C，东南风3级`,
    {
      name: "weather_query",
      description: "查询指定城市的实时天气信息，包含温度、风向、天气状况",
      schema: z.object({ city: z.string().describe("城市名称") }),
    }
  ),
  tool(
    async ({ query }) => `搜索结果：${query} 相关内容...`,
    {
      name: "web_search",
      description: "在互联网上搜索最新信息、新闻、技术文档",
      schema: z.object({ query: z.string().describe("搜索关键词") }),
    }
  ),
  tool(
    async ({ expression }) => eval(expression).toString(),
    {
      name: "calculator",
      description: "执行数学计算，支持加减乘除、幂运算、三角函数",
      schema: z.object({ expression: z.string().describe("数学表达式") }),
    }
  ),
  tool(
    async ({ symbol }) => `${symbol} 当前价格：$150.25，涨跌：+2.3%`,
    {
      name: "stock_price",
      description: "查询股票实时价格和涨跌幅",
      schema: z.object({ symbol: z.string().describe("股票代码") }),
    }
  ),
  tool(
    async ({ from, to, amount }) => `${amount} ${from} = ${amount * 7.2} ${to}`,
    {
      name: "currency_exchange",
      description: "货币汇率换算，支持美元、欧元、人民币等主流货币",
      schema: z.object({
        from: z.string(),
        to: z.string(),
        amount: z.number(),
      }),
    }
  ),
];

// 构建工具向量索引
const embeddings = new OpenAIEmbeddings({ model: "text-embedding-3-small" });

// 预计算所有工具描述的向量（启动时执行一次）
const toolDescriptions = allTools.map(t => `${t.name}: ${t.description}`);
const toolVectors = await embeddings.embedDocuments(toolDescriptions);

// 工具注册表：id → { tool, vector }
const toolRegistry = allTools.map((t, i) => ({
  tool: t,
  vector: toolVectors[i],
}));

上图展示了 Step 1 的核心流程：把每个工具的 name + description 拼成一段文本，批量送入 embeddings.embedDocuments()，一次性得到 5 个浮点向量。这一步在服务启动时执行一次，运行时不再重算。toolRegistry 就是一张「工具 → 向量」的映射表，后续所有检索都查它。

Step 2：实现余弦相似度检索

// 余弦相似度计算
function cosineSimilarity(a: number[], b: number[]): number {
  const dot = a.reduce((sum, val, i) => sum + val * b[i], 0);
  const normA = Math.sqrt(a.reduce((sum, val) => sum + val * val, 0));
  const normB = Math.sqrt(b.reduce((sum, val) => sum + val * val, 0));
  return dot / (normA * normB);
}

// 动态检索 Top-K 工具
async function selectTools(query: string, topK: number = 3) {
  const queryVector = await embeddings.embedQuery(query);
  
  const scored = toolRegistry.map(({ tool, vector }) => ({
    tool,
    score: cosineSimilarity(queryVector, vector),
  }));
  
  // 按相似度降序排列，取 Top-K
  scored.sort((a, b) => b.score - a.score);
  const selected = scored.slice(0, topK);
  
  console.log("动态选择的工具：");
  selected.forEach(({ tool, score }) => {
    console.log(`  - ${tool.name}: ${score.toFixed(3)}`);
  });
  
  return selected.map(({ tool }) => tool);
}

上图展示了 Step 2 的检索过程：用户 query 先经过 embedQuery() 变成向量，再用余弦公式 dot(a,b) / (|a|·|b|) 和注册表里每个工具向量逐一打分，最终按分数降序取 Top-K。余弦相似度值域 [-1, 1]，越接近 1 说明语义越相似。整个过程纯内存运算，延迟 <10ms，比调一次 LLM 便宜几个数量级。

Step 3：LangGraph 集成——select_tools 节点

import { Annotation, StateGraph, ToolNode, END } from "@langchain/langgraph";
import { ChatOpenAI } from "@langchain/openai";
import { HumanMessage, AIMessage } from "@langchain/core/messages";

// 状态定义：添加 selectedTools 字段
const AgentState = Annotation.Root({
  messages: Annotation<(HumanMessage | AIMessage)[]>({
    reducer: (x, y) => x.concat(y),
    default: () => [],
  }),
  selectedTools: Annotation<typeof allTools>({
    reducer: (_, y) => y,  // 直接替换，不追加
    default: () => [],
  }),
});

const llm = new ChatOpenAI({ model: "gpt-4o-mini", temperature: 0 });

// select_tools 节点：根据最新消息动态选择工具
async function selectToolsNode(state: typeof AgentState.State) {
  const lastMessage = state.messages[state.messages.length - 1];
  const query = lastMessage.content as string;
  
  // 动态检索 Top-3 工具
  const selectedTools = await selectTools(query, 3);
  
  return { selectedTools };
}

// agent 节点：用动态选择的工具调用 LLM
async function agentNode(state: typeof AgentState.State) {
  const { messages, selectedTools } = state;
  
  // 关键：每次都重新绑定，确保 LLM 只看到精选工具
  const llmWithTools = llm.bindTools(selectedTools);
  const response = await llmWithTools.invoke(messages);
  
  return { messages: [response] };
}

// 判断是否需要调用工具
function shouldContinue(state: typeof AgentState.State) {
  const lastMessage = state.messages[state.messages.length - 1] as AIMessage;
  if (lastMessage.tool_calls && lastMessage.tool_calls.length > 0) {
    return "tools";
  }
  return END;
}

// 构建图
const graph = new StateGraph(AgentState)
  .addNode("select_tools", selectToolsNode)
  .addNode("agent", agentNode)
  .addNode("tools", new ToolNode(allTools))  // ToolNode 持有完整工具集，执行时无需筛选
  .addEdge("__start__", "select_tools")
  .addEdge("select_tools", "agent")
  .addConditionalEdges("agent", shouldContinue, {
    tools: "tools",
    [END]: END,
  })
  .addEdge("tools", "select_tools")  // 工具执行后重新选择（多轮场景）
  .compile();

// 运行
const result = await graph.invoke({
  messages: [new HumanMessage("上海今天天气怎么样？")],
});
console.log(result.messages[result.messages.length - 1].content);

上图是完整的 LangGraph 执行图。关键设计有两点：① select_tools 节点负责"挑工具"，每轮对话都重新跑一次向量检索，把最新 Top-3 工具写入 State；② agent 节点用 bindTools(selectedTools) 把精选工具绑给 LLM，而 ToolNode 持有完整工具集负责实际执行——两者职责分离，互不干扰。工具执行完后回到 select_tools 重新检索，确保多轮对话中每轮都用最合适的工具。

关键细节：ToolNode 持有完整工具集负责执行，agentNode 里用 bindTools(selectedTools) 只让 LLM 看到精选工具。两者分开，互不干扰。

---

4、 方案三实战：规则 + 语义混合选择

向量检索对语义清晰的 query 效果很好，但遇到「帮我把100美元换成人民币然后买一点苹果股票」这类复合意图，相似度排名容易漏掉某个工具。混合策略更稳。

// 工具规则映射：关键词 → 强制包含的工具名
const toolRules: Record<string, string[]> = {
  天气: ["weather_query"],
  温度: ["weather_query"],
  股票: ["stock_price"],
  涨跌: ["stock_price"],
  汇率: ["currency_exchange"],
  换算: ["currency_exchange"],
  搜索: ["web_search"],
  计算: ["calculator"],
  多少: ["calculator"],
};

async function hybridSelectTools(query: string, topK: number = 4) {
  // Step 1: 规则硬匹配
  const forcedToolNames = new Set<string>();
  for (const [keyword, toolNames] of Object.entries(toolRules)) {
    if (query.includes(keyword)) {
      toolNames.forEach(name => forcedToolNames.add(name));
    }
  }
  
  const forcedTools = allTools.filter(t => forcedToolNames.has(t.name));
  console.log("规则强制工具：", forcedTools.map(t => t.name));
  
  // Step 2: 语义检索补充（排除已命中的工具）
  const remaining = allTools.filter(t => !forcedToolNames.has(t.name));
  const remainingRegistry = toolRegistry.filter(r => !forcedToolNames.has(r.tool.name));
  
  const supplementCount = Math.max(0, topK - forcedTools.length);
  let semanticTools: typeof allTools = [];
  
  if (supplementCount > 0 && remainingRegistry.length > 0) {
    const queryVector = await embeddings.embedQuery(query);
    const scored = remainingRegistry.map(({ tool, vector }) => ({
      tool,
      score: cosineSimilarity(queryVector, vector),
    }));
    scored.sort((a, b) => b.score - a.score);
    semanticTools = scored.slice(0, supplementCount).map(s => s.tool);
    console.log("语义补充工具：", semanticTools.map(t => t.name));
  }
  
  // Step 3: 合并
  return [...forcedTools, ...semanticTools];
}

// 测试复合意图
const tools = await hybridSelectTools("帮我把100美元换成人民币然后买一点苹果股票");
// 规则强制工具: ["currency_exchange", "stock_price"]
// 语义补充工具: ["calculator"]
// 最终: ["currency_exchange", "stock_price", "calculator"]

5、 工具描述工程：影响选择准确率的隐藏变量

做了上面的代码之后，很多同学发现选择准确率还是上不去。真正的问题往往不在算法，在工具描述。

来看一个真实踩坑的例子：

// ❌ 坏描述：模糊、缺少触发场景
tool(weatherFn, {
  name: "weather",
  description: "获取天气",
  // ...
})

// ✅ 好描述：明确触发词、用途、参数语义
tool(weatherFn, {
  name: "weather_query", 
  description: [
    "查询城市的实时天气状况。",
    "适用场景：用户询问天气、温度、降雨、风速、空气质量。",
    "关键词：天气、晴雨、几度、穿什么衣服、要不要带伞。",
    "参数 city：城市名称，如"上海"、"北京"、"New York"。",
  ].join(" "),
  // ...
})

工具描述质量直接影响向量相似度的准确率。几个原则：

描述要素	作用	示例
适用场景	告诉 LLM 什么时候选这个工具	「用户询问天气、温度…」
关键词列举	提升向量检索召回率	「晴雨、几度、穿衣…」
参数说明	减少 LLM 填参错误	「city：城市名称，如"上海"」
反向排除	避免与相似工具冲突	「不适用于历史天气查询，历史天气用 weather_history」

---

6、 多轮对话中的工具重选：每轮重新计算还是复用？

工具选择是在每轮对话都重新计算，还是复用上一轮的结果？这是一个经常被忽视的问题。

// 场景：多轮对话
// 第1轮："上海天气怎么样？" → 选了 [weather_query, web_search, ...]
// 第2轮："那100美元能换多少人民币？" → 话题完全切换了！

// ❌ 错误做法：第2轮复用第1轮的工具，结果 weather_query 还在，currency_exchange 没选上
function shouldContinue(state) {
  const lastMessage = ...;
  if (lastMessage.tool_calls?.length > 0) {
    return "tools";  // 直接去执行，没有重新选工具
  }
}

// ✅ 正确做法：每次回到 agent 前，先过一遍 select_tools 节点
.addEdge("tools", "select_tools")  // 工具执行后重新选择
.addEdge("select_tools", "agent")

图中 tools → select_tools → agent 这条边的设计，就是为了保证每轮对话都基于最新 query 重新检索工具。代价是多一次向量检索（<50ms），换来多轮场景的准确率。

值不值得？非常值。

---

7、 常见坑：我在生产中摔过的四个跟头

坑 1：工具执行失败时，模型选了第二顺位的工具继续调

症状：weather_query 报错，模型自动改调 web_search 查天气，结果格式不对，下游解析崩。
原因：没有处理工具错误的降级逻辑，模型在 context 里看到错误，自己「脑补」了降级路径。
修复：在 ToolNode 外包一层错误处理，错误统一返回标准格式，别让模型自己决定降级。

const safeToolNode = async (state) => {
  try {
    return await toolNode.invoke(state);
  } catch (error) {
    // 返回标准错误消息，让 agent 节点决定下一步
    return {
      messages: [new ToolMessage({
        content: JSON.stringify({ error: error.message, code: "TOOL_ERROR" }),
        tool_call_id: state.messages.at(-1)?.tool_calls?.[0]?.id ?? "",
      })],
    };
  }
};

坑 2：Top-K 设为 2，但正确答案排第 3

症状：某些 query 的工具选不到，模型输出「我没有对应的工具」。
原因：工具描述质量差 + K 值太小，正确工具被排除在外。
修复：先把 K 调到 5，观察一周，根据实际日志调整到合适值。

坑 3：工具向量没有随工具更新

症状：加了一个新工具，但 Agent 从不选它。
原因：工具向量是启动时预计算的，新工具加进代码后忘了重建索引。
修复：工具注册表变更时触发向量重建，或者用增量更新。

// 工具注册表变更时调用
async function rebuildToolIndex() {
  const descriptions = allTools.map(t => `${t.name}: ${t.description}`);
  const vectors = await embeddings.embedDocuments(descriptions);
  // 更新 toolRegistry...
}

坑 4：语义检索选了功能相近但参数不匹配的工具

症状：用户问「搜一下最新的 AI 新闻」，选了 search_internal_doc（搜内部文档的工具），而不是 web_search。
原因：两个工具描述都含「搜索」，向量相似度接近。
修复：在工具描述里加「反向排除」：「本工具仅用于内部知识库，不适用于互联网搜索」。

---

总结

这篇我们从头到尾拆解了动态工具选择的完整方案：

• 静态全量绑定是生产毒药：50个工具全绑上去，token 消耗涨 6 倍，选错率超 25%

• 向量检索是基础方案：预计算工具描述向量，每次请求 <50ms 检索 Top-K，成本最低

• 混合策略最稳健：规则硬命中 + 语义补充，复合意图下零漏召

• 工具描述工程是隐藏变量：准确率的上限不在算法，在描述质量，加适用场景、触发词、反向排除

• 每轮重新选工具：多轮对话话题切换时，复用上轮工具是最常见的坑之一

• 错误降级要显式设计：别让模型自己决定降级路径，统一用标准错误格式兜底

  最后

2026年技术圈的分化愈发明显：降薪裁员潮持续蔓延，传统开发、测试等岗位大批缩水，不少从业者陷入职业焦虑；与之形成鲜明对比的是，AI大模型相关岗位迎来疯狂扩招，薪资逆势飙升150%，大厂更是直接开出70-100W年薪，疯抢具备实战能力的大模型人才，甚至放宽年龄限制，只求能快速落地技术、创造价值！

很多程序员、职场新人纷纷入局大模型领域，绝非盲目跟风，而是实实在在看到了不可替代的价值优势，这也是2026年最值得抓住的职业风口：

1、窗口期红利，入门门槛友好：不同于成熟赛道的“内卷式招聘”，2026年大模型人才缺口巨大，简历只要达标（掌握基础AI应用+具备简单项目经验），年龄、学历均非硬性要求，小白可快速入门，转行程序员也能无缝衔接；

2、技术可复用，上手速度翻倍：如果你有前后端开发、测试、数据分析等基础，在大模型落地、系统部署、Prompt工程等环节会更具优势，无需从零开始，复用原有技术能力就能快速进阶；

3、懂业务更吃香，竞争力翻倍：单纯懂技术已不够，2026年大厂更看重“技术+业务”的复合型人才，有垂直领域（金融、医疗、工业等）经验者，能精准定位模型落地痛点，薪资比纯技术岗高出30%以上；

更重要的是，即便没有转型需求，用AI大模型工具为工作赋能、提升效率，也已经成为80%企业的硬性要求——不会用大模型提效，未来很可能被行业淘汰！

那么2026年，小白/程序员该如何高效学习大模型？

很多人想入门大模型，却陷入两大困境：要么到处搜集零散资料，不成体系，越学越懵；要么被收费高昂的课程割韭菜，花了钱却学不到实战技能，白白浪费时间走弯路。

今天就给大家精心整理了一份2026年最新、免费、系统化的AI大模型学习资源包，覆盖从零基础入门到商业实战、从理论沉淀到面试通关的全流程，所有资料均已整理归档，无需拼凑，直接领取就能上手学习，小白可照做，程序员可进阶！

👇👇扫码免费领取全部内容👇👇

1、大模型系统化学习路线

这份学习路线结合2026年行业趋势和新手学习规律，由行业专家精心设计，从零基础到精通，每一步都有明确指引，帮你节省80%的无效学习时间，少走弯路、高效进阶，避免踩坑。

2、从0到进阶大模型学习视频教程

从入门到进阶这里都有，跟着老师学习事半功倍。

3、大模型学习书籍&电子文档

涵盖2026年最新技术要点，包括基础入门、Transformer核心原理、Prompt工程、RAG实战、模型微调与部署等内容

4、AI大模型最新行业报告

报告包含腾讯、阿里、甲子光年等权威机构发布的核心内容，还有2026年中文大模型基准测评报告、AI Agent行业研究报告等，帮你站在行业前沿，把握技术风口。

5、大模型项目实战&配套源码

项目包含Deepseek R1、GPT项目、MCP项目、RAG实战等热门方向，还有视频配套代码，手把手教你从0到1完成项目开发，既能练手提升技术，又能丰富简历，为求职和职业发展加分。

6、2026大模型大厂面试真题

2026年大模型面试已全面升级，不再单纯考察基础原理，而是转向侧重技术落地和业务结合的综合考察，很多程序员和新手因为缺乏针对性准备，明明技术不错，却在面试中失利。

适用人群

四阶段学习规划（共90天，可落地执行）

第一阶段（10天）：初阶应用

该阶段让大家对大模型 AI有一个最前沿的认识，对大模型 AI 的理解超过 95% 的人，可以在相关讨论时发表高级、不跟风、又接地气的见解，别人只会和 AI 聊天，而你能调教 AI，并能用代码将大模型和业务衔接。

• 大模型 AI 能干什么？
• 大模型是怎样获得「智能」的？
• 用好 AI 的核心心法
• 大模型应用业务架构
• 大模型应用技术架构
• 代码示例：向 GPT-3.5 灌入新知识
• 提示工程的意义和核心思想
• Prompt 典型构成
• 指令调优方法论
• 思维链和思维树
• Prompt 攻击和防范
• …

第二阶段（30天）：高阶应用

该阶段我们正式进入大模型 AI 进阶实战学习，学会构造私有知识库，扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架，抓住最新的技术进展，适合 Python 和 JavaScript 程序员。

• 为什么要做 RAG
• 搭建一个简单的 ChatPDF
• 检索的基础概念
• 什么是向量表示（Embeddings）
• 向量数据库与向量检索
• 基于向量检索的 RAG
• 搭建 RAG 系统的扩展知识
• 混合检索与 RAG-Fusion 简介
• 向量模型本地部署
• …

第三阶段（30天）：模型训练

恭喜你，如果学到这里，你基本可以找到一份大模型 AI相关的工作，自己也能训练 GPT 了！通过微调，训练自己的垂直大模型，能独立训练开源多模态大模型，掌握更多技术方案。

到此为止，大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗？

• 为什么要做 RAG
• 什么是模型
• 什么是模型训练
• 求解器 & 损失函数简介
• 小实验2：手写一个简单的神经网络并训练它
• 什么是训练/预训练/微调/轻量化微调
• Transformer结构简介
• 轻量化微调
• 实验数据集的构建
• …

第四阶段（20天）：商业闭环

对全球大模型从性能、吞吐量、成本等方面有一定的认知，可以在云端和本地等多种环境下部署大模型，找到适合自己的项目/创业方向，做一名被 AI 武装的产品经理。

• 硬件选型

• 带你了解全球大模型

• 使用国产大模型服务

• 搭建 OpenAI 代理

• 热身：基于阿里云 PAI 部署 Stable Diffusion

• 在本地计算机运行大模型

• 大模型的私有化部署

• 基于 vLLM 部署大模型

• 案例：如何优雅地在阿里云私有部署开源大模型

• 部署一套开源 LLM 项目

• 内容安全

• 互联网信息服务算法备案

• …

👇👇扫码免费领取全部内容👇👇

7、这些资料真的有用吗？

这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理，现任上海殷泊信息科技CEO，其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证，服务航天科工、国家电网等1000+企业，以第一作者在IEEE Transactions发表论文50+篇，获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。

资料内容涵盖了从入门到进阶的各类视频教程和实战项目，无论你是小白还是有些技术基础的技术人员，这份资料都绝对能帮助你提升薪资待遇，转行大模型岗位。

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