[raymondginger2018-sudo]

设计说明

问题：deepseek-reasoner / o1 / o3 / o4 等模型不支持（或官方不推荐）函数调用参数传递。直接发 tool_calls 会报错或静默降级，agent 失去工具能力。

解法：三件套——

1. resolve_fn_call_policy()：纯函数判定该模型是否走函数调用通道
2. to_non_function_call_messages()：把 tool_calls/tool 结果互转为纯文本消息
3. build_fallback_system_reminder()：降级时把工具清单以纯文本注入，让模型仍知道可用工具

关键设计决策：

• additive：不改变任何现有调用路径，只提供机制 + 开关
• 开关优先级：显式参数 > 环境变量 DEEPCODE_FN_CALL_COMPAT（on/off/auto）> 默认按模型名判定
• 降级名单是保守清单（命中即默认关闭 fn_call），不是能力白名单
• 纯 stdlib

边界情况：

• auto 模式下非名单模型照常走函数调用
• 消息互转保持角色顺序，不丢失 tool 结果内容

测试建议：对 deepseek-reasoner 验证 auto 判定 → 互转消息结构；对 deepseek-chat 验证正常通道

[raymondginger2018-sudo]

关键设计决策补充

• 降级名单 vs 能力白名单： 本模块维护的是保守的降级名单。缺点是新 model 发布后短时间可能被误拦（如果名字含 'reasoner'）；优点是绝不会漏掉不支持 fn_call 的模型。
• 消息互转的 fidelity： to_non_function_call_messages() 把 tool_calls 参数展开为自然语言描述（"Calling tool X with args Y"），把 tool 结果包裹为 "Tool result from X: ..."。这保持了信息的完整性但丢失了结构化调用链——不影响单次执行但多轮分析时要注意。
• 和 PR feat(loop): SLM/LLM subtask complexity routing #218 的关系： feat(loop): SLM/LLM subtask complexity routing #218（SLM routing）在请求层做模型路由，本 PR 在 provider 层做 fn_call 兼容。两者正交：可以同时启用。

[Zongwei9888]

Thank you for the submission, @raymondginger2018-sudo. Closing for three reasons. First, the capability already exists as configuration: ExecutionProfile.tool_calling (toolCalling) and validate_request_capabilities refuse tool requests for models declared without function calling, and core/providers/model_compat.py deliberately avoids name-substring detection, which this module reintroduces. Second, the list is wrong for current models (the o3/o4 series support function calling; "reasoner" as a substring is too broad). Third, the fallback is only half a mechanism: it converts tool_calls to text on the way out but never parses the model's text back into tool calls, so a degraded session cannot actually use tools. If you want to pursue a text-protocol fallback, it has to include that reverse parser and an end-to-end test against a real non-function-calling model.