调用大模型的两种方法

调用方法一response client.chat.completions.create( modelkimi-k2.6, messages[ { role: system, content: 你是 SQL 专家只输出 JSON不要输出其他内容。, }, {role: user, content: prompt}, ], temperature0.2, # SQL 生成需要高度确定性 )调用方法二intent llm.invoke(classification_prompt).content.strip().lower()两者本质都是调用大模型最终发往模型服务的请求是完全一致的区别只在于抽象层级和封装程度不同第一个是直接调用模型厂商的原生 API 接口所有请求参数都需要手动组装精细度高、可控性强第二个是调用 LangChain 框架封装好的模型对象框架底层帮你自动完成了参数组装、格式转换写法更简洁。一、第一种原生 SDK 调用generate_sql函数你看到的client.chat.completions.create 完整messages数组是大模型厂商提供的标准 OpenAI 兼容接口的原生写法。1. 为什么必须写完整的messages结构这是大模型 Chat Completions 接口的强制要求模型本身是对话式的必须通过role角色来区分消息身份system系统指令 / 人设、user用户输入、assistant模型回复原生接口不会帮你做任何格式封装你必须严格按照接口规范手动把所有对话内容组装成列表传进去2. 为什么这个函数要用原生写法这个场景有两个强需求原生调用更合适强格式约束需求生成 SQL 并输出 JSON对输出稳定性要求极高需要单独的system角色来给模型强人设、强规则单独的 system 指令比混在用户提示里的约束效果更好精细参数控制需要手动指定模型名称kimi-k2.6、调低temperature0.2还要拿到最原始的响应结构后续手动做 JSON 提取、异常捕获、格式清洗原生调用能拿到完整的响应对象灵活度最高二、第二种LangChain 封装调用run_data_analysis函数你看到的llm.invoke(分类提示词)是LangChain 框架对大模型调用的高层封装。1. 为什么一句话就能完成调用llm是提前初始化好的 LangChain 模型对象比如ChatOpenAI/ChatMoonshot它的invoke()方法底层帮你做了这些重复工作自动把你传入的字符串包装成[{role: user, content: 你的提示词}]的标准 messages 格式自动携带初始化时配置好的模型名、temperature、API Key 等参数自动解析响应直接返回模型的文本内容不用你再写.choices[0].message.content去取值相当于把原生调用里的「组装参数 → 发请求 → 提取结果」三步封装成了一步。2. 为什么这个函数可以用简化写法意图分类是非常简单的单轮场景不需要复杂的多角色对话分类规则直接写在用户提示词里也能正常工作不需要精细控制每一个请求参数复用全局初始化的模型配置即可只需要拿到纯文本结果做分支判断不需要处理复杂的响应结构同时这个函数后续还要对接 LangChain 的 Agent统一用 LangChain 的接口写法和生态组件的兼容性更好三、两种写法的对比与选型表格维度原生 SDK 调用LangChain 封装调用抽象层级底层直接对接模型接口高层框架封装屏蔽细节代码量多需手动组装所有参数少一行完成调用可控性极高所有参数可精细调整中等常用参数已封装格式灵活性强适合自定义解析、异常处理弱统一返回标准格式适用场景结构化输出、多轮对话、强格式约束简单单轮请求、快速开发、对接 Agent 生态四、补充LangChain 也支持完整角色写法不是 LangChain 不能加 system 角色而是这个场景不需要所以用了最简写法。如果需要LangChain 也可以和原生一样传多角色消息python运行from langchain_core.messages import SystemMessage, HumanMessage # 和原生写法效果完全等价 response llm.invoke([ SystemMessage(content你是分类专家只输出一个单词), HumanMessage(contentclassification_prompt) ]) intent response.content.strip().lower()最后总结没有哪种写法绝对更好完全由场景决定需要稳定、精准、自定义解析→ 用原生调用需要简洁、快速、和框架生态联动→ 用封装调用两者底层最终发往大模型的 HTTP 请求本质是完全一样的。