AI Agent 的“最后一厘米”:你的产品需要 CLI 吗?

邮件写好了，却发不出去；会议安排好了，却不能直接创建日程；表格分析完了，却不能把结果更新回系统。

从“会回答”到“能执行”，看似只差一步。我把它叫作 AI 执行的“最后一厘米”。

要跨过这最后一厘米，问题不只在于模型是否足够聪明，还在于 Agent 能否进入业务系统、调用产品能力。CLI 也因此重新受到关注。

但真正需要回答的，不是“产品要不要 CLI 化”，而是：

哪些能力适合交给 Agent？应该通过什么方式开放？又该怎样控制它的执行范围？

01 /CLI 是什么？为什么它适合 Agent？

GUI 把能力放在页面里，CLI 把能力放在命令里

GUI 把产品能力放在页面和按钮里，用户通过点击完成操作；CLI 则把产品能力封装成一条条命令，通过输入参数完成调用。

从产品视角看，可以把它理解为：

CLI 是一种通过文本命令调用产品能力的接口。

为什么 CLI 适合 Agent？

比如，让 Agent 向项目群发送一条版本通知。

通过页面操作，人需要打开飞书、搜索群聊、输入消息，再点击发送。如果使用 CLI，这个动作可以表达成一条命令：

lark-cli im +messages-send \   --chat-id "<chat_id>" \   --text "版本将在今晚发布"

这里省略了鉴权和权限配置，但命令本身已经说明了三个关键信息：执行什么动作、向哪个群发送、发送什么内容。

对人来说，点击页面可能更直观；但对 Agent 来说，命令减少了执行过程中的模糊空间。它不需要识别页面图标，也不需要寻找输入框和发送按钮。只要参数和权限正确，就可以发起调用，并根据返回结果判断成功还是失败。

一条命令的结果还可以交给下一条命令继续处理：查到群聊 ID 后发送消息，读取表格后更新数据，完成质量检查后创建缺陷……这些动作既可以重复执行，也可以组合成一条更长的任务链。

所以，CLI 适合 Agent，原因不在于 Agent“喜欢命令行”，而在于一个设计良好的 CLI，能够把动作、参数和结果表达得更加明确。

CLI 化，不是把所有按钮变成命令

这并不意味着页面上的每一个功能都要改造成命令。

需要视觉判断、自由探索或复杂交互的任务，未必适合 CLI。CLI 化也不是把 GUI 菜单逐项翻译成命令，而是从产品能力中挑出适合机器调用的动作，为它们建立稳定、清晰的调用约定。

重点不在命令行本身，而在于产品是否为 Agent 提供了明确、稳定、可组合的能力入口。

理解了这一点，接下来要讨论的就是：GUI、CLI 以及其他调用方式应该如何分工。

02 /Agent 使用产品能力，不只有一种方式

每当一种新的能力或技术概念出现，讨论往往很快转向比较：

MCP 会不会取代 API？Tool 和 Skill 有什么区别？CLI 会不会替代 GUI？

这些比较有助于理解概念，但在一项具体任务中，更实际的问题是：Agent 应该通过什么方式使用产品能力？

答案通常不止一种。

GUI 和 Browser：通过页面完成交互

GUI 主要为人服务，适合浏览信息、比较内容，以及完成需要视觉判断的操作。

当系统没有开放其他调用方式时，Agent 也可以通过 Browser 或 Computer Use 识别页面，完成点击、输入和滚动等操作。

这种方式可以直接使用现有系统，不需要提前改造产品。但页面一旦变化，或者出现弹窗、登录失效等情况，原来的执行过程就可能中断。

因此，Browser 更适合依赖视觉判断、暂时没有其他调用方式，或者使用频率较低的任务。

API 和 CLI：直接调用产品能力

API 和 CLI 都可以让 Agent 绕过页面，直接调用产品能力，只是使用方式有所不同。

API 适合系统之间稳定、明确的数据交互，例如查询订单、创建任务或更新状态。

CLI 将产品能力封装成一条条命令，更适合本地操作、批量处理，以及多个动作之间的连续执行。

SDK 则是提供给开发者的工具包。它通常会对 API 等能力进行封装，减少认证、请求和异常处理的接入成本，但不是 Agent 完成任务时必须经过的一条独立路径。

