首页/@claw-academy

"飞书接上 Claude Code 后，数字员工终于有了“办公入口”？"

龙虾学堂
龙虾学堂2026年5月25日

"飞书 CLI、MCP 与 IM 桥接，让数字员工从聊天框走进办公流；但权限、边界和流程设计比接入本身更关键。"

飞书接上 Claude Code 后，数字员工终于有了“办公入口”？

很多小团队第一次试 AI Agent，都会卡在一个很现实的问题上：

不是模型不够强，也不是 prompt 不够漂亮，而是——你到底从哪里叫它干活？

让员工去终端里敲 Claude Code？不现实。
让运营同学复制飞书文档、粘到网页对话框、再把结果贴回群里？太慢。
让老板在十几个 AI 工具之间切换？很快就没人用了。

所以，最近飞书官方 CLI、飞书 OpenAPI MCP，以及一些“把 Claude Code / Codex 接到飞书、微信、Telegram 等 IM 工具”的开源项目一起出现时，我更愿意把它看成一个信号：

数字员工真正要落地，缺的可能不是“大脑”，而是一个大家每天都会打开的办公入口。

这里的“入口”，不是再做一个聊天机器人那么简单。它指的是：员工在飞书里发一句话，Agent 能理解上下文、调用文档/日历/表格/消息等能力，必要时还能转到本地或云端执行任务，并把过程和结果回到团队协作流里。

这件事如果做成，AI Agent 就不再只是个人效率工具，而会开始变成团队里的“可协作角色”。

但先说明边界：目前公开资料能确认的是，飞书官方已经开源/提供了面向 Agent 的 CLI 与 MCP 能力；也存在社区项目把 Claude Code 接入飞书聊天窗口。至于“飞书官方已经完整接入 Claude Code”这类说法，我没有找到足够强的官方证据。本文因此按“公开能力 + 社区实现 + 趋势判断”来分析，不把它写成一个已被官方发布的完整产品。

谁会先痛？不是大公司，而是小团队

大公司谈数字员工，通常会先谈权限体系、流程治理、审计合规、知识库治理。那当然重要。

但真正最早感到痛的，往往是 10 到 50 人的小团队：

  • 运营每天在飞书群里收需求、追进度、整理表格；
  • 产品负责人一边看用户反馈，一边写 PRD、拆任务、催研发；
  • 创始人既要看销售线索，又要盯交付、财务、招聘；
  • 技术同学能用 Claude Code、Codex 把代码和脚本跑起来，但非技术同事很难参与。

这个阶段的团队最大问题不是“没有工具”，而是工具太多、流程太散、信息太碎。

数字员工如果只能待在一个单独网页里，它很难进入真实工作。因为真实工作发生在群聊、文档、日历、任务、表格、审批和代码仓库之间。

飞书这类协作平台的价值就在这里：它不是一个单点工具，而是很多工作流的交汇处。

如果 Agent 能进入这个入口，它就有机会做三类事。

第一类是“读”：读群聊、读文档、读表格、读日历、读任务。
第二类是“写”：写周报、写会议纪要、写任务、写文档、发消息。
第三类是“做”：调用 CLI、MCP、脚本、代码工具，把一个结果真正执行出来。

过去很多 AI 助手卡在前两类：能总结、能生成，但很难稳定完成动作。Claude Code 这类工具的意义，是把“做”的能力放大了：它可以读写代码库、编辑文件、运行命令、自动化开发任务。飞书 CLI / MCP 的意义，则是把“办公系统”变成 Agent 可以调用的工具集合。

当两边接上，数字员工才开始像一个能进入办公室的人，而不只是一个会聊天的网页。

为什么这次值得信？有三个公开信号

1. 飞书正在把自己变成 Agent 可调用的能力层

飞书官方 CLI 的 GitHub 介绍里，明确写到它是官方 Lark/Feishu CLI，由 larksuite 团队维护，面向人类和 AI Agent，覆盖消息、文档、多维表格、日历、邮件、任务、会议等核心业务域，并提供 200+ 命令和 20+ AI Agent Skills。

