把“帮我整理未读邮件并把摘要发到项目群”交给 AI 时，真正困难的不是理解中文，而是知道先查什么权限、该用用户身份还是机器人身份、哪条命令会写入数据。larksuite/cli 的 Agent Skills 正是在补这层操作知识。

Skill 不是权限，而是操作说明书

CLI 提供能做事的命令，Skill 告诉 Agent 什么时候调用、参数怎样填、失败后往哪里检查。

官方 README 列出的 Skills 覆盖日历、消息、文档、云空间、电子表格、多维表格、邮箱、任务、知识库、会议等域。它们会共同加载 lark-shared，统一处理应用配置、用户与机器人身份、scope、安全提醒和结构化输出。

我会这样试：先让 Agent 回答“当前是谁登录、有哪些权限”，确认它能调用 auth status --json --verify，再交付具体业务任务。

一句自然语言怎样走到飞书里

1. Agent 根据请求选择 lark-mail、lark-doc 或其他 Skill。
2. Skill 要求检查身份、所需 scope、目标 URL 或 token。
3. Agent 运行对应的 lark-cli 快捷命令。
4. CLI 调用飞书开放平台，并把成功或错误写成结构化结果。
5. Agent 根据返回值继续处理，或把缺失权限链接交给本人确认。

读和写不要揉成一步

我更愿意把任务拆成“读取—生成计划—预览—执行”。查日程、读文档和看未读邮件先只读；发消息、改正文、写单元格再单独确认。可能产生副作用的命令先加 --dry-run，高风险写操作遇到确认门禁时，不让 Agent 自动补 --yes。

三个适合入门的 Agent 工作流

日程助理

读取当天安排、比较多人忙闲，再给出会议候选时间。

文档协作

创建初稿、读取划词评论、按意见修改，并保留可复查的改动。

会议信息整理

读取会议记录与妙记，把待办、决策和产出写回文档或表格。

我的使用边界会写在任务里

• 只申请当前任务需要的 scope，不默认开全量权限。
• 个人资源用 --as user，通知机器人等场景再考虑 --as bot。
• 把接入 CLI 的机器人当私人助手，不随意拉进群聊开放给他人。
• 检查结果用 ok == true 或进程退出码判断，不沿用旧 OpenAPI 的 code == 0 习惯。

Skills 让 AI 更懂得怎样操作，但不会消除模型幻觉或越权风险。好的用法不是把飞书完全交出去，而是让 Agent 在清楚的身份、scope、预览和确认规则内替你完成重复工作。