Otari AI 管治：Mozilla AI 將模型選擇與代理限制整合至單一閘道

Mozilla AI 於 11 月 4 日概述其 Otari AI 管治方案，將模型選擇與對代理工具及開支的限制並列處理。該公司形容 Otari 是一個用於管治的作業系統，儘管產品本身是一個開源閘道。閘道位於應用程式與 AI 服務之間，提供統一位置以轉送請求及套用規則。

這項主張旨在處理一項實際矛盾：團隊希望可自由更換模型，卻不必重建圍繞模型的控制措施。Mozilla AI 表示，Otari 結合工作區權限、預算檢查及使用情況可見度。這對每個應用程式各自維護供應商連接及保護措施的做法構成壓力。

Otari 進入的是一個已建立的類別，LiteLLM 等替代方案已提供集中式存取及開支控制。當代理既可選擇下一項行動，也可選擇下一項付費請求時，關鍵問題在於權限應由何處掌握。

Otari AI 管治將模型選擇與權限結合

Mozilla AI 將模型存取及代理權限視為同一項基礎設施決策的組成部分。

Mozilla AI 在其 AI 管治公告中說明，工作區規則涵蓋可使用的模型、網頁搜尋、程式碼執行及必要檢查。該公司表示，被標記的請求可在到達供應商前遭封鎖。預算會連結至使用者及應用程式金鑰，即應用程式用以存取閘道的憑證。

這些功能確立了產品預期的邊界。開發者可圍繞共同存取點建立應用程式，而管理員則決定這些應用程式可以使用哪些服務。更換模型與賦予代理另一項能力，因而成為彼此相關的決策。

這項區別很重要，因為模型的回答與代理的權限帶來不同責任。錯誤的草稿可能需要編輯；錯誤的行動則可能在任何人審閱結果前，已修改紀錄、洩露資料或啟動額外工作。

共享閘道讓組織可在與模型的對話以外表達限制。這改變了誰作出最終存取決定。應用程式可以請求某項能力，但基礎設施可以拒絕該請求。

設想一個假設性的客戶支援助手，使用獲批准的文件來擬寫回覆。其獲指派的工作並不自動證明可存取不受限制的瀏覽器或執行環境是合理的。即使這些能力可改善其在無關任務上的表現，仍需要各自的理據。

這個例子也揭示了關於自主性的討論中常見的模糊之處。為代理提供更多有用資訊，與允許它採取更多行動，是兩回事。產品可透過更好的文件變得更有幫助，卻毋須獲得修改客戶紀錄的權限。

因此，對於詢問 Otari 是甚麼的讀者而言，有用的答案在於其架構。它是一個協調各個 AI 應用程式存取決策的位置，而 Mozilla AI 將管治與供應商選擇一併定位。

作業系統的說法仍然只是一個比喻。買家應將其理解為一項關於協調的主張，而非 Otari 管理組織所有 AI 活動的證據。資料存取、應用程式行為及業務審批，仍需要有明確的負責人。

11 月的公告最適宜理解為一項產品方向聲明。它說明 Mozilla AI 希望團隊控制甚麼，以及那些控制措施應設於何處。它並未證實安全性、可靠性或營運成本已有獨立量度的改善。

實際改變，是應用程式團隊與平台擁有人之間出現更明確的契約。開發者透過介面請求存取；管理員界定其獲准範圍。這份契約是否有效，取決於應用程式實際採用的路徑。

平台團隊承擔代理無法自行作出的決策

集中存取令責任更清晰，但仍須有人界定每個工作流程應獲得甚麼權限。

最直接的壓力落在平台工程師、安全團隊及應用程式擁有人身上。他們必須把「負責任地使用 AI」這種廣泛指示，轉化為有關憑證、允許服務、開支及審閱的決策。

Mozilla AI 早前的 代理基礎設施論點區分了指示與約束。書面規則告訴代理應如何行事；強制限制則決定它實際上能做甚麼。

當工作流程處理外部人士提供的材料時，這項區別便會帶來實際後果。提示注入是指內容嘗試重新導向模型行為，而不只是提供資訊。因此，支援工單、擷取到的文件或網頁，都可能成為不必要指示的來源。

基礎設施限制不要求模型辨識每一段惡意內容。若工作流程沒有使用特定能力的權限，即使模型判斷失誤，這個邊界仍可維持有效。

OWASP 的 過度代理權限指引將過多功能、權限及自主性列為造成破壞性行動的不同原因。其建議包括限制工具、收窄下游權限，以及對具重大後果的操作要求審批。

