在上一篇文章中，我们已经成功完成了Hermes的安装，并配置了其与飞书的消息网关。这实现了Hermes与我们在飞书应用内的基础对话功能。如果仅仅是为了初步体验AI对话，这一步确实已经足够。
然而，如果我们部署Hermes的目标更为深入——不仅是“聊天”，而是希望它能真正成为工作助手，自动化处理任务、提升团队协作效率，甚至替代部分重复性手动操作——那么当前的状态显然还有巨大的提升空间。
当前困境：操作仍需手动介入
尽管Hermes已经成功接入飞书，但在处理飞书内部的具体业务时，许多关键步骤仍然离不开人工手动操作。
例如，撰写一份项目报告。Hermes或许能够协助搜集资料、生成内容大纲，但它无法直接在飞书云文档中创建新文件并自动填充格式化内容。同样，发送群组通知、查询团队日程、创建多维表格或在知识库中检索信息，这些操作在目前阶段，大多仍需我们回到飞书客户端界面手动完成。
这就形成了一个效率瓶颈：表面上，通信链路已经打通；但在实际执行层面，大量任务的“最后一公里”仍需人工跑通。简而言之，目前实现的更多是“信息交互层”的连通，距离让Hermes真正“上手做事”的“业务执行层”，还有关键一步需要跨越。
飞书CLI的核心价值
正因如此，在完成基础配置后，接入飞书命令行工具（CLI）就显得至关重要。消息网关主要解决了Hermes“能否接收和回复消息”的问题；而飞书CLI，则补全了Hermes“能否感知并操作飞书内业务数据”的核心能力。
飞书CLI带来的能力飞跃主要体现在两个维度：
第一是丰富的上下文感知能力。它使Hermes能够突破聊天窗口的限制，直接读取飞书环境中的消息历史、云文档、多维表格、知识库条目、日历事件以及待办任务等。这意味着AI能够理解你当前的工作全貌，而不仅仅是单次对话。
第二是强大的自动化执行能力。Hermes从此不再是“旁观者”或“建议者”，它可以主动执行操作：创建并编辑文档、向指定群聊或人员发送消息、查询及管理日程、在知识库中进行智能搜索、处理表格数据等。它将那些需要手动点击的流程自动化地推进下去。
以一个典型的内容创作流程为例：许多开发者习惯先用Markdown在本地或AI工具中起草技术文档。如果流程止步于此，后续仍需手动将内容复制到飞书文档，并重新调整代码高亮、表格、标题等格式。若涉及技术架构图，还需切换到绘图工具另行制作。
而接入了飞书CLI的Hermes，可以让整个流程无缝衔接：Markdown草稿能一键转换为格式完好的飞书云文档；甚至可以根据文档内容，指令AI自动生成并插入对应的架构示意图。工作流得以连贯、自动化，避免了在不同工具间频繁切换和搬运数据的低效操作。
更重要的是，飞书CLI的设计并非简单的API封装。它是专为AI智能体（Agent）工作模式而构建的能力层。它在设计上充分考虑了Agent的交互特性：
- 当操作出错时，它不仅返回错误代码，还会提供清晰的修复指引；
- 当权限不足时，流程不会直接中断，而是引导Agent或用户完成授权；
- 其命令结构也经过优化，能有效控制交互过程中的Token消耗，提升效率与经济性。
因此，它解决的不仅是“能否连接”的技术问题，更是“连接之后，能否稳定、智能且高效地持续完成任务”的体验问题。
实战教程：将飞书CLI接入Hermes
理论阐述完毕，现在进入核心的实操环节，一步步将飞书CLI的能力赋予Hermes。整个过程清晰直接。
如果你已经在本地或服务器上成功运行了Hermes服务，最便捷的方式是直接让Hermes自行安装飞书CLI。只需在对话中提供仓库地址即可：
请帮我安装飞书CLI：https://github.com/larksuite/cli当然，你也可以选择通过系统终端进行手动安装：
npm install -g @larksuite/cli安装完成后，下一步是关键的身份配置与授权。
首先，执行初始化配置命令：
lark-cli config init --new ## 配置应用凭证（此步骤通常只需执行一次，CLI会进行交互式引导）执行后，终端通常会显示一个二维码或登录链接。请使用你的飞书App扫描登录。随后，CLI会引导你完成初始化流程，系统将询问是“创建新应用”还是“使用现有应用”。
由于在部署Hermes时，我们已经创建并配置过一个飞书应用，此处建议直接选择“使用已有应用”，以避免应用重复和管理混乱。选择成功后，终端会显示配置成功的信息。
配置成功后，紧接着进行登录授权，以获取操作权限：
lark-cli auth login --recommend ## 登录授权（--recommend参数会自动选择推荐的常用权限集）执行后，终端会提示你在浏览器中打开一个认证链接。首次授权需要在飞书权限页面进行确认，按提示完成即可。使用--recommend参数可以快速启用一套常用的权限，提升授权效率。如果你需要对权限进行更精细化的控制，也可以不使用此参数，手动勾选所需的具体权限范围。
授权完成后，你可以通过以下命令查看当前账号已授予的所有权限状态：
lark-cli auth status这里有一个至关重要的细节容易被忽略：完成飞书CLI的授权后，在飞书中测试时，你可能会发现Hermes并未成功调用CLI功能。这通常是由于缺少用户白名单配置所致。你需要在Hermes的环境配置文件（.env）末尾，添加你的飞书用户Open_ID：
FEISHU_ALLOWED_USERS=ou_f072e8875039516834c5ea504bxxxx如果你希望允许所有授权用户访问（适用于测试环境），可以配置：
GATEWAY_ALLOW_ALL_USERS=true请务必注意：修改完环境配置后，必须重启Hermes服务，新的配置才会生效。
验证接入是否成功
完成上述所有步骤后，强烈建议进行一次实际的功能测试，以验证Hermes调用飞书CLI的整个链路是否通畅。
最直接的方法是在飞书的Hermes机器人对话窗口中，发送一个具体的操作指令进行尝试。例如，让它创建一个简单的测试文档：
帮我创建一个名为“功能测试”的飞书文档如果Hermes能够成功接收指令，并在你的飞书云文档中创建出对应的文档，那么基本可以确认：飞书CLI的安装、配置、授权以及Hermes的调用链路均已成功打通。这标志着Hermes正式从“聊天机器人”升级为具备“操作能力”的智能工作助手。
当然，创建文档只是一个起点。一旦核心链路验证通过，你就可以探索更多自动化场景：例如，让Hermes读取一篇飞书文档并自动排版后同步到公众号后台、创建周期性的团队例会日程、向项目群发送每日汇总消息、或者自动整理多维表格中的数据等。可能性的大门从此打开。
结语
部署和深度集成像Hermes这样的AI智能体工具，往往不是一个一蹴而就的动作，而是一个逐步深化、持续扩展其能力边界的过程。正如本文所详细讲解的飞书CLI接入，它带来的改变是根本性的：将Hermes的能力半径从单纯的“对话与建议”，实质性扩展到了“感知与操作”。
大型语言模型本身虽然拥有强大的推理和生成能力，但“聪明”并不直接等同于“实用”。如果AI对我们当前的工作上下文一无所知——不知道我们手头有哪些待办事项、项目文档进展到哪一步、团队日程如何安排——那么它大多时候只能给出泛泛的建议。回答可能看似精彩，但最终执行操作、点击按钮、搬运数据的人，依然是我们自己。
飞书CLI正是为了填补这一关键缺口而设计。它一方面为AI Agent提供了真实、丰富的工作环境上下文，使其脱离“空想”，能够“脚踏实地”；另一方面，也将操作飞书各类功能的“双手”直接交给了Agent。
于是，人机协作的模式开始发生转变：以往是我们手动操作工具，AI从旁辅助；未来将逐渐演变为AI主动操作工具执行常规任务，而我们则专注于更高层次的决策、审核与创意工作。因此，为Hermes接入飞书CLI，其意义远不止是增加了一个工具或打通了一层API权限。
更重要的是，它为我们开启了一条通往更深层次、更广范围业务自动化的路径。随着连接的业务系统越来越多、获取的权限越来越完善、集成的场景越来越深入，Hermes将逐渐蜕变，从一个“会说话的机器人”，成长为一个真正能理解需求、感知环境并执行任务的“智能业务助手”。
