很多人用 Hermes，已经能让它写代码、改文件、整理资料。
可一到办公流，马上卡住。
会议在飞书里，日程在飞书里，文档在飞书里，多维表格在飞书里，任务清单也在飞书里。Hermes 在终端里很能干，但如果它进不了这些地方，最后还得你自己复制、粘贴、建文档、发消息、补待办。
这一步很折磨。
AI 帮你写好了周报，你再手动发到飞书文档；AI 帮你整理了会议纪要，你再手动拆任务；AI 帮你分析了表格，你再手动回填。前面省下来的时间，后面又一点点花回去了。
飞书官方开源的Lark-cli，解决的就是这个入口问题。
它是 larksuite 团队维护的飞书 / Lark 官方 CLI，目前 GitHub 已经到 10.2k Star。官方介绍写得很清楚：这个工具面向人类和 AI Agent，覆盖消息、文档、多维表格、电子表格、日历、邮箱、任务、会议、Markdown 等核心业务域，提供 200+ 命令和 24 个 AI Agent Skills。
这个项目很适合 Hermes 用户研究。
因为 Hermes 擅长调工具、跑命令、组织任务。飞书 CLI 则把飞书里的办公动作拆成了命令。两者接起来后，Hermes 就不只是在本地回答你，而是有机会真正进入你的办公流。
先搞清楚：它不是一个“发消息脚本”
很多人听到飞书 CLI，第一反应可能是：是不是就能让 AI 发个飞书消息？
范围比这个大很多。
官方列出的能力覆盖得很广：日历可以查看、创建、更新日程，查会议室和忙闲；即时通讯可以发消息、回复消息、创建群聊、搜索消息；云文档可以创建、读取、更新、搜索；多维表格可以管理表、字段、记录、视图、仪表盘和数据聚合；电子表格可以读取、写入、追加、查找、导出；任务可以创建、查询、更新和完成。
这才是它对 Agent 有价值的地方。
Agent 不该只帮你写一段“周报草稿”。更好用的方式是：它读会议纪要，提取待办，写进任务；它查今天日程，整理成早间摘要；它读取表格，分析完再回填；它根据文档内容，生成一份同步消息，先给你预览，再发出去。
以前这些动作都要你在浏览器里点来点去。现在至少有了一个官方命令入口。
飞书 CLI 的设计，对 Agent 很友好
这个项目最值得看的地方，不只是“命令多”。
官方把它做成了三层调用架构。
第一层是快捷命令，通常带 +，适合人和 Agent 直接用。比如查日程可以用：
lark-cli calendar +agenda这类命令参数更短，默认值更智能，输出也更适合 Agent 读。
第二层是 API 命令，对应飞书开放平台的具体端点。你要做更细的动作，就可以往这一层走。
第三层是通用 API 调用，适合确实需要覆盖底层 API 的情况。
这个分层很实用。
新手不用一上来啃开放平台接口。先用快捷命令跑通最常见动作，能查日程、读文档、看任务，再逐步碰更细的 API。Hermes 也不需要每次从接口文档里猜该怎么调，它可以先走最稳的快捷命令。
配套 Skill 才是关键
飞书 CLI 还带了 24 个 AI Agent Skills。
这点比命令数量更重要。
命令只是工具。Skill 负责告诉 Agent：什么时候该用哪个工具，遇到什么输出该怎么处理，权限不足该怎么办，高风险写操作前要怎么确认。
比如 lark-shared 这个 Skill 里就写了很多共享规则：第一次使用要先跑 lark-cli config init；用户身份和机器人身份要分清；遇到权限不足时看缺哪个 scope；写入和删除前要确认用户意图；遇到高风险写操作的确认门禁，不能看到 exit code 10 就自动加 --yes 重试。
这类规则非常适合 Agent。
如果没有 Skill，Agent 可能只会机械地执行命令。执行失败了，它不知道是缺权限、身份错了，还是应该发给用户一个授权链接。
有 Skill 后，它至少知道一套基本流程：先配置，后授权；先读状态，再做写操作；高风险动作先预览，等用户确认后再执行。
这也是为什么这类官方 Skill 很有价值。它不是只给 Agent 一把工具，还给了一份操作说明。
第一步：安装飞书 CLI 和 Skills
先确认本机有 Node.js 和 npm / npx。
官方推荐用 npm 安装：
npx @larksuite/cli@latest install如果需要安装配套 Skills，可以执行：
npx skills add larksuite/cli -y -g这里要看你使用的 Agent 环境是否能自动识别这套 Skills。Claude Code、Codex、Cursor 这类工具通常会更直接。Hermes 用户可以先让 Hermes 读取这个仓库里的 skills 目录，或者按自己当前 Hermes 的 Skill 目录规则接入。
更稳的做法，是直接对 Hermes 说：
请研究并接入飞书官方 CLI：https://github.com/larksuite/cli先不要执行任何写操作。请先读取 README.zh.md 和 skills 目录，确认：1. 安装命令是什么；2. 需要哪些授权；3. 当前环境是否能识别 lark-cli；4. 先用只读命令做最小测试。这样能避免 Agent 一上来就去发消息、改文档。
第二步：初始化配置
安装完成后，先跑配置。
如果你自己在终端里操作，可以用：
lark-cli config init如果是让 Hermes 帮你发起配置，官方给 Agent 模式准备了更合适的命令：
lark-cli config init --new这个命令会输出授权链接。Hermes 要做的事不是替你乱点，而是把链接原样发给你，你自己在浏览器里完成配置。
这里有个细节很重要。
授权链接不要让 Agent 重新拼，不要让它改写，不要让它包装成花哨格式。直接复制原始链接最安全。飞书 Skill 里也专门提醒，看到 verification_url、verification_uri_complete、console_url 这类字段，要把 URL 原样转发给用户。
第三步：登录授权
配置应用后，再登录授权。
最省事的命令是：
lark-cli auth login --recommend它会按推荐范围发起授权。
如果你只想先试日历和任务，可以先按业务域授权：
lark-cli auth login --domain calendar,task如果只想给一个具体权限，也可以按 scope 授权：
lark-cli auth login --scope "calendar:calendar:read"刚开始我更建议从小权限试。
先让 Hermes 读日程、读任务、查文档。确认流程顺了，再考虑发消息、写文档、改表格。办公工具和本地小脚本不一样，飞书里很多内容牵涉团队、客户、项目和权限。先读后写，能少很多不必要的麻烦。
第四步：确认登录状态
授权完以后，先别急着让 Hermes 干活。
先检查状态：
lark-cli auth status这个命令能看到当前登录状态和已授权的 scope。
如果这一步都没通，后面查日程、读文档、发消息都会失败。
然后跑一个最小只读测试：
lark-cli calendar +agenda能看到你的日程，说明最基础的链路通了。
这一步很适合作为第一次验收。
不要一上来就让 Agent 建文档、发群消息、改多维表格。先确认它能读，再让它做写。读操作跑通后，问题一般会集中在权限、身份和参数；写操作直接上，排查会更乱。
Hermes 可以先从这 3 个场景用起来
第一个场景，查日程。
你可以让 Hermes 每天早上先跑：
lark-cli calendar +agenda然后让它把今天的会议、空档、冲突整理成一段简短摘要。
这个场景很适合入门。它只读，不会改东西，风险低。你能很快判断飞书 CLI 是否真的接通。
第二个场景，整理会议纪要。
飞书 CLI 覆盖会议记录、会议纪要产物、妙记总结、待办和逐字稿。Hermes 可以先读取会议相关内容，再帮你提取决策、待办、负责人和截止时间。
这类任务很适合 Agent，因为人最烦的不是读会议纪要，而是把里面的待办拆出来。
第三个场景，维护任务清单。
用 Hermes 整理完会议纪要后，不要只停在一段文字。下一步可以让它把明确的 action item 写成飞书任务。
不过这里建议先让它输出 dry-run 或任务草稿。
你确认负责人、截止时间和任务描述没问题，再让它真正创建。
写操作前，先让它 dry-run
飞书 CLI 适合 Agent，但不能完全放手。
尤其是写文档、发消息、删除文件、改表格这些动作。Agent 有时会理解错对象，也可能拿错 chat id、doc token 或表格 token。
飞书 Skill 里有一个很实用的规则：高风险写操作前，可以用 --dry-run 预览请求。它会打印请求详情，你看过后再决定是否真的执行。
可以给 Hermes 立一条规则：
以后调用飞书 CLI 时，所有写操作先 dry-run。请把将要执行的命令、目标对象和关键参数列出来。我确认后，你再执行真正写入。这条规则很值。
因为飞书不是测试沙盒。一次误发消息、误删文件、误改表格，成本比本地多改一个文件高得多。
身份也要看清：user 和 bot 差别很大
飞书 CLI 支持用户身份和机器人身份。
这两个身份不能混着用。
用户身份适合访问你自己的资源，比如个人日历、云空间文档、邮箱。机器人身份更适合应用级操作，比如以应用名义发消息。
如果你用 bot 身份查自己的日程，结果可能是空的，因为它看到的是 bot 自己的资源。反过来，如果你想让它代表应用发消息，用用户身份也未必符合你的流程。
第一次调试时，建议在命令里明确身份：
lark-cli calendar +agenda --as user发消息类操作如果确实要用机器人，再写成：
lark-cli im +messages-send --as bot --chat-id "oc_xxx" --text "Hello"不要让 Agent 自己猜身份。
身份错了，最常见的表现不是报错，而是“什么都查不到”或“发出去的主体不对”。这种问题特别容易浪费时间。
权限不足时，别让 Agent 硬试
飞书 CLI 的权限报错通常会带出缺失的 scope、后台配置链接或修复提示。
遇到权限不足，不要让 Hermes 连续换命令硬试。
更好的流程是：
如果 lark-cli 返回权限不足，请先停止。请提取缺失的 scope、console_url 和 hint。用简短中文告诉我缺什么权限，并把需要我打开的链接原样发给我。这个动作能少很多无效尝试。
很多飞书问题不是命令错了，只是后台权限没开，或者用户授权范围不够。Agent 如果不懂这个区别，会一直换参数，最后把问题搞复杂。
飞书 CLI 和 Hermes 放在一起，适合做什么
这套组合最适合做“办公流里的最后一公里”。
比如每天早上，让 Hermes 查今天日程，整理出会议、空档和提醒。
比如开完会后，让 Hermes 读会议纪要，拆成待办，先给你确认，再写进飞书任务。
比如每周五，让 Hermes 汇总几份文档和表格，生成周报草稿，创建到飞书文档。
比如项目推进时，让 Hermes 读取多维表格里的任务状态，找出卡住项，整理成同步消息。
这类任务很有价值，因为它们以前都是碎活。
每件事单独看不大，合起来很耗时间。Agent 接上飞书 CLI 后，至少有机会把这些碎活串成流程。
先别急着放进群聊
飞书 CLI 官方安全提示里说得很直接：AI Agent 授权后，会在授权范围内以你的身份执行操作，可能带来数据泄露或越权操作风险。它还建议把对接工具的飞书机器人作为私人对话助手使用，不要随便拉进群聊。
这条建议很现实。
刚开始用，最好只在自己的测试空间、私人对话或小范围文档里试。等你确认它怎么读、怎么写、怎么预览、怎么处理权限，再逐步放进更真实的流程。
尤其是群消息、邮箱、审批、删除文件、改权限这类操作，先不要自动执行。
让 Hermes 先列计划，再 dry-run，再等你确认。
一个最小可用流程
如果你今天就想试，可以按这个顺序来。
# 1. 安装飞书 CLInpx @larksuite/cli@latest install# 2. 安装配套 Skillsnpx skills add larksuite/cli -y -g# 3. 初始化配置lark-cli config init# 4. 登录授权lark-cli auth login --recommend# 5. 查看登录状态lark-cli auth status# 6. 只读测试：查今天日程lark-cli calendar +agenda如果你让 Hermes 来做，就把要求说得更清楚：
请帮我接入飞书官方 CLI。要求：1. 先安装 lark-cli 和配套 skills；2. 配置和授权时，把链接原样发给我，不要改写；3. 完成后先运行 lark-cli auth status；4. 再运行 lark-cli calendar +agenda 做只读测试；5. 任何写操作都先 dry-run，等我确认后再执行。这段提示词很适合作为第一次上手。
它把安装、授权、验证、只读测试和写操作边界都说清了。Hermes 不会一上来乱改东西，你也能一步步看到链路是否通了。
最后说一句
飞书官方 CLI 值得看的地方，也是真正让人有感觉的
是把飞书里的办公动作拆成了 Agent 能调用的命令和 Skill。
Hermes 擅长组织任务和调用工具，飞书 CLI 则打开了日程、文档、表格、任务、会议纪要这些办公入口。
两者接起来后，AI 才更像进入了日常工作流，而不是只在旁边帮你写草稿。
新手先别急着做复杂自动化。
先跑通安装、授权、状态检查和日程读取。确认没问题后，再从会议纪要转任务、文档生成、表格分析这些低风险流程开始。
飞书里的东西很多，也很敏感。
先让 Hermes 会读，再让它会写。这个顺序，会舒服很多。
热门跟贴