Gradient Flow

Your CLI Was Built for Humans, Not Agents

6.9内容质量
Your CLI Was Built for Humans, Not Agents

TL;DR · AI 摘要

Your CLI Was Built for Humans, Not Agents - Gradient Flow Your CLI Was Built for Humans, Not Agents Posted by Ben Lorica...

核心要点

  • 主题聚焦:Your CLI Was Built for Humans, Not Agents
  • 来源:Gradient Flow,建议结合原文判断细节。
  • AI 分析暂不可用,本条为保底评分与摘要。
#AI#编程#后端#云计算#安全
打开原文

你的 CLI 是为人类而非代理而设计 - Gradient Flow

你的 CLI 是为人类而非代理而设计

发布者

Ben Lorica

2026 年 7 月 8 日

2026 年 7 月 2 日

发布于

未分类

.meta-info

.post-thumbnail

开发者之间存在一场友好的争论,讨论如何让 AI 代理可靠地使用外部工具、数据和服务,从而完成超出文本生成的实用工作。一方支持 CLI(命令行接口),代理通过 git、aws、jq、duckdb 和内部脚本等工具运行文本命令。另一方支持 MCP(模型上下文协议),它为代理提供结构化方式发现工具、认证并通过定义的模式调用服务。这可能看似局限于代码代理,但这种权衡对在运维、金融、客户成功或任何需要代理接触真实系统的流程中部署代理的任何人同样适用。一旦代理开始采取行动,其与外部世界的接口就不再只是技术细节,而是安全、成本和治理的关键决策点,无论该代理是编写代码还是管理客户数据。

如果你经常阅读,请考虑成为付费支持者 🙏

##### CLI:快速、熟悉且锋利

CLI 最强的优势在于其熟悉性、灵活性和低成本。首先,AI 模型在大量 shell 脚本、开发文档和终端内容上进行训练,这意味着它们无需特殊配置就能理解 git、docker 和 kubectl 等工具,这种熟悉度直接转化为可靠性和更低的错误率。其次,CLI 输出具有可组合性:代理可以将一个命令的输出直接传递给另一个命令,在数据进入模型工作内存前进行过滤、聚合或重塑。最后,令牌效率优势是真实且可衡量的。加载单个 MCP 服务器的完整工具模式可能在任何有用工作开始前消耗数万个令牌,而 CLI 工具无需任何前期上下文成本,代理可以通过内置的 --help 标志按需发现工具的功能。但问题是,CLI 访问可能过于强大。在没有沙箱、凭证隔离和审批机制的情况下授予代理原始 shell 访问权限,会使防止未经授权的文件和网络更改变得极其困难。

##### 代理的 MCP 论点

MCP 的支持者对 CLI 优先的观点有直接回应:CLI 没有考虑到 AI 在现实世界中的实际使用方式。大多数与 AI 代理互动的人通过基于浏览器的聊天界面或移动应用进行,运行 shell 命令根本不可行,许多商业工具甚至根本没有 CLI 等价物。在这些场景中,MCP 填补了真实的需求:它为代理提供自描述接口,代理在连接时可以自动发现可用工具及其使用方法,无需猜测命令语法或解析文档。与 CLI 不同,MCP 内置了 OAuth 认证、按用户权限和满足企业安全要求的审计跟踪。

主要的批评集中在开销问题上。较差的MCP实现可能在实际工作开始前就加载大量工具模式,消耗令牌、增加延迟并压缩推理空间。MCP还可能引入服务器故障、认证摩擦和更复杂的调试流程。实践经验表明,MCP需要良好的接口设计:更小的任务级工具、渐进式披露、模式过滤,以及仅展示代理所需内容的网关。

##### 你的CLI是为人类而非代理设计的

代理可以学习命令语法。更困难的问题在于,大多数CLI是为人类而非受时间、令牌和安全约束的软件代理设计的。我们很容易忽视这些缺陷,因为人类擅长填补空白。我们可以从糟糕的手册中猜测缺失步骤,解读模糊的错误信息,并自行意识到工具在展示选项前需要登录。而代理需要为每个空白付出具体代价:重复的发现循环、浪费的令牌、脆弱的文本解析,以及不必要的中断询问用户下一步操作。CLI没有改变,改变的是用户。

实践应对方案是将CLI代理就绪性视为可衡量和改进的指标,而非理所当然的假设。一个名为CLIARE(CLI Agent Readiness Evaluation)的开源项目正是如此。它检测实际安装的二进制文件而非你的文档,记录实际行为,并在六个维度生成评分报告:命令是否可发现且可导航、是否能构建有效调用、是否能完整执行而不卡顿、错误输入是否能清晰报错、是否提供可用的机器可读输出模式,以及只读探测是否保持只读属性。最终生成的评分表可运行、跨版本追踪,并与基于你工具构建代理的团队共享。这将接口质量从猜测游戏转变为可衡量指标。

这不仅影响代理编码,对企业的实际运营也至关重要。公司可通过CLI暴露真实操作权限:部署、财务流程、数据库作业、云控制平面、支持脚本、分析流水线和内部平台。如果代理要接触这些界面,关键问题不是"CLI是否存在",而是"代理能否在不猜测的情况下理解并使用它"。向代理暴露CLI的AI团队应尝试CLIARE,或至少借鉴其核心理念:使命令界面可衡量、可版本化、可解析,并明确说明前提条件、输出结果、副作用和风险。

##### 将接口与风险匹配

我不认为这是CLI和MCP之间的宗教性选择。更关键的问题是代理被赋予何种权限,以及它代表谁行事。在工作流本地、可组合、可检查且已贴近终端的场景中使用CLI:代码、测试、日志、文件、数据检查、构建系统、成熟供应商工具和内部脚本。但如果代理将频繁使用该CLI,应在依赖前使用CLIARE衡量其接口。

在以下场景中使用 MCP:工作流需要托管、支持多用户、涉及权限管理,或与 SaaS 系统集成且需要 OAuth、用户授权、访问控制和审计追踪功能。无论哪种情况,当代理需要处理资金、身份信息、生产系统、客户数据或不可逆状态时,都应提高安全标准。通用设计原则很简单:暴露任务本身,而非整个系统。保持接口简洁,优先采用可解析的输出格式,分离读写操作,记录具有重大影响的操作,并对不可轻易撤销的操作强制要求审批。传输方式的选择至关重要,但接口设计的影响更为关键。