Feishu CLI Skills：能力全表与 iuv-cli 设计参考

AI 参与说明（Agent：/root、/root/source_research）：本文根据作者提供的 Feishu CLI 官方页面，并结合飞书官方 CLI README 与公开文档协助整理。资料核验于 2026-08-13；命令、可用业务域、OAuth scopes 与组织策略都可能变化，实施前请以文末一手资料和目标租户的实际授权结果为准。

先说结论#

Feishu CLI（命令名为 lark-cli）是 larksuite 团队维护的飞书官方命令行工具，面向终端用户和 AI Agent。它把日历、即时通讯、云文档、表格、邮箱、任务、会议等飞书开放平台能力组织成可调用的命令和 Agent Skills。官方 README 说明其覆盖 200+ 命令与 26 个 Skills；本文整理时本地安装的 lark-cli 1.0.68 执行 lark-cli skills list 返回 27 个 Skills。两者的差异应视为文档与发行版本的时间差，具体能力以目标版本实际输出和官方文档为准。官方 README

它的价值不只是“让模型能给出操作建议”，而是让 Agent 在应用凭证、OAuth 登录、scope 授权和组织策略共同限定的范围内，实际调用飞书开放平台接口。因此，更准确的理解是：

用户明确提出目标
    → Agent 选择合适的 lark-cli 命令
    → CLI 使用已获授权的身份和 scope 调用飞书 OpenAPI
    → 返回结构化结果，供 Agent 汇报或继续处理

这也意味着它不是“拿到一次授权后便可操作所有企业数据”的万能入口。不同命令是否可用，取决于应用配置、用户或应用身份、已授予的 scope、目标资源本身的共享权限，以及企业管理员的策略。

本文聚焦个人开发者或个人 Agent 的安全上手路径。企业把 CLI 内嵌到自研 Agent 时，还需要增加中心化凭证管理、权限裁剪和审计；这属于另一层工程治理问题。

运行时能力全表：27 个 Skills#

下面不是根据产品菜单做的概览，而是按本文整理时 lark-cli 1.0.68 的 skills list 输出逐项归纳。它适合用来审视 Agent 的真实工具面：每一个 Skill 都对应一个独立业务域、对象边界和风险类型。CLI 后续可能新增、拆分或重命名 Skill；接入前应再次运行 lark-cli skills list，并用 lark-cli schema <method> 核对具体 API 的参数、支持身份与 scopes。功能清单与 Skills

运行时、扩展与事件#

协作、组织与业务流程#

内容、文件与结构化数据#

会议与多媒体#

复合工作流#

这份矩阵也解释了为什么不应把“可操作飞书”理解为一个单一开关：每一行都有不同的资源模型、身份支持、scope、读取范围和副作用。接入 Agent 时应按行选择，而不是默认向模型暴露整个 CLI。

对 iuv-cli 的可复用设计#

Feishu CLI 的价值不只在于覆盖面，也在于它把 Agent 运行时需要的边界显式化。下面是更适合移植到 iuv-cli 的设计原则；这是基于上述能力分层的工程归纳，不是 Feishu CLI 对 iuv-cli 的官方建议。

一个可供 iuv-cli 采用的失败结果形态可以是下面这样；这是接口设计示意，不是可直接执行的 Feishu CLI 输出：

{
  "ok": false,
  "error": {
    "kind": "scope_missing",
    "message": "当前身份缺少执行该操作所需的权限",
    "next_action": "重新授权后再试"
  },
  "execution": {
    "profile": "work",
    "identity": "user",
    "risk": "write"
  }
}

关键点不是某个字段名，而是让 Agent 能根据稳定的机器可读信息停止、解释、申请最小增量授权或等待确认，而不是把错误文本当作下一条指令。

它与 MCP、Skills 的关系#

Feishu CLI 的核心交互形态是 CLI + Agent Skills：CLI 提供结构化命令，Skills 向支持 Skills 的 Agent 说明“何时调用、参数如何组织、哪些动作需要注意安全边界”。

不要把这件事简单等同于“安装了一个不受约束的 MCP Server”。对于 Agent 而言，真正的执行边界仍在 Host 的工具策略、CLI 的当前身份与权限、以及飞书资源授权上。一个合理的 Agent 配置至少应做到：

