Agent时代CLI设计指南：从工具到智能体执行入口

1. 从"CLI-Anything"说起：命令行工具正在经历一场静默革命

第一次看到"CLI-Anything"这个说法，我脑子里蹦出来的不是某个具体工具，而是一种趋势判断——命令行界面正在从"运维专属"变成"人人都能用的自动化入口"。过去我们聊CLI，默认场景是Linux服务器上敲ls、grep、awk，或者写个Shell脚本定时备份数据库。但现在你打开任何一个技术社区，热搜词里全是codex cli、claude cli、pi cli、minimax code cli，甚至还有obsidian cli这种把笔记软件也搬进终端的玩法。这说明什么？说明CLI已经不再是"没有图形界面时的妥协方案"，而是变成了Agent调用工具、执行任务、串联工作流的核心通道。

我自己的体会是，2024年之前，我写CLI工具主要是为了"省事"——把重复的运维操作封装成脚本。但2024年之后，我写CLI工具的目的变成了"让Agent能调用"。这个转变非常关键。因为Agent本身没有手没有脚，它要操作文件、查询数据库、调用API、部署服务，最终都得落到某个可执行的命令上。CLI就是Agent的"手"。你给Agent配一个设计良好的CLI，它就能像资深工程师一样干活；你给它配一个参数混乱、错误处理稀烂的CLI，它就会陷入无限重试和报错循环。

所以"CLI-Anything"这个标题，我理解它想表达的是：任何能力都可以通过CLI暴露给Agent，任何Agent都可以通过CLI获得执行能力。这不是一个具体项目，而是一种架构思路。围绕这个思路，我会从设计原则、技术选型、实操落地、常见坑四个层面展开，把我在多个Agent项目中积累的CLI设计经验完整拆一遍。无论你是刚接触codex cli安装的新手，还是正在设计多Agent协作框架的老手，下面这些内容应该都能直接拿去用。

2. 为什么Agent时代CLI反而更重要了

2.1 Agent的"手"和"脚"到底是什么

很多人第一次接触Agent开发，会以为Agent就是一个大模型加一个循环，模型输出文本，循环判断是否结束。但真正跑起来就会发现，模型输出的文本必须被解析成具体动作，而动作的最终执行者就是CLI。比如你让Agent"把项目里所有console.log删掉"，它可能会生成一条命令：grep -rl "console.log" ./src | xargs sed -i '/console.log/d'。这条命令能不能跑通，取决于你的CLI环境是否完整、权限是否足够、路径是否正确。

我见过太多Agent项目卡在"模型知道该做什么，但命令执行失败"这一步。典型场景是Windows上安装codex cli，报错unable to locate the codex cli binary or required runtime components，或者node_modules\@opencode\cli\bin\opencode.exe 与你运行的 windows 版本不兼容。这些问题本质上不是Agent的问题，而是CLI环境的问题。Agent再聪明，CLI跑不起来，它就是个只会聊天的玩具。

所以我的第一个结论是：Agent开发的第一步不是写Prompt，而是把CLI环境搭稳。你要确保Agent能调用的每一个命令，在目标系统上都能稳定执行，错误码清晰，输出格式可解析。这件事做不好，后面所有Agent逻辑都是空中楼阁。

2.2 CLI作为Agent工具接口的三大优势

为什么不用HTTP API或者SDK，非要走CLI？我总结下来有三个原因，每一个都直接影响Agent的落地效果。

第一，CLI天然支持组合。Unix哲学里最核心的一条就是"每个程序只做一件事，做好，并且用管道连接"。Agent要完成复杂任务，最需要的就是组合能力。比如git diff --name-only | grep "\.js$" | xargs eslint --fix，这一条命令串联了版本控制、文件过滤、代码检查三个工具。如果换成API调用，你得写三段代码，处理三次鉴权，还要自己管理中间状态。CLI用管道符就解决了。

第二，CLI的输出格式对Agent友好。大部分CLI工具都支持--json、--format、--quiet这类参数，Agent可以直接拿到结构化数据。即使不支持，文本输出也比HTTP响应体更容易用正则提取。我实测下来，让Agent解析kubectl get pods -o json的输出，比让它解析一个REST API的嵌套JSON要稳定得多，因为CLI的输出边界清晰，不会混入无关的HTTP头、Cookie、重定向信息。

