Hermes 接上飞书还不够，飞书 CLI 才是关键这一步

一、前言

大家好我是卡卡，前两天我写了一篇关于 Hermes 的安装教程，当时我们也把消息网关配置到了飞书。

但我们把 Hermes 接到飞书这一步，本身其实还远远不够。因为现在最多也只是让 Hermes 能在飞书里面和我们聊起来了，如果只是拿来简单体验一下，那这样确实已经够了。

可如果我们装 Hermes，不只是为了体验，而是真的想让它帮我们做事，帮我们提效，甚至替代掉一部分原来还要我们自己手动操作的事情，那现在这个状态其实还差得很远哈。

二、现在的问题是，很多事情还是得我们自己动手

虽然我们现在已经把飞书配置好了，但如果真要去操作飞书的话，很多事情最后还是得我们自己动手。

比如我现在想写一篇文章，Hermes 可能能先帮我们把内容整理出来，甚至草稿都写好了，但它并不能直接帮我们在飞书里把文档建好，再把内容写进去。

再比如我想发一条消息、查一下日程、建一个表格，或者搜一份知识库内容，很多时候最后也还是得我们自己回到飞书里面一点一点去操作。

所以这件事现在比较尴尬的地方就在这里。表面上看，我们已经把 Hermes 接入飞书了，但真正到了做事这一步，很多动作还是得我们自己来。

也就是说，现在打通的更多还是聊天这一步，距离真正让 Hermes 帮我们把事情接过去，其实还差得很远。

三、这时候飞书 CLI 才真正有意义

所以我们除了给 Hermes 配置飞书之外，后面还需要把飞书 CLI 也接进来。

因为前面把飞书接上，解决的更多还是 Hermes 能不能在飞书里面出现、能不能在飞书里面和我们聊起来的问题，但真正到了做事情这一步，其实还差一层。

飞书 CLI 补上的，刚好就是这一层。

一层是 context，也就是让 Hermes 不只是停留在聊天入口，而是真的能读到飞书里的消息、文档、表格、知识库、日历、任务这些工作上下文。

另一层是手，也就是它不只是能看，还能真的去创建文档、发消息、查日程、搜知识库、处理表格，把原来还要我们自己手动去点的那些事情继续往前推。

比如拿我自己这种场景来说，我平时本来就会在 AI 工具里先用 Markdown 写技术方案或者文章草稿。如果只是写出来，其实还不够，后面往往还得再手动搬到飞书文档里，代码块、表格、标题层级这些格式还得重新整理一遍。更麻烦一点的话，文档里如果还涉及架构设计、流程图这些东西，很多时候还得再切到别的画图工具里去单独处理。

但如果这一步接了飞书 CLI，很多事情就可以直接往前走了。比如我可以把 Markdown 直接创建成飞书文档，或者根据文档内容继续去补流程图、架构图，这些就不再只是停留在我写完一段内容，后面还得自己再搬一次了。

而且飞书 CLI 的意义也不只是多了一层权限。

应用权限解决的，更多还是能不能接进去的问题，但飞书 CLI 补的，是更适合 Agent 去调用的一层能力。它不是把现有 API 简单换成命令行，而是专门按 AI Agent 的使用方式去设计的。

比如出错的时候，它不是只返回一个报错结果，而是会告诉Agent 下一步怎么修；缺权限的时候，也不是直接卡住，而是会引导补授权；包括命令本身也在尽量优化 token 消耗。

所以它解决的已经不只是 Hermes 能不能连上飞书，而是连上之后，它能不能更稳定、更自然地把事情继续做下去。

四、开始把飞书 CLI 接入 Hermes

前面说了这么多，接下来我们就直接开始动手，把飞书 CLI 真正接入 Hermes。

因为前面 Hermes 虽然已经能在飞书里聊起来了，但如果后面还想让它继续去读文档、查表格、碰日程这些东西，那飞书 CLI 这一层还是得补上。

这一步其实不复杂。

如果我们前面已经把 Hermes 跑起来了，那最省事的方式其实就是直接让 Hermes 自己去装飞书 CLI。我们可以直接把飞书 CLI 的仓库地址丢给它，让它帮你安装：

bash 复制代码

请帮我安装飞书CLI：https://github.com/larksuite/cli

当然，我们也可以自己在终端里装，直接手动执行：

bash 复制代码

npm install -g @larksuite/cli

这里我之前安装过，所以这里就不再贴图了哈。

装完之后，下一步就是把飞书 CLI 配好并授权起来。

先执行初始化配置：

csharp 复制代码

lark-cli config init --new   ## 配置应用凭证（仅需一次，交互式引导完成）

