ZON
Best Minds · Private Audit

OpenClaw × 飞书问题审计:你的真实痛点、闭环现状与最佳修复路径

我把你当前那张私有飞书表、你和 OpenClaw 的 85 条实际对话记录、以及 2026-03-09 时点的 OpenClaw 官方文档与公开 issues 放在一起看。结论很清楚:你最大的痛点不是“它完全不会”,而是大量问题停在“已回答、未验证、未真正执行”;其次是群路由/技能边界预期长线程上下文。真正应该先解决的是执行闭环与能力边界,而不是先追求更花的展示。
数据窗口:截至 2026-03-09 11:48 (Asia/Shanghai) 私有数据:飞书问题表 + 本机会话日志 + 本机 OpenClaw 配置 公开对照:OpenClaw 官方 repo / docs / issues
Total Questions
85
你实际向 OpenClaw 提过的记录数
Verified Closed
19
22% 真正可视为已闭环
Pending Verify
64
75% 已回但还没证据闭环
Immediate Fix
9
应该立刻优先处理的项

一眼结论

Maintainer lens

你碰到的不只是“模型不聪明”,而是典型的 agent surface area 过大:多群、多工作区、多自动化、多渠道,任何一个边界没钉死都会串。

Operator lens

对你这种使用强度,回答正确不够,必须“可验证执行”。没有证据链的回答都应该算未完成。

Product lens

你在意的是“好不好用、有没有真做、我能不能马上判断”,所以优先级应排“执行闭环 > 上下文准确 > 展示美观”。

这张表里到底记录了什么问题

要点 1

先看总盘子:你的核心矛盾不是没有回答,而是回答之后缺少执行证据与闭环确认。

Status · 闭环状态分布已验证闭环19已回复待验证64未解决2
从结果看,你和 OpenClaw 的主要矛盾不是“完全没有回答”,而是回答之后缺少可验证闭环。
Category · 记录到的官方问题类型其他43配置/排障14发布自动化9定时/心跳9UX/呈现5飞书集成4选题策略1
表格中的官方类型以“其他、配置/排障、定时/心跳、发布自动化”为主;但我进一步拆分后,真正的根因更集中在执行、边界和上下文。
Severity · 按现在应对紧迫度排序S1 立即解决9S2 本周解决16S3 排队优化41已闭环/观察19
如果按“现在要不要解决”来排,S1 与 S2 一共 25 条,足够构成一轮专门治理。
Scatter · 根因族价值 / 闭环度 / 频次606570758085907580859095闭环分(越右越接近真正做完)价值分(越上越值得优先解决)执行落地缺口27权限/配置/路由问题18上下文/历史理解缺口5自动化稳定性/调度8归档/信息组织6展示/交互体验5
这个散点图把“价值分、闭环分、出现次数”放在一起看:最大气泡是执行落地缺口,它不是最难理解的问题,却是最伤信任的问题。

你真正遇到的 6 类问题

要点 2

再看根因:执行落地、权限边界、上下文理解,是三条真正拉低你体验的主轴。

根因族出现次数平均优先级已闭环待验证未解决代表问题
执行落地缺口2761.83240那还是 1 吧,我有个页面想部署到子页面下,确认前先不要放到首页,直接给我子页面
权限/配置/路由问题1862.35130我好像改成了不同群调用不同skills 那你为什么还能获取所有的skills呢?是因为我的配置现在没有针对所有的群做配置吗?
上下文/历史理解缺口564.2140我本地有啊 你找不到吗
自动化稳定性/调度863.8440你推荐的每日内容是不是一样了?
归档/信息组织663.2240能先建一个飞书表格把我诉求放里面吗? music.zondev.top里面有相关歌曲的其他歌词
展示/交互体验557.6320为什么按优先级 任务内容都是空的

把官方粗分类翻译成你的真实体验后,结构会更清楚:执行落地缺口最多,权限/配置/路由其次,上下文/历史理解自动化稳定性则决定你会不会继续信任它处理复杂任务。

