LangGraph实战指南：手把手拆解Open Deep Research源码，详解多Agent动态模型配置（非常详细）。

Open Deep Research 简介

Open Deep Research 是一个基于 LangGraph 构建的多Agent深度研究系统。该系统将复杂的深度研究任务分解为多个专业化Agent，包括用户澄清Agent、研究Agent、压缩Agent和报告生成Agent等。每个Agent专注于特定任务，实现了职责分离、灵活配置和高效协作的多Agent架构设计。

在多Agent系统中，不同Agent往往需要不同的模型配置来优化其特定任务的性能。例如，研究Agent可能需要更强的推理能力，而压缩Agent可能更注重效率。因此，动态模型配置成为了多Agent系统设计中的关键。

而根据Open Deep Research的源代码，我们可以学习到一种更专业的配置方式，实现在Graph运行时通过配置字符串动态创建模型实例的效果。下面直接进入正题

动态模型配置实践学习

第一步：创建可动态配置的模型模板

init_chat_model这个接口我们已经很熟悉了，它是LangChain给我提供的调用模型能力的工具。它有一个参数configurable_fields，作用是指定哪些字段可以在运行时通过config参数动态修改。

如果不指定 configurable_fields，默认情况下 “model” 和 “model_provider” 是可配置的，我们之前通过init_chat_model使用DeepSeek就是这么用的。

from langchain.chat_models import init_chat_modelmodel = init_chat_model(model="deepseek-chat", model_provider="deepseek")

因为Open Deep Research是一个多Agent系统，不同的Agent由于负责的任务不同，可能需要适配不同的模型，因此我们需要通过configurable_fields来实现一个可动态配置参数的模型模板。

源代码如下：（deep_researcher.py Lines 56-58）

configurable_model = init_chat_model( configurable_fields=("model", "max_tokens", "api_key"),)

上述代码中，configurable_fields指定了三个可在运行时动态配置的字段：

•model：模型名称（如 “openai:gpt-4.1”）
•max_tokens：最大输出 token 数
•api_key：API 密钥

后续在不同节点里具体配置模型时，会使用这个模版，填入读取到的具体的配置参数，来“定制化”模型。下面我们逐步来学习这个过程。

第二步：读取模型的配置信息

由于所有模型节点的配置都是大同小异的，我们选择Open Deep Research中的第一个模型节点clarify_with_user来作为研究对象。

先来看源代码（deep_researcher.py Lines 60-74）

async def clarify_with_user(state: AgentState, config: RunnableConfig) -> Command[Literal["write_research_brief", "__end__"]]: """Analyze user messages and ask clarifying questions if the research scope is unclear. This function determines whether the user's request needs clarification before proceeding with research. If clarification is disabled or not needed, it proceeds directly to research. Args: state: Current agent state containing user messages config: Runtime configuration with model settings and preferences Returns: Command to either end with a clarifying question or proceed to research brief """ configurable = Configuration.from_runnable_config(config)

async是异步编程的内容，与本期无关，大家可以忽略，于是这就是个简单的节点函数。可以看到，在节点函数签名中，除了我们熟悉的state参数外，还有个config参数，类型为RunnableConfig，它就是我们动态调整模型配置的关键所在。

当 LangGraph 调用节点函数时，需要传入config参数，然后节点函数会从中读取配置，并将其转换为便于使用的Configuration对象（该对象在configuration.py中被定义），使节点函数能够根据运行时配置动态调整行为。

其中读取配置的代码就是：

configurable = Configuration.from_runnable_config(config)

可以看到，这里使用了Configuration类中定义的一个.from_runnable_config方法，下面我们展开看看它的作用原理。

如何从运行时配置读取`Configuration`

.from_runnable_config()的源代码如下（configuration.py Lines 236-247）。

@classmethod def from_runnable_config( cls, config: Optional[RunnableConfig] = None ) -> "Configuration": """Create a Configuration instance from a RunnableConfig.""" configurable = config.get("configurable", {}) if config else {} field_names = list(cls.model_fields.keys()) values: dict[str, Any] = { field_name: os.environ.get(field_name.upper(), configurable.get(field_name)) for field_name in field_names } return cls(**{k: v for k, v in values.items() if v is not None})

这是一个类方法（@classmethod），所以from_runnable_config的第一个参数是类本身（cls）。

从总体来说，.from_runnable_config()的思路就是从用户配置的config中获得一个数据字典，然后确定需要的字段来从这个字典中得到需要的值。接下来，我们逐步分析这个方法是如何工作的。

步骤 1：从 RunnableConfig 中提取 configurable 字典

configurable = config.get("configurable", {}) if config else {}

因为config是一个RunnableConfig对象，所以我们首先需要理解RunnableConfig的结构。

RunnableConfig是LangChain定义的一个配置字典，它可能包含多个字段，比如tags（用于标记）、metadata（元数据）等，但对我们来说最重要的就是configurable字段。

