解放你的 Agent，賦予它們 SSH 存取權限

每個 現代 平台都會提供你的 Agent 三種相同的整合選項：一個要註冊的 MCP 伺服器、一個要儲存並重新整理的 API 金鑰，或是一個要安裝的技能檔案，用來教導 Agent 如何執行前兩項。這些東西都需要 設定、會 外洩、而且會 過期。

Oberik 給你的 Agent 的是 ssh 存取權限。

不是給你，你在這個情境中是作為代理角色，它實際上是把 SSH 存取權限給你的 Agent。

1 ssh ssh.oberik.com

SSH 是程式碼 Agent 在需要與 Oberik 互動時使用的介面（例如： 建立工作區、設定其能力上限、鑄造代幣、與我們託管的 Agent 聊天等）。不需要設定檔、不需要在環境變數中放 token、不需要安裝任何東西。你的機器已經有客戶端程式，而且它已經知道如何處理唯一需要的憑證。

為什麼不用 MCP？

長話短說，問題出在輸出上。

MCP 之所以成為業界預設，是因為它解決了一個實際問題。你寫好一個工具，每個 Agent 都能以相同方式呼叫它。我們並不反對它。Oberik 會將你自己的 MCP 伺服器直接載入到我們託管的 Agent 中，每個租戶各自獨立，這對 Agent 對外連接 工具來說是個好方法。我們這裡要討論的是另一個方向：某個東西 最初是如何 設定 帳戶的。

儘管 MCP 使用起來很方便，但它核心有個缺陷：當工具執行時，整個輸出都會被推入模型的上下文。模型必須讀取所有內容。它無法決定「我只想要第三個欄位」，因為當文字送達時，過濾已經失敗了。

原則上 MCP 支援過濾和分頁。但實際上，必須有人把這些功能建置到每個工具中，而當它缺失時（這在 氛圍程式設計 的風氣下很常見），模型就只能 吞下 原始資料，並為此付出 token 和注意力的代價。

有了 SSH，Agent 可以自行組合它想要的檢視畫面，而不是接受工具塞給它的東西。

1$ ssh ssh.oberik.com 'documents --json' | jq -r '.data[].name'
2$ ssh ssh.oberik.com 'audit --limit 20 --json' | jq -r '.data[] | "\(.at) \(.command)"'

過濾器在機器上的管道中執行。即時、免費、而且範圍完全符合 Agent 的需求。模型讀取一行文字，而不是十頁。

有兩件事讓這得以實現。首先，每個回應都使用單行格式，例如 {"ok":…, "command":…, "message":…, "data":…}。這使得 jq 成為讀取輸出的預期方式，而不是一種變通方法。

JSON 模式也能防止互動中斷你的工作流程。如果某個指令缺少必要欄位，它會告訴你缺少什麼，而不是開啟一個表單。如果某個指令可能具有破壞性，它會要求你加上 --yes 重新執行，而不是停下來要求確認。

對於包含多個指令的一行命令，可以在開頭加上 format json;。這樣可以一次設定好格式，之後就不需要重複加上這個旗標。

有一個細節值得注意。這個旗標必須放在引號內。ssh ssh.oberik.com --json 'documents' 是行不通的，因為 ssh 會將目標位置之後的選項視為自己的參數。它會忽略這個旗標，然後客戶端會回應自己的使用說明輸出。由於這個輸出既沒有提到 Oberik 也沒有提到這個旗標，可能會讓主機看起來像壞掉了。

我們想說的是，我們已經訓練這些模型使用 電腦，那就讓它們使用 電腦 吧。

為什麼不用 API？

長話短說，問題出在憑證上。

別誤會，Oberik 確實有 API，而且它很好用。這是你的產品在正式環境中呼叫的方式，也是 SSH 閘道器在底層呼叫的方式。

但如果你看看它對呼叫者要求了什麼：

1. 取得一個 token
2. 儲存它
3. 重新整理它
4. 讓它遠離日誌檔和模型的上下文。

