本地 AI 與代理工具
Otis 將 llama.cpp、本地模型選型與代理權限整合進同一套桌面及終端介面
Otis 在 9 月 13 至 14 日集中公開推廣，會依硬體推薦並下載 GGUF，再以內建 llama.cpp 啟動本地代理。離線模式不需要帳號，但搜尋、PAIR 叢集及 Fireworks 推論屬於不同的資料與信任邊界。
新近在 LocalLLM 與 Hacker News 公開推廣的 Otis，試圖把「下載模型、啟動推論伺服器、設定代理工具」收斂成一次初始化流程。這個 MIT 授權專案提供原生桌面程式、OpenTUI 終端介面與無頭 CLI；共用的代理執行層可讀寫檔案、執行命令、搜尋網頁、保留 session，並把探索工作交給子代理。
本地路徑會偵測硬體、從策展目錄選擇 GGUF、驗證 checksum，再用 Otis 管理的 `llama-server` 綁定 `127.0.0.1`。README 建議至少配置 24GB RAM 或 Apple unified memory，Linux 則可用 Vulkan GPU 加速。若家中另有 NVIDIA 機器，也能接到獨立安裝的 PAIR，讓其透過 Ollama 或 LM Studio proxy 把完整請求路由至合適節點；需要更大開放權重模型時，則可攜帶自己的金鑰直接呼叫 Fireworks。
代理狀態採 append-only JSONL 保存，包含訊息、工具卡、diff 與供應商回報的用量。無頭模式可輸出純文字、JSON 或串流 JSONL；在沒有互動提示時，未符合政策的寫入、編輯和 shell 呼叫預設會被拒絕，除非使用者明確啟用自動執行。這使它比單純的本地聊天 UI 更接近可嵌入 CI 的代理 harness。
「本地」仍需精確解讀：只有 llama.cpp 路徑可完全離線；搜尋會直接連到 Parallel MCP，託管推論會送往 Fireworks，PAIR 的網路流量則由該叢集管理。專案目前沒有公開任務成功率、延遲或安全評測，社群採用量也仍小。接下來值得觀察的是硬體推薦能否處理量化品質與上下文記憶體，而不只是依總 RAM 配對模型，以及 shell 權限、技能來源和子代理委派能否接受獨立稽核。