从零开始学LangGraph指南（10）：利用Runtime自定义实现Model和System Prompt的灵活切换 - 文章 - 开发者社区

  
from langgraph.graph import END, StateGraph, START  
from typing\_extensions import TypedDict  
  
# 1. Specify config schema  
class ContextSchema(TypedDict):  
    my\_runtime\_value: str  
  
# 2. Define a graph that accesses the config in a node  
class State(TypedDict):  
    my\_state\_value: str

首先，除了老朋友State，我们再定义一个ContextSchema，它负责定义运行时配置的结构，告诉LangGraph，我们在调用Graph时可以传入哪些配置参数，比如这里我们定义了一个my\_runtime\_value字段，类型为str。

注意，对于ContextSchema定义的配置内容，节点可以读取，但不能直接修改。

2.在节点函数中配置runtime参数

接下来，我们定义节点函数。

  
from langgraph.runtime import Runtime  
  
def node(state: State, runtime: Runtime[ContextSchema]):    
    if runtime.context["my\_runtime\_value"] == "a":    
        return {"my\_state\_value": 1}  
    elif runtime.context["my\_runtime\_value"] == "b":    
        return {"my\_state\_value": 2}  
    else:  
        raise ValueError("Unknown values.")

首先，我们需要从langgraph.runtime中导入Runtime类型。由于Runtime是一个泛型类型，我们在指定自定义的ContextSchema时，需要使用方括号，即Runtime[ContextSchema]。

然后，在节点函数的参数中添加runtime参数，将它的类型设定为Runtime[ContextSchema]。这样，节点函数就可以访问运行时配置了。

接下来看函数体内部：

首先，我们通过runtime.context["my\_runtime\_value"]来访问配置值。这里runtime.context是一个字典，我们可以通过指定键名来获取对应的配置值。

然后，根据配置值的不同，节点会返回不同的state更新结果。如果传入的是"a"，就返回{"my\_state\_value": 1}；如果传入的是"b"，就返回{"my\_state\_value": 2}；如果传入其他值，则抛出异常。

换言之，根据上述代码，我们可以通过观察state值的变化，确定runtime信息是否被读取。

3.向Graph传入contetx_schema

接着，我们来构建Graph：

  
builder = StateGraph(State, context\_schema=ContextSchema)    
builder.add\_node(node)  
builder.add\_edge(START, "node")  
builder.add\_edge("node", END)  
  
graph = builder.compile()

这里的关键点在于StateGraph的初始化。除了传入State（这是我们之前就熟悉的），我们还需要传入context\_schema=ContextSchema参数。这个参数告诉LangGraph，这个Graph支持运行时配置，并且配置的格式由ContextSchema定义。

接下来的步骤就和之前一样了：添加节点、添加边、编译Graph。

4.Runtime Configuration的使用

然后我们来看看如何在调用Graph时传入Runtime Configuration：

  
# 3. Pass in configuration at runtime:  
print(graph.invoke({}, context={"my\_runtime\_value": "a"}))    
print(graph.invoke({}, context={"my\_runtime\_value": "b"}))

在调用graph.invoke()时，除了传入初始state（这里传入的是空字典{}），我们可以通过context参数传入运行时配置。

context参数接收一个字典，字典的键必须与ContextSchema中定义的字段名一致。这里我们传入{"my\_runtime\_value": "a"}或{"my\_runtime\_value": "b"}，Graph会根据不同的配置值，按照我们在节点函数中的设定，执行不同的逻辑。

实际效果：

• 第一次调用 graph.invoke({}, context={"my\_runtime\_value": "a"}) 时，节点会返回 {"my\_state\_value": 1}
• 第二次调用 graph.invoke({}, context={"my\_runtime\_value": "b"}) 时，节点会返回 {"my\_state\_value": 2}

这样，我们就实现了同一个Graph，根据不同的运行时配置，产生不同的行为的效果。

下面我们来看两个比较常用的runtime configuration的应用。

Runtime Configuration的实际应用

1.指定运行时使用的Model

