MimicLaw vs OpenClaw
一个 $5 的嵌入式 Agent 和完整框架相比如何？
功能对照
相同之处
差异之处
MimicLaw 缺失的功能
尚未实现（来自 TODO.md）：
受硬件限制而省略的功能：
- 本地 LLM 推理（RAM 不够）
- 音频输入输出（参考开发板无麦克风/扬声器）
- 视觉/摄像头
- 完整 POSIX 文件系统（SPIFFS 是平面的，无真正目录）
设计取舍分析
非流式 API 响应
MimicLaw 使用 Claude API 的非流式 JSON 响应，而非 SSE 流式传输。
为什么： 解析更简单（单个 JSON 对象），内存开销更低（无流式状态机），错误处理更容易。
代价： 用户在完整响应到达之前看不到任何输出。对于长回复，有明显的等待感。
JSONL 而非 SQLite
会话历史使用 JSONL（每行一个 JSON 对象）而非数据库。
为什么： 人类可读，不需要 SQLite 移植（节省 ~500 KB Flash），追加写入对 Flash 友好。
代价： 无索引，加载历史需要扫描整个文件。通过环形缓冲区缓解（只加载最近 20 条消息）。
直接调用 Anthropic API 而非 LiteLLM
MimicLaw 通过 esp_http_client 直接调用 Anthropic Messages API。
为什么： LiteLLM 需要 Python/Node.js 运行时。直接调用完全消除了这个依赖。
代价： 锁定在 Anthropic。切换到 OpenAI 或 Gemini 需要修改请求/响应格式的代码。
HTTP CONNECT 代理而非 SOCKS5
代理支持使用 HTTP CONNECT 隧道。
为什么： 协议更简单（基于 HTTP），被常用代理工具广泛支持（Clash Verge、V2Ray、Squid）。
代价： 不兼容仅支持 SOCKS5 的代理。
双核任务分离
Core 0 处理所有 I/O（Telegram、WebSocket、串口）。Core 1 专门运行 Agent 循环。
为什么： 防止网络 I/O 延迟阻塞 Agent 处理。Agent 可以在后台 Telegram 轮询的同时执行完整的 ReAct 迭代。
代价： 任务协调略复杂（队列而非直接调用）。
20 条消息的会话环形缓冲区
每个对话只将最近 20 条消息加载到 LLM 上下文中。
为什么： 限制内存增长。20 条消息约 200 token/条 ≈ 4,000 token，完全在 Claude 上下文窗口内。
代价： 长对话会丢失早期上下文。重要信息应由 Agent 保存到 MEMORY.md。
架构映射
MimicLaw 模块与 OpenClaw 模块的对应关系：