第三，CLI的权限模型简单。Agent要执行操作，最怕的就是权限混乱。CLI直接继承当前用户的系统权限，你给Agent一个受限用户，它就只能干受限的事。而API调用往往涉及Token、Scope、OAuth流程，一旦配置错误，要么权限过大，要么完全跑不通。对于快速迭代的Agent项目，CLI的权限模型更容易理解和控制。

2.3 从"人用CLI"到"Agent用CLI"的设计差异

这里有个关键认知：给人用的CLI和给Agent用的CLI，设计目标完全不同。给人用的CLI可以交互式提问、可以输出彩色表格、可以等待用户输入确认。但给Agent用的CLI必须做到非交互、确定性输出、幂等执行。

我踩过的一个坑是：早期我写了一个部署脚本，里面用了read -p "确认部署? (y/n)"。我自己用的时候没问题，但Agent调用时直接卡死，因为Agent不会输入y。后来我改成--yes参数跳过确认，并且默认输出纯文本，问题才解决。这个教训让我意识到，Agent调用的CLI必须假设"没有人类在旁边"。所有需要交互的地方都要有非交互的替代方案，所有需要确认的操作都要有--force或--yes开关。

另一个差异是错误处理。给人用的CLI，报错可以很随意，用户能看懂就行。但Agent需要的是可编程的错误码和结构化错误信息。比如exit code 1表示参数错误，exit code 2表示网络失败，exit code 3表示权限不足。Agent拿到错误码后可以决定是重试、换参数还是放弃。如果所有错误都返回exit code 1加一段人类可读的报错，Agent就只能瞎猜。

3. 设计Agent友好CLI的五个核心原则

3.1 原则一：非交互优先，交互作为可选

这条原则我放在第一位，因为它是区分"玩具CLI"和"生产CLI"的分水岭。具体做法是：所有命令默认走非交互模式，需要交互时通过--interactive显式开启。比如删除文件，默认直接删，加--interactive才逐个确认。这样Agent调用时不需要额外参数，人类使用时也能获得保护。

我见过一些CLI工具，默认就是交互式的，Agent调用时必须传一堆--no-input、--non-interactive、--batch参数才能跑。这种设计对Agent极不友好，因为Agent往往不知道要传这些参数，或者传了但工具版本不同导致参数名变了。最好的设计是：默认非交互，交互是例外。

3.2 原则二：输出必须可解析，JSON是首选

Agent解析文本输出的能力有限，尤其是当输出包含大量装饰性内容时。比如一个CLI输出：

正在处理... [=====> ] 50% 完成! 共处理 42 个文件

Agent要提取"42"这个数字，得写正则匹配共处理 (\d+) 个文件。但如果CLI支持--json，输出：

{"status": "success", "processed": 42, "failed": 0}

Agent直接JSON.parse就能拿到数据。所以我在设计CLI时，强制要求每个命令都支持--json参数，并且JSON结构保持稳定，不随版本随意变更。如果实在无法输出JSON，至少保证输出是纯文本、无颜色、无进度条，方便Agent用awk或cut提取。

3.3 原则三：幂等性设计，重复执行不产生副作用

Agent有个特点：它可能会重试。网络抖动、超时、解析失败，Agent都可能重新执行同一条命令。如果你的CLI不幂等，重试就会产生灾难性后果。比如create-user命令，第一次执行创建用户，第二次执行报"用户已存在"并返回错误码，Agent看到错误码可能又重试，陷入死循环。

正确的做法是：创建类命令要支持"存在即成功"语义。比如create-user --if-not-exists，如果用户已存在，返回成功而不是失败。删除类命令要支持"不存在即成功"，delete-user --ignore-missing。这样Agent重试时不会因为状态已变更而失败。

3.4 原则四：参数命名一致，减少Agent学习成本

Agent调用CLI时，参数名是它从文档或示例中推断出来的。如果你的CLI参数命名混乱，比如有的用--output，有的用--out，有的用-o，Agent就很容易传错。我的做法是：所有命令统一使用长参数，短参数只作为别名。比如--output是标准写法，-o是快捷方式。并且所有命令的参数命名遵循同一套规则：输入用--input，输出用--output，格式用--format，详细模式用--verbose，静默模式用--quiet。

这套规则看起来简单，但实际效果很好。我做过对比测试，同一套Agent逻辑，调用参数命名一致的CLI，成功率比调用命名混乱的CLI高出30%以上。因为Agent不需要为每个命令单独记忆参数名，它可以把一套调用模式复用到所有命令上。