同一项产品能力，也可以同时提供 GUI、API 和 CLI。

例如，“创建任务”既可以由人在页面上操作，也可以通过 API 接入其他系统，还可以被封装成命令供 Agent 调用。入口可以不同，但它们调用的应该是同一项产品能力，并遵守一致的权限和业务规则。

MCP 和 Skill：连接能力与使用规则

MCP 更关注 Agent 与外部系统之间如何建立标准化连接。MCP Server 可以向 Agent 提供可发现、可调用的工具，并描述这些工具需要什么参数。工具背后实际执行动作的，仍然可能是 API、CLI 或其他服务。

Tool 可以理解为 Agent 能够调用的一项具体能力，例如“查询订单”“创建缺陷”或“发送消息”。

Skill 则不是一种执行接口。它更像一份提供给 Agent 的工作说明，告诉它：

• 什么时候使用哪个工具；

• 按照什么顺序执行；

• 遇到异常时如何处理；

• 哪些节点需要交给人确认。

例如，一个“发布前质量巡检”Skill，可以规定先读取测试报告，再查询未关闭的缺陷，发现高风险问题时暂停流程，再把证据整理给负责人。

而读取报告、查询缺陷和发送通知，仍然需要通过 API、CLI、MCP Tool 或 Browser 等方式完成。

放进一项任务里，它们怎样配合？

可以这样理解：

Skill 负责说明流程和规则，MCP 让 Agent 发现并调用工具；API 和 CLI 承担明确、稳定的执行动作，Browser 补充没有稳定接口的页面操作。涉及判断、审批或责任承担的节点，则交给人处理。

这不是一套固定组合。

越明确、越高频、越需要重复执行的动作，越适合使用稳定的调用方式；越依赖视觉、探索和复杂判断的环节，越需要页面操作或人的参与。

理清这些方式的分工后，接下来需要判断：产品中的哪些能力，值得通过 CLI 开放？

03 /什么样的产品能力值得做成 CLI？

为产品提供 CLI，并不意味着把现有功能逐项用命令行重做一遍。需要判断的是：哪些产品能力值得通过 CLI 开放。

例如，在客户管理系统中，经营看板和客户画像更适合通过 GUI 查看；查询客户、导出名单、创建跟进任务、更新客户状态，则更适合提供明确的命令入口。

判断标准：明确、重复、可组合

动作明确，结果可以验证。

需要提供哪些参数、执行后会发生什么、怎样算成功，都可以被清楚定义。例如查询订单、转换文件格式、更新任务状态。

需要重复或批量执行。

偶尔发生一次的操作，通过页面完成已经足够。但当同样的动作需要频繁重复，或者一次处理大量对象时，CLI 更容易体现价值。

能够与其他动作组合。

Agent 很少只执行一个孤立动作。一项完整任务可能是：

查询符合条件的客户 → 创建跟进任务 → 更新客户状态 → 通知负责人

当这些动作都有明确的调用方式，Agent 才能把它们组合成一条连续的任务流程。

CLI 把一次操作变成可重复的执行路径

通过页面完成一项操作，通常需要打开页面、寻找入口、填写信息，再点击确认。对人来说，这种方式直观易懂；但当 Agent 需要反复执行同一项任务时，操作路径越长，中间需要识别和判断的地方就越多。

CLI 可以把这条操作路径收拢成一条参数明确的命令。它的价值不只是减少几次点击，而是让一次操作可以被直接调用、重复执行并保留下来。

这会带来三个变化：

• 从寻找入口变成直接调用。任务明确后，可以直接执行对应命令；

• 从单次操作变成批量处理。同一条命令可以更换参数后再次执行；

• 从临时过程变成可复现记录。执行时使用的命令、参数和返回结果可以被保存，方便定位问题。

API 同样可以提供稳定的执行能力。CLI 的特点在于，它把这些能力封装成了人、脚本和 Agent 都可以直接使用的命令；如果面对的是正式、长期的系统间集成，API 仍然可能是更合适的选择。

哪些情况不必急着做 CLI？

依赖视觉浏览和主观判断的任务，通常更适合 GUI 或 Browser；使用频率很低的操作，未必值得增加建设和维护成本；删除数据、批量发送消息等高风险动作，则需要先解决权限、确认和审计问题。

