大家好，我是悟鸣。 （公众号：悟鸣AI）
最近，悟鸣 AI 学习圈在云谷中心办了一场线下交流，主题是「CLI 全面打通企业内部系统」，内容主要围绕 Agent 工程师和 FDE 的落地实践展开。
大家对 AI 的热情很高。有朋友坐高铁从台州赶来，也有人带着孩子来听，还有情侣一起来学习。现场既有阿里、蚂蚁的同学，也有中小企业的 TL。结束后，也有几位热情的粉丝喊我合影，哈哈。
很多公司现在都在谈 AI First、端到端和超级个体。
但真实情况往往是：AI 在前面帮你分析了半天，到了最后一步，人还是要打开浏览器，登录不同平台，复制数据、填写表单、提交审批，再把结果贴回对话框。
只要这些关键动作仍然依赖人，所谓的"端到端"就很容易卡在人身上。
这也是我越来越重视 CLI 的原因。
它看起来是一种很传统的技术，甚至有点"古老"。但到了 Agent 时代，CLI 反而成了连接模型和企业系统的一种低成本、高可控的方式。
这篇文章主要回答四个问题：为什么要打通内部系统，CLI 和 MCP 如何取舍，CLI 与 Skill 怎么做，以及 FDE 最终如何用业务结果证明价值。
由于篇幅有限，改天我们会继续分享 CLI 打通企业内部系统的最佳实践部分。
1.为什么要打通企业内部系统？
现在模型能力越来越强，Agent 能完成的任务也越来越复杂。
但企业里的很多系统，依然按照"人打开网页、找到按钮、填写表单、点击提交"的方式设计。
网页当然适合人使用。它有界面、有提示，也方便人查看状态。
可如果执行者换成 Agent，这套交互方式就不一定合适了。
在多数自动化场景里，Agent 不需要浏览一个漂亮的首页，也不需要在十几个菜单里寻找入口。它更需要一组稳定、明确、可以组合的操作：查询数据、创建记录、更新状态、发起审批、获取结果。
这时，CLI 的价值就出来了。
它把原来藏在网页按钮后面的系统能力，变成可以被人、脚本和 Agent稳定调用的命令。
当一个 Agent 可以从 A 系统取数据，完成处理后写入 B 系统，最后到 C 系统更新状态，效率提升才会真正变得明显。
少点击一次按钮，可能没什么感觉。把多个系统串成一条链路，才是 CLI 真正产生价值的地方。
我把这套企业 AI 化的路径总结成三个动作：
1 .系统 CLI 化：让内部系统可以被 Agent 稳定调用
2.流程 Skill 化：把操作流程、业务知识和最佳实践交给 Agent
3.员工 Agent 化：把不同岗位中可标准化的工作交给不同 Agent 执行
人的工作也会随之发生变化：执行前负责澄清和确认，执行后负责检查和把关，中间遇到异常时再介入处理。
CLI 就是这套链路里非常关键的一环。
2.CLI 和 MCP 应该如何选择？
很多朋友会问：现在都在讲 MCP，为什么还要做 CLI？
MCP 提供了一套统一协议，也适合动态发现工具和长尾能力。服务端增加新功能后，客户端可以通过工具发现机制感知，相关生态也比较丰富。
但企业内部落地时，MCP 也有一些现实成本。
比如，在一些 Agent 客户端中，工具 Schema 会持续占用上下文；MCP Server 也增加了部署、调用和排障链路。出现问题时，还需要判断故障来自 MCP Server、认证流程还是下游接口。再加上权限、审计和部署成本，在固定场景里不一定划算。
所以我的实际选择通常是：
接口很少、逻辑简单，直接用脚本调用 API
接口较多、使用高频、稳定性要求高，优先封装 CLI
功能动态变化大、长尾工具很多，再考虑 MCP
我观察到，2026 年初，一些已经支持 MCP 的平台又开始补充 CLI，并通过 Skills 向 Agent 暴露能力。
现在，钉钉、企业微信、飞书等平台或社区项目都在探索 CLI 化。瑞幸咖啡、知识星球等服务，也可以通过 API 封装成面向 Agent 的 CLI。
打通企业内部系统之后，智能体就能在更长的业务链路中自动获取数据、执行操作，获得更完整的效率提升。
如果你的企业还没有布局这一块，率先做出一条可量化的业务链路，也可能成为 Agent 应用工程师或 FDE 证明自身价值的机会。
3.如何打通企业内部系统
(1).理解 CLI 与接口的关系
很多人不清楚 CLI 和 HTTP 接口的关系，这里简单讲一下。
CLI 是一种命令行工具，以前主要供程序员或 Shell 脚本使用。它不仅可以调用 HTTP 接口，也可以读写文件、执行本地任务。
调用接口时，CLI 会解析用户输入的参数、读取配置，再构造 HTTP 请求并发送到服务器。服务器处理完毕后返回结果，CLI 负责把结果展示出来。
(2).准备代码并确定技术方案
创建 CLI 时，最好把前后端代码一并提供给 Agent，让它获得足够完整的上下文。
接下来要选择技术栈。很多公司会使用 Node.js 加 TypeScript，也有团队选择 Python 或 Go。
正式开发前，一定要先划定功能优先级，优先打通最关键的功能。核心链路跑通以后，后续扩展会顺利很多。
(3).设计登录流程和基础命令
登录也是必须解决的问题。
传统命令行工具通常要求用户在终端里完成登录，但这套 CLI 最终会被普通用户通过智能体调用，因此更适合复用企业已有的网页登录流程。这样对普通用户更友好，也符合已有的使用习惯。
用户在浏览器完成认证后，CLI 可以通过本地回调或轮询获取登录结果，并安全保存凭证。浏览器页面提示登录成功后即可关闭。
开始创建时，可以把前后端代码交给 Agent，明确指定技术栈，让它封装成 CLI。
这里通常要特别说明两件事：一是登录流程如何处理；二是第一批要实现哪些功能。例如 --version、--help，以及登录、登出、查看当前用户等，都是 CLI 必备的基础能力。
(4).完成测试并创建配套 Skill
开发完成后，可以先让智能体自动执行测试，自己再手动运行几条关键指令，检查实际效果。
CLI 完成后，智能体未必能主动感知它的能力，所以还需要创建配套的 Skill。
这样既能减少 MCP 元信息持续占用上下文的问题，也能帮助大模型准确理解和调用 CLI。
创建完成后，再逐项检查 Skill 中的功能是否正常。
一个成熟的平台 Skill 应该同时包含 CLI 命令、平台特有的概念、关键知识，以及操作前后的处理逻辑。
如果你想用我的演示项目练手，可以在 GitHub 上搜索 fima-web。
对应的 CLI 项目是 fima-cli。
配套的 Skill 也已经开源，需要参考的同学搜索 fima 即可。
单个系统的提效可能并不明显。通过 CLI + Skills 把多个核心系统串成一条业务链路后，原本分散在多个系统里的重复操作会被一起压缩，整体收益也会迅速放大。
4.FDE 最后要交付的是业务结果
做完这些以后，向客户或主管汇报时，重点要落在业务结果上。CLI 很新、Agent 很火，都不足以成为企业投入的理由。
他们真正关心的是：
（1）原来需要多少人、多少时间
（2）现在能减少哪些重复操作
（3）哪些系统可以被串起来
（4）交付速度和数据质量有没有变化
（5）风险是否可控
比如，原来要在几个系统之间来回操作半小时，现在 Agent 几分钟就可以完成大部分步骤，人只负责最后核对。
这样的结果，才是 FDE 应该讲清楚的价值。
Agent 时代，系统的使用者正在发生变化：过去系统主要服务人，未来越来越多系统要为 AI 服务。
所以，企业 AI 化不能只盯着模型能力，还要重新设计系统被调用的方式。谁能率先把内部系统变成 Agent 可稳定使用的工具，谁就更有机会把 AI 从演示项目真正带进业务流程。
悟鸣，浙江省人工智能专家团专家，前蚂蚁集团 Agent 工程师，前蚂蚁集团年度优秀讲师，Qoder 企业培训大使、阿里国际全员 AI 学习和认证项目讲师、科大讯飞"星环计划"特邀布道师。专注 AI 培训和AI 落地等。