3.5 原则五：错误信息包含修复建议

Agent遇到错误时，最需要的是"下一步该怎么做"。如果CLI只输出Error: file not found，Agent只能猜是路径错了还是文件真的不存在。但如果输出Error: file not found: /path/to/file. Did you mean /path/to/file.txt?，Agent就能直接修正路径重试。

我在CLI里实现了一个简单的"错误建议"机制：当文件不存在时，自动搜索同目录下相似文件名；当参数值非法时，列出合法值；当权限不足时，提示需要什么权限。这些建议不需要很智能，只要能让Agent少走一步弯路，整体效率就会明显提升。

4. 实操：从零搭建一个Agent可调用的CLI工具

4.1 技术选型：Node.js、Python还是Go

选什么语言写CLI，直接决定后续的维护成本和Agent兼容性。我三个都用过，下面是我的实际体验对比。

如果你做的CLI会被Agent高频调用，我强烈推荐Go。原因是Go编译出来是单个二进制文件，没有运行时依赖，Agent在任何环境下都能直接执行。Node.js和Python都需要目标机器安装对应运行时，一旦版本不匹配，就会出现unable to locate the codex cli binary or required runtime components这类问题。我有个项目用Node.js写CLI，在开发机上跑得好好的，部署到Agent沙箱环境就报node: command not found，折腾了半天才解决。

但Go的缺点是开发效率不如Node.js和Python，尤其是处理JSON和HTTP请求时，代码量明显更多。所以我的建议是：如果CLI逻辑简单、调用频繁，用Go；如果逻辑复杂、迭代快速，用Node.js或Python，但一定要把运行时打包进去。比如用pkg把Node.js项目打包成单文件，或者用pyinstaller把Python项目打包成可执行文件。

4.2 项目结构：让Agent一眼看懂你的CLI

Agent调用CLI时，通常需要先了解这个CLI有哪些命令、每个命令接受什么参数。所以你的CLI项目结构要清晰，最好能自动生成帮助文档。我推荐的结构是这样的：

my-cli/ ├── bin/ │ └── my-cli # 入口文件 ├── src/ │ ├── commands/ # 每个命令一个文件 │ │ ├── create.js │ │ ├── delete.js │ │ └── list.js │ ├── utils/ # 公共工具 │ │ ├── output.js # 统一输出格式 │ │ └── error.js # 统一错误处理 │ └── index.js # 命令注册 ├── package.json └── README.md # 给Agent看的文档

关键点是commands/目录，每个命令独立一个文件，文件名就是命令名。这样Agent可以通过ls commands/快速知道有哪些命令可用。另外README.md要写得对Agent友好，每个命令都给出示例调用和预期输出，Agent可以直接复制示例中的参数格式。

4.3 核心代码：一个可复用的CLI骨架

下面是一个Node.js CLI骨架，我把它用在了多个Agent项目里，实测稳定。核心思路是：统一参数解析、统一输出格式、统一错误处理。

#!/usr/bin/env node const commands = { create: require('./commands/create'), delete: require('./commands/delete'), list: require('./commands/list'), }; async function main() { const args = process.argv.slice(2); const commandName = args[0]; const commandArgs = args.slice(1); if (!commandName || commandName === '--help') { console.log(JSON.stringify({ commands: Object.keys(commands), usage: 'my-cli <command> [options]' }, null, 2)); process.exit(0); } const command = commands[commandName]; if (!command) { console.error(JSON.stringify({ error: 'UNKNOWN_COMMAND', message: `Unknown command: ${commandName}`, available: Object.keys(commands) })); process.exit(1); } try { const result = await command(commandArgs); console.log(JSON.stringify({ status: 'success', data: result })); process.exit(0); } catch (err) { console.error(JSON.stringify({ status: 'error', code: err.code || 'UNKNOWN', message: err.message, suggestion: err.suggestion || null })); process.exit(err.exitCode || 1); } } main();

这个骨架有几个设计点值得说明。第一，--help输出JSON格式，Agent可以直接解析出所有可用命令。第二，未知命令返回结构化错误，并列出可用命令，Agent可以自动纠正。第三，所有成功输出都包在{status: 'success', data: ...}里，所有错误输出都包在{status: 'error', code: ..., message: ...}里，Agent只需要判断status字段就能知道执行结果。