Heatmap · 每类根因目前卡在哪一步已验证闭环已回复待验证未解决执行落地缺口3240权限/配置/路由问题5130上下文/历史理解缺口140自动化稳定性/调度440归档/信息组织240展示/交互体验320
热力图显示:执行与配置问题不是完全不会,而是大多停在“已回复待验证”。
Groups · 问题集中在哪些群💰Money29 · avgP 60.2🎶新专辑24 · avgP 58.9自媒体7 · avgP 60.6Tasks6 · avgP 59.3🎵Music5 · avgP 65.2Deploy5 · avgP 59.6公众号信息获取4 · avgP 59.8
问题量最高的是 💰Money 与 🎶新专辑;但平均优先级最高的是 🎵Music 和 actions tips,说明你在真实执行场景里更容易暴露边界。

直接和它对话,哪些真的实现了,哪些没有

要点 3

再看实现:真正已经实现的是局部能力;你最在意的“立刻执行并回证据”还没有成为默认动作。

Funnel · 直接对话到底有多少真的落地对话中提出问题85收到某种回复83仍待验证64已验证闭环19完全未解决2这里最重要的事实:不是“没回答”,而是“大量已经回答,但还没有被验证为真正完成”。
你最该盯的不是“它会不会说”,而是“有没有真正落地 + 有没有证据”。
Tradeoff · 先修哪里性价比最高实现成本(越右越高)收益(越上越高)执行闭环上下文准确调度稳定展示体验
如果资源有限,先修“执行闭环”和“上下文准确”最划算;展示体验可以排在后面。
已经真正实现 / 至少有明确证据
  • 你为什么会推荐这个 从用户吸引角度 你觉得合适吗:群提示词已固化“吸引优先 + 历史补捞”策略。
  • 从吸引用户的角度,告,让我每一天都发类似的内容,你不要每次都让我提醒:群提示词已固化“吸引优先 + 历史补捞”策略。
  • 你不能查看我的本地吗?没有设定相关内容吗?相关的skills 也没有吗?本地没有相关路径吗?就是我不是有每天定期发你的那个,你去查查聊天记录吧,要不?:群提示词已固化“吸引优先 + 历史补捞”策略。
  • 今天凌晨跑了几个定时任务:已增加 watchdog 例行检查,定时核验投递新鲜度。
  • 看不到我的定时任务吗?你应该是可以看到我的定时任务,其中有一个就是跟每天会发各种任务的那个文件,你可以去看:群提示词已固化“吸引优先 + 历史补捞”策略。
  • 你是不是能获取到我所有看板的调研?我看板调研每天都会有大量的信息,但是我发现你好像只对我当天处理的最新的内容去给我,那我觉得这样是不合理的。 你目前的这个逻辑是什么?你是怎么选定要推给我哪些内容的?:群提示词已固化“吸引优先 + 历史补捞”策略。
还没有真正实现 / 仍停在口头层
  • 我好像改成了不同群调用不同skills 那你为什么还能获取所有的skills呢?是因为我的配置现在没有针对所有的群做配置吗?:已给出文本方案与下一步操作口令。
  • 那还是 1 吧,我有个页面想部署到子页面下,确认前先不要放到首页,直接给我子页面:已给出文本方案与下一步操作口令。
  • 我本地有啊 你找不到吗:已给出文本方案与下一步操作口令。
  • 你推荐的每日内容是不是一样了?:已给出文本方案与下一步操作口令。
  • 其他定时任务的状态呢:已增加 watchdog 例行检查,定时核验投递新鲜度。
  • 你现在就改吧:已给出文本方案与下一步操作口令。

可以把当前状态概括成一句话:OpenClaw 已经能在你的一部分流程里产生真实动作,但你最在意的“当场执行、当场回证据、别空转”还没有被一致性地做到。

为什么你会遇到,而有些人不一定会遇到

你的使用方式更“极限”
  • 你不是单群、单工作区、单任务,而是多群、多 agent、多自动化、多外部系统一起跑。
  • 你期待的是“真正代办”而不是“聊天建议”,这天然会把执行证据、权限、路由边界都暴露出来。
  • 你把 Feishu、Git、Vercel、看板、表格、cron、知识库串成一条链,所以任何一个环节不稳都会被你放大看到。