在实际开发中，我们经常会遇到这样的场景：同一个AI Agent，有时候需要使用Claude模型（比如处理复杂推理任务），有时候需要使用GPT模型（比如处理代码生成任务）。如果每次都重新定义Graph，显然太麻烦了。

这时候，我们可以通过事先配置runtime相关schema，指定不同情况下使用的模型，实现在运行时动态切换模型的效果。

鉴于官方示例代码使用了Claude和OpenAI这些国外模型，为了方便大家实践，我做了些调整，把整个代码改为在DeepSeek的chat和reasoner之间切换。

（1）ContextSchema与模型库构建

  
from dotenv import load\_dotenv  
from langchain.chat\_models import init\_chat\_model  
from langgraph.graph import MessagesState, END, StateGraph, START  
from langgraph.runtime import Runtime  
from typing\_extensions import TypedDict  
  
  
# 导入API Key  
load\_dotenv()  
  
classContextSchema(TypedDict):  
    model\_type: str  
  
MODELS = {  
    "chat": init\_chat\_model("deepseek-chat", model\_provider="deepseek"),  
    "reasoner": init\_chat\_model("deepseek-reasoner", model\_provider="deepseek"),  
}

模型初始化相关内容不再赘述，不熟悉的同学请复习前期内容。

这里我们首先定义了一个ContextSchema，它包含一个model\_type字段，类型为str。

然后，我们定义一个MODELS字典作为模型库，存储不同提供商对应的模型实例（已通过init\_chat\_model完成初始化）。这样，我们就可以根据配置的提供商名称，快速获取对应的模型。

需要注意的是，这里可以看到我们没有定义state，那是因为我们引用了LangGraph的一个内置组件MessagesState。

（2）模型切换的节点函数定义

接下来，我们定义节点函数，参数传递方面同前文，不再赘述。

  
def call\_model(state: MessagesState, runtime: Runtime[ContextSchema]):  
    # 使用 get 方法提供默认值 "chat"  
    model\_type = (runtime.context or {}).get("model\_type", "chat")  
    model = MODELS[model\_type]  
    response = model.invoke(state["messages"])   
    return {"messages": [response]}

在函数体内，我们使用(runtime.context or {}).get("model\_type", "chat")获取配置的模型类型。这里使用(runtime.context or {})是为了处理runtime.context可能为None的情况，如果为None则使用空字典{}。然后使用get方法的好处是，如果没有提供配置（即context={}或context为None），则会使用默认值"chat"。因为在后面我们invoke Graph的时候，会向context参数传入形如{"model\_type": "chat"}或{"model\_type": "reasoner"}的键值对。

然后，根据获取到的model\_type从MODELS字典中选择对应的模型，调用模型的invoke方法处理消息，并将响应添加到消息列表中返回。

（3）搭建Graph传入context_schema

  
builder = StateGraph(MessagesState, context\_schema=ContextSchema)  
builder.add\_node("model", call\_model)  
builder.add\_edge(START, "model")  
builder.add\_edge("model", END)  
  
graph = builder.compile()

这些步骤和之前一样，不再赘述。

（4）在graph.invok中指定contetx的参数

这段代码展示了如何使用配置了Runtime Configuration的Graph：

  
# Usage  
input\_message = {"role": "user", "content": "hi"}  
# With no configuration, uses default ("chat")  
response\_1 = graph.invoke({"messages": [input\_message]}, context={})["messages"][-1]  
# Or, can set reasoner  
response\_2 = graph.invoke({"messages": [input\_message]}, context={"model\_type": "reasoner"})["messages"][-1]  
  
print(response\_1.response\_metadata["model\_name"])  
print(response\_2.response\_metadata["model\_name"])

首先，我们准备一个输入消息。然后，我们进行了两次调用：

第一次调用 ： context={} ，由于我们在节点函数中使用了 (runtime.context or {}).get("model\_type", "chat") ，当配置为空字典时，会使用默认值 "chat" ，所以这次调用会使用DeepSeek的chat模型。

第二次调用 ： context={"model\_type": "reasoner"} 。我们显式地传入配置，指定使用DeepSeek的reasoner模型。

