LangChain调用链路透明化：从黑盒调试到可观测应用开发

1. 从“黑盒”到“白盒”：为什么我们需要看清LangChain的调用链路

如果你最近在折腾大模型应用开发，大概率绕不开LangChain这个名字。它就像一个乐高积木箱，把调用大模型、处理文档、管理记忆这些复杂任务封装成了一个个可拼接的组件（Chain）。刚开始用的时候，感觉真爽，几行代码就能搭出一个能聊天的机器人或者文档问答系统。但用着用着，问题就来了：我的提示词（Prompt）到底是怎么被组装的？大模型返回的结果，在链（Chain）里到底经过了怎样的加工？为什么有时候输出的结果和预期差了十万八千里，我却像在调试一个黑盒，无从下手？

这就是我今天想聊的核心：把LangChain里的历史记录（Memory）和链式调用（Chain）写明白、看明白。这不仅仅是知道ConversationBufferMemory和LLMChain这两个类怎么用，而是要理解数据在它们之间流动的完整轨迹。很多教程只教你怎么“搭起来跑通”，但一个真正能在生产环境稳定运行、便于调试和维护的应用，必须建立在“透明”和“可控”的基础上。最近社区里关于LangGraph的讨论很热，其实LangGraph解决的也是类似问题——通过更直观的图结构来定义和控制工作流。但万变不离其宗，理解基础的Chain和Memory的运作机制，是驾驭任何高级框架的基石。

我经历过无数次这样的调试：用户说“它刚才还答得好好的，现在怎么胡言乱语了？”。没有清晰的调用历史，我只能靠猜——是记忆被污染了？还是某一步的解析（Output Parser）出错了？后来我花了大力气去“照亮”这个黑盒，才发现，问题往往出在一些意想不到的环节，比如上下文窗口超限后被静默截断，或者不同链之间传递的数据格式发生了微妙的变形。所以，这篇文章我会结合实际的代码和场景，带你亲手给LangChain装上“监控探头”和“行车记录仪”，让你不仅能搭出链，更能看清链里发生的每一件事。

2. 链式调用（Chain）的本质：不只是“连接”，更是“数据流管道”

很多人把Chain理解成“把几个步骤连起来”，比如“先检索，再生成回答”。这个理解没错，但太表层了。更准确的比喻是，Chain是一个定义了严格输入输出规范的数据流管道（Pipeline）。每个环节（如一个LLM调用、一个工具调用）都是一个节点，节点之间通过约定的数据格式传递信息。

2.1 一个链的解剖：输入、执行、输出

我们来看一个最简单的链，LLMChain。它的核心三要素是：LLM（大模型）、PromptTemplate（提示词模板）和OutputParser（输出解析器，可选）。

from langchain.prompts import PromptTemplate from langchain_openai import ChatOpenAI from langchain.chains import LLMChain # 1. 定义模板：这里{product}就是一个输入变量 prompt = PromptTemplate.from_template("给我写一句关于{product}的广告语。") # 2. 定义LLM llm = ChatOpenAI(model="gpt-3.5-turbo", temperature=0.7) # 3. 组合成链 chain = LLMChain(llm=llm, prompt=prompt) # 4. 运行链 result = chain.invoke({"product": "智能咖啡杯"}) print(result["text"])

看起来很简单，但内部发生了什么呢？

1. 输入：我们传入一个字典{"product": "智能咖啡杯"}。
2. 模板渲染：Chain内部用这个字典渲染PromptTemplate，生成最终的提示词字符串：“给我写一句关于智能咖啡杯的广告语。”。
3. 调用LLM：将这个字符串发送给ChatOpenAI实例。
4. 接收与解析：收到LLM的回复（一个AIMessage对象），如果定义了OutputParser，就进行解析；否则，直接提取其中的文本内容。
5. 输出：返回一个字典，通常包含text键（LLM的文本回复）和input键（你的原始输入）等信息。

关键点：chain.invoke()返回的result，就是这条管道最终输出的成品。但中间步骤的“半成品”——渲染前的变量、渲染后的完整Prompt、LLM返回的原始Message对象——默认对我们都是隐藏的。

2.2 复杂链与SequentialChain：数据是如何流转的？

单个LLMChain能力有限，真正的应用需要组合多个链。SequentialChain是常用的方式，它按顺序执行多个子链，并将前一个链的输出作为后一个链的输入。

