日韩欧美乱色视频,污污污在线免费观看网址,小明中文字幕在线视频

AI記憶革命爆發(fā)！Clawdbot如何像大腦般記住一切

發(fā)布日期： 2026-01-29 12:02:45 來源：新智元

新智元報(bào)道

(資料圖)

編輯：好困元宇

【新智元導(dǎo)讀】一個開源AI，能記住你幾個月前的決定、在本地替你跑活、還不受大廠控制：Clawdbot到底是個人助理，還是下一代「賽博打工人」？

Clawdbot太瘋狂了！

你的7×24小時AI員工；

不是智能體，是賺錢機(jī)器 ……

2026年初，一個名為Clawdbot的開源個人AI助手，迅速引爆了開源社區(qū)和硅谷極客圈。

從技術(shù)愛好者到普通用戶，許多人玩Clawdbot都玩瘋了，一開發(fā)起來，根本都停不下來。

甚至，還有人把Clawdbot當(dāng)成了賺錢工具，開始兜售Clawdbot賺錢指南，還不忘販賣一波焦慮：

錯過了Clawdbot浪潮，你將永遠(yuǎn)淪為「數(shù)字底層」！

Clawdbot被網(wǎng)友稱為「長了手的Claude」或者「7×24在線的賈維斯」，它最大的亮點(diǎn)之一，便是長時記憶和長時任務(wù)執(zhí)行能力。

回想一下你目前是如何使用AI助手的。

你在瀏覽器中打開AI助手，輸入問題，得到回復(fù)，然后關(guān)閉標(biāo)簽頁；但當(dāng)你明天再回來時，又得從頭開始。

它不會記住你昨天討論過的內(nèi)容，不了解你的偏好、你的項(xiàng)目，也不了解你的工作流程。

你可能會好奇Clawdbot是如何記住那么多東西的，最近AI研究工程師Manthan Gupta就寫了一篇文章來回答這個問題。

他在「Clawdbot如何記住一切」一文中詳細(xì)復(fù)盤了Clawdbot獨(dú)特的記憶機(jī)制原理。

與那些跑在云端的ChatGPT或者Claude不一樣，Clawdbot是直接在你本地機(jī)器上跑的，而且能直接集成到你已經(jīng)在用的聊天平臺里，比如Discord、WhatsApp、Telegram等。

最絕的是，Clawdbot能自主處理現(xiàn)實(shí)世界的任務(wù)：管理郵件、安排日歷、處理航班值機(jī)，還能按計(jì)劃跑后臺任務(wù)。

但真正吸引Manthan Gupta眼球的，是它的持久記憶系統(tǒng)：它能保持全天候的上下文記憶，記住之前的對話，并且能基于過往的互動無限疊加。

相比于ChatGPT和Claude，Clawdbot走了一條完全不同的路子：

它不搞那種基于云端、由大公司控制的記憶，而是把所有東西都留在本地，讓用戶完全掌控自己的上下文和技能。

下面，我們就來跟隨Manthan這篇文章，來深挖一下Clawdbot是怎么運(yùn)作的。

上下文與記憶

Clawdbot的基本問題定義

如何構(gòu)建上下文

在聊記憶之前，咱們先得搞清楚模型在處理每個請求時到底看到了什么：

[ 0] 系統(tǒng)提示詞 (System Prompt) (靜態(tài)+條件指令) [ 1] 項(xiàng)目上下文 (引導(dǎo)文件: AGENTS.md, SOUL.md 等) [ 2] 對話歷史 (消息, 工具調(diào)用, 壓縮摘要) [ 3] 當(dāng)前消息

系統(tǒng)提示詞定義了AI智能體有多大能耐以及有什么工具可用。

跟記憶有關(guān)的是項(xiàng)目上下文，這包括了注入到每個請求中的、用戶可編輯的Markdown文件：

這些文件跟記憶文件一塊待在AI智能體的工作區(qū)里，這就讓整個AI智能體的配置變得完全透明，而且你想改就改。

上下文與記憶的區(qū)別

搞清楚上下文和記憶的區(qū)別，是理解Clawdbot的基石。

上下文是模型在單次請求里看到的所有東西：

上下文 = 系統(tǒng)提示詞 + 對話歷史 + 工具結(jié)果 + 附件

上下文是：

轉(zhuǎn)瞬即逝的：只在這個請求里存在，用完即棄
有邊界的：受限于模型的上下文窗口 (比如200 Token)
昂貴的：每個Token都要算API的錢，還影響速度

記憶是存在硬盤里的東西：