能被写成命令，不代表值得投入建设。还要判断：CLI 是否缩短了执行路径，它带来的价值能否覆盖建设、维护和风险控制的成本。

完成能力筛选后，下一个问题是：怎样让 Agent 稳定使用这些命令？

04 /怎样让 Agent 稳定使用 CLI？

筛选出适合 CLI 的产品能力，只解决了“开放什么”的问题。

要让 Agent 稳定使用这些能力，需要同时解决两件事：CLI 提供稳定的执行方式，Skill 说明何时调用、按照什么规则调用。

CLI 先提供稳定的执行约定

一条面向 Agent 的命令，至少应该说清楚三件事：

• 调用时需要提供什么信息；

• 执行后会产生什么变化；

• 怎样判断成功、失败以及是否可以重试。

仍以飞书 CLI 发送群消息为例：

lark-cli im +messages-send \   --chat-id "<chat_id>" \   --text "版本将在今晚发布" \   --as user \   --format json

这条命令明确了消息发给谁、发送什么内容、以什么身份执行，以及结果以什么格式返回。Agent 不需要从页面或对话中猜测目标对象，也不需要在执行过程中临时补充信息。

仅仅做到参数明确还不够，执行结果也需要稳定、可预期。

例如，Agent 因等待超时而重复执行命令时，系统是否会发送两条相同的消息？批量修改之前，能否先查看影响范围？执行失败后，返回的信息能否帮助 Agent 判断是重新尝试，还是转交给人处理？

这些规则决定了一条命令能否被 Agent 稳定调用。

对 Agent 来说，一条可靠的命令不仅要能够执行，还要让执行前后的状态可以被判断。

Skill 告诉 Agent 什么时候、怎样调用

即使命令本身足够清楚，Agent 仍然可能不知道应该选择哪条命令。

比如用户说：“通知项目群，版本今晚发布。”

Agent 还需要判断：

• “项目群”具体指哪个群；

• 应该以用户身份还是机器人身份发送；

• 是否需要先确认接收对象和消息内容；

• 发送完成后，怎样判断任务已经结束。

这些内容很难都放进某一条命令里。它们更像一份面向 Agent 的使用说明，负责把用户意图、调用步骤和异常处理连接起来：

用户提出任务 → Skill 判断调用方式 → CLI 执行动作 → Agent 根据结果继续处理

飞书官方 CLI 采用的就是这种组合方式：CLI 提供消息、日历、文档等具体操作，配套的 Agent Skills 则补充身份、认证、任务分流、结果判断和风险提示。

如果你正在设计一套面向 Agent 的 CLI，可以把飞书官方 CLI 作为一个公开案例进行拆解。它值得参考的地方，不只是命令本身，还包括统一的帮助与认证、身份选择、结构化输出，以及与 CLI 配套的 Skills。

无需照搬整套设计，但可以重点观察：它如何把“产品能力怎么执行”和“Agent 应该怎样使用”分成两个层次。

Skill 可以指导 Agent，但不能代替系统约束

Skill 可以提醒 Agent，在发送消息前确认目标对象，也可以要求它在删除数据前取得用户同意。

但如果 CLI 本身没有参数校验、权限控制和风险拦截，仅靠一份 Markdown 文档提醒 Agent“小心操作”，并不可靠。

一些关键规则仍然要由 CLI 或服务端强制执行：

• 缺少必要参数时拒绝执行；

• 权限不足时阻止操作；

• 高风险操作要求明确确认；

• 重复请求不会产生不可控的重复结果。

飞书 CLI 也将使用规则与系统约束分开：Skill 会说明哪些操作需要确认；对于部分高风险操作，CLI 本身还会设置确认门槛。

因此，让 Agent 稳定使用 CLI，需要两层设计共同发挥作用：

CLI 定义可以执行的能力和边界，Skill 说明使用这些能力的方法和规则。

当调用进入批量、连续和自动执行，权限范围与操作风险也会随之放大。下一步要解决的，就是如何控制 Agent 的执行范围。

05 /Agent 能执行 CLI 以后，怎样控制风险？

