DEV Community: codemee

Codex 的 Subagents 數量上限

codemee — Sun, 05 Jul 2026 11:55:29 +0000

本文以此版文為測試依據：

> codex --version
codex-cli 0.142.5

在 Codex 的 Subagents 文件中提到，同時可以執行的 Subagents 數量由設定檔中的 agents.max_threads 決定，沒有設定時，預設是 6，不過時測時預設卻不是 6：

> codex exec "最多可以執行幾個 subagent？" 2>$null | glow -s light

  最多可同時執行 3 個 subagent；加上主 agent，共有 4 個並行執行槽位。

你可以看到預設是 4 個。

由於 codex exec 會透過標準錯誤輸出額外的資訊，為了避免干擾我們檢視回覆內容，因此利用 2>$nul 在 PowerShell 中把錯誤輸出轉向丟棄。另外，glow 是顯示 Markdown 文件的 CLI 工具。

但即使透過 agents.max_threads 強制設定：

> codex exec --config agents.max_threads=10 "最多可以執行幾個 subagent？" 2>$null | glow -s light

  最多可同時執行 3 個 subagent；加上我這個主 agent，共 4 個並行名額。

結果依然沒變，真是奇怪。還好，Codex CLI 是開放原始碼的專案，這種測試結果跟文件不一致的情況，就請 Codex 自己查看看原始碼：：

> codex exec "查一下原始碼中跟 subagent 數量上限有關的部分有哪些？查到後告訴我設定的方式" 2>$null | glow -s light

  目前 Codex 原始碼有兩套 subagent 數量限制，取決於使用哪一版 multi-agent。

  ### 1. 傳統 multi-agent                                          

  設定鍵：                                                         

    [features]                                                     
    multi_agent = true                                             

    [agents]                                                       
    max_threads = 12                                               

  預設值是  6 ：                                                   

    DEFAULT_AGENT_MAX_THREADS: Option<usize> = Some(6);            

  主要相關原始碼：                                                 

  •  codex-rs/core/src/config/mod.rs  https://github.              
  com/openai/codex/blob/main/codex-rs/core/src/config/mod.rs：預設值、讀取
  agents.max_threads                                               
  •  codex-rs/core/src/agent/control.rs  https://github.           
  com/openai/codex/blob/main/codex-rs/core/src/agent/control.rs：把限制交給
  session 執行 limiter                                             
  •  codex-rs/core/src/agent/registry.rs  https://github.          
  com/openai/codex/blob/main/codex-rs/core/src/agent/registry.rs：配置與回收
  spawn slot                                                       
  •  codex-rs/protocol/src/error.rs  https://github.               
  com/openai/codex/blob/main/codex-rs/protocol/src/error.rs：超過限制時的
  AgentLimitReached                                                

  也可以只對單次 CLI 執行覆寫：                                    

    codex -c agents.max_threads=12                                 

  或：                                                             

    codex exec -c agents.max_threads=12 "你的任務"                 

  ### 2. Multi-agent V2                                            

  新版另有獨立設定：                                               

    [features.multi_agent_v2]                                      
    enabled = true                                                 
    max_concurrent_threads_per_session = 8                         

  預設值是  4 ：                                                   

    DEFAULT_MULTI_AGENT_V2_MAX_CONCURRENT_THREADS_PER_SESSION: usize = 4;

  Schema 規定最小值是  1 ，原始碼目前看不到硬性最大值。設定 Schema 
  https://github.com/openai/codex/blob/main/codex-rs/core/config.schema.json

  你這個工作階段顯示「4 available concurrency slots」，與 V2       
  的預設值完全一致，所以如果要改目前看到的 4，應優先設定：         

    [features.multi_agent_v2]                                      
    enabled = true                                                 
    max_concurrent_threads_per_session = 8                         

  設定檔位置通常是 Windows 的：                                    

    %USERPROFILE%\.codex\config.toml                               

  修改後需重新啟動 Codex session。 agents.max_threads  和 V2 的    
  max_concurrent_threads_per_session                               
  是不同限制；為避免版本或功能切換造成落差，也可以兩個都設：       

    [features]                                                     
    multi_agent = true                                             

    [features.multi_agent_v2]                                      
    enabled = true                                                 
    max_concurrent_threads_per_session = 8                         

    [agents]                                                       
    max_threads = 8                                                

  數值開太高可能增加 429、token 消耗和資源競爭；官方把舊版預設設為 6、新版設為
  4，應是刻意的保守值。

你可以看到居然有兩套 Subagent 機制，該不會現在 Codex 其實是採用文件上沒有寫的 multi_agent_v2 吧？

> codex exec "現在是不是有啟用 multi_agent_v2？有的話，要如何設定 Subagent 數量上限？" 2>$null | glow -s light

  沒有啟用  multi_agent_v2 。本機狀態是：                          

    multi_agent       stable             true                      
    multi_agent_v2    under development  false                     

  目前工作階段上限是 4 個 agent thread（包含主 Agent），因此最多同時執行 3 個
  Subagent。                                                       

  若要設定全域上限，編輯  %USERPROFILE%\.codex\config.toml ：      

    [agents]                                                       
    max_threads = 4                                                
    max_depth = 1                                                  

  也可放在專案的  .codex/config.toml 。 max_threads  預設為 6； max_depth
  控制 Subagent 可繼續產生幾層子代理。設定後重開 Codex 工作階段。  

  若要實驗性啟用 v2：                                              

    codex features enable multi_agent_v2                           

  但一般 Subagent 工作目前使用穩定的  multi_agent  即可，無須啟用  
  v2。參考：Subagents                                              
  https://developers.openai.com/codex/subagents、Configuration reference
  https://developers.openai.com/codex/config-reference。

咦？並沒有啟用 multi_agent_v2，但 multi_agent_v2 預設限制是 4 個 Subagent，這看起來跟我們前面的測試相符，死馬當活馬醫，如果試試用用 multi_agent_v2 的方式設定：

> codex exec --config features.multi_agent_v2.max_concurrent_threads_per_session=6 "最多可以執行幾個 subagent？" 2>$null | glow -s light

  最多可同時執行 5 個 subagent，加上主 agent 共 6 個並行工作槽位。

成功了，雖然沒有啟用 multi_agent_v2，但卻要照著 multi_agent_v2 的方式設定，原因不知道，但至少目前可行。

誠品線上庫存查詢工具 — 技術報告

codemee — Sun, 05 Jul 2026 06:02:10 +0000

⚠ 本文由 Claude Code 生成

1. 問題背景

誠品線上（eslite.com）的商品頁面雖然會顯示庫存狀態，但僅能逐一開啟網頁人工確認，無法：

一次查詢多筆商品
對限量或熱銷商品做「上架/補貨」的持續監控
以結構化格式（JSON）取得資料供其他程式串接

因此本專案目標是撰寫一支輕量 CLI 工具，直接呼叫誠品線上背後的商品 API，取代人工刷新網頁的行為。開發過程中遇到的核心技術問題並非「業務邏輯」，而是如何繞過前端防護、正確組出可用的 API 請求。以下逐項說明。

2. 核心技術問題與解法

2.1 Cloudflare TLS 指紋偵測導致 403

誠品線上的 API 後端（athena.eslite.com）架設在 Cloudflare 之後。Cloudflare 除了檢查 HTTP Header，還會在 TLS handshake 階段比對 JA3/JA3S 指紋（ClientHello 中的 cipher suite 順序、TLS 擴充欄位順序、支援的橢圓曲線等）。

Python 的 requests 或 httpx 底層使用 OpenSSL 產生的 TLS 指紋，與真實 Chrome 瀏覽器不同，即使把 User-Agent 偽裝成 Chrome，Cloudflare 仍能從 TLS 層辨識出「非瀏覽器流量」並直接回傳 403 Forbidden：

# ❌ 會被 Cloudflare 擋下（TLS 指紋不符，即使偽造了 User-Agent）
import requests

resp = requests.get(
    "https://athena.eslite.com/api/v1/products/10012013492683166052007",
    headers={"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/120.0"},
)
print(resp.status_code)  # 403

解法：改用 curl-cffi，它底層綁定 curl-impersonate，能重現特定瀏覽器版本（如 Chrome 120）的實際 TLS/HTTP2 指紋，而非只偽造 Header：

# ✅ curl-cffi 以 impersonate 參數重現真實 Chrome 的 TLS 指紋
from curl_cffi import requests as cffi_requests

resp = cffi_requests.get(
    "https://athena.eslite.com/api/v1/products/10012013492683166052007",
    headers={"Accept": "application/json", "Referer": "https://www.eslite.com/"},
    impersonate="chrome120",
    timeout=10,
)
resp.raise_for_status()

impersonate="chrome120" 這行是整個工具能否運作的關鍵，缺少它請求一律被 Cloudflare 攔截。

2.2 API 要求動態時間戳參數

觀察誠品線上網頁實際發出的請求後發現，商品 API 每次呼叫都必須帶上 datetime query 參數，格式為 YYYYMMDDHHmmss（如 20260705143210），推測用於後端做請求時效驗證或快取失效判斷：

from datetime import datetime

def fetch_product(guid: str) -> dict:
    url = f"https://athena.eslite.com/api/v1/products/{guid}"
    ts = datetime.now().strftime("%Y%m%d%H%M%S")
    resp = cffi_requests.get(
        url,
        params={"datetime": ts},
        headers=_HEADERS,
        impersonate="chrome120",
        timeout=10,
    )
    resp.raise_for_status()
    return resp.json()

若省略此參數或帶入固定值，部分情況下 API 會回傳錯誤或非預期的快取結果，因此每次請求都即時產生當下時間戳。

2.3 商品 GUID 的容錯擷取

使用者輸入的來源可能是純數字 GUID，也可能是完整商品頁 URL（如 https://www.eslite.com/product/10012013492683166052007）。為避免要求使用者自行複製 GUID，改用正規表達式從任意字串中擷取 20 位以上的連續數字：

import re

_GUID_RE = re.compile(r"\d{20,}")