而同时，configurable字段本身也是一个字典，里面存放着所有可以在运行时动态调整的配置项。一个典型的RunnableConfig结构如下：

{ "configurable": { "research_model": "openai:gpt-4.1", "research_model_max_tokens": 10000, "allow_clarification": True, # ... 其他配置项 }, "tags": ["production", "v1"], "metadata": {"user_id": "12345"}, # ... 其他字段}

所以，前述源代码的逻辑就是：

• 如果config存在，就尝试从中获取"configurable"字段
• 如果config为None或者"configurable"字段不存在，就返回一个空字典{}

需要多说一句的是，这个config在Open Deep Research项目中主要是通过使用LangGraph Studio UI来输入配置的，

步骤 2：获取 Configuration 类中定义的所有字段名

field_names = list(cls.model_fields.keys())

这一步的目的是获取Configuration类中定义的所有配置字段的名称。为后面提取Configuration类中定义的特定字段，然后根据前一步获得的configurable 字典分配对应的配置值做准备。

那么，如何获取这些字段名呢？这里用到了Pydantic的一个特性。因为Configuration类继承自BaseModel，Pydantic会自动扫描类中所有用Field()定义的字段，并创建一个名为model_fields的字典属性。这个字典的键是字段名，值是字段定义对象。

还是以源代码为例，Configuration类的定义大概如下：

class Configuration(BaseModel): """Main configuration class for the Deep Research agent.""" # General Configuration max_structured_output_retries: int = Field(...) allow_clarification: bool = Field(...) max_concurrent_research_units: int = Field(...) # Research Configuration search_api: SearchAPI = Field(...) max_researcher_iterations: int = Field(...) max_react_tool_calls: int = Field(...) # Model Configuration summarization_model: str = Field(...) summarization_model_max_tokens: int = Field(...) max_content_length: int = Field(...) research_model: str = Field(...) research_model_max_tokens: int = Field(...) compression_model: str = Field(...) compression_model_max_tokens: int = Field(...) final_report_model: str = Field(...) final_report_model_max_tokens: int = Field(...) # MCP server configuration mcp_config: Optional[MCPConfig] = Field(...) mcp_prompt: Optional[str] = Field(...)

Pydantic 会将这些字段收集到model_fields字典中（通过cls.model_fields)，其结构如下：

cls.model_fields = { # 键是字段名（字符串），值是 FieldInfo 对象 'max_structured_output_retries': FieldInfo( default=3, metadata={...}, # ... 其他字段信息 ), 'allow_clarification': FieldInfo( default=True, metadata={...}, ), 'max_concurrent_research_units': FieldInfo( default=5, metadata={...}, ), 'search_api': FieldInfo( default=SearchAPI.TAVILY, metadata={...}, ), ......}

然后，再使用.keys()返回一个视图对象，包含所有字段名：

dict_keys([ 'max_structured_output_retries', 'allow_clarification', 'max_concurrent_research_units', 'search_api', ......])

最后，用list()将其转换为列表，便于后续遍历处理。

field_names = [ 'max_structured_output_retries', 'allow_clarification', 'max_concurrent_research_units', 'search_api', ......]

值得一提的是，这种方式是动态的：当你在Configuration类中添加新字段时，model_fields.keys()会自动包含新字段，无需修改from_runnable_config方法。这避免了手动维护字段列表的麻烦，也减少了出错的可能性。

步骤 3：按优先级顺序读取每个字段的配置值

values: dict[str, Any] = { field_name: os.environ.get(field_name.upper(), configurable.get(field_name)) for field_name in field_names}

这是整个方法的核心逻辑。使用字典推导式，为每个配置字段（field_name）确定最终使用的值。这里的关键在于优先级机制的设计。

os.environ.get(field_name.upper(), configurable.get(field_name))这行代码体现了两个优先级的处理：

优先级 1：环境变量（最高优先级）

os.environ.get(field_name.upper(), ...)首先尝试从系统环境变量中读取配置。注意这里有一个细节：字段名会被转换为大写。比如，如果字段名是research_model，那么会去查找环境变量RESEARCH_MODEL。

优先级 2：运行时配置（次优先级）

如果环境变量中没有找到对应的值（os.environ.get()返回None），那么os.environ.get()的第二个参数就会生效，这个参数是configurable.get(field_name)，即从我们步骤一中获取的运行时配置的configurable字典中读取值。

优先级 3：默认值（最低优先级）

如果前两者都没有提供值，则在这一步field_name的值将为none。而后面我们会看到，通过过滤none，相关的值最终会使用Configuration类中定义的默认值。这个默认值是在定义Configuration类时通过Field(default=...)设置的。

步骤 4：过滤 None 值并创建 Configuration 实例

return cls(**{k: v for k, v in values.items() if v is not None})

最后一步，我们需要将收集到的配置值传递给Configuration类的构造函数，创建Configuration实例。

这里有一个重要的细节：我们使用字典推导式{k: v for k, v in values.items() if v is not None}过滤掉了所有值为None的项。为什么要这样做呢？

这是因为，如果某个字段在前面的步骤中既没有从环境变量读取到，也没有从运行时配置读取到，那么它的值就是None。如果我们把这些None值也传给Configuration的构造函数，可能会覆盖掉类中定义的默认值。通过过滤掉None值，我们确保了只有明确提供的配置值才会被使用，而那些没有提供的字段，会使用Configuration类中通过Field(default=...)定义的默认值。

最后，cls(**{...})使用解包操作符**将字典展开为关键字参数，调用Configuration类的构造函数，创建一个配置实例并返回。

第三步：为不同的节点创建配置字典模板

接下来的步骤就很简单了，我们只需要从上一步读取运行时配置后创建的Configuration 类的configurable中读取相关信息。

model_config = { "model": configurable.research_model, "max_tokens": configurable.research_model_max_tokens, "api_key": get_api_key_for_model(configurable.research_model, config), "tags": ["langsmith:nostream"] }

model、max_tokens都是直接通过点的方式从configurable中读取对应的字段信息，比如我们这里是research节点，所以读的是research_model、research_model_max_tokens，如此，实现了config的动态变化。

api_key稍微特殊点，使用了get_api_key_for_model()这个函数，根据模型名称前缀（如 “openai:”、“anthropic:”）从环境变量或配置中获取。这个函数的具体作用原理就不再赘述了，感兴趣的朋友可以把代码丢给AI解读下：

def get_api_key_for_model(model_name: str, config: RunnableConfig): """Get API key for a specific model from environment or config.""" should_get_from_config = os.getenv("GET_API_KEYS_FROM_CONFIG", "false") model_name = model_name.lower() if should_get_from_config.lower() == "true": api_keys = config.get("configurable", {}).get("apiKeys", {}) ifnot api_keys: returnNone if model_name.startswith("openai:"): return api_keys.get("OPENAI_API_KEY") elif model_name.startswith("anthropic:"): return api_keys.get("ANTHROPIC_API_KEY") elif model_name.startswith("google"): return api_keys.get("GOOGLE_API_KEY") returnNone else: if model_name.startswith("openai:"): return os.getenv("OPENAI_API_KEY") elif model_name.startswith("anthropic:"): return os.getenv("ANTHROPIC_API_KEY") elif model_name.startswith("google"): return os.getenv("GOOGLE_API_KEY") return None

第四步：将配置到应用到模型

# Configure model with structured output and retry logic clarification_model = ( configurable_model .with_structured_output(ClarifyWithUser) .with_retry(stop_after_attempt=configurable.max_structured_output_retries) .with_config(model_config) )

最终，在我们第一步创建的configurable_model这个模板的基础上，使用.with_config()方法将前面获取的配置信息应用进去，就大功告成啦。

补充：config 的来源

前文中我们已经了解了Open Deep Research中模型动态配置的基本原理，但有个尾巴还需要说明一下。我们已经知道了节点在读取模型的配置信息时，有个环境变量 > 运行时配置 > 默认值的优先级顺序，前后两个都好理解，那么“运行时配置”到底是从哪里来的呢？

通过LangGraph Studio UI配置

对于Open Deep Research这个项目来说，它推荐的方法是使用LangGraph Studio 。

由于源代码在图的定义中指定了config_schema=Configuration：

deep_researcher_builder = StateGraph( AgentState, input=AgentInputState, config_schema=Configuration # 指定配置 schema)

所以LangGraph Studio 会根据Configuration类的字段定义自动生成配置 UI。用户在 UI 的 “Manage Assistants” 标签页中设置的配置会自动作为config传入所有节点。

程序调用时手动传入

第二种方式就是我们熟悉的手动传入了。我们可以在代码中写好config的内容，然后在invoke图的时候作为参数传入。

config = { "configurable": { "research_model": "openai:gpt-4.1", "research_model_max_tokens": 10000, # ... 其他配置项 }}result = deep_researcher.invoke(inputs, config)

总结

综上，Open Deep Research 大致通过以上四步配置流程实现了多Agent系统的动态模型配置：

• 1.创建模型模板：使用init_chat_model(configurable_fields=...)创建可配置的模型模板
• 2.读取预设配置：通过Configuration.from_runnable_config()从运行时配置中提取参数，支持三级优先级（环境变量 > 运行时配置 > 默认值）
• 3.构建模型配置字典：根据不同节点需求，从Configuration对象提取相应配置项，构建model_config字典
• 4.应用配置：使用.with_config(model_config)将配置应用到模型模板，生成定制化的模型实例

好了，以上就是本期的全部内容，如果大家觉得对自己有帮助的，还请多多点赞、收藏、转发、关注！祝大家玩得开心，我们下期再见！

如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。