古代人刻竹簡、抄手稿，每個字的儲存成本都極高。這個物理限制直接塑造了文言文的語言風格——用最少的字，傳遞最密集的語意。
這不只是文化，是工程決策。
當我開始思考 AI agent 的 memory 管理問題，這個古老的邏輯突然變得非常現代。
文言文是一種有損壓縮格式
從資訊理論的角度看，文言文是一套高壓縮比、高解碼成本的編碼系統。
竹簡有重量，有體積，刻寫需要工時。這些都是實體成本。當儲存成本極高時，語言會朝向低熵方向演化：
- 虛詞能省則省
- 語境依賴極重（解碼需要大量背景知識）
- 歧義換取密度（讀者端承擔解壓縮負擔）
對比白話文：
有趣的是，活版印刷大幅降低了複製成本，照理說語言應該走向白話——但文言文仍然主導書面世界數百年。因為寫作者的習慣與社會認可機制的慣性，遠比技術變革的速度慢。
白話文運動最終發生，更多是政治與教育普及的需求，而非技術成本。
這個觀察本身就是一個警示：即使最優解存在，系統切換的成本可能讓它長期無法落地。
Token 是現代的竹簡
AI agent 每次被呼叫，都需要把 memory 塞進 context window。Token 是直接成本：計費、速度、context 容量，都和 token 數量正相關。
現有的 memory 格式大多長這樣：
這是白話文。結構清晰，人讀得懂，但對機器來說充滿冗餘。
如果我們用文言文的邏輯重新設計：
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：
具體長這樣：
{
"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？前者讓引擎更自治，後者讓引擎更確定性。這個選擇影響整個依賴架構，值得獨立討論。
可行性小結
核心結論：方向可行，但不適合一開始就追求極限壓縮。比較務實的做法，是先用 hybrid 格式保留必要上下文，再逐步把穩定、重複出現的 memory 壓成結構化節點。
後記
文言文撐了兩千年，不是因為它最好讀，而是因為它在當時的成本結構下是最優解。當成本結構改變（印刷術、白話文運動），語言才真正轉型。
AI memory 目前的「白話文」格式，是在 context window 相對充裕、token 成本可接受的前提下成立的。當 agent 開始大規模運作、memory 數量指數成長，成本結構會變，最優解也會跟著變。
現在思考壓縮，不是為了立刻重寫所有 memory，而是為了在成本結構改變的時候，不用從零開始想。
想看更多作品、服務與主站整理，請前往 stanwu.org。