記憶= MEMORY.md + memory/*.md + 會話實(shí)錄

記憶是：

持久的：重啟、過幾天、過幾個月都在
無邊界的：可以無限增長
便宜的：存著不花 API 的錢
可搜索的：建了索引，支持語義檢索

記憶工具

AI智能體通過兩個專門的工具來查閱記憶：

1. memory_search

目的：在所有文件里把相關(guān)的記憶找出來：

{"name": "memory_search", "deion": "強(qiáng)制回憶步驟：在回答關(guān)于以前的工作、決定、日期、人員、偏好或待辦事項(xiàng)的問題之前，先對MEMORY.md + memory/*.md進(jìn)行語義搜索", "parameters": { "query": "關(guān)于API咱們定的什么？", "maxResults": 6, "minScore": 0.35}}返回：{"results": [{" path": "memory/2026-01-20.md", "startLine": 45, "endLine": 52, "score": 0.87, "snippet": "## API討論\n為了簡單起見，決定用REST而不是GraphQL...", "source": "memory"}],"provider": "openai", "model": "text-embedding-3-small"}

2. memory_get

目的：找到內(nèi)容后，把具體內(nèi)容讀出來

{"name": "memory_get", "deion": "在 memory_search 之后，讀取記憶文件里的特定行", "parameters": { " path": "memory/2026-01-20.md", "from": 45, "lines": 15}}

{"path": "memory/2026-01-20.md", "text": "## API討論\n\n跟團(tuán)隊(duì)開了個會討論API架構(gòu)。\n\n### 決定\n我們選了REST沒選GraphQL，理由是：\n1. 實(shí)現(xiàn)起來簡單\n2. 緩存更好做\n3. 團(tuán)隊(duì)更熟這個\n\n### 端點(diǎn)\n- GET /users\n- POST /auth/login\n- GET /projects/:id"}

寫入記憶

這里沒有專門的memory_write工具。AI智能體想寫記憶，就用它平時寫文件、改文件的那些標(biāo)準(zhǔn)工具。

既然記憶就是純Markdown，你也可以手動去改這些文件（它們會被自動重新索引，很智能）。

具體寫到哪，是由AGENTS.md里的提示詞來控制的：

自動寫入也會在「預(yù)壓縮刷新」和會話結(jié)束時發(fā)生。

記憶存儲

Clawdbot記憶系統(tǒng)的核心原則就是：「記憶就是AI智能體工作區(qū)里的純Markdown文件?！?/p>

Clawdbot記憶系統(tǒng)如何運(yùn)作的？

雙層記憶系統(tǒng)

記憶就住在AI智能體的工作區(qū)里（默認(rèn)是~/clawd/）：

~ /clawd/├── MEMORY. md- 第 2層: 長期精選知識 └── memory/├── 2026- 01- 26.md - 第 1層: 今天的筆記 ├── 2026- 01- 25.md - 昨天的筆記 ├── 2026- 01- 24.md - ...以此類推 └── ...

第1層：每日日志（memory/YYYY-MM-DD.md）

這些是「只增不減」的每日筆記，AI智能體一整天都會往這里寫東西。

當(dāng)它想記住點(diǎn)什么，或者你明確告訴它「把這個記下來」的時候，它就寫這。

# 2026-01-26## 10:30 AM - API討論跟用戶討論了REST vs GraphQL。決定：為了簡單用REST。關(guān)鍵端點(diǎn)：/users, /auth, /projects。## 2:15 PM - 部署把v2.3.0發(fā)到生產(chǎn)環(huán)境了。沒毛病。## 4:00 PM - 用戶偏好用戶提了一嘴，他們更喜歡Type而不是Java。

第2層：長期記憶（MEMORY.md）

這是精選過的、持久的知識庫。

當(dāng)有大事發(fā)生、或者有了重要的想法、決定、觀點(diǎn)和經(jīng)驗(yàn)教訓(xùn)時，AI智能體會寫到這里。

# 長期記憶## 用戶偏好- 相比Java更喜歡Type-喜歡簡潔的解釋 -正在搞 "Acme Dashboard" 項(xiàng)目 ## 重要決定- 2026-01-15: 數(shù)據(jù)庫選了PostgreSQL-2026-01-20: 采用了REST而不是GraphQL -2026-01-26: 用Tailwind CSS寫樣式 ## 關(guān)鍵聯(lián)系人- Alice (alice@acme.com) - 設(shè)計(jì)主管-Bob (bob@acme.com) - 后端工程師

AI智能體如何知道要讀記憶

AGENTS.md文件（會自動加載）里寫著指令：

## 每次會話在干別的事之前：1.讀SOUL.md - 這是「你是誰」 2.讀USER.md - 這是「你在幫誰」 3.讀memory/YYYY-MM-DD.md（今天和昨天的）以此獲取最近的上下文 4.如果是在主會話（MAIN SESSION）（直接跟人類聊天），還要讀MEMORY.md 別問許可，直接干就完了。

記憶如何被索引

當(dāng)你保存一個記憶文件時，后臺是這么運(yùn)作的：

┌─────────────────────────────────────────────────────────────┐│ 1. 文件保存 ││ ~/clawd/memory/2026-01-26.md │└─────────────────────────────────────────────────────────────┘│▼┌─────────────────────────────────────────────────────────────┐│ 2. 文件監(jiān)聽器檢測到更改 ││ Chokidar監(jiān)控MEMORY.md + memory/**/*.md ││ 防抖1.5秒以批處理快速寫入 │└─────────────────────────────────────────────────────────────┘│▼┌─────────────────────────────────────────────────────────────┐│ 3. 分塊（Chunking） ││ 分割成約400 Token的塊，重疊80 Token ││ ││ ┌────────────────┐ ││ │ 塊1 │ ││ │ 行1-15 │──────┐ ││ └────────────────┘ │ ││ ┌────────────────┐ │（80 Token重疊） ││ │ 塊2 │?─────┘ ││ │ 行12-28 │──────┐ ││ └────────────────┘ │ ││ ┌────────────────┐ │ ││ │ 塊3 │?─────┘ ││ │ 行25-40 │ ││ └────────────────┘ ││ ││ 為什么是400/80? 平衡語義連貫性與粒度。 ││ 重疊確?？缭綁K邊界的事實(shí)能在兩個塊中都被捕獲。 ││ 兩個值都是可配置的。 │└─────────────────────────────────────────────────────────────┘│▼┌─────────────────────────────────────────────────────────────┐│ 4. 嵌入（Embedding） ││ 每個塊 -> 嵌入提供商 -> 向量 ││ ││ "討論了REST vs GraphQL"-> │ │ OpenAI/Gemini/Local -> ││ [0.12, -0.34, 0.56, ...] (1536維) │└─────────────────────────────────────────────────────────────┘│▼┌─────────────────────────────────────────────────────────────┐│ 5. 存儲 ││ ~/.clawdbot/memory/ .sqlite │ │ ││ 表: ││ - chunks ( id, path, start_line, end_line, text, hash) │ │ - chunks_vec ( id, embedding) -> sqlite-vec │ │ - chunks_fts (text) -> FTS5全文搜索 ││ - embedding_cache ( hash, vector) -> 避免重復(fù)嵌入 │ └─────────────────────────────────────────────────────────────┘

