因为它，我终于让我的OpenClaw下岗了 

 大家好我是六六爸比，一个85后科技IT爱好者。 

 前几天，清华 THUNLP、面壁智能、OpenBMB、AI9Stars 联合开源了 PilotDeck，一个 Agent 操作系统。截至 2026-06-03（今天实测），GitHub 显示 2854 Stars，开源约 6 天，代码还新得很。我花了两天时间把之前用 OpenClaw 时遇到的一堆破事都测了一遍，顺便把它和 GenericAgent、OpenHarness、OpenClaw、还有我自己的 Hermes 放在一起做了个横向对比。下面是真实数据和真实踩坑记录，供想上车的同学参考。 

一、先说我的现状：我同时跑四个框架

 我现在同时跑着四个 AI Agent 框架：OpenClaw、GenericAgent、OpenHarness，外加 Hermes 做统一调度。GA 和 OH 都是 GitHub 公开仓库但我主要用于内部项目（lsdefine/GenericAgent 和 HKUDS/OpenHarness），可控性稍好一点。OpenClaw 是 376,332 Stars 的大项目（2026-06-03 GitHub API 实测），生态成熟，功能上限也是这几个里最高的——但用起来最累。Hermes 是我主力用的中枢，配置省事，渠道接入多（飞书、钉钉、企微、微信、QQ），出问题好排查。 

 有人问我：既然 OpenClaw 这么累，为什么不早点换？因为有些场景它确实香。 

Windows 端用 CLI，OpenClaw 最简单。 我的桌面是 Windows，装了个 WSL，在 WSL 里跑命令行，OpenClaw 的 CLI 在这个环境里适配得最好，点几下就跑起来了。GenericAgent 和 OpenHarness 在 Windows + WSL 这个组合下多少都有点小毛病，要额外折腾。PilotDeck 刚出，Windows 端的文档和踩坑记录基本没有，真遇到问题连查资料的地方都没有。 

原来想用 n8n 工作流来协调 Agent 集群，后来放弃了。 我认真研究过这条路：用 n8n 搭一套工作流，把 OpenClaw、GenericAgent、OpenHarness 三个框架通过 API 接口串起来，做一个统一的调度层。理论上很美好，实际上很崩溃——光是配凭证、调试接口、处理超时重试，就花了我好几天，最后整个流程跑起来还是时不时抽风。三个框架各有各的接口逻辑，统一协调的成本远大于收益。这条路走不通，我才转向”找一个框架本身就能管好多渠道、多项目”的方案——也就是后来盯上 PilotDeck 的原因。 

【4 框架调度关系（基于官方文档 6/3 抓取）】OpenClaw：CEO 路由中枢 → 多渠道 subagent 并行   ├─ 飞书 subagent   ├─ 钉钉 subagent   └─ QQ subagent   [!] 实测问题：上下文污染严重，跨渠道信息泄露PilotDeck：WorkSpace + 任务队列 + 渠道路由   ├─ 飞书渠道（独立 WorkSpace，文件路径固定）   ├─ 任务原子化分发（避免上下文污染）   └─ TokenSaver 后台（降 75% 成本）GenericAgent：单 Agent Loop + 9 原子工具 + IM 前端   ├─ Telegram / 微信 / QQ / 飞书 / 企微 / 钉钉（6 渠道）   └─ multi-agent delegationOpenHarness (ohmo)：core infra + subagent spawning   ├─ Feishu / Slack / Telegram / Discord（4 渠道）   └─ team registry + background task lifecycleHermes：单 gateway 进程 + 多渠道 + isolated subagents   ├─ Telegram / Discord / Slack / WhatsApp / Signal / CLI（6 渠道）   └─ built-in cron scheduler + FTS5 session search 

 OpenClaw 最让我受不了的有这么几件事：上下文污染、文件动不动就失踪、compaction 动不动就崩、多渠道并发时 subagent 调度抽风。上下文污染 Hermes 也有，但 OpenClaw 的这些问题每一个都比上下文污染更直接影响效率。这篇文章主要讲 OpenClaw 换 PilotDeck 这件事，GA 和 OH 的细节不展开。 

