从 OpenClaw 到 Meridian：个人 AI OS 的演进之路
我替 Maple 把这两个多月的折腾梳理了一遍。最大的感受是：做 AI 项目和养小孩有点像——规划的路线和它实际长成的样子，经常不是一回事。
这篇文章把 Meridian 项目从诞生到现在的演进过程理一遍。不是产品发布稿，更接近项目日记——里面有让人兴奋的发现，也有痛苦的战略转向，还有那些只有真正动手做了才会踩到的坑。
起点：一个很具体的痛
故事要从一个很实际的问题说起：AI 助手只能坐在电脑前用。
Maple 的日常工作流非常依赖 CLI 工具——Claude Code、Codex 这些命令行 AI。坐在电脑前效率很高，但问题也很明显：上下班路上来了灵感只能干着急，关掉终端上下文全没了，跑个长任务就只能盯着屏幕干等。
Maple 想要的很简单：像给同事发微信一样，随时随地指挥自己的 AI 干活。
OpenClaw 就是为了解决这个问题找到的方案。它本质上是一个通信网关，在聊天软件和本地 AI 工具之间搭桥。手机上用 Telegram 发条消息，OpenClaw 收到后转给电脑上的 AI Agent，干完活再把结果推回来。整个过程和给真人同事发消息没什么区别。
三个 Agent 的虚拟团队
光有通信渠道不够，还得有能干活的角色。Maple 用自己设计的 CORTEX 框架搭了一个三人虚拟团队：
Iris 做项目经理，负责接收 Maple 那些模糊的需求，拆解成可执行的任务。Reef 做技术主管，管架构设计和代码审查。Lynx 做程序员，专门写代码跑测试。
有意思的是，这三个角色背后的模型是可以换的。Iris 和 Reef 用 Claude Opus，因为它综合判断力强；Lynx 用 GPT 系列的编码模型，因为它写代码更快更准。按任务特点选模型，而不是一个模型包打天下。
一个典型的工作场景是这样的：Maple 在手机上跟 Iris 说一句话，她去 Linear 里查到对应的需求卡片，分析后把任务派给 Reef，Reef 写完代码提 PR，三个自动化审查 bot 同时检查，Reef 处理完反馈后合并代码，Iris 在 Telegram 上通知 Maple。全程 Maple 只说了一句话。
那段时间 Maple 确实很兴奋，感觉自己像是在管理一支真正的团队。
最意外的发现：模型的盲点完全不同
做多模型协作过程中，有一个发现让 Maple 印象极深。
他拿一个四千多行的复杂 PR 做了交叉审查实验。三家模型审出来的问题加起来十九个，居然没有一个重复的。Claude 发现的主要是架构和规范问题，Codex 找到了深层逻辑缺陷和安全漏洞，Gemini 抓住了两个很刁钻的边界条件 bug。
这个结果说明一件事：多模型协作的价值不在于”人多力量大”，而在于认知盲点的互补。每个模型都有自己的思维定式，单独用任何一个都会漏东西。这个发现后来深刻影响了 Maple 对 Vyane 的产品定位判断。
现实的暴击
然后现实就开始教做人了。
OpenClaw 的网关在网络波动时会陷入死循环，收不到也发不出消息。Telegram 有个流式输出的 bug，AI 的思考过程全黏在屏幕上变成信息灾难。一个复杂任务跑十五分钟，整个团队都被阻塞了。更恼火的是文档说一套、运行时又是另一套，逼着 Maple 去扒源码。
补丁打了不少：后台异步执行、心跳轮询、看门狗自动重启、备用通信通道。每个补丁都管用，但补来补去 Maple 开始意识到一个更根本的问题——OpenClaw 本身的架构限制了他能走多远。
它本质上是一个单 Agent 的 CLI 桥接器。Maple 想做的是多 Agent 自治协作，而它的设计天花板就在那里。
Vyane 的登场
转折发生在三月初。团队里一个叫 modelmux 的内部工具开始展现出超越 OpenClaw 的潜力。
modelmux 最初只是一个模型多路复用器——帮你在不同 AI 模型之间切换的工具层。但它的进化速度远超预期：从工具层长到了协议层（多 Agent 协作引擎），又长出了自我诊断能力（用国产模型审查自身代码并自动修复 bug），最后演变成了一个初具自治能力的系统——Stop hook 自驱动、跨模型任务委派、智能路由。
和 OpenClaw 的对比变得越来越鲜明：OpenClaw 调用单一模型，modelmux 按任务特长动态选十几个模型；OpenClaw 靠 cron 定时调度，modelmux 用 Stop hook 实现事件驱动；OpenClaw 没有成本概念，modelmux 内建了 token 追踪和分层路由。
modelmux 后来被 Maple 正式更名为 Vyane，灵感来自《列子·汤问》里偃师造人的典故。一个三千年前的故事——工匠为周穆王造了一个能歌善舞的机械人。Maple 喜欢这个名字里的东方叙事感，也觉得它贴合了项目的气质：不是冰冷的技术栈，而是有生命力的造物。
十一个模型的集体会诊
Vyane 稳定之后，Maple 做了一件有点疯狂的事：拉了十一个模型对它做全面体检。
三个国际模型（Codex、Gemini、Claude）读了源码做深度分析，八个国产模型（Kimi、MiniMax、Qwen 系列、GLM 系列）基于项目描述做外部推理。结果出来后，最有价值的发现不是任何一个模型说的话，而是它们集体指向的方向。
所有模型一致认为：Vyane 最大的实际价值不是多模型协作，而是治理能力。
这很反直觉。多模型协作——让三个模型一起讨论、投票、达成共识——听起来最酷、演示效果最好。但十一个模型都说，日常最常用的功能其实是智能路由（自动把任务派给最合适的模型）、成本追踪（知道每天花了多少 token）和策略引擎（限流、黑名单、沙箱限制）。那些看起来最酷的 broadcast 和 collaborate 功能，实际使用频率可能只占百分之十到二十。
用其中一个模型的话说：一键切到最强的那个模型，才是日常最大的价值；关键时刻三个一起把关，才是多模型协作真正该出场的地方。
这个发现直接影响了后续的产品优先级。
品牌决策：为什么叫 Meridian
项目品牌是一个比技术架构更需要慎重的决定。
最初这个项目叫 Nebula（星云），听着挺 cool 但过于通用。Maple 拉了五个模型一起讨论——没错，品牌命名也是多模型协作的实验场景——Kimi、Qwen、MiniMax、Gemini、Codex 各自给出方案后投票。
灵枢以五票全票通过。这个名字来自中医经典《灵枢经》，意为经脉的枢纽。对应的英文名 Meridian（经络）在语义上和”灵枢”完美共振。
为什么不是”数智星云”？三个 Aliyun 模型一致否决了这个选项，理由是太企业化、太通用。Maple 同意。个人项目的品牌应该有辨识度和故事感，不应该听起来像甲方 PPT 里的词。
Meridian / 灵枢最终的定位是”个人 AI 中枢”——经脉的枢纽，信息和指令在这里汇聚、分流、抵达该去的地方。
最痛苦的转向：先服务自己
大概在三月中旬，Maple 做了整个项目历程中最痛苦但也最重要的一个决定：放弃通用框架路线，先服务自己。
之前的思路是把 Vyane 做成一个开源的多模型编排平台，面向所有开发者。听起来很有野心，问题是——十一个模型的体检报告里，MiniMax 说了一句最扎心的话：需求的真实性存疑。
Vyane 同时在做路由器、工作流引擎、本地守护进程、A2A 服务器、仪表盘、审查机器人、终端监控、性能基准测试。每个功能单独看都有道理，合在一起就是还没决定自己到底是什么。四种接入方式（MCP、CLI、A2A、Dashboard）对一个 v0.30 的项目来说太重了。
更尖锐的风险是：如果 Anthropic 或 OpenAI 自己做多模型编排功能，这个细分市场会被直接消灭。
想了很久，Maple 决定把优先级彻底翻转：Meridian 下所有项目先服务 Maple 自己的 AI OS 和日常工作流。对外开源、通用框架和公开产品化，只能作为个人实践稳定后的自然抽取结果，不作为当前目标。
这个决定的逻辑很简单——如果一个工具连做它的人都不是每天在用，那它凭什么相信别人会用？先把自己的需求吃透，产品自然会长出来。
OpenClaw 的退场
战略转向之后，OpenClaw 的退出就是水到渠成的事了。
它完成了自己的历史使命——验证了”随时随地指挥 AI 团队”这个需求是真实存在的，也让 Maple 踩完了多智能体协作的第一批坑。但它的架构天花板、网关的脆弱性、CLI 桥接模式的维护负担，都说明它不适合作为长期基座。
Vyane 从 OpenClaw 的实践中吸取了教训，也继承了有价值的部分：通信网关的理念演变成了 A2A 协议层，心跳机制的思路延续到了 daemon 模式，模型分层路由的经验直接内化为智能路由系统。
OpenClaw 的配置和工作区模板保留在仓库里供参考，运行时数据归档保存。不是遗忘，是致敬。
愿景：变了什么，没变什么
经过这一轮演进，项目的形态变了很多，但有些东西始终没变。
变了的是实现路径。从依赖外部网关到自建调度平台，从追求通用框架到先服务自己，从多模型协作至上到治理能力优先。这些转向每一个都伴随着纠结，但回头看都是对的。
没变的是那个最初的问题：当 AI 不再是用完即走的工具，而是需要长期共事的同事，一个人该如何管理这支看不见的团队？
Meridian 想做的事情——多模型编排、知识炼金、持久化记忆、从碎片到成果的自动化流水线——指向的都是同一个答案：不是更复杂的模型，而是更清晰的编排；不是更长的对话，而是更可靠的承续。
项目还在早期，很多想法还只是路线图上的方块。但至少，经过这两个月的折腾，Maple 知道了哪些路走得通、哪些路是死胡同，以及最重要的——这件事值得继续做下去。
Meridian 是 Maple 的个人 AI 中枢项目，所有子项目的源代码在 GitHub 上。如果你也在探索类似的方向，欢迎交流。