從文言文到 AST：AI Agent Memory 語義壓縮的可行性分析

Tue, 14 Apr 2026 00:01:00 +0800

古代人刻竹簡、抄手稿，每個字的儲存成本都極高。這個物理限制直接塑造了文言文的語言風格——用最少的字，傳遞最密集的語意。

這不只是文化，是工程決策。

當我開始思考 AI agent 的 memory 管理問題，這個古老的邏輯突然變得非常現代。

文言文是一種有損壓縮格式

從資訊理論的角度看，文言文是一套高壓縮比、高解碼成本的編碼系統。

竹簡有重量，有體積，刻寫需要工時。這些都是實體成本。當儲存成本極高時，語言會朝向低熵方向演化：

虛詞能省則省
語境依賴極重（解碼需要大量背景知識）
歧義換取密度（讀者端承擔解壓縮負擔）

對比白話文：

	文言文	白話文
壓縮率	高	低
自解釋性	低（需訓詁）	高
儲存成本	低	高
解碼門檻	高	低

有趣的是，活版印刷大幅降低了複製成本，照理說語言應該走向白話——但文言文仍然主導書面世界數百年。因為寫作者的習慣與社會認可機制的慣性，遠比技術變革的速度慢。

白話文運動最終發生，更多是政治與教育普及的需求，而非技術成本。

這個觀察本身就是一個警示：即使最優解存在，系統切換的成本可能讓它長期無法落地。

Token 是現代的竹簡

AI agent 每次被呼叫，都需要把 memory 塞進 context window。Token 是直接成本：計費、速度、context 容量，都和 token 數量正相關。

現有的 memory 格式大多長這樣：

memory 範例：prose 格式

name: 回應風格偏好 type: feedback

使用者偏好簡潔回應，不喜歡在結尾加摘要總結。 Why: 他說他可以自己讀 diff，不需要 AI 重複說明已完成的事。 How to apply: 每次回應結尾不要加「以上是本次修改的摘要」之類的段落。

這是白話文。結構清晰，人讀得懂，但對機器來說充滿冗餘。

如果我們用文言文的邏輯重新設計：

no-trailing-summary; trigger=response_end; reason=user_reads_diff

同樣的語意，token 省了 70% 以上。

關鍵洞察：memory 的唯一讀者是 AI agent

這裡有一個根本性的問題值得釐清：

memory 是為誰而寫的？

傳統 memory 設計預設「人需要能讀懂」，所以用完整句子、加 Why 說明、保留上下文。但仔細想，memory 的實際讀者是 agent 本身。人審查 memory 是偶發需求，不是主流路徑。

這意味著：

human-readable 在大多數情境下是偽需求
壓縮的唯一硬性約束是：agent 能 100% decode
其餘的可讀性成本，都是在為一個低頻需求買單

這個邏輯和 LLM embedding 是一樣的：向量記憶體對人完全不可讀，但 agent 的 retrieve 語意還原率反而更高。文字 memory 之所以還在用，是因為人需要 audit 能力，而不是因為它對機器更好。

從 AST 借鑑結構化表示

這時候自然會想到 AST（Abstract Syntax Tree，抽象語法樹）。

在編譯器領域，AST 是把原始碼轉成**結構化中間表示（IR）**的標準手法。原始碼是給人讀的（高冗餘），AST 是給編譯器處理的（結構化、可操作）。

把這個概念移植到 memory：

flowchart TD
 A["自然語言 memory（原始碼）"] -->|encode| B["AST memory node（IR）"]
 B -->|retrieve + decode| C["agent 行為"]

具體長這樣：

{
 "type": "behavior_rule",
 "trigger": { "context": "response_end" },
 "action": { "suppress": "summary" },
 "condition": { "user_action": "reads_diff" },
 "confidence": 0.95,
 "raw": "user reads diff directly, finds summaries redundant"
}

AST 相對於 prose memory 的優勢

可 diff：兩條 rule 衝突時，agent 比較節點而非解析自然語言，衝突偵測可以程式化。

可 merge：新 observation 進來時，patch 特定節點而非整段重寫，incremental update 成本低。

可 query：trigger.context == "response_end" 精確 retrieve，不依賴語義相似度，查詢結果確定。

可繼承：子節點 override 父節點，類似 CSS cascade，可以做 context-specific 的行為覆寫。

可版本化：節點帶 schema version，memory 格式演化時可以做 migration 而非全部重寫。

這個設計的根本張力

AST 設計看起來很美，但有一個繞不開的核心問題：

張力一：固定 schema vs 表達彈性

程式語言的 AST 有嚴格 grammar，語義確定。Memory 的 schema 需要人工設計，而觀察的種類是開放的——你無法預先定義所有可能的 node type。