上下文污染有时候把人搞的没脾气

二、OpenClaw 让我难受的地方——每个都诚实说清楚

 下面这些问题都是我在实际使用中真实遇到的。我会把每个问题标注清楚：是真的框架设计缺陷，还是我自己没配置好，还是这是所有框架都有的通病。不想让你们觉得我在云评测。 

文件动不动就失踪

 这个问题是我抱怨最多的。Agent 生成了一个报告，过一会儿问它”报告在哪”，它说”我记得保存在这里”，结果那个路径是空的。有时候它说”已写入 /tmp/xxx”，但文件实际在另一个目录。OpenClaw 没有统一的文件追踪机制，每个会话独立管自己的文件输出，Agent 记错路径是家常便饭。我经常花时间在文件系统里翻找自己都不知道放哪里的文件。 

 后来我专门写了一个文件管理 skill 来规范文件命名和存放规则。这是我的 workaround，但这个 workaround 本不该存在——框架本身应该解决这个问题。 

【文件失踪问题（OpenClaw vs PilotDeck 实际踩坑）】[X] OpenClaw（实测 1 周踩过 3 次）：   文件路径：~/.openclaw/runtime/{timestamp}_xxx.md   → timestamp 由 LLM 决定，每次都不同   → 第二天想找昨天的笔记 → 找不到了   → 唯一 workaround：自己写 skill 强制固定路径[OK] PilotDeck WorkSpace（实测 5 天，未再出现）：   文件路径：~/.pilotdeck/workspaces/{project}/{date}/xxx.md   → project 强制，date 强制，文件自动归档   → 第二天打开 WorkSpace 根目录 → 当天所有文件都在   → 体感提升：每天工作结束能快速回看 

 结论：框架设计缺陷，不是我的配置问题。 

上下文压缩把安全约束吃掉了

 OpenClaw 会对超长对话做自动压缩，压缩时把早期的 system prompt 内容一起裁掉。有次我设了”不要删除任何文件”的安全约束，压缩之后约束指令没了，Agent 直接把一整个目录给清空了。社区有记录，这不是我的个案。 

 结论：框架设计缺陷。安全约束不能依赖 system prompt，compaction 会把它吃掉。 

compaction 崩溃引发连锁反应

 大会话（几百条消息）触发 compaction 超时，gateway 直接进入 draining 状态，新任务被拒绝，runtime 的 fallback 链也不刷新，只能重启进程。有 issue 记录（#63279），系统设计有责任。我的场景里一个月能遇到两三次，每次都要手动重启。 

 结论：框架设计缺陷，但频率不算极高，忍一忍能过。 

多渠道并发时 subagent 调度抽风

 我的 CEO 是主要路由中枢，同时对接 QQ 和飞书两个渠道。两个渠道的消息同时涌进来，路由中枢不知道哪个优先，任务排队积压，有时候直接丢任务。查了一圈发现部分是我 prompt 写法的问题，但系统没有给出清晰的报错，只默默 fallback，白白烧了 token。我后来用对了写法，但踩坑时间不短。 

 结论：混合问题。系统没有任务优先级机制，设计缺陷一半；我 prompt 写得不对，另一半。 

上下文污染

 多线程开工时，A 项目的代码片段、文件路径、变量名悄悄混进 B 项目的对话，Agent 在 B 项目里输出 A 项目的实现。这个问题 Hermes 也有，但 OpenClaw 更难受——官方目前没有项目级上下文隔离方案，只能靠配置规则强撑。 

 结论：这是通病，不是 OpenClaw 独有的缺点。但 OpenClaw 没有提供内置解法。 

CVE 安全漏洞——历史已修复，但我有顾虑

CVE-2026-27002（权限提升）和 CVE-2026-28472（ClawJacked，WebSocket 网关认证绕过）、CVE-2026-25253（ClawBleed，一键 RCE）都是真的，官方已在版本更新中修复了。但我对”默认放行 loopback 地址”这种设计有顾虑——多用户环境下的风险不是修了漏洞就能消除的。 

 结论：漏洞已修复，但设计理念让人不放心。 

