本文首发地址 https://h89.cn/archives/612.html
过去一周，我把飞书官方 CLI 接入了我的工作流，试图回答这个问题。结果不是"可以"或"不可以"，而是"能接管一部分，但边界比你想象的硬"。

封面

一、为什么是飞书 CLI

我每天在飞书上花的时间可以分成三块：

  1. 被动响应：群消息、日程邀请、审批提醒
  2. 信息查询：今天有什么会、谁@我了、某个文档在哪
  3. 主动操作：发消息、建日程、回复审批、整理会议纪要

前两块的逻辑是死的——查日程不需要创造力，回"收到"也不需要思考。如果 Agent 能接手这部分，每天能省出 40 到 60 分钟。

飞书官方在 2026 年初开源了 lark-cli，MIT 协议，Go 写的，npm 分发。这不是一个普通的 API 封装工具，它是为 Agent 原生设计的——26 个 Skill、结构化 JSON 输出、OAuth Device Flow 支持后台轮询、每条命令都声明了风险等级和所需权限。这意味着它不是给人类顺手用的，而是给机器可靠调用的。

我试了七天。以下是实测记录。

二、安装：第一道坎不在代码里

安装本身很简单：

npm install -g @larksuite/cli

但装完还不能直接用。lark-cli 的 Skill 系统和二进制是分离的——CLI 负责执行命令，Skill 负责教 Agent 怎么组合这些命令。如果 Skill 版本和 CLI 版本不同步，Agent 会引用不存在的命令或错误的参数格式。

npx skills add larksuite/cli -y -g

这一步官方文档一笔带过，但实际很关键。我第一天就遇到了 _notice.skills 的告警——JSON 输出里多了一段：

{
  "_notice": {
    "skills": {
      "current": "",
      "target": "0.4.0",
      "message": "locally installed skills are out of sync",
      "command": "lark-cli update"
    }
  }
}

current 是空字符串，表示 Skill 从来没同步过。Agent 读到这里会尝试执行 lark-cli update，但如果 npm 权限没配好，这一步会挂。这不是技术难题，是工程链路的摩擦点——Agent 调用工具时，工具本身也需要维护。

三、认证：Agent 登录飞书，比人类更麻烦

要让 Agent 操作飞书，必须先解决"谁的身份"问题。lark-cli 支持两种身份：

  • User：以你的个人账号操作，能看到你所有的群、日程、消息
  • Bot：以应用机器人的身份操作，只能看到它被拉入的群，发言时显示为机器人

初始化配置是交互式的：

lark-cli config init

这一步需要输入 App ID 和 App Secret——得先去飞书开放平台创建一个企业自建应用。对开发者来说不复杂，但对 Agent 来说意味着它无法自己完成冷启动。Agent 不能自己去开放平台填表单、勾权限、下载凭证。

配置完应用凭证，下一步是登录授权：

lark-cli auth login --recommend

这里用的是 OAuth 2.0 Device Flow，流程长这样：

  1. CLI 向飞书请求一个 device_code 和验证链接
  2. 终端输出一行：Open this URL in your browser: https://open.feishu.cn/connect/oauth2/device_confirm?user_code=XXXX
  3. 你（人类）必须在浏览器里打开链接，点击"确认授权"
  4. CLI 后台每 5 秒轮询一次 token 端点，最多 600 次，直到授权完成或超时

我计时了：从执行命令到拿到 token，最快 12 秒，最慢 47 秒。差距不在网络，在我——我多久注意到终端里那一行验证链接，并打开手机浏览器点确认。

Agent 没有手指，也没有浏览器。它可以在后台轮询 token 端点（每 5 秒一次，最多 600 次），但在人工点击确认之前，它只能干等。你可以把链接丢给 Agent，让它"转发给用户"，但点下去的那一下，永远是人类完成。

这就是飞书 OAuth Device Flow 的安全设计：授权链路故意断在浏览器端，不让机器闭环。它不是 bug，却直接划出了 Agent 的能力边界——首次准入永远有一道人工关卡，Agent 跨不过去。

四、身份边界：机器人替我发言，还是我替机器人背锅？

认证通过后，真正的选择来了。同一套命令，加 --as bot 和 --as user，行为和权限完全不同。

