用 Codex GPT-5.5 與第三方 LLM 打通 Claude in Office:Gateway Adapter 實作筆記
最近我在測試一件事情。
我想知道,有沒有辦法把 Claude in Excel、Claude in PowerPoint、Claude in Word 這三個好用的 Office 外掛,串接到我自己常用的第三方 LLM 服務上來使用。
講白話就是,我想讓 Claude in Office 這個外掛介面繼續留在 Office 裡面,但背後實際回答問題、修改文件、操作表格的模型,可以切換成我自己平常較常使用的 Ollama、Google Gemini、NVIDIA API,甚至是目前最頂級的語言模型 OpenAI GPT-5.5。
這個想法一開始聽起來有點瘋狂。
但實際操作完之後,這個串接流程讓我有一個很重要的體認:AI 工具的前端介面、API 協議、gateway、模型供應商,其實全部都可以個別拆開使用。拆開之後,很多原本看起來只能照平台既定規則走的東西,都有彈性組合的空間。
我最後把這個實驗整理成一個 GitHub 專案:
anthropic-claude-office-gateway-adapter
這篇文章就來完整記錄這個專案的發想、踩坑、架構,以及一般讀者可以如何部署與使用。
Claude in Office 真正厲害的地方,是它整合在 Office 裡面
Anthropic 從 2026 年初開始,明顯加快把 Claude 放進辦公軟體工作流的速度。
根據 Anthropic 的 Release Notes,2026 年 2 月 5 日,Claude for PowerPoint 進入 research preview,同時 Claude for Excel 也升級到 Opus 4.6,並支援像是 pivot table editing、conditional formatting 這類更接近原生 Excel 操作的能力。
Anthropic 在 Claude Opus 4.6 的官方文章裡,也提到他們對 Claude in Excel 做了重大更新,並推出 Claude in PowerPoint research preview。後續再加上 Claude for Word,整個 Claude in Office 的輪廓就慢慢成形。
如果簡單拆開來看,這三個外掛大概是這樣:
Claude in Excel 可以讀懂 workbook、公式、儲存格和多工作表內容。你可以問它某個財務模型的假設怎麼來,也可以請它更新假設、檢查公式錯誤、找出 root cause,或是建立新的模型與填寫既有模板。官方文件也提到,它可以提供 cell-level citations,這一點對 Excel 其實很重要,因為你不只想知道答案,你還會想知道答案是從哪個儲存格來的。
Claude in PowerPoint 則是把 AI 放進簡報製作流程裡。它可以依照既有模板建立投影片、編輯目前的 slide、從自然語言產生完整 deck 結構,也可以把 bullet points 轉成圖表、流程圖或原生 PowerPoint 圖表。重點是,它會讀取現有 slide master、字體、顏色和版型規則,盡量維持簡報原本的格式。
Claude in Word 比較像文件工作流的助手。它可以閱讀文件、回答問題、編輯選取文字,並且保留周圍的格式、編號和樣式。它也支援 tracked changes,讓修改可以直接進到 Word 原生的修訂模式裡。對於合約、備忘錄、報告、企劃書這類文件,它的使用情境也很直觀。
所以我會說,Claude in Office 真正厲害的地方,不像微軟 Copilot 一樣只能聊天給建議。
它的價值在於,它真的進到你正在工作的 Office 檔案裡面,能實際動手幫你操作。
為什麼這比一般 AI 生成簡報更實用
這幾年大家很熱衷用 AI 生成簡報。
不管是 NotebookLM、Gemini,還是 OpenAI ChatGPT,很多工具都可以用圖像生成模型幫你生出一份看起來很漂亮的圖文簡報。
但我自己的實務經驗是,這類生成式簡報常有幾個問題。
第一,很多內容最後都是圖片格式。圖片裡面的文字看起來漂亮,但如果你要拿回 PowerPoint 裡面修改,常常還要靠 OCR 或人工重打。
第二,一旦 OCR 解析出文字後版面就很容易跑掉。AI 產生的東西在預覽時看起來可以,但真正要套到公司模板、客戶模板、既有簡報格式時,往往又要花一段時間調整。
第三,後續編輯不夠順。簡報真正麻煩的地方,通常在主管改、客戶改、團隊改、資料改的那一段。只要格式不能持續編輯,前面生成得再漂亮,最後還是會回到人工整理。
Claude in Office 這類外掛比較不一樣。
它不是在外面產出一張漂亮圖片,然後叫你自己搬回 Office。它是直接出現在 Excel、PowerPoint、Word 這些原生環境裡。
你可以選取一個範圍,叫它修改。你可以在 PowerPoint 裡開著簡報,叫它新增幾張 slide。你可以在 Word 裡選取一段文字,叫它改成比較正式、比較短、比較適合客戶看的語氣。
改完之後,檔案還是一般 Office 檔案。表格還是表格,投影片還是投影片,Word 修訂還是 Word 原生修訂。
Copilot 當然也有它的使用場景。不過就我自己的實測來看,Claude in Office 在某些文件編輯與人機協作場景裡,更像是一個真的坐在 Office 裡的工作夥伴,不只是旁邊給建議的聊天框。
可惜,好用的工具通常都有門檻
問題來了。
Claude in Office 這麼好用,當然不會完全沒有門檻。
目前 Anthropic 官方文件中,Claude for Excel、Claude for PowerPoint、Claude for Word 都屬於 beta 或 research preview 性質,並且主要提供給 Pro、Max、Team 或 Enterprise 方案使用者。這對本來就重度使用 Claude 的人沒有問題,但對一般使用者來說,狀況就不一樣。
很多人平常可能已經訂了 ChatGPT Plus、Google Gemini,或者手上已經有 OpenAI API、Google API、NVIDIA API、Ollama Cloud 之類的額度。
這時候如果只是為了 Claude in Office,再多訂一個 Claude Pro 或 Max,心理上會有一點卡。
尤其對於不是每天寫程式、不是每天跑 AI Agent 的使用者來說,每個月多一筆訂閱費,最後可能又用不完,形同資源浪費。這種感覺我完全可以理解。
所以我當時真正想問的問題其實很簡單:
如果 Claude in Office 官方本來就有支援第三方 Gateway,那我能不能把這條 Gateway 路線拿來接我自己的 LLM?
我意外發現,官方其實有 Gateway 路線
Anthropic 官方有一篇文件叫做 Use Claude for Excel, PowerPoint, and Word with third-party platforms。
這篇文件的重點是,如果組織已經透過 AWS Bedrock、Google Cloud Vertex AI、Azure AI Foundry,或自己的 LLM Gateway 來存取 Claude,就可以讓 Claude in Excel、PowerPoint、Word 透過這些第三方平台連線。
換句話說,Claude in Office 的登入方式不只有「登入 Claude 帳號」這條路。它也可以走第三方Gateway。
官方文件裡還提到,這和 Claude Code 的 gateway pattern 類似。如果組織已經讓 Claude Code 透過 LLM Gateway 運作,理論上 Office add-ins 也可以指向類似的 endpoint。
這裡還有一個很關鍵的細節。
Office add-in 是跑在 Microsoft application 裡面的 sandboxed iframe。它不能像 Claude Code 那樣直接使用作業系統的 keychain,所以 Anthropic 也提醒,不要在 Office add-in 裡直接輸入 raw cloud provider credentials,而是要輸入 gateway-issued token。
當時看到這裡,我的創意想法就冒出來了。
如果官方本來就允許 Gateway,那我是不是可以在自己電腦上跑一個本機 Gateway adapter?
第一個坑:大家的 API 語言格式不同,需要轉譯
真正開始做之後,第一個問題很快就出現。
Claude in Office 期待的是 Anthropic-compatible API,特別是 Anthropic Messages API 的格式。
可是很多常見的第三方模型服務,像 OpenAI、Google Gemini、NVIDIA NIM,主要提供的是 OpenAI-compatible API。
表面上兩邊都叫聊天 API,但 request、response、streaming、tool calling 的細節其實差很多。
舉例來說:
- Claude in Office 會呼叫類似
/v1/messages的 endpoint - OpenAI-compatible provider 常見的是
/v1/chat/completions - 串流 SSE event 的格式不一樣
- tool use 和 tool result 的資料結構不一樣
- 有些模型會回 thinking block,有些只回 text,有些會把 function call 包在完全不同的位置
如果只是一般聊天,問題還比較小。
但 Claude in Office 最有價值的地方,就是它會操作 Office 工具。Excel 寫入、PowerPoint 編輯、Word 修訂,這些都會牽涉 tool calling。只要 tool calling 格式轉錯,外掛可能就會回 network error、invalid tool parameters,或是模型看似有回答,但完全不會動手修改檔案。
當然,市面上有一些現成的轉譯工具,例如 LiteLLM。這些工具很方便,也能支援很多 provider。
只是我在做這個專案時,心裡有一個很明確的取捨。
Office 文件常常會包含公司資料、報價、合約、財務表、專案內容。若把 prompt、文件內容、API key 都交給外部轉譯服務,安全性和信任邊界就會變複雜。
第三方 gateway 當然有它方便的地方。只是當處理對象變成自己的 Excel、Word、PowerPoint 文件時,我會比較偏向把最小必要轉換層放在自己電腦上。
這就是我後來做 local adapter 的原因。
第二個坑:Office add-in 需要 HTTPS
第二個問題更實際。
本機程式通常跑在:
http://127.0.0.1:4010或:
http://localhost:4010但 Office add-in 對連線環境比較嚴格。Microsoft 在 Office Add-ins requirements 文件裡也提到,Office Add-ins 本質上是 web add-ins,使用 HTTPS endpoint 是強烈建議,在 Office on the web 或 Microsoft Marketplace 場景也會更明確要求 SSL-secured endpoint。
所以如果我只在本機開一個 HTTP gateway,Office 外掛通常不會接受。
這就是為什麼我需要一個 tunnel 工具,把本機 HTTP gateway 暴露成外部可連的 HTTPS URL。
我一開始試過 ngrok,也試過 Cloudflare Quick Tunnel。後來我最後選 localhost.run。
原因很簡單:localhost.run 可以直接用 Windows 內建 OpenSSH 建立 tunnel,不需要額外安裝大型 client。它的 Forever Free Tier 文件也提到,短期 tunnel 不需要註冊就能使用。若註冊帳號並加入 SSH key,免費 domain 的壽命有機會比較長。
當然,免費方案仍然有代價。domain 可能會變,速度也有限制。這不會是企業級 SLA,但對個人實驗、開源示範、小型工作流測試來說,已經很夠用了。
最後做出來的東西:Claude Office Gateway Adapter
我最後把這些踩坑整理成一個 GitHub 專案:
anthropic-claude-office-gateway-adapter
它的架構可以用一行來看:
Claude in Office
→ localhost.run HTTPS Gateway URL
→ local Python gateway adapter
→ provider-specific bridge
→ Ollama / Google Gemini / NVIDIA / Codex Bridge 等 upstream model這個專案的核心目標不是做一個超大型平台。
它的目標很單純:就是讓一般 Windows 使用者可以用一個批次檔,把本機 adapter、provider 轉譯、HTTPS tunnel 一次啟動起來,然後直接把 Gateway URL 和 Token 貼到 Claude in Excel、PowerPoint 或 Word 裡面來運作。
目前專案支援的方向包含:
- Ollama local / Ollama Cloud
- Google Gemini API
- NVIDIA API
- OpenAI-compatible provider
- Codex app-server bridge,可用來串接 Codex GPT-5.5
其中 Ollama 這條路也有官方背景。Ollama 官方文件有一頁 Anthropic compatibility,說明 Ollama 提供 Anthropic Messages API compatibility,可以讓 Claude Code 這類期待 Anthropic API 的工具連到 Ollama。文件裡也提到 Ollama 支援 local models 和 cloud models。
這也是我一開始會覺得這條路可行的原因。
既然 Claude Code 可以透過 Anthropic-compatible API 連到其他模型,那 Claude in Office 也值得試。
如何部署這個專案
以下用 Windows 環境示範。
你需要先準備:
- Windows 11
- Microsoft 365 的 Excel、PowerPoint 或 Word
- Python 3
- Git
- Windows OpenSSH client
- 至少一個你要使用的 upstream provider
Provider 可以是 Ollama、Google Gemini API、NVIDIA API、OpenAI-compatible API,或 Codex Bridge。你不需要全部都有,先選一個自己最容易測的就可以。
1. Clone 專案
git clone https://github.com/taoyutsun/anthropic-claude-office-gateway-adapter.git
cd anthropic-claude-office-gateway-adapter\windows2. 安裝 Python 套件
python -m pip install -r requirements.txt3. 設定 provider API key
如果你要使用 Google、NVIDIA 或其他需要 API key 的 provider,可以複製範例設定檔:
copy ClaudeOfficeProviders.env.example ClaudeOfficeProviders.env
notepad ClaudeOfficeProviders.env你只需要填自己要用的 provider。
這個 .env 檔案不要傳給別人。裡面會放你的 API key。
4. 建議設定 localhost.run SSH key
localhost.run 可以不用註冊就建立短期 tunnel。
不過我會建議註冊 localhost.run 帳號,並加入自己的 SSH key。這樣免費 domain 比較有機會維持久一點,也比較不容易每次都完全換掉。
localhost.run 的 SSH 用法也可以參考專案中 localhost.run Setup 說明或官方 CLI docs 和 Forever Free Tier。
5. 如果要使用 Codex Bridge,先登入
如果你想測 OpenAI / Codex Bridge 這條路,先執行:
.\Start-Claude-Office-CodexBridge-Login.bat這會使用獨立的 Codex home 來登入,不會直接覆蓋你主要的 Codex 設定。
6. 啟動 Gateway
接著執行:
.\Start-Claude-Office-CodexBridge.bat啟動並選擇要使用的服務供應商和語言模型後,終端機會顯示:
- Gateway URL
- Token
- Model
- Upstream provider
這時候打開 Claude in Excel、PowerPoint 或 Word,在 Gateway connection 裡填入 Gateway URL 與 Token。(專案預設會自動產生 gateway token。)
可以怎麼測試
我會建議讀者不要一開始就拿正式文件測。
可以先開一個空白 Excel、PowerPoint 或 Word,用簡單資料測通,再慢慢換成自己的工作檔案。
Excel 基本理解測試
請讀取目前工作表,幫我摘要這份表格的主要欄位、資料型態,以及你覺得最需要檢查的 3 個地方。Excel 寫入測試
請使用工具,在目前工作表建立一個簡單的月度支出摘要表。欄位包含「月份、收入、支出、結餘」,並填入 3 個月份的示範資料。完成後,請在表格下方加上一列合計。PowerPoint 測試
請幫我建立一份 5 張投影片的簡報大綱,主題是「第三方 LLM 串接 Claude in Office 的實作流程」。請包含:背景、問題、架構、操作流程、限制與風險。Word 測試
請閱讀這份文件,幫我整理成一段 300 字內的摘要,並列出 5 個可以改善語氣與結構的建議。跨 Office 測試
如果你同時開著 Excel 和 PowerPoint,也可以試:
請根據目前 Excel 工作簿裡的主要結果,幫我整理一段可以放到 PowerPoint 簡報的結論頁文字。這類測試可以幫你確認三件事:
- Gateway 是否能登入
- 模型是否能正常回覆
- 模型是否真的會調用 Office 工具
第三點最重要。因為有些模型可以聊天,但不一定擅長 tool calling。能登入不代表能穩定操作 Excel 或 PowerPoint。
這個專案目前的限制
我自己測到現在,這個方向是可行的。但我也不想把它講成萬能工具。
第一,這不是 Anthropic、Microsoft、Ollama、Google、NVIDIA 的官方產品。這是一個個人研究與實作用的 open-source adapter。使用前,請自行確認你使用的 provider 條款。
第二,不同模型的 Office 工具調用能力差很多。有些模型一般聊天很順,但遇到 Excel 寫入、PowerPoint 編輯、Word tracked changes,就可能開始出錯。這不是單純 gateway 的問題,也和模型本身對 tool schema 的理解能力有關。
第三,免費 API 或免費模型常有 rate limit。Office 工具呼叫看起來只有一個動作,但背後可能觸發多次 LLM request。若 provider 的 RPM 或 TPM 很低,就可能出現 Too Many Requests。
第四,localhost.run 免費 tunnel 有時間性限制。URL 可能變,斷線後可能要重新啟動 launcher。設定 SSH key 可以改善體驗,但它仍然不是企業級固定網域方案。
第五,無須把真實 API key 貼到 Office Gateway token 欄位。Gateway token 應該使用 adapter 產生的 token。
我會建議大家先用測試資料跑通,再決定要不要拿來處理正式文件。
我自己的 take-home message
這次實作對我來說,最有趣的地方其實不是多做了一個批次檔。
表面上看起來,它只是幫我啟動本機 proxy、模型 provider、localhost.run tunnel,然後印出一個 Gateway URL。
但真正做完之後,我才發現這件事背後的意義比較大。
當我們把 AI 工具拆成幾個層次來看,很多事情會變得比較清楚:
- 前端介面:Claude in Office
- 協議格式:Anthropic Messages API
- 轉譯層:local gateway adapter
- HTTPS 通道:localhost.run
- 模型供應商:Ollama、Google、NVIDIA、OpenAI / Codex
以前我們常常把這些東西綁在一起看。平台給什麼,我們就用什麼。
可是實際拆開之後,你會發現很多模組其實可以替換。前端可以保留,模型可以換。API 協議可以轉。HTTP 可以透過 tunnel 變成 HTTPS。認證也可以透過 gateway token 隔一層。
這對一般使用者來說,可能一開始有點技術門檻。
但對經常使用 AI 工具的人來說,這很可能會變成一種新的個人 AI 基礎建設。
你不用每次都等平台官方幫你整合。你可以用自己已經付費或免費的平台、已經熟悉、已經測過穩定的模型,串接到真正每天會用的工作場景裡。
這就是我做這個專案最大的收穫。
先求有,再求好。
先把最小可行版本跑通,後面很多想像空間就會自己冒出來。
📌 您可能也會有興趣的其他文章:
- 從零開始部署龍蝦 OpenClaw:Windows + WSL + Telegram + 多供應商入口,搭配免費與高 CP 值模型來源無痛暢用
- 想玩 AI Agent 自動化卻怕太花錢?9 個免費與高 CP 值雲端 API 來源一次整理
- 從雲端 AI LLM 到本地 AI Agent:我用 Vibe Coding 升級 Remove Text Extra Spaces
留言
張貼留言