OpenAI 推理模型端点迁移实战（llm 0.32a2）

Step 1：识别当前所有推理模型调用点

• 目标：找出代码库中所有使用 OpenAI 推理模型的请求构造逻辑。
• 动作：

1. 全局搜索 openai.ChatCompletion.create、client.chat.completions.create 或自定义 HTTP 请求中 /v1/chat/completions 的字符串。
2. 筛选出 model 参数为推理模型列表（o1、o1-mini、o3-mini、o3 等）的调用点并记录文件路径、行号、上下文。
3. 用 grep 或 IDE 的 find in files 配合正则：model:? "o[13]。

• 输出：调用点清单（文件路径 + 行号 + 当前使用的端点 + model 参数值）。
• 人工判断点：确认清单是否遗漏了动态 model 字符串（如从环境变量读取或拼接的模型名）。需要人工 review 所有非字面量 model 的位置，必要时添加日志 trace。

Step 2：改造请求构造逻辑，切换端点并适配响应差异

• 目标：将 推理模型 的请求从 /v1/chat/completions 切换为 /v1/responses，同时适配新旧端点的响应结构差异。
• 动作：

1. 根据 OpenAI Responses API 文档 了解新端点的请求体格式（例如 input 替代 messages，model 字段仍存在，tools 可能需调整等）。
2. 编写一个适配函数 call_reasoning_model(params)，内部判断模型类型后自动选择端点，并转换请求参数。
3. 修改 Step 1 中识别的每个调用点，替换为对新适配函数的调用，同时保持原有业务逻辑不变（如 temperature、max_tokens 等参数映射）。

• 输出：
• 适配函数代码（Python 示例）：

    def call_reasoning_model(client, model, messages, **kwargs):
        if model.startswith("o"):  # 推理模型
            endpoint = "/v1/responses"
            payload = {
                "model": model,
                "input": messages,  # 注意新端点要求 "input" 而不是 "messages"
                **kwargs
            }
        else:
            endpoint = "/v1/chat/completions"
            payload = {
                "model": model,
                "messages": messages,
                **kwargs
            }
        response = client.post(endpoint, json=payload)
        return response.json()

• 每个调用点的代码 diff（可合并提交）。
• 人工判断点：
• 检查 input 字段的格式是否兼容原 messages 结构（例如 system message 是否需要转为 developer role？）；
• 确认新响应中的 output 字段如何映射回原来的 choices[0].message.content；
• 对于流式调用（stream=True），额外确认新端点的 SSE 格式是否一致。

Step 3：编写自动化验证脚本并灰度上线

• 目标：确保迁移后所有推理模型调用返回正确结果，且性能无明显退化。
• 动作：

1. 编写一个集成测试用例集合，覆盖所有使用的推理模型（至少 o1 和 o3-mini），每个模型发送 2~3 个典型 Prompt，断言返回内容非空且格式正确（如 JSON 可解析）。
2. 在测试环境中运行新旧两套逻辑（通过 feature flag 控制），对比输出一致性（允许 LLM 输出天然差异，但检查是否有异常 HTTP 错误、超时、空响应）。
3. 将适配函数部署到灰度实例（例如 5% 流量），观察 30 分钟内无 4xx/5xx 异常，且响应延迟不超过旧端点的 1.2 倍。

• 输出：
• 集成测试脚本（Python，依赖 pytest + openai 客户端）；
• 灰度部署后的错误日志与性能数据报表。
• 人工判断点：
• 检查灰度期间是否有因为 input 结构问题导致的 400 Bad Request；
• 观察回滚策略：如果错误率 > 1% 或延迟超过阈值，立即回滚并人工分析根因。