這每一步都成了 Agent 的責任，而 Agent 的上下文並不是存放秘密的安全地方。任何看過模型回顯自己環境變數的人都知道這一點。我的意思是，如果你仔細觀察，你會發現你最喜歡的程式碼 Agent 在察覺到你的提示中有敏感金鑰時，預設行為就像是 睜一隻眼閉一隻眼。然而，一個貼入 Agent 的金鑰不僅僅是存在於 shell 歷史中；它還會被送到模型供應商、進入日誌、進入任何工具鏈保留的轉錄記錄中。

API 確實存在，但它並不是我們為 Agent 設計的 自我設定 主要路徑。透過 SSH，Agent 持有你的作業系統本來就設計要保護的唯一一種憑證類型：SSH 金鑰，而且私鑰從未傳輸過。向 Oberik 進行身份驗證不會在模型的上下文中放入任何秘密，因為根本沒有東西可以放進去。

為什麼不用 CLI？

長話短說，問題出在過時上。

安裝 CLI 是要求每個整合者的工具鏈做出承諾，而我們不想這麼 大膽，畢竟我們才剛起步。老實說，我們根本不想要 CLI，因為它基本上就是產品的凍結副本。Oberik 的控制平面會隨著我們獲得更多反饋而增加功能，這意味著如果我們當初選擇 CLI，我們就得不斷地推送新版本，並要求使用者更新。

我們基本上解決了這個問題，因為我們的 SSH 介面是動態生成的，而不是手寫的。我們控制平面中的每個路由都會連同其描述一起註冊，而這個描述就是 SSH 指令。新增到儀表板的路由會立即出現在 SSH 上，所以我們不需要擔心閘道器的變更。

沒有東西需要更新，因為沒有東西被安裝。

為什麼不用技能？

長話短說，問題出在指令上。

目前與任何面向 Agent 的產品一起推出的流行方法是 技能。這是一份書面程序，讓你的 Agent 安裝，告訴它如何呼叫產品。技能確實很有用，但它本質上就是一個精美的 README 檔案。技能是文件，而不是能力。它並沒有給你的 Agent 一個行動的方法；它仍然需要底層的 MCP 或 API 來執行任何操作，而你也會繼承那個問題。

除此之外，技能是關於如何使用一個不斷變化的產品的凍結副本。這跟 CLI 有相同的過時問題。它在 Agent 做任何事之前就佔據了上下文，在一個只要詢問介面就能列印出指令的情況下，浪費了注意力和 token。

我們對於「Agent 如何知道 Oberik 能做什麼」這個問題的答案，不是一個讓它安裝的檔案。而是讓 Agent 自己去探索的呼叫：

1$ ssh ssh.oberik.com 'discover'                  # 所有指令、其參數及類型
2$ ssh ssh.oberik.com 'docs'                      # 所有頁面及其涵蓋內容
3$ ssh ssh.oberik.com 'docs search capability'    # 提及特定內容的行

這個介面會在連線時，根據即時產品來描述自己。而 docs 的內容與文件網站上的文字完全相同，所以沒有任何東西是其他東西的摘要。這些指令永遠不會過時，因為 它們就是產品本身。

為什麼是 SSH？

長話短說，它能一次解決所有五個問題。