这里就引出了链式调用中最核心也最容易出错的概念：输入/输出键的映射。

from langchain.chains import SimpleSequentialChain, LLMChain # 链1：生成广告语 prompt1 = PromptTemplate.from_template("为{product}写一句广告语。") chain1 = LLMChain(llm=llm, prompt=prompt1, output_key="slogan") # 指定输出键为slogan # 链2：基于广告语写一篇短文 prompt2 = PromptTemplate.from_template("以“{slogan}”为核心，写一篇150字的产品推广短文。") chain2 = LLMChain(llm=llm, prompt=prompt2, output_key="essay") # 组合顺序链 overall_chain = SimpleSequentialChain(chains=[chain1, chain2], verbose=True) # 注意：SimpleSequentialChain要求每个链只有一个输入一个输出，且自动传递 # 对于更复杂的映射，需要使用 SequentialChain from langchain.chains import SequentialChain overall_chain_complex = SequentialChain( chains=[chain1, chain2], input_variables=["product"], # 整个链的初始输入变量 output_variables=["slogan", "essay"], # 整个链的最终输出变量 verbose=True ) result = overall_chain_complex.invoke({"product": "可折叠智能手机"}) print(f"广告语：{result['slogan']}") print(f"推广文：{result['essay']}")

这里有几个至关重要的细节：

1. output_key：在定义chain1时，我们显式指定了output_key="slogan"。如果不指定，默认的output_key是"text"。那么chain2的模板就需要去匹配{text}，而不是{slogan}。键名不匹配是导致链“断掉”、输出为空的常见原因。
2. input_variables与output_variables：在SequentialChain中，你必须清楚地声明整个链的输入变量列表（input_variables）和最终你想获取的输出变量列表（output_variables）。它不会自动推断。output_variables里的每个名字，必须是其对应子链的output_key。
3. verbose=True：这是LangChain内置的初级“调试模式”。设置后，运行时会打印出每个链的输入和输出。这是“写明白”的第一步，务必在开发阶段始终开启。

注意：SimpleSequentialChain用起来简单，但它隐藏了键的映射关系，只适用于极其简单的线性流程。一旦流程稍复杂，或者你需要中间结果，就必须使用SequentialChain并仔细管理输入输出键。

2.3 为什么我的链“哑火”了？常见数据流问题排查

当你发现链没有按预期执行，或者输出是None、空字典时，请按以下顺序排查：

1. 检查模板变量与输入键是否匹配：这是最高频的错误。你的PromptTemplate定义需要{topic}，但invoke时传入的是{"subject": "AI"}。LangChain不会报错，只会将未匹配的变量留空，导致Prompt不完整。
2. 检查子链间的输出/输入键映射：在SequentialChain中，确保前一个链的output_key（如slogan）与后一个链PromptTemplate所需的变量名（如{slogan}）完全一致。大小写敏感。
3. 检查output_variables声明：如果你在SequentialChain的output_variables里写了["final_answer"]，但没有任何一个子链的output_key是"final_answer"，那么最终结果里就不会有这个键。
4. 使用verbose=True：这是最直接的诊断工具。观察打印的日志，看数据在每一步变成了什么样子。是不是在某个环节丢失了？

实操心得：我习惯在项目初期为每个链都显式命名output_key，并且命名要有意义，如"refined_question"、"search_results_json"、"final_answer"，避免全部使用默认的"text"。同时，我会画一个简单的数据流草图，标明每个环节的输入键和输出键，这能极大减少后期调试的混乱。

3. 照亮黑盒：高级日志与追踪（Tracing）方案

verbose=True是基础，但信息有限，且散落在控制台，不利于分析和持久化。要真正“写明白”，我们需要更强大的工具。

3.1 使用回调处理器（Callbacks）记录每一步

LangChain的回调系统允许你在链执行的各个生命周期节点注入自定义逻辑。我们可以用它来捕获并记录详细的历史。