這是獨立的安全指引，並非對 Otari 的背書。它支持將限制置於模型判斷之外的根本理由，也說明為何閘道應配合更廣泛的權限系統。

設想一個可搜尋公開材料並整理研究結果的研究助手。其擁有人或會合理地批准網頁存取，卻不授予其對外發布結論的權限。尋找資訊與代表組織發言，是不同責任。

中央控制點有助突顯這項差異，但它不會決定組織政策。仍需要有人決定助手可存取哪些資訊、哪些輸出需要審閱，以及由誰處理例外情況。

對知識工作者而言，這直接關乎 個人知識庫與共享組織資源之間的分別。有用的檢索結果並不自動證明可獲得更廣泛存取權或行動權限。

因此，對應用程式擁有人的壓力很具體。他們需要足夠精確地描述工作流程，讓權限能配合其用途。「研究代理」這類標籤，提供的指引不如清楚交代獲批准輸入及允許輸出。

安全團隊亦有相應責任。限制措施應清晰易懂，讓開發者可預測應用程式的行為。無法解釋的拒絕會令排錯更困難，並鼓勵人們請求更廣泛的存取權。

財務及營運團隊也會加入討論，因為代理的選擇可產生重複的付費活動。他們需要可將用量連結至負責任工作流程的歸屬資料。沒有具體擁有人的共享憑證，會削弱這種問責。

Otari AI 管治令這些決策更接近彼此。其組織後果是共同承擔責任：應用程式團隊界定工作，平台團隊執行邊界，業務擁有人決定何種結果值得持續存取。

Otari vs LiteLLM 將焦點放在執行細節

有意義的比較在於控制措施於部署時如何運作，而非產品是否列出預算及模型路由功能。

LiteLLM 是一個有用的參照，因為其文件已說明集中式開支控制。其 預算執行文件涵蓋個人、團隊、團隊成員及代理預算，並指出預算執行取決於已連接的資料庫。

這項條件說明，功能名稱不足以構成完整比較。儀表板可以顯示預算，但底層部署可能沒有執行預算所需的狀態。營運人員需要理解支撐每項控制措施的條件。

因此，Otari vs LiteLLM 的評估應從應用程式的實際請求路徑開始。哪些憑證識別呼叫者？適用哪些限制？會計資料不可用時會發生甚麼？答案比一長串支援的整合列表更重要。

這也是集中式基礎設施與分別嵌入應用程式的保護措施之間的差異所在。分開的實作可反映本地需求，但每項實作都需要維護。共享控制點則創造機會，讓這些應用程式維持一致行為。

當團隊更換供應商或引入另一個工作流程時，這種一致性便有價值。管理員應能理解該改變是否保留既有規則。否則，每次整合都會成為政策逐漸偏離的另一個機會。

Mozilla AI 表示，Otari 提供一個通用應用程式介面，即 API，讓應用程式透過它接達模型。該公司亦描述了當供應商不可用時重新路由請求的後備規則。

後備安排可維持可用性，同時改變任務的其他特性。替代模型可能以不同方式遵循指示、產生不同回答格式，或需要額外審閱。因此，維持服務不同於維持等效行為。

這正是為何更換供應商仍應是一項經測試的營運決策。介面可減少整合工作，卻不能免除評估輸出品質的需要。應用程式仍取決於模型如何理解其指示及使用可用工具。

同樣的推理亦適用於開放權重模型，其模型參數可按適用條款使用。僅能存取這些參數，本身並不提供應用程式預期的周邊服務。

Mozilla AI 的 開放模型基礎設施討論，將搜尋及程式碼執行等工具視為缺失的周邊層一部分。其論點是，當應用程式保留對這些能力的存取權時，模型選擇會變得更實際。

對買家而言，含意是應在等效條件下比較已完成的工作。一個快速產生看似合理答案的模型，仍可能需要大量核對；另一個模型則可能以較少修正完成相同工作。

這些差異影響供應商可攜性的價值。當組織亦可判斷替代方案是否符合要求時，輕易路由才最有意義。沒有這種評估，切換能力大致仍只屬理論。

因此，Otari vs LiteLLM 是部署比較，而非宣告勝方。評估應由允許的工作流程及其失效條件共同決定。無論文件或功能清單，都不能證實哪一項產品會在特定環境中表現更佳。

預算控制取決於請求所採取的路徑

