深度報告
-
OneCLI 是一個面向 AI Agent 的開源憑證閘道器，由 Y Combinator 2026 夏季批次孵化，在 GitHub 上已獲得超過 2,800 星標。它解決的是 Agent 時代最棘手的安防問題之一：Agent 要呼叫外部 API，但直接交金鑰給 Agent 無異於把保險櫃密碼貼在門上。OneCLI 的解法是在 Agent 和目標服務之間插入一個透明代理閘道器，真實憑證加密儲存於閘道器內，Agent 只持有佔位符令牌，請求發出瞬間才由閘道器完成「假金鑰→真金鑰」的替換。 截至報告撰寫時，專案下載量已超過 32 萬次，並被 NanoClaw 選為預設憑證層。
-
OneCLI 由 Guy Ben Aharon 和 Jonathan Fishner 聯合創立。兩位創始人的背景集中在安全工程領域：Guy 曾是 Argon（後被 Aqua Security 收購）的首位工程師，Jonathan 在 Axis Security（後被 HPE 收購）從事零信任網路訪問工作，均來自以色列軍事情報部門。在此之前，兩人曾共同開發開源資料庫工具 ChartDB（GitHub 20,000+ 星標）。 創立動機來自親身經歷：他們在為 ChartDB 構建 Agent 編排層時，始終找不到一種安全的方式給自主 Agent 分發憑證。團隊調研發現，幾乎所有使用 Agent 的團隊要麼把 API Key 硬編碼到 .env 檔案中，要麼臨時拼湊代理方案。2026 年 7 月，專案正式開源並登上 Hacker News「Show HN」，迅速獲得社群關注。Y Combinator 在 2026 年 7 月 23 日透過官方 X 賬號公開推廣 OneCLI，將其定義為「讓 AI Agent 在不儲存密碼的情況下做真正的工作」的基礎設施層。 OneCLI 採用 Apache-2.0 許可證，目前仍處於早期快速迭代階段（v1.42.0+），但已有 Docker、MindsDB、Zoho、Coralogix 等公司開始使用。
-
OneCLI 的核心工作流程分為三步。第一步，運營者將真實的 API 憑據存入 OneCLI 的加密保險庫；第二步，為每個 Agent 發放佔位符金鑰（如 FAKE_KEY），Agent 在發出 HTTP 請求時使用這些假金鑰；第三步，OneCLI 閘道器攔截請求，根據主機和路徑匹配規則，在請求離開閘道器前完成憑證的解密和替換，最後將攜帶真實憑證的請求轉發給目標服務。整個過程中，Agent 從未在任何環節接觸真實金鑰。 技術棧上，OneCLI 由三層構成。Rust 編寫的高效能 HTTP 閘道器負責攔截出站請求並注入憑證，Agent 透過 Proxy-Authorization 頭攜帶訪問令牌完成身份認證。Next.js 構建的 Web 儀表盤用於管理 Agent、金鑰和許可權，閘道器透過儀表盤暴露的 API 動態解析每次請求該注入哪些憑據。憑證儲存層採用 AES-256-GCM 加密，金鑰只在請求發生時才解密，解密後嚴格按主機和路徑模式匹配後以請求頭或 URL 引數的形式注入。 部署極為簡單，一條命令即可啟動：docker run -d --name onecli -p 10254:10254 -p 10255:10255 -v onecli-data:/app/data ghcr.io/onecli/onecli 啟動後訪問 http://localhost:10254 建立 Agent、新增金鑰，然後將 Agent 的 HTTP 代理指向 localhost:10255。Agent 框架無需任何程式碼修改——只要支援設定 HTTPS_PROXY 環境變數即可接入。這包括 Claude Code、Codex、Cursor、Cline 以及 OpenClaw、NanoClaw、LangChain、CrewAI 等主流框架。 OneCLI 還提供 onecli CLI 命令列工具，讓 Agent 能透過 Shell 命令自主管理自己的身份和金鑰——Agent 編排器可以在一個指令碼中建立新 Agent、分配憑證、配置規則，無需人工操作儀表盤。 本地模式支援單使用者免登入執行，無需配置 NEXTAUTH_SECRET。團隊協作可以啟用 Google OAuth 認證。所有環境變數都有合理預設值，SECRET_ENCRYPTION_KEY 不設定時會自動生成。
-
OneCLI 目前完全免費開源（Apache-2.0），免費層支援最多 2 個 Agent，無需信用卡。專案團隊目前是 Y Combinator 孵化的創業公司，尚未公佈正式商業版本的具體定價方案。可以預見的商業路徑包括：企業版的多 Agent 支援、高階策略引擎、組織級身份提供商整合以及託管雲服務。
-
社群對 OneCLI 的總體評價積極，尤其在 Agent 安全社群中反響熱烈。Hacker News 討論帖中有開發者指出，憑證代理方案這類方案並非全新（如 Fly.io 的 Tokenizer、BuzzFeed SSO 代理等），但專為 AI Agent 場景量身定製的實現確實降低了落地門檻。也有開發者分享了使用 HashiCorp Vault 配合指令碼實現類似效果的方案，但承認 OneCLI 的「開箱即用」體驗更好。 Y Combinator 官方賬號推廣的演示影片展示了 Claude Code 透過 OneCLI 閘道器呼叫 GitHub API 的完整流程——Agent 全程只持有 FAKE_KEY，真實 PAT 在請求發出瞬間由閘道器注入。 中文社群的評價以建設性為主。部落格園上有開發者對 OneCLI 進行了實測，認為其「改造成本接近於零」，但對於已經在執行生產環境 Agent 的團隊，需要特別注意閘道器的 HTTPS 證書管理和網路隔離。也有評論指出，集中化管理憑證也意味著集中化了風險——如果 OneCLI 伺服器被攻破，攻擊者將獲得一個極為有價值的目標。
-
OneCLI 獲得了多個權威來源的正面報道。Y Combinator 的公開推廣被視為行業訊號——加速器認為 Agent 安全基礎設施是一個獨立的、值得重點佈局的賽道。The Agent Times、World AI 360 等媒體均進行了報道，普遍認為 OneCLI 的設計模式——將憑證隔離在 Agent 記憶體之外——有望成為 Agent 架構的標準安全層。 從競品格局來看，OneCLI 面臨的主要競爭來自兩類方案。一類是傳統金鑰管理工具（HashiCorp Vault、AWS Secrets Manager、1Password），這些工具解決的是儲存問題，但不解決注入問題——Agent 拿到金鑰後仍然存在洩露風險。另一類是新興的 Agent 框架（如 MCP 協議），但 MCP 工具定義會消耗 Agent 的上下文視窗，且每個 MCP 伺服器各自處理認證，缺乏統一的憑證管理。OneCLI 的差異化定位正是在這兩類方案之間找到了空白地帶：既解決儲存，又解決注入，同時不消耗 Agent 的上下文視窗。
-
OneCLI 並非沒有風險。核心問題在於 MITM CA 模型——閘道器需要持有 CA 金鑰來為任意目標籤發證書，這意味著在共享或多租戶機器上，許可權提升漏洞可能暴露 CA 金鑰。部署時需要在 Docker 容器隔離和網路名稱空間上格外謹慎。 專案雖然迭代速度快、社群增長迅猛，但仍處於 v1.x 階段，API 和配置格式可能隨版本升級發生變化。對於需要長期穩定性保障的企業，建議將 OneCLI 作為可評估的方案進行原型驗證，同時保留傳統憑證管理作為回退方案。 還有一個不可忽視的問題是集中化信任——把憑證集中在一個閘道器管理，雖然提升了運維效率，但也意味著閘道器本身成為單點爆破目標。運營者需要對該閘道器進行額外加固，包括但不限於：限制儀表盤訪問 IP、啟用審計日誌外部儲存、定期輪換加密金鑰。
-
OneCLI 最適合兩類團隊。第一類是正在執行編碼 Agent（Claude Code、Codex、Cursor）的開發和運維團隊，這些 Agent 需要頻繁呼叫 GitHub、Slack、Jira 等外部 API，每一行輸出都可能包含金鑰。第二類是構建多 Agent 協作系統的團隊，需要統一管理和審計所有 Agent 的 API 訪問。 不適合的場景包括：僅執行在完全隔離網路中的 Agent、已有成熟 HashiCorp Vault 部署且不願增加額外基礎設施的團隊，以及需要嚴格合規審計（如 SOC 2 Type II）的對標企業。對於後者，建議等 OneCLI 完成第三方安全審計後再考慮生產級部署。
-
OneCLI 精準命中了 AI Agent 普及過程中的一個真實痛點——憑證安全——並提供了一個工程上優雅且實用的解法。它的核心判斷是「Agent 連金鑰都不該碰」，並將這一原則貫徹到了架構層面。在 Agent 從玩具走向生產力的關鍵轉折期，OneCLI 有望成為 Agent 基礎設施的安全標配。但它的真正價值，要等到完成第三方審計併發布穩定版 2.0 之後才能被充分驗證。
使用者評論
-
2hyqkek—試了一下 OneCLI，把 Claude Code 的金鑰管理問題徹底解決了。之前每次都要在 .env 裡塞各種 API Key，現在一條 docker 命令跑起來，Agent 完全不知道真實金鑰，安全感提升太多了。 -
珊瑚37—有人拿它和 HashiCorp Vault 比，我覺得定位不一樣。Vault 太重了，一個小團隊搞 Agent 開發，OneCLI 一鍵部署真的省心。 -
RGonzales_Plus—Rust 寫的 HTTP 閘道器，效能確實穩。我測了一下延遲，加了 OneCLI 代理之後幾乎沒感覺到額外開銷，比用 Vault 每次去取金鑰快太多了。 -
王月珍—看到 YC 官方號推了 OneCLI，去了解了一下。思路確實好——不是不讓 Agent 呼叫 API，而是讓 Agent 連金鑰都不該碰。這個設計哲學我認可。 -
FrankHicksIII—Hacker News 上有人質疑說這東西不就是個 auth proxy 嗎，確實類似方案以前也有。但專為 Agent 場景做了最佳化，開箱即用，這就夠了。 -
AnnGray—部署是簡單，docker run 一行就能跑起來。但有一個坑：需要自己處理自簽證書的問題，Agent 容器裡不信任 CA 證書的話 HTTPS 流量就過不了。 -
流年472—OneCLI 的做法讓我想起了之前看的一個真實案例：某大廠的安全負責人給 Agent 授權後，Agent 開始瘋狂刪郵件。要是當時有一層閘道器策略限制，可能就只刪幾封而不是全部了。 -
8j0wz—用 OneCLI 配合 NanoClaw 試了一下，體驗很絲滑。Agent 完全不知道金鑰的存在，想洩露都沒辦法。對安全敏感的團隊來說，這個組合拳值得一試。 -
HaroldStephensIII—已在我的 Cursor 工作流裡整合了 OneCLI，給 GitHub、OpenAI 和 Slack 的 API 都配置好了。配置過程很直觀，Web 面板左管理 Agent 和金鑰，許可權粒度夠細。 -
AshleyOrtiz—唯一的顧慮是集中化風險。所有金鑰都走 OneCLI 閘道器，萬一這個閘道器被攻破就全完了。雖然加密儲存做得好，但在生產環境我對單點故障還是有些擔心。 -
康明_1—對比了幾款憑證管理工具，OneCLI 對個人開發者最友好。Authsome 雖然零基礎設施，但沒有審計；Vault 又太重。OneCLI 好在中間檔位。 -
Isabella.Morgan—還能對接 Bitwarden 這點挺香，金鑰不需要存在 OneCLI 本地資料庫裡，直接從 Bitwarden 拉取。對於已經在用密碼管理器的團隊來說遷移成本很低。 -
KeithStewartJr—看了一下程式碼，Rust 閘道器那層寫得挺紮實的。AES-256-GCM 靜態加密，請求時才解密，設計上沒有明顯短板。期待他們後續加審批流和監控規則。 -
Jacqueline.Adams—雖然 OneCLI 能防止金鑰洩露，但它擋不住授權後的 Agent 亂搞。Agent 有許可權調 Stripe API 就能隨便扣費，這個問題還需要審批流來解決，光靠閘道器不夠。 -
Laura_MooreIII—從 Show HN 關注的，到現在 2800+ star 了，增長確實快。說明這個痛點真的戳中很多人。Apache-2.0 協議＋YC 背書，值得關注。 -
7wnel5q—部署了 OneCLI 之後有個意外收穫：審計日誌太好用了。以前 Agent 調了什麼 API、什麼時候調的完全不可見，現在一目瞭然，排查問題效率高很多。 -
EHughesIII—Gateway + Dashboard + 加密儲存三件套的架構很清晰。Rust 閘道器的效能不是問題，Next.js 面板操作也順手。就是文件有些地方寫得太簡略，新手可能要多摸索一下。 -
smallpeacock198—跟著部落格園那篇實測文章走了一遍，本地部署花了不到十分鐘。用 Claude Code 調 GitHub API，全程只看見 FAKE_KEY。這個透明替換確實有點黑科技的感覺。 -
Brian.Martinez168—對我這種做 AI Agent 開發的來說，OneCLI 解決了最頭疼的問題——每次 demo 前都得檢查 .env 檔案有沒有被不小心 commit 上去。現在不用擔心了。 -
Web_3Wave—目前還處於 1.x 階段，API 變化可能比較頻繁。生產環境用的話建議鎖定版本，不然升級後配置格式變了就麻煩了。 -
purplepanda996—把 OneCLI 接入到我們團隊的多 Agent 系統裡了，三個專案各自隔離金鑰和策略。這種專案級隔離設計很實用，不同客戶的資料不會串。 -
許桂強—我就想知道它什麼時候支援 1Password 整合，現在只有 Bitwarden 有點侷限。團隊裡用 1Password 的人挺多的，希望能加上。 -
DianeMitchell_Plus60—Docker 一行命令就搭起來了，確實方便。不過我試了一下 Node.js 的 Agent，HTTP_PROXY 環境變數在 Node 舊版本上支援不太好，得用 22+ 才行。 -
LoganRodriguez_20234—好評。之前做過一個實驗，普通 Prompt Injection 攻擊從環境變數裡把 OpenAI Key 騙出來了。用了 OneCLI 之後再試同樣的攻擊，Agent 手裡根本沒有 Key，想洩露也洩露不了。 -
OMpow—策略引擎的設計不錯，可以為每個 Agent 單獨配 allow/block 規則和速率限制。這個比簡單的金鑰管理要深入得多，算是在網路層做了許可權管控。 -
雲煙737—PostgreSQL 依賴是個門檻，個人開發為了跑它還得裝個資料庫有點 overkill。好在他們說有 PGlite 嵌入式版本，不用單獨搭資料庫，期待正式支援。 -
AfraRomkes—和團隊的 DevOps 聊了一下，他覺得 OneCLI 的 MITM 代理方案對信創環境來說有合規風險。自簽證書在等保審計裡不一定被認可，建議留意這個點。 -
WLopezX736—The Agent Times 那篇分析文章寫得好，點出了關鍵問題：OneCLI 解決了金鑰洩露，但解決不了 Agent 濫用授權。不過瑕不掩瑜，至少先把最要命的問題解決了。 -
goldendog167—開了個 Issue 問關於審批流的問題，開發者回覆很快，說已經在 roadmap 上了。Y Combinator 押注的專案，迭代速度應該不會慢。 -
星辰_14—看了 karpathy 轉發的關於 CLI 和 Agent 的觀點，再來看 OneCLI 的設計，確實契合。CLI 是 Agent 的原生介面，在 CLI 層做憑據管理比在應用層做更底層、更通用。