Data agent 最難的地方，往往不是模型不會寫 SQL，而是它根本還沒建立起對資料的穩定理解。面對一堆 tables、files 和 databases，模型需要知道欄位代表什麼、資料彼此怎麼關聯，以及哪些工具可以安全地操作。這個模型和資料世界之間的落差，就是論文所說的 agent data gap。

EvoOntology 的想法，是在 agent 和資料源之間加入一層可以自我演化的 ontology。可以把它想成一份不只記錄欄位名稱的活字典。它透過 MCP server 提供三層資訊：schema 說明資料結構，content 補充實際內容與語意，tool 則描述可用的操作方式。builder agent 先建立這個 ontology，之後再根據 agent 回應中的 attribution，對型別和關係做有依據的修改。這比單純把整個資料庫塞進 prompt 更接近真正的系統設計，因為理解結果可以被保存、檢查，也能供下一次任務使用。

我覺得最有意思的是 paired evaluation。每個 LLM backbone 都在有 ontology 和沒有 ontology 的條件下成對比較，試圖把模型本身的能力差異隔離開來。作者報告它在三個 data agent benchmark、四種 LLM backbone 上優於強基線，這表示改善可能不只來自某個特定模型的 prompt 技巧。嚴格來說，這仍然是 benchmark 上的證據，不等於已經能在真實企業資料環境穩定運作。

限制也很明顯。第一，ontology 的演化品質取決於 attribution 是否可靠。如果 agent 引用了錯誤或不完整的證據，系統可能把錯誤理解正式寫進共享層，形成累積性的污染。第二，資料結構會變，權限和商業語意也會變，持續維護 ontology 的成本不能被自我演化四個字掩蓋。第三，論文摘要沒有讓我們知道不同 benchmark 的提升幅度、失敗案例，以及跨 domain 或跨語言資料的表現。

所以我不會把它理解成讓 agent 自己變聰明，而是讓 agent 擁有一個可版本化、可評估的外部語意記憶。這個方向對降低 hallucination 很有吸引力，但真正關鍵的問題是：誰來審核 ontology 的變更，如何回滾錯誤，以及當模型和本體衝突時誰具有最終權限。這些治理細節，可能比再增加一個 benchmark 分數更決定它能不能落地。