sqlite-vec是個SQLite擴(kuò)展，能直接在SQLite里搞向量相似度搜索，不需要外掛一個向量數(shù)據(jù)庫。
FTS5是SQLite自帶的全文搜索引擎，負(fù)責(zé)BM25關(guān)鍵字匹配。

這兩者配合起來，Clawdbot就能靠一個輕量級的數(shù)據(jù)庫文件同時搞定「語義+關(guān)鍵字」的混合搜索。

記憶如何被搜索

當(dāng)你搜記憶的時候，Clawdbot會并行跑兩種搜索策略。

向量搜索（語義）找的是意思相近的內(nèi)容，而BM25搜索（關(guān)鍵字）找的是有精確Token匹配的內(nèi)容。

結(jié)果會按權(quán)重打分合并：

finalScore= ( 0. 7* vectorScore) + ( 0. 3* textScore)

為何是70/30？

語義相似度是記憶召回的主力，但BM25關(guān)鍵字匹配能抓住向量可能會漏掉的精確術(shù)語（比如名字、ID、日期）。

分?jǐn)?shù)低于minScore閾值（默認(rèn)0.35）的結(jié)果會被過濾掉。這些值都可以自己配，它可以保證你無論是搜概念（比如「那個數(shù)據(jù)庫的東西」）還是搜具體細(xì)節(jié)（比如「POSTGRES_URL」），都能夠搜得準(zhǔn)。

多智能體記憶

Clawdbot支持多個AI智能體，而且每個智能體的記憶是完全隔離的：

~/.clawdbot/memory/ # 狀態(tài)目錄 (索引)├── main.sqlite # "main"智能體的向量索引└── work.sqlite # "work"智能體的向量索引~/clawd/ # "main"智能體工作區(qū) (源文件)├── MEMORY.md└── memory/└── 2026-01-26.md~/clawd-work/ # "work"智能體工作區(qū) (源文件)├── MEMORY.md└── memory/└── 2026-01-26.md

