# 21 個 GitHub 專案評估報告
## 對照 SA 文件（MEC-AI 機構設計 AI Agent 系統）之可行性分析
---
## 目錄
1. [SA 文件架構摘要](#1-sa-文件架構摘要)
2. [評估準則（14 項）](#2-評估準則14-項)
3. [專案分類總覽](#3-專案分類總覽)
4. [各專案詳細評估](#4-各專案詳細評估)
5. [組合方案建議](#5-組合方案建議)
6. [最終推薦排序](#6-最終推薦排序)
7. [結論](#7-結論)
**附錄**
- [附錄 A：IronClaw 連接遠端 PostgreSQL/pgvector 配置指南](#附錄-aironclaw-連接遠端-postgresqlpgvector-配置指南)
- [附錄 B：IronClaw pgvector 用途分析 — 記憶 vs. 知識庫](#附錄-bironclaw-pgvector-用途分析--記憶-vs-知識庫)
- [附錄 C：組合方案可行性深入分析](#附錄-c組合方案可行性深入分析)
- [附錄 D：SA 自建系統成本與維護性評估](#附錄-dsa-自建系統成本與維護性評估)
---
## 1. SA 文件架構摘要
| 層面 | SA 文件規格 |
|------|------------|
| **Client 端** | Windows 11 筆電 — FastAPI (Python 3.11) + LangGraph/LangChain Agent + llama.cpp server (port 8080) + React/Vite 前端 (port 5173) |
| **Server 端** | 整合部伺服器 — PostgreSQL 16 + pgvector (HNSW index) |
| **LLM** | Qwen2.5-VL 7B (chat+vision) + nomic-embed-text (embedding, 768-dim)，透過 llama.cpp 提供 |
| **Agent** | LangGraph 狀態機 + LangChain tool calling + MCP 協定（langchain-mcp-adapters） |
| **MCP** | CAD 工具伺服器 (port 8100) — BOM 查詢、公差查詢、材料推薦、圖面標註檢查 |
| **RAG** | pgvector 混合檢索 (向量 + 全文搜尋) |
| **Database** | PostgreSQL (server) + SQLite (client, 對話/稽核/checkpoint) |
| **部署** | 完全離線內網（air-gapped）、USB 安裝、NSSM 管理 Windows 服務 |
| **使用者** | 無需登入、單一使用者預設 |
---
## 2. 評估準則（14 項）
| # | 準則 | 說明 |
|---|------|------|
| C1 | Docker 為最後手段 | 優先裸機/原生安裝；Docker 僅作為備案 |
| C2 | Windows 原生支援 | 必須在 Windows 11 上原生運行（非 WSL2） |
| C3 | llama.cpp 相容 | 能使用 llama.cpp 或 OpenAI-compatible API 連接本地模型 |
| C4 | RAG/MCP/Skills 能力 | 具備 RAG 文件檢索、MCP 協定整合、技能擴展 |
| C5 | 低資源消耗 | 適合在一般筆電上運行（16GB RAM, 無獨顯亦可） |
| C6 | 公司/組織可靠度 | 背後有穩定團隊或公司，不會突然消失 |
| C7 | 商業化風險低 | 授權寬鬆（MIT / Apache 2.0），不會突然轉為閉源 |
| C8 | 基本 Agent 能力 | 檔案讀寫、Shell 執行、工具調用 |
| C9 | 向量資料庫外掛 | 支援 pgvector 或可插拔的向量 DB |
| C10 | Skills 外掛擴展 | 可自定義技能/工具/插件 |
| C11 | 無前端 UI 優先 | 傾向 headless / API-first；有 UI 也可但非必要 |
| C12 | 允許組合方案 | 可與其他專案搭配使用 |
| C13 | 低維護成本 | No-code/Low-code 友善，易於維護 |
| C14 | 技術棧獨立性 | 不綁定特定 LLM 供應商或雲端服務 |
---
## 3. 專案分類總覽
### A. LLM Runtime / 模型服務層
| 專案 | ⭐ Stars | 語言 | 授權 | 定位 |
|-------|---------|------|------|------|
| GPT4All | 77.2k | C++/Python | MIT | 桌面 LLM 應用，llama.cpp 核心 |
| Jan | 41.4k | TypeScript/Rust | Apache 2.0 | ChatGPT 替代品，llama.cpp + MCP |
| LM Studio CLI | 4.4k | TypeScript | MIT | LM Studio 專屬 CLI 工具 |
### B. AI Agent Framework / 後端框架
| 專案 | ⭐ Stars | 語言 | 授權 | 定位 |
|-------|---------|------|------|------|
| DeepAgents | 18k | Python | MIT | LangChain/LangGraph agent harness |
| Nanobot | 36.9k | Python | MIT | 輕量級 Python agent (MCP+Skills) |
| PicoClaw | 26.7k | Go | MIT | 超輕量 Go agent (<10MB RAM) |
### C. Full-Stack AI Chat/RAG 平台
| 專案 | ⭐ Stars | 語言 | 授權 | 定位 |
|-------|---------|------|------|------|
| AnythingLLM | 57.1k | JavaScript | MIT | 一站式 AI 應用（桌面/Docker） |
| LibreChat | 35k | TypeScript | MIT | 自建 AI 聊天平台 |
| Onyx | 20.1k | Python/TypeScript | MIT(CE) | 企業 AI 平台（40+ connectors） |
| Langflow | 146k | Python/TypeScript | MIT | 視覺化 AI 工作流建構器 |
### D. RAG 專用平台
| 專案 | ⭐ Stars | 語言 | 授權 | 定位 |
|-------|---------|------|------|------|
| Kotaemon | 25.2k | Python | Apache 2.0 | RAG 文件問答 UI |
| Quivr | 39.1k | Python | Apache 2.0 | RAG 函式庫（嵌入式） |
### E. Coding Agent / 程式助手
| 專案 | ⭐ Stars | 語言 | 授權 | 定位 |
|-------|---------|------|------|------|
| Cline | 59.6k | TypeScript | Apache 2.0 | VS Code 自主程式助手 |
| Aider | 42.5k | Python | Apache 2.0 | 終端機 AI 配對程設 |
| OpenCode | 132k | TypeScript | MIT | 開源 coding agent (TUI+Desktop) |
| OpenWork | 12.8k | TypeScript/Rust | MIT | OpenCode 桌面包裝 |
### F. 個人 AI 助手
| 專案 | ⭐ Stars | 語言 | 授權 | 定位 |
|-------|---------|------|------|------|
| OpenClaw | 340k | TypeScript | MIT | 多頻道個人 AI 助手 |
| IronClaw | 11.1k | Rust | MIT/Apache 2.0 | OpenClaw 的 Rust 重寫（安全優先） |
| NanoClaw | 25.9k | TypeScript | MIT | 輕量 OpenClaw（Claude 專屬） |
### G. 不相關 / 無法使用
| 專案 | 原因 |
|-------|------|
| Budibase | 通用低程式碼平台，與 AI Agent 無關 |
| ZeroClaw | 倉庫 404，不存在 |
| LM Studio CLI | LM Studio 專屬 CLI，無法獨立使用 |
---
## 4. 各專案詳細評估
### 評分說明
- ✅ 完全符合 | ⚠️ 部分符合/需調整 | ❌ 不符合 | ➖ 不適用
---
### 4.1 GPT4All（77.2k ⭐）
**定位**：桌面 LLM 應用（Nomic AI）
| 準則 | 評分 | 說明 |
|------|------|------|
| C1 Docker | ✅ | 原生桌面應用，無需 Docker |
| C2 Windows | ✅ | 原生 Windows 安裝程式 |
| C3 llama.cpp | ✅ | 核心基於 llama.cpp |
| C4 RAG/MCP/Skills | ⚠️ | LocalDocs 提供基本 RAG；**無 MCP、無 Skills** |
| C5 低資源 | ✅ | 桌面應用，資源消耗可控 |
| C6 組織可靠度 | ✅ | Nomic AI 公司支持 |
| C7 商業化風險 | ✅ | MIT 授權 |
| C8 Agent 能力 | ❌ | 無檔案操作、無 Shell、無 tool calling |
| C9 向量 DB 外掛 | ❌ | 內建 LocalDocs，不支援 pgvector |
| C10 Skills 外掛 | ❌ | 無插件系統 |
| C11 無前端 | ❌ | 桌面 GUI 為主 |
| C12 組合方案 | ⚠️ | 可作為 LLM runtime（透過 API），但功能有限 |
| C13 低維護 | ✅ | 安裝即用 |
| C14 技術棧獨立 | ⚠️ | 綁定 GPT4All 生態 |
**可替代角色**：僅能替代 llama.cpp server 部分（LLM 推理層），但 LocalDocs RAG 品質不如 SA 方案。
**最後活躍**：~10 個月前 — **潛在停滯風險**
**結論**：❌ 不建議。功能太少、缺乏 MCP/Agent/Skills，且專案可能停滯。
---
### 4.2 Jan（41.4k ⭐）
**定位**：開源 ChatGPT 替代品（Jan AI）
| 準則 | 評分 | 說明 |
|------|------|------|
| C1 Docker | ✅ | 原生桌面應用 |
| C2 Windows | ✅ | 原生 Windows 安裝（Tauri + Rust） |
| C3 llama.cpp | ✅ | 內建 llama.cpp engine |
| C4 RAG/MCP/Skills | ⚠️ | **有 MCP 整合**；RAG 需外掛；擴展系統存在但生態薄弱 |
| C5 低資源 | ✅ | Tauri 架構，比 Electron 輕量 |
| C6 組織可靠度 | ✅ | Jan AI 團隊，活躍開發中 |
| C7 商業化風險 | ✅ | Apache 2.0 |
| C8 Agent 能力 | ⚠️ | 有基本工具調用；無原生檔案操作/Shell 能力 |
| C9 向量 DB 外掛 | ❌ | 無 pgvector 支援 |
| C10 Skills 外掛 | ⚠️ | 擴展系統存在但不成熟 |
| C11 無前端 | ⚠️ | 有 OpenAI-compatible API (localhost:1337)，可 headless 使用 |
| C12 組合方案 | ✅ | 可作為 LLM runtime + MCP client |
| C13 低維護 | ✅ | GUI 管理模型，使用者友善 |
| C14 技術棧獨立 | ✅ | 支援多種模型和 API |
**可替代角色**：可替代 **llama.cpp server** 層，同時提供模型管理 GUI 和 MCP client。
**結論**：⚠️ 可考慮作為 LLM Runtime 元件。若僅需 LLM 推理 + 基本 MCP，Jan 是不錯選擇。但無法替代完整 Agent 框架和 RAG pipeline。
---
### 4.3 Langflow（146k ⭐）
**定位**：視覺化 AI 工作流建構器（DataStax）
| 準則 | 評分 | 說明 |
|------|------|------|
| C1 Docker | ⚠️ | 有 Desktop 版；pip install 也可 |
| C2 Windows | ✅ | Desktop app 支援 Windows |
| C3 llama.cpp | ⚠️ | 透過 Ollama/OpenAI-compatible API 間接支援 |
| C4 RAG/MCP/Skills | ✅ | 完整 RAG、MCP server/client、所有主流向量 DB |
| C5 低資源 | ❌ | Python 重依賴，資源消耗高（1-2GB+ RAM） |
| C6 組織可靠度 | ✅ | DataStax（企業級）收購支持 |
| C7 商業化風險 | ⚠️ | MIT 但 DataStax 可能推 Enterprise 版 |
| C8 Agent 能力 | ✅ | 流程中可加入工具節點 |
| C9 向量 DB 外掛 | ✅ | 支援 pgvector、Chroma、Pinecone 等所有主流 |
| C10 Skills 外掛 | ✅ | 自定義元件系統 |
| C11 無前端 | ❌ | 核心是視覺化 UI |
| C12 組合方案 | ✅ | 可匯出為 API，與其他系統整合 |
| C13 低維護 | ✅ | No-code 拖拉式設計，非常適合低維護 |
| C14 技術棧獨立 | ✅ | 支援所有主流 LLM/向量 DB |
**可替代角色**：理論上可替代整個 **Backend + Agent + RAG + MCP** 管線。
**關鍵問題**：
1. 資源消耗偏高（Python 大量依賴）
2. 離線部署需要預先打包所有依賴
3. 黑盒式架構，深度客製化困難
**結論**：⚠️ 有潛力但風險高。No-code 優勢強大，但在離線環境下打包部署複雜、資源消耗大。適合原型驗證，不建議作為最終生產方案。
---
### 4.4 LibreChat（35k ⭐）
**定位**：自建 AI 聊天平台
| 準則 | 評分 | 說明 |
|------|------|------|
| C1 Docker | ❌ | **強依賴 Docker Compose** |
| C2 Windows | ⚠️ | 需 Docker Desktop |
| C3 llama.cpp | ⚠️ | 透過 OpenAI-compatible API |
| C4 RAG/MCP/Skills | ✅ | Agents、MCP、RAG API、Code Interpreter |
| C5 低資源 | ❌ | MongoDB + 多容器，資源消耗高 |
| C6 組織可靠度 | ⚠️ | 社群主導，無公司支持 |
| C7 商業化風險 | ✅ | MIT |
| C8 Agent 能力 | ✅ | 完整 Agent 能力 |
| C9 向量 DB 外掛 | ⚠️ | 有 RAG 但向量 DB 選擇有限 |
| C10 Skills 外掛 | ⚠️ | 有擴展但生態一般 |
| C11 無前端 | ❌ | 重前端 UI |
| C12 組合方案 | ⚠️ | 作為前端 UI 層有價值 |
| C13 低維護 | ⚠️ | Docker 管理不算太複雜但非原生 |
| C14 技術棧獨立 | ✅ | 多 LLM 支援 |
**結論**：❌ 不建議。Docker 強依賴 + MongoDB 需求直接違反 C1 準則。
---
### 4.5 OpenClaw（340k ⭐）
**定位**：多頻道個人 AI 助手
| 準則 | 評分 | 說明 |
|------|------|------|
| C1 Docker | ⚠️ | 可裸機安裝但建議 Docker |
| C2 Windows | ❌ | **僅支援 WSL2**，不原生 Windows |
| C3 llama.cpp | ❌ | 主要依賴雲端 LLM API，無原生本地模型支援 |
| C4 RAG/MCP/Skills | ⚠️ | Skills 平台強大；MCP 有限；RAG 非核心 |
| C5 低資源 | ❌ | Node.js 22+，大型專案、多模組 |
| C6 組織可靠度 | ✅ | ClawLabs，大型社群（1,385 contributors） |
| C7 商業化風險 | ✅ | MIT |
| C8 Agent 能力 | ✅ | 瀏覽器控制、多 agent 路由 |
| C9 向量 DB 外掛 | ❌ | 非 RAG 導向 |
| C10 Skills 外掛 | ✅ | ClawHub 技能市集 + 自定義技能 |
| C11 無前端 | ⚠️ | 多頻道（CLI/Telegram/Slack/WhatsApp） |
| C12 組合方案 | ⚠️ | Skills 系統可重用 |
| C13 低維護 | ❌ | 複雜架構、高維護成本 |
| C14 技術棧獨立 | ❌ | 依賴雲端 LLM |
**結論**：❌ 不建議。WSL2 限制 + 無本地 LLM 支援 + 非 RAG 導向，與 SA 需求不匹配。
---
### 4.6 Nanobot（36.9k ⭐）
**定位**：超輕量級 Python AI Agent（HKUDS 學術團隊）
| 準則 | 評分 | 說明 |
|------|------|------|
| C1 Docker | ✅ | 純 Python，pip install 即可 |
| C2 Windows | ✅ | Python 跨平台，Windows 原生 |
| C3 llama.cpp | ✅ | 支援 Ollama/vLLM/任何 OpenAI-compatible API |
| C4 RAG/MCP/Skills | ✅ | **MCP 支援**（相容 Claude Desktop/Cursor 設定格式）、Skills、Web 搜尋 |
| C5 低資源 | ✅ | 極輕量，Python 單一套件 |
| C6 組織可靠度 | ⚠️ | 學術團隊（HKUDS），專案僅 ~1 個月，需觀察 |
| C7 商業化風險 | ✅ | MIT |
| C8 Agent 能力 | ✅ | **內建：bash 執行、檔案讀寫、檔案編輯、Web 搜尋** |
| C9 向量 DB 外掛 | ❌ | 無內建向量 DB 支援（無 RAG pipeline） |
| C10 Skills 外掛 | ✅ | Skills 系統，可自訂工具 |
| C11 無前端 | ✅ | **CLI/終端機介面**，API 模式 |
| C12 組合方案 | ✅ | 可搭配外部 RAG 服務使用 |
| C13 低維護 | ✅ | 極簡設計，維護負擔低 |
| C14 技術棧獨立 | ✅ | 支援任何 OpenAI-compatible 端點 |
**可替代角色**：可替代 **Agent 框架層**（LangGraph + LangChain 部分），但需外掛 RAG。
**關鍵優勢**：極輕量、MCP 整合完善、內建檔案操作和 Shell 執行、Python 生態。
**關鍵風險**：專案極新（約 1 個月），長期穩定性未知；無內建 RAG。
**結論**：✅ **高度推薦作為 Agent 框架元件**。需搭配 RAG 解決方案（如 pgvector 直連或 Kotaemon）。
---
### 4.7 NanoClaw（25.9k ⭐）
**定位**：輕量級 OpenClaw 替代品
| 準則 | 評分 | 說明 |
|------|------|------|
| C1 Docker | ❌ | **需要 Docker 或 Apple Container** |
| C2 Windows | ⚠️ | 需 Docker Desktop |
| C3 llama.cpp | ❌ | **綁定 Claude Code CLI**，無法使用本地模型 |
| C4 RAG/MCP/Skills | ⚠️ | Skills 架構有，但 Claude 專屬 |
| C5 低資源 | ⚠️ | 容器化增加開銷 |
| C6 組織可靠度 | ⚠️ | 社群專案 |
| C7 商業化風險 | ✅ | MIT |
| C8 Agent 能力 | ⚠️ | 依賴 Claude Agent SDK |
| C9 向量 DB 外掛 | ❌ | 無 |
| C10 Skills 外掛 | ⚠️ | 有 Skills 但 Claude 綁定 |
| C11 無前端 | ✅ | CLI 模式 |
| C12 組合方案 | ❌ | Claude 鎖定，難以組合 |
| C13 低維護 | ⚠️ | 需管理容器 |
| C14 技術棧獨立 | ❌ | **完全綁定 Anthropic Claude** |
**結論**：❌ 不建議。完全綁定 Claude，無法在離線環境使用本地 LLM。
---
### 4.8 PicoClaw（26.7k ⭐）
**定位**：超高效 Go 語言 AI 助手（Sipeed 硬體公司）
| 準則 | 評分 | 說明 |
|------|------|------|
| C1 Docker | ✅ | **單一二進位檔**，無需 Docker |
| C2 Windows | ✅ | **原生 Windows 支援** |
| C3 llama.cpp | ✅ | 支援 Ollama/vLLM/30+ LLM 供應商 |
| C4 RAG/MCP/Skills | ✅ | **MCP 完整支援、Skills 系統、17+ 頻道** |
| C5 低資源 | ✅ | **<10MB RAM**，極致輕量 |
| C6 組織可靠度 | ⚠️ | Sipeed（硬體公司），專案僅 ~2 個月 |
| C7 商業化風險 | ✅ | MIT |
| C8 Agent 能力 | ✅ | 工具調用、多頻道互動 |
| C9 向量 DB 外掛 | ❌ | 無內建向量 DB |
| C10 Skills 外掛 | ✅ | Skills 外掛架構 |
| C11 無前端 | ⚠️ | 有 Web UI Launcher，但可 headless 運行 |
| C12 組合方案 | ✅ | 單一二進位，極易組合 |
| C13 低維護 | ✅ | 單一二進位 = 極低維護 |
| C14 技術棧獨立 | ✅ | 多 LLM 供應商支援 |
**可替代角色**：可替代 **Agent 框架層**，極致輕量。
**關鍵優勢**：<10MB RAM、單一二進位、Windows 原生、MCP/Skills 完備。
**關鍵風險**：專案極新（約 2 個月）；Go 生態不如 Python 成熟，自訂 MCP 工具可能需要額外 effort。無 RAG 內建。
**結論**：✅ **高度推薦作為 Agent 框架元件**。需搭配 RAG 解決方案。Go 的優勢是部署極簡（單一 exe），劣勢是擴展生態不如 Python。
---
### 4.9 IronClaw（11.1k ⭐）
**定位**：OpenClaw 的 Rust 重寫，安全優先（NEAR AI）
| 準則 | 評分 | 說明 |
|------|------|------|
| C1 Docker | ✅ | 有 Windows 安裝程式 + cargo build |
| C2 Windows | ✅ | **有 Windows Installer（MSI）** |
| C3 llama.cpp | ⚠️ | 透過 Ollama/OpenAI-compatible API；內建多 LLM 供應商 |
| C4 RAG/MCP/Skills | ✅ | **MCP 協定、WASM 工具外掛、混合搜尋（全文+向量, RRF）、Skills** |
| C5 低資源 | ⚠️ | Rust 原生效能好，但需 PostgreSQL + pgvector |
| C6 組織可靠度 | ✅ | NEAR AI（NEAR Protocol 生態系） |
| C7 商業化風險 | ✅ | MIT + Apache 2.0 雙授權 |
| C8 Agent 能力 | ✅ | 完整 Agent loop、job 排程、tool 調用 |
| C9 向量 DB 外掛 | ✅ | **使用 PostgreSQL + pgvector（與 SA 文件相同！）** |
| C10 Skills 外掛 | ✅ | **WASM sandbox 插件 + MCP server 外掛** |
| C11 無前端 | ✅ | **REPL CLI 模式 + Web Gateway 可選** |
| C12 組合方案 | ✅ | 架構清晰，元件可拆分 |
| C13 低維護 | ⚠️ | Rust 編譯、PostgreSQL 維護 |
| C14 技術棧獨立 | ✅ | 多 LLM 供應商 + OpenAI-compatible |
**可替代角色**：理論上可替代 **Backend + Agent + RAG + MCP 完整管線**。
**關鍵優勢**：
1. **與 SA 架構最匹配** — 同樣使用 PostgreSQL + pgvector
2. 混合搜尋（全文+向量 RRF）與 SA 的 RAG 設計一致
3. MCP 協定支援完整
4. WASM sandbox 提供安全的工具執行環境
5. Windows 原生安裝程式
6. Rust 原生效能，單一二進位
**關鍵風險**：
1. 專案相對年輕（~1 個月活躍）
2. Rust 生態的 LLM/AI 工具不如 Python 豐富
3. 需要 NEAR AI 帳號進行初始設定（可旁路）
4. 自訂 MCP 工具需要 WASM 或 Rust 開發能力
**結論**：✅ **最高推薦——最接近 SA 架構的現成方案**。
---
### 4.10 OpenWork（12.8k ⭐）
**定位**：Claude Cowork 開源替代品（Desktop App）
| 準則 | 評分 | 說明 |
|------|------|------|
| C1 Docker | ✅ | Tauri 桌面應用 |
| C2 Windows | ⚠️ | Tauri 理論支援 Windows，但 Linux/macOS 為主 |
| C3 llama.cpp | ❌ | 依賴 OpenCode CLI 作為後端，雲端 LLM 為主 |
| C4 RAG/MCP/Skills | ⚠️ | Skills manager、OpenCode plugins；MCP 有限 |
| C5 低資源 | ⚠️ | Tauri + Node.js + Rust + Bun 多工具鏈 |
| C6 組織可靠度 | ⚠️ | 小型團隊（50 contributors） |
| C7 商業化風險 | ✅ | MIT |
| C8 Agent 能力 | ✅ | 繼承 OpenCode 的完整能力 |
| C9 向量 DB 外掛 | ❌ | 非 RAG 導向 |
| C10 Skills 外掛 | ✅ | Skills + OpenCode plugins |
| C11 無前端 | ❌ | 核心是桌面 UI |
| C12 組合方案 | ⚠️ | 可作為 UI 層 |
| C13 低維護 | ⚠️ | 依賴鏈複雜（Tauri+Node+Bun+Rust） |
| C14 技術棧獨立 | ⚠️ | 依賴 OpenCode 生態 |
**結論**：❌ 不建議。Coding assistant 定位不匹配、依賴鏈過重、非 RAG 導向。
---
### 4.11 Cline（59.6k ⭐）
**定位**：VS Code 自主程式助手
| 準則 | 評分 | 說明 |
|------|------|------|
| C2 Windows | ✅ | VS Code Extension |
| C3 llama.cpp | ⚠️ | 透過 LM Studio/Ollama OpenAI-compatible API |
| C4 RAG/MCP/Skills | ⚠️ | **MCP 完整支援**；但無內建 RAG |
| C8 Agent 能力 | ✅ | 檔案讀寫、終端機、瀏覽器、MCP 工具 |
| C11 無前端 | ❌ | VS Code 專屬 |
**結論**：❌ 不適用。這是 VS Code 程式助手，非企業知識 Agent 框架。MCP 能力強但定位錯誤。
---
### 4.12 Aider（42.5k ⭐）
**定位**：終端機 AI 配對程設工具
| 準則 | 評分 | 說明 |
|------|------|------|
| C2 Windows | ✅ | Python，跨平台 |
| C3 llama.cpp | ⚠️ | 支援本地模型 via Ollama/LM Studio |
| C4 RAG/MCP/Skills | ❌ | 無 MCP、無 RAG、無 Skills |
| C8 Agent 能力 | ⚠️ | 程式碼編輯、Git 整合；非通用 Agent |
**結論**：❌ 不適用。純 coding 工具，無 RAG/MCP/Agent 能力。
---
### 4.13 OpenCode（132k ⭐）
**定位**：開源 coding agent（anomalyco）
| 準則 | 評分 | 說明 |
|------|------|------|
| C1 Docker | ✅ | TUI + Desktop app，原生安裝 |
| C2 Windows | ✅ | **Windows Desktop + Scoop/Choco 支援** |
| C3 llama.cpp | ⚠️ | 支援 local models，非原生 llama.cpp |
| C4 RAG/MCP/Skills | ⚠️ | 有 MCP 支援（.mcp.json）；無 RAG |
| C8 Agent 能力 | ✅ | read_file, write_file, edit_file, execute, sub-agents |
**結論**：❌ 不適用。Coding agent 定位，非企業知識 Agent。優秀但不匹配需求。
---
### 4.14 DeepAgents（18k ⭐）
**定位**：LangChain/LangGraph Agent Harness
| 準則 | 評分 | 說明 |
|------|------|------|
| C1 Docker | ✅ | pip install，純 Python |
| C2 Windows | ✅ | Python 跨平台 |
| C3 llama.cpp | ✅ | 透過 `init_chat_model` 支援任何 LLM，含本地 |
| C4 RAG/MCP/Skills | ✅ | **MCP 透過 langchain-mcp-adapters**（與 SA 完全相同！）、Planning、Sub-agents |
| C5 低資源 | ✅ | 輕量 Python 套件 |
| C6 組織可靠度 | ✅ | **LangChain 官方團隊** |
| C7 商業化風險 | ✅ | MIT |
| C8 Agent 能力 | ✅ | **read_file, write_file, edit_file, execute, task（sub-agents）** |
| C9 向量 DB 外掛 | ⚠️ | 需自建 RAG pipeline（可用 LangChain 整合 pgvector） |
| C10 Skills 外掛 | ✅ | 自訂 tools + MCP 工具 |
| C11 無前端 | ✅ | **Library / CLI，無強制 UI** |
| C12 組合方案 | ✅ | LangGraph 原生，可與任何 LangChain 元件組合 |
| C13 低維護 | ✅ | 精簡設計；返回 LangGraph graph，可用 LangGraph Studio 視覺化 |
| C14 技術棧獨立 | ✅ | 任何支援 tool calling 的 LLM |
**可替代角色**：可替代 **Agent 框架層**（LangGraph 狀態機部分），事實上與 SA 使用相同底層技術。
**關鍵優勢**：
1. **與 SA 技術棧完全一致** — LangGraph + LangChain + langchain-mcp-adapters
2. LangChain 官方維護，長期穩定
3. 內建 Planning（write_todos）、檔案操作、Shell 執行、Sub-agents
4. 開箱即用的 agent，同時高度可客製化
5. 可直接接上 SA 文件中的 pgvector RAG pipeline
**關鍵風險**：
1. 仍在快速開發中（alpha 階段）
2. 需要自行建構 RAG pipeline（但可直接用 LangChain 的 pgvector retriever）
**結論**：✅ **最高推薦——與 SA 技術棧完全相同的 Agent Harness**。
---
### 4.15 Kotaemon（25.2k ⭐）
**定位**：RAG 文件問答 UI（Cinnamon AI）
| 準則 | 評分 | 說明 |
|------|------|------|
| C1 Docker | ✅ | pip install 或 Docker 均可 |
| C2 Windows | ✅ | Python，有 Windows release .zip |
| C3 llama.cpp | ✅ | 支援 Ollama + llama-cpp-python |
| C4 RAG/MCP/Skills | ✅ | **完整 RAG（混合檢索+向量+重排）、MCP tools（最近新增）、GraphRAG** |
| C5 低資源 | ⚠️ | Python + Gradio，中等資源消耗 |
| C6 組織可靠度 | ✅ | Cinnamon AI（越南 AI 公司），穩定開發中 |
| C7 商業化風險 | ✅ | Apache 2.0 |
| C8 Agent 能力 | ⚠️ | ReAct/ReWOO agent reasoning；但非通用 Agent |
| C9 向量 DB 外掛 | ⚠️ | 內建多種向量 DB；但主要用 LanceDB/Chroma |
| C10 Skills 外掛 | ⚠️ | 可自訂 RAG pipeline |
| C11 無前端 | ❌ | Gradio Web UI 為核心 |
| C12 組合方案 | ✅ | RAG pipeline 部分可獨立使用 |
| C13 低維護 | ✅ | 使用者友善的 Web UI |
| C14 技術棧獨立 | ✅ | 多 LLM + 多向量 DB |
**可替代角色**：可替代 **RAG Pipeline + 文件管理** 部分。
**關鍵優勢**：
1. 專精 RAG，品質高（混合搜尋+重排）
2. 多模態文件解析（PDF、表格、圖片）
3. GraphRAG 支援
4. 最近新增 MCP tools 支援
5. 離線可用（配合 Ollama/llama-cpp-python）
**結論**：✅ **推薦作為 RAG 元件**。可替代 SA 中的文件匯入和 RAG 檢索部分。
---
### 4.16 Quivr（39.1k ⭐）
**定位**：RAG 函式庫
| 準則 | 評分 | 說明 |
|------|------|------|
| C1 Docker | ✅ | pip install，純 Python 函式庫 |
| C2 Windows | ✅ | Python 跨平台 |
| C3 llama.cpp | ⚠️ | 支援 Ollama |
| C4 RAG/MCP/Skills | ⚠️ | 專精 RAG；無 MCP、無 Skills |
| C5 低資源 | ✅ | 輕量函式庫 |
| C6 組織可靠度 | ⚠️ | QuivrHQ，YCombinator 支持；但**最後 commit 9 個月前** |
| C7 商業化風險 | ⚠️ | Apache 2.0 但含 Enterprise 條款 |
| C8 Agent 能力 | ❌ | 純 RAG 函式庫 |
| C9 向量 DB 外掛 | ✅ | PGVector、Faiss |
| C10 Skills 外掛 | ❌ | 無 |
| C11 無前端 | ✅ | 純函式庫，無 UI |
| C12 組合方案 | ✅ | 可嵌入任何 Python 專案 |
| C13 低維護 | ✅ | 函式庫模式 |
| C14 技術棧獨立 | ⚠️ | 支援多 LLM 但較有限 |
**結論**：⚠️ 可作為 RAG 元件備選，但**專案可能停滯**（9 個月無更新）。不如直接用 LangChain 的 pgvector retriever。
---
### 4.17 Onyx（20.1k ⭐）
**定位**：企業 AI 平台
| 準則 | 評分 | 說明 |
|------|------|------|
| C1 Docker | ❌ | **以 Docker/K8s 為主要部署方式** |
| C2 Windows | ⚠️ | Docker Desktop |
| C3 llama.cpp | ⚠️ | 支援 Ollama/vLLM |
| C4 RAG/MCP/Skills | ✅ | Agents、RAG、MCP、Web Search、Deep Research、40+ Connectors |
| C5 低資源 | ❌ | 企業級平台，多容器，資源需求高 |
| C6 組織可靠度 | ✅ | Onyx 公司，穩定 |
| C7 商業化風險 | ⚠️ | MIT(CE) + EE 商業版 |
| C8 Agent 能力 | ✅ | 完整 Agent + Code Interpreter |
| C9 向量 DB 外掛 | ✅ | 內建向量搜尋 |
| C10 Skills 外掛 | ✅ | Actions + MCP |
| C11 無前端 | ❌ | 重 Web UI |
| C12 組合方案 | ⚠️ | 整體式架構 |
| C13 低維護 | ⚠️ | Docker 管理 |
| C14 技術棧獨立 | ✅ | 多 LLM |
**結論**：❌ 不建議。功能強大但 Docker 強依賴 + 資源需求過高，不適合筆電離線部署。
---
### 4.18 AnythingLLM（57.1k ⭐）
**定位**：一站式 AI 應用（Mintplex Labs）
| 準則 | 評分 | 說明 |
|------|------|------|
| C1 Docker | ✅ | **有 Desktop 版（原生安裝）+ Bare Metal 部署文檔** |
| C2 Windows | ✅ | **原生 Windows Desktop 應用** |
| C3 llama.cpp | ✅ | **原生支援任何 llama.cpp 模型 + Ollama + LM Studio** |
| C4 RAG/MCP/Skills | ✅ | **完整 MCP、Custom AI Agents、No-code Agent builder、RAG pipeline** |
| C5 低資源 | ⚠️ | Desktop 版資源消耗中等（Node.js + 嵌入模型） |
| C6 組織可靠度 | ✅ | Mintplex Labs，活躍開發中（205 contributors） |
| C7 商業化風險 | ✅ | MIT |
| C8 Agent 能力 | ✅ | **Agents 可瀏覽網頁、執行工具** |
| C9 向量 DB 外掛 | ✅ | **LanceDB（默認）+ PGVector + Chroma + Qdrant + Milvus + Weaviate + Pinecone** |
| C10 Skills 外掛 | ✅ | **Intelligent Skill Selection、Custom Agent Skills、Filesystem Agent Skill** |
| C11 無前端 | ⚠️ | 有 UI 但也有 **Developer API** 可 headless 使用 |
| C12 組合方案 | ✅ | 可獨立部署或與其他系統整合 |
| C13 低維護 | ✅ | **No-code AI Agent builder**、GUI 管理所有設定 |
| C14 技術棧獨立 | ✅ | 支援 30+ LLM 供應商 + 9 種向量 DB |
**可替代角色**：可替代 **完整 Backend + Agent + RAG + MCP 管線**（甚至包含前端）。
**關鍵優勢**：
1. **All-in-one**：LLM 連接 + RAG + Agents + MCP + 向量 DB，一次搞定
2. **PGVector 支援**（與 SA 相容）
3. **llama.cpp 原生支援**（可直接載入 GGUF 模型）
4. **No-code Agent builder** — 極低維護成本
5. **Windows 原生桌面應用**
6. **Bare Metal 部署文檔** — 可不用 Docker
7. 內建嵌入模型（AnythingLLM Native Embedder）
8. 多使用者支援（Docker 版）
9. 文件解析 pipeline（PDF/TXT/DOCX）
10. Developer API 可供外部程式調用
**關鍵風險**：
1. Node.js/JavaScript 技術棧（非 SA 偏好的 Python）
2. 前端與後端耦合度較高
3. 自訂 MCP 工具需要 JavaScript 開發
4. Telemetry 需注意關閉（離線環境）
**結論**：✅ **最高推薦——最接近「開箱即用」的完整解決方案**。
---
### 4.19 Budibase（27.8k ⭐）
**結論**：❌ 完全不相關。通用低程式碼平台，與 AI Agent 無關。
### 4.20 LM Studio CLI（4.4k ⭐）
**結論**：❌ 不適用。僅為 LM Studio 桌面應用的 CLI 工具，無法獨立使用。
### 4.21 ZeroClaw
**結論**：❌ 倉庫 404，不存在。
---
## 5. 組合方案建議
### 方案 A：「IronClaw 全棧方案」（與 SA 架構最接近）
```
┌─────────────────────────────────────────┐
│ IronClaw (Rust 單一二進位) │
│ ┌─────────┐ ┌──────┐ ┌──────────────┐ │
│ │Agent Loop│ │ MCP │ │ WASM Sandbox │ │
│ │+ Router │ │Client│ │ (Skills) │ │
│ └────┬─────┘ └──┬───┘ └──────────────┘ │
│ │ │ │
│ ┌────┴──────────┴───────────────────┐ │
│ │ 混合搜尋 (全文 + 向量 RRF) │ │
│ └────────────────┬──────────────────┘ │
└───────────────────┼──────────────────────┘
│
┌──────────┴──────────┐
│ PostgreSQL + pgvector│ (SA Server 端)
└─────────────────────┘
```
| 優點 | 風險 |
|------|------|
| 與 SA DB 架構完全一致（PostgreSQL + pgvector） | 專案年輕，Rust 生態 AI 工具少 |
| 單一二進位部署，Windows 原生 | 需要 Rust/WASM 開發自訂工具 |
| WASM sandbox 安全執行環境 | NEAR AI 帳號需求需旁路 |
| MCP 完整支援 | Qwen2.5-VL 模型需確認 OpenAI-compatible API 相容性 |
**改造工作量**：中。需自訂 CAD MCP tools（WASM 或外部 MCP server）、設定 llama.cpp 為 LLM 後端。
---
### 方案 B：「DeepAgents + pgvector 方案」（與 SA 技術棧 100% 一致）
```
┌──────────────────────────────────────────────┐
│ Python Backend (FastAPI) │
│ ┌───────────────────┐ ┌──────────────────┐ │
│ │ DeepAgents │ │ 自建 RAG Pipeline│ │
│ │ (LangGraph Agent) │ │ (LangChain + │ │
│ │ + MCP adapters │ │ pgvector) │ │
│ └────────┬───────────┘ └───────┬──────────┘ │
│ │ │ │
│ ┌────────┴─────────────────────┴──────────┐ │
│ │ llama.cpp server (port 8080) │ │
│ │ Qwen2.5-VL + nomic-embed-text │ │
│ └──────────────────────────────────────────┘ │
└──────────────────────┬───────────────────────┘
│
┌──────────┴──────────┐
│ PostgreSQL + pgvector│
└─────────────────────┘
```
| 優點 | 風險 |
|------|------|
| **與 SA 技術棧 100% 相同**：LangGraph + LangChain + langchain-mcp-adapters | DeepAgents 仍在 alpha 階段 |
| Python 生態豐富，自訂工具容易 | 需要自建 RAG pipeline（但 SA 中本就需要） |
| LangChain 官方維護 | 比 SA 自建 Agent 少了一些控制 |
| 直接復用 SA 的 FastAPI server 和 llama.cpp 設定 | |
| 內建 Planning + Sub-agents + 檔案操作 | |
**改造工作量**：低。事實上這就是在 SA 的 Agent 層用 DeepAgents 替代手寫的 LangGraph agent，其餘架構完全保留。
---
### 方案 C：「AnythingLLM 開箱即用方案」（最低改造成本）
```
┌──────────────────────────────────────┐
│ AnythingLLM Desktop App │
│ ┌──────────┐ ┌────────┐ ┌────────┐ │
│ │ Agents │ │ RAG │ │ MCP │ │
│ │ (No-code) │ │Pipeline│ │ Tools │ │
│ └─────┬─────┘ └───┬────┘ └───┬────┘ │
│ │ │ │ │
│ ┌─────┴───────────┴──────────┴────┐ │
│ │ llama.cpp (內建或外接) │ │
│ │ Qwen2.5-VL + nomic-embed-text │ │
│ └─────────────────────────────────┘ │
└────────────────┬─────────────────────┘
│ (可選)
┌──────────┴──────────┐
│ PGVector (外部 DB) │
│ 或 LanceDB (內建) │
└─────────────────────┘
```
| 優點 | 風險 |
|------|------|
| **最低改造成本**：安裝即用 | 前端與後端耦合 |
| No-code Agent builder | JavaScript 技術棧，自訂深度受限 |
| Windows 原生桌面應用 | 前端 UI 可能不符合「無前端」偏好 |
| 支援 PGVector + llama.cpp | 離線帶 Node.js runtime |
| Developer API 可供外部系統調用 | Telemetry 需要關閉 |
| Bare Metal 部署文檔 | |
| 文件解析 pipeline 現成 | |
**改造工作量**：極低。安裝 Desktop 版 → 設定 llama.cpp/PGVector → 建 MCP 工具 → 完成。
---
### 方案 D：「Nanobot/PicoClaw + Kotaemon 組合方案」
```
┌──────────────────┐ ┌──────────────────────┐
│ Nanobot │ │ Kotaemon │
│ (Agent 框架) │◄──►│ (RAG 文件問答) │
│ MCP + Skills │ │ 混合搜尋 + 重排 │
│ + 檔案操作 │ │ 多模態文件解析 │
│ + Shell 執行 │ │ GraphRAG │
└────────┬─────────┘ └──────────┬───────────┘
│ │
┌────┴────┐ ┌─────┴─────┐
│llama.cpp│ │ 向量 DB │
│ server │ │(LanceDB / │
│(port │ │ pgvector) │
│ 8080) │ └───────────┘
└─────────┘
```
| 優點 | 風險 |
|------|------|
| 各元件極輕量 | 需要自行整合兩個系統 |
| Python 一致技術棧 | 兩個都是新專案 |
| Kotaemon 的 RAG 品質高 | 整合 MCP 到 Kotaemon 需要開發 |
| Nanobot 的 Agent 能力完整 | |
| 可替換 PicoClaw（Go）以獲得更輕量部署 | |
**改造工作量**：中高。需要在兩個系統之間建立 API bridge。
---
## 6. 最終推薦排序
### Tier 1：強烈推薦
| 排名 | 方案 | 適用情境 | 改造量 |
|------|------|---------|--------|
| 🥇 | **方案 B：DeepAgents + 自建 RAG** | 想保持 SA 原有技術棧，最小改造 | 低 |
| 🥈 | **方案 C：AnythingLLM** | 想要最快上線、最低維護成本 | 極低 |
| 🥉 | **方案 A：IronClaw** | 想要最匹配的架構 + 高安全性 | 中 |
### Tier 2：值得考慮
| 排名 | 方案 | 適用情境 | 改造量 |
|------|------|---------|--------|
| 4 | Nanobot（單獨） | 輕量 Agent，自行搭配 RAG | 中 |
| 5 | PicoClaw（單獨） | 極致輕量，單一 exe 部署 | 中 |
| 6 | Kotaemon（單獨） | 僅需 RAG 文件問答，不需完整 Agent | 低 |
| 7 | Jan | 僅需替換 LLM runtime + 基本 MCP | 低 |
### Tier 3：不建議
| 專案 | 排除原因 |
|------|---------|
| Langflow | 資源消耗高、離線打包困難 |
| LibreChat | Docker 強依賴 + MongoDB |
| Onyx | Docker/K8s 強依賴、資源需求高 |
| OpenClaw | WSL2 only + 無本地 LLM |
| NanoClaw | Claude 鎖定 |
| Cline / Aider / OpenCode / OpenWork | Coding agent 定位不匹配 |
| Budibase | 與 AI Agent 無關 |
| GPT4All | 功能不足 + 潛在停滯 |
| Quivr | 9 個月無更新 |
| ZeroClaw | 404 不存在 |
| LM Studio CLI | LM Studio 專屬 |
---
## 7. 結論
### 最佳建議路徑
#### 🏆 如果要「最小改動 SA 架構」→ 方案 B：DeepAgents
- 理由：DeepAgents 就是 LangGraph Agent 的封裝，與 SA 文件使用完全相同的底層（LangGraph + LangChain + langchain-mcp-adapters）。實際上只是把 SA 中手寫的 Agent loop 替換為 DeepAgents 提供的現成版本，其餘架構（FastAPI, llama.cpp, pgvector, MCP）完全不動。
- **技術投入**：修改 Agent 層代碼，其餘保留。
#### 🏆 如果要「最快上線」→ 方案 C：AnythingLLM
- 理由：開箱即用的 All-in-one 方案：Windows 桌面應用 → 設定 llama.cpp 模型 → 連接 PGVector → 設定 MCP → 建立 Agent。No-code Agent builder 使非開發人員也能維護。
- **技術投入**：撰寫 MCP tool server（CAD 相關），其餘 AnythingLLM 已內建。
#### 🏆 如果要「最高安全性 + 最匹配架構」→ 方案 A：IronClaw
- 理由：Rust 原生效能 + WASM 安全沙箱 + PostgreSQL/pgvector + MCP + 混合搜尋，架構上與 SA 最匹配。適合對安全性有較高要求的場景。
- **技術投入**：WASM/MCP 工具開發、Rust 環境設定。
### 不可替代的 SA 元件
無論選擇哪個方案，以下元件都需要**自行開發或保留**：
1. **CAD 工具 MCP Server**（port 8100）— BOM 查詢、公差查詢、材料推薦、圖面檢查是業務專屬邏輯
2. **llama.cpp server** — 作為 LLM runtime 提供 Qwen2.5-VL 推理（除非改用 Ollama）
3. **PostgreSQL + pgvector server 端** — 向量資料庫基礎設施
4. **離線部署腳本** — USB 安裝、NSSM 服務管理等 Windows 特定配置
---
*報告產生日期：2026-03-30*
*評估基準：SA 文件 AI_Agent系統_SA文件.md*
---
---
## 附錄 A：IronClaw 連接遠端 PostgreSQL/pgvector 配置指南
### A.1 遠端伺服器端（整合部專用伺服器）
#### 1. 確認 pgvector 已安裝
```bash
sudo apt install postgresql-16-pgvector # Debian/Ubuntu
```
#### 2. 建立 IronClaw 專用資料庫與使用者
```sql
CREATE USER ironclaw_user WITH PASSWORD '你的強密碼';
CREATE DATABASE ironclaw OWNER ironclaw_user;
\c ironclaw
CREATE EXTENSION IF NOT EXISTS vector;
```
> **注意**：SA 既有的 PostgreSQL 伺服器可以直接複用，只需額外建一個 `ironclaw` 資料庫即可，不需要另外架設 PostgreSQL 實例。
#### 3. 設定遠端存取權限
**`postgresql.conf`**（允許監聽網路）：
```conf
listen_addresses = '*' # 或限定為內網網段 '192.168.x.x'
```
**`pg_hba.conf`**（允許 IronClaw 客戶端 IP 連入）：
```conf
# TYPE DATABASE USER ADDRESS METHOD
host ironclaw ironclaw_user 192.168.x.0/24 scram-sha-256
```
> 將 `192.168.x.0/24` 替換為客戶端筆電實際所在的內網網段。
```bash
sudo systemctl reload postgresql
```
#### 4. 確認防火牆開放 5432 port
```bash
sudo ufw allow from 192.168.x.0/24 to any port 5432
```
### A.2 客戶端（Windows 11 筆電 — IronClaw）
#### 1. 修改 `~/.ironclaw/.env`
IronClaw 的資料庫連線完全由 `DATABASE_URL` 環境變數控制（預設是 `postgres://localhost/ironclaw`）。改為指向遠端伺服器：
```env
DATABASE_URL=postgres://ironclaw_user:你的強密碼@192.168.x.x:5432/ironclaw
DATABASE_POOL_SIZE=5
```
| 參數 | 說明 |
|------|------|
| `ironclaw_user` | 遠端 PostgreSQL 的使用者名稱 |
| `你的強密碼` | 該使用者的密碼 |
| `192.168.x.x` | 遠端伺服器的內網 IP |
| `5432` | PostgreSQL 預設 port |
| `ironclaw` | 資料庫名稱 |
| `DATABASE_POOL_SIZE` | 連線池大小，遠端建議降為 5（預設 10） |
#### 2. 或使用互動式設定精靈
```bash
ironclaw onboard
```
在精靈中輸入遠端的 `DATABASE_URL`，效果相同。
#### 3. 首次啟動自動遷移
IronClaw 啟動時會自動執行 **14 個 migration 檔案**（V1~V14），包括：
- **V1** — 建立 `conversations`、`messages`、`memory_documents`、`memory_chunks`（含 `VECTOR(1536)` 和 HNSW 索引）等完整 schema
- **V9** — `flexible_embedding_dimension.sql`：將 `embedding` 欄位從固定 1536 維改為**任意維度**，並移除 HNSW 索引（改用精確搜尋，對個人助理等級的資料量影響可忽略）
- **V14** — `users` 表（DB-backed 使用者管理）
> **V9 的註解明確寫道**："This supports Ollama models (768-dim nomic-embed-text, 1024-dim mxbai-embed-large)"，這完全匹配 SA 指定的 **nomic-embed-text（768 維）**。
### A.3 搭配 SA 的 LLM 配置
在同一個 `.env` 檔案中，將 LLM 指向本地或伺服器上的 llama.cpp：
```env
LLM_BACKEND=openai_compatible
LLM_BASE_URL=http://192.168.x.x:8080/v1
LLM_MODEL=qwen2.5-vl
```
### A.4 架構對照
```
┌─────────────────────────┐ LAN ┌─────────────────────────────┐
│ Windows 11 筆電 (客戶端) │ ◄──────────────────► │ 整合部專用伺服器 │
│ │ │ │
│ IronClaw Agent │ DATABASE_URL ──────► │ PostgreSQL 16 + pgvector │
│ (.ironclaw/.env) │ :5432 │ DB: ironclaw │
│ │ │ │
│ │ LLM_BASE_URL ──────► │ llama.cpp / Ollama │
│ │ :8080/v1 │ (Qwen2.5-VL + nomic-embed) │
└─────────────────────────┘ └─────────────────────────────┘
```
> **結論**：IronClaw **不需要任何程式碼修改**，只需將 `DATABASE_URL` 從 `localhost` 改為遠端伺服器 IP 即可。SA 的客戶端-伺服器分離架構完全可以保持不變。
---
## 附錄 B：IronClaw pgvector 用途分析 — 記憶 vs. 知識庫
### B.1 IronClaw 的用法：Agent 記憶（Memory Workspace）
從 V1 migration 的 schema 可見：
| 表名 | 用途 |
|------|------|
| `memory_documents` | Agent **自己**建立的筆記、工作文件（路徑如 `context/vision.md`） |
| `memory_chunks` | 上述文件的分塊 + 向量，供 Agent 回顧自己的記憶 |
特徵：
- Agent 自己寫入、自己讀取（個人助理的「記事本」）
- **沒有**批次文件匯入管線
- **沒有** PDF/Word/圖片解析
- **沒有**文件狀態追蹤（`pending` → `processing` → `completed`）
- **沒有** `page_number`、`chunk_type`、來源引用等 metadata
### B.2 SA 的設計：企業知識庫（Knowledge Base for RAG）
| 表名 | 用途 |
|------|------|
| `documents` | 管理員匯入的企業技術文件元資料（PDF、Word、Markdown） |
| `document_chunks` | 文件切分後的段落 + 768 維向量，供 RAG 檢索回答使用者問題 |
| `batch_jobs` | 批次匯入任務狀態追蹤 |
特徵：
- 由獨立的 `document_import.py` 排程執行寫入
- 支援 PDF（pymupdf4llm）、Word（python-docx）、OCR（Tesseract）
- 有 Reranker、Context 壓縮、Self-RAG 等多層檢索策略
- 回答附帶**引用來源**（文件名稱、頁碼）
### B.3 結論：IronClaw 原生不具備 SA 要求的知識庫功能
| 維度 | IronClaw Memory | SA 知識庫 |
|------|-----------------|-----------|
| **資料來源** | Agent 自己產生的筆記 | 管理員批次匯入的企業文件 |
| **寫入方** | Agent 自動寫入 | `document_import.py` 排程寫入 |
| **文件解析** | 無（純文字） | PDF、Word、圖片 OCR |
| **檢索目的** | Agent 回顧自己的上下文 | 使用者問答時的 RAG 知識來源 |
| **引用來源** | 無 | 文件名稱 + 頁碼 |
| **Reranker** | 無（RRF 混合排序） | Cross-encoder 語意重排 |
### B.4 可行路徑：透過 MCP 擴展
最務實的做法是利用 IronClaw 的 MCP 擴展能力：
```
IronClaw ──MCP──► 自建 Knowledge Base MCP Server ──► PostgreSQL (document_chunks)
├─ tool: kb_search(query) → 向量檢索 + Reranker
├─ tool: kb_import(path) → 批次匯入觸發
└─ tool: kb_status() → 匯入狀態查詢
```
IronClaw 的 `memory_*` 表繼續作為 Agent 記憶使用，而知識庫功能透過 MCP Tool 橋接到 SA 規格的 `documents` / `document_chunks` 表。文件匯入管線（Python）仍需按 SA 規格獨立開發。
> **簡而言之**：IronClaw 的 pgvector 確實是給「記憶」用的，不是「知識庫」。要當知識庫用，需要自建文件匯入管線 + MCP Tool 橋接層。
---
## 附錄 C：組合方案可行性深入分析
### C.1 IronClaw + Quivr 組合 — ❌ 不推薦
#### 問題分析
| 問題 | 嚴重度 | 說明 |
|------|--------|------|
| **跨語言整合** | 🔴 高 | IronClaw（Rust）+ Quivr（Python），需 HTTP/MCP 橋接，同時維護兩套技術棧 |
| **Quivr 活躍度堪慮** | 🔴 高 | 最後 commit 2025-06-19（距今 ~9 個月），core 仍是 v0.0.33 |
| **Reranker 依賴雲端** | 🔴 高 | 預設 Cohere API，離線環境無法使用，需改寫原始碼 |
| **Schema 不匹配** | 🟡 中 | Quivr 用 `Brain` 抽象層，非 SA 的 `documents`/`document_chunks`/`batch_jobs` |
| **Enterprise 授權** | 🟡 中 | LICENSE 含 Enterprise Features 條款 |
| **無批次匯入** | 🟡 中 | Quivr 為互動式問答設計，SA 需排程批次匯入 |
#### Quivr Reranker 離線問題
```yaml
# Quivr 的 workflow 配置
reranker_config:
supplier: "cohere" # ← 需要連雲端
model: "rerank-multilingual-v3.0" # ← Cohere API
top_n: 5
```
> 要在離線環境使用，必須改寫 Quivr 原始碼換成本地 cross-encoder。
#### 較佳替代：IronClaw + Kotaemon
| 維度 | Quivr | Kotaemon |
|------|-------|----------|
| 最後活動 | 9 個月前 | **持續活躍** |
| 離線 Reranker | ❌ 預設 Cohere | ✅ 支援本地 cross-encoder |
| 多模態文件解析 | 基本 | ✅ PDF/表格/圖片 |
| GraphRAG | ❌ | ✅ |
| MCP 支援 | ❌ | ✅ 最近新增 |
| 混合搜尋 | 有 | ✅ 向量 + 全文 + 重排 |
| 授權 | Apache 2.0 + Enterprise 條款 | **純 Apache 2.0** |
---
### C.2 Nanobot + Quivr 組合 — ⚠️ 不建議
#### 優勢
| 項目 | 說明 |
|------|------|
| **同語言** | 都是 Python，可直接 `import` 整合 |
| **都輕量** | Nanobot 極簡 + Quivr 是 `pip install` 的函式庫 |
| **互補性好** | Nanobot 有 Agent/MCP/Skills、Quivr 有 RAG pipeline |
#### 問題
| 問題 | 嚴重度 | 說明 |
|------|--------|------|
| **Quivr 停滯** | 🔴 高 | 最後 commit 2025-06-19，core 仍 v0.0.33 |
| **Reranker 依賴雲端** | 🔴 高 | 預設 Cohere API，離線無法使用 |
| **Schema 不匹配** | 🟡 中 | Quivr 的 `Brain` 抽象非 SA 的 `documents`/`document_chunks` |
| **Nanobot 極新** | 🟡 中 | 專案僅約 1 個月歷史 |
| **Enterprise 授權** | 🟡 中 | Quivr LICENSE 含企業限制 |
| **無批次匯入** | 🟡 中 | SA 需排程批次匯入，Quivr 不支援 |
#### 成本分析：Quivr 省下的 vs 額外付出的
**Quivr 幫你省的**：RAG pipeline 的基本框架（chunking、embedding、retrieval）
**Quivr 讓你多做的**：
1. 改寫 Reranker 模組以支援離線
2. 適配 `Brain` 抽象到 SA schema
3. 自建批次匯入（Quivr 不支援）
4. 處理 Megaparse 依賴（SA 用 pymupdf4llm）
5. 承擔停滯專案的維護風險
**結論：額外付出 > 省下的工作**。若偏好 Nanobot，應搭配自建 RAG 而非 Quivr。
---
### C.3 各組合方案對比總表
| 維度 | IronClaw + Quivr | Nanobot + Quivr | Nanobot + 自建 RAG | DeepAgents + 自建 RAG |
|------|-----------------|-----------------|-------------------|---------------------|
| 技術棧 | ❌ Rust + Python | ✅ 全 Python | ✅ 全 Python | ✅ 全 Python |
| RAG 品質 | ⚠️ Quivr 通用 | ⚠️ Quivr 通用 | ✅ 按 SA 規格 | ✅ 按 SA 規格 |
| 離線 Reranker | ❌ 需改寫 | ❌ 需改寫 | ✅ 直接用本地模型 | ✅ 直接用本地模型 |
| Schema 匹配 | ❌ 需適配 | ❌ 需適配 | ✅ SA 原生 | ✅ SA 原生 |
| 批次匯入 | ❌ 需自建 | ❌ 需自建 | ✅ 自建 | ✅ 自建 |
| MCP 支援 | ✅ IronClaw 原生 | ✅ Nanobot 原生 | ✅ Nanobot 原生 | ✅ langchain-mcp-adapters |
| Agent 成熟度 | ✅ NEAR AI | ⚠️ 極新 | ⚠️ 極新 | ✅ LangChain 官方 |
| 第三方風險 | 🔴 Quivr 停滯 | 🔴 Quivr 停滯 | ✅ 無第三方 RAG | ✅ 無第三方 RAG |
| 維護成本 | 🔴 兩語言兩依賴 | 🟡 兩個依賴 | ✅ 一個依賴 | ✅ 一個依賴 |
---
## 附錄 D：SA 自建系統成本與維護性評估
### D.1 開發範圍拆解
| 模組 | 涉及技術 | 複雜度 |
|------|---------|--------|
| FastAPI 後端骨架 | Python/FastAPI/Uvicorn | 低 |
| LangGraph Agent 狀態機 | LangGraph/LangChain | 🔴 高 |
| RAG Pipeline | pgvector/LangChain | 🟡 中 |
| 文件匯入管線 | pymupdf4llm/python-docx/Tesseract | 🟡 中 |
| MCP Server（CAD 工具） | mcp SDK + JSON 資料庫 | 🟡 中 |
| MCP Client 整合 | langchain-mcp-adapters | 低 |
| 意圖分類路由 | LangGraph conditional edges | 🟡 中 |
| Reranker + Context 壓縮 | sentence-transformers/cross-encoder | 🟡 中 |
| Self-RAG | LangGraph loop | 🔴 高 |
| 視覺分析（Qwen2.5-VL） | llama.cpp multimodal | 🟡 中 |
| Context 管理 + Token 預算 | LangGraph | 🟡 中 |
| SQLite 本機快取 | SQLAlchemy/aiosqlite | 低 |
| React 前端（3 頁面） | React/TypeScript/Vite/TailwindCSS | 🟡 中 |
| SSE 串流 | FastAPI StreamingResponse | 低 |
| 稽核日誌 | SQLite + middleware | 低 |
| Windows 部署腳本 | PowerShell/NSSM | 低 |
| TLS + 備份策略 | 內部 CA/pg_dump | 低 |
### D.2 開發時程與人力估算
SA 規劃的時程為 **18 週**（M1-M5），最少人力為 **1 名具 LangChain/LangGraph + Python 全端經驗的開發者全職投入**。
| 里程碑 | 週次 | 核心產出 | 人力 |
|--------|------|---------|------|
| M1 環境就緒 | W0-W2 | llama.cpp + PostgreSQL + 基礎問答 API | 1 全端 |
| M2 RAG 可用 | W3-W6 | 文件匯入 + 向量化 + OCR + RAG 問答 | 1 全端 |
| M3 Agent 完整 | W7-W10 | MCP 整合 + 意圖路由 + Reranker | 1 全端 + 0.5 CAD 領域專家 |
| M4 前端完整 | W11-W14 | React UI + 多模態 + Self-RAG | 1 全端 |
| M5 部署 | W15-W18 | 安全/備份/測試/部署腳本 | 1 全端 |
#### 預估代碼量
| 模組 | 估算行數 |
|------|---------|
| 後端 Python（Agent + RAG + API + MCP） | ~3,000-4,000 行 |
| 前端 TypeScript/React | ~2,000-2,500 行 |
| SQL Schema + Migration | ~200 行 |
| 部署腳本 | ~300 行 |
| **合計** | **~6,000-7,000 行** |
### D.3 長期維護成本
| 維護項目 | 頻率 | 工作量 | 說明 |
|---------|------|--------|------|
| LLM 模型更新 | 每季 | 低 | 替換 GGUF 檔案，測試相容性 |
| Python 依賴更新 | 每月 | 低-中 | LangChain/LangGraph 更新頻繁，可能有 breaking changes |
| CAD 指令資料庫維護 | 按需 | 低 | 新增 SolidWorks/CATIA 版本指令 |
| 知識庫文件匯入 | 每日/每週 | 極低 | 排程自動執行 |
| pgvector 維護 | 每季 | 低 | VACUUM、索引重建 |
| Bug 修復 + 使用者回饋 | 持續 | 中 | 調整 prompt、RAG 參數、Agent 行為 |
| **LangChain 生態追蹤** | **持續** | **🔴 高** | **LangChain 約每 2-4 週一大版本，API 經常變動** |
> **最大維護風險**：SA 依賴了 `langchain`、`langchain-community`、`langchain-postgres`、`langchain-mcp-adapters`、`langgraph` 至少 5 個 LangChain 系套件，版本鎖定後不更新則會落後，更新則需要持續適配。
### D.4 減少成本的替代策略
#### 策略 A：SA 全自建（基準線）
| 項目 | 值 |
|------|-----|
| 開發時程 | 18 週 |
| 人力 | 1 全端（需精通 LangChain/LangGraph） |
| 維護成本 | 中-高（LangChain 生態追蹤） |
| 風險 | LangChain breaking changes、Agent 調優耗時 |
| 優勢 | 完全掌控、完全匹配需求 |
#### 策略 B：用 DeepAgents 替代手寫 Agent（推薦降本）
省掉 LangGraph 狀態機手寫（`graph.py`, `nodes.py`, `state.py`）、意圖路由、MCP 整合。保留自建 RAG pipeline、文件匯入、CAD MCP Server、前端。
| 項目 | 值 |
|------|-----|
| 開發時程 | **12-14 週**（省 ~4 週 Agent 開發 + 調優） |
| 省掉代碼 | ~800-1,200 行 Agent 狀態機代碼 |
| 維護成本 | 中（DeepAgents 由 LangChain 官方維護） |
| 風險 | DeepAgents 仍在 alpha；底層是 LangGraph，必要時可 fork |
#### 策略 C：用 AnythingLLM 替代全部後端（最大降本）
省掉 FastAPI、Agent 框架、RAG pipeline、文件匯入、前端（全部）。僅保留自建 CAD MCP Server。
| 項目 | 值 |
|------|-----|
| 開發時程 | **4-6 週** |
| 省掉代碼 | ~5,000+ 行 |
| 維護成本 | **低**（No-code Agent builder、GUI 管理） |
| 風險 | 無法精細控制 RAG 策略（無 Self-RAG、無 Reranker） |
| 代價 | 需降低 SA 規格（放棄 Self-RAG、Cross-encoder、GraphRAG） |
#### 策略 D：分階段交付 + 漸進式增強（⭐ 最務實）
先用最少成本上線能用版本，再根據實際使用回饋決定是否需要進階功能。
```
Phase 1（4-6 週）: "能用版"
├── AnythingLLM Desktop（Agent + RAG + UI）
├── 連接 llama.cpp（Qwen2.5-VL）
├── 連接 pgvector（知識庫）
└── 自建 CAD MCP Server（最小可行版）
↓ 上線使用、收集回饋
Phase 2（選擇性，4-6 週）: "好用版"
├── 如果 RAG 品質不夠 → 加 Reranker + Context 壓縮
├── 如果需要精細控制 → 遷移到 DeepAgents + 自建 RAG
├── 如果需要批次匯入 → 建 document_import.py
└── 如果需要稽核日誌 → 加審計中間件
↓ 根據實際需求
Phase 3（選擇性，4-6 週）: "完整版"
├── Self-RAG、GraphRAG（如果真的需要）
├── React 自訂前端（如果 AnythingLLM UI 不夠用）
└── TLS、備份、Windows 服務化
```
### D.5 成本對比總覽
| 策略 | 開發時程 | 自建代碼量 | 維護成本 | RAG 品質 | 可控性 |
|------|---------|-----------|---------|---------|--------|
| A: SA 全自建 | 18 週 | ~7,000 行 | 🔴 高 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| B: DeepAgents + 自建 RAG | 12-14 週 | ~5,000 行 | 🟡 中 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| C: AnythingLLM + MCP only | 4-6 週 | ~500 行 | 🟢 低 | ⭐⭐⭐ | ⭐⭐ |
| **D: 分階段（推薦）** | **4→18 週** | **500→7,000 行** | **🟢→🔴** | **⭐⭐⭐→⭐⭐⭐⭐⭐** | **⭐⭐→⭐⭐⭐⭐⭐** |
### D.6 SA 文件「過度設計」風險提示
SA 文件設計完整，但以下功能在初版可能非必要：
1. **Self-RAG**（Agent 自我評估檢索品質）— 在「CAD 指令查詢」這種相對結構化的場景，基本 RAG + Reranker 通常已足夠
2. **GraphRAG**（知識圖譜 + 多跳推理）— SA 已標註為「進階，選用」，初版應跳過
3. **Cross-encoder Reranker** — 有用，但初版可先用 RRF（向量 + 全文混合排序）替代
4. **Context 壓縮** — 如果 token 預算足夠（Qwen2.5-VL 128K context），初版不需要
> **建議**：SA 文件可作為**最終目標藍圖**，而非第一天就要全部實現的規格。策略 D 的分階段交付路線最能平衡成本與品質。
*報告產生日期：2026-03-30*
*評估基準：SA 文件 AI_Agent系統_SA文件.md*
IronClaw 連接遠端 PostgreSQL/pgvector 配置指南
一、遠端伺服器端（整合部專用伺服器）
1. 確認 pgvector 已安裝
2. 建立 IronClaw 專用資料庫與使用者
注意：SA 既有的 PostgreSQL 伺服器可以直接複用，只需額外建一個 ironclaw 資料庫即可，不需要另外架設 PostgreSQL 實例。
3. 設定遠端存取權限
postgresql.conf（允許監聽網路）：
pg_hba.conf（允許 IronClaw 客戶端 IP 連入）：
將 192.168.x.0/24 替換為客戶端筆電實際所在的內網網段。
4. 確認防火牆開放 5432 port
二、客戶端（Windows 11 筆電 — IronClaw）
1. 修改 ~/.ironclaw/.env
IronClaw 的資料庫連線完全由 DATABASE_URL 環境變數控制（預設是 postgres://localhost/ironclaw）。改為指向遠端伺服器：
參數 說明
ironclaw_user 遠端 PostgreSQL 的使用者名稱
你的強密碼 該使用者的密碼
192.168.x.x 遠端伺服器的內網 IP
5432 PostgreSQL 預設 port
ironclaw 資料庫名稱
DATABASE_POOL_SIZE 連線池大小，遠端建議降為 5（預設 10）
2. 或使用互動式設定精靈
在精靈中輸入遠端的 DATABASE_URL，效果相同。
3. 首次啟動自動遷移
IronClaw 啟動時會自動執行 14 個 migration 檔案（V1~V14），包括：
V1 — 建立 conversations、messages、memory_documents、memory_chunks（含 VECTOR(1536) 和 HNSW 索引）等完整 schema
V9 — flexible_embedding_dimension.sql：將 embedding 欄位從固定 1536 維改為任意維度，並移除 HNSW 索引（改用精確搜尋，對個人助理等級的資料量影響可忽略）
V14 — users 表（DB-backed 使用者管理）
V9 的註解明確寫道："This supports Ollama models (768-dim nomic-embed-text, 1024-dim mxbai-embed-large)"，這完全匹配 SA 指定的 nomic-embed-text（768 維）。
三、搭配 SA 的 LLM 配置
在同一個 .env 檔案中，將 LLM 指向本地或伺服器上的 llama.cpp：
四、架構對照
┌─────────────────────────┐ LAN ┌─────────────────────────────┐
│ Windows 11 筆電 (客戶端) │ ◄──────────────────► │ 整合部專用伺服器 │
│ │ │ │
│ IronClaw Agent │ DATABASE_URL ──────► │ PostgreSQL 16 + pgvector │
│ (.ironclaw/.env) │ :5432 │ DB: ironclaw │
│ │ │ │
│ │ LLM_BASE_URL ──────► │ llama.cpp / Ollama │
│ │ :8080/v1 │ (Qwen2.5-VL + nomic-embed) │
└─────────────────────────┘ └─────────────────────────────┘
結論：IronClaw 不需要任何程式碼修改，只需將 DATABASE_URL 從 localhost 改為遠端伺服器 IP 即可。SA 的客戶端-伺服器分離架構完全可以保持不變。
Claude Opus 4.6 • 3x
IronClaw 的 pgvector ≠ SA 的知識庫
IronClaw 的用法：Agent 記憶（Memory Workspace）
從 V1 migration 的 schema 可見：
表名 用途
memory_documents Agent 自己建立的筆記、工作文件（路徑如 context/vision.md）
memory_chunks 上述文件的分塊 + 向量，供 Agent 回顧自己的記憶
特徵：
Agent 自己寫入、自己讀取（個人助理的「記事本」）
沒有批次文件匯入管線
沒有PDF/Word/圖片解析
沒有文件狀態追蹤（pending → processing → completed）
沒有 page_number、chunk_type、來源引用等 metadata
SA 的設計：企業知識庫（Knowledge Base for RAG）
表名 用途
documents 管理員匯入的企業技術文件元資料（PDF、Word、Markdown）
document_chunks 文件切分後的段落 + 768 維向量，供 RAG 檢索回答使用者問題
batch_jobs 批次匯入任務狀態追蹤
特徵：
由獨立的 document_import.py 排程執行寫入
支援 PDF（pymupdf4llm）、Word（python-docx）、OCR（Tesseract）
有 Reranker、Context 壓縮、Self-RAG 等多層檢索策略
回答附帶引用來源（文件名稱、頁碼）
結論：IronClaw 原生不具備 SA 要求的知識庫功能
這兩者的本質差異：
維度 IronClaw Memory SA 知識庫
資料來源 Agent 自己產生的筆記 管理員批次匯入的企業文件
寫入方 Agent 自動寫入 document_import.py 排程寫入
文件解析 無（純文字） PDF、Word、圖片 OCR
檢索目的 Agent 回顧自己的上下文 使用者問答時的 RAG 知識來源
引用來源 無 文件名稱 + 頁碼
Reranker 無（RRF 混合排序） Cross-encoder 語意重排
要讓 IronClaw 滿足 SA 的知識庫需求，需要額外開發：
文件匯入管線（document_import.py 等價物）— 解析 PDF/Word/圖片、切分、向量化、寫入 pgvector
知識庫專用 schema（documents、document_chunks、batch_jobs）— 可建在同一個 PostgreSQL 但需獨立於 IronClaw 的 memory_* 表
RAG 檢索 MCP Tool— 撰寫一個 MCP Server，讓 IronClaw 透過 MCP 協議查詢知識庫（IronClaw 原生支援 MCP）
Reranker + 引用來源— SA 要求的 Cross-encoder 重排和來源標注
可行路徑
最務實的做法是利用 IronClaw 的 MCP 擴展能力：
IronClaw ──MCP──► 自建 Knowledge Base MCP Server ──► PostgreSQL (document_chunks)
├─ tool: kb_search(query) → 向量檢索 + Reranker
├─ tool: kb_import(path) → 批次匯入觸發
└─ tool: kb_status() → 匯入狀態查詢
這樣 IronClaw 的 memory_* 表繼續作為 Agent 記憶使用，而知識庫功能透過 MCP Tool 橋接到 SA 規格的 documents / document_chunks 表。文件匯入管線（Python）仍需按 SA 規格獨立開發。
簡而言之：IronClaw 的 pgvector 確實是給「記憶」用的，不是「知識庫」。要當知識庫用，需要自建文件匯入管線 + MCP Tool 橋接層。IronClaw 提供的價值是 Agent 框架 + MCP 擴展機制 + PostgreSQL 基礎設施，但 RAG 知識庫本身需要自己建。
Claude Opus 4.6 • 3x
Comments...
No Comments Yet...