開支限額的效力，取決於其會計規則、涵蓋範圍，以及在並發請求下的行為。

Otari 的預算安全說明提供了一些值得與公告一併留意的限定條件。其中描述了針對按 token 計價及圖像請求的並發成本預留機制。Token 是模型在處理、理解或生成文字時所使用的單位。

預留機制會在工作派送前計入估算成本。當請求同時到達時，這一點尤其重要：每項請求都不應假設自己可動用同一筆剩餘額度。

安全說明亦將這些預留機制，與追溯匯入、批次作業及目前未設預留的固定價格路徑區分開來。文件沒有將這些路徑描述為嚴格的即時上限。因此，這項承諾的適用範圍相當重要。

這並不代表預算控制沒有幫助，而是意味其運作邊界本身就是採購決策的一部分。團隊應了解其預定工作負載是採用預留路徑，還是依賴稍後才進行的成本核算。

例如，設想一個假設性的文件處理應用程式，以批次方式提交工作。即使它與互動式助理顯示在同一個開支儀表板上，其營運者亦不應假設兩者的行為相同。

關鍵在於系統何時承諾執行工作。若成本核算發生在該承諾之後，顯示的餘額所承擔的作用，便與請求發出前的限制不同。兩者都可支援財務管理，但回答的是不同問題。

模型定價是另一項依賴因素。Otari 的安全政策表示，系統預設要求提供定價資訊，並會根據文件所述規則拒絕未定價模型的請求。這是具體的保障措施，可避免將未知成本視為零成本。

不過，營運者可以變更設定，而同一份說明亦列明例外情況。部署評估應檢視實際生效的設定及端點，而非基於預設值作出假設。

更廣泛的教訓是，成本控制屬於請求處理的一部分。它取決於身分、定價資訊、核算狀態，以及批准執行工作的時機。單靠報告無法建立所有這些條件。

人工審核引入了另一條界線。代理即使仍在開支額度內，也可能產生無法使用的輸出。預算限制的是風險暴露，並不能判定工作是否值得該筆支出。

這項區別應塑造內部報告方式。應用程式擁有人需要將使用量與已獲接納的結果、修正工作及放棄的嘗試連結起來。否則，即使工作流程只是完成了較少有用的工作，較低消耗量看來仍可能像是成功。

團隊比較模型時，同樣應作出這種審視。若較便宜的請求導致反覆重試或大量清理工作，整個流程仍可能十分昂貴。真正相關的價值單位，是已完成的任務。

Otari AI governance 為團隊提供了一個可協調這些決策的建議位置，但其安全文件為對「控制」的廣泛解讀加上了限制。採購方在撰寫需求時應保留這些限定條件。

負責任的評估會在獲授權的環境中，同時測試一般請求及邊界條件。結果應確立何者會被停止、何時停止，以及哪些活動仍不受嚴格上限所限。

這類證據會比僅僅聲稱存在預算功能更有用。它能將產品文件所述的機制，與機構實際面對的財務風險連結起來。

追蹤功能帶來可見性與保留內容之間的取捨

團隊需要分辨：看見發生過甚麼，與保留代理所讀取或產生的一切內容，並不是同一回事。

工作階段追蹤會將活動連結成時間線，讓營運者可調查工作流程如何推進。Mozilla AI 的公告描述了一種不儲存提示、回應或工具結果的追蹤方式。這是其所述可見性方案的重要部分。

不過，專案的發佈紀錄補充了一項限定條件。日期為 11 月 4 日的 0.38.0 版本，列出支援保留明確要求保留內容的已路由請求內容。

這些說法不應被合併解讀為對儲存作出的無條件承諾。公告描述的是盡量減少內容保留的做法，而發佈說明則顯示可選擇啟用內容保留功能。因此，部署選擇值得關注。

對營運者而言，這些模式支援不同的調查工作。時間線可協助找出失敗的請求或路由變更；要重建某個答案為何包含特定錯誤，則可能需要掌握所涉及材料的資訊。

這造成實際的張力。保留較少內容可減少為除錯而收集的敏感材料；保留較多內容則可令某些事故更容易理解。沒有任何一種偏好能滿足所有營運需要。

假設一個處理內部研究資料的助理，這種取捨便十分具體。其活動紀錄可能顯示哪個服務處理了請求，以及請求是否失敗；要理解一份具誤導性的摘要，亦可能需要查閱原始段落。