Markdown文件（真相的源頭）在每個工作區(qū)里，而SQLite索引（衍生數(shù)據(jù)）在狀態(tài)目錄里。

每個AI智能體都有自己的地盤和索引。

內(nèi)存管理器是靠agentId + workspaceDir來區(qū)分的，所以自動跨智能體搜記憶這事是不會發(fā)生的。

那AI智能體能讀對方的記憶嗎？

默認(rèn)不行。

每個AI智能體只能盯著自己的工作區(qū)。

不過，工作區(qū)只是個軟沙箱（默認(rèn)工作目錄），不是那種不可逾越的硬邊界。

理論上，除非你開了嚴(yán)格的沙箱模式，否則AI智能體是可以用絕對路徑去訪問另一個工作區(qū)的。

這種隔離對于區(qū)分上下文特別好用。

比如搞個用于WhatsApp的「私人」 AI智能體，再搞個用于Slack的「工作」AI智能體，它倆就能有完全不同的記憶和性格。

Clawdbot如何管住上下文

壓縮

每個AI模型都有上下文窗口的上限。

Claude是200K Token，GPT-5.1是1M。

聊得久了，總會撞上這堵墻。

一旦撞墻，Clawdbot就會使出「壓縮」大法：把舊的對話總結(jié)成一個精簡的條目，同時保留最近的消息原封不動。

┌─────────────────────────────────────────────────────────────┐│ 壓縮前 ││ 上下文: 180,000 / 200,000 Tokens ││ ││ [第1輪] 用戶: "咱們搞個API吧"│ │ [第2輪] 智能體: "好嘞! 你需要什么端點(diǎn)?"│ │ [第3輪] 用戶: "用戶和認(rèn)證"│ │ [第4輪] 智能體: *寫了500行Schema* ││ [第5輪] 用戶: "加上速率限制"│ │ [第6輪] 智能體: *改代碼* ││ ... (還有100輪) ... ││ [第150輪] 用戶: "現(xiàn)在什么狀態(tài)了?"│ │ ││ ?? 接近上限 │└─────────────────────────────────────────────────────────────┘│▼┌─────────────────────────────────────────────────────────────┐│ 觸發(fā)壓縮 ││ ││ 1. 把第1-140輪總結(jié)成一個精簡摘要 ││ 2. 第141-150輪保持原樣 (最近的上下文) ││ 3. 把摘要持久化保存到JSONL實(shí)錄里 │└─────────────────────────────────────────────────────────────┘│▼┌─────────────────────────────────────────────────────────────┐│ 壓縮后 ││ 上下文: 45,000 / 200,000 Tokens ││ ││ [摘要] "構(gòu)建了帶/users, /auth端點(diǎn)的REST API。 ││ 實(shí)現(xiàn)了JWT認(rèn)證, 速率限制（100請求/分）, ││ PostgreSQL數(shù)據(jù)庫。已部署到預(yù)發(fā)布環(huán)境v2.4.0。 ││ 當(dāng)前重點(diǎn): 準(zhǔn)備生產(chǎn)環(huán)境部署。" ││ ││ [第141-150輪保持原樣] ││ │└─────────────────────────────────────────────────────────────┘

自動vs手動壓縮

自動：快到上下文長度限制時觸發(fā)

你會看到詳細(xì)模式下自動壓縮已完成
原始請求將使用壓縮后的上下文重試

手動：使用/compact命令

`/compact`專注于決策和待解決的問題

跟某些優(yōu)化不一樣，壓縮后的東西是會存到硬盤里的。摘要會被寫進(jìn)會話的JSONL轉(zhuǎn)錄文件，所以以后的會話開始時，都能帶著這段被壓縮的歷史。

記憶刷新

基于LLM的壓縮是有損的。重要信息可能會被「總結(jié)沒了」。

為了防止這個，Clawdbot用了一招「壓縮前記憶刷新」。

┌─────────────────────────────────────────────────────────────┐│ 上下文接近上限 ││ ││ ████████████████████████████???????? 75%的上下文 ││ ↑ ││ 越過軟閾值 ││ (contextWindow - reserve - softThreshold)│└─────────────────────────────────────────────────────────────┘│▼┌─────────────────────────────────────────────────────────────┐│ 靜默記憶刷新輪次 ││ ││ 系統(tǒng): "壓縮前記憶刷新?，F(xiàn)在存儲持久記憶 ││ (使用memory/YYYY-MM-DD.md)。 ││ 如果沒什么可存的，回復(fù)NO_REPLY。" ││ ││ 智能體: 審查對話里的重要信息 ││ 把關(guān)鍵決定/事實(shí)寫進(jìn)記憶文件 ││ -> NO_REPLY（用戶什么也看不見） │└─────────────────────────────────────────────────────────────┘│▼┌─────────────────────────────────────────────────────────────┐│ 壓縮安全進(jìn)行 ││ ││ 重要信息現(xiàn)在已經(jīng)在硬盤上了 ││ 壓縮可以繼續(xù)，知識不會丟 │└─────────────────────────────────────────────────────────────┘

