CLI as Agent Interface
为什么现在是造 CLI 的最好时机
来源：J0hn，2026-04-03
二十年空白与终端文艺复兴
1995-2015 年，CLI 工具创新几乎停滞。然后 Go 和 Rust 打破了局面。
关键突破：单二进制分发
以前用 Python 写 CLI，用户得先装 Python、pip install、处理版本冲突...
Go/Rust 编译出来的是一个独立的二进制文件。一行 curl，下载，给执行权限，完事。
curl -L https://example.com/tool | tar xz
chmod +x tool
./tool
不需要运行时，不需要依赖管理，不需要 Docker。
Rust 社区重写经典 Unix 命令
| 经典命令 | 现代替代 | 改进 |
|---|---|---|
| grep | ripgrep | 快 10 倍，默认递归，自动跳过 .gitignore |
| cat | bat | 语法高亮，行号，Git diff 标记 |
| ls | eza | 彩色输出，树形视图，Git 状态 |
| find | fd | 语法更直觉，默认忽略隐藏文件 |
| cd | zoxide | 记住常去目录，模糊匹配 |
Agent 让 CLI 成为软件入口
钉钉、飞书等大厂亲自下场做 CLI。
原因：CLI 是 Agent 的终局接口。Agent 不需要 GUI，它需要结构化的命令和输出。
OpenCLI：Agent 的 Emacs
来源：OpenCLI，2026-04-05
核心范式
万物皆可 CLI。网站、Electron 应用、本地工具 —— 所有外部交互都被统一到一个可编程的命令行环境中。
Agent 可以自由发现、调用、组合、修复，甚至创造新的命令。
与 Emacs 的类比
| 特性 | Emacs | OpenCLI |
|---|---|---|
| 核心哲学 | 万物皆可 Elisp | 万物皆可 CLI |
| 安装方式 | 放入 ~/.emacs.d/ |
放入 ~/.opencli/clis/ |
| 生效时机 | require/autoload | 文件落盘即自动注册 |
| 原语 | buffer、text、command | args、columns、format |
Agent 使用示例
# Agent 只需知道这一行，不需要知道背后的 Wbi 签名和 Cookie 处理
opencli bilibili search "Rust 教程" --limit 10 -f json
复杂性被插件封装，暴露出来的是干净的命令接口。
"Bash is all you need"：CLI vs MCP 的根本差距（2026-05-05）
新璐的核心暴论：CLI 工具比 MCP 好一大截。原因不是工程实现，而是预训练数据的分布：
| 维度 | Unix CLI | MCP |
|---|---|---|
| 预训练语料占比 | 几十亿次出现（cd、ls、grep、git...） | <0.1%（近一两年才提出的协议） |
| 模型训练鲁棒性 | 极高 | 极低 |
| 成功率 | 高 | 低（实测 GitHub MCP → CLI 明显提升） |
实证案例
- GitHub MCP → 切换到 GitHub CLI，成功率明显提升
- 飞书 CLI 同理，各系统都开始开发 CLI 而非 MCP
- 趋势判断："返璞归真"——CLI 作为 Agent 接口正在回归
这与 product-trends/cli-as-agent-interface#Agent 让 CLI 成为软件入口 中"CLI 是 Agent 的终局接口"的判断一致，但新璐补充了更深层的解释：不只是接口设计问题，而是模型预训练数据分布决定了哪种工具形式更鲁棒。
关联
- product-trends/overview — Product Trends 总览
- product-trends/agent-native-architecture — Agent-native 架构
- harness-engineering/overview — CLI 是 Harness 的一部分
Tools
expect-cli
终端交互自动化 CLI 工具。
基本信息
安装: npx expect-cli@latest
类型: CLI工具
用途: 终端交互自动化和测试
安装使用
# 初始化
npx expect-cli@latest init
# Web 使用
npx expect-cli@latest
AI Agent应用场景
自动化测试
- 自动化 CLI 工具交互测试
- 模拟用户输入进行端到端测试
- 验证命令行应用行为
Agent 工作流
- 自动化需要交互的命令行流程
- 批量处理需要确认的脚本
- 无人值守的自动化任务
相关资源
- 类似工具: expect (Linux 经典工具)
评估状态
- 已安装测试
- 已集成到工作流
- 已用于实际项目
CLI for Agent
来源：@ericzakariasson 仓库：https://github.com/cursor/plugins/tree/main/cli-for-agent 收藏：3,176
核心问题
大多数CLI是为人类设计的：
- 交互式提示
- 模糊错误信息
- 无示例帮助
Agent使用时会被卡住或解析失败。
7条Agent友好CLI设计原则
1. 非交互优先
所有输入都能通过flag传入，交互模式只作为fallback。
2. 按需发现文档
不要一次性dump所有文档，让Agent逐层--help探索。
3. --help必须有示例
Agent靠模式匹配，示例比描述有效10倍。
4. 支持flag和stdin
Agent思维是管道，要能链式调用。
5. 快速报错且可操作
缺少flag立即报错并展示正确调用方式。
6. 幂等性
Agent会重试，同一命令执行两次应返回"已完成，no-op"。
7. --dry-run
让Agent先预览再执行破坏性操作。
额外建议
--yes/--force：跳过确认- 可预测的命令结构：如果学会
mycli service list，应该能猜到mycli deploy list - 成功时返回数据：显示部署ID和URL，表情符号不是必须的
应用场景
- 构建新的CLI工具
- 重构现有CLI
- 编写子命令帮助文档
- 审查现有工具是否会阻塞Agent
项目中的检查清单
任何暴露给Agent调用的CLI工具（obsidian CLI、gog、podwise等）都应对照检查：
- 确保所有参数都有flag版本
- 错误信息要包含正确调用示例
- 破坏性操作加
--dry-run
CLI Printing Press：从手工编写到自动生成 (2026-05-08)
Matt Van Horn 的 CLI Printing Press 是 CLI-as-Agent-Interface 趋势的完整落地案例。它不是讨论「CLI 应该怎么设计」，而是直接把任意网站/API/HAR 文件自动转成符合 agent 标准的 CLI。
为什么它重要
之前的 CLI-for-Agent 讨论停留在设计规范层面（用什么 flag、怎么返回错误、如何支持 --json）。Printing Press 把这一步从「手工 craftsmanship」变成「规模化生产」。
生成标准
每个生成的 CLI 自动满足本文前面讨论的所有 agent 友好标准：
--agent=--json --compact --no-input --no-color --yes- 单二进制分发（Go 编译）
- 可 pipe、可 filter、非交互式
- 附带对应的 Claude Code Skill 和可选 MCP Server
已生成的 50+ CLI
| CLI | 服务 | 特殊能力 |
|---|---|---|
pp-linear |
Linear | 离线可用 |
pp-kalshi |
Kalshi | P&L 分析 |
pp-airbnb |
Airbnb | 直订发现（绕过平台） |
pp-ebay |
eBay | 狙击竞价 |
信号
- 当生成 CLI 的成本趋近于零，「每个服务一个 CLI」将从理想变成默认
- HAR 文件 ingestion 意味着不需要官方 API——从网络日志反向工程即可
- 这是「个人软件」基础设施的关键组件：为自己定制工具，而非适应通用 SaaS