定制化 CLI：提升 AI 智能体任务执行效率的最佳实践

当工具可以被表达为精确的命令时，Codex 在使用这些工具方面表现得非常出色。

这听起来似乎显而易见，但它改变了我对于如何让 Codex 访问我日常使用工具的思考方式。连接器或 MCP (Model Context Protocol) 服务器固然是获取访问权限的好方法，我也会通过这种方式使用 Slack、Linear 和 Sentry。但有时，原始输出的数据量太大、太杂乱，或者格式太别扭，不适合直接交给 Codex 处理。在这些情况下，我通常更倾向于使用一种“侧边工具”：一个带有参数标志、稳定的 JSON 输出、可预测的错误提示以及帮助界面的命令行工具 (CLI)。

这为 Codex 提供了一个它已经非常擅长使用的界面。

它可以进行搜索、缩小范围、重试、通过管道传输输出、将大量结果写入文件、检查 --help 帮助信息，并根据上一个结果组合下一个命令。整个过程几乎没有冗余的仪式感。

如果你想要获取具体的实操指南，我在这里写了如何让 Codex 构建这样一个工具：

为 Codex 创建一个 Agent 友好的 CLI： https://developers.openai.com/codex/use-cases/agent-friendly-clis

第一步是使用 Codex 创建 CLI。第二步是将该 CLI 封装成一项“Skill”，这样未来的 Codex 会话就能知道首先运行哪些命令、需要拉回多少输出，以及哪些操作需要人工批准。

以下是我实际使用的三个 CLI 工具。它们并不是连接器的替代品，而是作为连接器的补充，当我希望 Codex 在不将整个数据源拖入对话线程的情况下处理大型数据源时，它们就派上用场了。

1. Codex 历史会话管理 (Codex Threads)

我旧的 Codex 会话中充满了有趣的模式，我希望从中学习并将其固化为未来有用的 Skill 和自动化流程。

我经常让 Codex 引用它自己的历史会话。我还运行着一个自动化程序，扫描最近的会话，寻找值得保存为 Skill 的模式。

原始的会话存档对于直接交给 Codex 来说太嘈杂了。它包含了工具输出、部分尝试以及仅在当时有用的上下文。虽然你可以告诉 Codex 直接读取它的会话，但这确实可行，但如果你经常这样做，速度会变慢且干扰增多。

因此，我使用 codex-threads。

codex-threads --json sync
codex-threads --json messages search "build a CLI" --limit 20
codex-threads --json threads resolve "tweet idea"
codex-threads --json threads read <session-id>
codex-threads --json events read <session-id> --limit 50

它在本地维护一个 ~/.codex/sessions 的可搜索索引，然后为 Codex 提供搜索、解析和读取旧线程的命令。

当我想要将一个会话转化为一项 Skill 时，这尤其有用。许多优秀的 Skill 都始于“找到那个进展顺利的会话，然后保留那个模式”。

2. Slack 检索 (Slack CLI)

当答案埋藏在我无法手动找到的线程中时，我会要求 Codex 读取 Slack：例如为什么某个应用服务器的授权决策被做出、其他人是否也遇到了同样的本地开发故障，或者评审人员在发布频道中已经达成了什么共识。

Slack 连接器很有用，但当 Codex 拥有“命令式”工具时，重复的研究工作会变得更加容易：

slack-cli search "app server auth" --all-pages --max-pages 3 --json
slack-cli resolve-permalink "https://openai.slack.com/archives/..."
slack-cli read-thread L143 123522523239.633199 --json
slack-cli context R152 25723525099.626199 --before 5 --after 5 --json

这让 Codex 能够广泛搜索、定位精确的线程、提取周边上下文，并引用关键消息。

slack-cli 仍然使用经过批准的 Codex 应用网关。它不是权限绕过工具，而是相同的访问模型，只是被塑造成了 Agent 可以组合使用的命令。

3. 内容发布管理 (Typefully CLI)

我使用 Codex 编写和安排了大量内容，并使用 Typefully 进行管理。

Typefully 有一个很好的 API，但我不需要 Codex 每次在协助我处理草稿时都重新学习整个 API。我只需要我实际使用的那几个操作：

typefully-cli --json drafts list --social-set <id> --limit 20
typefully-cli --json drafts read --social-set <id> <draft-id>
typefully-cli --json drafts create --social-set <id> --body-file draft.json
typefully-cli --json media upload --social-set <id> ./image.png
typefully-cli --json queue schedule-read --social-set <id>

因此，我让 Codex 阅读了 API 文档，并构建了 typefully-cli，这是一个我可以在任何仓库中运行的小型 Rust 二进制文件。

围绕它构建的“Skill”与二进制文件本身一样重要。它告诉 Codex 使用 JSON 格式、默认创建草稿、当 Shell 引用变得麻烦时使用 body 文件，并且除非我明确要求，否则绝不发布、排期、删除或覆盖任何内容。

最后一部分是核心所在。我不希望每次请求帖子修改建议时，都要重复输入“不要发布这个”。

总结与建议

核心逻辑非常简单：如果我发现自己不断地向 Codex 提供相同的文档、导出文件、日志或奇怪的 API 解释，我通常会停止解释，转而给它一个命令。

然后，我将该 CLI 封装在一个 Skill 中，以便 Codex 记住如何使用它。如果你想让 Codex 为你自己的工具构建一个这样的 CLI，我在这里写了操作指南：

使用案例：https://developers.openai.com/codex/use-cases/agent-friendly-clis

• 原文链接： x.com/nickbaumann_/statu...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～