TL;DR
- 命令行接口（CLIs）通常更适用于代理，因为命令形成了一个紧凑且可检查的操作接口。 代理可以调用一个操作，读取文本输出，检查退出状态，并将结果与另一个工具组合。
- CLI的最大优势不是单独的令牌使用更少，而是明确的执行合同。 稳定的标志、可机器读取的输出、标准流以及非交互模式使操作更易于测试和重放。
- CLI输出只有在其具有稳定模式时对代理友好。 面向人类的进度条、颜色、提示和变化的文句使自动化变得脆弱。
- 当发现、类型模式、远程服务或受管认证重要时，MCP更好。 本地命令和MCP服务器解决不同的边界并可以一起使用。
- 在没有可靠的自动化表面的视觉判断和工作流程中，图形用户界面（GUIs）仍然更好。 强迫基于坐标的交互变成CLI参数并不会使任务确定。
- 将每个CLI视为具有最小特权权限的能力。 使用允许列表、超时、隔离工作目录、输出限制和副作用的批准门。
为什么命令行接口适合AI代理的工作方式
命令行接口适合AI代理，因为它们将意图转化为具有可观察结果的有界操作。一个命令具有名称、参数、输入、输出、退出状态，通常还有帮助界面。这种形状远比一个主要是视觉状态的界面更容易放入代理系统。当代理需要当前公共网络证据而不是本地命令时，Nstdata Crawl可以提供类似的有界集合能力。
有关“为什么命令行接口对代理更好”的搜索结果在很大程度上依赖于速度和令牌节省。这些优势确实存在，但它们是一个更深层次属性的结果：接口是明确的。像git status --porcelain=v2这样的命令请求一个定义明确的可机器读取形式，而GUI则要求代理从小部件、布局和瞬态通知中推断状态。
这并不意味着每个CLI都是好的。一个打印装饰性输出、提出突然问题、在文句中隐藏错误或在版本之间更改格式的工具，仅仅是通过终端传递的一个困难API。
命令行接口揭示了小的操作面
一个好的CLI允许代理仅加载所需的操作。代理可以检查tool --help，调用子命令，并在解析后丢弃结果。大SDK或协议服务器可能在任何操作发生之前暴露许多模式，而图形应用程序可能暴露数千个语义薄弱的屏幕元素。
小的操作面提高了三个操作属性：
- 选择： 代理有更少的合理操作可供混淆。
- 验证： 应用程序可以在执行之前检查参数。
- 审计： 追踪记录确切的命令、工作目录、退出代码和经过清理的输出。
结果并不自动安全。rm是紧凑但具有破坏性的。周围的运行时仍然需要权限和确认规则，以区分只读检查与变更。
文本流使工具可组合
命令行接口可以通过标准输入和输出传递数据，因此一个确定的操作可以为另一个提供输入，而不需要请求模型重写中间表示。 Bash管道文档定义了命令如何将输出连接到输入，以及如何推导管道状态。
对于代理来说，可组合性意味着检索命令可以发出JSON，验证器可以拒绝格式错误的记录，格式化器可以生成最终工件。模型决定运行的顺序；传统软件处理可预测的转换。这减少了伪造字段名称或意外数据丢失的机会。
管道还创建了失败陷阱。如果运行时仅检查最后一个进程，则早期命令可以在不中断工作流程的情况下失败。根据需要使用严格的Shell设置，检查每个相关的退出状态，避免通过连接不受信任的文本构建命令。
## CLIs使执行可重现