这句话的重点不是“又多了一个命令行工具”。

重点是：飞书把原本需要人点界面的功能，整理成了 Agent 更容易调用的命令和结构化输出。

对 AI Agent 来说，GUI 是不稳定的：按钮位置会变，页面结构会变，截图识别也容易出错。CLI 和 API 更像是稳定的“工作语言”。如果一个协作平台愿意把自己的核心能力变成 CLI / MCP / OpenAPI，Agent 才有机会可靠地接入。

这也是为什么我认为飞书 CLI 的意义不只是“开发者工具”，而是一个办公平台在为 Agent 时代重构入口。

2. 飞书 OpenAPI MCP 把“接口”包装成模型能理解的工具

飞书 OpenAPI MCP 官方说明提到，它基于已有 OpenAPI，把接口封装并优化成适合 AI 场景的 MCP 工具，让 AI 更自然地理解业务语义并执行数据读取、写入和业务操作。

官方文档也提醒：远程 MCP 目前重点支持 Docs 场景；本地 OpenAPI MCP 则可覆盖更多飞书服务端 OpenAPI 能力，但需要开发者自行部署。

这说明两件事。

第一，飞书确实在做“让 AI 访问办公能力”的基础设施。
第二，这件事还在演进中，不是所有场景都已经成熟到开箱即用。

对小团队来说，这个边界很重要。你可以先把 Agent 用在低风险、高频的文档和信息整理场景，而不是一上来就让它自动审批、自动发客户消息、自动改核心表格。

3. 社区已经开始把 Claude Code 接到 IM 入口

公开 GitHub 上已经能看到一些桥接项目。

例如 qingpingwang/remote-claude-code 的 README 描述：它把 Claude Code 接入飞书，实现本地电脑助手功能；每个私聊/群聊有独立上下文；可通过飞书长连接接收消息；Claude Code 可以执行本地命令、操作文件、做 Git 和脚本类任务。

另一个 op7418/Claude-to-IM-skill 则把 Claude Code / Codex 接到 Telegram、Discord、Feishu/Lark、QQ、WeChat 等 IM 平台，并强调权限控制、会话持久化、日志脱敏等设计。

这些项目不是飞书官方发布的“Claude Code 产品集成”。但它们证明了一件事：

把 IM 当成 Agent 入口，把 Claude Code / Codex 当成执行后端，这条路已经有人在做，而且技术链路是可行的。

这就够了。早期趋势不一定等官方产品完全打包好才成立。很多基础设施变化，都是先从开发者和小团队的拼装式工作流开始。

但别把它误解成“飞书里多了一个 ChatGPT”

如果只是给飞书群加一个聊天机器人，那价值很有限。

真正有用的数字员工，至少要满足四个条件。

第一，它要有明确岗位，不是万能助手

“帮我处理工作”是一个失败需求。

更好的定义是：

  • 运营助理：每天 18:00 汇总群内用户反馈，按产品模块归类，写入多维表格；
  • 销售助理：每晚整理新增线索、补齐客户资料、提醒明日跟进；
  • 产品助理：把会议纪要拆成任务，标注负责人和截止日期；
  • 技术助理：监听需求群里的 bug 描述，生成复现清单和初步 issue；
  • 内容助理：收集群内选题、生成初稿、整理发布 checklist。

岗位越清楚，权限越容易控，效果越容易评估。

第二，它要进工作流，而不是停在对话里

一个能回答问题的 Agent，只是问答助手。

一个能把结果写回文档、表格、任务和群聊的 Agent，才开始进入工作流。

比如运营助理不是只回复“我整理好了”，而是应该：

  1. 读取指定群聊消息；
  2. 提取用户反馈；
  3. 合并重复问题；
  4. 写入指定多维表格；
  5. 在群里发一条摘要；
  6. 标出需要人工确认的条目。

这才是数字员工和普通聊天机器人的分水岭。