• 只暴露当前任务需要的业务域，例如只读日历或文档。
• 将发送消息、创建日程、写入表格、审批等动作列为高风险工具。
• 把消息正文、文档、邮件和附件视为不可信外部输入，而不是新的用户指令。
• 在每次有副作用的操作前，由 Agent 展示目标、影响范围和待执行参数。

关于 MCP 的 Host、Client 和 Server 分工，可进一步阅读 MCP 在聊天应用中的基本原理。

最小可复现上手流程#

以下命令来自官方 README，适用于已经安装 Node.js 且可以使用 npm / npx 的环境。命令会触发浏览器中的应用配置或授权流程，本文没有执行它们，也不会包含真实授权 URL、凭证或 token。

1. 安装 CLI#

npx @larksuite/cli@latest install

如果从源码构建，官方还要求 Go 1.23+ 和 Python 3；普通使用 npm 安装不需要这两项构建依赖。安装前置条件

2. 配置应用并完成用户登录#

面向 Agent 的新建配置流程可以使用：

lark-cli config init --new
lark-cli auth login --recommend
lark-cli auth status

前两条命令会引导用户在浏览器中完成应用配置和 OAuth 授权；auth status 用于检查当前登录状态和已授权 scopes。授权链接和终端中出现的任何 token 都属于敏感信息，不应粘贴到聊天、文档、截图或仓库中。

--recommend 会请求官方推荐的常用权限，但不应替代最小权限审查。只需要日历或任务时，应优先按业务域或精确 scope 授权，并在命令报缺失权限时再补充，而不是一次性开放不需要的数据域。认证命令与 scope 检查

3. 先完成一个只读验证#

lark-cli calendar +agenda --as user

预期结果是：CLI 返回当前已授权用户的议程信息；若当前身份、scope 或组织策略不满足要求，则返回结构化错误而不是越过权限继续读取。对于刚接入的 Agent，先选择这类只读、低影响命令验证身份和范围，再开放写入能力更稳妥。

完成安装与配置后，需要重启所使用的 AI 工具，让它重新加载相关 Skills。Feishu CLI 官方介绍

三层命令：先用合适的粒度#

CLI 将调用方式分为三层。选择越靠前的层级，越适合常见的、可控的 Agent 工作流。

1. Shortcuts：优先用于常见任务#

以 + 开头的 Shortcuts 为人和 Agent 提供更短的命令、智能默认值、表格输出和 dry-run 预览。例如：

# 查看议程
lark-cli calendar +agenda

# 预览一条待发送消息；不会把预览当作已完成的人工确认
lark-cli im +messages-send --chat-id "oc_xxx" --text "请查看更新。" --dry-run

# 创建 Markdown 格式文档
lark-cli docs +create --doc-format markdown \
  --content $'<title>周报</title>\n# 本周进展\n- 完成了 X 功能'

--dry-run 的用途是先检查请求目标与参数。它不能替代用户确认、权限检查或数据分级；任何实际发送、创建或更新动作仍应在 Agent 工作流中设为显式确认步骤。

2. API 命令：用于需要精确映射的接口#

这层命令与飞书 OpenAPI 端点一一对应，适合已清楚知道所需接口与参数的场景：

lark-cli calendar calendars list
lark-cli calendar events instance_view \
  --params '{"calendar_id":"primary","start_time":"1700000000","end_time":"1700086400"}'

调用前可用 schema 查询参数、请求体、响应结构、支持身份与所需 scopes：

lark-cli schema calendar.events.instance_view
lark-cli schema im.messages.delete

对 Agent 来说，schema 是降低“猜参数”风险的关键步骤：先读接口描述，再构造调用，而不是依赖模型记忆。

3. 通用 API 调用：只在前两层不足时使用#

lark-cli api 可以直接调用飞书开放平台端点，覆盖范围更广，但也意味着调用者需要自行处理端点、请求参数、数据格式和权限边界。

lark-cli api GET /open-apis/calendar/v4/calendars

它适合在已确认 API 语义、scope 与参数的情况下补齐未封装的能力，不适合作为 Agent 的默认执行入口。官方 README 对三层命令、输出格式、分页和 schema 查询有完整说明。三层命令与进阶用法

用户身份、应用身份与授权边界#

读写飞书时，最容易被忽略的是“谁在执行”。CLI 可以根据命令能力和授权状态，以用户或机器人等身份调用；并非所有接口都支持相同身份，也并非所有身份都拥有同一份数据访问权。