我以一个最常见的场景测试：自动回复群消息。

测试 1：以 Bot 身份收发消息

# 订阅实时事件
lark-cli event consume im.message.receive_v1 \
  --as bot \
  --jq 'select(.event.message.chat_type == "group")' \
  --max-events 5 --timeout 60s

Bot 能收到消息的前提是：应用必须被拉入那个群。我在测试群加了机器人应用，然后发了一条"测试"。终端输出：

{
  "ok": true,
  "identity": "bot",
  "data": {
    "event": {
      "message": {
        "chat_type": "group",
        "content": "{\"text\":\"测试\"}",
        "chat_id": "oc_xxxxxxxxxxxxxxxx"
      }
    }
  }
}

收到消息后，让 Bot 回复：

lark-cli im +messages-send \
  --as bot \
  --chat-id "oc_xxxxxxxxxxxxxxxx" \
  --text "收到，正在处理"

群里显示的是应用机器人的头像和名称，所有人一看就知道是机器人在说话。这是 Bot 身份最大的优势——身份透明，不会混淆。

但 Bot 有个硬边界：它看不到被拉进群之前的任何历史消息。你想让 Agent 分析"这个群过去一周讨论了什么"，Bot 无能为力。

测试 2：以 User 身份搜索历史消息

lark-cli im +messages-search \
  --as user \
  --query "项目排期" \
  --format json

User 身份可以搜索我的聊天记录，返回结果包含群聊和私聊。但这里有一个风险：这条消息是以"我"的名义发出去的。

我故意让 Agent 以 User 身份在测试群发了一条"大家好，周报已更新"。群里没有任何标识显示这是 Agent 发的——它和我的手动发言一模一样。同事如果刚好在群里，会以为我本人在线。

这就是 User 身份的核心风险：Agent 获得了你的社交身份，但没有获得你的社交判断力。它不会知道这条消息该不该发、什么时候发不合适、措辞是否符合当下的语境。

身份边界总结

能力 Bot User
实时消息接收 ✅ 必须在群里 ✅ 自动可见所有群
历史消息搜索 ❌ 无权限 ✅ 可搜索
发言身份 机器人（透明） 你本人（易混淆）
Token 稳定性 稳定长期有效 需刷新，依赖登录态
风险范围 仅限所在群 全平台可见范围

结论：群里的自动化交互，用 Bot；需要历史回溯或个人视角的操作，才考虑 User，且必须加 --dry-run 先预览。

五、四个工作流实测

我挑了三个最消耗时间的日常任务，让 Agent 接管。

工作流 1：晨间日程概览

每天早上花 3 到 5 分钟翻看日历确认今天的会。Agent 能不能代劳？

lark-cli calendar +agenda --as user

返回结果：

{
  "ok": true,
  "identity": "user",
  "data": {
    "events": [
      {
        "summary": "产品周会",
        "start_time": "2026-05-22T10:00:00+08:00",
        "end_time": "2026-05-22T11:00:00+08:00",
        "location": {
          "name": "5F 会议室 A"
        },
        "attendees": [
          {"name": "张三", "rsvp_status": "accepted"},
          {"name": "李四", "rsvp_status": "tentative"}
        ]
      }
    ]
  }
}

再用 --format table 输出更易读：

lark-cli calendar +agenda --as user --format table

结果：Agent 可以完美替代这个任务。我把它写成了一个每天早上 8:55 执行的 cronjob，输出通过 jq 过滤成纯文本推送到终端。省 3 分钟。

但有一个前提：日历事件里必须有清晰的标题。如果同事创建日程时标题写"碰一下"，Agent 无法判断这是什么会，只能原样输出。

工作流 2：群消息关键词响应

我在一个运维群里测试：当有人发"告警"时，Agent 自动回复值班表链接。

#!/bin/bash
# watch-alert.sh

lark-cli event consume im.message.receive_v1 \
  --as bot \
  --jq 'select(.event.message.content | contains("告警"))' \
  --timeout 10m \
  | while read -r event; do
    chat_id=$(echo "$event" | jq -r '.data.event.message.chat_id')
    lark-cli im +messages-send \
      --as bot \
      --chat-id "$chat_id" \
      --text "收到告警，当前值班人员：xxx（值班表：https://...）"
  done

