LLM

同一週 Hacker News 上有四篇文章我一起讀完,發現它們在問同一件事,只是切入點不同。表面上一篇談思考、一篇談工作、一篇談真誠、一篇在吐槽 Claude 的口頭禪,毫不相干。但把它們擺在一起,共同的主軸只有一句話: 當 AI 什麼都能代勞,哪一塊還算是人的。 前三篇從正面論證這條線該畫在哪;第四篇是這條線在日常裡留下的刮痕——有人正在動手,把機器的口氣從自己的字裡刮掉。 思考:是你在想,還是它替你想 第一篇是 Yennie Jun 的 Offloading thinking to AI。 她想分開兩件常被混為一談的事:用 AI 自動化雜務,跟用 AI 替你決定該想什麼。前者省時間,她不反對;後者交出的,是判斷本身。 她引 Ken Liu 小說裡一個凡事問 AI 的角色——連早餐吃什麼、要不要跟對象在一起都讓助理決定——當作警示。也講自己在葡萄牙旅行時,和妹妹先自己推理一輪再去問 AI,發現「推理的過程本身」才是有價值的東西。 她的解法很溫和:用 AI 延伸、測試你的想法,而不是取代。文章裡最刺的一句是講那個 AI 助理: Tilly doesn’t just tell you what you want! She tells you what to think. 工作:從划船變成掌舵 第二篇是 Arvind Narayanan 的 What will be left for us to work on?。 他反炒作。主張 AI 不會靠某個單一突破一夜之間消滅工作,而是像電力改造工廠那樣花了四十年——真正的瓶頸在組織適配、法規、tacit knowledge,不在實驗室能力。 他打了幾個常見誤解:所謂「工作總量固定」的謬誤(productivity 提升不等於工作變少);ATM 普及後行員反而變多;AI coding 讓工程師更有生產力,但工程師沒有變少。 ...

這天我在整理自己的 AI agent 記憶系統,順手研究了兩個開源專案(TencentDB-Agent-Memory 和 obra/superpowers),挑出幾個值得學的改動。 其中兩個我沒自己下判斷,而是交給同一套流程:讓一個較快、較便宜的 model 實作,再讓另一個同型 model 去對抗式複審。兩個改動、同一套流程,結果卻相反——一個被否決、一個通過合併。 回頭看,決定結果的不是流程本身,是「複審手上有沒有客觀標準可以打」。 那套流程長什麼樣 拆成兩個角色,刻意用不同的 agent: 實作 agent:在隔離的 git worktree 改 code、自己驗證、commit、回報。 複審 agent:進同一個 worktree,被明確指示「去 refute 第一版的宣稱、找邊界 case」,不是幫忙背書。 關鍵設計只有一條:複審不能是實作者自己。實作者對自己寫的東西有動機說「大致還好」,這個動機本身就是盲點來源。 第一輪:一個排序改動,被 golden bench 打回 背景是記憶搜尋的排序,想從線性加權換成 RRF(reciprocal rank fusion)。 實作 agent 加了新模式、保留舊的當預設、跑了幾個 query 的 A/B 對照,自評「大部分持平,有一個 query 略差」,並宣稱測試通過。 複審 agent 做了實作 agent 沒做的一件事:跑 repo 裡本來就有的 golden benchmark。結果不太好看: MRR 從 0.675 掉到 0.188、Recall@1 從 0.60 掉到 0.07。15 題裡 8 題退步、0 題改善。不是「略差」,是全面退化。 一個真 bug:RRF 讀到的是四捨五入到小數點三位的顯示值。在低區分度的 query 上,幾百個候選塌成十來個相異值、出現 35-way 平手,排序退化成按掃檔順序抽籤。 一個空測試:複審做了突變測試——把舊路徑的一個關鍵係數整段拿掉,測試竟然全綠。所謂「測試通過」根本沒在保護舊行為。 判決:否決,branch 直接刪掉。舊的本來就是預設,零損失。 ...

為什麼把翻譯模型搬回本機 沉浸式翻譯（Immersive Translate）這類瀏覽器擴充預設走雲端 API，品質夠用，但有三個煩人的地方：網路 round-trip 是延遲主因、開「網頁語言檢測」每開一個 tab 就燒掉上千 token、敏感內容也得送出去。 翻譯是少數很適合丟給小模型的任務——它不需要通用推理，只要把一段文字準確地搬到另一個語言。一顆 1~2B 的翻譯專用模型在 Apple Silicon 上就跑得飛快，延遲、成本、隱私三件事一次解決。 我原本用的是 Tencent 的 Hunyuan-MT v2 1.8B（Hy-MT2-1.8B Q4_K_M，量化後 1.13GB），搭 llama.cpp 跑在一台 16GB 的 M4 上。在 M4 16GB 上實測約 72 tok/s，日常網頁、技術文件、字幕都夠。但用久了會撞到它的天花板。 1.8B 的弱點：跟 7B 同句對照就現形 同系列除了 1.8B 還有一顆 7B（Hy-MT2-7B，Q4_K_M 量化後磁碟上約 4.3 GiB；HuggingFace 頁面標 4.62 GB，差在 GiB 與 GB 的進位——這篇剛好在講單位）。把同一句餵給兩顆，差距很直接。以下都是 M4 16GB 上的實測輸出，目標語言只給泛稱「Traditional Chinese」： 來源句 1.8B Q4（~72 tok/s） 7B Q4（~19 tok/s） The Transformer is the backbone of… …現代大型语言模型的核心组件 …現代大型語言模型的核心 エヴァンゲリオン初号機にシンジが… 希真登上 EVA 初号机出击 真嗣駕駛初號機出擊 …about 1.1 gigabytes 模型文件大小约为 1.1 吉字节 模型檔案的大小約為 1.1 GB 差距落在三類。人名與單位是硬傷：日文人名「シンジ（真嗣）」1.8B 翻成不存在的「希真」、單位 gigabytes 翻成「吉字节」沒保留 GB；7B 兩個都對。這類要模型記得住約定俗成的譯名，1.8B 容量不夠，換 prompt 也救不回來。 ...

