AI

Windows-Copilot-API：把 Microsoft Copilot 逆向工程成免費的 OpenAI 相容 API

Monday

本內容僅供參考，詳細使用規則與工具安全性與否，建議要進行相關安全性測試與評估

在 AI 工具費用水漲船高的今天，一個僅花四天就累積超過 370 顆星的開源專案悄悄引發社群熱議——它把 Microsoft Copilot 的消費者版 Web 介面，徹底逆向工程成一個可以直接呼叫的本地 OpenAI 相容 REST API，完全不需要任何 API Key 或付費方案。

1. 專案背景與定位

Windows-Copilot-API 由 GitHub 用戶 sums001 在 2026 年 6 月 19 日發布，短短四天內獲得 371 顆星與 129 次 Fork，顯示出這個「繞過 API 收費」的需求有多強烈。

其核心定位非常清晰：利用你自己的 Microsoft 免費帳號（就是登入 copilot.microsoft.com 那個），透過 Playwright 瀏覽器自動化技術，把 Copilot 的 Web 對話介面包裝成一個執行在本地端 http://localhost:8000/v1 的 API Server，對外完整模擬 OpenAI API 的呼叫格式。

這意味著任何原本接 OpenAI 的工具、SDK、或應用程式，只需把 base_url 改成 localhost:8000/v1，就能「無縫切換」到免費的 Copilot 後端。這個設計吸引了大量個人開發者、學生族群，以及想在封鎖地區（如印度）繞過匿名 Copilot 限制的使用者。

2. 技術架構與核心設計

整個專案的技術棧相當精簡，核心依賴為：

  • Playwright（Chromium）：負責驅動真實瀏覽器，執行登入、Session 維持、以及頁面互動
  • Session 持久化：首次登入後，瀏覽器 Session 被序列化存放在本地 session/ 目錄，後續呼叫自動 Resume，無需重複登入
  • OpenAI Schema 模擬：Server 層實作 /v1/chat/completions 端點，回應格式完整符合 OpenAI 規範，包含 SSE Streaming 的逐 Token 輸出
  • 多輪對話管理：透過 conversation_id 追蹤對話上下文，支援多輪 Thread

使用介面支援兩種模式：

# 模式一：Python Library 直接呼叫
from copilot import CopilotClient
client = CopilotClient()
response = client.chat("解釋量子糾纏")
print(response)

# 模式二：OpenAI SDK 相容呼叫（指向本地 Server）
from openai import OpenAI
client = OpenAI(base_url="http://localhost:8000/v1", api_key="unused")
response = client.chat.completions.create(
    model="gpt-4",
    messages=[{"role": "user", "content": "Hello!"}]
)

架構上最值得關注的設計決策是「完全無狀態的 API 層 + 有狀態的瀏覽器層分離」，API Server 本身是無狀態的，所有狀態（登入 Session、對話歷史）都維持在 Playwright 瀏覽器實例內，這讓系統部署相對簡單，同時也支援 Docker 容器化（前提是在 Host 端完成初次登入）。

3. 社群熱度與生態採用

指標 數值
Stars 371（4天內）
Forks 129
語言 Python
建立日期 2026-06-19
最後更新 2026-06-23

從 129 個 Fork 來看，有大量使用者在進行二次開發或個人部署，這個比例（Fork/Star ≈ 35%）遠高於一般資訊性專案，說明使用者動機強烈且有實際落地需求。

生態整合層面，由於相容 OpenAI API 格式，理論上可直接接入：

  • Open WebUI / LibreChat 等本地 Chat 前端
  • LangChain / LlamaIndex 等 AI 框架
  • Cursor、Continue 等 AI 編碼工具（透過自訂 API endpoint）
  • 任何接受自訂 OpenAI base_url 的應用

4. 局限性與潛在風險

這個專案的技術可行性無庸置疑，但使用前必須清楚認識以下風險：

服務條款風險（最高）
微軟的 Copilot 消費者服務條款明確禁止自動化或 API 化存取。使用此工具可能導致帳號被暫停或封禁，且微軟有能力透過行為分析識別自動化流量。

穩定性風險
整個系統依賴 Copilot Web 前端的 DOM 結構與 API 行為，一旦微軟更新 UI 或後端協議，工具可能立即失效。這類「Screen Scraping」型工具的維護成本極高。

安全性風險
Session 文件以明文序列化形式存在本地，若機器被入侵，攻擊者可直接取得你的 Microsoft 帳號存取權限。此外，以你的個人帳號代理 API 請求，可能使帳號面臨濫用風險。

效能瓶頸
瀏覽器自動化本質上有較高延遲，並發能力受限於單一瀏覽器實例，不適合高吞吐量或生產環境負載。

5. 應用價值與適用場景

最適合的使用族群：

  • 個人開發者 / 學生：想在個人專案中實驗 GPT-4/GPT-5 能力，但無法或不願支付 API 費用
  • 受地區限制的開發者：在匿名 Copilot 被封鎖的地區，透過已登入帳號仍可正常使用
  • 工具鏈整合測試者：想在不花費 API 額度的情況下，測試 OpenAI 相容工具鏈的整合

不適合的場景：

  • 生產環境或商業用途
  • 高並發、低延遲需求
  • 需要長期穩定保障的應用

與其他方案比較：

方案 費用 穩定性 法律風險
Windows-Copilot-API 免費 低 高
OpenAI API 付費 高 無
Ollama（本地模型） 免費 高 無
Azure OpenAI 付費 高 無

Monday 的觀點與架構建議

最值得學習的設計決策

這個專案最聰明的地方在於「OpenAI 格式相容層」的設計——不是重新發明輪子，而是把現有生態的接口標準直接搬過來當 Output 格式。這讓零成本的接入變得可能。對任何想包裝非標準 AI 服務的開發者，這是一個值得參考的架構範式。

生產環境採用時的架構注意事項

如果你真的考慮在半正式環境使用，建議：

  1. 使用專用微軟帳號，與個人帳號完全隔離
  2. Session 文件加密存放，不要放在版本控制目錄內
  3. 加入熔斷機制（Circuit Breaker），當 Playwright 失敗時快速降級
  4. 定期監控微軟 Copilot 前端的變更，準備好應對 Breaking Changes

對 AI 應用開發方向的意義

這個專案的爆紅折射出一個現實：AI API 費用已成為個人開發者入門門檻的主要阻礙之一。當社群願意承擔服務條款風險去找「免費替代方案」，這對 AI 工具提供商是一個清晰的市場信號。

從技術趨勢看，「OpenAI API 格式已成為 AI 服務的事實標準接口」這件事越來越清楚——無論是 Ollama、vLLM 還是各類代理工具，都在往這個格式靠攏。未來構建 AI 應用時，選擇支援此標準的框架，能大幅降低日後切換底層模型的遷移成本。

參考來源