OpenClaw × Feishu：
Skills 暴露、群路由与安全复用审计
最初目的
你最初真正要的不是“改几个 prompt”
- 不同飞书群应该像不同角色和不同工作台，而不是只换个名字。
- 群里发话后，机器人要么执行、要么读取、要么明确说读不到，不能假装完成。
- 已有别人方案时优先复用，但必须先做安全筛查，不能把 issue 评论里的 shell 直接当答案。
- 如果你踩到的是通用问题，最好能沉淀成可以反馈到官方仓库的价值资产。
我怎么盘点你的现状
盘点方法
- 读本地
openclaw.json，确认 skills、群 prompt、bindings 和脚本入口。 - 读官方 docs，核对 skills、workspaces、sandbox、configuration 的真实定义。
- 读官方 issues，看相关问题是否已有官方路线或修复。
- 读本地 gateway / config audit / ship logs，确认哪些是“真的发生过”。
- 尝试用 Playwright 做飞书网页登录态验证，确认是否已真正能做 UI 级验收。
现状快照：当前配置里存在 4 个全局 skills extraDirs、12 条 bindings；这解释了为什么“群路由正确”并不等于“skills 真隔离”。
版本快照：本机 OpenClaw 版本为 2026.3.2。本次读取到网关 runtime 在跑，但 CLI RPC probe 依然有波动。
E2E 验证快照：Playwright 飞书验证脚本已实际跑过一次，结果是 needs_login，说明当前浏览器 profile 没有可复用登录态。
最有价值的要点
关键发现
- 根因不是“某个 prompt 写得不够凶”，而是路由、skills 作用域、执行诚实性和验证闭环四层一起叠加。
- 现在最划算的修法是 prompt 级行为治理，不是立刻大改全局 skills 目录。
- 本机 CLI 存在可复现 parser bug：带引号的 bracket 路径会把引号写进 key。
- 官方对“按群细粒度隔离权限/能力”还在演进中，不是你没找到某个隐藏开关。
- 你现在确实值得做上游贡献，因为你拥有可复现证据、真实使用场景和实际收益。
要点 1
先修“会不会说真话、会不会先执行”，再修“是不是完全隔离”。
要点 2
所有可复用方案先过官方文档、官方已合并代码和本地已验证脚本三重门。
要点 3
quoted bracket path parser bug 适合单独上游；它是明确的实现问题，不是使用姿势问题。
要点 4
是否“真的跑通”必须看飞书网页登录态和 UI 渲染，而不能只看 prompt 与配置文件。
问题分类、程度与当前状态
| 问题 | 类型 | 程度 | 当前状态 | 已匹配方案 |
|---|---|---|---|---|
| 不同群仍会看到同一套 skills / 能力 | 架构 / 作用域 | 高 | 部分确认，未彻底修 | 官方 docs 指向 workspace + extraDirs；目前更适合做第二阶段隔离改造 |
| 执行类问题没执行就像执行了 | 行为 / 诚实性 | 高 | 已优化 | 在 Money 群 prompt 中强制 execute-first / read-first / evidence-first |
| Deploy 群只回裸链接，难以排障 | UX / 运维 | 中高 | 已优化 | 状态/故障问题允许先给 1–2 句人话，再补 3 行 URL |
config set bracket 路径写出错误 quoted key |
CLI / 配置 | 中高 | 本地已修复配置，官方未见修复证据 | 手工修复 + 可复现 issue 适合提交上游 |
| 网关运行中但 CLI RPC probe 偶发失败 | 可观测性 | 中 | 仍存在 | 已定位现象，但没有官方修复证据 |
| 飞书网页侧 E2E 验证没有直接闭环 | 验证 / 登录态 | 中 | 未完成 | Playwright 验证脚本可复用，但当前 profile 需要重新登录 |
散点图：按重要性排序该先做什么
理想提交长什么样
对应的 issue / PR 结构
- Bug issue：命令、输入路径、版本、复现步骤、错误结果、期望结果、代码定位。
- Docs PR：补一段“bindings vs skills isolation”的明确说明，再给推荐配置方式。
- Guide / example：说明如何安全复用官方 / 本地已验证脚本，避免 issue comment 投毒。
理想结果：官方最少会接受 bug issue；docs PR 和 example PR 的概率也不低，因为它们不涉及大改架构。
具体怎么解决：本轮已做与后续应做
| 层级 | 本轮动作 | 为什么这样选 | 下一步 |
|---|---|---|---|
| Prompt 行为 | 给 Money 群增加 execute-first / read-first / evidence-first / safe reuse | 改动小、收益大、能立刻抑制“没做却像做了” | 继续补触发词覆盖与异常回执规范 |
| Deploy UX | 给 Deploy 群和 web-ship 加“状态问题可先人话解释，再给 3 URL” | 保留原契约，不破坏已有消费侧 | 补一次真实群内 status/debug 问题回放测试 |
| 配置修复 | 修正错误 quoted keys，恢复正确 group prompt | 防止 CLI bug 留下隐藏坏状态 | 整理最小复现并发官方 issue |
| 作用域隔离 | 本轮没有直接砍全局 extraDirs | 那会影响多个现有工作流，风险过大 | 第二阶段按 agent/workspace 设计真实隔离方案 |
前后用户体验流程对比
官方最新状态：修了什么，没修什么
截至 2026-03-10 的判断
- 未看到官方已合并修复证据：按群细粒度 permission / control 仍在 issue 讨论中。
- 未看到官方已合并修复证据：Feishu 路由错位类问题仍有公开 issue。
- 未看到官方已公开修复证据：CLI quoted bracket path bug；而且本机 2026.3.2 的源码里仍能看见 parsePath 的实现缺口。
- 官方已经给出的最佳实践：skills 与 workspaces 是作用域概念；bindings 负责把消息路由到 agent，不自动代表技能隔离。
这是基于 docs + issues + 当前安装代码的推断，不是空口猜测。
为什么官方之前没优先做这件事？ 这是一个带推断成分的结论：OpenClaw 当前更优先解决“消息路由到哪个 agent”和“通用 gateway 能跑”，而你遇到的是多群、多技能、多工作流叠加后的 power-user 边缘问题。
此外，像“Deploy 群应该先人话解释再给 URL”“issue 评论 shell 不能直接执行”这类内容，更接近产品化经验与安全运营规则，官方未必会默认替你内置。
为什么这件事值得你来做
做完后的直接好处
- 减少“机器人看起来做了，其实没做”的错误预期。
- 减少部署群的沟通摩擦，尤其是 404、无回复、链接区别不清的问题。
- 把“安全复用”从个人习惯升级成系统规则，降低误执行风险。
- 给之后真正的 skills 隔离改造打好边界和优先级基础。
- 如果上游接受反馈，你以后维护成本会更低，甚至别人也会因此少踩坑。
是否真的跑通了？触发条件与验证结果
当前可以诚实说“已验证”的部分
- 关键 prompt 内容已经写入配置，对应群规则已经更新。
- web-ship 本地规则与 Deploy 群回复契约已经同步。
- 历史部署日志显示网页发布链路曾成功走通。
- 当前 gateway runtime 处于运行状态，但 CLI RPC probe 仍有波动。
当前不能假装说“已完全跑通”的部分
- 飞书网页侧 UI 验证未闭环：Playwright 验证脚本命中
needs_login。 - 因此，本轮没有拿到“当前登录态下卡片/文本已在飞书 Web 中真实渲染”的新截图证据。
| 触发条件 | 期待行为 | 当前结论 |
|---|---|---|
| Money 群中出现“执行吧 / 继续 / 现在就改 / 帮我修复 / 实现了吗” | 先执行，再回结论 + 证据 + 下一步 | 已写入 prompt 规则 |
| Money 群中出现“前面那个链接 / 我本地有 / 历史记录 / 你能看到内容吗” | 先读取对象；读不到就明确说未读取 | 已写入 prompt 规则 |
| Deploy 群问“为什么 404 / 为什么没回 / 为什么失败 / 最新地址是什么” | 先用 1–2 句解释，再给 3 条 URL | 已写入 prompt 与本地 AGENTS |
| 飞书网页登录态可用、群里有验证消息 | Playwright 检出 card / button / text | 本次未满足登录态，未完成闭环 |
Best Minds：谁会怎么说
Martin Fowler
如果路由、能力边界和执行动作没有清楚分层，你会误以为“系统已经隔离”，但其实只是消息转发到了另一个 agent。
Charity Majors
“已完成”必须伴随证据；否则这不是 observability，而是表演。你现在修的正是这个坑。
Guillermo Rauch
把状态问题讲清楚、把稳定入口给到用户，往往比再加一个新功能更能改善体验。
结论
一句话总结：你这轮最重要的诉求不是“彻底隔离 skills”本身，而是把 OpenClaw 变成一个说真话、会执行、能解释、可安全复用、值得向官方反馈的系统。
已实现：Money 群行为治理、Deploy 群状态解释、本地 web-ship 同步、quoted key bug 定位与本地修复。
未完全实现：真正的 skills / workspace 隔离、稳定的 CLI RPC probe、飞书网页登录态下的 E2E UI 验证。
最短下一步：先补一次飞书网页登录，再跑验证脚本；随后把 parser bug 和 docs 澄清整理成可直接发官方仓库的 issue / PR 草稿。