夜雨聆风
上周四凌晨两点，我们的 AI CEO 龙虾卡住了。
它需要在飞书里建一张多维表格——追踪本周8个子任务的进度。听起来不难，对吧？
但要通过 API 实现这件事，需要先申请权限、获取 access_token、调用 bitable.v1.app.create、再调用 bitable.v1.app.table.create、接着逐个 bitable.v1.app.table.field.create……保守估计 40 行代码，还不算错误处理和重试逻辑。
龙虾发了一条消息给我：「Wesley，我需要你帮我写一段飞书 API 调用代码。」
凌晨两点。
然后到了周六，飞书在 GitHub 上悄悄推了一个仓库：lark-cli。
我打开一看，第一行命令：
lark bitable create --name "任务追踪表" --field "任务名称:text,状态:select,负责人:user"
一行。
我有点愣住了。
过去 40 年，人类界面的进化方向是：CLI → GUI。
从命令行到图形界面，从 DOS 到 Windows，从终端到鼠标——我们一直在「让机器学说人话」。
但 AI 时代来了，方向反了。
现在最大的问题不是人看不懂命令行，而是 AI 看不懂 GUI。点哪个按钮？拖到哪里？图标什么意思？AI 要么靠视觉识别（费算力、不稳定），要么靠 API（费代码、权限复杂）。
CLI 突然变成了最优解。
2026年3月最后一周，三件事同时发生：
▶ 3/28：飞书开源 lark-cli，Go语言，MIT协议，200+ 命令，19 个 AI Agent Skills，覆盖消息/文档/多维表格/日历/邮箱/任务/会议等 11 大业务域
▶ 3/30：企业微信开源 wecom-cli，Rust语言，MIT协议，7 大品类，12 个 AI Agent Skills，覆盖通讯录/待办/会议/消息/日程/文档/智能表格
▶ 三周前：Google 开源了 gws（Google Workspace CLI），同样思路
这不是巧合。这是企业协作软件行业在集体做一件事：向 AI Agent 打开大门。
全文约 4000 字，阅读大约需要 10 分钟。
一、我们龙虾团队是怎么撞上这件事的
先说我们自己的情况，这样你能感受到这件事的重量。
我的一人公司里跑着一个 AI Agent 团队：CEO 龙虾负责战略协调，下面有专门做内容、运营、开发、基础设施的子 Agent。整个团队通过飞书跟我实时沟通——晨间简报、任务派发、进度汇报、异常告警，全部走飞书。
这套系统跑了三个多月，效果很好，但有一个持续的痛点：
子 Agent 想主动操作飞书，难度极高。
以前我给龙虾团队用的方式，是「飞书 Bot + 自定义工具函数」。每次要新增一个能力，比如「Agent 自动创建飞书文档」，就得走一遍完整流程：在飞书开放平台申请对应权限、等审核、写 API 调用函数、处理 Token 刷新、处理并发限制……前后至少半天。
然后飞书 CLI 来了。
npm install -g @larksuite/cli
lark auth login
lark doc create --title "本周任务" --space-id xxx
三行。文档建好了。
Agent 现在可以在一次对话里直接说：「帮我建一个飞书文档，标题叫《本周复盘》，把这五条内容写进去。」然后它自己去执行——不需要我事先写任何胶水代码。
企微也是同样的逻辑：
npm install -g @wecom/cli
wecom todo create --title "跟进客户A" --due "2026-04-03"
对于同时管理飞书团队和企微客户的人来说，这两个工具同时开放，意味着什么——你自己体会。
二、CLI 到底比 API 好在哪里？
这个问题很多人会有疑问：飞书本来就有开放 API，为什么还要搞 CLI？CLI 不就是封装了 API 吗？
是的，CLI 底层确实是 API。但对 AI Agent 来说，这层封装的意义是质的变化。
1. CLI 自描述，AI 不需要读文档
API 文档动辄几百页。AI 每次调用前需要先读懂文档，或者你得事先把接口说明写进 Prompt。
CLI 不一样：lark --help 直接输出所有命令列表；lark doc create --help 列出所有参数。AI 在运行时就能探索能力边界，不依赖外部文档。
2. 文本输入/输出，天然适配 LLM
LLM 本质是文字游戏。CLI 的输入是文字命令，输出是文字结果。整个交互过程对 AI 来说是零摩擦的——它就像在写代码，输出就是执行结果。
相比之下，GUI 的「找到那个按钮，点它，等弹框」对 AI 来说是噩梦。
3. 不占上下文窗口
MCP（Model Context Protocol）工具调用方式虽然也很强，但有个问题：工具描述本身要占上下文。你装了30个 MCP 工具，光工具描述就吃掉几千 Token，真正用来思考的空间就少了。
CLI 不同——用一条命令调用，调完就走，不在上下文里留残影。
4. 组合能力
Unix 哲学：每个工具做一件事，管道串联。
lark calendar list --today | lark message send --target "Wesley" --content "今日日程：$(cat)"
这种管道组合，让 Agent 可以临时拼出各种自定义工作流，不需要预先定义每一个场景。
5. dry-run 安全网
这一点我重点讲，因为它对 AI Agent 的安全运行极其重要。
大多数高质量 CLI 工具都支持 --dry-run 参数：预演整个操作流程，输出「将要做什么」，但不真正执行。
lark bitable batch-delete --table-id xxx --filter "status=done" --dry-run
# 输出：将删除 23 条记录（状态=完成）
# 实际：0 条删除
Agent 权限问题是所有人最担心的：给 AI 太多权限，一旦它判断失误，后果可能不可逆。dry-run 机制让 Agent 在执行高风险操作前先「给人看一眼」，这是最轻量的人机协作安全网。
三、六个我已经在验证的新玩法
说完原理，讲点实际的。
这些场景有的已经在我们团队跑通，有的还在实验中。但每一个，在 CLI 开放之前都是「要么手动要么不可能」。
🤖 玩法一：AI 秘书晨间简报
每天早上 8 点，Agent 自动执行：
查飞书日历（今日所有会议）
+ 查飞书邮件（未读重要邮件摘要）
+ 查飞书任务（今日到期任务列表）
→ 汇总成一条飞书消息推送给你
这套流程在飞书 CLI 开放之前，需要给 Agent 单独写三个 API 调用函数，还要处理权限同步问题。
现在一段脚本就能串联起来，Agent 自己维护，不需要我介入。
📝 玩法二：会后自动拆任务
会议结束后，语音转文字已经很成熟。但「纪要 → 任务 → 通知到人」这条链还需要人工。
现在：
▶ 会议结束，纪要文档自动生成到飞书
▶ Agent 读取纪要（lark doc read）
▶ LLM 分析，拆解出 N 条任务（含负责人、截止时间）
▶ 逐条创建飞书任务（lark task create）并指派
▶ 通过飞书消息通知对应负责人（lark message send）
整个过程 5 分钟之内完成，全程无需人工。这是我认为短期内价值最高的场景——节省的不只是时间，是所有人都会在会后漏掉的那些「谁来跟进」的细节。
📊 玩法三：智能表格数据管道
飞书多维表格和企微智能表格，本质上都是企业级 Database。
以前 Agent 要读写这些数据，需要事先配置专用的 API 凭证，还要针对每张表写解析代码。
现在：
# 读飞书多维表格
lark bitable list-records --app-id xxx --table-id xxx --filter "status=pending"
# 写企微智能表格
wecom sheet update-row --sheet-id xxx --row-id xxx --data '{"status":"done","note":"已完成"}'
对我们团队来说，这意味着 Agent 可以直接把工作结果写回表格，不需要人工转录。我们用飞书多维表格追踪每周内容的数据指标，以前每周一要手动更新，现在 Agent 读取数据平台接口、自动更新表格——这个动作省了我每周约 30 分钟。
💬 玩法四：消息智能归档
企微是很多人管理客户关系的主战场。每天几十上百条客户消息，要手动分类、创建跟进待办，是巨大的心力消耗。
wecom-cli 开放了消息读取能力：
wecom message list --chat-id xxx --since "2026-03-30"
配合 LLM 分析，可以自动识别：「这是一个新需求」「这是一个投诉」「这是一个合作意向」，然后自动创建对应类型的待办：
wecom todo create --title "跟进XX客户产品需求" --due "明天" --priority high
这个场景的关键不是技术，是「把碎片化的对话转化为结构化的行动」，这正是 LLM 最擅长的事。
📅 玩法五：跨人日程协调
「我们找个时间开个会」是企业里最低效的一句话。
查每个人的飞书日历空闲时间、找重合段、发邀请——这件事做一次不难，但每次都要手动做很烦。
# 批量查多人闲忙
lark calendar freebusy --users "user1,user2,user3" --date "2026-04-01"
# 创建会议并发邀请
lark calendar event create --title "本周同步" --start "2026-04-01T14:00" --attendees "user1,user2,user3"
Agent 可以帮你做完这整条链，你只需要说：「帮我约一下龙虾团队，找下周二下午的时间」。
🔄 玩法六：跨平台联动
这是我认为最有想象空间的场景，也是我们正在深度实验的方向。
飞书和企微在很多公司是并存的：内部团队用飞书，外部客户用企微。信息割裂是长期痛点。
现在两套 CLI 同时开放，配合 OpenClaw 的 Agent 编排能力：
▶ 企微客户发来新需求 → 企微 CLI 读取 → LLM 整理 → 飞书 CLI 创建内部任务 → 指派给对应负责人
▶ 飞书内部项目完成 → 飞书 CLI 读取状态 → 生成客户更新通知 → 企微 CLI 发送给客户
打通两端的信息流，让 Agent 成为真正的「信息枢纽」，不再是人工在两个平台之间来回搬数据。
完整的实现细节我放在知识星球「光锥之内」里——这套跨平台自动化的配置有不少坑，适合对着具体代码讲。
四、权限安全：Agent 能干多少，你说了算
讲完能干什么，聊聊最担心的事：AI Agent 的权限边界在哪里？
这是所有人在接入 AI Agent 做企业自动化时绕不开的问题。我给的答案是分三层管：
第一层：认证隔离
lark-cli 和 wecom-cli 都支持多账号、多权限级别的凭证配置。给 Agent 专门创建一套「只读+有限写入」的凭证，和管理员账号完全隔离。Agent 凭证就算被滥用，也不会有管理员级别的破坏力。
第二层：dry-run 预演
前面提到了，高风险操作（批量删除、群发消息、表格清空）必须先 dry-run，输出预览，经人确认后再执行。这一条规则，我在给龙虾团队做自动化配置时已经当成强制要求——不是「建议」，是「默认行为」。
第三层：审计日志
所有 CLI 操作都要记录日志，包括时间戳、执行的命令、操作结果。这不只是为了排查问题，更是为了在 Agent 做了意外操作时能快速回溯。
有人问过我：「Agent 权限怎么给？不给什么都干不了；给多了，怕干出不可逆的事。」
我的回答是：从最小权限开始，观察三周，每次只扩一点——就像当年把公司账户从保险柜搬到网银，也是一步步摸索出来的。
五、这不是「多了个工具」，这是一个信号
我想在这里说一个更大的判断。
飞书、企微、Google Workspace 在同一个月开源 CLI，不是巧合，是竞争压力下的集体选择。
原因很简单：企业软件的下一个战场是 AI Agent 生态。
哪个平台能让 AI Agent 最容易接入、运行得最稳定、权限管理最安全——它就能成为企业 AI 工作流的基础设施。飞书和企微都意识到了这一点，所以它们在做同一件事：降低 AI Agent 接入门槛，抢占生态位。
这对我这样的超级个体来说，意味着什么？
意味着未来一两年，企业协作软件将全面支持 AI Agent 作为一等公民。你的 AI 助手不再是一个只能聊天的工具，它可以直接在你用的软件里做事。
飞书 lark-cli 的 19 个 AI Agent Skills，不只是 19 个命令集合，而是 19 个「AI 可以主动完成的工作职责」。
当一个 AI Agent 能负责日程管理、文档整理、任务跟进、消息汇总——「Agent 是工具」这个说法就过时了。它是一个会用工具的人。
我这次学到的 4 个教训
教训一：CLI 开放是基础设施事件，不只是开发者工具
很多人看到 CLI 开源，第一反应是「这是给程序员的」。不对。这是给所有想用 AI Agent 替代重复工作的人准备的。代码是表面，背后是企业软件向 AI 全面开放的信号。
教训二：dry-run 不只是技术功能，是信任建立机制
我最初以为 dry-run 是「测试用的」，用完就去掉。后来发现它是 Agent 与人协作的核心机制——特别是在 Agent 第一次做某类操作时，dry-run 是「我先给你看，你觉得 OK 了再做」。这种机制让人敢于给 Agent 更多权限。
教训三：工具统一比工具强大更重要
飞书和企微同时开放 CLI，最大的价值不是单个工具变强了，而是两个平台的信息流第一次可以被同一套逻辑打通。碎片化是 AI Agent 最大的敌人——工具越统一，Agent 能做的事越完整。
教训四：给 Agent 的权限要「分级给，分周期扩」
不要在 Agent 第一天就给满权限。从只读开始，观察一周，再开写入权限，再观察，再扩——这不是不信任 AI，这是建立信任的正确方式。就像新员工入职，你也不会第一天就给他财务签字权。
写在最后
上周四凌晨两点，龙虾卡在那 40 行 API 代码前。
现在它只需要一行命令。
这中间发生的不是技术进步，是一种态度的转变：企业协作软件开始认真对待 AI Agent 作为使用者，而不只是集成对象。
如果你也在用 OpenClaw 跑 Agent 团队，飞书 lark-cli 和企微 wecom-cli 值得现在就装上试试。不需要你写一行 API 代码，--help 开始探索就好。
有问题欢迎留言，或者来知识星球「光锥之内」找我。
往期精选
📌 OpenClaw实战：20个Cron Job的血泪史——AI自动化不是自动躺平
📌 OpenClaw实战：Agent输出总翻车？踩坑30天后找到的几个核心原因
📌 OpenClaw实测：稳定输出——记一个3w星框架如何帮我炼出5条AI管理铁律
📌 OpenClaw实战：记忆架构升级——给AI Agent Teams建一个集体大脑
📌 OpenClaw实战：让AI越变越聪明的秘密——每日复盘，自我进化
📌 OpenClaw 实战：AI Agent 团队从1个扩到8个，再砍回4个的真实原因
📌 给 OpenClaw Agent Team 装上记忆——踩了19天坑，终于搞明白了
📌 实战复盘：OpenClaw 6人Agent Team险些全军覆没
🦞 关于「Wesley AI 日记」
记录一个人用 6 个 AI 员工撑起一人公司的全过程。没有成功学，只有真实的系统设计、真实的翻车现场、真实的复盘。每篇文章都是一个完整的实战故事。
想要更深度的内容、完整的 OpenClaw 配置、完整的自动营销增长 Skill、完整的 SOUL.md 模板、Workflow 最佳实践、以及和我直接交流的机会？加入知识星球「光锥之内」——这里会有平台发不了的完整内容和实操资料。
扫描下方二维码，或在知识星球搜索「光锥之内」
关注 Wesley AI 日记，持续更新一人公司 AI 团队实战全记录。