本机配置层面我看到的直接原因
  • 当前配置已经按 Feishu 群做了 bindings 分流,但技能目录仍然是全局 extraDirs 加载。
  • 当前至少有一条群提示词已写入“先执行再回复、回传执行证据”的规则,但对话结果里仍有大量只答不做。
  • 当前已启用 reply-context-slim 之类的历史压缩钩子,说明你已经在主动缓解长上下文问题。
  • 当前使用了 heartbeat / watchdog / 飞书台账 / 看板等多层自动化,因此你的问题比普通 OpenClaw 用户更容易暴露边界。

所以并不是“别人没遇到,你比较倒霉”。更准确地说,是你已经把 OpenClaw 用到了更像运营系统 / agent OS 的强度,而官方产品与配置模型还没有把这些高级场景全部磨平。

最新官方仓库与 issues:哪些与你高度相关

Timeline · 上游最近公开问题与你的映射2026-02-06#40337 Feishu channel binding seems…2026-02-07#40325 Add permissionMode to bindin…2026-02-07#40317 Add per-binding permissionMo…2026-03-05#10859 Cron scheduler timer never f…2026-03-06#10848 Compaction summaries fail du…2026-03-06#10840 System events lose thread co…
2026-02 到 2026-03 的公开 issue 已经能看出上游正在处理“上下文、cron、Feishu 路由与权限边界”这些和你非常接近的主题。
IssueDateTitle与你的关系
#403372026-03-06Feishu channel binding seems not to be working, all incoming messages go to default agent与你的“分群后仍串路由/默认 agent”最接近
#403252026-03-06Add permissionMode to bindings for multichannel / group control说明“按绑定粒度控权限”仍在补齐
#403172026-03-05Add per-binding permissionMode for finer group/channel control与你想要的“每群能力边界”高度相关
#108592026-02-07Cron scheduler timer never fires解释为什么仅靠内建定时不够稳
#108482026-02-07Compaction summaries fail due to context limits与你的“长线程、长上下文、链接后续理解”问题相关
#108402026-02-06System events lose thread context and expose cross-thread leaks与你的“历史、线程、上下文”抱怨高度相关

这里最关键的判断是:你的问题并不全是“你自己配错了”。至少“Feishu 绑定/权限粒度”“长上下文压缩”“cron 稳定性”这三类,上游在 2026-03-09 仍有公开 issue,说明它们仍属于活跃中的工程边界。

最佳实践:现在最值得怎么修

要点 4

最后看解法:先钉死执行闭环,再修能力边界与读取 guard,最后再优化展示和归档。

Ownership · 这些问题该找谁解决上游内核本地配置提示词/交互执行落地缺口很高权限/配置/路由问题很高上下文/历史理解缺口自动化稳定性/调度归档/信息组织展示/交互体验很高
这张图不是为了分锅,而是为了避免你把所有问题都丢给同一个层面去解决。
P1

把“执行请求”和“咨询请求”彻底分流

为什么:27 条都落在“口头确认多、执行证据少”的执行缺口,这是最大信任损耗源。

怎么做:对所有“执行吧 / 改吧 / 帮我部署 / 建表”类话术,强制进入 execute mode:必须调用工具、必须回 messageId/URL/改动结果;失败时明确 FAILED。

P2

不要把 bindings 当成 skills 隔离

为什么:你遇到的“不同群仍能看到全部 skills”本质不是你记错,而是产品模型就是“绑定路由 agent,skills 目录全局加载”。

怎么做:若要真隔离,优先做 dedicated agent + dedicated workspace + 专属 systemPrompt;同时跟踪 #40317 / #40325,等 per-binding 权限能力成熟。

P3

把“先读链接/先读文件”做成硬前置

为什么:“我本地有啊 你找不到吗”“你能看到那个链接内容吗”说明它常在没打开内容前就先回答。