def extract_guid(text: str) -> str:
    m = _GUID_RE.search(text)
    if m:
        return m.group()
    raise ValueError(f"無法從 {text!r} 解析出商品 GUID（需為 20 位以上數字）")

這讓 CLI 同時支援兩種輸入形式：

uv run eslite_stock.py 10012013492683166052007
uv run eslite_stock.py https://www.eslite.com/product/10012013492683166052007

2.4 持續監控（--watch）與狀態顯示

限量書籍的補貨時機難以預測，因此加入 --watch N 參數，每 N 秒重新查詢並清空終端機重繪，直到使用者按 Ctrl+C 中斷：

if args.watch:
    try:
        while True:
            console.clear()
            query_all(guids, args.raw_json)
            console.print(f"\n[dim]每 {args.watch} 秒更新一次，按 Ctrl+C 結束[/dim]")
            time.sleep(args.watch)
    except KeyboardInterrupt:
        console.print("\n[dim]已停止監控[/dim]")

庫存與購買狀態以顏色區分，方便在終端機掃視多筆商品時快速辨識可搶購的項目：

_BUTTON_LABEL = {
    "add_to_shopping_cart": "[bold green]可加入購物車[/bold green]",
    "out_of_stock":         "[bold red]缺貨[/bold red]",
    "not_for_sale":         "[yellow]停售[/yellow]",
    "pre_order":            "[cyan]預購中[/cyan]",
}

2.5 多目標查詢與錯誤隔離

支援一次傳入多個 GUID/URL，且單一商品查詢失敗（如 GUID 打錯、該商品已下架）不應中斷整批查詢：

def query_all(guids: list[str], raw_json: bool) -> None:
    for i, guid in enumerate(guids):
        try:
            data = fetch_product(guid)
        except Exception as e:
            status = getattr(getattr(e, "response", None), "status_code", None)
            if status:
                console.print(f"[red]HTTP {status}（GUID: {guid}）[/red]")
            else:
                console.print(f"[red]錯誤：{e}（GUID: {guid}）[/red]")
            continue
        ...

每筆商品各自 try/except，確保部分失敗不影響其餘商品的查詢結果。

2.6 Windows 終端機中文編碼相容性

在部分 Windows 終端環境（如舊版 cmd.exe）下，sys.stdout 預設編碼並非 UTF-8，直接輸出中文書名或 rich 的方塊字元會出現亂碼或 UnicodeEncodeError。啟動時主動偵測並重新設定編碼：

if sys.stdout.encoding and sys.stdout.encoding.lower() != "utf-8":
    sys.stdout.reconfigure(encoding="utf-8", errors="replace")
    sys.stderr.reconfigure(encoding="utf-8", errors="replace")

2.7 PEP 723 獨立腳本（零安裝執行）

本工具以 PEP 723 內嵌相依套件宣告，使用者無需事先 pip install 或維護虛擬環境，uv run 會自動解析並快取相依套件：

# /// script
# requires-python = ">=3.11"
# dependencies = [
#   "curl-cffi>=0.7",
#   "rich>=13",
# ]
# ///

uv run eslite_stock.py <GUID或URL> [--watch 秒] [--json]

3. 架構小結

使用者輸入 (GUID / URL)
        │
        ▼
  extract_guid()  ──▶ 正規表達式擷取 20 位以上數字
        │
        ▼
  fetch_product()  ──▶ curl-cffi + impersonate="chrome120" 繞過 Cloudflare TLS 指紋偵測
        │              帶入即時 datetime 參數
        ▼
  athena.eslite.com/api/v1/products/{guid}
        │
        ▼
  show_product() / json.dumps()  ──▶ rich 彩色輸出 或 原始 JSON
        │
        ▼
  （若 --watch）迴圈重新查詢，Ctrl+C 結束

整個專案最主要、也最不易從程式碼本身看出「為什麼這樣寫」的技術決策，是 2.1 節的 TLS 指紋問題：一般開發者在遇到 API 回傳 403 時，直覺會先懷疑 Header 或 Cookie，但根因其實在 TLS 層，必須改用能重現瀏覽器指紋的函式庫（curl-cffi）才能解決，單純偽造 User-Agent 完全無效。

Tkinter 快顯功能表關閉殘影調查報告

codemee — Sun, 05 Jul 2026 05:57:10 +0000

⚠ 本篇報告全文由 Codex 生成

1. 摘要

test_tk_manual.py 在 Windows 上顯示 Tkinter 右鍵快顯功能表後，若使用者選擇 Close 並直接在選單 callback 中執行 root.destroy()，主視窗雖然關閉，畫面上卻可能暫時留下選單殘影。

調查確認，問題核心不是一般 Tk widget 沒有刷新，而是 Windows 上的 Tk 選單使用原生 menu loop。選單 callback 執行時，menu.tk_popup() 可能仍未返回；此時銷毀選單的 owner 視窗，會破壞 Windows 正常結束與重繪選單的時序。

目前的修正策略如下：

選單 callback 不直接銷毀主視窗。
callback 設定關閉旗標。
呼叫 Windows EndMenu()，明確結束目前執行緒的原生 menu loop。
等 menu.tk_popup() 返回後，再由外層事件處理函式執行 root.destroy()。

目前版本已通過 Python 語法檢查；最終視覺效果仍需由使用者在實際桌面環境確認。

2. 原始展示範例

以下是會觸發問題的最小範例：

import tkinter as tk

root = tk.Tk()
root.geometry("300x100+100+100")

menu = tk.Menu(root, tearoff=0)
menu.add_command(label="Close", command=root.destroy)

def show_menu(event):
    menu.tk_popup(event.x_root, event.y_root)

root.bind("<Button-3>", show_menu)
root.mainloop()

重現步驟：

執行程式。
在主視窗按滑鼠右鍵。
在快顯功能表選擇 Close。
觀察主視窗消失後，選單區域是否留下殘影。

問題點在這一行：

menu.add_command(label="Close", command=root.destroy)

它會在選單 callback 尚處於原生選單處理流程時，立即銷毀 owner 視窗。

3. 平台行為與根因

Tk 的選單行為會依視窗平台而不同。Tk 開發資料指出，在 Windows 上選單由原生機制處理，而且 menu post 呼叫可能在選單關閉前不返回，但等待期間仍會處理事件。參考資料：

事件順序可概括為：

使用者點選 Close
        |
        v
Tk 執行選單 command callback
        |
        |  此時 Windows menu loop 可能仍在運作
        v
若 callback 直接 root.destroy()
        |
        v
owner 視窗提前消失，選單清除／重繪時序不完整
        |
        v
可能留下快顯功能表殘影

因此，安全的關閉點不是選單 callback 本身，而是原生 menu loop 結束、tk_popup() 返回之後。

4. 修正歷程

4.1 直接銷毀主視窗

初始程式在選單命令中直接呼叫：

menu.add_command(label="Close", command=root.destroy)

結果：主視窗關閉，但 Windows 桌面可能留下快顯功能表殘影。

4.2 `unpost()`、釋放 grab，再用 `after_idle()` 關閉

第一次嘗試：

def close_window():
    menu.unpost()
    menu.grab_release()
    root.after_idle(root.destroy)

結果：殘影仍存在。

原因：after_idle() 只保證目前 Tk callback 返回後執行，不保證 Windows 原生 menu loop 已經退出。

4.3 延遲 100 ms 後關閉

第二次嘗試：

root.after(100, root.destroy)

結果：殘影仍存在。

原因：原生選單等待期間仍會處理 Tk 事件，因此計時器可能在 tk_popup() 尚未返回時觸發。增加任意延遲不能建立可靠的事件順序，只會造成時間相依的行為。

4.4 callback 只設定旗標

第三次嘗試讓 callback 只記錄關閉要求：

def close_window():
    global close_requested
    close_requested = True

並在 tk_popup() 返回後關閉：

menu.tk_popup(event.x_root, event.y_root)
if close_requested:
    root.destroy()

結果：選擇 Close 後主視窗沒有立即關閉，必須再按一下滑鼠，選單與主視窗才一起消失。

原因：只設定旗標沒有主動終止目前的原生 menu loop，所以 tk_popup() 仍未返回，外層的 root.destroy() 尚無機會執行。

4.5 使用 `menu.unpost()` 或 `tk::MenuUnpost`

後續分別測試 widget 層級的：

menu.unpost()

以及 Tk 內部完整狀態清理：

root.tk.call("tk::MenuUnpost", menu._w)

結果：實際環境仍需額外滑鼠點擊才能讓 tk_popup() 返回。

這表示 Tk 層級的 unpost 清理在此 Windows 原生 menu loop 中不足以立即終止追蹤流程。

4.6 使用 Windows `EndMenu()`

目前版本改用 Windows API：

ctypes.windll.user32.EndMenu()

EndMenu() 的用途是結束呼叫執行緒目前作用中的選單。callback 僅終止 menu loop，不銷毀 owner；等 tk_popup() 返回後，才關閉主視窗。

5. 目前完整展示範例

import ctypes
import tkinter as tk

root = tk.Tk()
root.geometry("300x100+100+100")

label = tk.Label(root, text="Right-click me")
label.pack(fill="both", expand=True)

menu = tk.Menu(root, tearoff=0)
close_requested = False

def close_window():
    global close_requested
    close_requested = True
    ctypes.windll.user32.EndMenu()

menu.add_command(label="Close", command=close_window)

def show_menu(event):
    try:
        menu.tk_popup(event.x_root, event.y_root)
    finally:
        menu.grab_release()

    if close_requested:
        root.destroy()

root.bind("<Button-3>", show_menu)
label.bind("<Button-3>", show_menu)
root.mainloop()

6. 修正版事件順序

使用者點選 Close
        |
        v
close_window() 設定 close_requested
        |
        v
EndMenu() 結束 Windows 原生 menu loop
        |
        v
menu.tk_popup() 返回
        |
        v
finally 釋放 menu grab
        |
        v
show_menu() 檢查 close_requested
        |
        v
root.destroy() 安全銷毀主視窗

7. 驗證方式

7.1 語法檢查

.\.venv\Scripts\python.exe -m py_compile test_tk_manual.py

預期結果：命令結束碼為 0，沒有輸出語法錯誤。

