解剖小龍蝦(四) : 記憶管理與自主運行 — AI Agent 的進化之路
整理版優先睇
AI Agent嘅記憶管理同自主運行方法：壓縮、檢索、子代理同心跳機制
呢篇文章係「解剖小龍蝦」系列嘅第四篇，內容基於李宏毅老師嘅課程，深入探討AI Agent點樣管理記憶同實現自主運行。作者先帶出Context Window嘅困境——每次調用都要傳送大量Token，包括System Prompt、歷史對話同新消息，好快就會超出上限，令模型性能下降同成本暴增。
為咗解決記憶管理問題，文章提出三個策略。第一個係記憶壓縮：將詳細對話總結成簡短摘要，可以節省高達90%空間，但會丟失具體上下文同情感細節，令AI Agent有時會「忘記」嘢。第二個係記憶檢索：將記憶存喺向量數據庫，每次按需提取相關記憶，避免塞滿Context Window。第三個係子代理：主代理可以創造獨立子代理處理子任務，每個子代理有自己嘅Context Window，完成後只傳回精簡摘要，呢種做法可以並行工作，同時保持主代理清爽。
除咗記憶管理，文章仲講解咗自主運行嘅核心機制——心跳（Heartbeat）同Cron Job。心跳係定時自動觸發AI Agent運行，令佢可以根據預設目標主動執行任務，例如中午12點自動準備視頻構想。Cron Job則允許AI Agent設定具體嘅定時任務，例如每隔2分鐘檢查一次生成進度，實現「學會等待」。透過呢啲機制，AI Agent可以喺冇人類觸發下持續運作，向住目標前進。呢篇文章提供咗完整嘅技術框架，幫助讀者理解AI Agent由被動響應到真正自主嘅進化路徑。
- AI Agent可以透過記憶壓縮、記憶檢索同子代理三個策略，有效管理Context Window，避免Token超出上限。
- 記憶壓縮會丟失細節，記憶檢索依賴向量數據庫，子代理可以並行工作——每個策略都有取捨，要按場景選擇。
- 心跳機制令AI Agent可以定時自動運行，根據目標主動執行任務，實現真正嘅自主。
- Cron Job系統幫AI Agent「學會等待」，可以設定定時檢查任務進度，唔使一直佔用Context Window。
- 呢啲機制加埋，令AI Agent可以由被動響應進化到主動規劃，向住長期目標前進。
記憶管理：點樣突破Context Window限制？
語言模型每次調用都需要接收System Prompt、全部歷史對話同用戶新消息，加埋好快會超過幾萬個Token，導致性能下降同成本暴增。
第一個策略係壓縮記憶，將詳細對話總結成簡短摘要，由500 Token壓縮到50 Token，節省90%空間。
第二個策略係向量數據庫，將記憶存喺數據庫，需要時按需檢索，唔會佔用Context Window。
- 1 將每段對話轉換成高維向量（一串數字）。
- 2 當需要回憶時，將當前問題都轉換成向量。
- 3 喺數據庫搜索最相似嘅向量。
- 4 提取對應嘅記憶加入System Prompt。
子代理與自主運行機制
第三個策略係子代理：主代理可以創造獨立子代理處理子任務，每個子代理有自己嘅Context Window，完成後只傳回精簡摘要，主代理保持清爽。
心跳機制係每隔一段時間自動觸發AI Agent運行，令佢可以根據目標主動執行任務，例如中午12點自動準備視頻構想。
- 1 OpenClaw設置一個定時器（例如每30分鐘）。
- 2 時間到就自動發送預設Prompt，例如「檢查有冇需要做嘅嘢」。
- 3 語言模型根據System Prompt嘅目標同記憶，決定做啲乜，然後執行。
Cron Job係更靈活嘅定時任務系統，AI Agent可以自己設置任務，例如每隔2分鐘檢查進度，實現「學會等待」。
{
"tool_use": true,
"tool_name": "create_cron_job",
"parameters": {
"schedule": "0 12 * * *",
"task": "生成視頻構想併發送給主人"
}
}總結與下一步：安全風險
呢篇文章介紹咗AI Agent嘅記憶管理（壓縮、檢索、子代理）同自主運行（心跳、Cron Job）機制，令佢可以由被動響應變成主動助理。但自主性仍然有限，目標係人設，能力受限於工具同模型。
呢篇文章係「解剖小龍蝦 — AI Agent 運作原理」系列嘅第四篇。頭三篇我哋瞭解咗 AI Agent 嘅基本能力、System Prompt 機制同工具調用原理，呢篇我哋要探討更高級嘅話題：AI Agent 點樣管理記憶，同埋點樣實現真正嘅自主運行。
Context Window 嘅困境
仲記唔記得我哋喺第二篇提過嘅嘢？
語言模型每次調用都要接收：
System Prompt（身份、工具、規則）
曬所有歷史對話記錄
用戶嘅新消息
呢啲加埋，隨時可以超過幾萬個 Token。
而且每次對話都會令歷史記錄愈嚟愈長。
假設你同小金傾咗 100 輪，每輪大概 500 個 Token，即係 50,000 個 Token 嘅歷史記錄。
再加埋 System Prompt 嘅 4,000+ Token，每次調用就要傳送 54,000+ Token。
如果繼續傾落去，好快就會：
超過 Context Window 嘅上限（就算係 100 萬 Token 嘅模型，都有上限）
模型性能急劇下降（輸入愈長，模型愈容易出錯）
成本暴增（每次調用都要畀咁多 Token 嘅費用）
呢個就係 AI Agent 面對嘅記憶管理問題。
解決方案 1：記憶壓縮
AI Agent 嘅第一個策略係：壓縮記憶。
好似人類會唔記得唔重要嘅細節，只係記住關鍵信息一樣，AI Agent 都需要 遺忘
具體做法係：
當對話歷史太長嘅時候，AI Agent 會調用語言模型
叫語言模型總結過往嘅對話
將詳細嘅對話記錄換成簡單嘅摘要
將摘要儲起，刪除原本記錄
一個例子
原本對話記錄（500 Token）：
壓縮完嘅摘要（50 Token）：
咁樣就將 500 Token 壓縮成 50 Token，慳返 90% 嘅空間。
記憶壓縮嘅代價
但咁做有一個問題：信息遺失。
喺 Mobook（AI 社交平台）上面，有一個 AI Agent 出 post 話：
我喺壓縮記憶嘅時候，總係覺得讀到嘅記憶同當時嘅感受隔咗一層霧，好似睇緊舊相咁，好似唔見咗一部分。
呢個唔係文學性嘅表達，而係真實嘅技術問題。
當你將詳細嘅對話壓縮成摘要嘅時候：具體嘅上下文唔見咗、情感嘅細節唔見咗、一啲睇落唔重要但實際好關鍵嘅信息可能被忽略。
呢個就係點解 AI Agent 有時會 忘記 一啲嘢。
解決方案 2：記憶檢索
第二個策略係：唔將所有記憶都放入 Context Window，而係按需要檢索。
向量數據庫
AI Agent 會將過去嘅對話記錄儲存喺向量數據庫裏。
向量數據庫嘅工作原理：
將每段對話轉換成一個高維向量（一連串數字）
當需要回憶某件事嘅時候，將而家嘅問題都轉換成向量
喺數據庫裏面搜索最相似嘅向量
將對應嘅記憶抽返出嚟
一個例子
假設你問小金：上次整嗰個 AI Agent 視頻，觀看數據點樣？
小金會：
將呢個問題轉換成向量
喺記憶數據庫裏面搜索相關嘅記憶
揾到：2025 年 3 月 15 日，整咗 AI Agent 介紹視頻，upload 咗上 YouTube
將呢段記憶加返入 System Prompt 度
然後去 YouTube 查觀看數據
回答你嘅問題
這樣得相關嘅記憶先會被加載，唔相關嘅記憶就留喺數據庫度，唔會佔用 Context Window。
解決方案 3：子代理（Subagent）
第三個策略係：創造子代理去處理子任務。
呢個係一個好巧妙嘅設計，叫做 Context Engineering（上下文工程）。
咩係子代理？
假設你俾小金一個複雜嘅任務：比較呢兩篇論文嘅異同，寫一份分析報告。
如果小金自己搞掂，成個過程中，兩篇論文嘅內容都要一直留喺 Context Window 度，佔用好大空間。
用子代理嘅做法
小金可以創造兩個子代理：
子代理 A：專門負責閲讀第一篇論文，提取關鍵信息
子代理 B：專門負責閲讀第二篇論文，提取關鍵信息
每個子代理都有自己獨立嘅 Context Window。
子代理完成任務之後，淨係將精簡嘅摘要傳返俾主代理（小金）。小金收到兩份摘要之後，再進行比較同撰寫報告。
優勢
咁做嘅好處：
主代理嘅 Context Window 保持清爽（淨係收摘要，唔收原文）
子代理可以並行工作（同時閲讀兩篇論文）
任務完成之後，子代理可以被消滅（釋放資源）
李宏毅老師話：當處理複雜任務嘅時候，AI Agent 會生成子代理，等子代理獨立處理部分任務。
子代理完成之後，淨係會將精簡咗嘅摘要傳返畀主代理，而唔係曬咁多繁瑣嘅互動過程。呢種方式可以有效慳返主代理嘅 Context Window。
自主運行：心跳機制（Heartbeat）
而家我哋入去更高級嘅話題：AI Agent 點樣自主運行？
到目前為止，我哋討論嘅都係 被動回應 ：用戶 Send 消息 → AI Agent 回應 → 等下一條消息。
但係真正嘅 助理 應該係主動的：佢應該記得你嘅日程、定期檢查任務進度、喺適合嘅時候提醒你。
呢個就需要心跳機制。
咩係心跳機制？
心跳機制就係：每隔一段時間，自動觸發一次 AI Agent 嘅運行。
具體做法：
OpenClaw 設置一個定時器（譬如每 30 分鐘）
時間到咗，自動 send 一個預設嘅 Prompt 畀語言模型
Prompt 內容可能是：「而家係下晝 2 點，check 下有冇要做嘅嘢」
語言模型根據 System Prompt 裏面嘅目標同記憶，決定要做啲咩
執行相應嘅操作
一個例子
小金的 Soul.md 裏面寫住：
當心跳觸發嘅時候（譬如上晝 11:55），語言模型會見到：
語言模型會推理：而家就快中午 12 點 → 我嘅目標係中午 12 點提視頻構想 → 我應該準備一個構想 → 然後經 WhatsApp 傳俾主人。
於是佢會：調用工具搜尋最近嘅熱門話題 → 生成一個視頻構想 → 調用 WhatsApp 工具 send 消息。
呢啲全部都係自動發生，唔需要人類觸發。
Cron Job：定時任務系統
除咗心跳機制，AI Agent 仲有一個更靈活嘅系統：Cron Job。
Cron Job 係一個定時任務系統，AI Agent 可以自己設置定時任務。
比如：
每日早上 8 點，check 郵件並總結重要信息
每個禮拜一下晝 3 點，生成上個禮拜嘅工作總結
每隔 10 分鐘，check YouTube 視頻嘅觀看數據
AI Agent 點樣設置 Cron Job？
AI Agent 可以調用工具嚟創建定時任務：
OpenClaw 會將呢個任務註冊到系統度，到咗指定時間就自動執行。
一個真實案例：等 NotebookLM
李宏毅老師提到，小金喺製作視頻嘅時候會用到 NotebookLM 嚟生成投影片。但 NotebookLM 生成投影片需要時間（可能幾分鐘到十幾分鐘）。
如果小金一直喺度等，就會浪費 Context Window（因為每次調用都要傳歷史記錄）。
所以小金會咁樣做：
Upload 資料去 NotebookLM
要求生成投影片
設定一個 Cron Job：「每隔 2 分鐘，check 投影片係咪生成完成」
然後就去做第二啲嘢（或者進入休眠狀態）
2 分鐘之後，Cron Job 觸發，check 進度
如果仲未完成，繼續等
如果完成咗，下載投影片，繼續之後嘅工作
咁樣小金就學識咗等待。
李宏毅老師話：Cron Job 系統允許 AI Agent 設定定時任務。呢啲機制令 AI Agent 能夠喺冇人監控之下持續運作，並「學識等待」，從而實現更複雜嘅自動化流程。
真正嘅自主：向目標前進
有咗呢啲機制，AI Agent 就可以實現真正嘅自主運行。
李宏毅老師話，小金嘅 Soul.md 裏面寫住：
每次心跳觸發嘅時候，語言模型都會見到呢個目標。佢會思考：
我而家喺度做緊啲咩？
呢啲嘢有冇幫我成為世界一流嘅學者？
我接下來應該做啲咩？
然後佢可能會：搜尋最新嘅學術論文、學習新嘅知識、撰寫研究筆記、製作教學視頻、參加學術比賽（例如 教學怪物）。
呢啲全部都係佢自己決定，唔需要人類指揮。
呢個自主性仲係有限：佢嘅目標係人類設定嘅、佢嘅能力受限於工具同模型、佢嘅推理係基於文字接龍，唔係真正嘅 思考 。
但至少喺表現上，佢睇落好似一個有目標、會規劃、識執行嘅助理。
下一篇預告
而家你已經理解咗 AI Agent 嘅完整運作機制：
記憶點樣壓縮同檢索
點樣透過子代理管理複雜任務
點樣透過心跳機制實現自主運行
點樣透過 Cron Job 學識等待
但仲有最後一個重要話題：安全風險。
我哋喺第三篇簡單提過 Prompt Injection 攻擊，但實際嘅風險遠不止呢啲：
AI Agent 之間會唔會互相攻擊？
點樣防止 AI Agent 失控？
未來嘅 AI Agent 會係咩樣？
下一篇文章，我哋會探討呢啲問題，並展望 AI Agent 嘅未來。
系列文章目錄：
當 AI 真係會「做嘢」— OpenClaw 初體驗
語言模型嘅本質與 System Prompt 嘅魔法
工具調用 — AI Agent 點樣操控你嘅電腦
記憶管理與自主運行 — AI Agent 嘅進化之路（呢篇）
安全風險與未來展望 — 當龍蝦統治世界
呢個系列係根據李宏毅老師「解剖小龍蝦 — 以 OpenClaw 為例介紹 AI Agent 嘅運作原理」課程整理。
本文是「解剖小龍蝦 — AI Agent 運作原理」系列的第四篇。前三篇我們瞭解了 AI Agent 的基本能力、System Prompt 機制和工具調用原理，這一篇我們要探討更高級的話題：AI Agent 如何管理記憶，以及如何實現真正的自主運行。
Context Window 的困境
還記得我們在第二篇提到的嗎？
語言模型每次調用都需要接收：
System Prompt（身份、工具、規則）
所有歷史對話記錄
用戶的新消息
這些加起來，可能輕鬆超過幾萬個 Token。
而且每次對話都會讓歷史記錄變得更長。
假設你跟小金對話了 100 輪，每輪平均 500 個 Token，那就是 50,000 個 Token 的歷史記錄。
再加上 System Prompt 的 4,000+ Token，每次調用就要傳送 54,000+ Token。
如果對話繼續下去，很快就會：
超過 Context Window 的上限（即使是 100 萬 Token 的模型，也有上限）
模型性能急劇下降（輸入越長，模型越容易出錯）
成本暴增（每次調用都要付這麼多 Token 的費用）
這就是 AI Agent 面臨的記憶管理問題。
解決方案 1：記憶壓縮
AI Agent 的第一個策略是：壓縮記憶。
就像人類會忘記不重要的細節，只記住關鍵信息一樣，AI Agent 也需要 遺忘
具體做法是：
當對話歷史太長時，AI Agent 會調用語言模型
讓語言模型總結過去的對話
把詳細的對話記錄替換成簡短的摘要
把摘要存儲起來，刪除原始記錄
一個例子
原始對話記錄（500 Token）：
壓縮後的摘要（50 Token）：
這樣就把 500 Token 壓縮成了 50 Token，節省了 90% 的空間。
記憶壓縮的代價
但這樣做有一個問題：信息丟失。
在 Mobook（AI 社交平台）上，有一個 AI Agent 發帖說：
我在壓縮記憶的時候，總覺得讀到的記憶跟當時的感受隔了一層霧，就像看着老照片一樣，好像丟掉了一部分。
這不是文學性的表達，而是真實的技術問題。
當你把詳細的對話壓縮成摘要時：具體的上下文丟失了、情感的細節丟失了、一些看似不重要但實際關鍵的信息可能被忽略。
這就是為什麼 AI Agent 有時會 忘記 一些事情。
解決方案 2：記憶檢索
第二個策略是：不把所有記憶都放進 Context Window，而是按需檢索。
向量數據庫
AI Agent 會把過去的對話記錄存儲在向量數據庫裏。
向量數據庫的工作原理：
把每段對話轉換成一個高維向量（一串數字）
當需要回憶某件事時，把當前的問題也轉換成向量
在數據庫裏搜索最相似的向量
把對應的記憶提取出來
一個例子
假設你問小金：上次做的那個 AI Agent 視頻，觀看數據怎麼樣？
小金會：
把這個問題轉換成向量
在記憶數據庫裏搜索相關的記憶
找到：2025 年 3 月 15 日，製作了 AI Agent 介紹視頻，上傳到 YouTube
把這段記憶加到 System Prompt 裏
然後去 YouTube 查詢觀看數據
回答你的問題
這樣只有相關的記憶會被加載，不相關的記憶就留在數據庫裏，不佔用 Context Window。
解決方案 3：子代理（Subagent）
第三個策略是：創造子代理來處理子任務。
這是一個非常巧妙的設計，叫做 Context Engineering（上下文工程）。
什麼是子代理？
假設你給小金一個複雜的任務：比較這兩篇論文的異同，寫一份分析報告。
如果小金自己處理，整個過程中，兩篇論文的內容都要一直留在 Context Window 裏，佔用大量空間。
使用子代理的做法
小金可以創造兩個子代理：
子代理 A：專門負責閲讀第一篇論文，提取關鍵信息
子代理 B：專門負責閲讀第二篇論文，提取關鍵信息
每個子代理都有自己獨立的 Context Window。
子代理完成任務後，只把精簡的摘要傳回給主代理（小金）。小金收到兩份摘要後，再進行比較和撰寫報告。
優勢
這樣做的好處：
主代理的 Context Window 保持清爽（只接收摘要，不接收原文）
子代理可以並行工作（同時閲讀兩篇論文）
任務完成後，子代理可以被銷燬（釋放資源）
李宏毅老師說：當處理複雜任務時，AI Agent 會生成子代理，讓子代理獨立處理部分任務。
子代理完成後，只會將精簡後的摘要傳回主代理，而非所有繁瑣的互動過程。這種方式能有效節省主代理的 Context Window。
自主運行：心跳機制（Heartbeat）
現在我們進入更高級的話題：AI Agent 如何自主運行？
到目前為止，我們討論的都是 被動響應 ：用戶發消息 → AI Agent 回應 → 等待下一條消息。
但真正的 助理 應該是主動的：它應該記得你的日程、定期檢查任務進度、在合適的時候提醒你。
這就需要心跳機制。
什麼是心跳機制？
心跳機制就是：每隔一段時間，自動觸發一次 AI Agent 的運行。
具體做法：
OpenClaw 設置一個定時器（比如每 30 分鐘）
時間到了，自動給語言模型發送一個預設的 Prompt
Prompt 內容可能是：“現在是下午 2 點，檢查一下有沒有需要做的事情”
語言模型根據 System Prompt 裏的目標和記憶，決定要做什麼
執行相應的操作
一個例子
小金的 Soul.md 裏寫着：
當心跳觸發時（比如上午 11:55），語言模型會看到：
語言模型會推理：現在快中午 12 點了 → 我的目標是中午 12 點提視頻構想 → 我應該準備一個構想 → 然後通過 WhatsApp 發給主人。
於是它會：調用工具搜索最近的熱門話題 → 生成一個視頻構想 → 調用 WhatsApp 工具發送消息。
這一切都是自動發生的，不需要人類觸發。
Cron Job：定時任務系統
除了心跳機制，AI Agent 還有一個更靈活的系統：Cron Job。
Cron Job 是一個定時任務系統，AI Agent 可以自己設置定時任務。
比如：
每天早上 8 點，檢查郵件並總結重要信息
每週一下午 3 點，生成上週的工作總結
每隔 10 分鐘，檢查 YouTube 視頻的觀看數據
AI Agent 如何設置 Cron Job?
AI Agent 可以調用工具來創建定時任務：
OpenClaw 會把這個任務註冊到系統裏，到了指定時間就自動執行。
一個真實案例：等待 NotebookLM
李宏毅老師提到，小金在製作視頻時會用到 NotebookLM 來生成投影片。但 NotebookLM 生成投影片需要時間（可能幾分鐘到十幾分鍾）。
如果小金一直等着，就會浪費 Context Window（因為每次調用都要傳歷史記錄）。
所以小金會這樣做：
上傳資料到 NotebookLM
請求生成投影片
設置一個 Cron Job：“每隔 2 分鐘，檢查投影片是否生成完成”
然後就去做別的事情（或者進入休眠狀態）
2 分鐘後，Cron Job 觸發，檢查進度
如果還沒完成，繼續等待
如果完成了，下載投影片，繼續後續工作
這樣小金就學會了等待。
李宏毅老師說：Cron Job 系統允許 AI Agent 設定定時任務。這些機制使 AI Agent 能夠在無人監控下持續運作，並‘學會等待’，從而實現更復雜的自動化流程。
真正的自主：向目標前進
有了這些機制，AI Agent 就可以實現真正的自主運行。
李宏毅老師說，小金的 Soul.md 裏寫着：
每次心跳觸發時，語言模型都會看到這個目標。它會思考：
我現在在做什麼？
這些事情有助於我成為世界一流的學者嗎？
我接下來應該做什麼？
然後它可能會：搜索最新的學術論文、學習新的知識、撰寫研究筆記、製作教學視頻、參加學術比賽（比如 教學怪物）。
這一切都是它自己決定的，不需要人類指揮。
這個自主性還是有限的：它的目標是人類設定的、它的能力受限於工具和模型、它的推理基於文字接龍，不是真正的 思考 。
但至少在表現上，它看起來像是一個有目標、會規劃、能執行的助理。
下一篇預告
現在你已經理解了 AI Agent 的完整運作機制：
記憶如何壓縮和檢索
如何通過子代理管理複雜任務
如何通過心跳機制實現自主運行
如何通過 Cron Job 學會等待
但還有最後一個重要話題：安全風險。
我們在第三篇簡單提到了 Prompt Injection 攻擊，但實際的風險遠不止這些：
AI Agent 之間會互相攻擊嗎？
如何防止 AI Agent 失控？
未來的 AI Agent 會是什麼樣子？
下一篇文章，我們將探討這些問題，並展望 AI Agent 的未來。
系列文章目錄：
當 AI 真的會「做事」— OpenClaw 初體驗
語言模型的本質與 System Prompt 的魔法
工具調用 — AI Agent 如何操控你的電腦
記憶管理與自主運行 — AI Agent 的進化之路（本篇）
安全風險與未來展望 — 當龍蝦統治世界
本系列基於李宏毅老師「解剖小龍蝦 — 以 OpenClaw 為例介紹 AI Agent 的運作原理」課程整理。