Sakana Aquarium 企業代理平台發表，資料定義與核准接進流程

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

2026 年 10 月 23 日（日本時間），東京的 Sakana AI 發表企業 AI 代理平台 Aquarium。這場發表沒有新模型：主角是一層把組織資料的共用定義、代理工作流程與權限治理裝進同一個平台的基礎建設，代理從查資料、下判斷到執行動作，中間可以卡一道人工核准，事後留下從判斷依據到執行結果的紀錄。發布文只出了日文版，導入採諮詢制，沒有公開價格，也沒有開放試用。

一間以模型研究聞名的公司先賣基礎層，理由官方自己講了：每個企業導入案都在重做同樣的底層整理，把資料接起來、把用語與判斷標準說清楚，做完一案換下一案又從頭來。Aquarium 想把這段工作變成組織裡可以重複使用的資產。

沒有新模型的發表會，主角是組織知識的共用層

Aquarium 的核心叫 Ontology（知識本體）。白話說，就是把組織判斷事情會用到的知識、規則與資料，連同各自的意義、彼此的關係，整理成一套大家共用的定義。拿一個入門的例子想：兩份表格都寫著供應商，一份記的是公司主體，一份記的是聯絡人，名稱看起來相近，不代表它們能互相替代。AI 讀得到兩份表，跟 AI 知道哪個欄位指哪家公司、更新時該對到誰，是兩回事。

規則也有同樣的問題。一份文件說明哪些行動可以採取，另一份文件定義哪些狀況必須先核准，代理兩份都讀得到，跟它在執行前把規則接到正確的對象上，也是兩個層次的工作。把這些定義放到共用層，而不是藏在某個代理的一次性提示詞裡，第二個代理來的時候才有現成的關係可用，這是 Ontology 在平台裡的實際位置。集中管理也有它的代價：多個代理都依同一組供應商關係做判斷時，組織一旦調整定義，跟著變動的流程範圍就必須一起盤點，這是共用層換來的重用效率背後，必然新增的管理工作。

發布文把平台拆成三個機制：Ontology 負責把知識、規則與資料體系化；Governance 負責設定存取權限與行動放行前的把關，並記錄判斷依據與執行結果；Managed Agents 則讓代理在這套定義上執行任務，把資訊參照、AI 判斷、函式執行與人工核准寫成工作流程就能部署，並管理代理的整個生命週期。產品頁另外列了第四層 Data，發布文只列三個機制，兩份文件的口徑有落差。

Pin

平台名稱的比喻也出自發布文：許多魚在同一個整理好的水槽裡游，所以叫水族館。魚是各個代理，水槽是整理好的組織知識環境。官方強調，整理好的資料與 Ontology 可以直接拿給別的代理使用，所以第二個、第三個代理不必重學同一套資料。這句是平台最核心的價值宣稱，屬於官方說法，實際重用成效要等導入案例公布才檢驗得了。

資料要搬家嗎：原地連接，更新會跟著反映

產品頁把資料接法稱為 Connect in place（原地連接）：表格、Office 文件、既有資料庫，從原本的儲存位置接上共用定義，不必為了導入代理先把資料搬進另一套系統。對已經有多年資料資產的企業，這一點決定導入是新建工程還是接線工程，也是評估此類平台時最該先問的問題之一。

光接上還不夠，資料會持續變動。第二個特性 Stay Updated 處理這件事：連接來源的資訊更新時，內容會反映到 Ontology，代理依更新後的狀況做判斷，而不是拿上個月的庫存或名單回答今天的問題。對判斷結果要對他人負責的單位，判斷依據的時效本身就踩在說明責任上，這層設計的分量比看起來重。

邊界官方也寫得明白：既有資料平台與 Ontology 之間怎麼連接、怎麼同步，依導入對象個別設計。原地連接講的是資料位置不動，資料的意義與對應關係仍然要逐一定義，同一個供應商在不同系統裡的對應方式還是得先說清楚，平台才知道更新該對到哪個對象。通用連接器清單、同步延遲或服務保證，這次都沒有公布。換句話說，資料不搬家是真的，整理工作不會因為不搬家就消失。

代理怎麼行動：一條供應商回覆流程，核准卡在中間

產品頁上唯一具體的流程示例，是處理供應商回覆。輸入有兩種：供應商回覆與供應商，從流程圖的標籤看，一個對應收到的文件內容，一個對應組織裡的往來對象，兩者並列且標成不同的資料類型，代理的分析才連得上正確的企業主體，而不是對著一大段混合文字自己猜角色。流程分三步：讀取回覆把資料交出來，代理分析產生判斷，人工核准決定能不能往執行走，畫面在這一步標示等待批准。整條流程用 YAML 描述，那是一種用文字表達設定的格式，寫成文字的好處是每一步誰做、做什麼都攤得開，團隊討論時有共同的語言。

Pin

