打开网易新闻 查看精彩图片

飞书刚开源了一个命令行工具 lark-cli。功能很直白：让 AI Agent 直接操作飞书——发消息、查日历、写文档、建多维表格、发邮件、管任务。你跟 AI 说一句话，它自己调命令行把活干了。

类似的 CLI 最近扎堆出现。三周前 Google 开源了 gws，让 AI Agent 操作 Google Workspace；更早之前，Anthropic 的 Claude 已经能调用终端；OpenAI 的 Codex CLI 更是直接把"程序员写代码"这件事搬到了命令行里。

为什么大家都在做命令行？

这有点像智能手机早期的"语音助手困境"。Siri 能听懂你说"订明早去上海的机票"，但它不知道怎么点 App、怎么填日期、怎么选座位——它只能"看着"屏幕干着急。AI Agent 现在面临同样的问题：大模型再聪明，缺了操作系统的"手"，就只能输出文字建议。

CLI 就是这只"手"。它绕过了图形界面，让 AI 直接调用系统能力。不需要模拟鼠标点击，不需要识别按钮位置，一条命令就是一个原子操作。对开发者来说，这像是给 AI 配了一套"机械外骨骼"——笨重，但精准可控。

飞书这次开源的 lark-cli，本质上是在回答一个问题：当 AI 成为主要用户，产品该怎么重新设计接口？图形界面是给人类看的，命令行才是给机器用的。把 API 封装成 CLI，等于在告诉开发者：你们不用自己造轮子了，直接拿这个去搭 Agent。

不过这里有个微妙的权衡。CLI 越强大，AI 的自主性就越高——但也意味着出错成本越高。想象一下，你对 AI 说"把下周会议都取消"，它调了命令行，结果把全公司的会都删了。没有二次确认，没有弹窗警告，执行就是执行。

Google 的 gws 和飞书的 lark-cli，目前都还在"实验性"阶段。真正的考验不是技术能不能跑通，而是企业敢不敢把生产环境的权限交给一条命令。

一位试用过 lark-cli 的开发者反馈："让它帮我发周报，它把草稿发给了全组。好消息是流程跑通了，坏消息是我现在每周多了一项任务——检查 AI 有没有选错收件人。"