7.2 手動視覺測試

.\.venv\Scripts\pythonw.exe .\test_tk_manual.py

測試項目：

編號	操作	預期結果
1	在主視窗按右鍵	`Close` 選單立即出現
2	點選 `Close`	選單與主視窗立即消失
3	觀察原選單位置	不留下選單內容或陰影殘影
4	再次執行，點選選單外部	選單取消，主視窗保持開啟
5	重複快速開啟與取消選單	不應卡住 grab 或要求額外點擊

7.3 驗收狀態

項目	狀態
Python 語法檢查	已通過
原始問題重現	已確認
`after_idle()` 修正	失敗
100 ms 延遲修正	失敗
Tk `unpost` 修正	失敗
Windows `EndMenu()` 修正	已實作，待使用者確認視覺結果

8. 限制與後續考量

目前修正呼叫 Windows API，因此是 Windows 專用方案。若程式未來需要跨平台，應依 root.tk.call("tk", "windowingsystem") 分流：Windows 使用 EndMenu()；其他平台保留 Tk 原生關閉流程。

若 EndMenu() 在目標機器上仍無法消除殘影，下一步不應再增加延遲時間，而應考慮：

收集 Python、Tcl/Tk 與 Windows 的確切版本。
建立獨立的最小重現程式並記錄螢幕畫面。
改用自訂 Toplevel 實作非原生快顯選單，以完全避開 Windows native menu loop。
比較不同 Tcl/Tk 發行版本，確認是否為特定版本的 Windows 選單缺陷。

Gemini 模型的 tokenizer

codemee — Tue, 27 Jan 2026 02:52:19 +0000

Gemini 並沒有提供類似 OpenAI 的 Tokenizer 頁面，方便大家觀察切割 token 的結果，如果你有使用 Vertex AI，則可以透過本文介紹的兩種方式查看。

Vertex AI Studio

在 Vertex AI Studio 中，在輸入框輸入內容時，輸入框下緣會顯示目前的 token 數（Gemini 稱為『詞元』），像是底下的例子就告訴我們『這是什麼奇怪的世界？』會被切割為 5 個詞元：

如果想知道實際切割的結果，只要按一下顯示詞元數量的地方，就會在右側顯示詳細資料：

它會以不同的背景色來標示每一個詞元的涵蓋範圍，你也可以切換頁次，觀察每個詞元對應的編號：

要特別提醒你的是，Vertex AI Studio 和 Google AI Studio 雖然很相似，但這個觀察 token 切割結果的功能就只有 Vertex AI Studio 才有。

透過 Vertex AI API 取得切割結果

如果你需要在程式中即時取得切割詞元的結果，也可以透過 Vertex AI API，在 GenAI SDK 的 Client 類別中，提供有 models.compute_tokens 方法可以取得切割資訊，它的參數和 generate_content 相同，但會傳回 ComputeTokensResponse 類物件，它的 tokens_info 屬性是一個 TokensInfo 類物件的串列，個別代表輸入的 contents 中每個 content 的切割結果，其中 token_ids 是詞元編號的串列、tokens 是個別詞元對應的文字段落，role 是發言角色。

以下我們就依據上述結構，設計了一個簡單的 CLI 程式，可以指定文字與模型，輸出切割結果：

from google import genai
from rich.console import Console
import sys
import dotenv
import os

dotenv.load_dotenv()

client_vertex = genai.Client(
    vertexai=True,
    api_key=os.environ.get("VERTEX_API_KEY")
)

color_map = {
    '3': '#ccbfee',
    '2': '#beedc6',
    '1': '#f4d7ab',
    '0': '#f4aeb1',
    # '4': '#a4dcf3',
}

console = Console()

def main():
    if len(sys.argv) < 2:
        console.print("用法：main.py prompt [model_name]", style="bold red")
        return

    prompt = sys.argv[1].encode("utf-8")
    model = sys.argv[2] if len(sys.argv) > 2 else "gemini-3-pro-preview"
    result = client_vertex.models.compute_tokens(
        model=model,
        contents=prompt
    )

    print(f"共 {len(result.tokens_info[0].token_ids)} 個 token：")
    for i, token in enumerate(result.tokens_info[0].tokens):
        color_index = str(i % len(color_map))
        bg_color = color_map.get(color_index, '#ffffff')
        console.print(
            token.decode("utf-8").replace("\n", "\\n"),
            style=f"on {bg_color}",
            end="",
        )
        console.print(" ", end="")

if __name__ == "__main__":
    main()

你可以像是這樣使用，如果沒有指定模型，預設會是 gemini-3-pro-preview：

➜ uv run main.py "今天是偉大的日子" gemini-2.5-flash

它會比照 Vertex AI Studio 的顏色顯示底色：

我也在 HuggingFace 上部署了一個 Gradio 的版本：

再次提醒，models.compute_tokens 只有 Vertex AI API 才能使用，如果你使用 Gemini API，雖然看起來也可以叫用，但是只會傳回錯誤，告訴你這個方法只有 Vertex AI API 才支援。我不知道 Google 到底在想什麼，切割 token 的資訊都要 Vertex AI 才提供，政策沒有變更之前，你就只能透過上述方法取得相關資訊，還好，models.compute_tokens 並不會號用詞元，所以不會產生費用。

在我的觀察中，Gemini 的 tokenizer 不會把單一中文字元切開成多個詞元，非句首的英文單字也不大會切割成多個詞元，所以如果單純以詞元數來看，相同 context windows 下 Gemini 模型可以吃進入比 OpenAI 模型更多的文本，這也是大部分文章沒有提到的一點。

Colab 中在背景執行程式的方法

codemee — Sat, 24 Jan 2026 03:59:37 +0000

Colab 背後仰賴一個跑 Linux 的虛擬機器執行你的 Python 程式，如果要測試一些後端程式，其實也是沒有問題，尤其即使是免費用戶，也可以打開終端機直接操作背後的作業系統，非常方便。本文介紹在測試後端程式時常會需要在背景執行程式的方法。

直接開終端機下指令

要在背景執行指令，最簡單的方法就是開啟終端機下指令，例如：

/content# sleep 10 &
[1] 7542
/content#

指令看起來會立即結束，如果以 ps 指令檢查，就會看到在背景執行的指令：

/content# ps -eo pid,command | grep sleep
   7542 sleep 10
   7554 sleep 1
   7556 grep --color=auto sleep
/content#

等它結束後再度查詢：

/content# ps -eo pid,command | grep sleep
   7644 sleep 1
   7646 grep --color=auto sleep
[1]+  Done                    sleep 10
/content#

就會看到原本在背景執行的 sleep 10 已經不見了，而在查詢指令結束後，也會出現已經結束的背景程式資訊。

使用 `!` 執行指令

Colab 本質是 Jupyter，提供有 ! 特殊命令可以執行系統指令，所以理論上可以 !sleep 10 & 這樣執行背景程式：

但你會發現儲存格會一直處在執行中狀態，直到背景程式結束：

你會看到儲存格的執行時間是 10 秒，這使得背景程式執行時無法執行其他儲存格。會發生這樣的狀況，是因為 ! 必須捕捉所執行程式的輸出，以便能夠顯示在儲存格的輸出區域，所以即使是以背景方式執行程式，但仍持續捕捉它的輸出，所以儲存格就會停留在執行中的狀態。

要解決這個問題，最直接的方式就是把背景程式的輸出轉向，例如 !sleep 10 >/dev/null 2>&1 &：

你可以看到這裡儲存格的執行時間是 0 秒，也就是執行儲存格後就會離開執行中的狀態，即使背景程式仍在執行中，這樣就可以在背景執行必要的程式，但又可以執行其他儲存格了。要特別注意的是，轉向時，要把標準輸出以及標準錯誤都一併轉向。

上述指令是把輸出都轉向到 Linux 的黑洞檔案 /dev/null 中，所以完全無法看到背景程式的輸出或錯誤訊息。如果需要看到輸出結果，也可以轉向到任一檔案，例如 ! python -c "print 'hello'" > out.log 2>&1 &：

就可以看到背景程式有噴出錯誤訊息，對於需要檢視後端程式輸出或除錯很有幫助。

使用 `nohup` 協助轉向

如果覺得上述輸出轉向語法有點複雜，也可以透過 nohup 指令自動處理，這個指令原本是為了讓你可以在執行即使斷開當前終端機連線也會繼續執行的背景程式。前述的背景程式執行方法，會在你離開當前終端機階段（關閉終端機或是結束 ssh 連線等，稱為 hang up，也是掛斷電話的意思）時一併結束，nohangup 代表 "no hang up"，表示不理會掛斷。nohup 會幫你把輸出轉向到 nohup.out 檔，例如 !nohup sleep 10 &：

執行後唯一的輸出就是告知輸出轉向檔案的訊息。

要注意的是，! 一樣會把儲存格輸出區的輸入轉向給執行的指令，如果沒有加上 & 指定在背景執行，斷開儲存格輸入與指令的連結，一樣會處於等待輸入的狀態，像是 !nohup sleep 10：

就無法執行其他儲存格了。

遠端使用 ollama 的方法

codemee — Mon, 19 Jan 2026 06:52:04 +0000

ollama 除了可以在本機使用外，也可以從遠端連接，不過預設 ollama 只接受本機的連線，無法從遠端連接。

設定可接受遠端連線

要讓 ollama 接受遠端連線，必須在啟動 ollama 服務前設定 OLLAMA_HOST 環境變數為 0.0.0.0，否則就只會接收本機連線。設定環境變數時可設定為 0.0.0.0 保留預設連接埠 11434，或是也可以同時指定連接埠，像是 0.0.0.0:11434，不過不建議更改連接埠，以維持最大的相容性。

Window 環境

在安裝完 ollama 後，你可以利用以下指令查看目前 ollama 監聽的 IP：

netstat -ano | findstr ":11434"

輸出如下，可以看到目前只監聽本機迴路的 IP：

  TCP    127.0.0.1:3923         127.0.0.1:11434        TIME_WAIT       0
  TCP    127.0.0.1:11434        0.0.0.0:0              LISTENING       21544