把輸入、判斷、核准拆開，實際意義是企業可以指定哪一段交給 AI、哪一段必須由人決定，核准出現在行動之前，而非事後看報告。等待批准這個狀態放在流程裡，人的參與時點就跟著流程走，這是它與只在最後生成一份摘要的做法最直接的差別。

Governance 層在這裡接手：存取權限決定代理碰得到哪些資訊，核准這道關卡決定哪些動作放行，紀錄從判斷依據一路留到執行結果，執行的速度、準確度與模型使用狀況也看得到。允許讀供應商資料，不等於有權對它執行所有操作，權限與核准是兩道分開的關卡。出問題時，組織才有材料分辨是參照資料錯、規則定義不清，還是代理判斷本身要調；代理出現非預期行為時要能回頭追查，是近期各家都在補的環節，例如 OpenAI 先前把防護搬到代理碰不到的地方的停用監控設計。對需要向稽核或客戶交代判斷過程的單位，這條紀錄鏈是平台最對味的一段。

這條供應商流程是官方示意，畫面上沒有真實採購單或客戶信件，它支持的是工作分工的理解，不能推成某家企業已經用同一套流程全自動處理供應商事務。代理行動前先過人這一關的設計，近期在消費端產品也反覆出現，例如代理寄信付款前先讓使用者放行的更新，兩者把同一個問題放在不同規模上處理。

為什麼是 Sakana 做這個：從每案重做的痛開始

發布文花了相當篇幅交代來歷。這家公司在金融等要求精度與說明責任的領域累積過多個實作：與三菱UFJ銀行做 AI 融資專家、與 SMBC 集團做提案書自動生成、與大和證券集團共同開發。每個案子都由前線部署工程師進場，先理解現場的資料與作業方式，再負責流程設計、評估與精度改善。反覆出現的痛是：資料連接、用語定義與判斷基準的整理，每案都從頭做一次。Aquarium 就是把這些工作抽成組織共用的基礎，導入顧問與工程師的角色也保留在官方的導入說明裡。

三個金融合作必須看清楚位置：發布文把它們放在過往實績的背景段落，沒有任何一家被列為 Aquarium 的客戶。讀相關報導時，把銀行名字直接接在 Aquarium 後面，是最容易出現的轉述錯誤。

開發團隊的組成也寫在發布文裡：Sakana AI 內部負責 AI 實作的團隊，加上曾在 Palantir、Snowflake、Microsoft 與 AWS 等公司打造資料平台、資料治理的成員。這個組合解釋了產品的長相，先治理、後代理，重點放在企業資料的定義與權限，而不是先衝代理的能力上限。想認識這家公司研究側的思路，可以看讓模型組團互相監督、從工作紀錄改進自己的 MASS 研究，兩條線剛好對照：研究端推能力邊界，產品端打底層地基。

現在能用嗎：只有日文、諮詢制、無公開價格

截至本文撰寫，Aquarium 的導入方式是諮詢制，官方請有興趣的組織帶著想解決的課題與作業條件聯絡，沒有通用價格、沒有公開試用，發布文與產品頁都只有日文版。企業官網導覽列上，Aquarium 單獨放在 Platform 分類，與 Fugu、Namazu、Marlin、Translate、Chat 這些產品並列但不混在一起，擺位本身說明它賣給組織，不是賣給個人使用者。

受影響的族群因此很明確：一般使用者今天沒有可用的東西，也不需要做任何事；正在評估把內部資料接上代理流程的企業決策者，多了一個把資料定義與治理當成第一公民的參考樣本。從僅日文發布、諮詢制導入這兩點推論，初期對象以日本企業為主，這句是編輯推論，官方文件沒有直說。

未確認的事項也列得出來：價格與計費方式、資料連接器清單、同步機制的具體行為、服務水準保證，以及日本以外市場的供應條件，官方文件都沒有觸及。這些空白不代表產品不存在，只代表現在還無法估算任何組織的導入成本，也無法把平台能力換算成實際工作量。企業若要把 Aquarium 排進評估清單，目前能做的第一件事是帶著一條具體作業去問，而不是先比較規格表。

之後怎麼追蹤：等活用事例再評估不遲

發布文給了三個後續方向：把運作中產生的修正與判斷納回系統，讓 Ontology 與代理跟著組織變化更新；開發讓 AI 協助建立代理的機制；活用事例將陸續公布。對外部觀察者，活用事例是最該等的一份，共用定義能不能真的讓第二個代理省掉重整理，重用宣稱成不成立，都要看到實際案例才有答案。

回查點可以設三個：活用事例公布時檢驗重用成效，價格出現時才能算導入成本，英文版頁面上線時代表市場範圍可能擴大。三個都沒發生前，多數讀者把這則新聞當作企業代理平台重心轉向資料定義與治理層的訊號看待即可。

真的想先做準備的團隊，可以從官方那條供應商回覆流程反推：在組織裡找一條已經有人負責、規則寫得下來的作業，盤點它的輸入有哪些、判斷依據在哪、誰有權核准。這些盤點不管最後用哪個平台都用得上，也是導入這類系統真正花時間的地方。