Agent 記憶大亂鬥：Statewave provenance vs Knowhere Tree-RAG 揀邊款？

2026 年，每一個整 agent 嘅人都中咗同一條咒：個 agent 做完十步任務，到第十一步就唔記得第三步做過乜。你用 ChatGPT 幫手寫份研究報告，頭五個 source 好靚，到第八個 source 佢開始 loop 返第一個 source 嘅內容。呢個唔係模型能力問題，係記憶架構問題。而家業界有兩條新路線冒起——Statewave 嘅 provenance graph 同 Knowhere 嘅 Tree-RAG，佢哋代表咗兩種完全唔同嘅哲學，indie developer 應該點揀？

記憶唔係儲存，係因果鏈

大部分人諗 agent 記憶，第一個反應係「搵個 vector DB 塞晒啲 context 入去就得」。呢個諗法喺 2024 年可能仲 work，但 2026 年 agent 行嘅 workflow 複雜度已經翻咗幾倍。一個 agent 可能要同時做 research、寫 code、跑測試、部署，每個步驟之間嘅因果關係先係重點。

Statewave 嘅 provenance approach 就係針對呢個問題。佢唔係單純記住「發生過乜事」，而係記錄「點解會發生呢件事」——每個 state 嘅 transformation 都會被 capture 成一個 provenance node，形成一個 DAG。當 agent 做完 task A 再到 task B，provenance graph 會清楚標示 B 依賴於 A 嘅邊個 output。呢個設計令 debugging 變得極之直接：你可以 trace 返任何一個 decision 係由邊個 source 推導出嚟。

對於香港嘅 indie developer 嚟講，provenance 嘅最大價值係 debuggability。你整一個 trading agent，佢買咗某隻股票，你需要知道佢係因為邊個新聞、邊個技術指標、定係邊個 macro 分析先做呢個決定。Statewave 嘅 graph 結構令你可以成條因果鏈拎出嚟睇，而唔係靠 log 度逐行估。

缺點？provenance graph 嘅儲存成本唔低。每個 node 要 record 嘅 metadata 好多，長時間運行嘅 agent 好易生出一个幾千個 node 嘅巨形 graph，查詢 latency 會急升。Indie developer 如果冇 budget 做 graph compression 或 pruning，呢條路可能會好快玩唔掂。

Tree-RAG 嘅結構優勢

Knowhere 行嘅係另一條路。佢底層係 Milvus 嘅 Knowhere 向量引擎——呢個 engine 本身喺 vector search 領域已經磨咗好多年，對高維向量嘅 ANN search 做得極之高效。Tree-RAG 嘅核心 insight 係：與其 flat 咁塞一堆 vector chunk 入去 search，不如將 document 組織成 tree structure，每個 parent node 係 summary，child node 係 detail，search 時由 root 開始逐層 refine。

呢個做法喺 multi-hop reasoning 場景特別有效。假設你個 agent 要理解一篇幾十頁嘅技術白皮書，flat RAG 通常會抽到一堆 disjointed 嘅段落，然後靠 LLM 自己拼埋。Tree-RAG 就唔同，佢會先 retrieve 到最相關嘅 chapter summary（第一層），再根據個 summary 落去 retrieve 對應嘅 section（第二層），最後先到具體嘅 paragraph。成個過程似一個 funnel，每次 search 都愈來愈精準。

對獨立開發者嚟講，Knowhere Tree-RAG 嘅上手門檻明顯低過 Statewave。向量引擎已經好成熟，tree indexing 嘅 library 亦愈來愈多現成 implementation。你一個 weekend 就可以砌一個 prototype 出嚟，而 provenance graph 你可能要用成個 sprint 去搞 infrastructure。

但 Tree-RAG 有個致命弱點：佢唔擅長處理 stateful 嘅多步 workflow。佢可以幫你 retrieve 到好準嘅 context，但唔會幫你 tracking「目前做到邊一步」或者「呢個 decision 係由邊個 previous output 推導出嚟」。如果你嘅 agent 只係 Q&A bot 或者 document analyst，Tree-RAG 綽綽有餘；但如果你嘅 agent 係 autonomous workflow executor，你始終要自己喺上面搭多層 state management。

實戰選擇框架：你嘅 agent 做緊邊種任務？

我建議用一個簡單嘅框架去決定：你個 agent 嘅任務係「linear」定係「branching」？

Linear 任務：user 問一條問題，agent search 幾個 source，然後俾一個答案。呢種 pattern 唔需要 provenance graph，Tree-RAG 已經做到 90 分。你慳返嘅 infrastructure cost 同開發時間可以用嚟 improve 其他嘢。

Branching 任務：agent 要處理 multiple parallel paths，conditionally 決定下一步，仲要 backtrack 或者修正之前嘅 steps。呢種情況你一定要 provenance。Statewave 嘅 DAG 結構唔係 luxury，係 necessity。冇 provenance tracking 嘅 branching agent 三個月後就會變成一個冇人敢郁嘅 technical debt 黑洞。

仲有一個 hybrid 策略：用 Knowhere 做底層 retrieval layer，用 Statewave 做上層 workflow memory。即係「Tree-RAG 負責搵料，provenance graph 負責理解點解要搵呢啲料同點樣用得著佢哋」。呢個組合喺 production 環境嘅 agent 度愈來愈常見，但需要你 team 入面有人同時搞得掂 vector search 同 graph DB 兩個領域。

香港 indie developer 嘅行動建議

唔好一嚟就揀 framework。先問自己一個問題：你個 agent 會唔會行超過五步仲要記住每一步嘅 context？如果唔會，Knowhere Tree-RAG 係你 best bet，快、平、準。如果會，你需要 provenance，唔好慳呢筆 infrastructure 錢。

如果你係 solo developer，建議先由 Knowhere 入手，一個星期內出到 prototype，等到你真係撞到「記憶唔夠用」嘅牆先再考慮加 provenance layer。唔好為咗一個仲未發生嘅 scalability problem 而 over-engineering。

最後提一句：無論揀邊條路，一定要做 memory eviction strategy。Agent 記憶最常見的死法係「記太多」，最後 search latency 爆標、token cost 失控、agent 自己都睇唔明自己嘅 memory。Set 一個 hard limit——例如最多 keep 100 個 recent context nodes——好過任由 graph 無限膨脹。

Agent 記憶嘅 game 仲未有人贏。2026 年呢一刻，揀啱路線俾你跑得快過 90% 嘅人已經好夠。