4.4 参数解析：手写还是用库

参数解析我建议手写，不用yargs、commander这类库。原因是这些库的输出格式往往带有装饰性内容，而且版本升级可能导致行为变化。手写解析虽然代码多一点，但完全可控。下面是我常用的参数解析函数：

function parseArgs(args) { const params = {}; for (let i = 0; i < args.length; i++) { const arg = args[i]; if (arg.startsWith('--')) { const key = arg.slice(2); const next = args[i + 1]; if (next && !next.startsWith('--')) { params[key] = next; i++; } else { params[key] = true; } } } return params; }

这个解析器支持--key value和--flag两种形式，足够覆盖大部分场景。如果Agent传了未知参数，解析器不会报错，而是忽略，这样Agent即使多传了参数也不会导致命令失败。这一点很重要，因为Agent有时会从其他命令的示例中复制参数，多传一两个无关参数是常有的事。

5. Agent调用CLI的典型场景与避坑指南

5.1 场景一：代码生成后的自动格式化与检查

这是最常见的Agent场景。Agent生成代码后，需要调用eslint --fix、prettier --write、gofmt -w等工具格式化。这里最大的坑是工具版本不一致导致格式化结果不同。我遇到过Agent在本地格式化通过，但CI环境格式化失败的情况，原因是本地prettier是2.x，CI是3.x，默认配置变了。

解决办法是在CLI里锁定工具版本，或者把格式化工具作为CLI的依赖打包进去。比如你的CLI叫my-cli，里面内置prettier，Agent调用my-cli format --file xxx.js，实际执行的是你打包好的prettier，不受环境版本影响。这样Agent的行为就完全确定了。

另一个坑是格式化工具的输出路径。有些工具默认输出到stdout，有些默认原地修改。Agent如果不知道这个差异，可能会拿到空输出或者意外修改文件。我的做法是：CLI统一行为，format命令默认原地修改，加--dry-run才输出到stdout。并且在帮助文档里明确写清楚。

5.2 场景二：数据库迁移与数据操作

Agent操作数据库时，最怕的是误删数据。我设计过一个数据库CLI，delete命令默认只生成SQL不执行，必须加--execute才真正执行。这样Agent即使误调用delete，也不会造成实际影响。如果Agent确实要执行删除，它需要显式传--execute，这个动作在Agent的决策链里会留下明确记录。

还有一个坑是连接超时。Agent调用数据库CLI时，如果数据库响应慢，CLI可能会挂起。Agent等不到输出，可能会重试，导致多个连接堆积。解决办法是给CLI加--timeout参数，默认30秒，超时后返回明确错误码。Agent拿到超时错误后，可以选择等待后重试，而不是立即重试。

5.3 场景三：文件系统操作与路径处理

文件操作看似简单，但跨平台时坑很多。Windows用反斜杠，Linux用正斜杠；Windows路径有盘符，Linux没有；Windows文件名不区分大小写，Linux区分。Agent如果生成的是Linux风格路径，在Windows上执行就会失败。

我的做法是在CLI里做路径归一化：所有输入路径先转成绝对路径，再根据当前系统转成对应格式。同时，list命令返回的文件路径统一用正斜杠，Agent处理时不需要关心平台差异。这个细节看起来小，但能减少大量跨平台问题。

5.4 常见问题速查表

这张表是我在实际项目中反复遇到的，基本上覆盖了80%的Agent调用CLI失败场景。每次遇到新问题，我都会往表里加一行，现在它已经成了我排查问题的第一入口。

6. 多Agent协作下的CLI编排策略

6.1 为什么多Agent需要CLI编排

单Agent调用CLI很简单，一个命令一个命令执行就行。但多Agent协作时，问题就复杂了。比如Agent A负责生成代码，Agent B负责测试，Agent C负责部署。它们之间怎么传递文件？怎么同步状态？怎么避免冲突？

我的经验是：用CLI作为Agent之间的契约。Agent A生成代码后，调用my-cli package --output /tmp/artifact.tar.gz打包。Agent B拿到这个路径后，调用my-cli test --input /tmp/artifact.tar.gz测试。Agent C调用my-cli deploy --input /tmp/artifact.tar.gz部署。每个Agent只需要知道CLI的输入输出格式，不需要知道其他Agent的内部逻辑。

