【OpenClaw具身硬件】MiniClaw 閱讀筆記—(4) 文件讀寫(xiě)文章目錄【OpenClaw具身硬件】MiniClaw 閱讀筆記---(4) 文件讀寫(xiě)0x00 概要0x01 Read file RAG1.1 經(jīng)典RAG的工作方式1.2 MimiClaw反過(guò)來(lái)LLM是檢索的發(fā)起者1.3 為什么這么做動(dòng)機(jī)1MCU跑不動(dòng)經(jīng)典RAG的基礎(chǔ)設(shè)施動(dòng)機(jī)2可解釋性可調(diào)試性動(dòng)機(jī)3LLM已經(jīng)具備“讀懂目錄頁(yè)自主路由“的能力判斷1在LLM足夠強(qiáng)的時(shí)代“檢索“和“思考“的邊界正在消融判斷2:“讓LLM自己讀“會(huì)帶來(lái)質(zhì)的不同1.4 為什么能“工作“機(jī)制1上下文里始終有“地圖“機(jī)制2紀(jì)律性的prompt協(xié)議機(jī)制3文件系統(tǒng)作為“扁平知識(shí)庫(kù)”和 Agentic-RAG/ Function-calling RAG 的關(guān)系1.5 代價(jià)隱含假設(shè)崩塌場(chǎng)景1知識(shí)庫(kù)規(guī)模超過(guò)“目錄頁(yè)極限“ 現(xiàn)象崩塌場(chǎng)景2文件名標(biāo)題不再具備“語(yǔ)義自描述性“ 現(xiàn)象崩塌場(chǎng)景3換了一個(gè)不夠強(qiáng)的模型崩塌場(chǎng)景4延遲敏感場(chǎng)景實(shí)時(shí)控制、對(duì)話感現(xiàn)象崩塌場(chǎng)景5多用戶(hù)共享/高并發(fā)知識(shí)更新崩塌場(chǎng)景6知識(shí)是連續(xù)大段落不是離散文檔現(xiàn)象綜合判斷什么時(shí)候該考慮 補(bǔ)變?cè)獙用娴谋浪軐W(xué)本身的“成立條件“在變0xFF 參考0x00 概要MimiClaw 是**$5 芯片上的 AI 助理OpenClaw。沒(méi)有 Linux沒(méi)有 Node.js純 C。**用戶(hù)在 Telegram 發(fā)一條消息ESP32-S3 通過(guò) WiFi 收到后送進(jìn) Agent 循環(huán) — LLM 思考、調(diào)用工具、讀取記憶 — 再把回復(fù)發(fā)回來(lái)。同時(shí)支持Anthropic (Claude)和OpenAI (GPT)兩種提供商運(yùn)行時(shí)可切換。一切都跑在一顆 $5 的芯片上所有數(shù)據(jù)存在本地 Flash。本篇會(huì)對(duì)MiniClaw 的思路和實(shí)現(xiàn)細(xì)節(jié)做進(jìn)一步討論。LLM自主read_file替代RAG檢索”把檢索的決策權(quán)從外部基礎(chǔ)設(shè)施交還給 LLM把檢索基礎(chǔ)設(shè)施從向量數(shù)據(jù)庫(kù)簡(jiǎn)化為文件系統(tǒng)把“準(zhǔn)備上下文這個(gè)動(dòng)作從prompt階段后移到推理階段一用 frontier model 的語(yǔ)義理解力換掉了所有embedding/index/rerank組件。這是一個(gè)只有在大模型時(shí)代才成立的設(shè)計(jì)選擇也是MimiClaw能夠把“完整Agent塞進(jìn)5美元芯片的關(guān)鍵技術(shù)杠桿之一。如果不是這個(gè)判斷MimiClaw就得在云端跑一套檢索服務(wù)整個(gè)“純C/純本地/ 0.5W的產(chǎn)品故事會(huì)塌掉。0x01 Read file RAGMiniClaw 用 LLM自主read_file 替代RAG檢索。它包含一個(gè)隱含的對(duì)照一經(jīng)典 RAG是“系統(tǒng)替 LLM決定要看什么而MimiClaw反過(guò)來(lái)一LLM自己決定要看什么。/*Register read_file*/mimi_tool_t rf{.nameread_file,.descriptionRead a file from SPIFFS storage. Path must start with MIMI_SPIFFS_BASE/.,.input_schema_json{\type\:\object\,\properties\:{\path\:{\type\:\string\,\description\:\Absolute path starting with MIMI_SPIFFS_BASE/\}},\required\:[\path\]},.executetool_read_file_execute,};register_tool(rf);我們就來(lái)看看其思路和優(yōu)劣。1.1 經(jīng)典RAG的工作方式經(jīng)典RAG云端常見(jiàn)由外部管線主導(dǎo)用戶(hù)提問(wèn) ↓[Embedding模型】把問(wèn)題編碼成向量[向量數(shù)據(jù)庫(kù)]↓ 檢索top-K最相似段落 ↓[Reranker/過(guò)濾]可選 ↓ 把段落塞進(jìn) system prompt 或 user message ↓ LLM接收已經(jīng)準(zhǔn)備好的上下文→生成回答關(guān)鍵特征LLM只是消費(fèi)者。它在收到prompt之前就已經(jīng)被“喂飽“了一檢索過(guò)程對(duì)模型完全不可見(jiàn)模型也無(wú)法對(duì)檢索結(jié)果做主動(dòng)反饋除非套一層 agentic-RAG但那已經(jīng)是MimiClaw的方向了1.2 MimiClaw反過(guò)來(lái)LLM是檢索的發(fā)起者M(jìn)imiClaw沒(méi)有上述任何一步外部檢索。代替它的是這樣一個(gè)流程用戶(hù)提問(wèn) ↓ LLM看到的system prompt只包含-靜態(tài)指令工具列表-幾份“目錄頁(yè)”MEMORY摘要、Skills標(biāo)題、文件路徑約定 LLM判斷“要回答這個(gè)問(wèn)題我需要看x文件“ ↓ LLM主動(dòng)發(fā)起tool_use:read_filepath/spiffs/skills/weather.md)↓ agent_loop 執(zhí)行 tool把文件內(nèi)容作為 tool_result 塞回 messages ↓ LLM拿到內(nèi)容再?zèng)Q定下一步繼續(xù)檢索/回答/調(diào)其他工具關(guān)鍵反轉(zhuǎn)LLM不再是“被喂飽的消費(fèi)者”而是**主動(dòng)伸手取閱的讀者“**。檢索從“發(fā)生在LLM之前的預(yù)處理“變成了“發(fā)生在 LLM思考過(guò)程中的工具調(diào)用“。1.3 為什么這么做三個(gè)層面的動(dòng)機(jī)如下。動(dòng)機(jī)1MCU跑不動(dòng)經(jīng)典RAG的基礎(chǔ)設(shè)施回顧經(jīng)典RAG的依賴(lài)項(xiàng)組件MCU上的代價(jià)Embedding模型哪怕MiniLM量化幾MB模型權(quán)重 數(shù)百ms CPU推理不可接受向量數(shù)據(jù)庫(kù)FAISS/Annoy/hnsw索引文件幾十MBPSRAM裝不下文檔分塊索引構(gòu)建管線需要離線預(yù)處理服務(wù)器Reranker又一個(gè)模型任意一項(xiàng)都超出ESP32-S3的資源預(yù)算。要么把這些放云端增加網(wǎng)絡(luò)依賴(lài)、隱私問(wèn)題、服務(wù)器成本要么放棄經(jīng)典 RAG。MimiClaw選擇了后者。動(dòng)機(jī)2可解釋性可調(diào)試性經(jīng)典RAG的一個(gè)老大難是“為什么這次檢索結(jié)果不好“—是chunk太大embedding模型不匹配top-K截?cái)嗔藃e-ranker 出錯(cuò)調(diào)試鏈路長(zhǎng)。MimiClaw這套機(jī)制下每一次“檢索“都是一個(gè)清晰可見(jiàn)的tool_use日志[agent] tool_use:read_file(path/spiffs/memory/MEMoRY.md) [agent] tool_result: 1842 bytes [agent] tool_use: read_file(path/spiffs/skills/weather.md) [agent] tool_result: 612 bytes [agent] final answer generated那個(gè)文件被讀了、讀到了什么、為什么讀都能從串口日志一行行看下來(lái)。調(diào)試RAG退化為調(diào)試一段對(duì)話。動(dòng)機(jī)3LLM已經(jīng)具備“讀懂目錄頁(yè)自主路由“的能力LLM的指令遵循能力強(qiáng)到可以替代很多原本需要專(zhuān)門(mén)管線的工作給它一個(gè)目錄“這里有5個(gè)skill分別是X/Y/Z…它能根據(jù)用戶(hù)問(wèn)題自動(dòng)判斷“用戶(hù)問(wèn)天氣我應(yīng)該讀weather.md然后發(fā)起對(duì)應(yīng)的read_file調(diào)用這本質(zhì)上是把“檢索路由“這層職責(zé)從embedding相似度轉(zhuǎn)交給了LLM 的語(yǔ)義理解。在大模型時(shí)代之前這是天方夜譚一以前的小模型理解不了“目錄“的隱喻但今天的frontier model目錄頁(yè)就是它的索引。MimiClaw做的不過(guò)是信任這種能力并把它寫(xiě)進(jìn)prompt協(xié)議里。當(dāng)然這種做法是基于以下兩個(gè)判斷。判斷1在LLM足夠強(qiáng)的時(shí)代“檢索“和“思考“的邊界正在消融經(jīng)典RAG的預(yù)設(shè)是檢索是廉價(jià)的預(yù)處理推理是昂貴的核心計(jì)算所以要把檢索做厚、做精、把“對(duì)的內(nèi)容“喂進(jìn)去。MimiClaw反過(guò)來(lái)預(yù)設(shè)LLM 的推理已經(jīng)強(qiáng)大到可以把“決定看什么“也包含進(jìn)去。因此把檢索作為推理的一部分tool_use而不是推理之前的獨(dú)立階段。這種范式在云端也有同樣的趨勢(shì)Claude 的 agentic browsing、GPT 的 file_search toolMimiclaw 只是因?yàn)橘Y源約束被迫走得更徹底。判斷2:“讓LLM自己讀“會(huì)帶來(lái)質(zhì)的不同經(jīng)典RAG模型被動(dòng)接受N段文本無(wú)法判斷“還需要再多一段”。MimiClaw模式模型可以讀完一份文件后覺(jué)得不夠繼續(xù)read_file第二份一這是一個(gè)真正的迭代過(guò)程ReAct循環(huán)最多10次工具調(diào)用讓LLM可以深度探索Q我上周三跟你說(shuō)了什么 LLM: list_dir(/spiffs/sessions/) → 看到tg_12345.jsonl LLM:read_file(/spiffs/sessions/tg_12345.jsonl) → 看到20條最近消息沒(méi)有上周三 LLM:read_file(/spiffs/memory/2026-04-22.md) → 找到當(dāng)天日記 LLM最終回答這種“翻找 → 看一眼 → 決定再翻 → 給答案“的過(guò)程更接近人類(lèi)查資料而不是“系統(tǒng)給我5個(gè)段落我從中挑”。信息密度低、覆蓋面廣的場(chǎng)景下主動(dòng)檢索往往優(yōu)于被動(dòng)top-K一尤其是MimiClaw這種文件數(shù)量本來(lái)就少幾十到幾百的場(chǎng)景。1.4 為什么能“工作“光說(shuō)讓LLM自己讀“是不夠的MimiClaw至少有三件事在協(xié)同支撐這個(gè)范式機(jī)制1上下文里始終有“地圖“context_builder.c把這些總是出現(xiàn)在system prompt里工具列表包含read_file、list_dir等“探索性“工具M(jìn)EMORY.md內(nèi)容讓LLM知道“我已經(jīng)記得什么Skills目錄頁(yè)讓LLM知道“還有哪些文件值得看路徑約定/spiffs/memory//spiffs/skills//spiffs/sessions/)這構(gòu)成了一份“知識(shí)地圖“。LLM不需要embedding也能知道該去哪里找東西一一一因?yàn)榈貓D本身就告訴了它。機(jī)制2紀(jì)律性的prompt協(xié)議回看system prompt里這些守則- Always read_file MEMORY.md before writing - Use get_current_time before writing daily notes - When a task matches a skill,read the full skill file for detailed instructions - Read MEMoRY.md before answering questions about the users preferences這些是用自然語(yǔ)言寫(xiě)出的檢索時(shí)機(jī)規(guī)則一什么時(shí)候應(yīng)該主動(dòng)read。它們替代了經(jīng)典RAG里的“檢索觸發(fā)器邏輯但實(shí)現(xiàn)成本只是幾行markdown。機(jī)制3文件系統(tǒng)作為“扁平知識(shí)庫(kù)”SPIFFS上的所有文件都是markdown/JSONL人類(lèi)可讀、模型可讀、可枚舉。LLM可以用list_dir(“/spiffs/skills/”)發(fā)現(xiàn)資源用read_file加載特定資源用write_file/edit_file修改資源整個(gè)文件系統(tǒng)就是一個(gè)“模型可尋址的知識(shí)庫(kù)”。它不用建索引因?yàn)長(zhǎng)LM自己能讀懂weather.md 里大概是天氣相關(guān)內(nèi)容“一一一文件名 標(biāo)題 第一段就是天然的語(yǔ)義索引。和 Agentic-RAG/ Function-calling RAG 的關(guān)系熟悉Agent架構(gòu)的人會(huì)問(wèn)這不就是Agentic RAG/ReActretrieval tools嗎是的這正是Agentic RAG的一種極簡(jiǎn)形態(tài)。但MimiClaw把它推到一個(gè)更極端的位置維度典型 Agentic RAGMimiClaw檢索后端仍然是向量庫(kù) / 關(guān)鍵詞索引就是文件系統(tǒng) 路徑工具復(fù)雜度多個(gè)檢索工具 重排三五個(gè)文件操作工具索引維護(hù)需要離線管線更新 embedding零索引—LLM 寫(xiě)文件即 “更新索引”知識(shí)演化重新跑 ingest pipelineLLM 自己 write_file 立即生效可觀測(cè)性檢索日志 LLM 日志只有 tool_use 日志統(tǒng)一視圖所以更準(zhǔn)確的描述是MimiClaw是“把Agentic RAG簡(jiǎn)化到只剩文件系統(tǒng)“的極致版本。1.5 代價(jià)為了平衡必須承認(rèn)這套哲學(xué)的代價(jià)代價(jià)說(shuō)明延遲更高每次 read_file 都是一輪 LLM 調(diào)用10 KB 文件 ReAct 多輪 數(shù)秒到十幾秒token 成本可能更高主動(dòng)探索會(huì)重復(fù)加載文件內(nèi)容到 messages依賴(lài)模型能力弱模型不會(huì)主動(dòng)檢索會(huì)瞎答只有 Claude/GPT 這種級(jí)別的模型才能穩(wěn)定執(zhí)行大規(guī)模知識(shí)庫(kù)無(wú)效文件超過(guò)幾百個(gè)時(shí)目錄頁(yè)塞不下LLM 無(wú)法發(fā)現(xiàn)所有可用資源缺少跨文檔融合沒(méi)有 reranker / fusion靠 LLM 自己把多個(gè) read_file 結(jié)果 “在腦子里” 融合所以這種哲學(xué)的適用邊界很清晰適合知識(shí)庫(kù)小1000 文件、文件本身有清晰命名、運(yùn)行 frontier-class LLM的場(chǎng)景。MimiClaw完美卡在這個(gè)區(qū)間— 一臺(tái)個(gè)人設(shè)備上的幾十份 markdownAnthropic/OpenAI 頂級(jí)模型天作之合。要是哪天有人想拿MimiClaw這套架構(gòu)去管10萬(wàn)份企業(yè)文檔那才是真正需要回歸經(jīng)典 RAG的時(shí)刻。隱含假設(shè)這套哲學(xué)依賴(lài)幾個(gè)隱含假設(shè) ----- 一旦假設(shè)失效整個(gè)范式就會(huì)出問(wèn)題。它的隱含假設(shè)大致有六條知識(shí)庫(kù)規(guī)模小到能在目錄頁(yè)里列得完文件命名標(biāo)題已經(jīng)具備語(yǔ)義可識(shí)別性LLM模型足夠強(qiáng)、能穩(wěn)定自主路由用戶(hù)對(duì)多輪tool_use的延遲與成本可接受知識(shí)更新頻率低/由LLM自己負(fù)責(zé)更新知識(shí)結(jié)構(gòu)是離散文檔不是連續(xù)大段落每條假設(shè)崩塌時(shí)觸發(fā)的失敗模式不同需要的“補(bǔ)變“也不同。崩塌場(chǎng)景1知識(shí)庫(kù)規(guī)模超過(guò)“目錄頁(yè)極限“ 現(xiàn)象當(dāng)文件數(shù)從幾十漲到幾千context_builder.c里Skills段那塊2KB緩沖再也裝不下完整目錄。要么截?cái)郘LM 看不到后半部分文件要么膨脹systemprompt突破16KB上限。更隱蔽的失敗即使prompt還能裝下LLM在100條目錄里也找不準(zhǔn)一注意力分散召回率掉到不可用。補(bǔ)變手段從“全量目錄“退化為“分層索引檢索”等級(jí)做法一級(jí)補(bǔ)變把 skills 按目錄分類(lèi)/spiffs/skills/home/, /spiffs/skills/work/目錄頁(yè)只列類(lèi)別而非文件二級(jí)補(bǔ)變引入 search_files(query) 工具做文件名 標(biāo)題的關(guān)鍵詞匹配不是 embedding是 BM25/正則。LLM 不再看完整目錄而是先 search 再 read三級(jí)補(bǔ)變上云端做向量檢索—這時(shí)候已經(jīng)回到經(jīng)典 RAG承認(rèn) MCU 不再適合作為單點(diǎn)處理器需要外掛檢索服務(wù)崩塌場(chǎng)景2文件名標(biāo)題不再具備“語(yǔ)義自描述性“ 現(xiàn)象LLM自主路由依賴(lài)文件名足以暗示內(nèi)容。但當(dāng)文件命名失去這種性質(zhì)自動(dòng)生成的文件名note_a8f3c2.md、UUID命名用代號(hào)/內(nèi)部縮寫(xiě)PROJ-X42-spec.md大量同質(zhì)化標(biāo)題每天日記都叫日記標(biāo)題沒(méi)區(qū)分度LLM看到目錄就懵了一它只能亂試或完全放棄主動(dòng)檢索。觸發(fā)條件系統(tǒng)自動(dòng)歸檔機(jī)制把“語(yǔ)義命名“剝奪了多語(yǔ)言混雜中文文件名英文LLM訓(xùn)練偏置極度專(zhuān)業(yè)領(lǐng)域醫(yī)學(xué)代碼、化學(xué)命名LLM訓(xùn)練時(shí)見(jiàn)過(guò)少補(bǔ)變手段強(qiáng)制語(yǔ)義命名在write_file工具的 prompt 里加約束“filename should describe content in 3-5words”加目錄段落描述每個(gè)目錄放一份INDEX.md由LLM維護(hù)列“這個(gè)目錄里有什么“文件首行強(qiáng)制為 #Human-readable Title—skill_loader.c已經(jīng)這么做了可推廣核心思路把“語(yǔ)義“從“文件名“擴(kuò)展到”自我描述的元數(shù)據(jù)”讓目錄頁(yè)的每一項(xiàng)都自帶摘要。崩塌場(chǎng)景3換了一個(gè)不夠強(qiáng)的模型補(bǔ)變手段縮短 ReAct鏈在弱模型上把工具調(diào)用上限從 10砍到 3避免迷路預(yù)加載策略在context_builder.c里直接inline 一份“今日相關(guān)“內(nèi)容比如總是把今天的日記完整塞進(jìn)去不依賴(lài) LLM主動(dòng)讀簡(jiǎn)化目錄頁(yè)每次只暴露3-5個(gè)最相關(guān)的 skill由路徑前綴或最近使用時(shí)間篩選回退到經(jīng)典 RAG當(dāng)模型置信度不足時(shí)外掛一個(gè) BM25/embedding 服務(wù)做硬路由本質(zhì)弱模型場(chǎng)景下要把更多決策權(quán)拿回到prompt builder手里一philosophy從“信任LLM逐步退回“系統(tǒng)輔助LLM。崩塌場(chǎng)景4延遲敏感場(chǎng)景實(shí)時(shí)控制、對(duì)話感現(xiàn)象“看目錄→讀文件→綜合→回答“是一個(gè)串行的多輪LLM調(diào)用。每一輪HTTPSTLSLLM推理都是3-10秒。如果回答需要讀3個(gè)文件總延遲可達(dá)30秒。但有些場(chǎng)景完全不能等候智能家居語(yǔ)音助手“開(kāi)燈“必須1秒內(nèi)響應(yīng)緊急通知火警、安防觸發(fā)短回合社交聊天用戶(hù)期待5秒響應(yīng)感這些場(chǎng)景下 ReActread_file的延遲模型直接出局。補(bǔ)變手段分級(jí)路由在LLM調(diào)用前用一段輕量C代碼做意圖識(shí)別關(guān)鍵詞匹配命中“控制類(lèi)“指令直接走GPIO工具不進(jìn)ReAct 循環(huán)預(yù)熱緩存把高頻文件MEMoRY.md、今日日記在 system prompt 階段就完整inlineLLM 不需要再 read 豬異步預(yù)讀心跳觸發(fā)時(shí)預(yù)讀高概率文件并緩存到PSRAMagent_loop命中時(shí)省一次 read流式響應(yīng)如果未來(lái)支持讓LLM邊讀文件邊輸出“正在查記憶…“給用戶(hù)填充感這個(gè)崩塌場(chǎng)景指向一個(gè)更大的真相Agentic RAG的“靈活性“和“延遲“是天敵。MimiClaw 的設(shè)計(jì)偏向前者所以低延遲場(chǎng)景需要繞過(guò)整個(gè)Agent循環(huán)走快速通道。崩塌場(chǎng)景5多用戶(hù)共享/高并發(fā)知識(shí)更新現(xiàn)象當(dāng)前架構(gòu)假設(shè)-個(gè)LLM主動(dòng)維護(hù)一份記憶所以用 read_fileMEMoRY.md之前必須 read再edit_file 寫(xiě)一這本質(zhì)是樂(lè)觀鎖丟失版。如果出現(xiàn)多個(gè)用戶(hù)同時(shí)和同一個(gè)MimiClaw對(duì)話Heartbeat在寫(xiě)MEMORY.md時(shí)用戶(hù)也在觸發(fā)對(duì)話Cron任務(wù)回調(diào)和 Telegram消息并發(fā)處理LLM看到的MEMORY.md可能已經(jīng)被另一條路徑改過(guò)了但LLM用的是幾秒前的快照來(lái)edit_file寫(xiě)回時(shí)靜默覆蓋了別人的修改。觸發(fā)條件多用戶(hù)家庭部署爸爸媽媽孩子各自和同一臺(tái)MimiClaw對(duì)話IoT群部署一個(gè)集群共用一份記憶高頻心跳高頻對(duì)話疊加補(bǔ)變手段加文件級(jí)鎖在memory_store.c里用 FreeRToSmutex 包 read-modify-write但這只解決并發(fā)寫(xiě)按用戶(hù)分文件MEMORY.md改為MEMORY_uSer_id.md避免共享append-only模型永遠(yuǎn)不edit只append定期由 LLM觸發(fā)“壓縮歸檔但歸檔窗口短丟失少真正的并發(fā)場(chǎng)景退到云端embedded不適合做共享狀態(tài)權(quán)威源應(yīng)該外掛一個(gè)KV服務(wù)這個(gè)崩塌場(chǎng)景揭示了一個(gè)本質(zhì)限制MCU單設(shè)備適合做單用戶(hù)的私人助理不適合做多用戶(hù)的共享大腦。崩塌場(chǎng)景6知識(shí)是連續(xù)大段落不是離散文檔現(xiàn)象MimiClaw的“文件即知識(shí)單元“假設(shè)最適合離散、可獨(dú)立解讀的小文檔一一份skill、一天日記、一段GPIO 守則。但當(dāng)知識(shí)形態(tài)是一本200頁(yè)的產(chǎn)品手冊(cè)不能整個(gè)read分塊又丟上下文一份長(zhǎng)會(huì)議錄音轉(zhuǎn)寫(xiě)線性敘述無(wú)章節(jié)法律合同/學(xué)術(shù)論文需要跨節(jié)引用大段聊天歷史信息分散在數(shù)百條對(duì)話里L(fēng)LM沒(méi)法用一次read_file“解決又沒(méi)有chunkingranking的基礎(chǔ)設(shè)施去定位段落。它只能盲讀或放棄。觸發(fā)條件用戶(hù)希望 MimiClaw 幫自己 “讀一份長(zhǎng)文檔”客服場(chǎng)景需要查詢(xún)長(zhǎng)合同條款意識(shí)形態(tài)本身就不能拆成小文件補(bǔ)變手段離線預(yù)切分在文檔進(jìn)入 SPIFFS 之前先用 LLM 切成有標(biāo)題的小章節(jié)每章獨(dú)立存為一個(gè) .md用 LLM 做離線 chunking 的語(yǔ)義版本加 read_file_section(path, section) 工具讓 LLM 能按 markdown 二級(jí)標(biāo)題精讀一段頁(yè)碼 摘要外掛每個(gè)長(zhǎng)文檔配一份 .toc.md列出小節(jié)摘要 起止行號(hào)LLM 先讀 toc 再精讀真正長(zhǎng)文場(chǎng)景需要 chunk embedding這時(shí)候徹底承認(rèn)現(xiàn)行哲學(xué)不適用回到經(jīng)典 RAG臨界點(diǎn)單文檔 8 KB超過(guò) tool_result 上限就必須有切分機(jī)制 32 KB 基本必須 RAG 化。綜合判斷什么時(shí)候該考慮 “補(bǔ)變”把上面六個(gè)場(chǎng)景歸納成一張決策表信號(hào)該補(bǔ)變什么緊迫程度文件數(shù) 200加 search_files 分類(lèi)目錄中用戶(hù)切到 mini/小模型inline 高頻內(nèi)容 縮短 ReAct高出現(xiàn)實(shí)時(shí)控制需求加快速通道繞過(guò) Agent高多用戶(hù)場(chǎng)景加鎖 分用戶(hù)記憶看部署處理長(zhǎng)文檔離線切分 section 工具低如果不做這個(gè)產(chǎn)品就不需要文件名失去語(yǔ)義加 INDEX.md 強(qiáng)制命名約束低設(shè)計(jì)早期就避免總體原則先觀察失敗模式用戶(hù)問(wèn)了什么、LLM 做了什么、最終給了什么答案再判斷對(duì)應(yīng)哪種崩塌場(chǎng)景。不要預(yù)防性地引入復(fù)雜度—MimiClaw 當(dāng)前的 “零 RAG 基礎(chǔ)設(shè)施” 在 90% 個(gè)人場(chǎng)景里都?jí)蛴眠^(guò)早加 vector store反而把5美元芯片純本地的故事毀了。元層面的崩塌哲學(xué)本身的“成立條件“在變MimiClaw的整套上下文工程哲學(xué)本質(zhì)是押注“frontier LLM的能力會(huì)持續(xù)增強(qiáng)、價(jià)格會(huì)持續(xù)下降”。如果未來(lái)某天frontier model價(jià)格反轉(zhuǎn)上漲→多輪tool_use成本不可承受模型能力被監(jiān)管限制function-calling 被收窄、tool_use被審計(jì) → 主動(dòng)檢索不可靠用戶(hù)隱私法規(guī)要求所有處理本地化 → 不能依賴(lài)外部LLM API那么“用frontier model 智能換基礎(chǔ)設(shè)施復(fù)雜度“這筆賬就需要重新算了一一一整個(gè)哲學(xué)的根基會(huì)被動(dòng)搖而不是某個(gè)具體崩塌場(chǎng)景。屆時(shí)MimiClaw 可能需要切換到純本地小模型經(jīng)典RAG 的范式但那已經(jīng)是另一個(gè)產(chǎn)品了。這層“宏觀崩塌“提醒我們?nèi)魏?Agent架構(gòu)都是和當(dāng)下LLM生態(tài)綁定的工程權(quán)衡沒(méi)有永恒正確。MimiClaw的優(yōu)雅恰恰來(lái)自于它清醒地接受了這種時(shí)代依賴(lài)一它沒(méi)裝作自己是放之四海而皆準(zhǔn)的方案而是給定 2024-2026的LLM現(xiàn)狀下的最優(yōu)近似解。0xFF 參考