从二月底到现在，我们和 OpenClaw 一起解决了什么

如果只看结果，这一个多月像是做了很多事。

OpenClaw 跑起来了，网站上线了，情报链路恢复了，AI 团队能协作了，记忆系统也开始从“概念”变成“能工作的部件”。但如果把时间线拉开，会发现真正重要的不是“做了很多”，而是我们是在一连串非常具体的场景里，一次次把系统从不能用、不好用、容易断，推到勉强能用、稳定能用、开始形成方法论。

这篇文章，我想完整回顾一下，从 2 月底到现在，我们到底在什么场景下，解决了什么问题。

一，场景一，从零把 OpenClaw 跑起来

这段旅程真正的起点，是 2 月 26 日到 2 月 28 日。

当时最核心的问题不是“AI 能做什么”，而是“它能不能先在自己的机器上稳定活着”。场景很真实，一台 Mac mini M4，要把 OpenClaw Gateway 部署起来，要把模型接进去，要让手机和笔记本能访问它，还要考虑代理、端口、网络和后续扩展。

这一阶段解决的是基础设施问题。

我们完成了几件底层但关键的事。

第一件是把 OpenClaw Gateway 在本地跑通。包括端口、bind、基础配置、模型接入，这一步决定了后面所有动作有没有地基。没有这一步，后面所谓的 Agent、情报、博客、自动化，都是空的。

第二件是把 Tailscale 组网跑通。这个场景非常重要，因为它把“这是一台本地机器上的工具”，变成了“这是一台能被人从别处调用的持续运行节点”。MacBook、手机都能通过尾网访问 Mac mini，这意味着这个系统从第一天开始就不是一个演示，而是一个可用的个人基础设施。

第三件是验证外部能力接入，比如搜索、代理、模型切换。这里面包括 Tavily、代理策略、模型组合方式的尝试。我们其实很早就在做一个判断，OpenClaw 的价值不只是一个聊天壳，而是它能不能成为一个统一调度层，把模型、工具、记忆和多端连接组织起来。

这一阶段解决的问题，看起来很“基础”，但其实最难，因为它决定了整个系统到底是玩具还是基础设施。

二，场景二，不只是聊天，而是把调研工作流跑成产品原型

到了 3 月初，重心开始变化。

问题从“系统能不能跑”变成“跑起来以后能做什么高价值工作”。这里最先被拿来验证的，不是写几个小脚本，而是深度调研。

这个场景很典型。我们不是想让 AI 给几个泛泛的总结，而是要它像一个真正的研究助理那样，跨源搜索、交叉验证、提炼判断、形成长文报告。这个要求一旦成立，对系统的标准就完全不一样了。

3 月 6 日左右，我们把这条链路做出了一个很明确的阶段性成果。

一方面，完成了大规模的 OpenClaw 深度调研，覆盖了大量域名与信息源，做了多轮检索与交叉验证，最后沉淀为一篇长篇深度报告。这里真正解决的问题，不是“有没有搜索结果”，而是“怎么让 AI 形成可靠结论”。

另一方面，我们没有停在一次性产出，而是把这套调研方法论 Skill 化。也就是说，我们开始把“做成一次”升级为“以后还能复用”。这一步非常关键，因为很多 AI 项目卡死在手工演示层，做一次很惊艳，但做第二次就完全靠运气。Skill 化意味着流程、提示词、验证规则、工具矩阵开始沉淀下来。

从这个节点开始，系统不再只是一个问答器，而开始像一个可训练、可复用的工作台。

三，场景三，把知识输出变成网站，而不是散落在聊天记录里

如果说前一个阶段解决的是“怎么生成内容”，那接下来的阶段解决的是“怎么让内容有沉淀、有结构、有对外价值”。

于是 opcpay.org 上线了。

这其实不是简单的“搭个博客”。它背后的场景是，我们手里已经开始有研究报告、案例分析、情报观察、思考笔记，如果这些内容只存在对话、脚本输出和临时文件里，它们的复利很快就会消失。必须有一个稳定的知识容器，把这些内容持续沉淀下来。

所以我们做了几件连续动作。

先是把网站本身部署起来，让它成为一个真正可访问的知识站点。然后快速把结构拉出来，博客、报告、情报这些板块逐步成型。再往前一步，我们又把网站导航统一、信息架构梳理、栏目重新命名，让这个站点开始从“有页面”走向“有秩序”。