也可以透過測試連線來確認，首先取得本機的 IP 位址：

Get-NetIPAddress | Select-Object IPAddress, InterfaceAlias, AddressFamily | Where-Object {$_.AddressFamily -eq 'IPv4'}

IPAddress      InterfaceAlias                     AddressFamily
---------      --------------                     -------------
172.19.144.1   vEthernet (WSL (Hyper-V firewall))          IPv4
169.254.130.47 區域連線* 3                                 IPv4
169.254.236.94 區域連線* 2                                 IPv4
169.254.221.5  藍牙網路連線                                IPv4
192.168.0.71   Wi-Fi                                       IPv4
127.0.0.1      Loopback Pseudo-Interface 1                 IPv4

利用 curl 連線本機迴路測試：

curl http://127.0.0.1:11434/

可正常運作：

Ollama is running

但如果利用 Wi-Fi IP 連線：

curl http://192.168.0.71:11434/

就會無法連線：

curl: (7) Failed to connect to 192.168.0.71 port 11434 after 2032 ms: Could not connect to server

為了讓 ollama 可以接受本機迴路以外的連線，你可以在使用者或是系統環境變數加入 OLLAMA_HOST：

重新登入或是重新啟動後即可確認環境變數：

$env:OLLAMA_HOST 
0.0.0.0:11434

再透過指令確認目前監聽的狀況：

netstat -ano | findstr ":11434"

輸出如下：

  TCP    0.0.0.0:11434          0.0.0.0:0              LISTENING       11832
  TCP    [::]:11434             [::]:0                 LISTENING       11832

即可看到監聽了所有的 IP，如果用 curl 測試：

curl http://192.168.0.71:11434/
Ollama is running

會看到可以正常連線。

Linux/MacOS 下手動啟動

如果你沒有把 ollama 安裝成自動啟動的服務，就只要在使用者自己的 .bashrc 或是 .zshrc、.profile 檔中匯出環境變數即可，以下先取得本機 IP 位址：

ip addr show eth0 | grep inet

可以看到本機的 IP 是 172.19.149.141：

inet 172.19.149.141/20 brd 172.19.159.255 scope global eth0
inet6 fe80::215:5dff:fe40:a05c/64 scope link

透過 curl 可以測試是否可連線：

curl http://localhost:11434/
Ollama is running

curl http://172.19.149.141:11434/
curl: (7) Failed to connect to 172.19.149.141 port 11434 after 0 ms: Couldn't connect to server

接著先把 ollama 停掉：

pkill ollama

如果只是要短暫接受非本機連線，也可以直些設定環境變數，例如：

OLLAMA_HOST=0.0.0.0 ollama serve &

現在不論是本機或是非本機的 IP 都可以正常連線了：

curl http://localhost:11434/
Ollama is running

curl http://172.19.149.141:11434/
Ollama is running

如果希望每次啟動 ollama 都會接收非本機的連線，就可以在 .bashrc、.profile 等 shell 的設定檔中加入：

export OLLAMA_HOST=0.0.0.0

也可以達到一樣的效果，重新啟動 ollama 後，我從 Windows 連過去測試：

(Invoke-WebRequest -Uri "http://172.19.149.141:11434/").Content
Ollama is running

現在就通行無阻了。

Linux 下使用 systemctl 啟動的服務

如果是以 systemctl 啟動服務，必須到對應的 service 檔中設定環境變數，你可以在 /etc/systemd/system 或是 /usr/lib/systemd/system 下找到 ollama.service 檔：

cat /etc/systemd/system/ollama.service

底下是我自己的範例，請在 [Service] 區段中找到 Environment 項目，以 "key=value" 的格式加入環境變數，我在這裡加入了 "OLLAMA_HOST=0.0.0.0:11434" 讓 ollama 會監聽所有的 IP。：

連接埠 11434 是預設值，可以省略。

[Unit]
Description=Ollama Service
After=network-online.target

[Service]
ExecStart=/usr/local/bin/ollama serve
User=ollama
Group=ollama
Restart=always
RestartSec=3
Environment="PATH=<安裝時使用者的 PATH 路徑設定>" "OLLAMA_HOST=0.0.0.0:11434"

[Install]
WantedBy=default.target

你也可以把 Environment 項目分成多行撰寫：

Environment="PATH=<安裝時使用者的 PATH 路徑設定>" 
Environment="OLLAMA_HOST=0.0.0.0:11434"

注意：在 Linux 中，重新安裝是更新 Ollama 的唯一方法，但是重新安裝會蓋掉上述服務設定檔，所以請記得更新版本後，要重新修改設定檔，否則就無法從遠端連入使用 Ollama 了。

修改完存檔後必須重新啟動服務才會生效，重新啟動前：

sudo apt install net-tools
sudo netstat -anp | grep ollama

會看到只監聽 128.0.0.1 這個 IP 位址：

tcp        0      0 127.0.0.1:11434         0.0.0.0:*               LISTEN      120/ollama          
unix  3      [ ]         STREAM     CONNECTED     1342     120/ollama

接著重新啟動：

sudo systemctl daemon-reload
sudo systemctl restart ollama

確認是否有生效：

sudo netstat -anp | grep ollama

輸出如下，現在監聽的是 :::11434，沒有限定只有本機迴路的 IP 了：

tcp6       0      0 :::11434                :::*                    LISTEN      1092/ollama

現在除了以 localhost 或是 127.0.0.1 連接 ollama 外，也可以使用本機對外的 IP 位址：

ip addr show eth0 | grep inet

可看到像是如下的輸出：

inet 172.19.149.141/20 brd 172.19.159.255 scope global eth0
inet6 fe80::215:5dff:fead:ec41/64 scope link

即可使用該 IP 測試：

curl http://172.19.149.141:11434/

看到以下訊息就表示成功：

Ollama is running

你也可以到 Windows 的 PowerShell 測試了：

Invoke-WebRequest -Uri "http://172.19.149.141:11434/" | Select-Object -ExpandProperty Content

一樣可以取得同樣的結果：

Ollama is running

macOS

注意：Ollama 目前在使用者介面上已經有 Expose OLLAMA to the network 選項可以切換是否要讓外部連入，不用撰寫服務設定檔了。

Mac 下比較特別：首先，在 .zshrc 等 shell 相關設定檔中設定的環境變數只對 shell 有效，但是 ollama 在 Mac 上是在使用者登入後透過帳戶的登入項目與延伸功能的設定啟動 ollama 桌面程式（也就是你在工作列看到的小圖示），並且在 ollama 桌面程式的資源檔中設定執行 ollama serve 指令啟動 ollama 服務，因此在 shell 的設定檔中所設定的環境變數完全不會生效。

為了讓 ollama 服務啟動時可以依據環境變數接受非本機連線，我們必須改成使用 launchd 機制啟動 ollama 服務。首先，必須在 ~/Library/LaunchAgents/ 建立一個com.ollama.serve.plist 服務描述檔：

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.ollama.serve</string>
    <key>ProgramArguments</key>
    <array>
        <string>/Applications/Ollama.app/Contents/Resources/ollama</string>
        <string>serve</string>
    </array>
    <key>EnvironmentVariables</key>
    <dict>
        <key>OLLAMA_HOST</key>
        <string>0.0.0.0:11434</string>
    </dict>
    <key>RunAtLoad</key>
    <true/>
    <key>KeepAlive</key>
    <true/>
</dict>
</plist>

其中：

Label 鍵：此服務的名稱。
ProgramArgs 鍵：此服務要執行的指令。
EnvironmentVariables 鍵：要提供給此服務執行時的環境變數

這個服務會在此帳號的使用者登入時啟動，要讓這個服務生效，必須先把已經在執行的 ollama 服務關閉：

killall ollama

然後使用 launchctl 指令載入剛剛寫好的設定：

launchctl load ~/Library/LaunchAgents/com.ollama.serve.plist

載入後，就可以測試看看，先取得 IP：

ipconfig getifaddr en0
192.168.0.37

再利用 curl 工具測試：

curl http://192.168.0.37:11434
Ollama is running

確認可以正常運作之後，還有最重要的一步，移除原本 ollama 桌面程式在登入後自動執行並啟動 ollama 服務的設定，否則 launchd 啟動服務時會因為已經有在監聽本機迴路的 ollama 而失敗：

移除 ollama 項目後，之後重新開機登入此帳號，就會自動啟動剛剛設定的服務了。

之後若是有修改服務的設定檔，就要先從系統中卸載之前載入的設定檔：

launchctl unload ~/Library/LaunchAgents/com.ollama.serve.plist

再重新載入設定檔即可。

使用 ollama 指令連接遠端的 ollama 服務

只要設定 OLLAMA_HOST 環境變數為遠端 ollama 服務的位址，就可以連接遠端 ollama 服務，例如：

ollama list

沒有設定 OLLAMA_HOST 時，這是本機上 ollama 安裝的模型：

NAME                                                   ID              SIZE      MODIFIED    
weitsung50110/llama-3-taiwan:8b-instruct-dpo-q4_K_M    7fcf06fa5eaa    4.9 GB    5 days ago     
weitsung50110/multilingual-e5-large-instruct:f16       ad6d1b04ec00    1.1 GB    2 weeks ago    
gemma3:latest                                          a2af6cc3eb7f    3.3 GB    2 weeks ago

我們可以先設定環境變數（以下以 Linux 示範），再重新執行同樣的指令：

OLLAMA_HOST=192.168.0.37 ollama list

現在看到的則是我在 192.168.0.37 位址的 ollama 安裝的模型：

