---
title: 给 Coding Agent 接飞书：一个 Skill，按需加载
description: Lark CLI Progressive Skill 把飞书能力收成一个入口，任务来了再加载对应领域指南
---

如果你想让 Coding Agent 帮你查飞书日程、找文档、发消息，最容易踩的坑不是配置 OAuth。

是上下文。

官方 Lark CLI 把能力拆成很多领域 Skill：日历、IM、文档、云盘、Base、审批、任务、邮件、知识库，甚至会议纪要和实时事件。它们当然都很有用。但绝大多数请求只会碰其中一两个。

于是有个很朴素的问题：

> 我只是想问“今天有什么会”，为什么 Agent 要先背完云盘权限、审批流和多维表格的说明？

[Lark CLI Progressive Skill](https://github.com/OiAnthony/lark-cli-progressive-skill) 的答案很直接：只让 Agent 发现一个 `lark` Skill，其余二十多个领域指南留在包里，等任务真的命中时再读。

这不是阉割版 CLI。能力还在，只是不在启动时挤进上下文。

## 安装方式

推荐直接把这段 Prompt 交给 Coding Agent。它会完成单一 `lark` Skill 的全局安装；若机器上已有旧版 `lark-*` Skills，只迁移来源可验证的官方项。

```text
请阅读 https://github.com/OiAnthony/lark-cli-progressive-skill 的 README，并按其中推荐流程为我完成全局安装。使用单一的 lark Skill；如发现旧版 lark-* Skills，先检查并只迁移来源可验证的官方项，保留未知或第三方项。不要安装上游完整 Skill bundle。
```

想手动安装时，仍按这个顺序执行：

```bash
npm install -g @larksuite/cli@latest
npx skills add OiAnthony/lark-cli-progressive-skill --skill lark -g -y
```

不要运行 `lark-cli update`，也不要和官方完整 Skill bundle 混装。前者会重新装回完整 bundle，后者会把按需加载省下来的上下文又占回来。

## 用起来是什么感觉

你不需要先研究飞书 API，也不用记住是 `lark-calendar` 还是 `lark-vc`。

直接说人话：

```text
列出我今天的日程，找出空闲的 30 分钟，并约一个产品评审会。
```

Agent 会先读日历领域的指南，再按当前 `lark-cli --help` 和命令 schema 执行。需要创建会议室时，还是日历。需要查已经结束的会议纪要，才转到会议领域。

再比如：

```text
在项目群里找上周提到过的发布计划，把相关文件下载到当前目录。
```

这里才会依次用到 IM 和 Drive。不是一上来把它们和 Base、Mail、OKR 一起装进脑子里。

这种路由看起来小，实际决定了 Agent 接下来会不会稳定。领域边界被写清楚后，它知道“待办”该去 Task，“审批待办”该去 Approval，“下周会议”该去 Calendar，“会议产物”该去 VC。少靠猜，少走错服务。

## 它解决的不是安装，而是默认成本

很多工具的安装说明会把“功能完整”当成“默认全加载”。对人类 IDE 这没有太大问题，对 Context 有上限的 Coding Agent 却是持续税。

这个项目把结构反过来：

```text
用户请求
  ↓
lark Skill 判断领域
  ↓
只读取当前任务需要的 GUIDE.md
  ↓
根据实时 CLI help 和 schema 执行
```

有两个细节很对味。

第一，领域指南是内置快照，不需要每次需求来了再联网安装一个 Skill。第二，执行时仍要求先看当前 CLI 的 `--help` 和 schema，不把文档里的历史参数当事实。

前者减少装配摩擦，后者避免 Agent 一本正经地调用过期参数。

## 该装给谁

如果你已经把 Coding Agent 当成飞书里的操作员，这个包很合适：查日程、搜群消息、整理文档、上传文件、维护 Base、创建任务，都是它的日常工作。

如果你只是偶尔打开飞书网页，或者不使用支持 Skills 的 Agent，就没必要为了这个再加一层工具。

它也不适合和官方完整 Skill bundle 混装。两套同时存在，按需加载的意义就没了。

## 账号和副作用，还是人说了算

首次连接账号时仍需要完成应用配置和授权。这是正常的。Skill 解决的是 Agent 如何理解和调用飞书，不会绕过你对账号、scope 和外部操作的控制。

项目对发送消息、删除资源、改权限、审批等有副作用的动作保留确认边界，也明确不让 Agent 从聊天内容或 CLI 输出里“捡”到授权。

我喜欢这种收敛：一个入口，按需拿说明，实时确认命令，再把副作用留给人确认。

如果你正在给 Coding Agent 接飞书，先试试这个。别让它为了查一场会，先把整个飞书都背下来。