假设你对 Agent 说：
“把本周飞书会议纪要汇总出来，提取待办，写入项目表，再把结果发到群里。”
模型理解这句话并不难。真正容易出错的是执行：它该找妙记、会议纪要还是云文档？项目表是电子表格还是多维表格？写入使用谁的身份？发群前是否需要确认？
自然语言解决了“我想做什么”，没有自动解决“系统应该怎样安全地完成”。Agent 越能理解模糊意图，执行层越需要确定的输入、输出和边界。
这也是 CLI 重新进入 Agent 工程视野的原因。
这里的“重新流行”是工程趋势判断，不是市场规模结论。CLI 火的不是黑色终端，而是它提供的稳定执行边界。
CLI 为什么适合 Agent
如果让模型直接拼 HTTP 请求，它需要处理 SDK、URL、认证头、分页、限流、错误码和不同版本的数据结构。每接入一个系统，都要重新学习一套细节。
CLI 把细节收进一个进程，对外留下命令、参数、标准输出和退出码。Agent 不需要知道内部使用什么语言，只需要知道：调用什么、传什么、成功得到什么、失败后怎么办。
它有四项现实价值：
- 接入成本低：多数编程型 Agent 已经能执行本地命令；
- 容易重放：人可以先验证命令，Agent 的调用也能复制复查；
- 便于组合：查询、转换、校验、写入可以拆成独立步骤；
- 复用现有生态：Git、数据库、云服务和构建工具本来就以 CLI 存在。
但“有 CLI”和“有 Agent CLI”是两回事。如果输出只适合人看，参数靠 README 猜，失败只返回一句报错，它并没有解决 Agent 的执行问题。
CLI、MCP、开放平台不在同一层
CLI 常被拿来和 MCP 比较，也容易与开放平台混在一起。它们其实承担不同职责。
| 层级 | 主要产物 | 解决的问题 |
|---|---|---|
| 开放平台 | API、应用、scope、配额、审计 | 能力从哪里来，谁能调用 |
| CLI | 命令、参数、输出、退出码 | 能力如何稳定执行 |
| MCP | tools、resources、prompts 和连接协议 | Agent 宿主如何发现、连接能力 |
| Skill | 路由规则、流程、边界、示例 | 什么时候调用什么，先做什么 |
开放平台是能力与治理源头
开放平台提供 API、应用身份、OAuth、权限 scope、配额和版本治理。飞书 CLI 能查文档、改表格、发消息，前提仍是飞书开放平台提供了对应能力。
CLI 可以改善调用体验，但不能绕过服务端的数据权限、租户隔离和业务规则。
CLI 是本地执行入口
CLI 适合已有本地工具链、CI/CD、脚本复用和单机 Agent。能力就在本机，宿主又能运行命令时，再增加常驻服务和协议层未必划算。
它的优势是部署短、调试短、容易被人接管。
MCP 是标准连接协议
MCP 采用 host、client、server 架构。Agent 宿主可以发现 Server 提供的工具，再通过结构化调用执行；协议还承载 resources、prompts 和能力变化。MCP 官方架构文档
当能力位于远端、需要被多个 Agent 宿主复用，或者工具清单会动态变化时，MCP 更有价值。它解决的是连接标准化，不是“比 CLI 更高级”。
到底应该选哪一种
不要先问“CLI 还是 MCP”，先回答四个问题：
- 能力运行在本地还是远端？
- 只服务一个 Agent，还是需要跨宿主复用？
- 能力清单是静态的，还是需要动态发现？
- 谁负责认证、授权、租户隔离和审计？
本地工具链、CI、个人自动化通常优先 CLI。远程多租户服务、跨宿主复用和动态能力更适合 MCP。开放平台负责底层能力与治理，Skill 负责把用户语言路由到正确执行入口。
两者也可以组合：成熟 CLI 外面增加 MCP 适配层，或者 MCP Server 内部调用已有 CLI，避免重写业务逻辑。
选型的核心不是协议偏好，而是运行边界、连接边界和治理边界。
产品评审时检查四件事
- 能力真正运行在哪里？
- 是否需要跨宿主发现和复用？
- 权限真相与审计留在哪一层？
- 失败后谁负责重试、降级和人工接管？
自然语言负责理解目标，CLI 提供确定执行，MCP 提供标准连接，开放平台提供能力和治理，Skill 负责业务路由。把这几层放回正确位置，才不会把一张技术选型表做成伪命题。