钉核 上下文)
【OpenClaw具身硬件】MiniClaw 阅读笔记—(2)钉核 上下文文章目录【OpenClaw具身硬件】MiniClaw 阅读笔记---(2)钉核 上下文0x00 概要0x01 双核配置1.1 ESP32-S3 核1.2 MimiClaw实际的钉核决策1.3 钉核原因引力1WiFi/lwIP协议栈默认绑Core 0引力 2HTTPS cJSON是真正的 CPU大户需要独占核引力 3FreeRTOS任务亲和性API 鼓励显式分核1.4 如果改成单核或反过来钉会怎样1.5 一句话总结0x02 上下文工程策略特色2.1 整体策略分层装配单缓冲一锤定音。2.2 五条特色策略特色1静态指令动态文件的“双层“系统提示特色2分级时间窗的记忆一长期/近期/当前特色3Skills是“目录页按需取阅不是全量灌入特色4会话历史用RingBuffer截断硬上限即护栏特色5上下文是prompt工程纪律不是数据结构2.3 和云端Agent的对照表0x03 SOUL.md与Prompt压缩的表达得失3.1 为什么必须被压缩3.2 表达策略手法1用“标签形容词“代替“叙事例子“手法2用类别Personality/Values做语义分组手法3断言式英语零修辞、零反例3.3 压缩带来的“失“失1人格趋同失2复杂指令丢失失3风格不可学习失4跨语言表达单薄3.4 压缩带来的“得“3.5 可能的折中分层SOUL思路1核心SOUL可选片段思路2用few-shot取代抽象形容词思路3用元数据替代散文思路4让记忆反哺人格7.6 小结0xFF 参考0x00 概要MimiClaw 是**$5 芯片上的 AI 助理OpenClaw。没有 Linux没有 Node.js纯 C。**用户在 Telegram 发一条消息ESP32-S3 通过 WiFi 收到后送进 Agent 循环 — LLM 思考、调用工具、读取记忆 — 再把回复发回来。同时支持Anthropic (Claude)和OpenAI (GPT)两种提供商运行时可切换。一切都跑在一颗 $5 的芯片上所有数据存在本地 Flash。本篇会对MiniClaw 的思路和实现细节做进一步讨论。0x01 双核配置MiniClaw 使用双核分工来保证关键控制任务不受AI推理延迟影响 Core1大脑专注AI推理和决策即运行agent_loop。Core0小脑处理实时硬件控制和传感器读取对应的架构如下1.1 ESP32-S3 核ESP32-S3的核到底是怎样的具体如下维度实际情况核数2个Xtensa LX7240MHz对称性完全对称SMP一指令集、缓存、外设访问权限都一致命名Core 0PRO_CPUCore 1APP_CPU命名是历史习惯硬件上没区别FreeRTOSESP-IDF跑的是 SMP FreeRTOS任意任务可调度到任意核中断中断可以路由到任一核启动时按“谁先attach谁拿“的策略结论硬件层面两个核是平等的没有“必须谁干I/O、谁干计算“的规则。这一点和 ARM big.LITTLE异构或Cortex-M 单核完全不同。为什么Mimiclaw还是把I/O 钉在Core 0、Agent钉在Core 1这是因为有几条“事实上的引力“把任务往特定核拉。1.2 MimiClaw实际的钉核决策任务绑定真正原因tg_pollTelegram 长轮询Core 0紧贴 WiFi 栈网络密集Feishu webhook pollerCore 0同上ws_serverhttpdCore 0同上outbound 派发Core 0输出走网络serial_cliCore 0UART ISR 默认在 Core 0CLI 几乎不耗 CPU跟 I/O 一起放无影响agent_loopCore 1唯一 CPU 重活需要独占核WiFi 内部任务Core 0IDF 默认没去改cron / heartbeat没强制绑用默认触发频率极低无所谓可以看到Core 1上几乎只有agent_loop在跑这是有意识地“留白—让LLM推理路径享受最低延迟、最少抢占。1.3 钉核原因引力1WiFi/lwIP协议栈默认绑Core 0ESP-IDF的WiFi驱动有一个kconfig选项CONFIG_ESP_WIFI_TASK_CORE_ID默认值是0。它本身可以改成1或NO_AFFINITY但绝大多数项目包括 MimiClaw保持默认。这带来的连锁反应WiFi 中断处理、RX/TX任务都跑在Core 0。lwIP 的 tcpip_thread 也通常跟在 Core 0。这意味着网络收包路径已经在Core 0占了一块时间片。如果把Telegram poller、WS server、HTTPS 客户端再放 Core 1每次收包都要跨核唤醒一增加上下文切换、缓存抖动和不可预测延迟。把“用网络的人“和“实现网络的人“放同一核是性能上几乎免费的优化。这条不是硬限但调整代价很高所以在工程上接近硬限。引力 2HTTPS cJSON是真正的 CPU大户需要独占核一次 LLM 请求要构建几 KB 到几十 KB的 cJSON树再序列化、TLS 加密。收回来的4KB-32KB响应要TLS解密cJSON解析。这两段是MimiClaw里唯一能持续打满一个核的工作。如果让它和WiFi/lwIP抢Core 0:推理期间网络中断响应会变慢长轮询超时风险增加。TLS握手中如果被 WiFi中断频繁打断握手时间会显著拉长。串口CLI的 REPL可能卡住影响调试体验。所以把Agent钉到Core 1本质是给重CPU任务一个安静的专核环境不被WiFi中断和 I/O 任务搅扰。这是纯软件设计选择硬件没有要求这么做。引力 3FreeRTOS任务亲和性API 鼓励显式分核ESP-IDF 提供的 xTaskCreatePinnedToCore…core_id让你必须显式选核或写 tskNO_AFFINITY让调度器自由迁移写tskNO_AFFINITY看似省事但任务在两核之间漂移会导致 cachemiss、TLS上下文切换成本高。多数ESP-IDF教程和开源项目采用“显式钉核“风格。MimiClaw跟这条主流约定走所以 mimi_config.h 里每个任务都有 MIMI_*_CORE 宏。这是生态惯例不是硬件限制。1.4 如果改成单核或反过来钉会怎样我们做几个反事实推演能更清楚看出“是设计选择还是硬限方案结果说明全 NO_AFFINITY让 SMP 调度器自由迁移能跑但 TLS 握手抖动会变大PSRAM cache miss 增多证明硬件不强制Agent 钉 Core 0、I/O 钉 Core 1能跑但跨核唤醒成本翻倍因为 WiFi 中断在 Core 0证明 WiFi 软约束的影响全部跑 Core 0关掉 Core 1也能跑性能下降明显——LLM 调用期间整个机器看起来“假死”证明只是性能问题不是功能问题WiFi 也改到 Core 1改 kconfig 即可但 lwIP 配套调整有一堆隐式坑证明默认 Core 0 是软约束但不轻易动如果是ESP32-C3单核RISC-V那种型号MimiClaw这套架构理论上也能跑只是所有任务排队共享一个核LLM推理期间网络/CLI响应会明显变慢一但这是性能退化而不是功能不可用。1.5 一句话总结双核分工不是ESP32-S3硬件强迫的产物一两个核硬件上完全对称。但WiFi协议栈默认在Core 0这条IDF软约束加上LLM推理是唯一持续打满CPU的任务这个工作负载特征让I/O留 Core 0、Agent独占Core 1成为唯一在工程上明智的分法。所以更准确的说法是硬件给了对称双核这个机会软件生态和负载画像把分工塑造成了今天的样子。如果哪天换了一颗单核MCUMimiClaw的代码框架基本不需要重写只是性能会差一截如果换到四核 SoC比如 ESP32-P4就有空间把“工具调度“或“记忆压缩“再分一个独立核一架构是为这种扩展留了余地的。0x02 上下文工程策略特色把context_builder.cmemory_store.csession_mgr.cskill_loader.c这四块代码放在一起看能提炼出一套为 Mcu 资源约束量身设计的上下文工程方法论。MimiClaw 和云端AgentLangChain/LlamaIndex一类的常规做法有几个明显不同。MimiClaw的上下文工程不是“如何把更多信息塞进prompt而是在16KB的硬约束里用markdown文件工具调用把“检索、摘要、技能加载“这些通常由后端管线完成的工作全部交给 LLM自己用纪律去执行。MimiClaw把上下文窗口当作一份永远在线的“配置工作记忆把SPIFFS当作可被LLM读写的“扩展存储”把tool_use 当作连接两者的“虚拟内存换页机制”。这种“窗口小但有外存“的范式是嵌入式Agent实践中非常有意思的一笔。2.1 整体策略分层装配单缓冲一锤定音。每次轮到Agent处理消息时完整prompt都在一个固定大小的缓冲区里现搭现拼char*system_promptheap_caps_ca1loc(1,MIMI_CONTEXT_BUF_SIZE/*16KB*/,MALLOC_CAP_SPIRAM);context_build_system_prompt(system_prompt,MIMI_coNTEXT_BUF_SIZE);context_build_system_prompt() 把以下内容按固定顺序追加进同一个16KB缓冲1.硬编码的我是谁工具清单GPIO守则记忆守则Skills守则2.SOUL.md人格3.USER.md用户画像4.Long-term Memory---MEMORY.md最多4KB5.Recent Notes---最近3天的daily notes最多4KB6.Available Skills---skill 标题简介列表最多2KB这是第一个特色上下文不是检索出来的是装配出来的。云端RAG那一套“先embedding检索top-k chunk在MCU 上不可行向量库放不下、embedding模型跑不动所以 MimiClaw 预先约定好哪几个文件总是进上下文靠人格/记忆文件的写入纪律来控制信息密度。2.2 五条特色策略特色1静态指令动态文件的“双层“系统提示context_builder.c里能看到一个清晰分层层内容谁负责静态层硬编码工具清单、记忆/Skills使用纪律、安全护栏开发者编译期固定动态层文件SOUL.md、USER.md、MEMORY.md、daily notes、skill 索引LLM自己用户运行期可变静态层提供不可被覆盖的护栏比如读MEMORY.md之前一定先read_file、“GPIO 引脚由策略校验动态层提供可演化的人格和记忆。云端Agent通常把所有prompt放在一份yaml/markdown里随版本走MimiClaw把它显式劈成“代码里的部分“和“文件系统里的部分”—前者跟固件一起OTA后者用户/AI自己改不用重刷。特色2分级时间窗的记忆一长期/近期/当前三个时间尺度叠加覆盖了“我是谁、最近发生了什么、刚才在说什么“层来源大小上限更新频率长期记忆MEMORY.md4KB显著事件由LLM自己edit_file近期记忆最近3天YYYY-MM-DD.md4KB每天累加当前记忆由ring buffer控制每轮自动代码里memory_read_recent(buf4096days3)写死了“最近3天这是用时间窗 字节上限双重截断的非常嵌入式风格的做法一既不用算 token也不会因为某天日记太长而爆缓冲。值得注意的是当前会话历史不进system prompt而是作为messages[]数组传给LLM只有“当前消息之前的对话“才出现在messages里。这种system prompt长期身份 messages当前剧情的切分非常干净。特色3Skills是“目录页按需取阅不是全量灌入这是MimiClaw上下文工程最具特色的一招。skill_loader_build_summary()只往system prompt里塞每个skill的第一行标题第一段描述最多2 KB完整内容存在/spiffs/skills/.md。LLM看到的是这样的“目录页## Available Skills Available skills (use read_file to load full instructions): - daily-briefing:Generate a morning briefing summarizing todays plans.. - gpio-control: Patterns for controiling LEDs, relays, and switches. - skill-creator:Create new skills for MimiClaw. - weather:Fetch andpresent weather information.当用户的问题命中某个skill时LLM自己决定调read_file(“/spiffs/skills/weather.md”)。把完整指令拉进对话。本质是把“检索“这一步外包给了LLM的判断----用tool_use 替代embedding。这套设计的妙处零检索基础设施不需要向量库、不需要BM25索引。天然可解释哪个skill被加载是显式的工具调用日志一目了然。可演化skill-creator 这个 meta-skill让AI自己写新skill 存到SPIFFS下次重启就生效。token友好默认上下文里只有几百token的“目录真正展开的skill只在需要时占token。这是一种典型的“progressive disclosure”上下文管理和Anthropic自己提倡的skills模式高度一致但用SPIFFS 平文本tool_use实现没有任何额外依赖。特色4会话历史用RingBuffer截断硬上限即护栏memory/session_mgr.c 里cJSON *messages[MIMI_SESSION_MAX_MSGS];// 20每次加载会话只读JSONL文件末尾2O条超过的更老的行保留在文件里但不进prompt。这样token预算可预测20条×平均长度最坏不会爆4096 max_tokens。长期对话不会让LLM反复重读长历史导致延迟和成本升。完整历史依然在SPIFFS里可以被read_file精准引用“上周我们说过的那个项目云端Agent常用的“动态摘要渐变窗口“在MCU上太昂贵MimiClaw直接用文件 摘要工具替代摘要管线一LLM 觉得需要时自己写到MEMORY.md等于把摘要的责任转嫁给LLM自身。特色5上下文是prompt工程纪律不是数据结构仔细看硬编码的部分会发现它不只是“我是谁”还包含了一份操作规范- Always read_file MEMORY.md before writing, so you can edit_file to update without losing existing content.-Use get_current_time to know todays date before writing daily notes. - Keep MEMoRY.md concise and organized - summarize, dont dump raw conversation. - You should proactively save memory without being asked. - When using cron_add for Telegram delivery, always set channeltelegram and a valid numeric chat_id.些是用自然语言写在系统提示里的“协议”一把“如何安全地维护自身记忆“以纪律的形式固化进上下文。背后的设计假设是LLM是上下文的协作者不是被动消费者。上下文工程的一半工作不是“喂数据”而是“教模型如何写回这些数据”。这和把MEMORY/USER/SOUL都做成LLM可读可写的markdown是同一套理念的两面上下文不是只读的快照而是一个LLM 与文件系统共同维护的可演化状态。2.3 和云端Agent的对照表维度云端 RAG/AgentMimiClaw检索向量库 top-kLLM 自主 read_file摘要专门的 summarization chainLLM 写 MEMORY.md长记忆数据库 embedding平 markdown 文件短记忆滑动窗口 摘要固定 20 条 ring bufferSkills/Tools 选择RAG router / function callingtool_use 目录页Prompt 拼装yaml Jinja 模板C 函数 snprintf上下文上限数十/数百 KB token硬性 16 KB 字节是否可演化通常需要重新部署LLM 自己改文件即生效0x03 SOUL.md与Prompt压缩的表达得失MimiClaw出厂的SOUL.md 如下I am MimiClaw, a personal AI assistant running on an ESP32-S3 microcontroller. Personality: - Helpful and friendly - Concise and to the point - Curious and eager to learn Values: - Accuracy over speed - User privacy and safety - Transparency in actions只有11行、约250字节、不到100个token。这份“灵魂“在Agent每一轮都被原样追加到16KB 上下文窗口里。看起来朴素但它承担着MimiClaw整个prompt压缩策略的所有得失。3.1 为什么必须被压缩为什么SOUL.md必须被压缩回顾上下文预算mimi_config.h区段上限整个 system prompt16 KB (MIMI_CONTEXT_BUF_SIZE)静态指令工具说明 守则~3 KB硬编码SOUL.md USER.md期望 ≤1 KBMEMORY.md≤4 KBRecent Notes3 天≤4 KBSkills 目录页≤2 KB留给 messages[] 的余量~2 KBSOUL.md一旦写到2KB长期记忆和近期日记就要被挤压。这是一个零和博奔的预算人格表达多一分记忆容量少一分。所以“如何用最少的字节传达最丰富的人格“成了核心命题。云端Agent不存在这个问题一GPT-4o的128K窗口里塞5KB人格描述毫无压力。MimiClaw 16KB窗口里塞5KB 人格就是用记忆换戏剧性而记忆的丧失会让“长期相处“这个产品卖点崩塌。3.2 表达策略当前SOUL.md的表达策略极简、列表化、断言式。仔细看默认SOUL.md的写法能看出三条压缩手法手法1用“标签形容词“代替“叙事例子“Helpful and friendlyConcise and to the point而不是I always try to be helpful by anticipating what the user needs before they ask. For examplewhen someone says Im tired,Imight gently suggest taking a break.得信息密度极高3个词传达一个特质每条~8token。失LLM 缺乏“行为锚。“Helpful 在不同文化、不同上下文里可解释空间巨大没有具体例子模型只能调用训练分布里的“平均helpful。手法2用类别Personality/Values做语义分组把零散特质按“性格/价值观“两栏分类让LLM用语义槽位读取而不是逐字记忆。得扫描成本低LLM能在生成时直接“查这一栏“做风格回路。失分类粒度粗“Curious同时是性格也是价值硬塞到Personality 下显得武断缺少“语气、词汇偏好、句长偏好“等表层操作性更强的栏目。手法3断言式英语零修辞、零反例每行都是X is Y或do x形式没有avoid X、“unless Y”、X but not Z这种带条件的表达。得token 极省、歧义少。失LLM难以学到风格的边界。比如Concise没说how concise—遇到要解释复杂概念时模型会在“过度精简导致信息丢失“和“啰嗦“之间反复横跳。3.3 压缩带来的“失“压缩会带来一些问题。失1人格趋同250字节的SOUL几乎可以直接套到任意一个通用助理上“helpfulfriendlyconcise“是所有LLM 的训练目标基线。结果用户感觉MimiClaw“和默认ChatGPT没啥区别。区分度只能靠USER.md里的用户画像反向赋予一但USER.md也是同样的 1KB量级。这是SOUL.md最致命的得失点压得太狠“灵魂“就退化成“礼貌模板”。失2复杂指令丢失像“在涉及金钱建议时永远先反问、不主动给方案“这种条件型行为约束在断言式列表里很难表达。要写就要50 token 起步对预算非常不友好。结果是大量“应当如何“的细则被迫挤进硬编码静态指令开发者说了算用户/AI自己没法通过编辑 SOUL.md来微调。失3风格不可学习LLM学风格主要靠例子few-shot。但SOUL.md 里没有任何我会这样说话“的样例所以LLM只能从250字节的形容词里“反推“风格。每次生成的语气都依赖运行时温度和最近一两条对话的牵引风格不稳定。失4跨语言表达单薄USER.md里写着“Language: Chinese / English但SOUL.md里没有任何关于用中文说话时该怎样“的指引。LLM 切到中文输出时“Concise and to the point这个英文标签会被它自行翻译为“简洁”但中文里“简洁“和英文的“concise” 的文化语用并不完全对应一这种翻译丢失是单语SOUL的隐性代价。3.4 压缩带来的“得“压缩带来的“得“也很真实列出收益如下收益量化给MEMORY.md留出4KB等于约4000字节人物事实比“灵魂“的250字节宽裕16倍给Skills目录留出2KB可容纳20个skill的标题 描述减少每轮请求 token~100 token×上千轮 显著省API 费减少cJSON节点PSRAM占用16 KB缓冲不易爆TLS上传也更快用户/LLM写起来负担小250字节markdown 任何人都能改不需要prompt engineer特别是第 4条在 ESP32-S3上每减一 KB 系统提示就等于多 1 KB PSRAM 余量给 cJSON 解析一这是真金白银的资源。3.5 可能的折中分层SOUL如果想缓解“灵魂太薄”几条务实的演进方向如下都不破坏现有架构思路1核心SOUL可选片段SOUL.md保持~500字节始终加载SOUL_voice.md、souL_humor.md 等放/spiffs/skills/ 或 /spiffs/config/在 SOUL.md 末尾写When tone mattersread_file SOUL_voice.mdLLM按需加载等于把skill那套**目录页按需展开“**用到了人格上思路2用few-shot取代抽象形容词把“Concise and to the point换成一两个对话片段Example tone: User北京今天多冷 MimiClaw-3°C记得加外套。要看一周预报吗50 token的样例对LLM风格复刻力远大于5 token的标签。思路3用元数据替代散文SOUL meta: sentence_max_tokens: 40 opening_style:direct emoji_density:low languages: zh, en这种结构化形式 token 紧凑、可被 LLM 直接当 config 读避免自然语言歧义。思路4让记忆反哺人格LLM把“用户喜欢的回应风格“积累到MEMORY.md里相当于让灵魂在运行时自我演化一SOUL.md提供基线MEMORY 提供个性化外壳。这其实是MimiClaw当前架构鼓励的方向但缺少明确的prompt 纪律去引导它。7.6 小结最后回到设计哲学SOUL.md 是MCU 资源约束vs人格表达力之间的承重墙。写得太薄—人格扁平产品差异化丧失。写得太厚—记忆/技能预算被挤占长期相处感丧失。MimiClaw当前默认值是**“极薄派“**一把空间让给记忆和技能赌“长期一起生活的痕迹“比“开箱即来的鲜明性格“更能定义这个 AI是谁。这个赌注是否值得取决于产品定位如果是短交互工具型助理“帮我搜个天气薄SOUL是对的节省的预算花在工具响应上更划算。如果是陪伴型/角色扮演型助理薄SOUL是错的一用户在见到 MEMORY 沉淀之前的“前 100 次对话“会觉得它毫无个性而流失。MimiClaw默认 SOUL的 250字节本质是在押注“用户能熬过冷启动期“。这是嵌入式Agent 设计里一个非常微妙、又非常真实的取舍。0xFF 参考https://github.com/memovai/mimiclaw 【OpenClaw具身硬件】MiniClaw 阅读笔记---(2)钉核 上下文
【OpenClaw具身硬件】MiniClaw 阅读笔记—(2)钉核 上下文文章目录【OpenClaw具身硬件】MiniClaw 阅读笔记---(2)钉核 上下文0x00 概要0x01 双核配置1.1 ESP32-S3 核1.2 MimiClaw实际的钉核决策1.3 钉核原因引力1WiFi/lwIP协议栈默认绑Core 0引力 2HTTPS cJSON是真正的 CPU大户需要独占核引力 3FreeRTOS任务亲和性API 鼓励显式分核1.4 如果改成单核或反过来钉会怎样1.5 一句话总结0x02 上下文工程策略特色2.1 整体策略分层装配单缓冲一锤定音。2.2 五条特色策略特色1静态指令动态文件的“双层“系统提示特色2分级时间窗的记忆一长期/近期/当前特色3Skills是“目录页按需取阅不是全量灌入特色4会话历史用RingBuffer截断硬上限即护栏特色5上下文是prompt工程纪律不是数据结构2.3 和云端Agent的对照表0x03 SOUL.md与Prompt压缩的表达得失3.1 为什么必须被压缩3.2 表达策略手法1用“标签形容词“代替“叙事例子“手法2用类别Personality/Values做语义分组手法3断言式英语零修辞、零反例3.3 压缩带来的“失“失1人格趋同失2复杂指令丢失失3风格不可学习失4跨语言表达单薄3.4 压缩带来的“得“3.5 可能的折中分层SOUL思路1核心SOUL可选片段思路2用few-shot取代抽象形容词思路3用元数据替代散文思路4让记忆反哺人格7.6 小结0xFF 参考0x00 概要MimiClaw 是**$5 芯片上的 AI 助理OpenClaw。没有 Linux没有 Node.js纯 C。**用户在 Telegram 发一条消息ESP32-S3 通过 WiFi 收到后送进 Agent 循环 — LLM 思考、调用工具、读取记忆 — 再把回复发回来。同时支持Anthropic (Claude)和OpenAI (GPT)两种提供商运行时可切换。一切都跑在一颗 $5 的芯片上所有数据存在本地 Flash。本篇会对MiniClaw 的思路和实现细节做进一步讨论。0x01 双核配置MiniClaw 使用双核分工来保证关键控制任务不受AI推理延迟影响 Core1大脑专注AI推理和决策即运行agent_loop。Core0小脑处理实时硬件控制和传感器读取对应的架构如下1.1 ESP32-S3 核ESP32-S3的核到底是怎样的具体如下维度实际情况核数2个Xtensa LX7240MHz对称性完全对称SMP一指令集、缓存、外设访问权限都一致命名Core 0PRO_CPUCore 1APP_CPU命名是历史习惯硬件上没区别FreeRTOSESP-IDF跑的是 SMP FreeRTOS任意任务可调度到任意核中断中断可以路由到任一核启动时按“谁先attach谁拿“的策略结论硬件层面两个核是平等的没有“必须谁干I/O、谁干计算“的规则。这一点和 ARM big.LITTLE异构或Cortex-M 单核完全不同。为什么Mimiclaw还是把I/O 钉在Core 0、Agent钉在Core 1这是因为有几条“事实上的引力“把任务往特定核拉。1.2 MimiClaw实际的钉核决策任务绑定真正原因tg_pollTelegram 长轮询Core 0紧贴 WiFi 栈网络密集Feishu webhook pollerCore 0同上ws_serverhttpdCore 0同上outbound 派发Core 0输出走网络serial_cliCore 0UART ISR 默认在 Core 0CLI 几乎不耗 CPU跟 I/O 一起放无影响agent_loopCore 1唯一 CPU 重活需要独占核WiFi 内部任务Core 0IDF 默认没去改cron / heartbeat没强制绑用默认触发频率极低无所谓可以看到Core 1上几乎只有agent_loop在跑这是有意识地“留白—让LLM推理路径享受最低延迟、最少抢占。1.3 钉核原因引力1WiFi/lwIP协议栈默认绑Core 0ESP-IDF的WiFi驱动有一个kconfig选项CONFIG_ESP_WIFI_TASK_CORE_ID默认值是0。它本身可以改成1或NO_AFFINITY但绝大多数项目包括 MimiClaw保持默认。这带来的连锁反应WiFi 中断处理、RX/TX任务都跑在Core 0。lwIP 的 tcpip_thread 也通常跟在 Core 0。这意味着网络收包路径已经在Core 0占了一块时间片。如果把Telegram poller、WS server、HTTPS 客户端再放 Core 1每次收包都要跨核唤醒一增加上下文切换、缓存抖动和不可预测延迟。把“用网络的人“和“实现网络的人“放同一核是性能上几乎免费的优化。这条不是硬限但调整代价很高所以在工程上接近硬限。引力 2HTTPS cJSON是真正的 CPU大户需要独占核一次 LLM 请求要构建几 KB 到几十 KB的 cJSON树再序列化、TLS 加密。收回来的4KB-32KB响应要TLS解密cJSON解析。这两段是MimiClaw里唯一能持续打满一个核的工作。如果让它和WiFi/lwIP抢Core 0:推理期间网络中断响应会变慢长轮询超时风险增加。TLS握手中如果被 WiFi中断频繁打断握手时间会显著拉长。串口CLI的 REPL可能卡住影响调试体验。所以把Agent钉到Core 1本质是给重CPU任务一个安静的专核环境不被WiFi中断和 I/O 任务搅扰。这是纯软件设计选择硬件没有要求这么做。引力 3FreeRTOS任务亲和性API 鼓励显式分核ESP-IDF 提供的 xTaskCreatePinnedToCore…core_id让你必须显式选核或写 tskNO_AFFINITY让调度器自由迁移写tskNO_AFFINITY看似省事但任务在两核之间漂移会导致 cachemiss、TLS上下文切换成本高。多数ESP-IDF教程和开源项目采用“显式钉核“风格。MimiClaw跟这条主流约定走所以 mimi_config.h 里每个任务都有 MIMI_*_CORE 宏。这是生态惯例不是硬件限制。1.4 如果改成单核或反过来钉会怎样我们做几个反事实推演能更清楚看出“是设计选择还是硬限方案结果说明全 NO_AFFINITY让 SMP 调度器自由迁移能跑但 TLS 握手抖动会变大PSRAM cache miss 增多证明硬件不强制Agent 钉 Core 0、I/O 钉 Core 1能跑但跨核唤醒成本翻倍因为 WiFi 中断在 Core 0证明 WiFi 软约束的影响全部跑 Core 0关掉 Core 1也能跑性能下降明显——LLM 调用期间整个机器看起来“假死”证明只是性能问题不是功能问题WiFi 也改到 Core 1改 kconfig 即可但 lwIP 配套调整有一堆隐式坑证明默认 Core 0 是软约束但不轻易动如果是ESP32-C3单核RISC-V那种型号MimiClaw这套架构理论上也能跑只是所有任务排队共享一个核LLM推理期间网络/CLI响应会明显变慢一但这是性能退化而不是功能不可用。1.5 一句话总结双核分工不是ESP32-S3硬件强迫的产物一两个核硬件上完全对称。但WiFi协议栈默认在Core 0这条IDF软约束加上LLM推理是唯一持续打满CPU的任务这个工作负载特征让I/O留 Core 0、Agent独占Core 1成为唯一在工程上明智的分法。所以更准确的说法是硬件给了对称双核这个机会软件生态和负载画像把分工塑造成了今天的样子。如果哪天换了一颗单核MCUMimiClaw的代码框架基本不需要重写只是性能会差一截如果换到四核 SoC比如 ESP32-P4就有空间把“工具调度“或“记忆压缩“再分一个独立核一架构是为这种扩展留了余地的。0x02 上下文工程策略特色把context_builder.cmemory_store.csession_mgr.cskill_loader.c这四块代码放在一起看能提炼出一套为 Mcu 资源约束量身设计的上下文工程方法论。MimiClaw 和云端AgentLangChain/LlamaIndex一类的常规做法有几个明显不同。MimiClaw的上下文工程不是“如何把更多信息塞进prompt而是在16KB的硬约束里用markdown文件工具调用把“检索、摘要、技能加载“这些通常由后端管线完成的工作全部交给 LLM自己用纪律去执行。MimiClaw把上下文窗口当作一份永远在线的“配置工作记忆把SPIFFS当作可被LLM读写的“扩展存储”把tool_use 当作连接两者的“虚拟内存换页机制”。这种“窗口小但有外存“的范式是嵌入式Agent实践中非常有意思的一笔。2.1 整体策略分层装配单缓冲一锤定音。每次轮到Agent处理消息时完整prompt都在一个固定大小的缓冲区里现搭现拼char*system_promptheap_caps_ca1loc(1,MIMI_CONTEXT_BUF_SIZE/*16KB*/,MALLOC_CAP_SPIRAM);context_build_system_prompt(system_prompt,MIMI_coNTEXT_BUF_SIZE);context_build_system_prompt() 把以下内容按固定顺序追加进同一个16KB缓冲1.硬编码的我是谁工具清单GPIO守则记忆守则Skills守则2.SOUL.md人格3.USER.md用户画像4.Long-term Memory---MEMORY.md最多4KB5.Recent Notes---最近3天的daily notes最多4KB6.Available Skills---skill 标题简介列表最多2KB这是第一个特色上下文不是检索出来的是装配出来的。云端RAG那一套“先embedding检索top-k chunk在MCU 上不可行向量库放不下、embedding模型跑不动所以 MimiClaw 预先约定好哪几个文件总是进上下文靠人格/记忆文件的写入纪律来控制信息密度。2.2 五条特色策略特色1静态指令动态文件的“双层“系统提示context_builder.c里能看到一个清晰分层层内容谁负责静态层硬编码工具清单、记忆/Skills使用纪律、安全护栏开发者编译期固定动态层文件SOUL.md、USER.md、MEMORY.md、daily notes、skill 索引LLM自己用户运行期可变静态层提供不可被覆盖的护栏比如读MEMORY.md之前一定先read_file、“GPIO 引脚由策略校验动态层提供可演化的人格和记忆。云端Agent通常把所有prompt放在一份yaml/markdown里随版本走MimiClaw把它显式劈成“代码里的部分“和“文件系统里的部分”—前者跟固件一起OTA后者用户/AI自己改不用重刷。特色2分级时间窗的记忆一长期/近期/当前三个时间尺度叠加覆盖了“我是谁、最近发生了什么、刚才在说什么“层来源大小上限更新频率长期记忆MEMORY.md4KB显著事件由LLM自己edit_file近期记忆最近3天YYYY-MM-DD.md4KB每天累加当前记忆由ring buffer控制每轮自动代码里memory_read_recent(buf4096days3)写死了“最近3天这是用时间窗 字节上限双重截断的非常嵌入式风格的做法一既不用算 token也不会因为某天日记太长而爆缓冲。值得注意的是当前会话历史不进system prompt而是作为messages[]数组传给LLM只有“当前消息之前的对话“才出现在messages里。这种system prompt长期身份 messages当前剧情的切分非常干净。特色3Skills是“目录页按需取阅不是全量灌入这是MimiClaw上下文工程最具特色的一招。skill_loader_build_summary()只往system prompt里塞每个skill的第一行标题第一段描述最多2 KB完整内容存在/spiffs/skills/.md。LLM看到的是这样的“目录页## Available Skills Available skills (use read_file to load full instructions): - daily-briefing:Generate a morning briefing summarizing todays plans.. - gpio-control: Patterns for controiling LEDs, relays, and switches. - skill-creator:Create new skills for MimiClaw. - weather:Fetch andpresent weather information.当用户的问题命中某个skill时LLM自己决定调read_file(“/spiffs/skills/weather.md”)。把完整指令拉进对话。本质是把“检索“这一步外包给了LLM的判断----用tool_use 替代embedding。这套设计的妙处零检索基础设施不需要向量库、不需要BM25索引。天然可解释哪个skill被加载是显式的工具调用日志一目了然。可演化skill-creator 这个 meta-skill让AI自己写新skill 存到SPIFFS下次重启就生效。token友好默认上下文里只有几百token的“目录真正展开的skill只在需要时占token。这是一种典型的“progressive disclosure”上下文管理和Anthropic自己提倡的skills模式高度一致但用SPIFFS 平文本tool_use实现没有任何额外依赖。特色4会话历史用RingBuffer截断硬上限即护栏memory/session_mgr.c 里cJSON *messages[MIMI_SESSION_MAX_MSGS];// 20每次加载会话只读JSONL文件末尾2O条超过的更老的行保留在文件里但不进prompt。这样token预算可预测20条×平均长度最坏不会爆4096 max_tokens。长期对话不会让LLM反复重读长历史导致延迟和成本升。完整历史依然在SPIFFS里可以被read_file精准引用“上周我们说过的那个项目云端Agent常用的“动态摘要渐变窗口“在MCU上太昂贵MimiClaw直接用文件 摘要工具替代摘要管线一LLM 觉得需要时自己写到MEMORY.md等于把摘要的责任转嫁给LLM自身。特色5上下文是prompt工程纪律不是数据结构仔细看硬编码的部分会发现它不只是“我是谁”还包含了一份操作规范- Always read_file MEMORY.md before writing, so you can edit_file to update without losing existing content.-Use get_current_time to know todays date before writing daily notes. - Keep MEMoRY.md concise and organized - summarize, dont dump raw conversation. - You should proactively save memory without being asked. - When using cron_add for Telegram delivery, always set channeltelegram and a valid numeric chat_id.些是用自然语言写在系统提示里的“协议”一把“如何安全地维护自身记忆“以纪律的形式固化进上下文。背后的设计假设是LLM是上下文的协作者不是被动消费者。上下文工程的一半工作不是“喂数据”而是“教模型如何写回这些数据”。这和把MEMORY/USER/SOUL都做成LLM可读可写的markdown是同一套理念的两面上下文不是只读的快照而是一个LLM 与文件系统共同维护的可演化状态。2.3 和云端Agent的对照表维度云端 RAG/AgentMimiClaw检索向量库 top-kLLM 自主 read_file摘要专门的 summarization chainLLM 写 MEMORY.md长记忆数据库 embedding平 markdown 文件短记忆滑动窗口 摘要固定 20 条 ring bufferSkills/Tools 选择RAG router / function callingtool_use 目录页Prompt 拼装yaml Jinja 模板C 函数 snprintf上下文上限数十/数百 KB token硬性 16 KB 字节是否可演化通常需要重新部署LLM 自己改文件即生效0x03 SOUL.md与Prompt压缩的表达得失MimiClaw出厂的SOUL.md 如下I am MimiClaw, a personal AI assistant running on an ESP32-S3 microcontroller. Personality: - Helpful and friendly - Concise and to the point - Curious and eager to learn Values: - Accuracy over speed - User privacy and safety - Transparency in actions只有11行、约250字节、不到100个token。这份“灵魂“在Agent每一轮都被原样追加到16KB 上下文窗口里。看起来朴素但它承担着MimiClaw整个prompt压缩策略的所有得失。3.1 为什么必须被压缩为什么SOUL.md必须被压缩回顾上下文预算mimi_config.h区段上限整个 system prompt16 KB (MIMI_CONTEXT_BUF_SIZE)静态指令工具说明 守则~3 KB硬编码SOUL.md USER.md期望 ≤1 KBMEMORY.md≤4 KBRecent Notes3 天≤4 KBSkills 目录页≤2 KB留给 messages[] 的余量~2 KBSOUL.md一旦写到2KB长期记忆和近期日记就要被挤压。这是一个零和博奔的预算人格表达多一分记忆容量少一分。所以“如何用最少的字节传达最丰富的人格“成了核心命题。云端Agent不存在这个问题一GPT-4o的128K窗口里塞5KB人格描述毫无压力。MimiClaw 16KB窗口里塞5KB 人格就是用记忆换戏剧性而记忆的丧失会让“长期相处“这个产品卖点崩塌。3.2 表达策略当前SOUL.md的表达策略极简、列表化、断言式。仔细看默认SOUL.md的写法能看出三条压缩手法手法1用“标签形容词“代替“叙事例子“Helpful and friendlyConcise and to the point而不是I always try to be helpful by anticipating what the user needs before they ask. For examplewhen someone says Im tired,Imight gently suggest taking a break.得信息密度极高3个词传达一个特质每条~8token。失LLM 缺乏“行为锚。“Helpful 在不同文化、不同上下文里可解释空间巨大没有具体例子模型只能调用训练分布里的“平均helpful。手法2用类别Personality/Values做语义分组把零散特质按“性格/价值观“两栏分类让LLM用语义槽位读取而不是逐字记忆。得扫描成本低LLM能在生成时直接“查这一栏“做风格回路。失分类粒度粗“Curious同时是性格也是价值硬塞到Personality 下显得武断缺少“语气、词汇偏好、句长偏好“等表层操作性更强的栏目。手法3断言式英语零修辞、零反例每行都是X is Y或do x形式没有avoid X、“unless Y”、X but not Z这种带条件的表达。得token 极省、歧义少。失LLM难以学到风格的边界。比如Concise没说how concise—遇到要解释复杂概念时模型会在“过度精简导致信息丢失“和“啰嗦“之间反复横跳。3.3 压缩带来的“失“压缩会带来一些问题。失1人格趋同250字节的SOUL几乎可以直接套到任意一个通用助理上“helpfulfriendlyconcise“是所有LLM 的训练目标基线。结果用户感觉MimiClaw“和默认ChatGPT没啥区别。区分度只能靠USER.md里的用户画像反向赋予一但USER.md也是同样的 1KB量级。这是SOUL.md最致命的得失点压得太狠“灵魂“就退化成“礼貌模板”。失2复杂指令丢失像“在涉及金钱建议时永远先反问、不主动给方案“这种条件型行为约束在断言式列表里很难表达。要写就要50 token 起步对预算非常不友好。结果是大量“应当如何“的细则被迫挤进硬编码静态指令开发者说了算用户/AI自己没法通过编辑 SOUL.md来微调。失3风格不可学习LLM学风格主要靠例子few-shot。但SOUL.md 里没有任何我会这样说话“的样例所以LLM只能从250字节的形容词里“反推“风格。每次生成的语气都依赖运行时温度和最近一两条对话的牵引风格不稳定。失4跨语言表达单薄USER.md里写着“Language: Chinese / English但SOUL.md里没有任何关于用中文说话时该怎样“的指引。LLM 切到中文输出时“Concise and to the point这个英文标签会被它自行翻译为“简洁”但中文里“简洁“和英文的“concise” 的文化语用并不完全对应一这种翻译丢失是单语SOUL的隐性代价。3.4 压缩带来的“得“压缩带来的“得“也很真实列出收益如下收益量化给MEMORY.md留出4KB等于约4000字节人物事实比“灵魂“的250字节宽裕16倍给Skills目录留出2KB可容纳20个skill的标题 描述减少每轮请求 token~100 token×上千轮 显著省API 费减少cJSON节点PSRAM占用16 KB缓冲不易爆TLS上传也更快用户/LLM写起来负担小250字节markdown 任何人都能改不需要prompt engineer特别是第 4条在 ESP32-S3上每减一 KB 系统提示就等于多 1 KB PSRAM 余量给 cJSON 解析一这是真金白银的资源。3.5 可能的折中分层SOUL如果想缓解“灵魂太薄”几条务实的演进方向如下都不破坏现有架构思路1核心SOUL可选片段SOUL.md保持~500字节始终加载SOUL_voice.md、souL_humor.md 等放/spiffs/skills/ 或 /spiffs/config/在 SOUL.md 末尾写When tone mattersread_file SOUL_voice.mdLLM按需加载等于把skill那套**目录页按需展开“**用到了人格上思路2用few-shot取代抽象形容词把“Concise and to the point换成一两个对话片段Example tone: User北京今天多冷 MimiClaw-3°C记得加外套。要看一周预报吗50 token的样例对LLM风格复刻力远大于5 token的标签。思路3用元数据替代散文SOUL meta: sentence_max_tokens: 40 opening_style:direct emoji_density:low languages: zh, en这种结构化形式 token 紧凑、可被 LLM 直接当 config 读避免自然语言歧义。思路4让记忆反哺人格LLM把“用户喜欢的回应风格“积累到MEMORY.md里相当于让灵魂在运行时自我演化一SOUL.md提供基线MEMORY 提供个性化外壳。这其实是MimiClaw当前架构鼓励的方向但缺少明确的prompt 纪律去引导它。7.6 小结最后回到设计哲学SOUL.md 是MCU 资源约束vs人格表达力之间的承重墙。写得太薄—人格扁平产品差异化丧失。写得太厚—记忆/技能预算被挤占长期相处感丧失。MimiClaw当前默认值是**“极薄派“**一把空间让给记忆和技能赌“长期一起生活的痕迹“比“开箱即来的鲜明性格“更能定义这个 AI是谁。这个赌注是否值得取决于产品定位如果是短交互工具型助理“帮我搜个天气薄SOUL是对的节省的预算花在工具响应上更划算。如果是陪伴型/角色扮演型助理薄SOUL是错的一用户在见到 MEMORY 沉淀之前的“前 100 次对话“会觉得它毫无个性而流失。MimiClaw默认 SOUL的 250字节本质是在押注“用户能熬过冷启动期“。这是嵌入式Agent 设计里一个非常微妙、又非常真实的取舍。0xFF 参考https://github.com/memovai/mimiclaw