为了用上免费的，把收费的账号干废几个。

源码整改方案

1. 修复请求语义丢失（最高优先级）

修改 internal/web/protocol_compat.go：

• 完整接收并处理：
  • instructions
  • max_output_tokens
  • parallel_tool_calls
  • tool_choice
  • reasoning
  • include
  • temperature
  • text
  • service_tier
  • context_management
  • previous_response_id
• instructions 每一轮都作为最高优先级指令发送给上游，不能在转换过程中丢失。
• 无法支持的参数明确返回 unsupported_parameter，禁止静默忽略。

这是当前“像智障、不干活、反复询问”的主要源码问题。官方 Responses 规范也明确指出：previous_response_id 不会自动继承上一轮 instructions，每轮都必须正确处理。Responses API 文档

2. 重构工具调用状态机

修改：

• internal/web/model_tool_router.go
• internal/web/server.go
• internal/web/tool_state.go

调整为固定状态机：

接收请求
→ 恢复会话与任务状态
→ 判断是否需要工具
→ 输出 function_call
→ 等待对应 call_id 的结果
→ 合并工具证据
→ 继续推理
→ 必要时继续调用工具
→ 验证结果
→ 最终回答

必须保证：

• 不把长任务压缩成最后约 3000 字再判断。
• 工具路由器同时获得系统指令、当前任务、工具定义和任务进度。
• call_id 严格匹配，不能串轮、串账号。
• 工具结果已经提交后不得重复调用。
• parallel_tool_calls=false 时只能生成一个调用。
• 设置最大工具轮数、重复调用检测和幂等保护。
• 长任务不能因为换号而从头开始。

3. 增加服务器端“任务账本”

新增统一任务状态结构，保存：

• 原始用户目标
• 不可违反的约束
• 已执行步骤
• 已获得的工具结果
• 剩余步骤
• 当前账号
• 上游 conversation/session
• 失败和切换记录

这样即使上下文裁剪、断流或账号切换，模型仍知道“要做什么、做到哪里”，不会突然重新询问任务。

4. 重新设计上下文管理

修改：

• internal/web/prompt_budget.go
• internal/web/response_session.go
• internal/web/sessions.go

上下文分为三级：

1. 永久任务指令和用户约束
2. 当前任务账本及工具证据
3. 普通历史对话

裁剪时先删普通历史，不能删任务目标和工具证据。

同时：

• 限制每个会话保留的 response alias 数量。
• 稳定 session key 不参与普通别名淘汰。
• 旧 previous_response_id 保留合理窗口。
• 避免 sessions.json 随工具轮次无限膨胀。
• 会话写入失败必须记录并显式告警，不能表面回答成功、下轮却断档。

5. 账号严格顺序、会话粘连和隔离

修改账号调度源码：

• 固定 1 → 2 → 3 → 4 顺序，禁止随机。
• 正常对话始终粘在当前账号。
• 未使用账号不得建立上游会话或发送预热请求。
• 只有可切换故障才切到下一个账号。
• 切换成功后，当前任务账本和会话映射整体迁移。

错误必须分类，不能“出错一律乱换号”：

• 429/配额耗尽：顺序换下一个账号。
• 鉴权失效、代理/网络连接失败、上游 5xx：首个输出前顺序换号。
• 参数错误、工具结果错误、无效 previous_response_id：不换号，返回明确错误。
• 已经开始向客户端输出：禁止换号重放，避免重复执行工具。
• 客户端取消：不换号、不处罚账号。

6. 修正模型能力虚标

当前源码把 gpt-5.6-sol 映射成 Microsoft 365 的 ChatHub tone，它并不是真正的 OpenAI GPT-5.6 Sol。

整改为：

• 保留 gpt-5.6-sol 兼容别名，防止客户端配置失效。
• /v1/models 明确标识：
  • backend=microsoft-365
  • compatibility_alias=true
  • 实际有效上下文大小
• 服务端按实际约 96K 输入预算管理，不能对客户端声称 1.05M、内部却只处理约 96K。
• 如果以后需要真正的 GPT-5.6 Sol，应增加独立 OpenAI 上游，不能靠改名称伪装。官方模型的确支持 1.05M 上下文和原生工具调用，但 M365 映射层不能自动获得这些能力。GPT-5.6 Sol 文档

7. 完整验收，不再只测一句话

上线前必须覆盖：

• Hermes、OpenCode、Codex 三种客户端。
• 纯文本多轮。
• 30/100 轮上下文保持。
• 串行与并行工具调用。
• 50轮以上工具结果续接。
• 5–15分钟长任务。
• 请求中途断流和恢复。
• 429、401、5xx、网络超时、坏 JSON。
• 账号顺序切换和未使用账号隔离。
• 工具失败后纠错。
• 防止重复执行有副作用的工具。
• 超长 instructions。
• previous_response_id 合法与非法场景。
• 实际完成文件、执行测试、读取结果的端到端任务。

验收标准：

• 明确任务不得无故反问。
• 不得伪造工具成功。
• 不得重复执行已完成工具。
• 账号切换保持原任务上下文。
• 未使用账号零请求。
• 长任务无静默结束。
• 所有失败都返回结构化错误。
• 老版本与新版使用同一批任务进行 A/B 对比。