Yuxi-Know是一個免費開源平台，構建在Langstra、Vue.js、FastAPI和LightRAG之上，可以創建具有檢索增強生成（RAG）知識庫和知識圖的代理。其最新測試版v0.4.0-Beta（於2025年12月發布）添加了文件上傳、多模式圖像支持、文件生成思維導圖、評估工具、黑暗模式和優化的圖形可視化功能。該平台幫助用戶快速構建和部署定製的AI主體，用於問答、分析和檢索場景，而無需從頭開始開發，從而節省了大量開發時間和精力。
過去兩年，大型語言模型幾乎解決了「語言」本身的問題。
但出現了一個更現實的問題：
如果我們不想做ChatBot，而是想做「Agent」，我們從哪裡開始呢？
- 特工需要有記憶嗎？
- 您希望能夠調用該工具嗎？
- 你想要有長期目標嗎？
- 如何避免成為「shell GPT」？
玉溪知道 在GitHub上是一個 圍繞「如何構建代理」的實驗解決方案.
它不是成品，但更像是 草圖 代理架構的。
「建築代理人」的邊界
在Yuxi-Know的背景下， 代理搜索聊天機器人.
如果用一句話概括作者的想法：
代理= LLM +記憶系統+行為能力+內部狀態管理
這與許多現成的解決方案不同，因為它們是：
- 不是「提示答案」
- 刪除不是「任務列表'自動」
- 這是一個 持久、積累經驗並可以調用外部能力的系統
Yuxi-Know試圖解決的是 代理的「系統層問題」 而不是提示技巧。
Yuxi-Know的代理解決方案：整體架構拆解
如果從「建築代理人」的角度來看，這個項目的結構非常清晰，可以細分為5個核心層面。
代理核心：不是模型，而是「調度中心」
在Yuxi-Know，法學碩士 不是主角.
真正的主角是 代理控制層，負責：
- 接收用戶輸入
- 決定：
- 直接回復？
- 記憶檢查？
- 檢查知識庫？
- 呼叫工具？
- 管理多輪上下文和行為序列
這一步至關重要：
該模型只是所謂的「能力模塊」，而不是系統本身。
記憶：這是代理和聊天機器人的分水嶺時刻
Yuxi-Know非常重視 存儲器系統，而不僅僅是對話歷史。
其內存設計理念包括：
- 短期記憶：本屆會議的背景
- 長期記憶：歷史事件、知識片段（載體化存儲）
- 可收回的記憶：通過嵌入+載體搜索觸發「召回」
這一步解決了一個基本問題：
特工可以「記住過去的自己」嗎？
如果沒有這一層，所謂的代理很容易淪為一次性的對話工具。
知識：外界的「認知擴展器」
在Agent架構中，有一個非常重要的原則：
不要讓模特「硬背世界」，而要學會「檢查世界」。
Yuxi-Know的知識系統承擔了這一角色：
- 文檔載體化
- 內部/外部知識庫
- 檢索後交給Agent判斷是否使用
這使得特工能夠擁有 可擴展的知識邊界 而不是被鎖定在模型訓練數據中。
工具：使代理能夠真正「行動」
這是Yuxi-Know明確調整Agent概念的一層。
該工具系統允許代理：
- 搜索信息
- 調用API
- 執行腳本
- 操作文件（理論上）
也就是說，該系統的設計具有：
從語言智能遷移的界面到行為智能
這一步是許多代理項目陷入困境的地方，而Yuxi-Know至少在結構上是清晰的。
UI：故意削弱，但並非不重要
Yuxi-Know的前端基於ChatGPT-Next-Web，但您會發現：
- UI不是項目的重點
- 只是個 調試和交互門戶
這是成熟的代理項目應該有的態度：
代理是一個系統，而不是接口。
解決方案的核心價值是什麼？
如果只看功能，Yuxi-Know 並不「神奇」 現在
但從「構建代理解決方案」的角度來看，它有三個非常重要的價值。
明確區分「模型」和「代理人」
許多項目的問題是：
- 將Agent視為「自動多說幾句話的GPT」
- 或者作為「帶工具的提示」
而Yuxi-Know很清楚：
模型是可替換部件，代理是系統。
給出了可著陸的Agent最小結構
它幾乎給了一個 代理MVP清單:
- 是否有代理控制層？
- 你有長期記憶嗎？
- 我可以調用外部工具嗎？
- 還能繼續運營嗎？
您可以使用它作為一個 代理模式的參考模板.
Github：https://github.com/xerrors/Yuxi-Know
管材：