from langchain.callbacks.base import BaseCallbackHandler import json class DetailedLoggingCallback(BaseCallbackHandler): def on_chain_start(self, serialized, inputs, **kwargs): print(f"\n[链开始] 链名称: {serialized.get('name', 'N/A')}") print(f"输入: {json.dumps(inputs, indent=2, ensure_ascii=False)}") def on_chain_end(self, outputs, **kwargs): print(f"[链结束] 输出: {json.dumps(outputs, indent=2, ensure_ascii=False)}") print("-" * 50) def on_llm_start(self, serialized, prompts, **kwargs): print(f"\n[LLM调用开始] 发送的提示词:") for i, p in enumerate(prompts): print(f"Prompt {i}: {p}") def on_llm_end(self, response, **kwargs): print(f"[LLM调用结束] 生成结果: {response.generations[0][0].text}") # 使用回调 callbacks = [DetailedLoggingCallback()] chain = LLMChain(llm=llm, prompt=prompt, callbacks=callbacks) result = chain.invoke({"product": "量子计算机"})

通过继承BaseCallbackHandler并重写on_xx方法，你可以捕获链开始/结束、LLM调用开始/结束、工具调用等事件。这是构建自定义监控系统的基石。

3.2 集成LangSmith：企业级的可观测性平台

如果你需要生产级别的追踪、版本对比、性能分析和团队协作，LangChain官方推出的LangSmith是目前最强大的选择。它提供了一个可视化的界面来追踪每一次链式调用。

配置非常简单：

1. 在LangSmith官网注册并创建API密钥。
2. 设置环境变量：

   export LANGCHAIN_TRACING_V2=true export LANGCHAIN_ENDPOINT="https://api.smith.langchain.com" export LANGCHAIN_API_KEY="你的api-key" export LANGCHAIN_PROJECT="你的项目名" # 可选，用于分类

3. 之后，你所有使用LangChain的代码执行都会被自动记录到LangSmith平台。

在LangSmith的界面上，你可以：

• 完整回放：像看录像一样查看一次调用的完整树状结构，点击每个节点查看详细的输入、输出、提示词、耗时和Token使用量。
• 对比实验：对同一个Prompt运行不同模型或参数，直观对比结果和成本。
• 数据集测试：用一批测试用例批量运行你的链，评估准确性和稳定性。
• 发现瓶颈：清晰看到时间都花在了哪个环节（是检索慢还是LLM生成慢）。

个人体会：对于个人项目，用回调写日志到文件可能就够了。但对于任何严肃的团队项目，LangSmith的投入产出比极高。它把调试从“猜谜游戏”变成了“数据驱动的分析”。特别是当链变得复杂，涉及多个检索器、条件判断时，没有可视化追踪简直寸步难行。它不仅能帮你“写明白”历史，更能帮你“优化”未来。

3.3 手动记录与结构化存储

有时你可能需要将调用历史保存到自己的数据库（如PostgreSQL、MongoDB）中，以便与业务数据关联或进行自定义分析。结合回调系统可以轻松实现。

import uuid from datetime import datetime from your_database_module import get_db_session, TraceRecord # 假设的ORM模型 class DBCallbackHandler(BaseCallbackHandler): def __init__(self, trace_id=None): self.trace_id = trace_id or str(uuid.uuid4()) self.chain_stack = [] # 用于处理嵌套链 def on_chain_start(self, serialized, inputs, **kwargs): chain_name = serialized.get('name', 'Unknown') self.chain_stack.append({ 'name': chain_name, 'start_time': datetime.utcnow(), 'inputs': inputs }) def on_chain_end(self, outputs, **kwargs): if self.chain_stack: chain_info = self.chain_stack.pop() chain_info['end_time'] = datetime.utcnow() chain_info['outputs'] = outputs # 保存到数据库 record = TraceRecord( trace_id=self.trace_id, chain_name=chain_info['name'], inputs=str(chain_info['inputs']), outputs=str(chain_info['outputs']), duration=(chain_info['end_time'] - chain_info['start_time']).total_seconds() ) session = get_db_session() session.add(record) session.commit()

这样，每一次对话或任务执行都有一个唯一的trace_id，链的每一步记录都关联到这个ID，方便你事后进行完整的审计和复盘。

4. 历史记录（Memory）的真相：它不仅仅是“记住”

Memory是LangChain中用于管理对话或应用状态的组件。常见的误解是“Memory就是保存聊天记录”。其实，它的核心功能是在链式调用之间，持久化并管理上下文信息。

4.1 Memory的工作机制：它是链的一个特殊输入

理解Memory的关键在于：Memory对象在链被调用时，会动态地向输入变量中注入内容。