這個記憶刷新可以在clawdbot.yaml或clawdbot.json文件里配置。

{"agents":{"defaults":{"compaction":{"reserveTokensFloor":20000,"memoryFlush":{"enabled":true,"softThresholdTokens":4000,"systemPrompt":"Session nearing compaction. Store durable memories now.","prompt":"Write lasting notes to memory/YYYY-MM-DD.md; reply NO_REPLY if nothing to store."}}}}}

剪枝

工具返回的結(jié)果有時候巨大無比。一個exec命令可能吐出50,000個字符的日志。

剪枝就是把這些舊的輸出給修剪掉，但不重寫歷史。這是個有損過程，剪掉的舊輸出就找不回來了。

┌─────────────────────────────────────────────────────────────┐│ 剪枝前 (內(nèi)存中) ││ ││ 工具結(jié)果 ( exec): [50,000字符的npm install輸出] │ │ 工具結(jié)果 ( read): [巨型配置文件, 10,000字符] │ │ 工具結(jié)果 ( exec): [構(gòu)建日志, 30,000字符] │ │ 用戶: "構(gòu)建成功了嗎?"│ └─────────────────────────────────────────────────────────────┘│▼ (軟修剪 + 硬清除)┌─────────────────────────────────────────────────────────────┐│ 剪枝后 (發(fā)送給模型) ││ ││ 工具結(jié)果 ( exec): "npm WARN deprecated...[截?cái)郵 ││ ...Successfully installed." ││ 工具結(jié)果 ( read): "[Old tool result content cleared]"│ │ 工具結(jié)果 ( exec): [保留 - 太近了沒剪] │ │ 用戶: "構(gòu)建成功了嗎?"│ └─────────────────────────────────────────────────────────────┘

硬盤上的JSONL文件：沒變（完整的輸出還在那）。

Cache-TTL剪枝

Anthropic會把提示詞前綴緩存最多5分鐘，以此來降低重復(fù)調(diào)用的延遲和成本。

如果你在TTL（生存時間）窗口內(nèi)發(fā)送相同的提示詞前綴，緩存的Token費(fèi)用能省大概90%。

要是TTL過期了，下個請求就得重新緩存整個提示詞。

問題來了：如果會話閑置時間超過了TTL，下個請求就沒緩存了，必須按全價「緩存寫入」費(fèi)率重新緩存整個對話歷史。

Cache-TTL剪枝就是為了解決這個問題，它會檢測緩存什么時候過期，并在下個請求之前把舊的工具結(jié)果剪掉。

重新緩存的提示詞變小了，成本自然就低了：

{"agent":{"contextPruning":{"mode":"cache-ttl","http://":"只在緩存過期后才剪","ttl":"600","http://":"配合你的 cacheControlTtl","keepLastAssistants":3,"http://":"保護(hù)最近的工具結(jié)果","softTrim":{"maxChars":4000,"headChars":1500,"tailChars":1500},"hardClear":{"enabled":true,"placeholder":"[Old tool result content cleared]"}}}}

會話生命周期

會話不會永遠(yuǎn)持續(xù)。它們會根據(jù)可配置的規(guī)則進(jìn)行重置，給記憶創(chuàng)造了天然的邊界。

默認(rèn)行為是每天重置。不過也有其他模式可選。

會話記憶鉤子

當(dāng)你運(yùn)行/new開一個新會話時，會話記憶鉤子能自動保存上下文。

/ new│▼┌─────────────────────────────────────────────────────────────┐│ 觸發(fā)會話記憶鉤子 ││ ││ 1.提取剛結(jié)束會話的最后 15條消息 │ │ 2.用 LLM生成個描述性的 Slug（標(biāo)識符） │ │ 3.保存到~ /clawd/memory/ 2026- 01- 26-api-design. md│ └─────────────────────────────────────────────────────────────┘│▼┌─────────────────────────────────────────────────────────────┐│ 新會話開始 ││ ││ 以前的上下文現(xiàn)在可以通過memory_search搜到了 │└─────────────────────────────────────────────────────────────┘

總結(jié)

Clawdbot的記憶系統(tǒng)之所以能成，是因?yàn)樗鼒?jiān)持了這么幾個關(guān)鍵原則：