烧20亿Token后我弃用OpenClaw，转投Claude Code生态

背景

随着 Clawdbot（即 OpenClaw）的爆火，AI Agent（智能体）形态在开发者社区中引发了巨大争议与狂热。作者作为一名开发者，目睹了营销号的炒作、群内的热烈讨论甚至主创被迫改名的戏剧性事件。出于对自动化工作流的探索欲，作者花费半天时间在 Claude Code 的指导下配置了 OpenClaw，试图解决日常工作中“AI 生成内容 -> 手动粘贴至飞书文档 -> 人工修改 -> 再复制回 AI”这一低效循环中的痛点。

作者的核心需求是实现飞书文档与本地 Markdown 文件的实时双向同步：监听编辑事件，自动转换格式（Markdown 转富文本），并在发生冲突时通过评论区或群组 @相关人员给出合并方案。然而，在实际部署过程中，OpenClaw 暴露出了权限管理混乱、自我终止后无法自重启、代码质量低下（“屎山”）以及维护成本极高等问题。相比之下，作者发现通过 Claude Code、Codex 等 CLI 工具结合开源连接器（如 Halo），能以更低的成本、更高的安全性和更强的稳定性实现相同甚至更优的功能。

核心内容

1. 初始尝试与 OpenClaw 的局限性

作者首先尝试让 OpenClaw 自主完成飞书同步功能的开发。初期，OpenClaw 因权限不足报错，并在代码仓库中拉取了大量混乱的代码。在切换至 Claude Sonnet 4.6 模型后，OpenClaw 虽然修复了部分逻辑并增加了防抖机制，但最终陷入“准备重启”状态后自我 Kill 进程，导致服务中断。尽管作者手动重启后功能可用，但这一过程暴露了 OpenClaw 作为独立 Agent 形态在稳定性上的致命缺陷。

随后，作者尝试将 OpenClaw 生成的 Skill 迁移至 Claude Code。Claude Code 迅速识别问题，编写了后台脚本解决了 CLI 环境下订阅事件存活的问题，并创建了 CLAUDE.md 进行统一配置。这一对比让作者意识到，Claude Code 在代码生成、调试和系统集成能力上远超 OpenClaw。

2. 技术路线的转向：从 OpenClaw 到 Claude Code/Codex

作者进一步调研发现，连接飞书等 IM（即时通讯）工具并非 OpenClaw 的独家优势。通过搜索开源项目（如 Halo、AIonUI），作者发现只需提供 ID 和 Secret，几分钟即可通过 Claude Code 或 Codex 生成连接器。作者最终放弃了 OpenClaw，转而采用以下架构：

• 核心引擎：使用 Claude Code / Codex / Gemini CLI 等强模型 CLI 工具。
• 连接器：利用开源项目快速打通飞书等 IM 平台。
• 智能体管理：构建名为 “Lucy-Coder” 的 Codex MCP Server，负责管理其他 Agent（如 Lucy, Lucy-Manager）的功能迭代与故障复活。由于 MCP Server 具有权限隔离特性，Lucy-Coder 本身具备极高的稳定性。
• 应用场景：
  • 学术工作流：定时检索知识图谱+LLM 论文，生成总结并同步至 NotebookLM，形成“检索-笔记-对话”闭环。
  • 健康管理：通过拍照识别热量与营养占比，结合个人身体指标提供点评。

3. OpenClaw 与 Claude Code/Codex 的深度对比

作者通过实际体验，对两者进行了详细对比：

