# 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-自建系統成本與維護性評估)
- [附錄 E：IronClaw / Nanobot + LightRAG MCP Server 組合評估](#附錄-eironclaw--nanobot--lightrag-mcp-server-組合評估)
- [附錄 F：客製化 Nanobot UI 可行性評估](#附錄-f客製化-nanobot-ui-可行性評估)
---
## 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 的分階段交付路線最能平衡成本與品質。
---
## 附錄 E：IronClaw / Nanobot + LightRAG MCP Server 組合評估
*評估日期：2026-03-31*
### E.1 LightRAG 專案概覽
[LightRAG](https://github.com/HKUDS/LightRAG)（HKUDS/LightRAG）是香港大學研究團隊開發的 GraphRAG 框架，已發表於 EMNLP 2025。
| 項目 | 資料 |
|------|------|
| **GitHub Stars** | 31.2k ⭐ |
| **Contributors** | 236 人 |
| **最新版本** | v1.4.13rc1（2026-03-30） |
| **最後 Commit** | 昨日（持續活躍） |
| **語言** | Python 80.7% + TypeScript 13.4% |
| **授權** | **MIT**（純 MIT，無 Enterprise 限制） |
| **論文** | arXiv:2410.05779（EMNLP 2025） |
#### LightRAG 核心能力
| 能力 | 說明 |
|------|------|
| **GraphRAG** | 自動從文件中提取實體 + 關係，建構知識圖譜，搭配向量混合檢索 |
| **多查詢模式** | `local`（上下文相關）、`global`（整體知識）、`hybrid`（混合）、`naive`（基本搜尋）、`mix`（KG + 向量） |
| **PostgreSQL 16 原生支援** | KV、Vector、Graph、DocStatus 四種 Storage 全部支援 PG 後端 |
| **pgvector** | `PGVectorStorage` — 支援自訂向量維度（匹配 nomic-embed-text 768 維） |
| **本地 Reranker** | **支援 vLLM 部署的本地 Reranker**（BAAI/bge-reranker-v2-m3），完全離線可用 |
| **引用來源** | 2025.03 新增 Citation 功能，回答附帶文件來源引用 |
| **多模態文件處理** | 透過 RAG-Anything 整合，支援 PDF、DOCX、PPTX、XLSX、圖片 |
| **文件狀態追蹤** | `pending` → `processing` → `processed` → `failed`，含 Track ID |
| **批次文件匯入** | 支援 Batch Insert、Pipeline Insert、目錄掃描匯入 |
| **LightRAG Server** | 內建 REST API（port 9621）+ WebUI + Ollama 相容介面 |
| **知識圖譜視覺化** | Web UI 提供知識圖譜瀏覽、節點查詢、子圖過濾 |
| **離線部署** | 官方 [Offline Deployment Guide](https://github.com/HKUDS/LightRAG/blob/main/docs/OfflineDeployment.md)，支援 `pip install lightrag-hku[offline]` |
| **OpenAI 相容 API** | 支援任何 OpenAI-compatible API（llama.cpp / Ollama / vLLM） |
| **認證與安全** | API Key + JWT 認證，SSL/TLS 支援 |
| **Docker** | 官方 Docker 映像，已預設離線環境配置 |
| **多實例隔離** | `workspace` 參數確保不同知識庫的資料隔離 |
### E.2 LightRAG MCP Server 選項
目前有多個社群開發的 LightRAG MCP Server 封裝：
| 專案 | Stars | 架構 | 說明 |
|------|-------|------|------|
| [daniel-lightrag-mcp](https://github.com/desimpkins/daniel-lightrag-mcp) | 25 | HTTP → LightRAG Server API | 22 個 MCP 工具：文件管理(6)、查詢(2)、知識圖譜(6)、系統管理(4)、健康檢查(1) |
| [knowledge-mcp](https://github.com/olafgeibig/knowledge-mcp) | 39 | 內嵌 LightRAG 作為函式庫 | CLI + MCP Server，支援多知識庫管理、可配置 user_prompt、text-only 解析模式 |
| [kodabi-lightrag-mcp](https://github.com/Ekestfa/kodabi-lightrag-mcp) | 6 | Rust，HTTP → LightRAG Server API | Rust 實作的 MCP 封裝 |
**推薦選用 `daniel-lightrag-mcp`**：
- 22 個 MCP 工具涵蓋**文件管理 + 查詢 + 知識圖譜操作 + 系統監控**完整流程
- 透過 HTTP 呼叫 LightRAG Server API，**架構上支援客戶端-伺服器分離**（MCP Server 在客戶端，LightRAG Server 在遠端伺服器）
- 純 Python，與 SA 技術棧一致
### E.3 組合方案一：IronClaw + LightRAG MCP Server
#### 架構
```
┌────────────────────────────┐ LAN ┌──────────────────────────────┐
│ Windows 11 筆電 (客戶端) │ │ 整合部專用伺服器 │
│ │ │ │
│ IronClaw Agent (Rust) │ │ LightRAG Server (Python) │
│ │ │ │ ├── REST API :9621 │
│ ├─ MCP ──► │ │ ├── WebUI │
│ │ daniel-lightrag │ HTTP ──────────────► │ ├── 文件匯入 Pipeline │
│ │ -mcp (Python) │ :9621 │ └── 知識圖譜建構 │
│ │ │ │ │
│ └─ MCP ──► │ │ PostgreSQL 16 + pgvector │
│ CAD MCP Server │ │ ├── LightRAG Storage │
│ │ │ └── ironclaw DB (記憶) │
│ │ │ │
│ IronClaw 記憶 │ DATABASE_URL ──────► │ llama.cpp / Ollama │
│ (.ironclaw/.env) │ :5432 │ ├── Qwen2.5-VL (chat) │
│ │ │ ├── nomic-embed-text (768d) │
└────────────────────────────┘ │ └── bge-reranker (vLLM) │
└──────────────────────────────┘
```
#### 優勢
| 維度 | 說明 |
|------|------|
| **RAG 品質超越 SA** | LightRAG 的 GraphRAG（KG + 向量）**原生超越** SA 設計的基本 RAG，SA 標註為「進階、選用」的 GraphRAG 在 LightRAG 中是**標配** |
| **PostgreSQL 共用** | IronClaw 用 `ironclaw` DB，LightRAG 用獨立 DB，共用同一 PostgreSQL 實例 |
| **離線 Reranker** | LightRAG 支援 vLLM 部署 `BAAI/bge-reranker-v2-m3`，完全離線 |
| **引用來源** | LightRAG 2025.03 新增 citation，匹配 SA 要求 |
| **WebUI** | LightRAG Server 自帶文件管理 + 知識圖譜視覺化 WebUI |
| **批次匯入** | LightRAG 支援目錄掃描、批次上傳、進度追蹤 |
| **離線部署** | LightRAG 有官方離線部署指南，Docker 映像預設離線 |
| **MIT 授權** | IronClaw（MIT）+ LightRAG（MIT），完全無限制 |
#### 問題
| 問題 | 嚴重度 | 說明 |
|------|--------|------|
| **跨語言** | 🟡 中 | IronClaw（Rust）+ LightRAG MCP Server（Python）+ LightRAG Server（Python），需維護兩種技術棧 |
| **LLM 參數不足** | 🟡 中 | LightRAG 建議 32B+ LLM 做實體關係提取，SA 的 Qwen2.5-VL 7B **可能導致知識圖譜品質降低** |
| **三層服務** | 🟡 中 | IronClaw → MCP Server → LightRAG Server，Debug 鏈較長 |
| **Schema 不匹配** | 🟢 低 | LightRAG 自管 schema（4 種 Storage），非 SA 的 `documents`/`document_chunks`/`batch_jobs`，但**功能等價且更強** |
| **額外服務** | 🟡 中 | Reranker 需額外 vLLM 實例（或略過 Reranker，用 LightRAG 的 mix mode KG+向量混合代替） |
---
### E.4 組合方案二：Nanobot + LightRAG MCP Server
#### 架構
```
┌────────────────────────────┐ LAN ┌──────────────────────────────┐
│ Windows 11 筆電 (客戶端) │ │ 整合部專用伺服器 │
│ │ │ │
│ Nanobot Agent (Python) │ │ LightRAG Server (Python) │
│ │ │ │ ├── REST API :9621 │
│ ├─ MCP ──► │ │ ├── WebUI │
│ │ daniel-lightrag │ HTTP ──────────────► │ ├── 文件匯入 Pipeline │
│ │ -mcp (Python) │ :9621 │ └── 知識圖譜建構 │
│ │ │ │ │
│ └─ MCP ──► │ │ PostgreSQL 16 + pgvector │
│ CAD MCP Server │ │ └── LightRAG Storage │
│ │ │ │
│ FastAPI 後端 (Python) │ │ llama.cpp / Ollama │
│ │ │ ├── Qwen2.5-VL (chat) │
└────────────────────────────┘ │ ├── nomic-embed-text (768d) │
│ └── bge-reranker (vLLM) │
└──────────────────────────────┘
```
#### 優勢
| 維度 | 說明 |
|------|------|
| **全 Python** | Nanobot + MCP Server + LightRAG 全部 Python，統一技術棧 |
| **LightRAG 完整功能** | 同方案一，GraphRAG + 離線 Reranker + Citation + WebUI + 批次匯入 |
| **輕量 Agent** | Nanobot 極簡，支援 MCP + Skills，適合小團隊快速上手 |
| **可深度整合** | 同語言可直接 `import lightrag` 作為函式庫，省去 MCP 層（如果需要更緊密整合） |
| **漸進演化** | 初期用 Nanobot 快速驗證，後期可遷移到 DeepAgents/LangGraph 而不影響 LightRAG |
#### 問題
| 問題 | 嚴重度 | 說明 |
|------|--------|------|
| **Nanobot 極新** | 🟡 中 | 專案約 1-2 個月歷史，穩定性未經驗證 |
| **LLM 參數不足** | 🟡 中 | 同方案一，7B 模型做實體提取可能不夠精確 |
| **Agent 能力有限** | 🟡 中 | Nanobot 無 LangGraph 的狀態機、條件路由等 Agent 進階能力 |
| **Schema 不匹配** | 🟢 低 | 同方案一，LightRAG 自管 schema，功能等價 |
---
### E.5 關鍵問題分析：7B 模型與 LightRAG 的相容性
LightRAG 官方建議：
> *"It is recommended to use an LLM with at least 32 billion parameters."*
>
> *"The context length should be at least 32KB, with 64KB being recommended."*
SA 指定的 Qwen2.5-VL 7B 遠低於此建議。影響範圍：
| 階段 | 影響 | 說明 |
|------|------|------|
| **文件索引（Indexing）** | 🔴 高 | LightRAG 需要 LLM 從文件中**提取實體和關係**來建構知識圖譜，7B 模型提取品質會降低 |
| **查詢（Query）** | 🟡 中 | LightRAG 建議查詢用比索引更強的模型，7B 對查詢回答品質也有限制 |
| **Embedding** | 🟢 無影響 | Embedding 模型獨立於 LLM，SA 的 nomic-embed-text 768 維完全支援 |
| **Reranker** | 🟢 無影響 | Reranker 模型獨立於 LLM |
#### 緩解方案
1. **CAD 文件領域特性**：CAD 技術文件結構相對規律（指令名稱、參數、步驟），實體關係相較於通用語言更明確，7B 模型有可能勝任
2. **分時推理**：索引階段對 latency 要求低（離線批次），可使用 Qwen2.5 **14B 或 32B** 量化版（如 Q4_K_M）在同一 llama.cpp 上部署，索引時切換模型
3. **降級使用 naive mode**：如果知識圖譜品質不足，可退回 `naive` 模式（純向量搜尋），品質仍優於手寫 RAG
4. **LightRAG 2025.09 有專門針對開源 LLM 的優化**：*"Enhances knowledge graph extraction accuracy for Open-Sourced LLMs such as Qwen3-30B-A3B"*，表明官方在積極改善小模型相容性
> **實務建議**：先用 7B 測試，觀察知識圖譜品質。若不夠好，索引階段升級為 14B/32B 量化版（可在伺服器上部署多個 GGUF 模型，按需切換）。
---
### E.6 LightRAG vs SA 設計對照
| SA 需求 | SA 自建方案 | LightRAG 方案 | 比較 |
|---------|------------|--------------|------|
| **文件解析** | `pymupdf4llm` + `python-docx` + Tesseract OCR | RAG-Anything（PDF/DOCX/PPTX/XLSX/圖片） | ✅ LightRAG 更強（多模態） |
| **批次匯入** | 自建 `document_import.py` 排程 | LightRAG Server 目錄掃描 + 批次上傳 + Track ID | ✅ LightRAG 已內建 |
| **文件狀態追蹤** | `batch_jobs` 表（pending/processing/completed） | DocsStatus Storage（pending/processing/processed/failed） | ✅ 功能等價 |
| **向量搜尋** | pgvector + HNSW | pgvector + 任意維度 | ✅ 相同 |
| **全文搜尋** | PostgreSQL `tsvector` | LightRAG 的 KV Storage | ⚠️ 不同實現方式 |
| **Reranker** | Cross-encoder（自建） | vLLM 部署 BAAI/bge-reranker-v2-m3 | ✅ LightRAG 有方案 |
| **GraphRAG** | 「進階，選用」—自建 NetworkX | **原生內建**（KG 自動提取+多種查詢模式） | ✅✅ LightRAG 核心優勢 |
| **引用來源** | `document_id` + `page_number` 回傳 | Citation 功能（`file_path` + `content` 回傳） | ✅ 功能等價 |
| **Self-RAG** | LangGraph 迴圈（自建） | LightRAG 的 `mix` 模式（KG + Vector + Rerank） | ⚠️ 不完全等價，但 mix mode 更先進 |
| **Context 壓縮** | `compress_context` 節點（自建） | `max_total_tokens` 參數控制 token 預算 | ⚠️ 不同方法，功能相近 |
| **離線環境** | 自建離線安裝腳本 | 官方 Offline Deployment Guide + Docker | ✅ LightRAG 更完整 |
| **Schema** | `documents`/`document_chunks`/`batch_jobs`（SA 自訂） | LightRAG 自建 4 種 Storage schema | ⚠️ 不匹配但功能等價 |
| **WebUI** | React 自建（3 頁面） | LightRAG Server 自帶 WebUI | ✅ 省掉前端開發 |
| **知識圖譜視覺化** | 無（SA 未規劃） | LightRAG WebUI 原生支援 | ✅ 額外加值 |
---
### E.7 LightRAG vs Quivr 比較（為何 LightRAG 遠優於 Quivr）
| 維度 | Quivr | LightRAG | 勝者 |
|------|-------|----------|------|
| **GitHub Stars** | 39.1k | 31.2k | Quivr |
| **最後活動** | 2025-06-19（~9 個月無更新） | **昨日**（持續活躍） | ✅ LightRAG |
| **版本** | v0.0.33 | v1.4.13rc1 | ✅ LightRAG |
| **離線 Reranker** | ❌ 預設 Cohere 雲端 | ✅ vLLM 本地部署 | ✅ LightRAG |
| **PostgreSQL 支援** | ❌ Brain 抽象層 | ✅ 原生 PG 四種 Storage | ✅ LightRAG |
| **GraphRAG** | ❌ 無 | ✅ 核心功能 | ✅ LightRAG |
| **授權** | Apache 2.0 + Enterprise 限制 | **純 MIT** | ✅ LightRAG |
| **引用來源** | 基本 | ✅ Citation 功能 | ✅ LightRAG |
| **批次匯入** | ❌ 互動式 | ✅ 批次 + 目錄掃描 + Track ID | ✅ LightRAG |
| **離線部署文件** | 無 | ✅ 官方指南 | ✅ LightRAG |
| **WebUI** | 無（函式庫） | ✅ 內建 WebUI | ✅ LightRAG |
| **多模態文件** | 基本 | ✅ RAG-Anything | ✅ LightRAG |
| **學術背景** | 無 | EMNLP 2025 論文 | ✅ LightRAG |
> **結論**：LightRAG 在幾乎所有維度上大幅超越 Quivr。之前不推薦 Quivr 的**所有問題**（停滯、雲端 Reranker、授權、Schema 不匹配）在 LightRAG 都**不存在**。
---
### E.8 兩組合方案對比總表
| 維度 | IronClaw + LightRAG | Nanobot + LightRAG | DeepAgents + 自建 RAG | SA 全自建 |
|------|---------------------|--------------------|-----------------------|----------|
| **技術棧** | ⚠️ Rust + Python | ✅ 全 Python | ✅ 全 Python | ✅ 全 Python |
| **RAG 品質** | ✅✅ GraphRAG 內建 | ✅✅ GraphRAG 內建 | ✅ 手寫 RAG | ✅ 手寫 RAG |
| **離線 Reranker** | ✅ vLLM 部署 | ✅ vLLM 部署 | ✅ 自建 | ✅ 自建 |
| **Schema 匹配** | ⚠️ LightRAG 自管（功能等價） | ⚠️ LightRAG 自管（功能等價） | ✅ SA 原生 | ✅ SA 原生 |
| **批次匯入** | ✅ 內建 | ✅ 內建 | ❌ 需自建 | ❌ 需自建 |
| **知識圖譜** | ✅ 原生 | ✅ 原生 | ❌ 需自建 | ❌ 需自建 |
| **引用來源** | ✅ Citation | ✅ Citation | ❌ 需自建 | ❌ 需自建 |
| **WebUI** | ✅ LightRAG 自帶 | ✅ LightRAG 自帶 | ❌ 需自建 | ❌ 需自建 |
| **MCP 支援** | ✅ IronClaw 原生 | ✅ Nanobot 原生 | ✅ langchain-mcp | ✅ SA 自建 |
| **Agent 成熟度** | ✅ IronClaw 穩定 | ⚠️ Nanobot 極新 | ✅ LangChain 官方 | ✅ 完全自控 |
| **7B 模型風險** | 🟡 知識圖譜品質可能降低 | 🟡 知識圖譜品質可能降低 | 🟢 無（純向量 RAG） | 🟢 無 |
| **維護成本** | 🟡 兩語言 + LightRAG 追蹤 | 🟢 單語言 + LightRAG 追蹤 | 🟡 LangChain 追蹤 | 🔴 高（全部自維護） |
| **開發時程** | **4-6 週** | **3-5 週** | 12-14 週 | 18 週 |
| **自建代碼量** | **~500 行**（CAD MCP 只） | **~500 行**（CAD MCP 只） | ~5,000 行 | ~7,000 行 |
---
### E.9 綜合評估與推薦
#### ✅ 推薦：Nanobot + LightRAG MCP Server（短期最優）
**理由**：
1. **全 Python 技術棧** — 與 SA 一致，團隊只需維護一種語言
2. **LightRAG 替代 80% 的 SA 自建工作** — 文件匯入、向量化、KG 建構、Reranker、Citation、WebUI 全部省掉
3. **開發時程僅 3-5 週** — 只需自建 CAD MCP Server + 配置 LightRAG + 部署
4. **GraphRAG 免費獲得** — SA 標註為「進階、選用」的功能，LightRAG 原生提供
5. **後續可演化** — Nanobot 可替換為 DeepAgents/LangGraph，LightRAG 層不變
**風險與緩解**：
- Nanobot 極新 → **如果發現不穩定，Agent 層可快速切換至 DeepAgents**
- 7B 模型 → **索引階段可切換至 14B/32B 量化版，查詢階段用 7B**
#### ⚠️ 次推薦：IronClaw + LightRAG MCP Server
**理由**：IronClaw Agent 更成熟穩定，但 Rust + Python 跨語言增加維護成本。適合團隊有 Rust 經驗的情況。
#### 最終策略建議：分階段 + LightRAG
結合附錄 D 的策略 D（分階段交付），將 LightRAG 納入架構：
```
Phase 1（3-5 週）: "能用版"
├── LightRAG Server（部署在伺服器，連接 PostgreSQL + pgvector）
│ ├── 配置 Ollama/llama.cpp 做 LLM + Embedding
│ ├── 匯入 CAD 技術文件
│ └── 驗證知識圖譜品質（7B 是否足夠？）
├── Nanobot Agent（客戶端）
│ ├── 連接 LightRAG MCP Server（知識庫查詢）
│ └── 連接 CAD MCP Server（自建，最小可行版）
└── 使用 LightRAG WebUI 做文件管理
↓ 上線使用、收集回饋
Phase 2（選擇性，2-4 週）:
├── 如果 7B 知識圖譜不夠好 → 部署 14B/32B GGUF 做索引
├── 如果 Nanobot 不穩定 → 切換 Agent 層到 DeepAgents
├── 如果需要本地 Reranker → 部署 vLLM + bge-reranker-v2-m3
└── 如果 LightRAG WebUI 不夠用 → 自建 React 前端
↓ 根據實際需求
Phase 3（選擇性，4-6 週）:
├── 更精細的 Agent 路由（LangGraph 狀態機）
├── 稽核日誌、權限控制
└── Windows 服務化、TLS、備份策略
```
> **核心洞見**：LightRAG 是目前發現的**最佳 RAG 引擎替代方案**，它以 MCP Server 形式提供的能力直接覆蓋了 SA 設計中約 60-70% 的自建工作量（文件匯入管線、向量化、知識圖譜、Reranker、Citation、WebUI），且品質（GraphRAG）**超越** SA 原始設計的基礎 RAG。唯一需要驗證的風險點是 7B 模型在知識圖譜提取上的表現。
---
## 附錄 F：客製化 Nanobot UI 可行性評估
### F.1 研究背景
附錄 E 建議採用「Nanobot + LightRAG MCP Server」方案，但該方案缺少面向使用者的 Web 前端。SA 文件規格要求 React/TypeScript/Vite/TailwindCSS 前端，包含三個頁面（對話、文件管理、管理後台）。本附錄評估如何解決前端層的缺口。
### F.2 Nanobot 本體 UI 分析
**倉庫**：[HKUDS/nanobot](https://github.com/HKUDS/nanobot)（37.1k ⭐，MIT，Python 98.3%）
| 面向 | 現況 |
|------|------|
| **介面模式** | **純 CLI 終端機**（`nanobot agent`）+ Chat Channel（Telegram/Discord/WhatsApp 等 12 種） |
| **API** | OpenAI-compatible REST（`nanobot serve`，Port 8900），僅 3 端點 |
| **串流支援** | ❌ **API 不支援 `stream=true`**；但 Channel 層有端對端串流（v0.1.4.post6） |
| **Session** | API 端固定 session（`api:default`），所有請求共用同一對話 |
| **內建 Web UI** | ❌ **完全沒有** |
| **前端擴展點** | 無框架、無模板、無前端建構系統 |
**結論**：Nanobot 本體**不可能直接客製化 UI**，因為它根本沒有 Web UI 可供修改。
### F.3 社群 WebUI 專案調查
| 專案 | ⭐ | 技術棧 | 特色 | 成熟度 |
|------|----|--------|------|--------|
| [lucmuss/nanobot-webgui](https://github.com/lucmuss/nanobot-webgui) | 16 | Python 73% + HTML 20% + JS 5%（Flask/Jinja SSR） | Dashboard、MCP 管理、Chat（含上傳）、Memory 編輯、Admin 設定精靈 | v0.3.12，123 contributors，活躍更新 |
| [wangyixuxiaowei/x-nanobot-ui](https://github.com/wangyixuxiaowei/x-nanobot-ui) | 4 | TypeScript 73%（Lit 3.x + Vite）+ Python 25%（FastAPI） | Chat、Config 管理、Cron 任務、Status | 1 commit、1 contributor、2 週前建立 |
| [vincentwuxi/nonobot](https://github.com/vincentwuxi/nonobot) | 0 | Python（fork） | Web Console + Sandbox 檔案系統 | 極早期 |
### F.4 SA 前端規格需求 vs. 現有選項
| SA 需求 | nanobot-webgui | x-nanobot-ui | 自建 React 前端 |
|---------|---------------|--------------|-----------------|
| **React 18** | ❌ Flask/Jinja SSR | ❌ Lit 3.x | ✅ |
| **TypeScript** | ❌ Python + vanilla JS | ✅ TypeScript | ✅ |
| **Vite** | ❌ 無前端建構 | ✅ Vite | ✅ |
| **TailwindCSS + shadcn/ui** | ❌ | ❌ | ✅ |
| **SSE 串流聊天** | ⚠️ 有 Chat 但非 SSE 標準格式 | ⚠️ WebSocket | ✅ 可實作 |
| **引用來源顯示** | ❌ | ❌ | ✅ 可整合 LightRAG `include_references` |
| **文件管理頁** | ❌ 無文件管理 | ❌ | ✅ 呼叫 LightRAG REST API |
| **對話歷史側邊欄** | ⚠️ 有基本功能 | ⚠️ 有 Session 管理 | ✅ |
| **JWT 認證** | ⚠️ 有 Admin 登入+Cookie | ❌ | ✅ |
| **角色控制** | ⚠️ 僅 Admin | ❌ | ✅ |
| **圖片上傳** | ✅ | ❌ | ✅ |
| **離線內網** | ✅ | ✅ | ✅ |
### F.5 四種前端策略比較
#### 策略 A：直接採用 nanobot-webgui
```
Browser → nanobot-webgui (Flask/Jinja, :18791)
│
├── 呼叫 Nanobot Agent 核心（Python 直調）
└── 讀寫 config.json / memory docs
```
| 優勢 | 劣勢 |
|------|------|
| 零開發、立即可用 | ❌ Python SSR，非 React SPA |
| 有 Chat + Admin + MCP 管理完整功能 | ❌ 完全不符合 SA 前端技術棧 |
| 活躍維護（v0.3.12） | ❌ 無文件管理頁（LightRAG 部分無法覆蓋） |
| MIT 授權 | ❌ 自訂程度受限（Jinja 模板） |
**適用場景**：快速 POC / 內部測試用，不做為正式交付物。
#### 策略 B：Fork nanobot-webgui + 加掛 LightRAG 頁面
```
Browser → nanobot-webgui (Fork 版, :18791)
│
├── 原有功能（Chat/Admin/MCP）
└── 新增 /documents 頁面 → 呼叫 LightRAG REST API (:9621)
```
| 優勢 | 劣勢 |
|------|------|
| 基礎功能已就緒 | ❌ 仍然是 Flask/Jinja，非 React |
| 加掛 LightRAG 文件管理相對簡單 | ❌ 兩套不同風格的 UI |
| 工期短（1-2 週） | ❌ 長期維護需追蹤上游變更 |
**適用場景**：Phase 1 過渡方案，Phase 2 再替換為 React 前端。
#### 策略 C：自建 React 前端 + FastAPI 代理後端（✅ 推薦）
```
┌──────────────────────────────────┐ ┌──────────────────────────┐
│ React SPA (:5173) │ │ LightRAG Server (:9621) │
│ React 18 + TypeScript + Vite │ │ WebUI + REST API │
│ TailwindCSS + shadcn/ui │ │ 文件管理 / KG / Query │
│ │ └────────────┬─────────────┘
│ /chat → WebSocket → Proxy │ │
│ /documents → REST → LightRAG │ │
│ /admin → REST → Proxy │ ┌────────────┴─────────────┐
└──────────┬───────────────────────┘ │ Nanobot Agent │
│ │ (CLI/Python 核心) │
▼ │ MCP → LightRAG MCP Svr │
┌──────────────────────────────────┐ │ MCP → CAD MCP Server │
│ FastAPI Proxy Backend (:8000) │ └──────────────────────────┘
│ ~300-500 行 Python │
│ │
│ /chat/stream → SSE 串流橋接 │
│ (呼叫 Nanobot agent 內部 API │
│ + 轉換為 SSE token 事件) │
│ /chat/* → 對話管理 │
│ /documents/* → 轉發 LightRAG │
│ /admin/* → Nanobot config │
│ /auth/* → JWT 認證 │
└──────────────────────────────────┘
```
| 優勢 | 劣勢 |
|------|------|
| ✅ **完全符合 SA 前端技術棧** | 開發工期最長（3-5 週） |
| ✅ SSE 串流聊天（透過代理後端橋接） | 需要自建 FastAPI 代理層 |
| ✅ LightRAG 引用來源可直接顯示 | 前端工程量約 2000-3000 行 |
| ✅ 統一的 JWT 認證 + 角色控制 | — |
| ✅ 文件管理直接呼叫 LightRAG REST API | — |
| ✅ 前端可完全自訂 UX 風格 | — |
| ✅ 與 SA 文件 API 規格一致（`/chat/stream`） | — |
**串流解法關鍵**：Nanobot API 不支援 `stream=true`，但其 Channel 層和 Agent loop 內部有完整的串流機制。FastAPI 代理後端可透過以下方式取得串流：
1. **直接呼叫 Nanobot Agent 內部函式**（Python 同進程，推薦）：
- 匯入 `nanobot.agent.loop` 模組
- 透過回呼（callback）或 async generator 取得逐 token 輸出
- 轉換為 SSE `data: {"type":"token","content":"..."}` 推送
2. **WebSocket 橋接**（備選）：
- 參考 x-nanobot-ui 的做法（Lit + WebSocket）
- 代理後端建立 WebSocket 連線到 Nanobot
- 再轉換為 SSE 推送給 React 前端
#### 策略 D：使用 LightRAG WebUI + nanobot-webgui 雙 UI
```
Browser → LightRAG WebUI (:9621) → 文件管理 + 知識圖譜
→ nanobot-webgui (:18791) → Chat + Admin + MCP
```
| 優勢 | 劣勢 |
|------|------|
| 零開發 | ❌ 兩個獨立 UI，使用者體驗割裂 |
| 各自功能完整 | ❌ 無統一認證 |
| 適合開發者 / 管理員 | ❌ 不適合一般使用者 |
**適用場景**：純開發/管理用途，不作為使用者面向的正式 UI。
### F.6 策略總覽比較
| 維度 | A: webgui 直用 | B: webgui Fork | C: React 自建 ✅ | D: 雙 UI |
|------|---------------|---------------|-------------------|----------|
| 符合 SA 前端規格 | ❌ | ❌ | ✅ **完全符合** | ❌ |
| SSE 串流聊天 | ⚠️ | ⚠️ | ✅ | ⚠️ |
| 文件管理 | ❌ | ⚠️ 可加 | ✅ | ✅ LightRAG |
| 引用來源顯示 | ❌ | ❌ | ✅ | ❌ |
| 統一 UX | ⚠️ | ⚠️ | ✅ | ❌ 割裂 |
| JWT + 角色控制 | ⚠️ | ⚠️ | ✅ | ❌ |
| 開發工期 | 0 | 1-2 週 | **3-5 週** | 0 |
| 自建程式量 | 0 行 | ~200 行 Jinja | ~2500 行（前端+代理） | 0 行 |
| 長期維護性 | 依賴上游 | 需追蹤 Fork | ✅ 自主可控 | 依賴兩方上游 |
| 正式交付適合度 | ❌ POC | ⚠️ 過渡 | ✅ **正式** | ❌ 開發用 |
### F.7 推薦策略：分階段實施
```
Phase 1（0-5 週）: LightRAG WebUI + nanobot CLI
├── 使用 LightRAG WebUI 管理文件（免開發）
├── 使用 nanobot CLI 或 nanobot-webgui 做 Chat 測試
├── 驗證 LightRAG + Nanobot + MCP 整合是否正常
└── 重點：验证技術可行性，收集 UX 回饋
↓ 確認可行後
Phase 2（5-10 週）: 自建 React 前端
├── 建構 FastAPI 代理後端
│ ├── SSE 串流橋接（Nanobot → SSE token 事件）
│ ├── LightRAG API 轉發（文件上傳/刪除/狀態）
│ ├── JWT 認證模組
│ └── Nanobot config 管理 API
├── 建構 React 前端
│ ├── /chat — ChatWindow + Sidebar + MessageItem
│ ├── /documents — 文件上傳 + 索引狀態 + 搜尋
│ └── /admin — 系統設定 + 使用者管理
└── 重點：SA 規格對齊，正式交付品質
↓ 選擇性
Phase 3: 進階 UX
├── 知識圖譜視覺化（整合 LightRAG KG API）
├── Multi-turn 對話 Session 管理
└── 管理員稽核日誌介面
```
### F.8 React 前端自建工作量估算
| 模組 | 檔案數 | 估計行數 | 工期 |
|------|--------|----------|------|
| **FastAPI 代理後端** | | | |
| ├── SSE 串流橋接 | 1 | ~100 | 3 天 |
| ├── LightRAG API 轉發 | 1 | ~80 | 1 天 |
| ├── JWT 認證 | 2 | ~120 | 2 天 |
| └── 對話/Config 管理 | 2 | ~150 | 2 天 |
| **React 前端** | | | |
| ├── ChatWindow + SSE 客戶端 | 3 | ~400 | 4 天 |
| ├── MessageItem（Markdown + 引用） | 2 | ~200 | 2 天 |
| ├── Sidebar（對話歷史） | 1 | ~150 | 1 天 |
| ├── DocumentsPage（上傳+狀態） | 3 | ~350 | 3 天 |
| ├── AdminPage（設定+狀態） | 2 | ~250 | 2 天 |
| ├── Auth 頁面（Login） | 1 | ~100 | 1 天 |
| └── Layout + Router + 共用元件 | 3 | ~200 | 1 天 |
| **合計** | ~21 | **~2100 行** | **~3-4 週** |
### F.9 關鍵技術風險
| 風險 | 影響 | 緩解方式 |
|------|------|----------|
| Nanobot Agent 無公開串流 API | 無法實作 SSE 串流 | 直接呼叫內部 Python 模組的 agent loop，以 callback 取得串流 |
| Nanobot API 固定 session | 多使用者場景困難 | 代理後端管理多個 Nanobot session 實例，或用 `--config` 多實例模式 |
| LightRAG 跨域存取 | React SPA 無法直接呼叫 LightRAG | FastAPI 代理後端統一轉發，避免 CORS 問題 |
| Nanobot 極新（~2 個月） | 內部 API 可能大幅變動 | 代理後端做為抽象層，隔離前端與 Nanobot 變動 |
| nanobot-webgui 的 Chat 實作 | 不確定其串流品質 | 優先參考其 Chat 實作方式，再做改良 |
### F.10 結論
| 面向 | 結論 |
|------|------|
| **Nanobot 本體可客製 UI？** | ❌ **不可能**。Nanobot 是純 CLI 工具，完全沒有 Web UI |
| **社群 WebUI 可用？** | ⚠️ **部分可用**。nanobot-webgui 功能完整但技術棧（Flask/Jinja）不符合 SA |
| **最佳策略** | ✅ **Phase 1 用現成 UI 驗證、Phase 2 自建 React 前端** |
| **自建前端可行度** | ✅ **高度可行**。工作量 ~2100 行 / 3-4 週，技術風險可控 |
| **關鍵依賴** | Nanobot 內部 Agent loop 的串流回呼機制（需研究 `agent/loop.py`） |
> **核心洞見**：「客製化 Nanobot UI」的正確理解不是「修改 Nanobot 的 UI」（它沒有 UI），而是「**為 Nanobot 構建一個 Web 前端**」。最佳做法是建立一個薄型 FastAPI 代理後端（~450 行），將 Nanobot Agent 的對話能力 + LightRAG 的文件管理能力統一暴露為 SA 規格的 REST/SSE API，再由 React 前端（~1650 行）消費這些 API。整體工期可控在 3-4 週，且前端完全符合 SA 的 React/TypeScript/Vite/TailwindCSS 技術棧要求。
Comments...
No Comments Yet...