Meko：解決多代理記憶與知識問題

構建可投入生產的代理式 AI 應用時，常會揭露一個嚴峻的現實：代理失敗的原因很少是缺乏推理能力，而是無法有效分享其所知。當多個代理協同工作時，缺乏統一的記憶與知識層會導致說明性碎片化、營運成本高昂，以及「從頭開始」的心態——每個代理都必須重新發掘相同的教訓。

傳統上，開發者試圖透過拼湊各式資料庫來解決此問題——使用 PostgreSQL 處理關聯資料、Pgvector 進行語意搜尋、圖形資料庫作為記憶、物件儲存保存對話紀錄。此方式會產生資料孤島並帶來顯著的延遲。Meko 應運而生，作為原生代理的資料基礎設施，旨在抽象這些複雜性，讓開發者專注於構建系統，而非管理基礎設施。

核心挑戰：代理間不對齊

根據多代理系統失敗分類法（Multi-Agent System Failure Taxonomy，MAST），約有 36.9% 的多代理系統失敗源於代理間不對齊。這發生在代理各自孤立運作，導致一個代理的學習行為或知識更新無法傳播至系統其他部分。

當工作從代理 A 交接給代理 B 時，通常只會傳遞精選的輸出結果。底層的推理、假設與中間決策則會遺失。Meko 透過保留完整的決策過程上下文來解決此問題，確保接手的代理不僅了解 決定了什麼，更明白 為何 這樣決定。

Meko 架構：資料包（Datapack）

Meko 的核心是 datapack，它透過單一的 Model Context Protocol（MCP）端點與代理框架互動。Meko 不會將代理資料硬塞進通用表格，而是使用四種原生資料結構：

1. 集體記憶

與那些為每個代理提供獨立記憶的框架不同，Meko 實作了一個累積系統。它支援五種不同的記憶類型：

• 工作記憶（Working Memory）：用於活躍任務的暫存狀態。
• 情節記憶（Episodic Memory）：任務歷史與互動日誌。
• 語意記憶（Semantic Memory）：持久的事實與領域知識。
• 程序記憶（Procedural Memory）：學習的工作流程與工具使用模式。
• 共享記憶（Shared Memory）：在同一 datapack 內所有代理協調的共同基礎。

當代理學到新資訊時，該資訊會自動從私有記憶提升至共享知識層，惠及系統中所有其他代理。

2. 統一知識

AI 系統的知識是動態的。Meko 會自動處理多樣來源——PDF、SQL 表格、HTML 與即時資料流——產生向量與摘要，無需手動建置管線。

這使得「混合查詢」成為可能：代理可以一次性檢索在特定時間範圍內、語意相似且帶有特定 ID 標籤的資料，全部透過單一 PostgreSQL 陳述式完成，而不必分三次向不同資料庫發起往返。

3. 決策追蹤（Decision Traces）

對於生產系統而言，信任與可稽核性是不可妥協的。Meko 捕捉 decision traces，即完整的思考鏈路，包含最初的提示、代理的計畫、工具呼叫以及隨後的知識更新。這對於遵循如 EU AI Act 等法規尤為關鍵，該法規可能要求對高風險 AI 系統的決策記錄進行長期保存。

4. 分層對話（Tiered Conversations）

為了在效能與成本之間取得平衡，Meko 採用三層儲存模型來管理對話歷史：

• 熱儲存（Hot Storage）：近期對話保留於 YugabyteDB，具毫秒級延遲。
• 暖儲存（Warm Storage）：較舊的對話自動分層至 S3 物件儲存。
• 冷儲存（Cold Storage）：超過特定時間窗口後，只保留摘要，完整逐字紀錄則仍保留以備完整性需求。

基礎設施與整合

Meko 建構於 YugabyteDB 之上，這是一個水平擴展、相容 PostgreSQL 的分散式資料庫。它允許在單一層面同時支援 SQL、NoSQL、向量、時間序列與圖形查詢。

由於遵循 MCP 標準，Meko 能與 Claude Code、Claude Desktop、Cursor 等工具無縫整合。其無伺服器、多租戶架構特別針對代理工作負載的突發性進行調校，確保閒置代理幾乎不消耗資源，而活躍代理則能即時擴展。

生產模式摘要

Meko 設計支援工程團隊的六大關鍵模式：

1. 保留上下文的交接：推理與結果一併傳遞。
2. 集體學習：教訓跨工作流程持久化。
3. 可稽核追蹤：完整可追溯性以符合法規與調校需求。
4. 經濟化歷史：對話紀錄自動分層。
5. 代理可恢復性：完整狀態持久化，支援暫停與恢復執行。
6. 可移植的專案記憶：跨團隊共享程式碼標準與慣例。