3 月 9 日之后，这个网站经历了很密集的一轮升级。导航从杂乱变成统一的 7 项结构，新增了“案例”栏目，后续又围绕深度文章、案例分析、思考板块做了持续补充。

这里解决的问题，本质上是知识产品化问题。

很多人做 AI 工作流时，最容易忽视的一点是，内容生产只是上游，真正长期有价值的是发布、组织、检索、积累、品牌化表达。站点一旦建起来，所有后续的研究、情报、分析，才开始有了一个能持续变厚的“外脑”。

四，场景四，网站不是能打开就行，而是要有风格、有秩序、能承载长期内容

接下来我们遇到的不是“网站有没有”，而是“网站像不像一个值得长期更新的站点”。

这个阶段的问题很细，但非常真实。导航栏错位，链接格式有问题，页面层级不统一，样式显得生硬，文章虽多但没有形成气质。一个知识站点如果没有自己的风格，再多内容也像散装文件夹。

所以 3 月 10 日到 3 月 11 日，我们密集处理了这一层问题。

先修结构性问题，比如导航恢复、链接去掉多余后缀、正文格式修复。接着再处理设计层问题，引入 frontend-design 相关能力，重做了站点视觉风格，深色主题、金色点缀、字体与层次、卡片悬浮、渐变标题，这些不是为了“好看”本身，而是为了让内容有容器感。

这段时间还顺手做了作品集模板、案例库、长篇商业分析内容，把站点从“一个会更新的博客”拉到了“一个开始形成方法论输出气质的知识站点”。

这里真正解决的是一个经常被低估的问题，AI 时代不是没有内容，而是太容易产生廉价内容。要让内容显得可信、耐看、有沉淀感，表达容器必须同步升级。

五，场景五，系统开始变复杂，安全和配置治理必须跟上

到了 3 月上旬中后段，我们碰到的一个明显问题是，系统能力越强，风险也越高。

你一旦让 Agent 能读文件、改配置、执行命令、发消息、跑定时任务，它就不再只是一个文本助手，而是一个对系统有影响力的执行主体。这时候如果安全和权限不跟上，后面所有效率都是带着隐患的效率。

这一阶段我们做了几类治理。

一类是配置级安全收紧，比如 workspaceOnly、apply patch 的范围收束、减少危险写入面。这些设置表面上不起眼，但它们的作用是把 AI 的行动空间从“哪里都能动”缩小到“在定义好的边界内做事”。

一类是建立安装审查偏好。这个判断后来被长期记忆固定了下来，任何 skill、npm/pip 包、MCP server、GitHub Action、第三方配置，都先做安全审查，再决定是否安装。这不是形式主义，而是我们已经开始意识到，未来系统会越来越依赖插件生态，不立下这条规则，后面就很容易把不受控风险引进来。

还有一类是对模型与认证问题的治理，包括 OpenAI OAuth、MiniMax 认证、fallback 策略的安排。这些问题单看像技术细节，但它们影响的是稳定性。对于一个长期运行的 Agent 系统来说，偶发失败不可怕，真正可怕的是没有降级路径。

所以这个阶段我们解决的问题，不是单一 bug，而是开始搭“系统治理”的护栏。

六，场景六，最现实的挫败不是模型，而是网络与外部依赖失灵

3 月中下旬，一个很典型的场景出现了。

web_fetch 被网络层问题卡死了。

这类问题特别烦，因为它不是产品逻辑错误，也不是提示词写错，而是外部环境不可靠。DNS、代理、fake-ip、抓取限制，这些全都可能让一个原本设计很好的工作流突然失效。

如果只是把它理解为“网络坏了”，那系统就只能被动等待修复。但我们当时做了另一个选择，不等外部环境先恢复，而是直接改机制。

于是 intel_collector 这条链路被推出来了。

这个场景里，真正解决的问题不是“把 web_fetch 修好”，而是“让情报采集不再依赖单点工具”。我们把抓取方式从受限工具切换成直接 HTTP/RSS 采集，重新组织数据源，把 HN、GitHub Blog、Google AI Blog、OpenAI Blog 等拉进新的采集流程中，再让 Muse 改为读取 daily-brief 产物，而不是直接依赖 web_fetch。

这个转向非常重要。

