Gini Agent：把 runtime 當成 gateway 的個人代理，值不值得裝在你自己機器上
The agent that remembers and learns.
秒懂
- 它是什麼？
- Gini Agent 用單一 Bun 行程同時扮演 runtime 與 gateway，讓網頁、CLI、手機與 MCP 都只是同一個 /api/* 合約的客戶端。這篇談它解決什麼、機制長什麼樣、以及哪些情況下你根本不該選它。
- 適合誰用？
- 如果你要的是一個跑在自己機器上、狀態由 runtime 掌握、手機也能接手操作的個人代理，Gini Agent 的 gateway 即 runtime 設計值得實際裝一次來驗證，安裝指令就是 README 給的那行 curl 到 install.sh 的腳本。反過來說，若你需要的是無狀態、可水平擴充的服務端 agent，或你無法接受授權條款要求你自行確認的相依風險，這個專案不是對的選擇。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 60 天前。
- 用什麼語言寫的？
- 主要是 TypeScript（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它想補的那個洞：runtime 才是紀錄，聊天只是介面
多數個人代理專案把對話當成主要產物，狀態散在聊天記錄、暫存檔與工具回傳值裡。Gini Agent 的 README 直接把這件事翻過來講：聊天是互動介面，runtime 才是 conversations、runs、tasks、approvals、memory、skills、jobs、tools、traces、audit events 與 runtime health 的紀錄來源。這個定位決定了它的目標使用者。你要的不是一個問答視窗，而是一個會排程工作、跨工具執行多步驟任務、需要你核准時才打斷你的常駐程式。它明確說自己 built to be a product, not plumbing，也就是把「代理需要你介入」這件事當成產品功能來設計，而不是丟一句說明文字叫你自己去想辦法。文件裡列的互動原語有四種：安全憑證欄位、登入與敏感步驟的瀏覽器接手、選項提示、以及送出前確認。每一種都對應一份 ADR，例如 docs/adr/browser-fill-secret.md 與 docs/adr/user-confirmation-primitive.md。這種把「人機交接」規格化的做法，在同类專案裡並不常見，也是它最值得看的地方。
單一 Bun 行程扛下 gateway：客戶端只是同一份合約的門面
架構用一句話就能講完：runtime 就是 gateway。每個 instance 是一個 Bun 行程，獨佔狀態並執行工作。Next.js 網頁應用、CLI、Expo 手機應用、MCP 介面與訊息橋接，全部都是同一個認證過的 /api/* 合約的客戶端。README 附的示意圖把這件事畫得很清楚：gateway 在上方，下面分成 Next.js BFF（瀏覽器 UI，瀏覽器端不持有 token）、CLI 與腳本（bearer token）、以及其他客戶端（行動端、MCP、訊息）。這裡有個容易忽略的細節：BFF 那一支標註 no browser token，意思是瀏覽器不直接拿憑證，由 Next.js 伺服器端代為持有。這個切法讓網頁端不必把 token 放進前端，代價是你多了一層伺服器端要維護。平行 instance 是支援的，各自有隔離的狀態、連接埠與日誌，這對同時跑多個實驗環境的人有用。要注意的是這種「一個行程包辦全部」的設計，優點是狀態一致、部署單純，缺點是擴充路徑有限，之後要拆成多行程時，狀態歸屬會是第一個要解的問題。
記憶與技能學習：兩層獎勵、歸因、每日檢視與人工閘門
文件把記憶與技能學習拆成兩份：docs/memory.md 講 retain、recall、embeddings、reranking、review 與 storage；docs/skill-learning.md 講它如何從任務結果改進自己的技能，關鍵字是 two-tier reward、attribution、the daily review 與 the human gate。從這些詞可以推斷設計者的立場：不讓代理無條件自我修改。技能改進走的是每日檢視流程，而且有人工閘門，也就是改動要經過人同意才會生效。這是保守的選擇，換來的是可審計性，代價是學習速度受限於你多久看一次檢視結果。記憶方面，本地嵌入、重排序與語音訊息轉文字都是預設啟用，不強制外送。這對在意資料不出機器的人是加分，但反過來說，本地模型意味著你的硬體直接決定 recall 品質與延遲，而 README 並沒有給出任何效能數字，這部分只能自己裝起來量。
裝起來會碰到什麼：install.sh、/setup 與供應商憑證
README 給的安裝方式是這一行：curl -fsSL https://raw.githubusercontent.com/Open-Curiosity/gini-agent/main/scripts/install.sh | bash。在 macOS 上，安裝腳本會啟用自動啟動（runtime 與 webapp 各自一個 per-user LaunchAgent）、等待 webapp 起來，然後在瀏覽器打開 /setup 頁面。設定表單提供完整的供應商目錄。供應商支援範圍相當廣：Codex OAuth；OpenAI、Azure OpenAI、DeepSeek、OpenRouter 走 API key；第一方 Anthropic Claude API；Amazon Bedrock 走 model-agnostic Converse 與 AWS SigV4，涵蓋 Claude、Nova、Llama、Mistral、DeepSeek；以及任何 OpenAI 相容的本地伺服器。每個供應商的憑證、前置條件與 CLI/網頁設定分別寫在 docs/providers/README.md 底下。維運面另有 docs/operations.md 講 install、start、stop、smoke、diagnostics 與 cleanup，以及 docs/deployment-docker.md 講如何在容器裡以 Xvfb 跑真實瀏覽器做 headless 部署。遠端存取走 tunnel，文件分列 Gini Relay、Tailscale、ngrok 與 Cloudflare 四種，而且強調這些頁面就是應用程式內嵌開啟的同一份內容。從 openclaw 過來的使用者另有 docs/migration-from-openclaw.md 可參考。
憑證不進對話：安全卡片的實際邊界
README 對安全欄位的描述很具體：key、password、OTP 或付款欄位打進一張安全卡片，直接流向 gateway，不會經過模型、逐字稿或稽核軌跡。這句話的範圍要讀準。它保證的是憑證不進模型與紀錄，不保證代理之後不會拿這個憑證去做別的事。真正限制代理行為的是另一組原語：送出前確認。代理要替你發訊息、回覆、發文或購買之前，會先顯示即將發生的事與一顆送出按鈕。這兩件事合起來才是完整的故事：憑證保密是輸入端的事，行為授權是輸出端的事，兩者由不同機制處理。文件沒有說明安全卡片的實作細節，也沒有談金鑰在磁碟上如何存放，這是要自己去看原始碼或 docs/gateway.md 才能確認的部分。如果你的威脅模型包含本機檔案系統被讀取，這份 README 不足以讓你下判斷。
什麼時候它不是對的工具
第一，這是 local-first 的單機 runtime，不是無狀態服務。如果你要的是可以水平擴充、多租戶共用、按請求計費的後端 agent，這個架構從根上就不合，平行 instance 是隔離而非共享，狀態綁在行程上。第二，它的價值有很大一部分建立在「代理會主動做事」這個前提上。如果你只需要一個接上自家 API 的對話介面， approvals、jobs、skills 這些機制只會變成你要維護卻用不到的負擔。第三，本地嵌入與重排序是預設路徑，文件沒有提供硬體門檻或效能數據，資源受限的機器上這會是第一個瓶頸。第四，專案在 2026 年 5 月到 6 月間連續推出 v0.1.0、v0.2.0、v0.3.0，版本節奏快，介面與設定在這階段變動是常態，把它放進需要長期穩定的生產環境前要有心理準備。第五，README 在 Quick Start 段落被截斷，供應商目錄的完整內容無法從這份材料確認，實際可用的供應商清單要以 docs/providers/README.md 為準。
替代路線：OpenClaw 與「runtime 即 gateway」的差別
文件裡唯一被明確點名的同類系統是 openclaw，而且提供了 docs/migration-from-openclaw.md 這份匯入指南，可見兩者在資料模型上有對應關係，至少遷移是被當成正式路徑在維護。差別的關鍵在架構取捨而不是功能清單：Gini 把 runtime 與 gateway 合成單一行程，所有客戶端共用一份認證 API，狀態只有一處；這種做法讓網頁、CLI、手機看到的是同一份事實，代價是擴充與隔離都受限於單一行程。若替代方案的取向是把 runtime 與對外介面分開，好處是可以各自替換與擴充，代價是你得自己處理跨行程的狀態一致性。選擇的判準很簡單：你需不需要多個客戶端看到完全一致的即時狀態。需要，單行程的設計省掉大量同步工作；不需要，分離式架構給你更大的調整空間。至於其他個人代理框架，這份材料沒有提及，我不做比較。
授權與維護成本：MIT 之外你要自己算的帳
授權是 MIT，這在採用上幾乎沒有障礙，你可以修改、商用、閉源再散布，只要保留著作權與授權聲明。這不是法律意見，實際條文請自行確認。維護成本則要看幾個具體面：runtime 與 webapp 在 macOS 上以 per-user LaunchAgent 自動啟動，代表升級時你要處理正在執行的行程，docs/operations.md 的 stop 與 cleanup 章節就是為此存在。供應商憑證分散在各家，docs/providers/README.md 是唯一清單，換供應商時要重走一次設定。Bedrock 走 AWS SigV4，憑證輪替的流程與 API key 不同，這點在導入前要先確認。記憶與技能學習涉及本地模型檔案，docs/memory.md 講 storage，磁碟用量與備份策略要自己評估。專案有 docs/releases.md 說明版本慣例與發布流程，版本號還在 0.x，語意化版本在 0.x 階段的相容性承諾本來就弱，鎖版本是合理做法。
編輯結論
如果你要的是一個跑在自己機器上、狀態由 runtime 掌握、手機也能接手操作的個人代理，Gini Agent 的 gateway 即 runtime 設計值得實際裝一次來驗證，安裝指令就是 README 給的那行 curl 到 install.sh 的腳本。反過來說，若你需要的是無狀態、可水平擴充的服務端 agent，或你無法接受授權條款要求你自行確認的相依風險，這個專案不是對的選擇。動手前先確認三件事：docs/providers/README.md 裡你要用的供應商是否列在憑證與前置條件清單中、docs/gateway.md 描述的連接埠與磁碟配置是否與你機器上既有服務衝突、以及 docs/memory.md 說明的本地嵌入與重排序模型在你的硬體上是否跑得動。這三項沒確認，後面的設定都會卡住。
社群筆記