| 维度 | OpenClaw | Claude Code / Codex 等 | | :--- | :--- | :--- | | 即时通信 | 需复杂配置，依赖自身 IM 集成 | 已有大量开源项目（Halo 等），扫码即连，几分钟即可通过 SDK 生成连接器 | | 定时任务 | 依赖 cronjob 配合 Skill/Tools，实现复杂 | 定义 Skill 即可，无需 Agent 介入时直接执行，成本极低；需介入时使用 SDK/MCP Server，效果不逊于 OpenClaw | | 自进化/配置 | 依赖 SOUL.md, MEMORY.md 等多文件分散管理 | 统一为 CLAUDE.md，工具与 Skill 编写能力更强，官方支持深度打磨的记忆压缩机制 | | 电脑操控 | 看似强大实则因权限全开且模型聪明 | 同样可权限全开，拥有 agent-browser 等丰富生态，且 AI 浏览器领域潜力更大 | | 权限与安全 | 泄露事件频发，易受恶意指令（如关机）破坏 | 自带多级权限控制和可拓展的操作允许列表，安全性更高 | | 记忆能力 | 上下文压缩粗糙，易丢失关键执行规则 | 官方深度打磨的压缩能力，通过 exclude 等方案保证重要信息不丢失，支持自存储记忆 | | 维护与代码 | 几十万行“Vibe Coding”屎山，Bug 多，社区维护 | 由顶尖团队开发维护，反馈者多为开发者，代码质量可控 | | 成本 | 看似免费，但 Token 消耗巨大且产出低效 | 虽也消耗 Token，但大部分为有意义产出，正常工作量下成本可控 |

4. 反思：技术焦虑与工具本质

作者指出，当前技术圈存在严重的焦虑情绪。从 MCP 概念的泛化（万物皆 MCP），到 Agent 概念的滥用（万物皆 Agent），再到如今 OpenClaw 的过度推崇，人们往往因为害怕落后而盲目跟风。作者认为，OpenClaw 的价值在于打开了思路，证明了“定时任务+AI”、“浏览器+AI”、“强模型+全权限”以及“IM+AI”结合的可能性。但其形态并非最优解，Claude Code 等 CLI 工具在稍加配置后，同样能胜任常驻助理的角色，且在安全性、稳定性和维护性上更胜一筹。

关键要点

• OpenClaw 的痛点：虽然概念新颖，但存在代码质量差（“屎山”）、权限管理混乱、自我终止后无法自恢复、记忆机制粗糙导致关键信息丢失等严重问题。
• 替代方案更优：Claude Code、Codex 等 CLI 工具结合开源 IM 连接器（如 Halo），能以更低成本、更高安全性和更强稳定性实现相同功能。
• 架构建议：推荐使用 MCP Server 作为核心控制层（如作者命名的 Lucy-Coder），利用其权限隔离特性管理其他 Agent，实现功能迭代与故障恢复。
• 核心能力验证：
  • 定时任务+AI：可高效处理论文检索、笔记同步等自动化工作流。
  • 浏览器+AI：在自动化操作领域具有巨大潜力。
  • 强模型+全权限：在受控环境下能执行复杂任务，但需警惕安全风险。
  • IM+AI：将 AI 融入飞书等日常沟通工具，极大提升交互便捷性。
• 理性看待技术热潮：避免陷入“万物皆 Agent”的技术焦虑，应根据实际需求选择合适工具。OpenClaw 的价值在于探索边界，而非作为最终的生产力解决方案。

意义与影响

这篇文章不仅是一次个人技术实践的复盘，更是对当前 AI Agent 热潮的冷静反思。它揭示了在追求“全自动 Agent”的过程中，开发者容易忽视的基础设施问题（如权限、记忆、稳定性）。

1. 技术选型启示：对于大多数开发者而言，基于 CLI 工具（Claude Code/Codex）和 MCP 协议构建的模块化工作流，比依赖单一、黑盒化的 Agent 平台（如 OpenClaw）更具可控性、安全性和可维护性。
2. 工作流范式转移：文章验证了“IM + AI + 自动化脚本”混合模式的高效性。将 AI 能力嵌入到飞书、NotebookLM 等现有工具链中，比构建独立的 Agent 形态更能解决实际问题。
3. 对行业情绪的纠偏：在营销号鼓吹“养小龙虾”的狂热中，作者通过烧掉二十亿 Token 的惨痛教训，指出了盲目追随技术形态的风险。它提醒业界，技术的价值在于解决具体问题，而非概念本身。OpenClaw 作为探索者，其意义在于证明了可能性，而后续更稳健的技术栈（如 Claude Code + MCP）才是落地的方向。