这一步执行之后，终端里一般会弹出一个二维码或者登录链接，我们直接用飞书扫一下就行。

扫完之后，后面会进入 CLI 的初始化配置流程，这时候它会让我们选择是新建一个 CLI 应用，还是直接使用已有的应用。

因为我们前面在安装 Hermes 的时候，其实已经配过飞书应用了，所以这里我就没有再重新建一套，而是直接选了已有的应用。

然后我们直接选择已有应用之后，终端里提示配置成功就ok了，cli界面也会返回配置成功的信息：

配置跑通之后，下一步再去做登录授权：

css 复制代码

lark-cli auth login --recommend  ## 登录授权（--recommend 自动选择常用权限）

这一步执行之后，终端里会提示我们在浏览器里打开一个认证链接，我们直接点开就行。

如果是第一次授权，打开之后一般会看到一个权限确认页面，这时候按流程正常授权就可以了。

我这里因为前面已经授权过了，所以这一步走得会更顺一点，正常授权完成就行。

这里顺手提一下，--recommend 这个参数走的是推荐权限配置，所以会一次把常用权限带上。

如果觉得权限给得太多了，也可以不带 --recommend，自己按需要去选要绑定哪些权限，这样会更灵活一点。

授权做完之后，cli界面会返回我们授权成功的应用权限信息：

我们也可以执行：

lua 复制代码

lark-cli auth status

来查看账号当前已授予的全部权限哈。

对了，这里注意一下，这里还有一个容易漏掉的地方

我这边前面把飞书 CLI 授权跑完之后，去测试的时候发现其实还没有生效。

后面排了一下才发现，Hermes 这里还需要补飞书用户白名单配置，不然前面的授权就算跑通了，Hermes 这边也还是不认。

比如可以在 Hermes 的 env 配置文件最下面加上自己的 open_id：

ini 复制代码

FEISHUALLOWEDUSERS=ou_f072e8875039516834c5ea504bxxxx

如果想直接允许所有用户，也可以这样配：

ini 复制代码

GATEWAYALLOWALL_USERS=true

配置完之后记得重启 Hermes，不然这一步也不会生效。

五、验证一下是不是已经接好了

前面我们把飞书 CLI 配好之后，接下来最好还是实际跑一下，看 Hermes 是不是真的已经能用了。

最直接的方式，就是直接去飞书里的 Hermes 应用机器人里试一句话。

比如我这里直接让它帮我创建一个测试文档，看看它是不是已经有权限正常去调用飞书能力了。

复制代码

帮我创建一个测试文档

如果这一步能正常创建出来，那基本就说明前面的飞书 CLI 配置、授权，还有 Hermes 这边的链路都已经跑通了。

我这里测试下来是可以正常创建的，所以到这里为止，Hermes 和飞书 CLI 这一套就算是真的接好了，后面也就不是只能聊天了，而是真的可以开始结合飞书去做事情了。

当然，创建文档只是最简单的一种验证方式。

如果这一步已经通了，后面其实还可以继续去做很多事情。比如读取一篇飞书文档，再帮我们整理排版后发送到公众号草稿箱；比如创建一个定时任务；再比如查日程、发消息、建表格，这些都可以顺着往下试。

六、最后

虽然我们现在可能也还是刚开始接触 Hermes，但这类东西本来就不是一开始就完全体的，而是可以一步一步去补、一步一步去完善的。

就像这篇里我们接入的飞书 CLI，它带来的变化其实很直接，就是让 Hermes 不再只是停留在对话这一层了。

毕竟 AI 模型都很聪明，但聪明不等于有用。

如果它不知道我们现在在做什么，不知道我们手上有哪些文档、表格、消息、日程，也不知道我们真正想让它替我们做什么，那它很多时候就还是只能给建议。看起来回答得很厉害，但最后真正去点、去建、去发、去操作的人，还是我们自己。

而飞书 CLI 刚好补上了这一步。

它一边给了 Agent 足够多的工作上下文，让它不再是一个只会泛泛回答的模型；另一边也真的把操作飞书这件事交到了 Agent 手里。

这样一来，很多事情就开始变了。以前更多是我们自己去操作飞书，Agent 在旁边给建议；现在慢慢变成了 AI 去操作飞书，我们自己负责判断、负责拍板。

所以我觉得这件事对 Hermes 真正重要的地方，也不只是多接了一个 CLI，或者多打通了一层权限。

而是从这里开始，我们后面就有了更多往下接的空间。只要工具越来越多、权限越来越完整、场景越接越深，Hermes 就不再只是一个能聊天的机器人，而是会越来越接近一个真正能帮我们做事的 Agent。