2.5 LLM 集成与管理

2.5 LLM 集成与管理

模型配置是 Agent 的脸面——同一段系统提示，换个不同模型或不同温度，产出可能天差地别。这一节讲 llm_config 里到底放什么、怎么给不同 Agent 配不同模型、以及接多个服务商时怎么管理。

llm_config 里有什么

它是一个普通字典，常见字段：model（模型名）、api_key、base_url（私有化部署时填）、temperature、max_tokens、api_type。框架把它透传给底层客户端，不做多余封装。我们建议把会变的字段（key、base_url）走环境变量。

import os
llm_cfg = {
    "model": "gpt-4o-mini",
    "api_key": os.environ.get("OPENAI_API_KEY"),
    "temperature": 0.2,      # 越低越稳，写代码建议低
    "max_tokens": 1024,      # 控制单次回复长度，省钱
    "base_url": os.environ.get("OPENAI_BASE_URL", None),  # 私有化留口
}
​

给不同 Agent 配不同模型

第二章 2.2 提过强弱分工。这里给完整例子：写代码用强模型保证质量，跑代码用便宜模型省钱。

import os
strong = {"model": "gpt-4o", "api_key": os.environ.get("OPENAI_API_KEY")}
cheap = {"model": "gpt-4o-mini", "api_key": os.environ.get("OPENAI_API_KEY")}

from autogen import AssistantAgent, UserProxyAgent
writer = AssistantAgent("writer", llm_config=strong, system_message="你写代码。")
runner = UserProxyAgent("runner", llm_config=cheap, human_input_mode="NEVER",
                        code_execution_config={"use_docker": False})
# 强模型负责创造，便宜模型负责执行，单位成本明显下降
​

接多个服务商

如果你同时用两家服务，最干净的做法是写个工厂函数，按名字返回对应配置。这样 Agent 创建处只传角色名，不沾密钥细节。

import os
def make_cfg(provider: str) -> dict:
    if provider == "a":
        return {"model": "gpt-4o-mini", "api_key": os.environ.get("KEY_A")}
    if provider == "b":
        return {"model": "other-model", "api_key": os.environ.get("KEY_B"),
                "base_url": os.environ.get("BASE_B")}
    raise ValueError("未知服务商")

# 之后 assistant = AssistantAgent("x", llm_config=make_cfg("a"))
​

温度与产出稳定性

temperature 控制随机性。代码、结构化输出建议 0 到 0.3；头脑风暴可以 0.7 以上。我们踩过坑：温度高时模型偶尔返回不合法 JSON，函数调用就挂。所以凡涉及函数调用，温度压低是常识。

上下文长度与截断

每个模型有上下文上限。对话历史超长会被框架默认截断最早的消息（保留系统提示和最近几轮）。如果你任务依赖很早的信息，得自己管理记忆（第三章 3.5 讲）。

私有化部署的接法

不少企业模型服务不对外网开放，这时 base_url 填内网网关即可，模型名用服务方给的标识。框架对"是不是官方服务"无偏好，它只负责把配置透传。我们建议私有化时额外加超时和重试，内网服务也可能抖动。

# 私有化部署：改 base_url 即可，其余不变
private_cfg = {
    "model": "local-qwen",
    "api_key": os.environ.get("INNER_KEY"),
    "base_url": "http://inner-gateway/v1",
    "timeout": 30,   # 内网也别无限等
}
agent = ConversableAgent("a", llm_config=private_cfg, system_message="你答。")
​

多模型切换的运行时策略

有时你想按任务难度动态换模型——简单问题用便宜模型，复杂问题升档。做法是准备多份配置，在路由 Agent 决定后切换 llm_config。注意切换会重置该 Agent 与模型的会话参数，但不影响对话历史。

# 运行时换模型：直接改 agent.llm_config
agent.llm_config = strong if is_hard(task) else cheap
# 历史仍保留，下一轮用新配置生成
​

配置管理的边界

llm_config 只管"怎么调模型"，不管"调什么、何时调"——后者是系统提示和对话逻辑的事。把它们分开想，配置就清爽：换模型只动配置，改行为动提示。我们见过有人把业务规则塞进配置字典，结果配置比代码还乱。记住配置是阀门，不是业务逻辑容器。

一个避坑提醒

别在代码里 hardcode api_key，也别把 base_url 写死成某个环境。这两样都该走环境变量或配置中心，否则换环境就得改代码重发。我们用 make_cfg 工厂（前面示例）就是为了把所有易变项收口，Agent 创建处保持干净。这条在团队协作时尤其重要，免得有人把测试 key 推上生产。

本节要点回顾

• llm_config 是透传字典，变字段走环境变量。
• 强弱模型分工降本，函数调用场景温度压低。
• 多服务商抽成工厂函数，Agent 创建处保持干净。

⚠️ 函数调用时别开高温度，模型可能吐出非法参数结构，导致执行端解析失败。

💡 模型配置管理看似琐碎，实则是"对话即编排"可控性的阀门——同样的编排，阀门拧不同产出就不同。