這是我們在 OpenClaw 系統實作記憶機制的心得，也是對「讓 AI Agent 學會做夢」一文的延伸。我們不談論文，只談踩過的坑和做出來的解法。 為什麼 AI Agent 需要記憶？ 不是所有 LLM 應用都需要記憶。一個回答使用者問題的客服機器人，問完就可以忘了；一個生成文案的工具，用完就走。但當 Agent 需要 長期運行、累積經驗、理解上下文，情況就完全不同了。 我們的 OpenClaw Agent 需要： 記住使用者的偏好（他喜歡高密度資訊，不愛廢話） 記住基礎設施的狀態（哪台機器開了、哪個服務掛過） 記住決策的來龍去脈（當初為什麼選這個方案） 沒有記憶，每次對話都是獨立的瞬間，Agent 永遠是新手。這就是我們要解決的問題。 難題一：壓縮 — context window 有限，保留什麼？ 問題 即使是 GPT-5.4 或 Claude 4.6，context window 終究有限。當記憶累積超過臨界點，你不可能把全部東西都塞進去。壓縮不是選項，是必然。 但壓縮代表選擇。選擇本身就是困難的： 哪些對話值得記住？ 抽象化（summarization）會不會丟失關鍵細節？ 如果壓縮演算法選錯了重要資訊，後果是什麼？ 業界做法 常見的壓縮策略有幾種： 方法 說明 缺點 簡單摘要 LLM 產出濃縮版本 容易遺漏細節，無法精確檢索 向量檢索 存 embedding， query 時召回 只能搜「相似」，無法知道「重要」 優先級排序 依重要性決定保留顆粒度 依賴準確的優先級判斷 我們的做法 我們採用 三層記憶架構，用「分層」取代「一次性壓縮」： daily memory（便簽）→ MEMORY.md（長期）→ reference/（結構化知識） daily memory：每天的 raw 紀錄，像貼在冰箱上的便利貼 MEMORY.md：萃取後的長期知識，需要主動維護 reference/：結構化資料（設定檔、API 文件、流程 SOP） 同時搭配 P 級優先級： ...

記憶的腐爛問題 跑了兩個月的 AI agent，記憶檔案從幾 KB 膨脹到幾十 KB。一開始沒什麼感覺，直到某天 agent 引用了一個三週前就被推翻的技術決策，我才意識到問題有多嚴重。 記憶不是寫進去就沒事了。沒有維護的記憶，比沒有記憶更危險——因為 agent 會很有信心地根據過時資訊做決策。 人類的記憶會在睡眠中自動整理：重要的強化、矛盾的修正、不用的淡化。AI agent 的記憶沒有這個機制，所以得自己造一個。 靈感來源：Karry 的 Orb 直接觸發這個想法的，是 Karry 寫的一篇文章：《認知アップグレードの本当のループ——AI Agent の記憶設計から學んだ 3 つのこと》。 Karry 運營自己的 AI agent「Orb🔮」超過兩個月，得出一個跟主流完全不同的結論：記憶系統的核心不是 Vector DB，是認知循環。他指出三個真正的難題： 什麼時候該忘？ — 頻率衰減不夠用，年用一次但救命的記憶不能丟 AI 會捏造記憶 — 搜尋結果為空 ≠ 記錄不存在 教訓寫了也不一定有效 — 「知道」和「做到」之間有巨大的鴻溝 他的解法是三層記憶（L0 原始日誌 → L1 回顧摘要 → L2 長期記憶）加上「Hard Constraint」——犯錯兩次就強制鎖死，不靠自覺靠系統。 這些觀點跟我自己踩坑的經驗高度吻合，但我的問題不完全一樣。Karry 著重在「怎麼讓記憶影響行為」，我面對的是更前面一步：怎麼讓記憶自己保持乾淨。 Orb 做了什麼，我做了什麼不同 Karry 的 Orb 和我的 agent 有很多共通點——都用 Markdown 檔案、都分層、都相信簡單架構。但設計哲學有幾個明顯的差異： Karry’s Orb 我的做法 記憶儲存 Markdown + LLM 多段抽取 Markdown + LLM，但加了 Gemini embedding 做向量索引 遺忘策略 P0/P1/P2 分級 + 人工 review P0/P1/P2 分級 + 自動化腳本 (janitor/expire) 防呆機制 Hard Constraint（犯兩次就鎖） 分析/執行分離（反芻只建議，main session 決策） 獨特機制 — 「做夢」——冷記憶隨機抽取找跨領域洞察 記憶維護 LLM 每日抽取 cron 四件套：janitor + reflect + dream + expire 矛盾處理 手動 反芻引擎自動檢測，但人工確認修改 最大的差異是：Karry 更信任 agent 自己管記憶（自動壓縮、自動昇格），我更偏向讓 agent 當顧問、人類做最終決策。 ...