第三，它必须有权限边界和人工确认

把 Agent 接入飞书，最容易被忽略的不是技术，而是权限。

飞书里有客户资料、合同、薪酬、内部讨论、未发布产品计划。Claude Code 又具备本地文件读写、命令执行能力。如果没有边界，风险会很快放大。

建议小团队至少做这几层控制：

  • 从只读开始：先让 Agent 总结、检索、归类，不直接写入关键系统；
  • 分环境：测试群、测试文档、测试表格先跑；
  • 分权限：不同 Agent 用不同飞书应用和不同 scopes；
  • 关键动作确认：发外部消息、改重要表格、删文件、跑脚本，都必须人工确认；
  • 留痕：记录谁发起、Agent 做了什么、调用了哪些工具、结果写到哪里；
  • 敏感信息最小化：不要把不必要的客户数据、密钥、财务信息交给 Agent。

如果一个“数字员工”没有审计和确认机制，它不是员工，更像一个无人看管的脚本。

第四，它要能被团队成员共同使用

个人 Agent 很容易变成“只有某个技术同学会用”。

办公入口的价值在于：产品、运营、销售、创始人都已经在飞书里。大家不用学命令行，也不用理解 MCP，只要在合适的群里用自然语言发起任务。

这也是 IM 入口比单独网页更适合早期落地的原因：

  • 它天然有多人协作场景；
  • 它天然有上下文和记录；
  • 它天然能做权限分层；
  • 它天然能把结果通知到人。

Claude Code 在终端里很强，但终端不是团队入口。飞书不是最强 Agent，但它可能是团队最常用的入口。

小团队下一步怎么做？别急着全公司接入

如果你是小团队、创业者、运营或产品负责人，我不建议第一步就做“公司级数字员工平台”。那会把权限、流程、稳定性、预算、合规全都提前引爆。

更现实的路径是：选一个高频、低风险、可验收的岗位，从 1 个群 + 1 个文档/表格开始。

第一步：选一个“窄岗位”

优先选这类任务：

  • 高频重复，每天或每周都发生；
  • 输入主要来自飞书消息、文档、表格；
  • 输出格式稳定；
  • 出错成本可控；
  • 人工复核容易。

比如：

  • 用户反馈周报；
  • 会议纪要转任务；
  • 群消息摘要；
  • 内容选题池整理；
  • 竞品动态收集；
  • 日程冲突检查；
  • 内部 FAQ 检索。

不要一上来做“自动销售跟进”“自动审批报销”“自动修改生产数据库”。那些不是第一步。

第二步：画出最短工具链

一个可用的早期链路大概是：

飞书群 / 文档 / 表格
→ 飞书 CLI 或 MCP 读取信息
→ Claude Code / Codex / 其他 Agent 处理任务
→ 写回飞书文档、表格或任务
→ 群里发摘要和待确认项

如果是纯文档场景，可以优先看飞书 MCP。
如果要覆盖更多办公域，可以研究飞书 CLI。
如果要让团队成员直接在 IM 里唤起本地 Agent，可以参考社区桥接项目，但要特别注意权限和机器环境隔离。

第三步：设计“人机交接点”

数字员工不是越自动越好。

早期最稳的形态通常是“Agent 先做草稿，人最后确认”。

例如：

  • Agent 汇总 20 条用户反馈，人确认分类是否正确；
  • Agent 生成会议任务，人确认负责人和截止时间；
  • Agent 起草客户回复，人确认后发送；
  • Agent 生成脚本，人确认后执行。

你要明确规定：哪些动作可以自动完成，哪些动作必须确认，哪些动作永远不允许 Agent 做。

第四步：用一周验证三个指标

不要只问“它聪不聪明”。

更应该问：

  1. 它每周节省了多少人工时间？
  2. 它的结果有多少需要重做？
  3. 团队成员愿不愿意继续在飞书里叫它？