from langchain.memory import ConversationBufferMemory # 创建一个记忆体，它会记住历史对话 memory = ConversationBufferMemory(memory_key="chat_history") # memory_key 指定了注入到输入中的变量名 # 创建一个使用这个记忆体的链 prompt_with_history = PromptTemplate.from_template( """你是一个友好的助手。根据之前的对话和后续问题，给出回答。 之前的对话： {chat_history} 当前问题：{question} 回答：""" ) chain_with_memory = LLMChain( llm=llm, prompt=prompt_with_history, memory=memory, # 将memory对象关联到链 verbose=True ) # 第一次调用 print("=== 第一轮 ===") result1 = chain_with_memory.invoke({"question": "你好，我叫小明。"}) print(result1['text']) # 第二次调用：memory会自动将之前的对话注入到`chat_history`变量中 print("\n=== 第二轮 ===") result2 = chain_with_memory.invoke({"question": "我刚才说我叫什么名字？"}) print(result2['text'])

运行上述代码，并观察verbose=True的日志，你会发现：

• 第一轮调用时，输入是{'question': '你好，我叫小明。'}，因为此时chat_history为空。
• 第二轮调用时，输入变成了{'question': '我刚才说我叫什么名字？', 'chat_history': 'Human: 你好，我叫小明。\nAI: 你好小明！很高兴认识你。'}。ConversationBufferMemory自动将上一轮的问答对格式化后，添加到了输入变量里。

这就是Memory的本质：它是一个在链执行前后自动运行的“中间件”。在链执行前，它从存储（可能是内存、数据库等）中加载历史，并合并到本次调用的输入字典中；在链执行后，它可能将本轮输入输出保存到存储中。

4.2 不同类型的Memory及其适用场景

LangChain提供了多种Memory，区别主要在于它们保存什么、如何格式化以及存储在哪里。

选择建议：

• 新手和简单场景：直接用ConversationBufferMemory，配合verbose=True观察历史是如何被构建和注入的。
• 生产环境长对话：优先考虑ConversationBufferWindowMemory（如k=10），它是成本、效果和复杂度最平衡的选择。
• 需要记忆复杂事实：可以尝试ConversationEntityMemory，或者结合下文要讲的“自定义Memory”来实现。

4.3 Memory的陷阱：为什么它有时“记不住”或“记乱了”

即使理解了原理，Memory在实际使用中还是有很多坑。

陷阱一：Prompt模板与Memory Key不匹配这是最常见的问题。你的Memory设置了memory_key="history"，但PromptTemplate里引用的变量却是{chat_history}。那么Memory中保存的内容永远无法注入到Prompt中。务必保持这两个名称一致。

陷阱二：在链外手动修改Memory状态

# 错误示例 memory.chat_memory.add_user_message("外部添加的消息") chain.invoke({"question": "正常问题"})

如果你直接在memory.chat_memory（底层是ChatMessageHistory）上操作，可能会破坏Memory内部的状态管理逻辑。正确的做法是，所有消息都应该通过链的调用来自然添加，或者使用Memory提供的标准接口（如save_context）。

陷阱三：多个链共享同一个Memory实例导致状态污染

memory = ConversationBufferMemory(memory_key="history") chain_a = LLMChain(llm=llm, prompt=prompt_a, memory=memory) chain_b = LLMChain(llm=llm, prompt=prompt_b, memory=memory) # 共享同一个memory！ chain_a.invoke({"input": "我是A链的话题"}) chain_b.invoke({"input": "我是B链的话题"}) # 此时memory里混杂了A和B的对话，后续调用会混乱。

除非你明确希望两个链共享同一段对话历史（例如同一个聊天会话的不同处理阶段），否则应该为每个独立的对话流创建单独的Memory实例。

陷阱四：Token超限未被处理ConversationBufferMemory会无限制地增长。当历史对话文本长度超过LLM的上下文窗口时，直接将其注入Prompt会导致调用失败。你需要一个“修剪”策略。ConversationBufferWindowMemory和ConversationSummaryMemory是内置的解决方案。对于更复杂的场景，可能需要自定义一个Memory，在保存前检查Token数并智能截断或总结。