实测结果：能跑通，但生产环境不敢直接用。

问题不在技术，在语义。"告警"这个词在中文语境里太宽泛了——可能是真的系统告警，也可能是"价格告警了快买"。Agent 没有上下文理解能力，它只能做字符串匹配。如果有人在群里开玩笑说"我体重告警了"，Bot 也会一本正经地回复值班表。

要解决这个问题，需要引入更复杂的路由逻辑（比如正则匹配 + 发件人白名单），但这已经超出了"快捷命令"的范畴，进入了"写脚本"的领域。

工作流 3：会议纪要整理

这是我最期待的场景。飞书会议的妙记（Minutes）可以生成总结、待办、逐字稿，理论上 Agent 可以自动拉取并整理成文档。

链路是这样的：

# 1. 搜索昨天的会议
lark-cli vc +search --start "2026-05-21" --end "2026-05-22" --as user

# 2. 获取会议纪要
lark-cli vc +notes --meeting-ids "xxx" --as user

# 3. 创建汇总文档
lark-cli docs +create --doc-format markdown --content "# 会议纪要汇总\n..."

实测结果：第三步之前都很顺利，第三步卡住了。

vc +notes 返回的妙记内容往往很长，包含大量口语化的逐字稿。Agent 需要理解内容并提炼结构，这不是 CLI 能解决的——CLI 只负责取数据，理解和归纳需要 LLM 的推理能力。也就是说，CLI 提供了"手"，但没有提供"脑"。

我的实际做法是：CLI 负责取数据，把原始 JSON 喂给 Claude，由 Claude 生成 Markdown 摘要，再由 CLI 创建文档。这是一个人机协作的工作流，不是 Agent 单点接管。

工作流 4：技术问题分析（翻车）

前面三个工作流都是行政类任务。作为开发者，我心里清楚：真正的"班"是写代码、解 bug、做技术判断。这部分 Agent 能接管吗？

我在一个开发群里测试。群里有人丢了一段 Java 异常栈：

java.lang.NullPointerException: Cannot invoke "com.example.OrderService.getStatus()"
because the return value of "com.example.OrderService.findById()" is null
    at com.example.OrderService.process(OrderService.java:147)
    ...

我让 Agent 做三件事：

第一步：结构化录入 bug

lark-cli event consume im.message.receive_v1 \
  --as bot \
  --jq 'select(.event.message.content | contains("NullPointerException"))' \
  --max-events 1 --timeout 30s

Agent 成功提取了异常类型、堆栈顶帧、发言人和群 ID，并写入了多维表格的 bug 追踪表。这一步很顺畅——纯信息搬运，不需要判断。

第二步：搜索历史相似问题

lark-cli drive +search --as user --query "NullPointerException OrderService" --doc-types doc

Agent 找到了之前的一篇排查文档，提到了"空指针常见于未命中缓存时"。这是一个有价值的线索，但接下来它做了一件蠢事：它建议"在 findById 前加 @Cacheable"。这个建议从代码层面看没错，但完全忽略了业务上下文——这个服务其实不应该缓存，因为订单状态是实时变化的。

第三步：尝试定位根因

这里 Agent 彻底失效。它无法：

  • ssh 到服务器查看完整日志上下文
  • 在本地复现这个问题
  • 运行单元测试验证假设
  • 查看监控大盘的实时 QPS 和错误率

飞书 CLI 的操作边界止于飞书平台内部的消息、文档和表格。编码问题的核心——运行环境、调试工具、业务约束——都在这个平台之外。

我意识到一个关键区分：

Agent 能做的是"技术秘书"的工作——收集信息、查资料、格式化输出。
Agent 不能做的是"工程师"的工作——理解上下文、做判断、验证假设。

群里那段异常栈，最终是我本人打开 IDEA、下断点、查数据库、确认是"并发下缓存击穿导致回源查询时数据已被删除"，然后才在飞书文档里写下结论。Agent 全程只能旁观，最多帮我把结论归档到正确的目录下。