NAME                                                   ID              SIZE      MODIFIED       
gemma3:4b                                              a2af6cc3eb7f    3.3 GB    38 minutes ago    
weitsung50110/multilingual-e5-large-instruct:f16       ad6d1b04ec00    1.1 GB    3 hours ago       
weitsung50110/llama-3-taiwan:8b-instruct-dpo-q4_K_M    7fcf06fa5eaa    4.9 GB    3 hours ago       
gemma3:12b                                             f4031aab637d    8.1 GB    24 hours ago      
gemma3:1b                                              8648f39daa8f    815 MB    24 hours ago      
Darrrrr/mymodel:latest                                 40a13e3b82e2    815 MB    12 days ago       
deepseek-r1:14b                                        ea35dfe18182    9.0 GB    12 days ago       
qwq:latest                                             009cb3f08d74    19 GB     2 weeks ago       
gemma3:27b                                             a418f5838eaf    17 GB     2 weeks ago       
deepseek-r1:70b                                        0c1615a8ca32    42 GB     2 weeks ago       
deepseek-r1:32b                                        38056bbcbb2d    19 GB     2 weeks ago

這樣一來，你就可以彈性的配置實際要跑 ollama 模型的機器，其他的機器則只要透過遠端連線就可以使用同一組模型了。如果需要，你也可以直接在系統或是 shell 的設定檔中設定環境變數，就不需要每次執行都要先設定環境變數了。

使用 API 連接遠端的 ollama

從遠端利用 API 使用 ollama：只要透過 API 位址的參數指定遠端 IP 即可，本例遠端 ollama 服務位於 192.168.0.37：

curl http://192.168.0.37:11434/api/chat -d '{
>   "model": "gemma3:4b",
>   "messages": [
>     {
>       "role": "user",
>       "content": "你好"
>     }
>   ],
>   "stream": false
> }'

可以取得正確結果：

{"model":"gemma3:4b","created_at":"2025-04-30T09:48:53.946791Z","message":{"role":"assistant","content":"你好！很高兴和你聊天。有什么我可以帮助你的吗？\n"},"done_reason":"stop","done":true,"total_duration":361840209,"load_duration":57624667,"prompt_eval_count":10,"prompt_eval_duration":79502667,"eval_count":15,"eval_duration":224293500}

使用 ollama 套件則是指定 host 參數：

import asyncio
from ollama import AsyncClient

async def main():
    client = AsyncClient(host='http://192.168.0.37:11434')
    response = await client.chat(
        model='gemma3:4b',
        messages=[{'role': 'user', 'content': '你是誰?'}]
    )
    print('回應:', response['message']['content'])

asyncio.run(main())

若要使用 OpenAI API，必須傳入遠端 ollama 伺服器的位址連同連接埠（預設為 11434）給 base_url 參數：

from openai import OpenAI

# 配置遠端 Ollama API
OLLAMA_API_URL = "http://192.168.0.37:11434/v1"  # 遠端 Ollama 伺服器
# OLLAMA_API_URL = "http://127.0.0.1:11434/v1"  # 本機 Ollama 伺服器
MODEL_NAME = "gemma3:12b"

# 初始化 OpenAI 客戶端，指向 Ollama 的 API
client = OpenAI(
    base_url=OLLAMA_API_URL,
)

# 發送聊天完成請求
response = client.chat.completions.create(
    model=MODEL_NAME,
    messages=[
        {
            "role": "user", 
            "content": "你好"
        }
    ],
)
# 提取回應內容
print(response.choices[0].message.content)

讓 Claude Code 串接 Ollama 使用本地端模型

codemee — Mon, 19 Jan 2026 06:43:34 +0000

Ollama v0.14.0 後提供了與 Anthropic API 的相容性，這使得原本串接 Antropic API 的程式碼可以只接改用 Ollama 上的本地或雲端模型，同時也讓 Claude Code 可以改用 Ollama 上的本地或地端模型。

要讓 Claude Code 接上 Ollama，只要設定以下兩個環境變數：

export ANTHROPIC_AUTH_TOKEN=ollama
export ANTHROPIC_BASE_URL=http://<你的 Ollama 伺服器網址>:11434

Windows 請改成：

$env:ANTHROPIC_AUTH_TOKEN="ollama"
$env:export ANTHROPIC_BASE_URL="http://<你的 Ollama 伺服器網址>:11434"

如果要使用的是同一機器上的 Ollama 伺服器，伺服器網址寫 "localhost" 或是 "127.0.0.1" 都可以。如果是要使用其他台機上的 Ollama 伺服器，記得依照這篇遠端使用 ollama 的方法，讓 Ollama 伺服器可以接受遠端連線。

以我自己的環境為例，Ollama 伺服器位於區網上的 192.168.0.150，安裝的模型如下：

➜ ollama list
NAME                 ID              SIZE      MODIFIED
gemma3:27b           a418f5838eaf    17 GB     3 weeks ago
gemma3:12b-it-qat    5d4fa005e7bb    8.9 GB    2 months ago
gpt-oss:120b         a951a23b46a1    65 GB     2 months ago

就可以如下執行 Claude Code：

➜ claude --model gpt-oss:120b

實際測試如下：

> 你好

● 你好！有什么我可以帮助你的吗？

✻ Crunched for 56s

> 你現在使用哪一種模型？

● 我目前使用的是 gpt-oss:120b 模型。

以下則是 /model 的輸出：

 Select model
 Switch between Claude models. Applies to this session and future Claude Code sessions. For other/previous model
 names, specify with --model.

   1. Default (recommended)  Use the default model (currently Sonnet 4.5) · $3/$15 per Mtok
   2. Opus                   Opus 4.5 · Most capable for complex work · $5/$25 per Mtok
   3. Haiku                  Haiku 4.5 · Fastest for quick answers · $1/$5 per Mtok
 > 4. gpt-oss:120b √         Custom model

 Enter to confirm · escape to exit

除了本機端的模型，你也可以使用 Ollama 雲端的模型，例如以下先拉取所需的雲端模型資訊：

➜ ollama pull minimax-m2.1:cloud
pulling manifest 
pulling 692f7c2439cc: 100% ▕█████████████████████████████████████████████████████████▏  378 B                         
verifying sha256 digest 
writing manifest 
success

然後讓 Ollama 伺服器登入你的帳號以便取用雲端模型：

➜ ollama signin
You need to be signed in to Ollama to run Cloud models.

To sign in, navigate to:
    https://ollama.com/connect?name=ubuntu&key=c3NoLWVk...3NlYno

完成後即可使用剛剛拉取下來的雲端模型：

➜ claude --model minimax-m2.1:cloud

實測結果如下：

> 你好

✽ Beboppin'… (ctrl+c to interrupt)

● 你好！有什麼我可以幫你的嗎？

> 你使用哪一種模型？

● 我使用的是 minimax-m2.1:cloud 模型

Claude Code MCPSearch 工具

codemee — Sat, 17 Jan 2026 04:28:16 +0000

Claude Code 在 2.1.7 版時改成預設啟用 MCPSearch 工具，它會在你的 MCP 工具資訊佔用的 token 數達到 context window 的 10%（預設值） 時干預 MCP 工具的使用方式，最主要有兩個效應：

延後把 MCP 工具的資訊加入 contex 的時間：只有在模型判斷目前資訊無法完成任務時，才會使用 MCPSearch 工具搜尋是否有適當的 MCP 工具可用，這時才會根據 MCPSearch 工具的搜尋結果載入 MCP 工具的資訊。優點就是在不需要使用 MCP 工具的情況下，不論你連接了多少個 MCP 伺服器，都完全不佔用 contex window。
只會提供所需工具的資訊，不會把所屬 MCP 伺服器的所有工具的資訊都加入 context。也就是說，如果某個 MCP 伺服器提供有 10 個工具，但只需要用到其中一項工具時，就只會提供給模型該項工具的資訊參考，不會把 10 個工具的資訊都放入 context 中，無端佔用額外的 contex window。

有興趣可以參考 Claude 中相對應的 Tool Search 工具的說明。

以 Notion MCP 伺服器實測

你很容易就可以發現為什麼要預設啟用 MCPSearch 工具，以 Notion 官方的 MCP 伺服器為例，即使我的 Claude Code 只連接了這一個 MCP 伺服器：

➜ claude mcp list
Checking MCP server health...

notion: https://mcp.notion.com/mcp (HTTP) - ✓ Connected

當你以 /context 查看時：

 Context Usage
⛁ ⛀ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁   claude-opus-4-5-20251101 · 41k/200k tokens (21%)
⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁   ⛁ System prompt: 3.0k tokens (1.5%)
⛀ ⛀ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶   ⛁ System tools: 17.0k tokens (8.5%)
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶   ⛁ MCP tools: 21.1k tokens (10.6%)
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶   ⛁ Messages: 8 tokens (0.0%)
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶   ⛶ Free space: 114k (56.9%)
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶   ⛝ Autocompact buffer: 45.0k tokens (22.5%)
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛝ ⛝ ⛝
⛝ ⛝ ⛝ ⛝ ⛝ ⛝ ⛝ ⛝ ⛝ ⛝
⛝ ⛝ ⛝ ⛝ ⛝ ⛝ ⛝ ⛝ ⛝ ⛝

MCP tools · /mcp
└ mcp__notion__notion-search: 1.5k tokens
└ mcp__notion__notion-fetch: 304 tokens
└ mcp__notion__notion-create-pages: 2.0k tokens
└ mcp__notion__notion-update-page: 2.0k tokens
└ mcp__notion__notion-move-pages: 611 tokens
└ mcp__notion__notion-duplicate-page: 220 tokens
└ mcp__notion__notion-create-database: 5.8k tokens
└ mcp__notion__notion-update-database: 6.0k tokens
└ mcp__notion__notion-create-comment: 1.6k tokens
└ mcp__notion__notion-get-comments: 108 tokens
└ mcp__notion__notion-get-teams: 229 tokens
└ mcp__notion__notion-get-users: 452 tokens
└ mcp__notion__notion-get-self: 79 tokens
└ mcp__notion__notion-get-user: 120 tokens

會發現光是 Notion 提供的 MCP 工具就有 14 個，總共耗用 21.1k 個 token，比所有系統（內建）工具的 17.0k 還多。當然，這樣的好處是模型可參考所有工具的資訊，直接挑選適當的使用，例如：

> 我有哪些跟提案相關的筆記？

● notion - notion-search (MCP)(query: "提案", query_type: "internal")

───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
 Tool use

   notion - notion-search(query: "提案", query_type: "internal") (MCP)
   Perform a search over:
...（略）
 Do you want to proceed?
 > 1. Yes
   2. Yes, and don't ask again for notion - notion-search commands in C:\Users\meebo\code\tt
   3. No

 Esc to cancel · Tab to add additional instruction

你可以看到模型根據問題，馬上找出可以使用 Notion 提供的搜尋工具協助處理，但壞處就是如果提問內容根本不需要 MCP 工具的協助，還是得佔用這 21.1k 個 token 的空間，白白燒掉 token 額度。

我們沒有要真的測試 Notion 的工具效果，所以這裡先中斷離開 Claude Code。

使用 MCPSearch 工具

接著來看看如果啟用 MCPSearch 工具，會有什麼差別？要特別注意的是，雖然官方文件說預設會啟用 MCPSearch 工具，不過我自己的測試環境中，是已經升級到 2.1.11 的版本，但並不會自動啟用 MCPSearch 工具：

➜ claude --version
2.1.11 (Claude Code)

在 Claude Code 的 Github issue 頁面中，找到其他人類似的問題，提供了繞路的解法，設定環境變數 ENABLE_TOOL_SEARCH 為 true 就可以強制啟用 MCPSearch 工具，底下是我在 Windows 的 PowerShell 下測試：

➜ $env:ENABLE_TOOL_SEARCH="true"; claude

如果使用 macOS/Linux，就改用：

ENABLE_TOOL_SEARCH=true claude

如果覺得麻煩，也可以在 .claude/settings.json 檔中加入環境變數的設定：

{
  "env": {
    "ENABLE_TOOL_SEARCH": "true"
  }
}

執行後一樣使用 /context 觀察目前的 contex 用量：

 Context Usage
⛁ ⛀ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁   claude-opus-4-5-20251101 · 20k/200k tokens (10%)
⛀ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶   ⛁ System prompt: 3.1k tokens (1.5%)
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶   ⛁ System tools: 17.0k tokens (8.5%)
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶   ⛁ Messages: 8 tokens (0.0%)
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶   ⛶ Free space: 135k (67.5%)
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶   ⛝ Autocompact buffer: 45.0k tokens (22.5%)
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛝ ⛝ ⛝
⛝ ⛝ ⛝ ⛝ ⛝ ⛝ ⛝ ⛝ ⛝ ⛝
⛝ ⛝ ⛝ ⛝ ⛝ ⛝ ⛝ ⛝ ⛝ ⛝

MCP tools · /mcp (loaded on-demand)

Available
└ mcp__notion__notion-search
└ mcp__notion__notion-fetch
└ mcp__notion__notion-create-pages
└ mcp__notion__notion-update-page
└ mcp__notion__notion-move-pages
└ mcp__notion__notion-duplicate-page
└ mcp__notion__notion-create-database
└ mcp__notion__notion-update-database
└ mcp__notion__notion-create-comment
└ mcp__notion__notion-get-comments
└ mcp__notion__notion-get-teams
└ mcp__notion__notion-get-users
└ mcp__notion__notion-get-self
└ mcp__notion__notion-get-user

你可以看到兩個主要的差異：

在上方的分類 token 用量統計中，原本佔用 21.1k 個 token 的 MCP tools 不見了，總用量也從原本看到的 41k 驟降成 20k，少掉的就是 MCP Tools 的 21.1k。
在底下標示 MCP tools 的區域，出現了 "（loaded on-emand）" 字樣，表示現在是依據需要才會載入 MCP 工具的資訊到 context 中。

很顯然 MCPSearch 生效了，不確定會需要使用 MCP 工具時，就不會把 MCP 工具放入 context 中。接著就來驗證看看：

> 我有哪些跟提案相關的筆記？

● 讓我搜尋你的 Notion 筆記中與提案相關的內容。

● MCPSearch(Search MCP tools: "select:mcp__notion__notion-search")
  ⎿  Found 1 tool

● notion - notion-search (MCP)(query: "提案", query_type: "internal")

───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
 Tool use

   notion - notion-search(query: "提案", query_type: "internal") (MCP)
...（略）
 Do you want to proceed?
 > 1. Yes
   2. Yes, and don't ask again for notion - notion-search commands in C:\Users\meebo\code\tt
   3. No

 Esc to cancel · Tab to add additional instructions

我們問了同樣的問題，你會看到最終模型還是會使用 Notion 伺服器提供的搜尋工具，但是過程不大一樣：

模型先使用了 MCPSearch 工具，它的執行結果是 ""select:mcp_notion_notion-search")"，告訴模型可以選用 Notion 的搜尋工具。
接著模型依據 MCPSeach 工具的搜尋結果使用 Notion 的搜尋工具。

事情還不只如此，即使現在使用到了 Notion 伺服器提供的工具，如果中斷剛剛的交談，再使用 /context 查看用量：

 Context Usage
⛁ ⛀ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁   claude-opus-4-5-20251101 · 22k/200k tokens (11%)
⛁ ⛀ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶   ⛁ System prompt: 3.0k tokens (1.5%)
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶   ⛁ System tools: 17.0k tokens (8.5%)
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶   ⛁ MCP tools: 1.5k tokens (0.8%)
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶   ⛁ Messages: 685 tokens (0.3%)
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶   ⛶ Free space: 133k (66.4%)
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶   ⛝ Autocompact buffer: 45.0k tokens (22.5%)
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛝ ⛝ ⛝
⛝ ⛝ ⛝ ⛝ ⛝ ⛝ ⛝ ⛝ ⛝ ⛝
⛝ ⛝ ⛝ ⛝ ⛝ ⛝ ⛝ ⛝ ⛝ ⛝

MCP tools · /mcp (loaded on-demand)

Loaded
└ mcp__notion__notion-search: 1.5k tokens

Available
└ mcp__notion__notion-fetch
└ mcp__notion__notion-create-pages
└ mcp__notion__notion-update-page
└ mcp__notion__notion-move-pages
└ mcp__notion__notion-duplicate-page
└ mcp__notion__notion-create-database
└ mcp__notion__notion-update-database
└ mcp__notion__notion-create-comment
└ mcp__notion__notion-get-comments
└ mcp__notion__notion-get-teams
└ mcp__notion__notion-get-users
└ mcp__notion__notion-get-self
└ mcp__notion__notion-get-user

你會看到兩個不同的地方：

上方分類統計用量的地方出現了 MCP tools，但是總量是 1.5k，不是最前面看到的 21.1k，表示並不是所有 Notion 提供的工具資訊都放入了 context。
在下方標示 MCP tools 的地方，會看到多了 Loaded 區塊，這裡只列出了 mcp__notion__notion-search，佔用 1.5k 個 token。

正因為如此，所以雖然用到了 MCP 工具，但是 context 總量也還是只有 22k 而已，不會激增到最前面看到的 41k。

MCPSearch 工具的代價

MCPSearch 工具的基本概念很簡單，它想做到的就是像 Agent Skills 那樣，只有在需要的時候才提供完整資訊。如果 MCP 工具使用到的機率不高，廣度也不大，也就是不會一下要用 A 工具、一下要用 B 工具，一下又要用 C 工具，那麼沒有用到 MCP 工具時所省下的 token 量，應該可以讓你節省很多額度，代價則是在新的交談階段初次使用到特定的 MCP 工具前，都會先使用一次 MCPSearch 工具，多進行一次交談。

從上面的測試也可以看到，就算只連接了一個 MCP 伺服器，但如果提供的工具繁多，或是該工具比較複雜，那麼相關的資訊量也是可以多到你嚇一跳的。單單一個 Notion 伺服器提供的工具就佔了 21.1k 個 token，整個 context window 也才 200k，10%↑ 的量就不見了，是很有感的差異，更別說你可能連接了不只一個 MCP 伺服器。

當然，如果你就只會連接佔用量很少的 MCP 伺服器，整體用量可能比多一輪問答使用 MCPSearch 工具的 token 量（這會包含交談記錄、系統訊息、系統工具）少很多，或者使用到 MCP 工具的機率非常頻繁，那就可以權衡是否要啟用 MCPSearch 工具。

VScode 的自動執行機制--Tasks

codemee — Mon, 12 Jan 2026 04:13:37 +0000

由於看到一篇科技詐騙的文章，才知道 VSCode 開啟資料夾時問的『是否信任此資料夾』原來很重要。這個詐騙成功的關鍵首先是 VSCode 執行任務的機制，原始的目的是方便大家設計好可以建置環境、編譯、測試專案的指令，不需要自己再去終端機敲長串的指令，但要命的是這個機制可以設定成 VSCode 開啟資料夾時就自動執行，對於從像是 GutHub 複製下來的專案，增添了極高的風險。

自動執行任務的機制

VSCode 可以在 .vscode 下放置 tasks.json，格式如下：

{
    // See https://go.microsoft.com/fwlink/?LinkId=733558
    // for the documentation about the tasks.json format
    "version": "2.0.0",
    "tasks": [
        {
            "label": "play",
            "type": "shell",
            "command": "uv run main.py",
            "runOptions": {
                "runOn": "folderOpen"
            }
        }
    ]
}

其中：

type 項目可以搭配一些開發環境設定，執行特定的開發工具。若設定為 "shell"，就可以自由執行任何指令。
runOptions 則可以用來設定執行選項，像是 runOn 就可以設定為 "folderOpen"，只要用 VSCode 開啟該資料夾就會自動執行，這就可以用來執行自動清除快取之類的任務。

不過因為可以自動執行，所以如果埋了一個惡意程式，就可能會傷害你的電腦，甚至暗中安裝常駐的惡意程式之類。

這個自動執行機制還可以透過 presentation 屬性設定得更隱密：

{
    // See https://go.microsoft.com/fwlink/?LinkId=733558
    // for the documentation about the tasks.json format
    "version": "2.0.0",
    "tasks": [
        {
            "label": "play",
            "type": "shell",
            "command": "uv run main.py",
            "runOptions": {
                "runOn": "folderOpen"
            },
            "presentation": {
                "reveal": "never",
                "revealProblems": "never",
                "close": true
            }
        }
    ]
}

其中：

reveal：控制是否要顯示執行任務的終端機面板。
revealProblem：則是控制執行有問題時，是否要顯示問題面板。
close：控制執行完任務後是否要關閉終端機。