实操心得：我建议在开发初期，就把verbose=True和Memory的日志结合起来看。每次调用前，打印一下Memory当前的内容（print(memory.buffer)或print(memory.load_memory_variables({}))），确认即将注入的历史是否符合预期。这能帮你快速定位是Memory没存进去，还是Prompt没引用对。

5. 构建可审计的对话系统：将Memory与Tracing结合

一个健壮的、可调试的对话应用，需要同时做好历史记录（Memory）和调用追踪（Tracing）。Memory保证了单次会话的连续性，Tracing记录了系统内部的决策过程。我们可以将它们结合起来。

5.1 设计思路：为每次对话会话创建全链路追踪

假设我们构建一个客服聊天机器人，我们需要：

1. 每个用户会话有一个唯一ID（session_id）。
2. 这个会话的所有用户消息和AI回复都保存在Memory中，保证对话连贯。
3. 这个会话触发的每一次链式调用（可能包括检索、多步推理等）都有完整的追踪记录，并关联到该session_id。

from langchain.schema import AIMessage, HumanMessage from langchain.memory import ChatMessageHistory import json class AuditableConversationChain: def __init__(self, llm, prompt_template, session_id, tracing_callback): self.session_id = session_id # 使用ChatMessageHistory作为底层存储，便于灵活控制 self.message_history = ChatMessageHistory() # 创建Memory，并绑定到底层的message_history self.memory = ConversationBufferMemory( memory_key="history", chat_memory=self.message_history, # 关键：使用自定义的ChatMessageHistory return_messages=True # 返回Message对象列表，而非字符串 ) self.chain = LLMChain( llm=llm, prompt=prompt_template, memory=self.memory ) # 传入追踪回调，例如之前定义的DBCallbackHandler self.tracing_callback = tracing_callback def invoke(self, user_input): # 1. 在调用链之前，可以记录用户输入（也可由memory自动完成） self.message_history.add_user_message(user_input) # 2. 准备带追踪的调用 inputs = {"input": user_input} try: # 调用链，传入追踪回调 result = self.chain.invoke(inputs, callbacks=[self.tracing_callback]) ai_response = result['text'] except Exception as e: ai_response = f"系统错误：{e}" # 这里也可以记录错误到追踪系统 # 3. 记录AI回复到历史（同样，如果memory配置正确，可能自动完成） self.message_history.add_ai_message(ai_response) # 4. 可选：将本轮完整交互保存到自己的审计日志 self._save_to_audit_log(user_input, ai_response) return ai_response def _save_to_audit_log(self, user_input, ai_response): log_entry = { "session_id": self.session_id, "timestamp": datetime.utcnow().isoformat(), "user_message": user_input, "ai_response": ai_response, "full_history": [msg.dict() for msg in self.message_history.messages] # 保存完整历史快照 } # 写入你的审计数据库或日志文件 print(f"[审计日志] {json.dumps(log_entry, ensure_ascii=False)}")

在这个设计中：

• ConversationBufferMemory负责在链执行时，自动将message_history中的历史消息格式化成字符串，注入Prompt。
• ChatMessageHistory作为中心化的存储，我们直接通过add_user_message和add_ai_message来控制它，逻辑更清晰。
• tracing_callback（如集成LangSmith或自定义回调）记录了链内部执行的详细步骤，包括模型调用、中间结果等。
• _save_to_audit_log方法记录了业务层面的每一次问答对，并关联了session_id和完整的历史快照。

这样，当用户反馈“刚才的回答不对”时，你可以：

1. 通过session_id找到该用户的所有审计日志，看到完整的对话记录（full_history）。
2. 通过session_id和大致时间，在LangSmith或你的追踪数据库里，找到产生那次错误回答的特定链调用轨迹，查看当时的内部状态、检索到的文档、以及LLM收到的具体Prompt，从而精准定位问题根源。

5.2 处理长上下文：超越简单Memory的解决方案

当对话历史非常长时，即使使用ConversationSummaryMemory或窗口记忆，也可能面临信息丢失或成本过高的问题。更先进的模式是“检索增强记忆（Retrieval-Augmented Memory）”。

其核心思想是：不再将整个历史对话字符串都塞进Prompt，而是：

1. 将历史对话分块并向量化，存储到向量数据库。
2. 当用户提出新问题时，将新问题作为查询，去向量数据库中检索最相关的若干条历史对话片段。
3. 只将这些相关的片段作为上下文，与当前问题一起组成Prompt发送给LLM。