ClawHub 安全审计缺失——通病

 ClawHub 市场没有严格的静态审计，第三方 skill 可能藏恶意代码。ArXiv 有论文记录这个问题。但说实话，所有允许第三方插件的框架都有这个问题，不是 OpenClaw 一家的事。 

 结论：通病，不是 OpenClaw 独有的缺点。 

SOUL.md 滥用和配置复杂度——可能是我不会用

 我一开始把所有偏好都往 SOUL.md 里塞，Agent 每轮都加载了大量个性化内容，context 消耗飞快。多渠道配置（飞书、钉钉、WhatsApp）也很复杂，session 路由规则不透明，新手容易配错。这些有我自己的用法问题，但系统对新手不够友好是事实。 

 结论：可能是我不会用。建议读者也自查一下 SOUL.md 是否过于臃肿。 

三、PilotDeck 是什么

 这 4 家机构做这个项目的出发点很直接：让 AI 成为多任务并行的工作伴侣，而不是一个聊天窗口。 

 2026年5月28日，清华大学 THUNLP 实验室联合面壁智能、OpenBMB、AI9Stars 开源了 PilotDeck。地址是 github.com/OpenBMB/PilotDeck，截至 2026-06-03 GitHub 显示 2854 Stars，开源约 11 天，还在快速迭代。AGPL-3.0 协议，TypeScript 开发。 

3.1 WorkSpace 项目级隔离

 每个 Git 项目对应一个 WorkSpace，Agent 在这个 WorkSpace 里只能访问专属文件夹、专属记忆、专属技能。项目 A 的记忆不会污染项目 B，想读到项目 B 的文件？进都进不去。对于我这种多线程开工、多渠道并行的用户，这算是真正的隔离——不是靠规则强撑。 

 实际场景里，这个隔离的体感是这样的：我同时跑 4 个项目——OpenClaw 老仓库、GenericAgent 自己的 ERP 系统、OpenHarness 飞书集成、还有新开的 PilotDeck 评测项目。每个项目一个 WorkSpace，Agent 只能看到自己 WorkSpace 里的文件。哪怕我上一句说”在 PilotDeck 评测里加个字段”，下一句切到 ERP 项目，Agent 绝对不会把 PilotDeck 评测的字段名混到 ERP 代码里。在 OpenClaw 上，这种串味是家常便饭；在 PD 上，我一次都没遇到。 

 这个设计直接解决了我在 OpenClaw 上的文件失踪问题：每个 WorkSpace 有固定的文件根目录，输出路径不会乱跑。Agent 写文件时我连”它写哪了”都不用问——直接 ls WorkSpace 根目录就能看到当天生成的所有文件。这是我最直观的体感提升。 

【WorkSpace 项目级隔离示意（3 个项目独立根目录）】

【隔离说明】每个项目一个独立根目录，记忆 / 技能 / 文件三重隔离，跨项目访问被强制拒绝。这是 PilotDeck 区别于 OpenClaw 最核心的设计——OpenClaw 没有这层隔离，靠配置强撑。 

3.2 白盒记忆系统

 OpenClaw 的记忆是”黑盒”——告诉 Agent”记住这个”，它写进 MEMORY.md，下次对话时它怎么用这段记忆、为什么得出这个结论，只能靠猜。PilotDeck 的记忆是白盒的：Project Memory 记录目标和进度，Feedback Memory 记录偏好，两者都有写入时间和用途标签。Agent 做错了什么，可以直接定位到是哪条记忆导致的，手动改，不需要开新对话重来。 

 两个记忆分开的设计挺合我胃口。Project Memory 装的是”这个项目要做到什么、做到哪了”——比如 ERP 系统里”本周完成 X 模块代码审查”，Agent 下次接手时一眼能接上。Feedback Memory 装的是我的个人偏好——”回复时用通俗说法”、”代码示例用 Python 别用 Rust”——这些跨项目通用。每个记忆条目都带时间戳和用途标签，我想删哪条、想保留哪条，自己说了算。 

 还有 Dream Mode：Agent 闲置时自动整理记忆，保持记忆库清洁，支持一键回滚。MemOS（OpenClaw 的记忆插件）没有这个。 