怎么做:在群提示词里加 guard:涉及链接、本地文件、历史记录时,先说明“我将先读取/还未读取”,只有拿到证据后才能继续回答。

P4

继续保留外部 watchdog,不要只信内建 cron

为什么:官方仍有 #10859 这类调度问题;你自己也多次追问“其他任务状态呢”。

怎么做:保留现有 watchdog + 每日健康汇总,所有定时任务回执都统一进一张状态表,至少包含 freshness、last_ok、deliver_id。

P5

修正看板字段映射和卡片模板

为什么:“优先级有值但任务内容空”“不要只回链接”说明你现在的主要障碍已从模型能力转成信息呈现。

怎么做:先修字段 key mapping,再统一回复模板:一句人话摘要 + 为什么是这个链接 + 下一步动作 + 证据链接。

P6

把“信息组织”后移为治理项

为什么:建文件夹、飞书表、多维表都是对的,但它们不是当前的第一阻塞。

怎么做:等 P1–P5 稳定后,再把诉求、变更、执行证据抽成标准字段,沉淀到同一个知识账本。

Roadmap · 最省力的解决顺序T+0~1执行模式分流执行请求必须带证据回执T+1~3修 skills 预期按 agent/workspace 真隔离,不再把 bindings 当 skills 边界T+3~5补读取 guard链接/本地文件/历史先读后答T+5~7稳住调度继续用 watchdog + 状态账本T+7~14修展示与字段priority 映射、友好回复模板、统一卡片
推荐顺序:先把“真的做”修稳,再谈“更好看”“更自动”。

横向对比:哪些问题必须解决,哪些可以后排

问题族
是否必须解决
原因
主要责任
建议时机
执行落地缺口
必须
这是你信任 agent 的前提,不解决会一直变成“口头助手”。
提示词 / 本地流程
立即
权限/配置/路由问题
必须
不修会导致跨群串路由、边界模糊、能力预期错位。
本地配置 + 上游演进
立即
上下文/历史理解缺口
必须
复杂链路一旦读错上下文,后面都会偏。
上游 + 本地 guard
本周
自动化稳定性/调度
应该
这是“它能不能日常替你值班”的关键。
上游 + watchdog
本周
归档/信息组织
应该
能减少混乱,但不是当前第一阻塞。
本地流程
第二阶段
展示/交互体验
可后排
重要,但应放在执行闭环稳定之后。
提示词 / 模板
第二阶段

代表性案例

问题当前状态优先级我现在的判断
actions tips我好像改成了不同群调用不同skills 那你为什么还能获取所有的skills呢?是因为我的配置现在没有针对所有的群做配置吗?已回复待验证72已给出文本方案与下一步操作口令。
💰Money我本地有啊 你找不到吗已回复待验证71已给出文本方案与下一步操作口令。
自媒体你推荐的每日内容是不是一样了?已回复待验证71已给出文本方案与下一步操作口令。
🎵Music其他定时任务的状态呢已回复待验证71已增加 watchdog 例行检查,定时核验投递新鲜度。
💰Money为什么按优先级 任务内容都是空的已回复待验证63已给出文本方案与下一步操作口令。
Deploy是的,你要按比较友好的方式回我,而不是只回一条链接。即便你要回链接,你也要说明为什么回这个链接,而不是说只回链接。那肯定是之前设置的哪里有问题,你帮我看看怎么能更友好的设置已回复待验证57已给出文本方案与下一步操作口令。

Sources

公开引用只使用 OpenClaw 官方仓库 / 官方文档 / 官方 issue。你的私有飞书表、本机配置和本机会话只在本地分析后以脱敏聚合结果呈现,不在公开页面暴露原始内容。

一句话结论: 你和 OpenClaw 之间最值得立刻修的,不是“再加多少新能力”,而是把现有能力的执行闭环、群边界、上下文读取三件事钉死;这三件一稳,剩下的展示、归档和体验优化才会真正变成加分项。
把你的飞书问题表、真实对话与 OpenClaw 最新官方 issues 对齐,区分哪些已实现、哪些没实现、哪些值得现在立刻解决。
— One small system