機構應決定這些調查材料應存放於何處。它們可能已存在於應用程式自身的紀錄中，並受獨立的存取限制規管。在另一個系統中複製它們，便會增加另一個需要治理的位置。

因此，關於追蹤的聲稱不能取代機構層面的資料保留政策。應用程式、模型服務、搜尋服務及執行工具，在工作流程中可處於不同位置。

Gateway 的設定與這幅圖景有關，但它並不描述每一個其他元件。團隊在就資訊傳輸或留存位置作出保證前，應先繪製所涉及的服務。

營運可見性與輸出問責之間亦有差異。追蹤紀錄可確立某項行動曾經發生；要判斷該行動是否恰當，仍須參考工作流程的目的及其管治規則。

調查事故的審核人員，應能將活動連結到相關應用程式及負責擁有人。否則，即使時間線十分詳細，仍可能難以理解。

相同原則亦適用於被阻止的行動。若獲授權的營運者能理解是哪一項規則導致拒絕，拒絕便更有用。這有助進行修正，而無須自動擴大代理的權限。

開源特性提供了檢視實作選擇的機會，但並不能證明每個已部署實例均使用相同設定，或保留相同資訊。

對採購方而言，結論很具體：詢問啟用了哪一種追蹤模式、誰可變更它，以及誰可查閱產生的紀錄。這些答案可將一般的私隱聲稱轉化為營運承諾。

選擇應配合工作流程的敏感度及調查需要。公共研究助理與處理機密文件的助理，未必需要保留相同證據，亦能支援負責任的運作。

接下來要留意甚麼：執行證據、可攜性與採用情況

當使用者能將 Otari 的控制措施與真實工作流程中可觀察的行為連結起來時，其進展便會最為清晰。

未來數月首個值得留意的訊號，是可重現的執行證據。有用的報告會顯示某個具名部署如何處理遭拒的工具、已耗盡的預算及並發請求，並應識別版本及相關設定。

這會透過將已記錄的控制措施與觀察到的結果連結起來，強化 Mozilla AI 的主張。即使最終結果聽來令人鼓舞，若報告略去請求路徑或設定，所提供的信心仍會較低。

最具資訊價值的例子，會同時包括嘗試跨越界線的情況及正常運作。成功的答案證明實用性；恰當地被拒絕的請求，則證明某項限制在測試條件下確實成立。

第二個訊號，是在同等約束下的供應商可攜性。團隊應尋找此類比較：應用程式保持相同任務、獲允許工具及審核標準，同時更換背後的模型。

這可顯示更容易的路由是否真正轉化為實際選擇。若切換仍需要大幅修復工作流程，整合效益依然存在，但會比作業系統的比喻所暗示的範圍更窄。

輸出質素仍應是評估的一部分。若供應商變更保留了介面，卻增加修正工作，便會在其他地方產生額外工作。當機構可以接受由此產生的行為時，可攜性才具價值。

第三個訊號，是具明確營運責任的持續採用。相關案例應說明誰維護 gateway、審核政策變更、調查故障，以及決定某個代理是否值得獲得更廣泛存取權限。

這些細節可顯示集中管治是減少重複工作，還是僅僅將工作轉移到別處。一份具說服力的部署案例，應在說明效益的同時承認維護工作及例外情況。

這亦是開源方法可被檢驗之處。機構可以檢視軟件並選擇自行營運，但必須有人負責更新、設定及事故應對。

穩定責任歸屬的證據，會強化將 gateway 視為共享機構基建的理由。不論功能覆蓋多廣，若部署只能透過未記錄的介入才能運作，便會削弱這一理由。

這些訊號令討論立足於 Mozilla AI 所描述的事件。Otari 提出了一套連貫方案，以協調模型存取、代理權限及開支。其長遠價值取決於這些部分如何共同運作。

該公司的管治框架在促使人們提出精確問題時最有用。助理可請求哪些行動？基建可拒絕哪些行動？系統可在工作開始前限制哪些成本？

評估 Otari AI governance 的團隊，應從一個他們已理解其目的及可接受輸出的工作流程開始。這會令故障更容易辨識，改善亦更容易評估。在檢視權限、開支行為及出錯後可取得的證據時，應保持任務穩定。

在擴大存取權限前，要求應用程式擁有人說明新增能力可帶來甚麼，以及誰承擔其使用責任。要求平台擁有人展示該項權限在何處被執行。然後比較另一個模型能否在這些界線下完成相同工作。當代理犯錯時，哪些決定仍然可以被強制執行？