只要設定都不顯示面板，而且執行後關閉終端機，除非程式本身開啟額外的視窗、或非常佔用資源等等，否則就很難發現它的蹤跡。

避免自動執行任務的危險

要避免上述問題，最簡單的方式就是每次開啟新的資料夾時，都不要信任該資料夾。如果已經信任過資料夾，也可以按 Ctrl+Shift+C開啟命令選擇區後執行 manage workspace trust 命令進入設定頁面，再按不信任，

如果是因為父資料夾受信任而自動信任子資料夾，就要到父資料夾中設定。或者也可以在同一設定頁面下的信任的資料夾與工作區中，從清單中移除已被信任的資料夾。

如果需要信任資料夾的好處，不想動到資校夾或工作區的信任設定，也可以修改允許自動執行任務的設定，你可以在工作區的設定檔 .vscode/settings.json 中加上如下的設定：

{
    "task.allowAutomaticTasks": "off"
}

就不會自動執行任務。你也可以加到使用者設定檔中，避免從網路下載 repo 後，一時忘記就直接開啟，釀成大禍。之後若真的需要執行特定的任務，可以到命令選擇區中執行 Run Task 命令，選擇要執行的任務即可。

要注意的是，像是 Cursor 這個延伸自 VSCode 的編輯器，預設是不啟用信任機制的，也就是完全信任所有的資料夾，不可不小心。

PowerShell pipeline chain operator 的小陷阱

codemee — Fri, 12 Dec 2025 01:38:08 +0000

PowerShell 7 提供有pipeline chain operator，也就是 && 與 ||，不過使用上必須注意，不然就會遇到意外的結果。

運算子的兩端都要是指令

看到 && 與 ||，很容易就會寫出類似這樣的指令：

➜ cd \temp && exit

不過這會得到以下錯誤訊息：

exit: The term 'exit' is not recognized as a name of a cmdlet, function, script file, or executable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

這是因為 && 與 || 的左右兩邊都要是指令（包含 cmdlet、函式、腳本檔、外部程式等），但 exit 是 PowerShell 的保留字，在語法上是陳述句，並不是指令，所以你可以看到錯誤訊息明確表示無法執行 exit。

沒有 pipeline 的功能

這組運算子名稱中的 "pipeline" 也很容易誤解，以為他們是有條件的 pipeline，例如，你可能會期望以下指令可以在 \temp 資料夾存在的情況下，將資料夾內的檔案清單傳給右邊的 measure-object：

➜ test-path \temp
True
➜ ls \temp && Measure-Object

但其實並不會，你會看到類似以下的結果：

    Directory: C:\temp

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
d----         2025/12/9 下午 04:23                F6722
d----        2025/12/11 下午 10:49                test_wt
d----        2025/12/11 下午 10:45                tmr
-a---         2025/5/22 下午 10:50            162 tomica.jpg
-a---         2025/3/18 下午 04:55         521370 train1.jpeg
-a---         2025/3/18 下午 04:55         879688 train2.jpeg
-a---         2025/8/29 下午 11:56       10824402 VVAICar_Test.apk

Count             : 0
Average           : 
Sum               : 
Maximum           : 
Minimum           : 
StandardDeviation : 
Property          :

也就是 pipeline chain operator 只會串接指令，但不會傳送輸出結果，如果命名為 chain operator 好像比較適當。

遠端使用 ollama 的方法

codemee — Fri, 01 Aug 2025 05:42:48 +0000

ollama 除了可以在本機使用外，也可以從遠端連接，不過預設 ollama 只接受本機的連線，無法從遠端連接。

設定可接受遠端連線

Window 環境

在安裝完 ollama 後，你可以利用以下指令查看目前 ollama 監聽的 IP：

netstat -ano | findstr ":11434"

輸出如下，可以看到目前只監聽本機迴路的 IP：

  TCP    127.0.0.1:3923         127.0.0.1:11434        TIME_WAIT       0
  TCP    127.0.0.1:11434        0.0.0.0:0              LISTENING       21544

也可以透過測試連線來確認，首先取得本機的 IP 位址：

Get-NetIPAddress | Select-Object IPAddress, InterfaceAlias, AddressFamily | Where-Object {$_.AddressFamily -eq 'IPv4'}

IPAddress      InterfaceAlias                     AddressFamily
---------      --------------                     -------------
172.19.144.1   vEthernet (WSL (Hyper-V firewall))          IPv4
169.254.130.47 區域連線* 3                                 IPv4
169.254.236.94 區域連線* 2                                 IPv4
169.254.221.5  藍牙網路連線                                IPv4
192.168.0.71   Wi-Fi                                       IPv4
127.0.0.1      Loopback Pseudo-Interface 1                 IPv4

利用 curl 連線本機迴路測試：

curl http://127.0.0.1:11434/

可正常運作：

Ollama is running

但如果利用 Wi-Fi IP 連線：

curl http://192.168.0.71:11434/

就會無法連線：

curl: (7) Failed to connect to 192.168.0.71 port 11434 after 2032 ms: Could not connect to server

為了讓 ollama 可以接受本機迴路以外的連線，你可以在使用者或是系統環境變數加入 OLLAMA_HOST：

重新登入或是重新啟動後即可確認環境變數：

$env:OLLAMA_HOST 
0.0.0.0:11434

再透過指令確認目前監聽的狀況：

netstat -ano | findstr ":11434"

輸出如下：

  TCP    0.0.0.0:11434          0.0.0.0:0              LISTENING       11832
  TCP    [::]:11434             [::]:0                 LISTENING       11832

即可看到監聽了所有的 IP，如果用 curl 測試：

curl http://192.168.0.71:11434/
Ollama is running

會看到可以正常連線。

Linux/MacOS 下手動啟動

如果你沒有把 ollama 安裝成自動啟動的服務，就只要在使用者自己的 .bashrc 或是 .zshrc、.profile 檔中繪出環境變數即可，以下先取得本機 IP 位址：

ip addr show eth0 | grep inet

可以看到本機的 IP 是 172.19.149.141：

inet 172.19.149.141/20 brd 172.19.159.255 scope global eth0
inet6 fe80::215:5dff:fe40:a05c/64 scope link

透過 curl 可以測試是否可連線：

curl http://localhost:11434/
Ollama is running

curl http://172.19.149.141:11434/
curl: (7) Failed to connect to 172.19.149.141 port 11434 after 0 ms: Couldn't connect to server

接著先把 ollama 停掉：

pkill ollama

如果只是要短暫接受非本機連線，也可以直些設定環境變數，例如：

OLLAMA_HOST=0.0.0.0 ollama serve &

現在不論是本機或是非本機的 IP 都可以正常連線了：

curl http://localhost:11434/
Ollama is running

curl http://172.19.149.141:11434/
Ollama is running

如果希望每次啟動 ollama 都會接收非本機的連線，就可以在 .bashrc、.profile 等 shell 的設定檔中加入：

export OLLAMA_HOST=0.0.0.0

也可以達到一樣的效果，重新啟動 ollama 後，我從 Windows 連過去測試：

(Invoke-WebRequest -Uri "http://172.19.149.141:11434/").Content
Ollama is running

現在就通行無阻了。

Linux 下使用 systemctl 啟動的服務

如果是以 systemctl 啟動服務，必須到對應的 service 檔中設定環境變數，你可以在 /etc/systemd/system 或是 /usr/lib/systemd/system 下找到 ollama.service 檔：

cat /etc/systemd/system/ollama.service

底下是我我自己的範例，請在 [Service] 區段中找到 Environment 項目，以 "key=value" 的格式加入環境變數，我在這裡加入了 "OLLAMA_HOST=0.0.0.0:11434" 讓 ollama 會監聽所有的 IP。：

[Unit]
Description=Ollama Service
After=network-online.target

[Service]
ExecStart=/usr/local/bin/ollama serve
User=ollama
Group=ollama
Restart=always
RestartSec=3
Environment="PATH=/home/meebox/.local/bin:/home/meebox/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/lib/wsl/lib:/mnt/c/users/meebo/scoop/apps/vscode/current/bin" "OLLAMA_HOST=0.0.0.0:11434"

[Install]
WantedBy=default.target

修改完存檔後必須重新啟動服務才會生效，重新啟動前：

sudo apt install net-tools
sudo netstat -anp | grep ollama

會看到只監聽 128.0.0.1 這個 IP 位址：

tcp        0      0 127.0.0.1:11434         0.0.0.0:*               LISTEN      120/ollama          
unix  3      [ ]         STREAM     CONNECTED     1342     120/ollama

接著重新啟動：

sudo systemctl daemon-reload

確認是否有生效：

sudo netstat -anp | grep ollama

輸出如下，現在監聽的是 :::11434，沒有限定只有本機迴路的 IP 了：

tcp6       0      0 :::11434                :::*                    LISTEN      1092/ollama

現在除了以 localhost 或是 127.0.0.1 連接 ollama 外，也可以使用本機對外的 IP 位址：

ip addr show eth0 | grep inet

可看到像是如下的輸出：

inet 172.19.149.141/20 brd 172.19.159.255 scope global eth0
inet6 fe80::215:5dff:fead:ec41/64 scope link

即可使用該 IP 測試：

curl http://172.19.149.141:11434/

看到以下訊息就表示成功：

Ollama is running

你也可以到 Windows 的 PowerShell 測試了：

Invoke-WebRequest -Uri "http://172.19.149.141:11434/" | Select-Object -ExpandProperty Content

一樣可以取得同樣的結果：

Ollama is running

MacOS

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.ollama.serve</string>
    <key>ProgramArguments</key>
    <array>
        <string>/Applications/Ollama.app/Contents/Resources/ollama</string>
        <string>serve</string>
    </array>
    <key>EnvironmentVariables</key>
    <dict>
        <key>OLLAMA_HOST</key>
        <string>0.0.0.0:11434</string>
    </dict>
    <key>RunAtLoad</key>
    <true/>
    <key>KeepAlive</key>
    <true/>
</dict>
</plist>

其中：

