今天 Hacker News 上一篇文章引起了不少讨论：「You Need to Rewrite Your CLI for AI Agents」。我们花了大量精力构建面向人类的 CLI，但 AI Agent 正在成为 CLI 的主要消费者，而现有的 CLI 设计对它们来说几乎是灾难。
问题出在哪
传统 CLI 的设计哲学是「面向人类的可读输出」。彩色文字、进度条、表格对齐、交互式提示——这些对人类友好的特性，对 AI Agent 来说全是噪声。
更棘手的问题：
- 交互式提示会让 Agent 直接卡死（"Are you sure? [y/N]"）
- 非结构化错误信息让 Agent 无法判断失败原因和重试策略
- 隐式状态依赖让 Agent 的行为变得不可预测
- 退出码语义不够丰富，无法区分"参数错误"和"网络超时"
AI-Native CLI 该怎么设计
核心原则：把 CLI 当 API 来设计。
1. 结构化输出是必须的
--output json 不是新概念——kubectl、gh、docker 都支持。但 AI Agent 需要的是契约化的结构化输出，有明确的 schema 版本和字段语义。
2. 消灭交互式提示
所有确认操作必须支持 --yes 或 --force。对 Agent 来说，一个需要交互的 CLI 等于一个不可用的 CLI。
3. 错误信息也要结构化
Agent 需要知道：这个错误是什么类型？可以重试吗？怎么修复？
4. 提供机器可读的能力描述
这本质上是在做 CLI 层面的 tool description。MCP 和 function calling 在做的事情，CLI 也需要做。
为什么现在是关键时刻
AI Agent 的工作方式正在从「调 API」向「用工具」转变。但大部分 CLI 工具还活在「只有人类会用我」的假设里。
对工具开发者来说，最务实的起步方式：
- 加
--output json——今天就可以做 - 加
--yesflag——消灭所有交互式确认 - 丰富退出码——不同错误类型用不同退出码
- 写一个 tool description——无论是 MCP 还是 OpenAPI
不需要重写整个 CLI。但如果你今天还在设计新工具时只考虑人类用户，那你可能正在构建一个半成品。
Agent 时代的基础设施，从一个 --output json 开始。
🚀 在 OfoxAI（ofox.ai）上，一个账号接入多个 AI 模型，让不同模型各展所长。
