讨论: LLM 采样/推理参数的归属 — SessionConfig vs LLMAdapter

[uchouT]

背景

在设计 SessionConfig 统一配置形状的过程中（见进行中的 RFC），识别出一批 Anthropic / OpenAI 协议字段尚未决定归属。需要讨论这些字段应该放在 session 级配置里，还是由 LLMAdapter 自己消化。

涉及字段

两家协议共有

• temperature
• top_p
• stop_sequences (Anthropic) / stop (OpenAI)
• max_tokens (Anthropic 必填) / max_completion_tokens (OpenAI)
• tool_choice

各自独有

• Anthropic：top_k、thinking: { budget_tokens }（扩展思考）
• OpenAI：reasoning_effort（o 系列）、frequency_penalty、presence_penalty、response_format、seed

核心问题

上述字段有三种可能的归属方式：

方案 A：全部进 SessionConfig

SessionConfig {
  sampling?: { temperature, topP, topK, maxOutputTokens, stopSequences }
  toolChoice?: 'auto' | 'required' | 'none' | { name }
  reasoning?: { effort, budget }
}

• 优点：用户用统一 API 控制行为，与 session 身份绑定
• 缺点：需要在框架层做跨协议抽象（如 reasoning 统一 Anthropic thinking + OpenAI reasoning_effort），抽象选错易留债

方案 B：全部由 LLMAdapter 自己处理

LLMAdapter 构造时传入所有采样/推理参数，SessionConfig 不管。

• 优点：框架不做跨协议抽象，各 adapter 自行暴露原生字段
• 缺点：同一个 session 想换 sampling 参数就得换 LLMAdapter 实例；与 session "不可变配置 + fork 新 session 切换" 的模型耦合不顺畅

方案 C：分层——通用采样进 SessionConfig，专有字段进 LLMAdapter

• SessionConfig：temperature / topP / maxOutputTokens / stopSequences / toolChoice

• LLMAdapter 构造参数：topK、thinking、reasoning_effort、penalties、responseFormat、seed 等

• 优点：跨协议抽象只做两家都支持的字段，风险低

• 缺点：分界线有模糊地带（比如 reasoning — 两家都有类似能力但形式不同）

额外考虑

1. per-call 覆盖：某些参数（seed、response_format、tool_choice）天然 per-call 语义，即便 session 默认存在也要保留调用时覆盖能力
2. LLMAdapter 当前签名：需要核查是否已经能接收这些参数，以及是否有 per-call options 通道
3. session "不可变配置" 决策：已确认 session 创建后配置固化，若 sampling 参数进 SessionConfig 则也不可变——要换就 fork 新 session

期望产出

• 确定方案 A / B / C
• 列出最终进入 SessionConfig 的字段清单
• LLMAdapter 接口的调整（如需）

关联

• 本次讨论从 SessionConfig 统一配置形状的 RFC 中分离出来
• 依赖决策：SessionConfig 已确认不可变 + fork 覆盖模型