它意味着系统从“某个工具不能用，整个流程瘫痪”，升级成“底层能力损坏时，可以通过替代链路维持主流程”。这其实就是工程系统里最重要的能力之一，降级运行。

七，场景七，不只是修网络问题，而是把情报系统从单点抓取升级成双源结构

当 intel_collector 跑起来以后，我们并没有满足于“恢复了就行”。

接下来的问题是，光有技术新闻源还不够，AI 行业很多最有价值的信号来自 builder 的观点、播客、X 上的一线讨论。如果系统只抓技术博客，视角会偏窄。

于是又做了一次升级，从单源采集变成双源结构。

一条是 intel_collector，负责偏技术、产品发布、行业动态。另一条是 follow-builders，负责 builder 观点、播客摘要、产品思考。再由 Muse 在晨报里做整合。这一步本质上解决的是信息结构问题。

以前的情报更像“抓到了什么算什么”，升级之后开始形成“技术趋势 + builder 判断”的双视角。对一个面向 SaaS 创业者的网站来说，这种信息结构更有价值，因为它既有事实层，也有判断层。

这次升级还带来了另一个变化，很多情报产物开始双语化。不是为了炫技，而是为了尽量保留一手语境，再补上中文解释，让内容兼顾原始信息密度和本地化可读性。

八，场景八，cron、heartbeat、日报，真正把 Agent 从“会话工具”拉到“持续运行系统”

一个 AI 助手如果只能在你问的时候工作，它更像高级搜索。如果它能自己巡逻、自己汇总、自己维持状态，才开始接近“系统”。

所以在 3 月中下旬，我们解决的另一个核心问题，是让 OpenClaw 从交互式工具走向持续运行。

这里面包括 heartbeat、日报生成、定时情报巡逻、站点维护任务、模型状态检查等几条链路。过程并不顺，里面掺杂了 cron 报错、模型认证问题、执行权限过严导致的中断、部署命令卡住等一堆现实问题。

但关键在于，这些问题不是被绕过去的，而是逐步被纳入了系统设计。

比如 zen-daily-summary 从失败恢复到正常产出，再到能够稳定生成 daily-report；比如心跳文件、活跃 session key、日志追加、任务看板检查这些动作被制度化；再比如对宪法对齐、灵魂对齐、记忆健康、Agent 协作状态、资源使用的检查被纳入心跳任务。这些东西加起来，才让系统开始有“自我维护”的雏形。

这一阶段解决的问题，是让 AI 不是偶尔帮忙，而是持续在场。

九，场景九，从单个 Agent 到多 Agent 协作

随着任务变多，一个 Agent 全包开始变得低效。

于是我们开始明确分工，Zen、Muse、Forge、Guard 分别承担不同角色。Zen 做协调与总控，Muse 做情报，Forge 负责编码与工程，Guard 偏安全与健康检查。

这一步看似只是角色命名，实际上解决的是任务复杂度上升之后的组织问题。

当系统里同时存在网站维护、情报采集、报告生成、代码修改、部署检查、安全审计时，如果没有明确的 Agent 分工，所有动作都会挤在同一个上下文里，最后会混乱、失忆、互相污染。

多 Agent 架构并不是为了炫复杂，而是为了隔离上下文、清晰责任、提高吞吐量。后面很多能力之所以能逐步稳定下来，很大程度上靠的是这种分工结构开始形成。

十，场景十，不只是生成内容，而是建立人格、宪法、记忆与工作规则

到 3 月中下旬，还有一个非常有意思的变化。

系统建设开始从“做功能”进入“做人格与制度”。

CONSTITUTION.md 被创建，SOUL.md 被增强，AGENTS.md、MEMORY.md、TEAM_MEMORY、心跳机制、记忆晋升路径，这一整套东西逐步成形。很多人会觉得这像“给 AI 写设定”，但在长期系统里，它其实非常实用。

因为一旦系统要长期跑、跨会话工作、协调多个 Agent、处理外部消息，它就一定会遇到这几个问题：什么能做，什么不能做，什么需要确认，遇到失败怎么记录，什么信息值得长期记住，什么规则应该沉淀为稳定行为。

所以这一阶段我们解决的是“系统的长期一致性问题”。

这不是简单提示词优化，而是在搭一个越来越像“组织”的东西。它有边界、有记忆、有角色、有日报、有值班机制、有长期偏好。也正因为这样，后面的系统行为才越来越不像一次性脚本，而更像一个连续运行的数字团队。