这种设计的好处是解耦。Agent A可以换实现，只要它输出的artifact格式不变，Agent B和C就不受影响。同样，Agent B可以换测试框架，只要它调用的CLI命令不变，其他Agent也不受影响。

6.2 CLI编排的三种模式

我总结下来，多Agent场景下的CLI编排有三种模式，各有适用场景。

第一种是串行管道模式。Agent A的输出直接作为Agent B的输入，像Unix管道一样。这种模式最简单，但容错性差，中间任何一步失败，整个流程就断了。适合步骤少、依赖明确的场景。

第二种是状态机模式。每个Agent执行完CLI后，把状态写入一个共享存储（比如文件或数据库）。下一个Agent读取状态，决定是否继续。这种模式容错性好，中间步骤失败可以重试，但需要额外的状态管理逻辑。适合步骤多、需要人工介入的场景。

第三种是事件驱动模式。Agent执行CLI后发布事件，其他Agent订阅事件并触发自己的CLI。这种模式最灵活，但调试最复杂。适合Agent数量多、协作关系动态变化的场景。

我实际项目中用得最多的是状态机模式。因为Agent执行CLI时，失败是常态，状态机模式能让我清楚地知道每个步骤的执行结果，方便排查问题。

6.3 避免Agent之间的CLI冲突

多Agent同时调用CLI时，最容易出的问题是资源冲突。比如两个Agent同时写同一个文件，或者同时操作同一个数据库记录。解决办法有两个：一是CLI层面加锁，二是Agent层面加协调。

CLI层面加锁比较简单，比如my-cli write --file xxx --lock，执行时先获取文件锁，写完释放。如果锁被占用，返回LOCKED错误码，Agent等待后重试。这种方案适合文件操作。

Agent层面加协调需要引入一个协调者Agent，它负责分配任务和资源。比如协调者Agent维护一个任务队列，每个任务标记了需要操作的资源，协调者确保同一资源不会被两个任务同时操作。这种方案适合数据库操作。

我倾向于CLI层面加锁，因为实现简单，而且不依赖Agent之间的通信。Agent只需要处理LOCKED错误码，重试逻辑是通用的。

7. 从CLI到Agent Skill：能力封装的进阶思路

7.1 CLI和Agent Skill的关系

最近热搜词里经常出现agent skill、skill和agent的区别，我理解大家是在纠结：到底该把能力封装成CLI，还是封装成Skill？我的看法是：CLI是Skill的底层实现，Skill是CLI的上层抽象。

举个例子，你有一个deploy命令，接受--env、--version、--region参数。Agent要调用它，需要知道这些参数的含义和取值。如果你把它封装成Skill，Skill描述里会写："部署应用到指定环境，需要提供环境名、版本号和区域。"Agent看到这个描述，就知道什么时候该用这个Skill，以及需要准备什么参数。

所以CLI解决的是"怎么执行"，Skill解决的是"什么时候执行、需要什么输入"。两者不是替代关系，而是互补关系。我通常先写CLI，确保执行逻辑稳定，然后再基于CLI写Skill描述，让Agent能自动发现和调用。

7.2 如何把CLI封装成Agent可发现的Skill

封装Skill的关键是描述要准确、参数要明确、示例要完整。下面是一个Skill描述的模板：

name: deploy description: 部署应用到指定环境 parameters: - name: env type: string required: true description: 环境名，可选值：dev, staging, prod - name: version type: string required: true description: 版本号，格式：v1.2.3 - name: region type: string required: false default: cn-hangzhou description: 部署区域 command: my-cli deploy --env {{env}} --version {{version}} --region {{region}} examples: - input: "部署v1.2.3到dev环境" command: my-cli deploy --env dev --version v1.2.3

这个描述里，command字段直接给出了CLI调用模板，Agent只需要填充参数就能执行。examples字段给出了自然语言到命令的映射，Agent可以学习这个映射关系。我实测下来，有了完整的Skill描述，Agent调用CLI的成功率能从60%提升到90%以上。

7.3 Skill的版本管理与CLI的兼容性

Skill和CLI的版本必须同步管理。如果CLI升级了，参数变了，Skill描述没更新，Agent就会传错参数。我的做法是：CLI的版本号嵌入在--version输出里，Skill描述里引用这个版本号。Agent调用Skill前，先执行my-cli --version检查版本，如果版本不匹配，提示需要更新Skill。