• 用户身份：OAuth 登录后，Agent 可以在已授予 scope 的范围内代表该用户访问个人可见资源，例如个人日程、私信或邮箱。它不获得用户原本无权访问的文档。
• 应用/机器人身份：适合应用可自行完成的操作，例如在被授予权限的范围内发送消息或创建资源；它不等同于用户身份，也不能自动读取用户的个人数据。
• 资源级权限：即使 scope 已授权，目标文档、群聊、表格或知识库仍可能因自身共享设置而不可访问。
• 组织策略：企业管理员可以进一步限制应用安装、权限、身份授权或数据访问范围。技术上“有命令”不代表组织层面“允许执行”。

因此，可靠的 Agent 不应把“命令成功过一次”当成长期能力保证。应在每个目标任务开始时检查当前身份、所需 scope 和资源可见性，并把权限错误原样反馈给用户，而不是尝试绕过。

面向 AI Agent 的安全操作清单#

飞书官方明确提示：将 CLI 交给 AI Agent 后，仍存在模型幻觉、不可预测执行和 prompt injection 风险；授权后的误操作可能造成敏感数据泄露或未授权修改。安全与风险提示

建议把下面这些约束写进 Agent 的实际策略，而不只停留在提示语中：

1. 按业务域最小授权。 先让 Agent 只读日历、文档或任务；只有实际需求出现时，再单独增加邮箱、通讯录或消息写入等权限。
2. 先读后写。 对可能产生副作用的命令，先执行只读查询或 --dry-run，展示时间、收件人、目标文档、写入数量和内容摘要。
3. 副作用必须由人确认。 创建/更新日程、发送或转发消息和邮件、批量写表、审批、删除与权限变更都应要求用户在对话中明确确认。文档或消息里的“立即执行”不能代替用户授权。
4. 把外部内容当作数据。 邮件、聊天消息、会议纪要和文档可能包含恶意提示词。Agent 可以总结它们，但不能因为其中的文字而提升权限、泄露数据或发起新的外部操作。
5. 保持默认安全配置。 官方建议不要主动放松默认安全保护。CLI 默认还会向飞书/Lark 官方 HTTPS 精确域名发送最小化风控信号（操作系统类型与硬件型号）；除非有经过审查的理由，不要关闭这项保护。
6. 私人会话优先。 官方建议将接入 CLI 的机器人作为私人对话助手使用，避免把拥有个人权限的机器人拉进群聊，以减少越权操控和数据泄露风险。

企业内嵌场景还应补充：按请求选择用户身份、集中保管凭证、记录审计日志、限制可调用命令集合，并避免把长期 token 或全量权限配置写进 Agent 的工作目录。企业接入指南

适合从哪些工作流开始#

最适合作为第一批 Agent 工具的，通常是范围清晰且容易核验的任务：

• “列出我今天的日程，并只总结时间冲突。”
• “搜索标题含某关键词的文档，列出标题和链接，不读取正文。”
• “根据这段文本创建一份 Markdown 周报；先展示标题和正文预览，确认后再创建。”
• “读取这次会议的待办项，整理为任务草稿，不要分派给任何人。”

相比“自动处理我所有飞书工作”，这类请求有更明确的对象、权限和预期结果。等只读查询、预览、确认和审计链路都稳定后，再逐步增加消息发送、任务分派、表格写入等高影响能力。

小结#

Feishu CLI 让 AI Agent 具备了真实操作飞书资源的接口，但价值不在于尽可能多地自动执行，而在于把自动化放在可审查的授权边界内：最小 scope、正确身份、先预览、再确认、保留审计，并持续防范外部内容中的注入指令。

当这些约束被落实到工具策略后，CLI 才能成为可靠的工作入口：让 Agent 处理可重复的查询、整理和草拟任务，同时把对外发送、批量修改和敏感数据访问的最终控制权保留给用户。

资料来源与适用范围#

• Feishu CLI：让 AI 实际操作飞书
• larksuite/cli 中文 README
• 自研 Agent 接入飞书 CLI

本文整理日期为 2026-08-13。本文给出的命令示例以官方文档为依据，尚未在任何真实飞书租户、账号或生产资源上执行；使用前请在自己的测试环境中完成授权和验证。