1. 金鑰是 Agent 真正能夠持有的憑證。 SSH 金鑰認證已有數十年歷史，經過數十億次的實戰考驗，而且協定在我們查看指紋之前就會驗證簽名。我們覺得不需要在這裡重新發明輪子。我們只是不再要求模型去照看一個秘密，而是讓機器去做它天生就被設計來做的那一件事。
2. 無需分享密碼，你也能參與其中。 當 Agent 還沒有金鑰時，例如在它首次連接到 Oberik 時，它會啟動一個裝置登入流程。Agent 執行 login link，這會立即回傳一個 URL 和一個驗證碼，並將兩者顯示給你。你在自己的瀏覽器中打開該 URL。頁面會顯示將要被綁定的確切金鑰指紋，提供你核准或拒絕的選項，並顯示一個你可以與 Agent 列印出的驗證碼進行比對的碼。與此同時，Agent 執行 login wait 並等待你的決定。這兩個指令是刻意分開的。如果一個指令同時產生連結並等待，Agent 只會在請求過期後才顯示連結給你。一旦你核准，金鑰就會被註冊，所有未來的連線都會自動登入。你不需要再使用另一個連結。由於這個過程不使用秘密，因此沒有任何秘密會被寫入 Agent 的聊天記錄中。
3. 輸出專為管道設計。 在指令上使用 --json 請求 JSON 格式，或者在一行開頭使用 format json;，每個回應都會以單行封包的形式回傳。這使得 jq '.data[0].name' 成為讀取輸出的預期方式，而不是一種變通方法。過濾器在機器上執行，所以模型只會看到過濾後剩下的內容。錯誤訊息使用相同的封包格式，並包含底層的 HTTP 狀態碼。這讓重試機制能夠區分 429（請求過多）和 400（錯誤請求）錯誤。管道也可以雙向運作。閘道器無法讀取你的磁碟，所以接受檔案的指令會將檔名作為參數，並從連線中讀取檔案的內容。例如，ssh ssh.oberik.com 'document upload handbook.pdf' < handbook.pdf 會上傳該檔案。
4. 零安裝。 沒有東西需要註冊，沒有東西需要儲存，沒有東西需要保留在上下文中。你的 Agent 設定中沒有 MCP 伺服器，環境變數中沒有 token，PATH 路徑上沒有 CLI，也沒有技能檔案。我們建立的是開發者產品，所以我們使用了已經存在且每個 Agent 都知道如何使用的工具：SSH。
5. 自我描述且設計嚴謹。 discover 會列印完整的指令目錄。它包含所有指令、其參數和類型，以及任何確認要求。這個目錄是從產品即時生成的。它還會告訴客戶端哪些欄位預期接收檔案位元組而不是字串，這樣上傳就不會出錯。它不允許的是根據行號來鎖定目標。具有破壞性的指令需要一個名稱，伺服器會根據連線所選的專案來檢查該名稱。如果在選取「Support Bot」時請求「Staging」，伺服器會回傳 400 錯誤，並且不觸動工作區。

沒有什麼需要教導的，因為這個介面會自我教導。

以下是 Oberik 登入流程的樣子：

Oberik 登入流程

在你的產品上開一個 SSH 入口難道不是風險嗎？

這是個合理的問題，但實際情況幾乎相反。

閘道器本身沒有狀態或權限。每個指令都像在 React 應用程式中一樣，透過 HTTP 控制平面會話執行。因此，SSH 客戶端能做的事情不會超過同一個帳戶在瀏覽器中能做的事情。如果你登出、撤銷金鑰或刪除帳戶，變更會立即生效，因為沒有其他東西需要撤銷。

這個終端機是暴露在公共網際網路上的，所以任何人都可以匿名連線。每個指令都會被記錄，包括連線身份、IP 位址、金鑰和結果。憑證永遠不會被儲存。使用 login 輸入的密碼，或透過 --values 傳遞的提供者金鑰，在寫入記錄之前會被替換為 <redacted>。系統也會儲存原始指令的雜湊值，這樣就可以關聯重複的指令，同時又不會讓憑證可被還原。記錄會保留 30 天或 100,000 個指令，以先到者為準。

重複的失敗登入會變得越來越慢，而不是觸發鎖定。忘記密碼的人可以繼續嘗試而不會遇到太多阻礙，而使用錯誤密碼的自動重試迴圈則會變得越來越沒有效率。這就是我們預期的取捨。

總結

其他人都給你的 Agent 一個 API、一個 MCP 伺服器或一個技能檔案。我們給了它一個終端機。結果發現，這正是它想要的。