Roo-DeepSeek-Proxy：打通Roo Code与DeepSeek推理模型的桥梁

一个轻量级FastAPI代理，解决Roo Code使用DeepSeek v4/R1模型时的reasoning_content往返问题，支持工具调用和多轮对话中的推理内容保持。

Roo Code是一款流行的AI编程助手，它使用OpenAI兼容的聊天补全格式与各种LLM提供商通信。然而，当接入DeepSeek v4系列模型（包括DeepSeek-R1和DeepSeek v4 Pro/Flash）时，开发者会遇到一个棘手的问题。

DeepSeek的推理模型在返回响应时，会在每个流式响应块中包含一个特殊的reasoning_content参数。这个推理内容对于DeepSeek的工具调用工作流至关重要——模型在后续轮次中需要这些推理内容来处理工具结果。

但问题是：OpenAI标准格式并不包含reasoning_content字段。当Roo Code发送下一轮请求时（包含工具调用但没有推理内容），DeepSeek API会拒绝并返回：

400 Bad Request — "assistant message with tool_calls must also have reasoning_content"

这使得DeepSeek v4模型在Roo Code中无法开箱即用。

Roo-DeepSeek-Proxy是一个基于FastAPI的轻量级代理，它在Roo Code和DeepSeek API之间充当翻译官，执行三项关键转换：

在流式响应过程中，代理捕获reasoning_content并按tool_call_id进行索引存储。在后续请求中，自动将匹配的推理内容重新注入到对应的助手消息中。

作为容错机制，推理内容还会按消息内容的MD5哈希进行存储。如果工具ID匹配失败，基于内容的查找仍能恢复推理内容。

Roo Code有时会以块数组的形式发送内容（包含reasoning、text、tool_result类型）。代理将其扁平化为DeepSeek期望的简单字符串格式，同时保留助手消息的推理内容。

所有缓存的推理内容都会持久化到.roo_deepseek_cache.json文件中，即使代理重启也不会丢失。该文件已被自动加入.gitignore，可以安全删除——代理会在下次请求时重新创建。

代理暴露两个主要端点：

• GET /v1/models：返回可用的DeepSeek模型ID
• POST /v1/chat/completions：代理聊天补全请求到DeepSeek