别再让后端手写脚本了：我搭了一套可复用的企业 CLI 基座，命令扩展靠 YAML

Sat, 18 Apr 2026 12:00:00 +0800

内部工具越堆越多，每个新服务都要重新写一遍登录、鉴权、日志、错误处理。

新来的同事拿到一堆脚本，不知道哪个能跑、哪个已经废了。测试环境和生产环境的 token 混着用，一不小心就把测试数据写到生产。

这是我搭这套 CLI 基座的真实原因：不是为了让工程师更极客，而是为了把内部能力收敛成一个人和 Agent 都能调用的统一入口。

这个项目我已经用在企业内部，核心代码公开。看完你能照着自己搭一套。

一、我为什么把企业后台能力做成 CLI

先说判断。

GUI、API、CLI 这三层，很多企业只做了前两层：后台页面给人点，API 给系统调。但中间那层——对人足够友好、对脚本足够稳定、对 Agent 足够结构化——一直是空的。

后果就是：

业务同学要操作后台，点到手软
工程师要写脚本，每个脚本都重新处理一遍认证、日志、错误
Agent 要调用业务，得直接拼 API，参数错了都不知道怎么报错

CLI 正好卡在中间。

但企业 CLI 不是把几个 API 包成命令就完了。我搭这套基座时，核心就一个原则：稳定层先代码化，业务层再规格化。

什么意思？

认证、环境、HTTP 请求、Header 注入、打包发布——这些是稳定层，一次搭好，长期复用。

业务命令——这些是变化层，用 YAML 规格化，扩展时不改核心代码。

这样搭出来的 CLI，命令越多，扩展越快。而不是命令越多，代码越乱。

二、这套 CLI 基座的骨架

项目结构长这样：

.
├── cmd/ # Cobra 命令入口
│ ├── root.go # 根命令，加载 YAML 动态命令
│ ├── auth_login.go # 登录回调
│ ├── token_refresh.go # Token 刷新
│ └── oauth_injected.go # OAuth 凭据注入（构建时生成）
├── internal/
│ ├── auth/ # 认证层：登录、token、device_id
│ ├── httpx/ # 请求层：HTTP client、Header 注入、401 refresh
│ ├── runtime/ # 执行层：YAML 解析、Cobra 命令注册、请求执行
│ └── store/ # 存储层：profile、token 本地持久化
├── specs/
│ ├── groups/ # 业务命令规格
│ │ └── order/
│ │ ├── group.yaml # 订单组配置
│ │ └── commands/
│ │ └── list.yaml # 订单查询命令
│ └── embed.go # go:embed 把 YAML 编译进二进制
└── scripts/
 └── build-with-oauth.sh # 多环境、多平台打包脚本

核心分层：

MCP 被抛弃的背后：不是技术输了，是 Token 和效率扛不住了

Wed, 15 Apr 2026 00:00:00 +0000

今年 3 月，Perplexity 的 CTO 在一场开发者大会上公开宣布：他们内部正在全面转向 API 和 CLI 工具，放弃 MCP。

几乎同时，Y Combinator 的 CEO 也说自己选择用 CLI，不用 MCP。而最近爆火的 OpenClaw，在实际执行任务时用的几乎全是内部工具和 CLI 命令，基本上看不到 MCP 的身影。

这就有意思了。MCP 明明是专门为大模型设计的工具接口标准，曾被誉为"Agent 的万能接口"，为什么现在反而被一群"古老"的命令行工具抢了饭碗？

CLI 到底有什么惊为天人的优势？MCP 又有什么不为人知的问题？

CLI 的两大优势

既然 CLI 能获得越来越多人的青睐，那它必然有着非常明显的优势。我总结了一下，主要是两点：Token 消耗小和执行效率高。

Token 消耗：14268 vs 忽略不计

CLI 的 Token 消耗小，从反面看就意味着 MCP 的 Token 消耗大。尤其是 MCP 的元信息——包括名称、描述、入参格式等等——这些都会传到大模型的上下文里面，从而消耗大量 Token。