钉钉飞书为什么突然转向？Agent“终局”架构全解析（非常详细，看这篇就够了）

钉钉先出手钉钉的动作更早也更激进。3 月 17 日阿里发布「悟空」平台时钉钉 CTO 朱鸿说的是“我们希望每一个 AI Agent都能像调用系统命令一样自然地调用钉钉。注意用词「系统命令」不是「API」不是「协议」是ls、cd、grep那种东西。DingTalk Workspace CLI钉钉做的事情是重写底层代码把整个产品 CLI 化。并非在现有 GUI 上包一层壳是让 Agent 直接调用底层能力绕过图形界面。GitHub 项目叫dingtalk-workspace-cliGo 语言写的8MB 的原生二进制文件Apache-2.0 协议。安装方式是一行 curl 脚本装完之后本地多一个dws命令。实际装完跑一下dws --help能看到 12 个服务模块aitable AI 表格操作attendance 考勤打卡 / 排班 / 统计bot 机器人消息 / Webhookcalendar 日历日程 / 会议室 / 闲忙chat 群聊 / 会话 / 群组管理contact 通讯录 / 用户 / 部门devdoc 开放平台文档搜索ding DING 消息 / 发送 / 撤回oa OA 审批 / 同意 / 拒绝 / 撤销report 日志 / 模版 / 统计todo 待办任务管理workbench 工作台应用查询命令结构是标准的「服务/资源/动作」三级比如dws calendar event create、dws contact user search --keyword 张三。也没什么花哨的东西但直觉上倒是挺好理解的。钉钉还做了几个面向 Agent 的设计细节--yes参数。这个参数的描述是「跳过确认提示AI Agent 模式」。加上它之后Agent 执行操作不会被交互式确认卡住。这个看似不起眼但做过 Agent 开发的应该都懂一个交互式 prompt 就能让整个自动化流程崩溃。--mock参数。可以用模拟数据测试不用真的连钉钉后台。开发调试的时候非常实用。--dry-run预览。所有可能产生副作用的操作都能先预览再执行。Agent 要删个日程、发个 DING 消息之前先看看要干什么。安全方面钉钉做了三件事无感认证Agent 自动继承企业权限、批量熔断防止 Agent 失控批量操作、安全沙箱所有操作在沙箱内执行。钉钉还搞了个叫 RealDoc 的 AI 原生文件系统号称有 10000 条可用命令行指令支持原子级文件操作所有操作保留完整快照。飞书的三层架构飞书晚了 10 天但在架构设计上明显花了更多心思。飞书 CLI 叫lark-cli同样是 Go 写的但通过 npm 分发包了一层 Node.js wrapper14MB。MIT 协议。一行命令装完npm install -g larksuite/cli跑一下lark-cli --help第一眼就能看出跟钉钉的差异飞书的命令体系是三层设计。飞书 CLI 三层架构第一层Shortcuts前缀命令。这是飞书最有辨识度的设计。所有快捷命令都带前缀内置智能默认值lark-cli calendar agenda # 看今天日程lark-cli im messages-send --text hello --chat-id oc_xxxlark-cli contact search-user --query Johnlark-cli docs fetch --doc-id xxx这些命令做了大量参数简化。比如messages-send支持--text、--markdown、--image、--file这些直接参数不用自己拼 JSON content body。对 Agent 来说写--markdown 会议纪要已生成比拼一段{msg_type:post,content:{post:{zh_cn:...}}}要友好得多。光是base多维表格模块就有 68 个 shortcut 命令从创建仪表盘到管理工作流覆盖得挺全。第二层API Commands。100 多条命令跟飞书平台 API 一一对应。比如lark-cli calendar events list、lark-cli im messages create。第三层Raw API。直接调用飞书底层 2500 多个 OpenAPI 端点lark-cli api GET /open-apis/calendar/v4/calendarslark-cli api POST /open-apis/im/v1/messages --data {receive_id:ou_xxx,...}这层相当于一个万能逃生舱不管飞书有什么 API即使 CLI 没有封装对应的命令你也能直接调。从而让 Agent 遇到边缘场景的时候不会被卡住。飞书还内置了一个schema命令可以查看任何 API 方法的参数、类型和所需权限lark-cli schema calendar.events.list --format pretty这对 Agent 来说相当于一本随时可查的 API 字典。输出格式上飞书支持 JSON、NDJSON、table、CSV、pretty 五种格式。钉钉支持 JSON、table、raw 三种。飞书多出来的 NDJSON 和 CSV 在数据处理场景下挺关键的可以直接 pipe 给jq或者csvtool做后续处理。认证方面飞书的设计也更细致一些。lark-cli auth login支持按域domain申请权限比如--domain calendar,task只申请日历和任务相关的权限不用一口气开全。还支持--as user和--as bot切换身份同一个 CLI 可以模拟用户操作也可以用应用身份批量处理。还有个lark-cli doctor命令一键检查配置、认证和网络连通性排查问题的时候应该比较省心。两家对比钉钉 vs 飞书 CLI 能力对比两个 CLI 都装过用过之后差异就出来了。钉钉的优势侧重在企业管理场景。OA 审批approve/reject/revoke、考勤打卡/排班/统计、DING 消息、日志/周报这些飞书 CLI 里完全没有。如果你的 Agent 需要帮老板批审批单、查考勤、催日报钉钉目前是唯一选择。飞书的优势在开发者体验和文档协作。完整的邮件客户端搜索/起草/发送/转发/监听新邮件、文档的 Markdown 互转、电子表格的读写追加查找、知识库管理、会议纪要搜索这些钉钉 CLI 目前都还没覆盖到。用一个比喻来说钉钉 CLI 像是给企业行政部门配的数字助理飞书 CLI 更像是给研发团队配的效率工具。架构哲学上的差异也比较明显钉钉走的是「服务发现」路线dws --help里写的是「Discovered MCP Services」命令帮助全部是中文。飞书走的是「开发者工具」路线三层架构从快捷到通用逐级递进全英文界面还附带了 19 个 AI Skill 可以直接装进 Claude Code。全局参数上两家都有--dry-run和--format。钉钉独有--mock模拟数据和--yes跳过确认飞书独有--page-all自动翻页和--as身份切换。开源层面飞书的 GitHub 星标1313几乎是钉钉815的 1.6 倍。差点自己动手说句实话看到飞书出 CLI 的时候我的第一反应是总算特么来了。因为我其实差点就上手自己做了。Skill CLI 的组合架构我之前文章里聊过我从去年起就一直偏爱用 CLI Skill 的方式操控各种服务Cloudflare 的 CLI 管域名解析和 Workers 部署aliyunCLI 管 RAM 用户和 OSS 存储gcloudCLI 操作 Google Cloud。我会把这些 CLI 的用法写成 Skill更早时还没有 Skill告诉 Claude Code 每个命令该怎么用Agent 就能直接上手。飞书是我日常用得最多的办公工具之一但之前一直没有官方 CLI。社区里虽然有个feishu-cli500 多颗星能做 Markdown 和飞书文档的双向转换但覆盖面远远不够。我已经在琢磨自己基于飞书 OpenAPI 包一套 CLI 出来了。结果飞书官方直接出了还一上来就是 2500 API 端点全覆盖。省了我不少事但也说明了一个问题当用户都开始自己动手给你的产品做 CLI 的时候说明官方已经晚了。飞书这次算是踩在了临界点上。钉钉和飞书之后企业微信、Notion、Slack、……等应该都不会坐得住太久了。它们都清楚谁先出 CLI谁就先拿到 Agent 时代的入场券。MCP 的 17 倍成本技术选型上两家绕开 MCP 是有充分理由的。ScaleKit 做过一组 benchmark拿 GitHub 官方 MCP 服务器和ghCLI 做了一组对照实验跑的模型是 Claude Sonnet 4。各任务的 Token 消耗对比查一个仓库用什么语言CLI 消耗 1,365 tokensMCP 消耗 44,026 tokens。足足 32 倍查 PR 详情和审核状态CLI 1,648 tokensMCP 32,279 tokens。20 倍。查仓库元数据和安装方式CLI 9,386 tokensMCP 82,835 tokens。9 倍。所有 5 项任务的差异都具有统计显著性p 0.05。MCP 有 28% 的失败率可靠性的差距更大CLI 跑了 25 次全部成功。MCP 只成功了 18 次失败率 28%。7 次失败全是 TCP 层面的超时。成本与可靠性对比按月算就更直观了每月 1 万次操作CLI 大约 3.2 美元MCP 大约 55.2 美元。17 倍的成本差距。问题出在哪呢Schema 膨胀的解剖MCP 的 schema bloat。GitHub 的 MCP 服务器带了 43 个工具定义每次对话都得把这 43 个工具的完整描述全塞进上下文。你只是想查个仓库语言但模型得先读完所有 43 个工具的说明书。光一个list_stars_language_is_known工具的定义就占了 4,026 tokens。这就像去便利店买瓶水店员非要先把整本商品目录念给你听。ScaleKit 指出了一个关键判断MCP 的效率问题不在于协议本身而在于 schema 注入机制。但问题是这个机制恰恰是 MCP 设计的核心你没法绕开它。而 CLI 呢Agent 只需要跑一下--help按需读取某个子命令的参数说明就行。不用、也不会把所有命令的文档一股脑塞进上下文。Perplexity 的 CTO Denis Yarats 在今年的 Ask 开发者大会上也表了态Perplexity 内部正在远离 MCP原因是 72% 的上下文窗口被 MCP 占掉了再加上认证带来的摩擦成本。旧金山街头投票Composio 的联合创始人 Karan Vaidya 上周跑到旧金山街头做了个随机调查就问路过的开发者一个问题CLI 还是 MCP结果是CLI 17 票MCP 3 票。OpenAI 前联合创始人 Greg Brockman 站了 CLI。Y Combinator CEO 陈嘉兴的态度更干脆MCP sucks。一位被采访的开发者则贡献了全场最佳金句“MCP 像 Java 一样臃肿。Composio 顺势发了自己的 Universal CLI并给出了一个很精准的重新定义这场争论的本质不是品味之争是延迟之争。CLI 和 MCP 的核心差异归根到底就是一个快一个慢一个轻一个重。35 岁以下的开发者基本上全选了 CLI。这说明什么呢新一代开发者已经形成了一种直觉能用一行命令解决的事别搞一套协议。安全是伪命题吗当然也不是所有人都买账。OktaAuth0 的母公司的研发副总裁 Damian Schenkelman 写了篇文章标题就很刚「如果你要杀死 MCP说明你根本不在乎安全」。核心论点是CLI 调 API 要是认真做安全的话你最终得加上 OAuth 授权、动态客户端注册、敏感操作审批、服务端鉴权……加完这些你其实就重新发明了 MCP。他列了几条没法基于 Agent 身份做策略管控比如只允许特定 AI 厂商的 Agent 接入鉴权应该在服务端不能信任客户端敏感操作需要人工审批Agent 搞砸了得有人能拦住。这个论证乍一看确实有些道理不过仔细想想其实犯了一个典型的「过度泛化」错误。Schenkelman 描述的是一个完全开放的生态场景你做了一个 SaaS互联网上任何 Agent 都可能来调你的 API你不知道对方是谁不知道它要干什么。在这个场景下确实需要 MCP 那套完整的协议握手。但钉钉和飞书面对的场景则完全不同。企业内部的 Agent 身份是已知的权限是预设的操作在沙箱里跑日志全程可追溯。钉钉的批量熔断机制飞书的 dry-run 预览和按域权限申请本质上就是在 CLI 层面实现了 Schenkelman 所说的那些安全措施。只是没套 MCP 那个协议壳子而已。换个说法你家里人进厨房拿刀切菜不需要先通过安检、出示身份证、签免责协议。但如果是陌生人进你的厨房那确实应该先问问他是谁、要干什么。MCP 是给陌生人设计的安检流程CLI 是给自家人用的厨房工具。硬把安检流程套在自家人身上除了浪费时间没有任何安全增益。翻译层的演化从更长的时间线看这件事几乎是必然的。在之前的 Karpathy 和 Levie 那篇文章中我提过一个「第四次迁移」的框架大型机 → PC → 移动 → Agent每一次迁移都是因为出现了新的用户。而每次迁移旧时代的巨头恰恰因为在旧界面上做得太好反而无法适应新界面。Nokia 的实体键盘体验全球第一但触屏时代这成了累赘。翻译层的演化从 CLI 回到 CLI这次也一样。计算机诞生以来人和机器的交互方式经历了三次大迁移命令行 → 图形界面 → 触屏。每一次迁移都是因为出现了新的「用户」需要新的翻译层。普通人不会打命令所以有了 GUI。手机用户不方便用鼠标所以有了触屏。现在又来了一种新用户AI Agent。Agent 不需要按钮和菜单那些是给人类视觉系统设计的翻译层。Agent 不需要触屏手势那是给人类手指设计的。Agent 要的是结构化的输入输出要的是可以 pipe 的文本流要的是--help就能自描述的命令接口。GUI 是翻译层人类需要Agent 不需要而这恰恰就是 CLI 在五十年前就已经实现的东西。LLM 的训练数据里有数十亿行 shell 命令和脚本。对模型来说写一行lark-cli calendar agenda | jq .items[]比理解一个 MCP 工具的 JSON Schema 定义要自然得多了。Unix 哲学里的 pipe、组合、文本流这些设计范式已经稳定运行了五十年。CLI 是 LLM 的母语MCP 是后天学的外语。所以这轮迁移出现了一个反直觉的现象不是从旧到新是从新回到旧。GUI 是 CLI 之后发明的「翻译层」而 Agent 时代的最佳接口恰恰就是翻译层之前的原始形态。钉钉和飞书的选择本质上是在顺应这个事实。当你的用户从人变成了 AI你就该用 AI 最擅长的方式暴露你的能力。回头看几个时间线……CLI-Anything 在 GitHub 上拿了 15000 颗星证明了开发者社区对「万物 CLI 化」的热情。然后 OpenCLI 把浏览器和 Electron 应用也 CLI 化了30 多个站点和应用被拉通。现在钉钉和飞书官方亲自下场。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】