Label 鍵：此服務的名稱。
ProgramArgs 鍵：此服務要執行的指令。
EnvironmentVariables 鍵：要提供給此服務執行時的環境變數

這個服務會在此帳號的使用者登入時啟動，要讓這個服務生效，必須先把已經在執行的 ollama 服務關閉：

killall ollama

然後使用 launchctl 指令載入剛剛寫好的設定：

launchctl load ~/Library/LaunchAgents/com.ollama.serve.plist

載入後，就可以測試看看，先取得 IP：

ipconfig getifaddr en0
192.168.0.37

再利用 curl 工具測試：

curl http://192.168.0.37:11434
Ollama is running

確認可以正常運作之後，還有最重要的一步，移除原本 ollama 桌面程式在登入後自動執行並啟動 ollama 服務的定，否則 launchd 啟動服務時會因為已經有在監聽本機迴路的 ollama 而失敗：

移除 ollama 項目後，之後重新開機登入此帳號，就會自動啟動剛剛設定的服務了。

之後若是有修改服務的設定檔，就要先從系統中卸載之前載入的設定檔：

launchctl unload ~/Library/LaunchAgents/com.ollama.serve.plist

再重新載入設定檔即可。

使用 ollama 指令連接遠端的 ollama 服務

只要設定 OLLAMA_HOST 環境變數為遠端 ollama 服務的位址，就可以連接遠端 ollama 服務，例如：

ollama list

沒有設定 OLLAMA_HOST 時，這是本機上 ollama 安裝的模型：

NAME                                                   ID              SIZE      MODIFIED    
weitsung50110/llama-3-taiwan:8b-instruct-dpo-q4_K_M    7fcf06fa5eaa    4.9 GB    5 days ago     
weitsung50110/multilingual-e5-large-instruct:f16       ad6d1b04ec00    1.1 GB    2 weeks ago    
gemma3:latest                                          a2af6cc3eb7f    3.3 GB    2 weeks ago

我們可以先設定環境變數（以下以 Linux 示範），再重新執行同樣的指令：

OLLAMA_HOST=192.168.0.37 ollama list

現在看到的則是我在 192.168.0.37 位址的 ollama 安裝的模型：

NAME                                                   ID              SIZE      MODIFIED       
gemma3:4b                                              a2af6cc3eb7f    3.3 GB    38 minutes ago    
weitsung50110/multilingual-e5-large-instruct:f16       ad6d1b04ec00    1.1 GB    3 hours ago       
weitsung50110/llama-3-taiwan:8b-instruct-dpo-q4_K_M    7fcf06fa5eaa    4.9 GB    3 hours ago       
gemma3:12b                                             f4031aab637d    8.1 GB    24 hours ago      
gemma3:1b                                              8648f39daa8f    815 MB    24 hours ago      
Darrrrr/mymodel:latest                                 40a13e3b82e2    815 MB    12 days ago       
deepseek-r1:14b                                        ea35dfe18182    9.0 GB    12 days ago       
qwq:latest                                             009cb3f08d74    19 GB     2 weeks ago       
gemma3:27b                                             a418f5838eaf    17 GB     2 weeks ago       
deepseek-r1:70b                                        0c1615a8ca32    42 GB     2 weeks ago       
deepseek-r1:32b                                        38056bbcbb2d    19 GB     2 weeks ago

使用 API 連接遠端的 ollama

從遠端利用 API 使用 ollama：只要透過 API 位址的參數指定遠端 IP 即可，本例遠端 ollama 服務位於 192.168.0.37：

curl http://192.168.0.37:11434/api/chat -d '{
>   "model": "gemma3:4b",
>   "messages": [
>     {
>       "role": "user",
>       "content": "你好"
>     }
>   ],
>   "stream": false
> }'

可以取得正確結果：

{"model":"gemma3:4b","created_at":"2025-04-30T09:48:53.946791Z","message":{"role":"assistant","content":"你好！很高兴和你聊天。有什么我可以帮助你的吗？\n"},"done_reason":"stop","done":true,"total_duration":361840209,"load_duration":57624667,"prompt_eval_count":10,"prompt_eval_duration":79502667,"eval_count":15,"eval_duration":224293500}

使用 ollama 套件則是指定 host 參數：

import asyncio
from ollama import AsyncClient

async def main():
    client = AsyncClient(host='http://192.168.0.37:11434')
    response = await client.chat(
        model='gemma3:4b',
        messages=[{'role': 'user', 'content': '你是誰?'}]
    )
    print('回應:', response['message']['content'])

asyncio.run(main())

若要使用 OpenAI API，必須傳入遠端 ollama 伺服器的位址連同連接埠（預設為 11434）給 base_url 參數：

from openai import OpenAI

# 配置遠端 Ollama API
OLLAMA_API_URL = "http://192.168.0.37:11434/v1"  # 遠端 Ollama 伺服器
# OLLAMA_API_URL = "http://127.0.0.1:11434/v1"  # 本機 Ollama 伺服器
MODEL_NAME = "gemma3:12b"

# 初始化 OpenAI 客戶端，指向 Ollama 的 API
client = OpenAI(
    base_url=OLLAMA_API_URL,
)

# 發送聊天完成請求
response = client.chat.completions.create(
    model=MODEL_NAME,
    messages=[
        {
            "role": "user", 
            "content": "你好"
        }
    ],
)
# 提取回應內容
print(response.choices[0].message.content)

用 Inkscape 批次幫 SVG 檔文字轉外框

codemee — Wed, 30 Jul 2025 09:55:24 +0000

我的工作會遇到需要把 SVG 檔內含的文字轉外框，這可以透過開放原始碼的 Inkscape 處理，而且 Inkscape 還提供 CLI 介面，可以像是透過 Selenium 或是 Playwright 操控瀏覽器那樣自動化。於是我就請 Grok 幫我設計腳本，讓我可以批次處理一堆 SVG 檔轉外框在存檔的功能，以下是透過指令把 SVG 轉外框的批次檔：

@echo off
REM batch_text_to_path.bat
for %%f in (*.svg) do (
    echo Processing %%f...
    "C:\Program Files\Inkscape\bin\inkscape.exe" --actions="select-all;org.inkscape.text.convert_to_path;export-filename:%%~nf_converted.svg;export-do" "%%f"
)

它會把目前資料夾下的所有 SVG 檔用 Inkscape 一一開啟，開啟後：

選取所有物件
文字轉外框
以原檔名加上 "_converted" 字尾存檔

也有 bash 版：

#!/bin/bash
# batch_text_to_path.sh
for file in *.svg; do
    echo "Processing $file..."
    inkscape --actions="select-all;org.inkscape.text.convert_to_path;export-filename:${file%.svg}_converted.svg;export-do" "$file"
done

或是 PowerShell 版：

# batch_text_to_path.ps1
$inkscapePath = "C:\Program Files\Inkscape\bin\inkscape.exe" # 根據你的 Inkscape 安裝路徑調整
$svgFiles = Get-ChildItem -Filter *.svg

foreach ($file in $svgFiles) {
    Write-Host "Processing $($file.Name)..."
    & $inkscapePath --actions="select-all;org.inkscape.text.convert_to_path;export-filename:$($file.BaseName)_converted.svg;export-do" $file.FullName
    Write-Host "Saved as $($file.BaseName)_converted.svg"
}

如果想知道有哪些動作可以透過 CLI 完成，可以執行 --action-list：

c:\Program` Files\Inkscape\bin\inkscape --action-list

DEV Community: codemee

Codex 的 Subagents 數量上限

誠品線上庫存查詢工具 — 技術報告

1. 問題背景

2. 核心技術問題與解法

2.1 Cloudflare TLS 指紋偵測導致 403

2.2 API 要求動態時間戳參數

2.3 商品 GUID 的容錯擷取

2.4 持續監控（--watch）與狀態顯示

2.5 多目標查詢與錯誤隔離

2.6 Windows 終端機中文編碼相容性

2.7 PEP 723 獨立腳本（零安裝執行）

3. 架構小結

Tkinter 快顯功能表關閉殘影調查報告

1. 摘要

2. 原始展示範例

3. 平台行為與根因

4. 修正歷程

4.1 直接銷毀主視窗

4.2 unpost()、釋放 grab，再用 after_idle() 關閉

4.3 延遲 100 ms 後關閉

4.4 callback 只設定旗標

4.5 使用 menu.unpost() 或 tk::MenuUnpost

4.6 使用 Windows EndMenu()

5. 目前完整展示範例

6. 修正版事件順序

7. 驗證方式

7.1 語法檢查

7.2 手動視覺測試

7.3 驗收狀態

8. 限制與後續考量

Gemini 模型的 tokenizer

Vertex AI Studio

透過 Vertex AI API 取得切割結果

Colab 中在背景執行程式的方法

直接開終端機下指令

使用 ! 執行指令

使用 nohup 協助轉向

遠端使用 ollama 的方法

設定可接受遠端連線

Window 環境

Linux/MacOS 下手動啟動

Linux 下使用 systemctl 啟動的服務

macOS

使用 ollama 指令連接遠端的 ollama 服務

使用 API 連接遠端的 ollama

讓 Claude Code 串接 Ollama 使用本地端模型

Claude Code MCPSearch 工具

以 Notion MCP 伺服器實測

使用 MCPSearch 工具

MCPSearch 工具的代價

VScode 的自動執行機制--Tasks

自動執行任務的機制

避免自動執行任務的危險

PowerShell pipeline chain operator 的小陷阱

運算子的兩端都要是指令

沒有 pipeline 的功能

遠端使用 ollama 的方法

設定可接受遠端連線

Window 環境

Linux/MacOS 下手動啟動

Linux 下使用 systemctl 啟動的服務

MacOS

使用 ollama 指令連接遠端的 ollama 服務

使用 API 連接遠端的 ollama

用 Inkscape 批次幫 SVG 檔文字轉外框

4.2 `unpost()`、釋放 grab，再用 `after_idle()` 關閉

4.5 使用 `menu.unpost()` 或 `tk::MenuUnpost`

4.6 使用 Windows `EndMenu()`

使用 `!` 執行指令

使用 `nohup` 協助轉向