【OpenClaw具身硬件】MiniClaw 阅读笔记—(4) 文件读写文章目录【OpenClaw具身硬件】MiniClaw 阅读笔记---(4) 文件读写0x00 概要0x01 Read file RAG1.1 经典RAG的工作方式1.2 MimiClaw反过来LLM是检索的发起者1.3 为什么这么做动机1MCU跑不动经典RAG的基础设施动机2可解释性可调试性动机3LLM已经具备“读懂目录页自主路由“的能力判断1在LLM足够强的时代“检索“和“思考“的边界正在消融判断2:“让LLM自己读“会带来质的不同1.4 为什么能“工作“机制1上下文里始终有“地图“机制2纪律性的prompt协议机制3文件系统作为“扁平知识库”和 Agentic-RAG/ Function-calling RAG 的关系1.5 代价隐含假设崩塌场景1知识库规模超过“目录页极限“ 现象崩塌场景2文件名标题不再具备“语义自描述性“ 现象崩塌场景3换了一个不够强的模型崩塌场景4延迟敏感场景实时控制、对话感现象崩塌场景5多用户共享/高并发知识更新崩塌场景6知识是连续大段落不是离散文档现象综合判断什么时候该考虑 补变元层面的崩塌哲学本身的“成立条件“在变0xFF 参考0x00 概要MimiClaw 是**$5 芯片上的 AI 助理OpenClaw。没有 Linux没有 Node.js纯 C。**用户在 Telegram 发一条消息ESP32-S3 通过 WiFi 收到后送进 Agent 循环 — LLM 思考、调用工具、读取记忆 — 再把回复发回来。同时支持Anthropic (Claude)和OpenAI (GPT)两种提供商运行时可切换。一切都跑在一颗 $5 的芯片上所有数据存在本地 Flash。本篇会对MiniClaw 的思路和实现细节做进一步讨论。LLM自主read_file替代RAG检索”把检索的决策权从外部基础设施交还给 LLM把检索基础设施从向量数据库简化为文件系统把“准备上下文这个动作从prompt阶段后移到推理阶段一用 frontier model 的语义理解力换掉了所有embedding/index/rerank组件。这是一个只有在大模型时代才成立的设计选择也是MimiClaw能够把“完整Agent塞进5美元芯片的关键技术杠杆之一。如果不是这个判断MimiClaw就得在云端跑一套检索服务整个“纯C/纯本地/ 0.5W的产品故事会塌掉。0x01 Read file RAGMiniClaw 用 LLM自主read_file 替代RAG检索。它包含一个隐含的对照一经典 RAG是“系统替 LLM决定要看什么而MimiClaw反过来一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);我们就来看看其思路和优劣。1.1 经典RAG的工作方式经典RAG云端常见由外部管线主导用户提问 ↓[Embedding模型】把问题编码成向量[向量数据库]↓ 检索top-K最相似段落 ↓[Reranker/过滤]可选 ↓ 把段落塞进 system prompt 或 user message ↓ LLM接收已经准备好的上下文→生成回答关键特征LLM只是消费者。它在收到prompt之前就已经被“喂饱“了一检索过程对模型完全不可见模型也无法对检索结果做主动反馈除非套一层 agentic-RAG但那已经是MimiClaw的方向了1.2 MimiClaw反过来LLM是检索的发起者MimiClaw没有上述任何一步外部检索。代替它的是这样一个流程用户提问 ↓ LLM看到的system prompt只包含-静态指令工具列表-几份“目录页”MEMORY摘要、Skills标题、文件路径约定 LLM判断“要回答这个问题我需要看x文件“ ↓ LLM主动发起tool_use:read_filepath/spiffs/skills/weather.md)↓ agent_loop 执行 tool把文件内容作为 tool_result 塞回 messages ↓ LLM拿到内容再决定下一步继续检索/回答/调其他工具关键反转LLM不再是“被喂饱的消费者”而是**主动伸手取阅的读者“**。检索从“发生在LLM之前的预处理“变成了“发生在 LLM思考过程中的工具调用“。1.3 为什么这么做三个层面的动机如下。动机1MCU跑不动经典RAG的基础设施回顾经典RAG的依赖项组件MCU上的代价Embedding模型哪怕MiniLM量化几MB模型权重 数百ms CPU推理不可接受向量数据库FAISS/Annoy/hnsw索引文件几十MBPSRAM装不下文档分块索引构建管线需要离线预处理服务器Reranker又一个模型任意一项都超出ESP32-S3的资源预算。要么把这些放云端增加网络依赖、隐私问题、服务器成本要么放弃经典 RAG。MimiClaw选择了后者。动机2可解释性可调试性经典RAG的一个老大难是“为什么这次检索结果不好“—是chunk太大embedding模型不匹配top-K截断了re-ranker 出错调试链路长。MimiClaw这套机制下每一次“检索“都是一个清晰可见的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那个文件被读了、读到了什么、为什么读都能从串口日志一行行看下来。调试RAG退化为调试一段对话。动机3LLM已经具备“读懂目录页自主路由“的能力LLM的指令遵循能力强到可以替代很多原本需要专门管线的工作给它一个目录“这里有5个skill分别是X/Y/Z…它能根据用户问题自动判断“用户问天气我应该读weather.md然后发起对应的read_file调用这本质上是把“检索路由“这层职责从embedding相似度转交给了LLM 的语义理解。在大模型时代之前这是天方夜谭一以前的小模型理解不了“目录“的隐喻但今天的frontier model目录页就是它的索引。MimiClaw做的不过是信任这种能力并把它写进prompt协议里。当然这种做法是基于以下两个判断。判断1在LLM足够强的时代“检索“和“思考“的边界正在消融经典RAG的预设是检索是廉价的预处理推理是昂贵的核心计算所以要把检索做厚、做精、把“对的内容“喂进去。MimiClaw反过来预设LLM 的推理已经强大到可以把“决定看什么“也包含进去。因此把检索作为推理的一部分tool_use而不是推理之前的独立阶段。这种范式在云端也有同样的趋势Claude 的 agentic browsing、GPT 的 file_search toolMimiclaw 只是因为资源约束被迫走得更彻底。判断2:“让LLM自己读“会带来质的不同经典RAG模型被动接受N段文本无法判断“还需要再多一段”。MimiClaw模式模型可以读完一份文件后觉得不够继续read_file第二份一这是一个真正的迭代过程ReAct循环最多10次工具调用让LLM可以深度探索Q我上周三跟你说了什么 LLM: list_dir(/spiffs/sessions/) → 看到tg_12345.jsonl LLM:read_file(/spiffs/sessions/tg_12345.jsonl) → 看到20条最近消息没有上周三 LLM:read_file(/spiffs/memory/2026-04-22.md) → 找到当天日记 LLM最终回答这种“翻找 → 看一眼 → 决定再翻 → 给答案“的过程更接近人类查资料而不是“系统给我5个段落我从中挑”。信息密度低、覆盖面广的场景下主动检索往往优于被动top-K一尤其是MimiClaw这种文件数量本来就少几十到几百的场景。1.4 为什么能“工作“光说让LLM自己读“是不够的MimiClaw至少有三件事在协同支撑这个范式机制1上下文里始终有“地图“context_builder.c把这些总是出现在system prompt里工具列表包含read_file、list_dir等“探索性“工具MEMORY.md内容让LLM知道“我已经记得什么Skills目录页让LLM知道“还有哪些文件值得看路径约定/spiffs/memory//spiffs/skills//spiffs/sessions/)这构成了一份“知识地图“。LLM不需要embedding也能知道该去哪里找东西一一一因为地图本身就告诉了它。机制2纪律性的prompt协议回看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这些是用自然语言写出的检索时机规则一什么时候应该主动read。它们替代了经典RAG里的“检索触发器逻辑但实现成本只是几行markdown。机制3文件系统作为“扁平知识库”SPIFFS上的所有文件都是markdown/JSONL人类可读、模型可读、可枚举。LLM可以用list_dir(“/spiffs/skills/”)发现资源用read_file加载特定资源用write_file/edit_file修改资源整个文件系统就是一个“模型可寻址的知识库”。它不用建索引因为LLM自己能读懂weather.md 里大概是天气相关内容“一一一文件名 标题 第一段就是天然的语义索引。和 Agentic-RAG/ Function-calling RAG 的关系熟悉Agent架构的人会问这不就是Agentic RAG/ReActretrieval tools吗是的这正是Agentic RAG的一种极简形态。但MimiClaw把它推到一个更极端的位置维度典型 Agentic RAGMimiClaw检索后端仍然是向量库 / 关键词索引就是文件系统 路径工具复杂度多个检索工具 重排三五个文件操作工具索引维护需要离线管线更新 embedding零索引—LLM 写文件即 “更新索引”知识演化重新跑 ingest pipelineLLM 自己 write_file 立即生效可观测性检索日志 LLM 日志只有 tool_use 日志统一视图所以更准确的描述是MimiClaw是“把Agentic RAG简化到只剩文件系统“的极致版本。1.5 代价为了平衡必须承认这套哲学的代价代价说明延迟更高每次 read_file 都是一轮 LLM 调用10 KB 文件 ReAct 多轮 数秒到十几秒token 成本可能更高主动探索会重复加载文件内容到 messages依赖模型能力弱模型不会主动检索会瞎答只有 Claude/GPT 这种级别的模型才能稳定执行大规模知识库无效文件超过几百个时目录页塞不下LLM 无法发现所有可用资源缺少跨文档融合没有 reranker / fusion靠 LLM 自己把多个 read_file 结果 “在脑子里” 融合所以这种哲学的适用边界很清晰适合知识库小1000 文件、文件本身有清晰命名、运行 frontier-class LLM的场景。MimiClaw完美卡在这个区间— 一台个人设备上的几十份 markdownAnthropic/OpenAI 顶级模型天作之合。要是哪天有人想拿MimiClaw这套架构去管10万份企业文档那才是真正需要回归经典 RAG的时刻。隐含假设这套哲学依赖几个隐含假设 ----- 一旦假设失效整个范式就会出问题。它的隐含假设大致有六条知识库规模小到能在目录页里列得完文件命名标题已经具备语义可识别性LLM模型足够强、能稳定自主路由用户对多轮tool_use的延迟与成本可接受知识更新频率低/由LLM自己负责更新知识结构是离散文档不是连续大段落每条假设崩塌时触发的失败模式不同需要的“补变“也不同。崩塌场景1知识库规模超过“目录页极限“ 现象当文件数从几十涨到几千context_builder.c里Skills段那块2KB缓冲再也装不下完整目录。要么截断LLM 看不到后半部分文件要么膨胀systemprompt突破16KB上限。更隐蔽的失败即使prompt还能装下LLM在100条目录里也找不准一注意力分散召回率掉到不可用。补变手段从“全量目录“退化为“分层索引检索”等级做法一级补变把 skills 按目录分类/spiffs/skills/home/, /spiffs/skills/work/目录页只列类别而非文件二级补变引入 search_files(query) 工具做文件名 标题的关键词匹配不是 embedding是 BM25/正则。LLM 不再看完整目录而是先 search 再 read三级补变上云端做向量检索—这时候已经回到经典 RAG承认 MCU 不再适合作为单点处理器需要外挂检索服务崩塌场景2文件名标题不再具备“语义自描述性“ 现象LLM自主路由依赖文件名足以暗示内容。但当文件命名失去这种性质自动生成的文件名note_a8f3c2.md、UUID命名用代号/内部缩写PROJ-X42-spec.md大量同质化标题每天日记都叫日记标题没区分度LLM看到目录就懵了一它只能乱试或完全放弃主动检索。触发条件系统自动归档机制把“语义命名“剥夺了多语言混杂中文文件名英文LLM训练偏置极度专业领域医学代码、化学命名LLM训练时见过少补变手段强制语义命名在write_file工具的 prompt 里加约束“filename should describe content in 3-5words”加目录段落描述每个目录放一份INDEX.md由LLM维护列“这个目录里有什么“文件首行强制为 #Human-readable Title—skill_loader.c已经这么做了可推广核心思路把“语义“从“文件名“扩展到”自我描述的元数据”让目录页的每一项都自带摘要。崩塌场景3换了一个不够强的模型补变手段缩短 ReAct链在弱模型上把工具调用上限从 10砍到 3避免迷路预加载策略在context_builder.c里直接inline 一份“今日相关“内容比如总是把今天的日记完整塞进去不依赖 LLM主动读简化目录页每次只暴露3-5个最相关的 skill由路径前缀或最近使用时间筛选回退到经典 RAG当模型置信度不足时外挂一个 BM25/embedding 服务做硬路由本质弱模型场景下要把更多决策权拿回到prompt builder手里一philosophy从“信任LLM逐步退回“系统辅助LLM。崩塌场景4延迟敏感场景实时控制、对话感现象“看目录→读文件→综合→回答“是一个串行的多轮LLM调用。每一轮HTTPSTLSLLM推理都是3-10秒。如果回答需要读3个文件总延迟可达30秒。但有些场景完全不能等候智能家居语音助手“开灯“必须1秒内响应紧急通知火警、安防触发短回合社交聊天用户期待5秒响应感这些场景下 ReActread_file的延迟模型直接出局。补变手段分级路由在LLM调用前用一段轻量C代码做意图识别关键词匹配命中“控制类“指令直接走GPIO工具不进ReAct 循环预热缓存把高频文件MEMoRY.md、今日日记在 system prompt 阶段就完整inlineLLM 不需要再 read 猪异步预读心跳触发时预读高概率文件并缓存到PSRAMagent_loop命中时省一次 read流式响应如果未来支持让LLM边读文件边输出“正在查记忆…“给用户填充感这个崩塌场景指向一个更大的真相Agentic RAG的“灵活性“和“延迟“是天敌。MimiClaw 的设计偏向前者所以低延迟场景需要绕过整个Agent循环走快速通道。崩塌场景5多用户共享/高并发知识更新现象当前架构假设-个LLM主动维护一份记忆所以用 read_fileMEMoRY.md之前必须 read再edit_file 写一这本质是乐观锁丢失版。如果出现多个用户同时和同一个MimiClaw对话Heartbeat在写MEMORY.md时用户也在触发对话Cron任务回调和 Telegram消息并发处理LLM看到的MEMORY.md可能已经被另一条路径改过了但LLM用的是几秒前的快照来edit_file写回时静默覆盖了别人的修改。触发条件多用户家庭部署爸爸妈妈孩子各自和同一台MimiClaw对话IoT群部署一个集群共用一份记忆高频心跳高频对话叠加补变手段加文件级锁在memory_store.c里用 FreeRToSmutex 包 read-modify-write但这只解决并发写按用户分文件MEMORY.md改为MEMORY_uSer_id.md避免共享append-only模型永远不edit只append定期由 LLM触发“压缩归档但归档窗口短丢失少真正的并发场景退到云端embedded不适合做共享状态权威源应该外挂一个KV服务这个崩塌场景揭示了一个本质限制MCU单设备适合做单用户的私人助理不适合做多用户的共享大脑。崩塌场景6知识是连续大段落不是离散文档现象MimiClaw的“文件即知识单元“假设最适合离散、可独立解读的小文档一一份skill、一天日记、一段GPIO 守则。但当知识形态是一本200页的产品手册不能整个read分块又丢上下文一份长会议录音转写线性叙述无章节法律合同/学术论文需要跨节引用大段聊天历史信息分散在数百条对话里LLM没法用一次read_file“解决又没有chunkingranking的基础设施去定位段落。它只能盲读或放弃。触发条件用户希望 MimiClaw 帮自己 “读一份长文档”客服场景需要查询长合同条款意识形态本身就不能拆成小文件补变手段离线预切分在文档进入 SPIFFS 之前先用 LLM 切成有标题的小章节每章独立存为一个 .md用 LLM 做离线 chunking 的语义版本加 read_file_section(path, section) 工具让 LLM 能按 markdown 二级标题精读一段页码 摘要外挂每个长文档配一份 .toc.md列出小节摘要 起止行号LLM 先读 toc 再精读真正长文场景需要 chunk embedding这时候彻底承认现行哲学不适用回到经典 RAG临界点单文档 8 KB超过 tool_result 上限就必须有切分机制 32 KB 基本必须 RAG 化。综合判断什么时候该考虑 “补变”把上面六个场景归纳成一张决策表信号该补变什么紧迫程度文件数 200加 search_files 分类目录中用户切到 mini/小模型inline 高频内容 缩短 ReAct高出现实时控制需求加快速通道绕过 Agent高多用户场景加锁 分用户记忆看部署处理长文档离线切分 section 工具低如果不做这个产品就不需要文件名失去语义加 INDEX.md 强制命名约束低设计早期就避免总体原则先观察失败模式用户问了什么、LLM 做了什么、最终给了什么答案再判断对应哪种崩塌场景。不要预防性地引入复杂度—MimiClaw 当前的 “零 RAG 基础设施” 在 90% 个人场景里都够用过早加 vector store反而把5美元芯片纯本地的故事毁了。元层面的崩塌哲学本身的“成立条件“在变MimiClaw的整套上下文工程哲学本质是押注“frontier LLM的能力会持续增强、价格会持续下降”。如果未来某天frontier model价格反转上涨→多轮tool_use成本不可承受模型能力被监管限制function-calling 被收窄、tool_use被审计 → 主动检索不可靠用户隐私法规要求所有处理本地化 → 不能依赖外部LLM API那么“用frontier model 智能换基础设施复杂度“这笔账就需要重新算了一一一整个哲学的根基会被动摇而不是某个具体崩塌场景。届时MimiClaw 可能需要切换到纯本地小模型经典RAG 的范式但那已经是另一个产品了。这层“宏观崩塌“提醒我们任何 Agent架构都是和当下LLM生态绑定的工程权衡没有永恒正确。MimiClaw的优雅恰恰来自于它清醒地接受了这种时代依赖一它没装作自己是放之四海而皆准的方案而是给定 2024-2026的LLM现状下的最优近似解。0xFF 参考