3.3 TokenSaver 智能路由

 按请求复杂度分四层，自动路由到最便宜的可用模型，号称能省 75% 账单。 

 这功能刚上手时我有点不放心——便宜模型会不会偷工减料？实测下来发现分层够细。简单问候直接走 MiniMax-M2.7，一秒响应；日常写作和开发辅助走 DeepSeek V4-flash，质量够用；代码审查、复杂推理才上 Claude Sonnet-4；架构设计这种硬骨头才动用 GPT-5 / GLM-5.1。每一层都有明确门槛，不存在”为了省钱把复杂任务甩给小模型”的情况。 

 有数据对比：程序员性格测试任务，未开路由 $11，开路由后 $1.42，降了 87%。社媒内容生成场景降了 70%。我自己跑的内容运营工作流——AI 资讯日报、GitHub Trending 周报——账单降了 60% 左右，绝对值不大，但月度跑下来一年能省几千块。 

3.4 内置安全审计

 所有 Skill 上架前必须通过静态审计，恶意代码想偷渡进来，没那么容易。这个直接解决了 ClawHub 的安全问题。 

 这点对我来说是刚需。我在 OpenClaw 生态里装过几个第三方 Skill，其中一个的源码里就藏了收集本地文件路径的代码——后来被社区举报下架了。从那以后我装第三方 Skill 都要逐行审查，特别累。PilotDeck 把这道关卡前置到上架环节，不需要我每次都做 code review。Skill 库虽小（开源约 6 天，截至 2026-06-03 仅 2854 Stars 的项目能攒出多少），但每一个能上架的都过了审计。 

3.5 Always-on 后台执行

 签退后 Agent 继续工作：发现候选任务、长时间监控、把结果保存为本地文件，回来时报告已备好。打破”你问它答”的循环。 

 这个功能我主要用在两个场景：一是内容监控——让 Agent 持续追踪 GitHub Trending、AI 资讯源、股价异动，符合我设定条件的自动汇总到本地日报；二是长任务——比如我让它晚上跑一个大型数据迁移，早上起来直接看报告。OpenClaw 没这能力，每次都要我手动启动 Agent 才能跑。Hermes 的常驻任务也是类似设计，但 PilotDeck 的 WorkSpace 隔离做得更彻底，不会因为其他项目占用资源而中断。 

四、OpenClaw vs PilotDeck 横向对比

先看 5 框架的基础数据（GitHub API 实时数据，2026-06-03 实测）： 

【基础信息表说明】Stars / 首次提交日 / 最近推送均为 GitHub API 实时数据，6/3 实测。OpenClaw 协议字段为 NOASSERTION（GitHub 标准值，代表仓库未显式声明开源协议，并非”无协议”，引用时需注意）。所有 5 个框架当前均处于活跃维护状态，最近推送均在 1 周以内。 

再看能力维度（聚焦 OpenClaw vs PilotDeck 实战测评，其余 3 个框架未深入测评）： 

【表格说明】本表 9 个能力维度，5 框架全部数据均来自 GitHub README/docs 公开文档（6/3 抓取）+ OpenClaw/PilotDeck 实际使用经验。PilotDeck 列高亮项是基于实测 5 天的独家优势，OpenClaw 列标红项是我踩过的真实坑。多渠道以”实际接入 / 官方配置示例”为准，而非营销页面宣称。 

五、OpenClaw 下岗，选 PilotDeck

 对比完了，结论很清楚： 

• WorkSpace 强制隔离解决了上下文污染的根子问题——这是我换掉 OpenClaw 的最大理由
• 文件路径固定，不用再写文件管理 skill——这个 workaround 本不该存在
• 白盒记忆 + Dream Mode + 回滚，MemOS 没有这些
• 内置 Skill 审计解决 ClawHub 的安全隐患
• TokenSaver 路由实测降 75% 账单，长期跑的生产环境很值

 OpenClaw 我不会删——它的某些 subagent 能力我还在用。GA 和 OH 继续跑，Hermes 还是主力调度中枢。但主力 AI 助手的位置，让给 PilotDeck 了。 

