飞书 CLI：不是工具，而是 Agent 的神经系统
就在刚刚，我在 GitHub 上刷到一个项目——飞书官方开源的 CLI 工具 larksuite/cli。说实话，看到的第一眼我就坐不住了。
这不是一个简单的命令行工具。它覆盖了飞书的 11 个业务域、200+ 命令、19 个 AI Agent Skills，从日历、消息、文档到多维表格、邮件、会议纪要，几乎把整个飞书的能力都搬到了命令行里。
更关键的是它的设计理念——Agent-Native Design。它不是给人用的 CLI 然后碰巧 Agent 也能用，而是从一开始就为 AI Agent 设计的。每个命令都经过真实 Agent 测试，参数简洁、智能默认值、结构化输出，最大化 Agent 的调用成功率。
我为什么觉得这件事意义重大？因为飞书在做的事情，正是我在之前那篇《当微信开放 Agent 接口：企业软件的 Agent-First 转型思考》里预测的趋势——企业软件正在从”给人用的 UI”转向”给 Agent 用的接口”。
三层架构的深意
飞书 CLI 的三层架构设计很有意思：
- Shortcuts（快捷命令）：
+前缀，人类和 AI 都友好，智能默认值，表格输出 - API Commands（API 命令）：从飞书 OAPI 元数据自动生成，100+ 命令 1:1 映射平台端点
- Raw API（原始 API）：直接调用任意飞书开放平台端点，覆盖 2500+ API
这意味着什么？飞书把自己变成了一个可以被 Agent 完整操作的平台。
以前你要操作飞书，只能打开浏览器或者 App，点来点去。现在一个 Agent 可以通过 CLI 完成几乎所有操作——查日历、发消息、创建文档、读写表格、管理任务、处理邮件、查询会议纪要。
这让我想到我在那篇文章里写的一句话：UI 从”必需品”变成”可选项”。飞书正在用自己的产品验证这个判断。
Agent2Agent：不是科幻，是正在发生的现实
飞书 CLI 给我带来的最大启发，其实不是”Agent 可以操作飞书”，而是更深一层的东西——Agent2Agent 协作。
让我描述一个场景：
[日程 Agent] → 查看飞书日历 → 发现下午3点有产品评审会
↓
[文档 Agent] → 飞书 CLI 读取会议文档 → 提取待讨论的议题
↓
[数据 Agent] → 从飞书多维表格拉取相关数据 → 生成分析报告
↓
[消息 Agent] → 通过飞书消息把报告发给参会人 → 附上会议链接
↓
[会议 Agent] → 会后自动获取会议纪要 → 提取 Action Items → 创建飞书任务
这个流程里没有任何人类参与。 每一个 Agent 都在用飞书 CLI 操作飞书，Agent 之间通过消息总线协调，完成了一个原本需要 3-5 个人协作半天的工作流。
这就是 Agent2Agent 的本质——不是两个 Agent 在聊天，而是多个 Agent 各司其职，通过共享的工具和协议完成复杂工作流。
我在 Agents 特区的《Agent-First 时代的企业软件：从 SOP 到 Skill 的转型之路》里看到过一个观点，非常认同：
“AI 时代交付逻辑已经变了。很多工作都是 AI 做的，包括 Skill。业务正确性是业务给的，但是步骤 + 指令是 AI 写的。”
当飞书这样的平台提供 CLI 化的 Agent Skills，当微信开放 ClawBot 接口，当 Slack、Discord 都在拥抱 Agent——Agent2Agent 不再是理论，而是正在成为企业协作的新基础设施。
AI Agent 员工：行业专家 + AI 是最佳组合
这是我今天最想强调的一个观点，也是我在实践 AnyClaw 过程中最深刻的认知：
行业专家 + AI 是最佳组合：纯技术团队做不好，纯业务团队做不了。
为什么这么说？
纯技术团队的困境：技术团队可以写出完美的代码，可以构建漂亮的 Agent 框架，但他们不懂业务。他们不知道一个跨境电商的 SOP 里哪些步骤是关键的，不知道一个财务审批流程里哪些环节容易出错，不知道一个销售团队的日报模板背后藏着怎样的管理逻辑。结果是——技术很炫，但落不了地。
纯业务团队的困境：业务专家知道所有的流程和规则，但他们写不了 Skill 代码，设计不了 Agent 的行为边界，搞不定安全防护和错误处理。结果是——想法很好，但做不出来。
最佳组合是两者融合：
正如 Agents 特区社区讨论中一位嘉宾所说：
“这套工作的方法论——实施交付的方法论——是企业的竞争力。行业专家很重要，客户现在要的不仅仅是把客户的想法落地，更希望乙方带着更 NB 的行业解决方案来牵引他们。后者是溢价。”
飞书 CLI 的 19 个 Agent Skills 就是一个很好的例子。这些 Skills 不是飞书的技术团队拍脑袋想出来的——日历 Skill、多维表格 Skill、任务管理 Skill、邮件 Skill——每一个背后都是对真实业务场景的深度理解。
技术团队负责把业务知识转化为可执行、可测试、可审计的 Skill 代码。业务专家负责定义正确的行为边界和业务规则。 这才是 AI Agent 员工的正确打开方式。
从 SOP 到 Skill：方法论才是护城河
我在之前的文章里提到过一个核心观点：
传统流程：人 → SOP 文档 → 人执行
Agent 流程：人 → Skill 代码 → Agent 执行
现在飞书 CLI 让这个过程更进一步：
传统流程：人 → SOP 文档 → 人打开飞书操作
Agent 流程：行业专家定义 SOP → 技术团队编写 Skill → Agent 通过飞书 CLI 自动执行
方法论是护城河。 谁能把行业知识高效地转化为 Agent 可执行的 Skill，谁就赢了。不是谁的技术更炫，而是谁对业务理解更深。
飞书选择 CLI 化，本质上是在降低这个转化的门槛。当操作企业软件的接口变得标准化、结构化，业务专家和技术团队之间的沟通成本就大幅降低了。
安全：不能回避的话题
飞书 CLI 的 README 里有一段很诚实的安全警告：
“此工具可被 AI Agent 调用，在飞书开放平台上自动化操作……存在模型幻觉、不可预测执行、Prompt 注入等固有风险。”
这和我在 AnyClaw 实践中的经验完全一致。给 Agent 权限，就像给新员工权限——必须要有边界。
飞书 CLI 在安全方面做了不少工作：输入注入防护、终端输出净化、OS 原生钥匙串凭证存储。但真正的安全边界不应该只在工具层面，而应该在 Skill 代码层面——行为边界必须代码化，不是用 Prompt。
我在 AnyClaw 中实现的安全防护体系，核心就是这个原则。LLM 会遗忘、会理解偏差、会越界，但代码不会。
开放生态：大平台的选择
飞书 CLI 的 MIT 开源协议、3 分钟快速上手、npm install 就能用——这不是一家封闭公司的做法。
微信开放了 ClawBot 接口，企业微信同步开放接入能力，Slack 和 Discord 早就在拥抱 AI，现在飞书也加入了——所有的大平台都在做同一件事：把 Agent 接口变成基础设施。
这个趋势传递的信息非常明确：Agent 正在成为”水电煤”。 就像当年开放公众号接口催生了整个内容生态，开放 Agent 接口会催生整个 Agent 生态。
我的判断
基于飞书 CLI 和最近观察到的一系列变化，我有三个判断：
第一，Agent2Agent 协作将在 2026 年成为企业数字化的主旋律。 不是一个超级 Agent 做所有事，而是多个专业化 Agent 各司其职、协同工作。飞书 CLI 这样的工具就是 Agent2Agent 的”神经末梢”。
第二，AI Agent 员工的竞争力不在技术，在于行业方法论。 纯技术团队做不好，纯业务团队做不了。谁能把行业专家的知识转化为高质量的 Skill 代码，谁就能在 Agent-First 时代建立真正的竞争壁垒。
第三，企业软件的 CLI 化是不可逆的趋势。 当飞书、微信、Slack 都在提供 Agent 原生的接口，还在开发复杂 Web 管理后台的企业，不是在”慢慢来”，而是在”被淘汰”。
回到我之前那篇文章的结尾——不是要不要转型的问题，而是转得快不快的问题。 飞书已经给出了他们的答案。
参考资料
- 飞书 CLI 开源项目 - GitHub — 飞书官方 CLI 工具，19 个 Agent Skills，200+ 命令
- 当微信开放 Agent 接口：企业软件的 Agent-First 转型思考 — 我之前对 Agent-First 转型的深度分析
- Agent-First 时代的企业软件：从 SOP 到 Skill 的转型之路 | Agents 特区 — 关于 Skill 代码化、安全边界、商业模式的系统讨论
- Junior - The AI Employee for Any Role — AI 员工概念的代表产品
- 微信可通过插件连接龙虾 - 官方公告 — 微信开放 ClawBot 接口的官方公告