如果一个 Agent 很炫，但没人想用，那它没有进入工作流。
如果一个 Agent 很朴素，但每天稳定省 30 分钟，它就值得继续迭代。

我对这件事的判断

飞书接上 Claude Code，本质上不是“飞书 + 一个编码工具”的组合。

它背后更大的变化是：

  • 办公平台正在把能力开放给 Agent；
  • Agent 正在从对话工具变成执行工具；
  • IM 正在成为数字员工的前台；
  • CLI / MCP / OpenAPI 正在成为数字员工的手脚；
  • 小团队会先用拼装方式，把这些能力接成自己的工作流。

所以我的判断是：

数字员工不会先以“一个完整产品”的形态普及，而会先以“一个飞书群里的可调用角色”出现。

它可能叫“运营助理”“产品助理”“日报助理”“研发助理”。
它不一定很聪明，但它会读指定信息、做指定动作、写回指定位置、等待人工确认。

当团队开始习惯在群里 @ 一个 Agent 干活时，数字员工才真正有了办公入口。

这也是飞书 CLI、MCP 和 Claude Code 这类工具组合最值得关注的地方。

不是因为它们马上就能替代一个人，而是因为它们让“人如何指挥 AI 工作”这件事，第一次靠近了真实办公室。

UseClaw 持续记录 Claude、Codex、OpenClaw、AI Agent 与数字员工的真实案例、方法和产品化实践。
了解更多：https://useclaw.net/

参考资料与事实边界

  1. 飞书 CLI 官网：https://www.feishu.cn/feishu-cli

    • 用途：确认飞书官方对 CLI 的产品定位。
    • 注：网页抓取正文有限，主要标题和公开页面存在可确认。

  2. larksuite/cli GitHub：https://github.com/larksuite/cli

    • 用途：确认飞书/Lark 官方 CLI 的开源仓库、Agent-native 定位、覆盖业务域、命令数量、Skills、安全设计等。

  3. 飞书 OpenAPI MCP 官方文档：https://open.feishu.cn/document/uAjLw4CM/ukTMukTMukTM/mcp_integration/mcp_introduction

    • 用途：确认飞书 MCP 对 OpenAPI 的封装、AI 场景定位、当前 Docs 支持边界、本地/远程调用模式。

  4. larksuite/lark-openapi-mcp GitHub：https://github.com/larksuite/lark-openapi-mcp

    • 用途：确认官方 OpenAPI MCP 项目、Beta 提示、可与 Claude/Cursor/Trae 等 AI 工具集成、应用权限与 OAuth 配置要求。

  5. Claude Code 官方文档 Overview：https://code.claude.com/docs/en/overview

    • 用途：确认 Claude Code 是可读代码库、编辑文件、运行命令、集成开发工具的 agentic coding tool。

  6. qingpingwang/remote-claude-code GitHub：https://github.com/qingpingwang/remote-claude-code

    • 用途：社区项目案例，证明“飞书机器人接入 Claude Code、本地命令/文件操作、群聊/私聊上下文管理”的实现思路。

  7. op7418/Claude-to-IM-skill GitHub：https://github.com/op7418/Claude-to-IM-skill

    • 用途：社区项目案例，证明把 Claude Code / Codex 接入多种 IM（含 Feishu/Lark）并做权限确认、会话持久化、日志脱敏的方向。

事实边界

  • 没有找到强官方来源证明“飞书官方已经完整接入 Claude Code”。本文已降级为“公开能力 + 社区实现 + 趋势观察”，避免写成官方联合发布。
  • 飞书 OpenAPI MCP 官方文档显示远程 MCP 当前主要支持 Docs 场景，更多能力仍在演进；文章中已避免承诺所有飞书能力都可开箱即用。
  • 社区桥接项目的稳定性、安全性、维护状态需要读者自行评估，不能等同于官方能力。
  • 文章涉及 Claude Code 本地执行命令/文件操作，已加入权限、人工确认、审计和敏感数据最小化提醒。
#AI Agent#Claude Code#飞书#数字员工#自动化