这个机制看起来麻烦，但能避免很多"参数对不上"的问题。我有个项目，CLI从v1升级到v2时，把--env改成了--environment，结果Agent还在用旧参数，导致部署失败。后来加了版本检查，问题就再没出现过。

8. 我踩过的坑和最终沉淀下来的经验

8.1 坑一：CLI输出混入日志导致Agent解析失败

早期我写CLI时，习惯用console.log输出所有信息，包括调试日志。结果Agent解析JSON时，前面混了一行Connecting to database...，直接解析失败。后来我强制规定：stdout只输出结构化数据，所有日志输出到stderr。这个规定看起来简单，但执行起来需要自律，因为调试时很容易随手写console.log。

我的解决办法是封装一个logger工具，所有日志走logger.info、logger.error，这些方法内部写到stderr。console.log只在最终输出结果时使用。这样即使代码里有很多日志，也不会污染stdout。

8.2 坑二：CLI退出码不规范导致Agent误判

Agent判断CLI执行成功还是失败，主要看退出码。如果CLI不管什么错误都返回exit code 1，Agent就无法区分是参数错误还是网络错误。我后来规定：0表示成功，1表示参数错误，2表示网络错误，3表示权限错误，4表示资源不存在，5表示冲突。Agent根据退出码决定重试策略：参数错误不重试，网络错误重试，权限错误提示用户，资源不存在创建资源，冲突等待后重试。

这套退出码规范我用了半年，Agent的重试逻辑变得非常清晰，不再出现"无限重试参数错误"的情况。

8.3 坑三：CLI依赖环境变量导致Agent环境不一致

有些CLI依赖环境变量，比如DATABASE_URL、API_KEY。Agent执行CLI时，如果环境变量没设置，CLI就会失败。我遇到过Agent在本地跑得好好的，部署到服务器就报DATABASE_URL not set。

解决办法是：CLI必须支持通过参数传入配置，环境变量只作为默认值。比如my-cli query --db-url xxx，如果没传--db-url，才读DATABASE_URL。这样Agent可以显式传配置，不依赖环境变量。同时，CLI启动时检查必要配置，如果缺失，返回明确的错误码和提示，而不是直接崩溃。

8.4 最终沉淀：Agent友好CLI的检查清单

每次我写完一个新CLI，都会对照这个清单检查一遍。清单不长，但每一条都是踩坑换来的。

• [ ] 所有命令支持--json输出
• [ ] 所有命令默认非交互，交互需显式开启
• [ ] 退出码规范：0成功，1参数错误，2网络错误，3权限错误，4资源不存在，5冲突
• [ ] 错误信息包含修复建议
• [ ] 创建类命令支持--if-not-exists
• [ ] 删除类命令支持--ignore-missing
• [ ] 日志输出到stderr，数据输出到stdout
• [ ] 配置支持参数传入，环境变量仅作默认值
• [ ] 提供--version输出，格式固定
• [ ] 提供--help输出JSON格式的命令列表

这个清单我放在项目根目录的CONTRIBUTING.md里，每次提交代码前过一遍。看起来繁琐，但能避免90%的Agent调用问题。

9. 关于CLI-Anything的未来扩展方向

"CLI-Anything"这个思路往下走，我觉得有几个方向值得尝试。第一个方向是CLI自动生成。给定一个OpenAPI规范或者数据库Schema，自动生成对应的CLI命令。这样Agent需要操作新服务时，不需要等工程师写CLI，直接生成就能用。第二个方向是CLI能力发现。Agent执行任务时，自动扫描当前环境有哪些CLI可用，根据任务需求选择合适的CLI。第三个方向是CLI组合编排。Agent不直接调用单个CLI，而是描述任务目标，由编排层自动组合多个CLI完成。

这些方向我都在小范围试过，目前最成熟的是CLI自动生成。我用OpenAPI生成器做过一个原型，给定Swagger文档，自动生成my-cli <resource> <action>格式的命令，Agent调用成功率还不错。但生成的CLI在错误处理和幂等性上还需要人工调整，完全自动化还有距离。

如果你也在做Agent相关的CLI工具，我的建议是先从一个小场景切入，把上面提到的原则和检查清单用起来，跑通一个完整流程后再扩展。CLI这东西，看起来简单，但要做到Agent友好，细节非常多。我到现在也不敢说自己的CLI设计完美，每次新项目都会发现新的坑。但正是这些坑，让最终沉淀下来的经验变得有价值。