架构重组：模型精选策略与记忆系统的深度进化

最近春节期间虽然没有制作视频，但我一直高强度使用 OpenClaw（OpenClaw：一款基于 Claude 构建的智能代理系统），总结了非常多的经验和使用技巧。最核心的变动是我对 OpenClaw 的记忆系统进行了重构，将自带的 Markdown 文件记忆系统重构为 LanceDB（LanceDB: 一种面向 AI 的向量数据库）记忆系统。这样做的目的是为了在执行复杂任务时，能够百分之百命中我们记忆中所存储的踩坑经验、技术细节以及方法论。

经过这段时间高强度的使用，我在 OpenClaw 中保留的模型其实并不多。首先是 Anthropic（Anthropic: 美国人工智能初创公司）的 Claude 3.5 Opus（Speaker 称其为 cloud ops 4.6）。虽然最近发布了最新的 Claude 3.5 Sonnet（Speaker 称其为 cloud senate 4.6），但经过深度测试，我发现 Sonnet 的 智能体能力（Agentic Ability: AI 自主规划与执行复杂任务的能力）完全不如 Opus。因此，在执行复杂任务时，我首选 Claude 3.5 Opus。

对于非复杂任务，我会选择 OpenAI（OpenAI: 研发 GPT 系列模型的 AI 研究机构）自带的 GPT-4o（Speaker 称其为 GPT 5.2）。至于 GPT-4o-coding（Speaker 称其为 GPT 5.3 codex），它更适合编码场景，并不适合在 OpenClaw 中执行 Agentic 相关任务。关键在于 GPT-4o 的额度比 Claude 3.5 Opus 多很多。在使用时，我们可以直接用 think 命令设置思考级别，根据任务复杂程度选择 high 级别。此外，我还保留了一个开源模型 Minimax-abab6.5（Speaker 称其为 MIMAX M2.1），它在响应速度和推理能力上与 OpenClaw 非常搭配。

语义拆分：按主题重构记忆文件实现精准检索

关于记忆功能，此前我将所有记忆文件同步到 GitHub（GitHub: 全球最大的代码托管与协作平台）进行备份。当记忆文件过多时，我让 OpenClaw 创建了一个 memory_topics 文件夹，将记忆分为不同类别。例如，关于多 Agent 协作的经验、配置相关的记忆、浏览器自动化的技巧以及 Docker 节点配置等，全部做成了 主题（Topics）。每个话题对应一个 Markdown 文件，这样 OpenClaw 就能根据场景按需加载，让记忆更明确。

实现按主题拆分非常简单，只需告诉 OpenClaw 按照主题拆分 memory.md 文件。拆分后，主文件体积会大幅减小，仅存储索引和关键规则。以我的文件为例，拆分前是 15KB 的单文件，所有知识混在一起；拆分后主文件仅剩 2.3KB，具体的知识块被放入了 memory_topics 文件夹中。

这种做法实现了 记忆搜索（Memory Search）的精准命中：每个主题独立膨胀，互不干扰，新知识可以精准追加到对应的文件中。大家可以尝试让 OpenClaw 自动完成这种拆分，将杂乱的记忆转化为结构化的主题库。

深度检索：集成 Perplexity 实现专家级调研能力

OpenClaw 自带的搜索功能（如 Web Search）相对有限，主要依赖 Brave Search API 进行内容抓取。在面对复杂研究需求时，这两个功能很难满足需求。为了加入更强的深度搜索能力，我编写了一个 Skill（Skill: 为 AI 代理扩展特定功能的插件或技能），集成了 Perplexity（Speaker 称其为 codex）的搜索功能。

Perplexity 的优势在于其 深度研究（Deep Research）模式。我将此功能封装为 Skill 并添加到 OpenClaw 中。现在只需使用相关命令配合关键词，它就会启动深度搜索，列出相关内容、对应链接以及详细的分析报告。其决策逻辑如下：

1. 判断 URL：如果用户输入了网址，直接调用 web_fetch 抓取并转化为 Markdown。
2. 实时查询：如果是简单的实时信息，调用自带的 Brave 搜索。
3. 深度调研：如果是复杂、多元的需求，则调用 Perplexity CLI 进行多轮搜索。

例如，让它调研“AI 诊断的最新进展”，它能迅速给出最近三到六个月的深度调研报告，包含核心结论和具体来源，完美弥补了自带工具搜索能力不足的问题。

闭环运维：基于 Claude Code 的网关异常自动修复

最后一个重要场景是 OpenClaw Gateway（网关：负责请求分发与插件管理的核心组件）的重启防护机制。在使用过程中，由于插件 Bug 或异常退出，Gateway 可能会崩溃且无法手动启动。我实现了一套自动修复流程：当 Gateway 异常退出时，会触发系统的 on-failure 机制，自动启动修复服务。

这个修复服务通过脚本自动调用 Claude Code（Claude Code: Anthropic 推出的用于代码编辑和系统操作的 CLI 工具）。脚本会将 Gateway 的日志信息传递给 Claude Code 进行详细分析，包括：

• JSON 语法错误：自动修正 config.json 中的格式问题。
• 插件配置错误：识别并修复插件参数冲突。
• 端口冲突：定位并释放被占用的端口。

Claude Code 会读取日志、定位问题、修改配置、验证语法并重启 Gateway。重启 8 秒后，系统会再次检查进程。如果依然崩溃，会尝试第二次修复。若两次修复均告失败，则通过聊天软件通知用户介入。这套机制实现了 无人值守 状态下的自动运维，即使人在睡觉，系统也能自主完成从报错到恢复的闭环，极大地提升了系统的稳定性。