这个工作流的实测结果，比前三个更直接地回答了标题的问题：涉及判断力和执行环境的任务，Agent 连边都沾不上。

六、翻不过去的墙

七天测试里，有三类场景 Agent 完全无法自主处理。

1. 权限墙：scope 不够时，Agent 只能报错，无法自愈

飞书开放平台的权限模型很细。比如 Bot 要发消息，需要 im:message:send_as_bot；要以 User 身份发消息，需要 im:message.send_as_user。如果 Agent 调用时缺少某个 scope，CLI 会返回结构化的 JSON 错误：

{
  "ok": false,
  "error": {
    "type": "missing_scope",
    "code": 3,
    "message": "missing required scope(s): im:message:send_as_bot",
    "hint": "run `lark-cli auth login --scope \"im:message:send_as_bot\"` in the background. It blocks and outputs a verification URL — retrieve the URL and open it in a browser to complete login."
  }
}

注意这个 hint：它明确告诉 Agent 需要执行什么命令来修复。但执行这个命令又需要人类去浏览器点授权。Agent 可以读取 hint，但无法自己完成修复。这是一个自愈闭环的失败——Agent 知道怎么治病，但拿不到药。

2. 安全墙：高风险操作必须人类确认

lark-cli 对有副作用的命令标注了风险等级。比如删除邮件、发送消息、删除文档是 write；清空群成员、删除应用是 high-risk-write。

对于 high-risk-write，如果没有 --yes 标志，CLI 会拒绝执行：

lark-cli drive +delete --file-token "xxx" --type "file" --as user
# Error: confirmation required for high-risk-write action

这是安全设计，但直接限制了 Agent 的自主性。真正危险的操作，Agent 无权独自完成。这意味着 Agent 不可能"完全接管"你的工作——那些涉及删除、转账、审批终审的操作，最后一道门永远在人类手里。

3. 认知墙：Agent 没有上下文，只能执行，不能判断

这是最深层的限制。CLI 提供了 200+ 条命令，但选择哪条命令、什么时候不该执行、如何根据语境调整措辞，这些需要真正的理解能力。

比如审批场景。lark-cli approval tasks query 可以列出待审批任务，lark-cli approval tasks approve 可以通过审批。但 Agent 怎么知道哪个该批、哪个该拒？它看不到审批单里的业务内容，只能看到元数据（申请人、申请时间、审批类型）。让 Agent 自动批量通过所有审批，等于把业务判断权交给了随机数。

再比如回消息。Agent 可以检测关键词并自动回复，但它无法判断对方是不是在开玩笑、语气是否带有情绪、回复时机是否合适。社交互动不是 API 调用，它需要对语境的感知。

封面

七、结论：到底替我上了多少班？

七天实测后，我把工作分成三类：

类型 代表任务 Agent 接管程度 原因
纯查询 查日程、查任务、搜索文档 90% 逻辑死，无副作用
结构化操作 按模板发消息、建日程、导出表格 60% 有模板就能执行，但需要人类确认边界条件
判断型操作 审批、回复杂消息、会议决策 10% 需要上下文理解和业务判断

Agent 能替我上的"班"，本质上只有第一类：信息搬运和格式化输出。 这部分确实可观——每天省 40 到 60 分钟是真实的。但第二类和第三类，Agent 只能做"草稿"，不能独立完成。

飞书 CLI 的设计者也意识到了这个边界。它的安全机制（scope 预检、风险等级、内容安全扫描）、双身份系统、结构化的错误提示，本质上都是在说："我可以给 Agent 一只手，但不会给它替你做主的权力。"

所以回到标题的问题：能让 Agent 接管飞书替我上班嘛？

能，但只限于那些不需要你动脑子的班。

参考


本文链接：能让AGENT接管飞书替我上班嘛？ - https://h89.cn/archives/612.html

版权声明：原创文章 遵循 CC 4.0 BY-SA 版权协议，转载请附上原文链接和本声明。

标签: 飞书, AGENT, larksuite, cli, lark-cli

🎓 呈言英语 智能英语学习平台
📚单词学习 🎧听说练习 📖阅读理解 ✏️拼写练习 🌟 AI智能推荐 · 科学记忆曲线
🚀 立即开始免费学习

添加新评论