当 Agent 能通过 CLI 执行任务，错误就不再停留在回答里，而可能真正进入业务系统：发错消息、修改数据，或者导出超出任务范围的信息。

其中有两类风险尤其值得注意。

风险 01错误判断被真正执行

Agent 可能理解错用户意图，也可能在命令执行失败后，根据报错修改参数、切换命令，继续寻找完成任务的路径。

这种能力有助于处理普通故障，但遇到权限问题时，不能继续“想办法”。

Agent 本身无法获得服务端没有授予的权限；但如果它继承了过大的用户权限、不同入口的权限校验不一致，或者在被拒绝后不断更换参数尝试，实际执行范围仍可能超出当前任务的需要。

遇到权限拒绝时，不能把它当作一个需要 Agent 解决的普通错误，而是一条必须停下来的边界。

风险 02原有权限被机器规模放大

假设一名员工有权查看 CRM 中的客户资料。

由人操作时，他通常只会查询当前需要的几位客户；但 Agent 通过 CLI，可以连续翻页、批量查询，甚至在短时间内导出大量数据。

单看每一次查询，它可能都没有越权；但累积起来，获取的数据已经远远超出当前任务的需要。

所以，“允许查看”“允许批量查询”和“允许导出”不应该被视为同一种权限。人能够查看某条数据，不代表 Agent 可以遍历和导出整库数据。

Skill 可以告诉 Agent 应该怎样调用 CLI、遇到什么情况需要确认；真正的权限校验、数量限制和停止条件，则必须由 CLI 或服务端执行。

这些控制需要贯穿执行前、执行中和执行后三个阶段。

01执行前：按照任务授予权限

Agent 不应该直接继承用户的完整权限，而应只获得完成当前任务所需的命令、数据范围和使用时间。

例如，整理本周客户跟进情况，只需要读取指定客户和过去七天的记录，并不代表它可以遍历所有客户，更不代表它可以导出完整数据。

任务结束后，相应的临时权限也应及时失效。

02执行中：限制数量，也限制重试

对于查询操作，需要限制单次返回数量、连续翻页次数、调用频率和累计数据量。对于修改、删除、发送和批量导出等高风险操作，则可以增加执行预览或人工确认。

CLI 还需要让 Agent 区分不同类型的失败：

• 临时故障，可以在限定次数内重试；

• 高风险操作，需要等待确认；

• 权限拒绝或数据范围超限，必须停止执行。

遇到权限拒绝后，Agent 不应该自行更换账号、修改资源标识或者切换其他命令。如果确实需要更高权限，应当重新向用户申请授权。

03执行后：能够追踪和止损

系统需要记录任务由谁发起、Agent 使用了什么身份、执行了哪些命令，以及查询或修改了多少数据。

出现异常时，还要能够暂停任务、撤销授权，并对错误操作进行回滚或补偿。

但已经导出的数据很难真正收回。因此，执行后的审计可以帮助发现问题和确认影响，却不能代替执行前和执行中的限制。

CLI 提升了 Agent 的执行效率。风险控制要做的，是避免这种效率突破原有的权限边界。

一个面向 Agent 的 CLI，不仅要能执行任务，也要能在越界之前限制，在触碰边界时停止，并在出现问题后追踪影响。

06 /回到开头的问题：你的产品需要 CLI 吗？

判断是否需要 CLI，应该落到具体的产品能力上。

目标清晰、结果可验证，并且需要频繁、批量或组合执行的动作，更适合通过 CLI 开放给 Agent。高度依赖视觉判断、复杂决策和人工确认的任务，则更适合保留在页面中。

如果现有接口已经能够满足 Agent 的调用需求，也不必为了“CLI 化”再增加一个入口。

一项能力能否交给 Agent，还取决于它是否可控：身份和权限是否明确，调用范围能否限制，高风险操作是否需要确认，执行过程能否追踪，出现异常时能否及时停止。

如果这些条件尚未具备，比增加一条命令更重要的，是先补齐产品的能力边界。

CLI 不是所有产品的标准答案。它带来的提醒是：当产品开始被 Agent 使用，我们设计的就不再只是页面和操作流程，也包括产品能力以什么方式开放。

Agent 时代，产品不只要让人用得顺，还要让 Agent 调得动、管得住，出了问题查得清。