夜雨聆风今天把一条我一直想打通的链路终于跑顺了：OpenClaw 的 Feishu channel 接入完成后，再把飞书群绑定到 wechat agent，最终让 wechat agent 能直接操作飞书云盘和文档。
这件事表面看不复杂：接个 channel、配个插件、给点权限，好像就结束了。 但真折腾起来，我发现最容易让人绕进去的，不是接口细节，也不是某个报错，而是一个很隐蔽的误区：你以为“接通了飞书”，就等于 agent 已经拥有飞书能力。其实不是。
如果你也在折腾 AI 助手、自动化工作流，或者想把聊天入口和文档系统打通，这个坑大概率也会遇到。
为什么我要做这件事
我最近一直在折腾一条更顺手的工作流：平时在聊天入口里和 agent 对话，但真正的资料沉淀、文档整理、知识库维护，很多又都在飞书里。
如果这两边是割裂的，就会很别扭：
微信上能聊想法，但落不到飞书文档里 飞书里有资料，但当前会话里的 agent 又拿不到 想让它顺手建个文件夹、写个文档，最后还得自己切回去操作
所以我的目标从一开始就不是“把消息打通”这么简单，而是让 wechat agent 真正具备飞书云盘和文档的操作能力。只有这样，agent 才不只是一个聊天入口，而是能接进实际工作流的执行节点。
一开始最大的误区：以为 channel 通了，能力就都在了
最开始我犯了一个很典型的错误：我默认认为，只要 Feishu channel 接通了，agent 就应该天然具备飞书相关能力。
这个误区很容易出现。因为从表面体验看，群已经接进来了，消息也能收发，机器人也能正常聊天。人在这种时候会自然觉得：既然都“接上飞书”了，那创建文档、创建云盘文件夹、读写多维表格，不就应该顺手就能做吗？
但现实不是这样。
我当时把飞书群绑定到了 专属agent。绑定之后，群里聊天是正常的，消息链路完全没问题。可一旦我让它去创建飞书云盘文件夹或者文档，它就做不到。
更关键的是，飞书私聊机器人却可以创建文件夹。
这一下就把问题性质改变了。因为如果是飞书应用权限完全没开，那应该是私聊和群聊都不行；可现在是私聊可以，群里绑定到 wechat agent 的这条链路不行。这说明问题大概率不在“飞书有没有权限”这个层面。
先把概念捋清：Feishu channel 和 Feishu took 不是一回事
后来真正把这个问题想明白，是因为我先强行把两个概念拆开了。
Feishu channel 解决的是消息接入
它负责的是：
飞书群或私聊能不能接入 OpenClaw 机器人能不能在里面说话 这条消息能不能路由到某个 agent
也就是说，它更像是入口层。
真正干活的是 Feishu plugin / tools / skill
真正要去读写飞书文档、创建云盘文件夹、操作知识库、多维表格，靠的不是“channel 已接通”，而是当前会话里有没有暴露对应工具，比如：
feishu_docfeishu_drivefeishu_wikifeishu_bitable
这些才是 agent 真正“动手”的部分。
所以更准确地说：Feishu channel 解决“能不能说话”，Feishu tool 才解决“能不能做事”。
这也是我这次排障里最关键的概念澄清。
实际踩坑过程：现象很像权限问题，但又不完全像
这次最迷惑我的地方，不是彻底不能用，而是“一半能用，一半不能用”。
我先确认了 OpenClaw 里并没有一个特别显眼、可以一键开启的“官方内置 Feishu skill”入口。更明显的，是 Feishu channel / plugin 这一套机制。也就是说，系统本身更像是在提供一个插件能力层，而不是给一个统一的“飞书能力总开关”。
接着我看具体现象：
飞书群绑定到 wechat agent 后：能聊天，但不能创建云盘文件夹/文档 飞书私聊机器人：可以创建文件夹
这个差异很关键。它直接说明：问题不像是飞书权限完全缺失，更像是某条会话链路没有拿到正确能力。
后面我继续查，确认了几件事：
Feishu account 是 OK 的 插件也确实已经注册了工具 可见的工具包括： feishu_doc、feishu_drive、feishu_wiki、feishu_bitable
走到这里，其实已经能下一个中间结论：飞书能力本身是存在的。
我中间还尝试过给 wechat agent 做 coding + allow(feishu_doc/drive/...) 这一类配置，希望把相关工具显式放出来。但结果还是不行，群里依然拿不到这些工具。
排查到这里，方向就越来越清楚了：问题不是 Feishu app 没能力，而是 wechat 这条 agent 会话链路没有正确拿到这些 Feishu 工具。
真正根因：问题不在飞书权限本身，而在 tool policy / tool exposure
最后真正把问题定位清楚，其实就是一句话：
根因不在 Feishu 权限本身，而在 tool policy / tool exposure。
说直白一点：
不是 wechat agent 天生不能拥有飞书写权限 不是飞书插件没装好 也不是 Feishu app 完全没授权
而是原先这条会话链路里，Feishu plugin 提供出来的工具，没有被正确暴露到 wechat agent 当前会话中。
这就解释了前面的所有现象：
群里能聊天：说明 Feishu channel 通了 私聊能创建文件夹：说明飞书应用权限不是全坏 群里不能创建文档/文件夹：说明真正缺的是工具暴露，而不是消息能力，也不是账号权限
很多自动化系统的问题就是这样，表面上看像权限问题，根因其实是能力没有进入当前上下文。
最终解决方案：把 wechat.tools.profile 临时改成 full
最后真正解决问题的动作其实不复杂：把 wechat.tools.profile 临时改成 full。
改完之后，再回到群里测试，问题就直接解决了。之前不能用的飞书相关操作，在群里都能正常跑通。
这一步也基本把结论坐实了：
问题不在 Feishu 权限本身 问题在 tool policy / tool exposure wechat agent 不是不能拥有飞书写权限 而是原先这条链路没有把插件工具正确暴露出来
这类问题最烦的地方就在这里：现象看起来像“权限不够”，但真正的问题其实是“工具没进当前会话”。
这件事给我的几个启发
这次折腾完，我对 agent 系统里“接入”这件事的理解更具体了一点。
第一，能聊天和能执行，真的是两件完全不同的事。 一个 agent 看起来接得很顺，不代表它已经能帮你做完整工作流。能回消息，只说明它活着；能创建文档、整理云盘、改多维表格，才说明它真的开始干活了。
第二，排查问题一定要分层。 至少要分成三层看：
消息入口有没有通 插件和工具有没有注册 当前会话有没有拿到这些工具
前两层正常，不代表第三层也正常。而这次最核心的问题，恰恰就出在第三层。
第三，“权限问题”很多时候只是表象。 很多场景里，真正卡住你的不一定是 API scope，也不一定是 app 权限，而是工具没有暴露到当前 agent 上下文里。
如果你也想复现，我会给这几点建议
如果你也想把类似链路跑通，我建议优先注意这几件事：
1. 先分清 channel 和 tool
不要一上来就把“接入飞书”和“拥有飞书能力”当成同一件事。消息入口和工具能力，最好一开始就分开检查。
2. 一定做对照实验
像这次 飞书私聊可以、群里不行，这个对照非常关键。它能迅速帮你判断，到底是应用权限坏了，还是某条会话链路没拿到工具。
3. 先确认工具有没有真的注册出来
至少确认这些工具是否已经存在：
feishu_docfeishu_drivefeishu_wikifeishu_bitable
如果工具压根没注册，那就不是 agent 暴露问题，而是插件层的问题。
4. 不要只盯权限，也要盯 tool policy
很多时候你会本能去查“是不是没授权、是不是 scope 不够”。当然这也要查，但别只查这个。tool policy / tool exposure 往往更关键。
5. 先用 full 跑通，再做最小收敛
如果目标是先验证链路通不通，那临时把工具暴露放开，是很有效的办法。先证明能跑通，再回头慢慢收敛权限和 profile，比一开始就卡在精细化配置里效率高很多。
最后总结
这次折腾表面上是在打通 OpenClaw、Feishu channel 和 wechat agent，实际上更像是给我补了一课：agent 系统里的“接入成功”，并不等于“能力可用”。
飞书群能聊天，不代表就能写飞书文档；真正决定它能不能干活的，是对应插件工具有没有被正确暴露到当前会话。
这层一旦想明白，后面很多类似问题，排查路径都会清楚很多。
如果你也在折腾自己的 AI 工作流，我反而会建议你先别急着追求“一切自动化”，而是先把入口、工具、暴露策略这三层关系理顺。很多问题，会在这里提前消掉。