最后，我们打印两次调用的模型名称，可以看到它们确实使用了不同的模型。

• response\_1 会使用DeepSeek Chat模型处理消息
• response\_2 会使用DeepSeek Reasoner模型处理消息

这样，我们就实现了同一个Graph，根据运行时配置使用不同的模型 。在实际应用中，你可以根据任务类型、用户偏好、成本考虑等因素，动态选择最合适的模型。

2.指定运行时使用的System Prompt

除了动态切换模型，Runtime Configuration的另一个常见应用场景是动态指定System Prompt 。在实际应用中，我们可能需要根据不同的任务类型、用户角色或业务场景，使用不同的System Prompt来指导模型的行为。

比如，同一个客服Agent，在处理技术问题时需要使用技术支持的System Prompt，在处理退款问题时需要使用客服的System Prompt。如果每次都重新定义Graph，显然不够灵活。

下面我们结合代码来看看具体的实现过程。

（1）ContextSchema定义

  
from langchain.chat\_models import init\_chat\_model  
from langgraph.graph import MessagesState, END, StateGraph, START  
from langgraph.runtime import Runtime  
from langchain\_core.messages import SystemMessage  
from typing\_extensions import TypedDict  
  
class ContextSchema(TypedDict):  
    system\_prompt: str

这里我们定义了一个ContextSchema，它包含一个system\_prompt字段，类型为str。

（2）处理System Prompt的节点函数定义

接下来，我们定义节点函数：

  
def call\_model\_with\_prompt(state: MessagesState, runtime: Runtime[ContextSchema]):  
    model = init\_chat\_model("deepseek-chat", model\_provider="deepseek")  
      
    # 获取运行时配置的System Prompt，如果没有提供则使用默认值  
    system\_prompt = (runtime.context or {}).get("system\_prompt", "You are a helpful assistant.")  
    system\_message = SystemMessage(content=system\_prompt)  
      
    # 将System Message添加到消息列表的开头  
    messages = [system\_message] + state["messages"]  
      
    response = model.invoke(messages)  
    return {"messages": [response]}

在函数体内，我们首先初始化模型。然后使用(runtime.context or {}).get("system\_prompt", "You are a helpful assistant.")获取配置的System Prompt，如果没有提供配置（即context={}或context为None），则会使用默认值"You are a helpful assistant."。

接下来，我们创建一个SystemMessage对象，并将其添加到消息列表的开头。这样，模型在处理用户消息时，会首先看到System Prompt，从而按照指定的角色和风格来响应。

最后，调用模型的invoke方法处理消息，并将响应添加到消息列表中返回。

（3）搭建Graph传入context_schema

  
builder = StateGraph(MessagesState, context\_schema=ContextSchema)  
builder.add\_node("model", call\_model\_with\_prompt)  
builder.add\_edge(START, "model")  
builder.add\_edge("model", END)  
  
graph = builder.compile()

这些步骤和之前一样，不再赘述。

（4）在graph.invoke中指定context的参数

  
# Usage  
input\_message = {"role": "user", "content": "What is Python?"}  
  
# 使用默认的System Prompt  
response\_1 = graph.invoke(  
    {"messages": [input\_message]},   
    context={}  
)  
  
# 使用自定义的System Prompt  
response\_2 = graph.invoke(  
    {"messages": [input\_message]},   
    context={"system\_prompt": "You are a Python expert. Provide detailed technical explanations."}  
)

首先，我们准备一个输入消息。然后，我们进行了两次调用：

第一次调用 ： context={} ，这时Graph会使用默认值 "You are a helpful assistant." ，所以这次调用会使用默认的System Prompt。

第二次调用 ： context={"system\_prompt": "You are a Python expert. Provide detailed technical explanations."} 。我们显式地传入配置，指定使用自定义的System Prompt，让模型以Python专家的身份来回答问题。

这样，我们就可以在运行时动态指定System Prompt，而不需要修改Graph的定义。在实际应用中，你可以根据任务类型、用户角色、业务场景等因素，动态选择最合适的System Prompt。