这本质上就是将RAG（检索增强生成）技术用在了记忆管理上。LangChain的VectorStoreRetrieverMemory就是这个思路的实现。你也可以自己组合ConversationBufferMemory和RetrievalQA链来构建更定制化的方案。

from langchain.embeddings import OpenAIEmbeddings from langchain.vectorstores import Chroma from langchain.memory import VectorStoreRetrieverMemory # 创建向量数据库和检索器 embeddings = OpenAIEmbeddings() vectorstore = Chroma(embedding_function=embeddings, collection_name="conversation_memory") retriever = vectorstore.as_retriever(search_kwargs={"k": 3}) # 检索最相关的3条记忆 # 创建基于向量检索的Memory memory = VectorStoreRetrieverMemory( retriever=retriever, memory_key="relevant_history", input_key="question" # 指定哪个输入变量用于检索 ) # 在Prompt中使用检索到的记忆 prompt = PromptTemplate.from_template(""" 你是一个助手。以下是一些可能相关的过往对话片段： {relevant_history} 请回答当前问题：{question} """) chain = LLMChain(llm=llm, prompt=prompt, memory=memory, verbose=True) # 使用链进行多轮对话，memory会自动保存并检索

这种方式特别适合需要从很长历史中回忆特定事实的场景，但它引入了向量数据库的维护成本，并且检索结果的好坏非常依赖于嵌入模型和分块策略。

6. 实战：调试一个“失忆”的聊天机器人

让我们用一个综合案例，把上面所有知识串起来。假设你构建了一个机器人，用户反馈它经常“忘记”几分钟前说过的话。

问题现象：用户说“我喜欢吃苹果”，然后问“我刚才喜欢吃什么？”，机器人回答“我不知道你之前说过什么”。

排查步骤：

1. 开启verbose模式：这是第一步。在调用链时设置verbose=True，观察输出。

   chain.invoke({"question": "我刚才喜欢吃什么？"}, verbose=True)

   在日志中，你会看到链的输入。重点检查输入字典里是否包含记忆变量（比如chat_history）。如果chat_history是空的或者不包含之前的对话，那么问题就出在Memory没有正确保存或注入。

2. 检查Memory的存储：在调用前后，直接打印Memory的内容。

   print("调用前Memory内容:", memory.load_memory_variables({})) result = chain.invoke({"question": "我喜欢吃苹果"}) print("调用后Memory内容:", memory.load_memory_variables({}))

   如果第一次调用后，Memory里没有保存“我喜欢吃苹果”和对应的回复，说明Memory的保存环节出了问题。检查是否使用了正确的Memory类，以及链的调用是否正常完成（没有异常导致提前退出）。

3. 检查Prompt模板：确认你的Prompt模板中是否包含了正确的记忆变量占位符。比如，你的Memory的memory_key是"history"，但Prompt里写的是{chat_history}，那肯定无法注入。必须完全一致。

4. 检查链的配置：确认创建LLMChain时，memory参数确实传入了你创建的Memory对象。一个低级错误是定义了两个memory变量，但链使用的是那个未初始化的或错误的对象。

5. 检查对话作用域：你是否在每次用户请求时都创建了一个新的Memory实例？如果是Web服务，常见的错误是把Memory对象的初始化放在了请求处理函数内部，导致每次请求都是全新的、空的Memory。Memory实例需要与用户会话（Session）绑定并持久化（例如保存在服务器端的Session存储或数据库中）。

6. 深入回调与追踪：如果以上都没问题，就需要更细致的追踪。使用自定义回调或LangSmith，查看在on_chain_start时，系统准备给LLM的完整Prompt到底是什么。也许历史被正确注入了，但在Prompt的某个地方被覆盖或清除了。

最终，在这个案例中，根本原因可能是：开发者使用了ConversationBufferMemory，但在Prompt模板中错误地将历史变量命名为了{past_conversation}，而Memory的memory_key是默认的"history"。导致每次注入的历史都无法被模板使用，LLM始终看不到之前的对话。

通过这套“由外到内”的排查流程，你就能系统性地定位LangChain应用中的大多数“失忆”或“错乱”问题，真正做到对链和内存的完全掌控。记住，清晰的日志、细致的追踪和对数据流的深刻理解，是构建可靠大模型应用的必备技能。