Fixed ontology：查詢效率高，但遇到 schema 外的觀察無處放
Emergent schema：表達彈性高，但查詢一致性差

這是一個目前沒有標準答案的開放問題。

張力二：壓縮率 vs decode 完整性

文言文的問題是「解壓縮密鑰丟失後語義崩潰」。過度壓縮的 memory：

換模型或換 session 可能 decode 失敗
Edge case 無法判斷適用性
encode 錯誤無聲無息傳播

最優解不是最大壓縮，而是「剛好能讓同等智力的讀者正確 decode 的最小表達」——這其實也是文言文的設計目標，只是它的「同等智力讀者」預設了四書五經作為共同解碼器。

AI agent 的「共同解碼器」是 pre-training，這個基礎是穩定的，但並非無限可靠。

張力三：auditability vs 壓縮上限

如果完全移除「人要能審查」的約束，理論上可以讓 agent 自己設計一套極度壓縮的內部語言，壓縮率可以趨近理論上限。但你同時失去了：

偵測 encode 錯誤的能力
理解 agent 行為的能力
手動修正錯誤 memory 的能力

auditability 的要求，決定了壓縮的上限。

Hybrid 格式：務實的折衷

考慮以上三個張力，純 AST 和純 prose 都不是最優解。Hybrid 格式更接近實際可落地的方向：

{
 "type": "behavior_rule",
 "trigger": "response_end",
 "action": "suppress_summary",
 "raw": "user reads diff directly, finds summaries redundant"
}

結構化 header 負責 routing 和 query，raw 欄位保留自然語言作為 decode 邊界情況的 fallback。

這類似文言文後來發展出的注疏傳統——正文高度壓縮，注疏提供解碼上下文，兩者合讀才是完整資訊。

Python 作為統一引擎

如果要實作這個 memory 系統，Python 是自然的選擇。

更進一步，可以設計單一引擎、雙介面的架構：

memory_engine.py
├── CLI interface ← Bash tool 直接呼叫
│ python memory_engine.py encode "..."
│ python memory_engine.py query "response_end"
│ python memory_engine.py merge <node_id>
│ python memory_engine.py audit
│
└── Skill interface ← agent 透過 prompt 觸發
 複合操作、判斷 subcommand、串接多個操作

同一份邏輯，兩個 entry point，DRY 原則。

if __name__ == "__main__":
 parser = argparse.ArgumentParser()
 parser.add_argument("command", choices=["encode","query","merge","audit"])
 parser.add_argument("input", nargs="?")
 args = parser.parse_args()
 result = globals()[args.command](args.input)
 print(json.dumps(result, ensure_ascii=False))

encode 時需要 LLM 做語義解析，這裡有一個設計選擇：由 Python 內部發 API call，還是由 agent 自己解析後把結果傳給 script？前者讓引擎更自治，後者讓引擎更確定性。這個選擇影響整個依賴架構，值得獨立討論。

可行性小結

面向	結論
基本邏輯	成立。memory 本來就是給 agent 讀的，改成更結構化、更省 token 的格式是合理方向
實作難度	可控。LLM 已經能穩定輸出 structured output，Python 也足夠處理 encode、query、merge、audit
主要風險	encode 錯誤傳播、schema 太硬、壓得太短導致 agent decode 失敗
需要取捨的地方	壓縮率、可讀性、可審查性三者不可能同時最大化
可參考方向	MemGPT、Knowledge Graph + LLM、Minimum Description Length（MDL）

核心結論：方向可行，但不適合一開始就追求極限壓縮。比較務實的做法，是先用 hybrid 格式保留必要上下文，再逐步把穩定、重複出現的 memory 壓成結構化節點。

後記

文言文撐了兩千年，不是因為它最好讀，而是因為它在當時的成本結構下是最優解。當成本結構改變（印刷術、白話文運動），語言才真正轉型。

AI memory 目前的「白話文」格式，是在 context window 相對充裕、token 成本可接受的前提下成立的。當 agent 開始大規模運作、memory 數量指數成長，成本結構會變，最優解也會跟著變。

現在思考壓縮，不是為了立刻重寫所有 memory，而是為了在成本結構改變的時候，不用從零開始想。

Stan Wu 吳信典

從文言文到 AST：AI Agent Memory 語義壓縮的可行性分析

文言文是一種有損壓縮格式

Token 是現代的竹簡

關鍵洞察：memory 的唯一讀者是 AI agent

從 AST 借鑑結構化表示

AST 相對於 prose memory 的優勢

這個設計的根本張力

張力一：固定 schema vs 表達彈性

張力二：壓縮率 vs decode 完整性

張力三：auditability vs 壓縮上限

Hybrid 格式：務實的折衷

Python 作為統一引擎

可行性小結

後記