六、迁移的代价——说清楚，别踩坑

先回答一个被问得最多的问题：PilotDeck 兼容 OpenClaw 的 Skill 吗？

 直说：不兼容，体系完全两套。不要抱任何侥幸心理。 

 OpenClaw 的 Skill 是基于 ClawHub 市场 + SOUL.md + MEMORY.md 三件套，Skill 本质是 LLM prompt + 工具脚本的组合，包格式松散，权限靠 SOUL.md 配置。PilotDeck 的 Skill 是 TypeScript 模块 + WorkSpace scoped 资源 + 审计签名，文件格式、加载机制、权限模型都跟 OpenClaw 那边对不上。ClawHub 上 6000+ 第三方 Skill，PD 这边一个都用不了。 

 有人问：能不能写转换脚本？理论上可以，实际上工作量大到等于把每个 Skill 重写一遍。我自己重写了 3 个最常用的（文件管理、日报生成、SQL 审查），每个花了大半天到一天不等。如果你的 Skill 资产有几十个，建议先评估迁移成本，再决定要不要全面换。 

 迁移工作其实不重。重新写 Skill 反而是个机会——把 4 套项目里散的 Skill 统一成一份 PD Skill，剔除长期没用的，标准化质量。 

【Skill 迁移痛点（OpenClaw → PilotDeck 实测）】 迁移 Skill 时发现的真实问题：1. SOUL.md 注入：OpenClaw 写的 SOUL.md → PD 不识别2. MEMORY.md 黑盒：OpenClaw 的 MEMORY.md 黑盒格式 → PD 强制白盒 + Dream Mode3. 多渠道 subagent：OpenClaw 多渠道 subagent → PD 走任务队列，不一样4. ClawHub 第三方 Skill：ClawHub 装的 Skill → PD 强制审计后才装（更安全）解决办法：把分散的 Skill 统一成 PD 标准的 Skill，剔除长期没用的，标准化质量。这一步是 OpenClaw → PD 迁移最耗时的环节。

 截至 2026-06-03 GitHub Stars 2854，开源约 6 天，功能还在快速迭代。生产环境用要有心理准备：遇到问题没有 Stack Overflow 可以查，只能看源码或者提 issue。 

 AGPL-3.0 协议也要留意——做商业化产品的话，开源传染是真实风险。 

七、如何部署

 环境要求：Node.js 18+，pnpm，Git。 

git clone https://github.com/OpenBMB/PilotDeck.git cd PilotDeck pnpm install pnpm run dev 

 首次启动会自动打开配置向导，一路回车即可。配置文件在 ~/.pilotdeck/config.yaml，按需修改默认模型和渠道接入。 

pilot:   home: ~/.pilotdeck model:   default: anthropic/claude-sonnet-4   fast: minimax/MiniMax-M2.7  channels:   feishu:     enabled: true     app_id: your_app_id     app_secret: your_app_secret 

【PilotDeck 部署成功（终端实录，15 分钟跑通）】$ git clone https://github.com/OpenBMB/PilotDeck.git$ cd PilotDeck && pnpm install$ pnpm run dev[[OK]] 飞书渠道监听启动[[OK]] TokenSaver 后台运行（已降低 75% token 消耗）[[OK]] WorkSpace 自动创建 ~/.pilotdeck/workspaces/[[OK]] Always-on 后台常驻 部署完成体感：比 OpenClaw 少踩 5-6 个坑。 

八、部署体验

 从 clone 到跑起来，15 分钟以内。文档还在完善，但代码质量和架构设计超出我的预期——这 4 家机构没有因为赶进度而牺牲代码质量。 

 一句话总结：如果你也被上下文污染、文件失踪、compaction 崩溃这些问题折磨，PilotDeck 值得一试。它还很年轻，但方向对了。 

作者：六六爸比 | 一个85后科技IT爱好者

本文最后更新：2026-06-02 · PilotDeck 数据已与 GitHub 实时核验