要用 Sakana Fugu 比對兩個已登入的網站，請在本機 Agent 使用 fugu 路由，並讓它執行 Tabbit CLI。提供穩定記錄 ID，要求它在兩個獲准存取的網站中查找相同記錄，輸出附雙方來源連結的比較表。兩個網站都保持唯讀，任何差異都留在具名草稿中，交由人處理。
一位 Reddit 使用者分享，自己在程式任務中試用後更偏好標準 Fugu，而不是結果不一、速度較慢且費用較高的 Ultra。這是個人經驗，不是基準測試；但說明了可以先用基礎路由處理範圍清楚的查找，再判斷結果是否足夠。原始討論。
重點
Sakana 基礎 API 模型是
fugu，與有版本號的 Ultra 端點不同。模型端點不會攜帶網站登入狀態。本機客戶端必須在已有登入的瀏覽器設定檔執行 Tabbit CLI。
使用工單、訂單或案件編號等穩定 ID，不要只靠姓名。
對帳表應設為唯讀，每個系統附一個來源連結，並標示「待審閱」。
人工檢查雙方記錄並同意前，不要更新任何系統。
確認 Fugu 路由和本機瀏覽器路徑
| 檢查 | 確認事項 | 安全下一步 |
|---|---|---|
| 模型路由 | 客戶端或服務商提供 Sakana fugu | 先送出無敏感內容的短請求，確認所選路由 |
| Tabbit CLI 技能 | 本機客戶端已載入技能說明 | 依客戶端文件使用技能選單；Pi 使用 /skill:tabbit |
| 瀏覽器設定檔 | 兩個網站都登入正確帳號 | 委派前親自開啟網站確認 |
| 記錄鍵 | 兩邊都有相同且唯一的 ID | 若有多筆或不同 ID，停止並請人確認 |
Sakana 的官方 API 文件介紹 fugu 路由及 API。它會在支援的模型池中路由，但模型可用性和本機瀏覽器權限是兩項不同檢查。請以客戶端目前的模型清單為準；Models.dev Sakana 目錄只能協助發現模型，不保證帳號有權使用。Tabbit CLI 可在本機已登入設定檔中操作網頁，但 Fugu API 本身不能直接讀取頁面。參考Tabbit CLI 指南和連接既有瀏覽器。
用穩定 ID 比對兩個系統
選擇你有權查看的記錄。第一次最好用測試工單或訂單，而非客戶資料。只提供穩定 ID 和完成比較所需的欄位，要求 Agent 依照兩邊頁面上的可見資訊，不要自行猜測欄位含義。
| 比較欄位 | 系統 A | 系統 B | 審閱規則 |
|---|---|---|---|
| 穩定記錄 ID | 頁面上的 ID 與記錄 URL | 頁面上的 ID 與記錄 URL | ID 不同或有多筆匹配就停止 |
| 狀態 | 可見狀態文字 | 可見狀態文字 | 保留原文並標記差異 |
| 更新時間 | 顯示時間與時區 | 顯示時間與時區 | 不要抹去時區差異 |
| 金額或數量 | 數值與單位 | 數值與單位 | 只比對意義相同的欄位 |
相似姓名不能證明記錄相同。欄位未顯示時，應寫「頁面未顯示」並附連結。首個瀏覽器任務檢查表說明如何限制第一項任務範圍；Agent 瀏覽器基礎也說明為何要先採唯讀操作。
開兩個任務分頁並保留登入
開啟兩個網站前，先用已安裝的啟動器執行 tabbit-cli diagnose，確認本機控制器正在執行。這只檢查 CLI 是否可連線；模型選擇、技能載入和網站登入仍須分別確認。
使用一個已在兩個網站登入的 Tabbit 設定檔。Agent 應為每個網站各開一個獨立任務分頁，讓你可以繼續使用原有分頁。讀取欄位前先確認網站和精確 ID。
先親自確認兩個登入有效，再啟動本機 Fugu 客戶端並確認選取 fugu。從客戶端文件所列的技能選單載入 Tabbit CLI 技能。Pi 使用 /skill:tabbit，其他客戶端可能使用 /skills。讓 CLI 在系統 A 和 B 各開一個任務分頁；若網站要求重新登入或出現非預期頁面就停下。第一輪只讀取，不要授予寫入權限。
本機測試夾具中，受保護頁面在設定短期測試 Cookie 前回傳 401；第二個具名任務重用測試會話後讀到頁面。這只證明測試環境可沿用登入會話，沒有呼叫 Fugu、登入真實客戶網站或驗證外部模型整合。選擇接入方式可參考MCP 與 CLI及Codex Tabbit 設定。
要求建立對帳草稿，不要更新記錄
使用 Sakana Fugu 模型 fugu，比對我指定的兩個獲准網站中的記錄 ID TEST-4821。從本機 Agent 執行 Tabbit CLI，每個網站開一個獨立任務分頁。只讀取精確 ID 的記錄。建立名為「Fugu 記錄對帳」的草稿，欄位包括：欄位、系統 A 的值和 URL、系統 B 的值和 URL、匹配狀態、審閱備註。保留畫面顯示的原文和時間。若 ID 不存在、重複或不同，停止並標示「待審閱」。不要編輯、提交、批准或傳送任何資料。任何下一步前先展示草稿給我。TEST-4821 是示意用測試 ID，不是真實記錄，請替換成你有權查看的值。草稿應附雙方直接連結、原始欄位值和清楚的差異標記。一位 API 使用者在早期比較中分別記錄提示詞、Token 用量和延遲；這能幫助評估模型選擇，卻不能證明它能準確處理你的業務記錄。查看第一手 API 試用。
判斷基礎 Fugu 是否足夠
若 fugu 可用，記錄範圍清楚且易於閱讀，可以先用基礎路由。它可能經由持續變化的模型池處理任務，因此每次結果取決於當時服務和任務內容。只有在工作需要原版 Ultra，或自己的測試證明更深入推理有幫助時，才改用固定版 Ultra。不要把模型差異和瀏覽器登入能力混為一談。
若兩筆資料需要登入，而且本機瀏覽器已有登入狀態，Tabbit 才有用。公開資料也許只需搜尋工具；私有記錄則需要本機瀏覽器提供頁面內容，差異如何處理仍由人決定。先用一筆測試記錄產出可審閱的草稿。
Tabbit CLI 指南 · 連接既有瀏覽器 · 首個瀏覽器任務 · MCP 或 CLI · 搜尋或瀏覽器控制 · Agent 瀏覽器基礎 · Codex 設定 · Playwright MCP 設定
常見問題
標準 Sakana Fugu 的模型 ID 是什麼？
Sakana API 使用 fugu 作為基礎路由。它會在支援的模型池中路由，因此開始前請確認客戶端和服務商有提供。
Fugu 能比對兩個已登入的網站嗎？
Fugu 本身不提供瀏覽器登入狀態。請使用能呼叫 Fugu 並在已登入設定檔中執行 Tabbit CLI 的本機 Agent。
為何要用穩定記錄 ID？
不同系統的名稱和日期可能不同。共同 ID 可提供明確的查詢鍵，也讓差異更容易核對。
應該讓 Agent 更新任一系統嗎？
不要。先用唯讀權限建立含雙方記錄連結的對帳草稿，再由人確認差異並決定是否更新。
可以用遠端 Agent 完成嗎？
只有客戶端支援本機 Tabbit 瀏覽器接力時才可以。否則請在擁有登入設定檔的電腦執行 Agent。