需要再survey的部分
- 不太想用ollama，因為其實只需要API，但ollama除了API還包裝了其他功能
- 首選是 llama.cpp server
- 其次為 foundry local
- 再調查 lm studio cli 是否可行
- llama.cpp server, foundry local, lm studio cli, ollama 要進行評估比較
- 調查llama.cpp server, foundry local, lm studio cli 的版本更新是否足夠頻繁

上下文處理部分
- ex. ollama超過上下文限制會報奇怪的錯誤
- 例如openclaw有對上下文進行處理
- 本系統未敘述對上下文限制的處理方式

傳統的RAG產生的答案，可能對於用戶問題來說不夠精確。
- 現代的RAG有哪些方法去處理(向量化？多輪查詢？或是其他方式)
- 本系統的有沒有描述這部分的處理方式
- 有沒有現有的解決方案
- langextract是否是合適的解決方案

整體架構圖要區分出哪些在client端，哪些在remote端

client端(評估client端會占用多少資源)
- UI
- agent
- client要存的東西：ex. agent skills, mcp工具, cache(sqlite)
- 前端跟local的後端溝通(兩者都在client)
- 可能會是一個桌面的icon，執行時打開Agent的頁面，RAG知識庫是在架在remote端

remote端(由機構設計整合部host)
- postgresql / pgvector
- llm engine(llama.cpp)
- documents(來自KM系統，向量化後匯入pgvector)
- 文件向量化匯入程式

KM系統(已建立的文件存放系統)