API 命令行与编程 Agent 应如何选用

OpenAI CLI、Codex CLI、Claude Code 都在终端里运行，但它们解决的不是同一类问题。原文最重要的判断是：需要 AI 读仓库、改代码、跑测试，就用编程 Agent；需要在脚本里调用 API，就用 OpenAI CLI。

对前端和全栈开发者，这个区分直接影响 CI 的可控性、脚本维护成本和账单。不过，作者主要整理了文档与价格，并没有做三款工具的对照实测。工具定位可以参考，性能和省钱结论则要分开看。

都叫 CLI，为什么只有两个会改代码

按原文描述，OpenAI CLI 是一个用 Go 编写、采用 Apache 2.0 许可证的 API 客户端。自行编译需要 Go 1.26+；截至作者写作时，仓库约有 1.1k stars、575 次提交，最新版本是 2026 年 10 月 23 日发布的 v1.40.5。

它把 REST API 映射成 openai <resource> [subresource...] <command> [flags...]，覆盖 Responses、图像、文件、批处理、模型、音频与语音、本地 token 计数、webhook 测试，以及组织用量报告等管理接口。

列表很长，但没有 Agent 循环。也就是它不会拿到任务后，自行决定读哪些文件、调用哪些工具、接着做什么。你发请求，它返回结果。

安装可以用 brew install openai/tools/openai，也可以用 go install 'github.com/openai/openai-cli/cmd/openai@latest'；openai help setup 用来保存 API key。

Codex CLI 和 Claude Code 则是编程 Agent，能围绕仓库执行多步任务。原文提到的 HN 讨论有 235 分、111 条评论，其中不少困惑来自命名：用户输入 openai，期待得到编程助手，看到的却是 API 资源列表。

先判断需要一次 API 操作，还是需要一个自主执行任务的 Agent，再选工具。

脚本需要的可控性，体现在哪些细节里

原文没有否认 Agent 可以进入自动化流程。codex exec 把进度写到 stderr，把最终消息写到 stdout；claude -p 可以读取 stdin，因此 git diff main | claude -p "..." 这样的用法成立。作者还指出，两者都有支持 JSON 输出和 schema 的无界面模式。

差别在于，接入管道后，Agent 仍会决定执行多少轮、调用什么工具、消耗多少 token。

作者引用 Claude Code 文档提醒：未加 --bare 的 -p 会话会运行项目 .claude/settings.json 中的 hooks，并连接 .mcp.json 中配置的服务器，甚至可能发生在从未信任过的目录里。文档说，未来某个版本会让 --bare 成为 -p 的默认行为，但没有给出具体版本。

Codex 的 exec 默认使用只读沙箱；--sandbox danger-full-access 则只适合受控环境。这些配置都有实际用途，也说明 Agent 的执行范围需要额外管理。

OpenAI CLI 的优势，是请求和输出更容易接进现有脚本。下面这组命令分别展示逐行 JSON、文件重定向和字段提取：

openai models list --format jsonl | jq '.id'
openai files list --format json > files.json
openai files get file-example --transform filename --raw-output

重点看第三行：--transform 接受 GJSON 路径，简单取字段时可以省掉 jq。

错误默认以可读摘要写入 stderr，--format-error json 可以输出 API 错误详情；接受 JSON 的参数支持 @path，例如 --input @prompt.txt，可以把长提示词留在文件里。重定向后仍要检查退出状态，因为失败请求可能留下不完整文件。

这里的可控性也有边界：调用哪个接口、怎样处理结果更明确，不代表模型输出必然正确，仍需校验内容和格式。

省钱要看模型和批处理，不能只看 CLI

作者最想使用的是 Batch。下面两条命令分别创建任务，并等待结果写入指定目录：

openai batches create --input-file-id file-example --endpoint /v1/responses --completion-window 24h
openai batches wait batch_example --output-dir ./results

要看第一行的 --completion-window 24h：它适合不必立即拿到答案的工作。原文引用的价格页显示，Batch 价格是标准 API 的一半，但文章没有提供实际完成耗时或失败率测试。

另一个提醒来自 README 的冒烟测试：示例选择了 --model gpt-5.5。按作者引用的价格，每 1M tokens，gpt-5.5 输入为 $5.00、输出为 $30.00；gpt-6-luna 输入为 $0.10、输出为 $0.50。两者输入单价相差 50 倍，输出相差 60 倍。

这个差价成立，不代表所有任务都能按同样比例省钱。作者认为工单分类、日志摘要、文本字段提取可以尝试便宜模型，但没有提供准确率或返工成本对照。

单价便宜多少可以算出来，完成同一任务便宜多少需要测出来。

计费入口也要分清：原文按 README 只记录 API key 的情况判断，OpenAI CLI 应按 API 用量预算，ChatGPT Plus 不覆盖这部分。作者还提醒，GPT-5.5 已于 2026 年 10 月 14 日退出使用 ChatGPT 登录的 Codex，会话使用 API key 时仍可用。上述价格和可用性都是原文时点的信息。

我的判断

作者说对的一点，是把选型问题落到了执行边界。Makefile、cron 和 CI 中的一次模型调用，通常更需要明确的参数、输出格式与退出状态；仓库级修改则需要 Agent 的多步执行能力。

但 OpenAI CLI 是否优于 curl 或 SDK，要看工作放在哪里。CLI 提供命令补全、文件路径补全、无需 API key 或网络也能查看的 --help，能省去手写 /v1/files 上传请求等细节。如果团队已有稳定的 curl 脚本，替换收益未必大；如果调用已经在 Node 服务内部，SDK 往往更方便沿用异常处理和业务代码。这是工程取舍，原文没有给出维护成本对照。

API key 出现在进程列表中的问题，也取决于命令怎样传递凭据，不能据此认定所有 curl 用法都有问题。

至于 Codex CLI 和 Claude Code，作者建议优先考虑已经支付的 $20 订阅，但文章没有比较复杂修改成功率、审查质量或总耗时。因此，它能帮助读者分清工具类别，还不足以替团队决定哪款 Agent 更适合日常开发。

能拿来做什么

• 给 Makefile 或 CI 增加日志摘要、文本分类任务时，先用 openai models list 查看模型，再拿有代表性的输入比较质量与成本，避免把 README 中的 gpt-5.5 示例直接固化进脚本。
• 把 API key 通过密钥管理系统注入 OPENAI_API_KEY，在 CI 设置 OPENAI_CLI_NO_UPDATE_CHECK=1，并在消费重定向文件前检查退出状态和结果格式。
• 将无需实时返回的批量分类、摘要或字段提取任务放进 Batch，明确输入文件、结果目录及失败处理，再评估半价是否能转化成实际节省。
• 需要读仓库、改代码、跑测试时使用 Codex CLI 或 Claude Code；接入自动化前，检查 --bare、hooks、MCP 配置和沙箱权限，明确一次任务允许执行哪些动作。