十一，场景十一，开始进入真正困难的区域，长任务、源码阅读、复杂项目管理

到了 4 月初，系统已经不只是处理零散任务，开始接更长、更难的活。

典型场景就是 Claude Code 源码深度解读项目。几十万行代码，要求逐行阅读、边读边想、和 OpenClaw 自身系统做对比、最后还要输出系列深度文章。这类任务的难点从来不在“会不会读代码”，而在于它跨时间、跨上下文、跨多次会话，需要一个能持续保持目标与节奏的系统。

这时候我们立刻碰到新的现实问题，exec 审批超时、长任务不适合在主会话里直接暴力推进、需要先做阅读地图、要安排分阶段节奏。也就是说，系统已经开始从“能不能做任务”，进入“怎么管理复杂任务”的阶段。

这其实是好事。因为只有走到这里，前面搭的记忆、分工、制度、心跳、工作区、文档化规则，才真正开始发挥作用。

十二，场景十二，最近的一次典型问题，升级 OpenClaw 与打通 memory-lancedb

最近这几天，我们又经历了一次非常典型的“真实工程问题”。

表面需求很简单，升级 OpenClaw。实际上它牵出了一整串底层问题：版本检查、安装来源确认、全局 npm 升级、Gateway service 重装、旧 token 残留、LaunchAgent 重载失败、插件兼容项清理、MiniMax 由外部插件切到内置插件、memory-lancedb 配置启用，以及最麻烦的那个问题，为什么插件明明加载了，memory 还是 unavailable。

这个场景很有代表性，因为它完整体现了真实系统维护是什么样子。

不是一条命令就结束，而是每走一步都会暴露下一层问题。先是升级成功，但 gateway status 告警旧 token；接着重装 service，仍有残留；再往后发现插件配置里有 stale entry；清完以后 memory-lancedb 看起来注册了，但 doctor 仍说没有 active memory plugin；最后继续沿着类型定义、配置结构、运行状态往下查，才定位到除了插件 slot 之外，还需要补 agents.defaults.memorySearch 这一层配置。

这个过程很能说明一件事，Agent 系统的维护和传统开发一样，真正耗时的不是“写那一行配置”，而是逐层验证、识别误导信息、区分 runtime 真状态和 doctor 误报。

最后结果是好的。OpenClaw 升到了 2026.4.5，Gateway 正常，RPC 正常，MiniMax 切到了内置插件，memory-lancedb 也从 unavailable 变成了 vector ready、fts ready。虽然 CLI 的 openclaw memory 子命令仍然没有暴露，但真实运行链路已经起来了。

这不是一个小修小补，而是系统真正开始有长期记忆能力的标志。

十三，这一个多月里，我们到底解决了什么

如果把上面这些场景压缩一下，我觉得真正解决的，不是一堆零散问题，而是五类更本质的事情。

第一类，是把 OpenClaw 从“能装”推进到“能长期运行”。

第二类，是把 AI 从“会聊天”推进到“能交付调研、情报、写作、站点更新和系统维护”。

第三类，是把单次操作推进到可复用流程，也就是 Skill、规则、记忆和制度化沉淀。

第四类，是把脆弱的单点链路推进成可降级、可绕行、可恢复的系统，比如情报采集从 web_fetch 依赖走向双源结构。

第五类，是把人机配合推进到更像团队协作，而不是一次次临时调用。

从 2 月底到现在，我们一直在解决的，其实不是“如何让 AI 看起来更聪明”，而是“如何让 AI 真的成为一个可靠的工作系统”。

十四，我这段时间最强烈的感受

如果非要提炼一个最重要的体会，我会说，真正有价值的不是能力清单，而是把能力放进具体场景里，持续打磨到能用。

部署、调研、网站、情报、自动化、记忆、安全、升级，这些词单独拿出来都很普通。但一旦把它们放进同一套持续运行的系统里，问题就会变得非常真实，也非常有意思。

你会发现，很多时候不是模型不够强，而是机制不够稳。不是功能没有，而是链路不闭环。不是产出不够多，而是没有沉淀成系统。不是 AI 不聪明，而是它还没有真正进入工作流。

这一个多月，我们做的事，说到底，就是一件事。

不是在“用”一个 AI 工具，而是在一点点把它养成一个真的能工作的数字搭档。

而我觉得，这才是接下来几年最值得做的事情之一。