真正好用的 Codex 工具，不是把一切都接进来，而是先揉成 CLI
Nick Baumann 讲了一个很实用的经验，给 Codex 最好的工具往往不是直接塞原始系统访问，而是做一层 bespoke CLI，把噪音压掉，把输入输出变成稳定命令。重点不只是“能接入”，而是让 agent 真正能反复、可靠、低摩擦地调用。
来源参考： X
很多人给 agent 配工具，第一反应都是“接更多系统”。但 Nick Baumann 这条分享点出了一个更实在的判断，对 Codex 这类代理来说，真正好用的工具不一定是接入能力最强的那个，而是最像命令行的那个。
这听起来很朴素，甚至有点反直觉。大家这两年一直在讲 MCP、connector、统一工具协议，好像只要把 Slack、Linear、Sentry、数据库、文档系统都接进去，agent 自然就会变强。可一旦你真开始高频使用，就会发现“能访问”只是第一步，后面更麻烦的是输出太大、噪音太多、结构不稳、错误不一致。这些问题对人类还能凑合，对 agent 却是持续掉链子的来源。
核心事实
Nick 的做法很简单，也很值得抄。他不是排斥 connector 或 MCP，而是在这些接入层旁边，再做一层专门给 Codex 用的小 CLI。要求也不复杂，几个关键词已经把精髓说完了，flags、stable JSON、predictable errors、help screen。
为什么这种形态特别适合 Codex？因为 Codex 天生就擅长这一套工作流。它会搜，会缩小范围，会重试，会 pipe，会把大结果写进文件，会先看 --help，再根据上一步输出继续拼下一条命令。换句话说，你给它一个“命令形状”的接口，它就会像一个熟练的终端用户那样工作。
Nick 举了三个很典型的例子。
一个是 codex-threads，把历史线程归档做成本地可搜索索引，让 Codex 不用直接在噪音巨大的 session 原始数据里乱翻，而是通过 search、resolve、read 这些命令去找以前哪个线程做得好，再把模式沉淀成 skill。
另一个是 slack-cli。Slack connector 本身能用，但如果真要让 Codex 反复研究某个决策为什么定下来、某个 launch channel 里评审到底达成了什么共识，命令式工具会顺手得多。你可以让它先搜，再定位 permalink，再读 thread，再拉前后文，并且整个过程都是稳定 JSON 输出。
还有一个是 typefully-cli。这更能说明问题的核心，很多时候你并不是要 agent 学会整个 API，而只是想让它掌握你真正高频用的那几个动作，比如列草稿、读草稿、创建草稿、传图、读排期。把这些动作固化成一个小而稳的 CLI，比每次都把 API 文档重新喂一遍高效太多。
影响解读
我很认同这套思路，因为它把“给 agent 工具”这件事，从接口接入问题，往前推了一层，变成了交互设计问题。
MCP 或 connector 解决的是 access，CLI 解决的是 usability。前者回答“能不能接到”，后者回答“agent 能不能稳定地把它用好”。这两个问题看起来接近，实际上完全不是一个层级。
很多 agent 项目之所以越做越重，一个常见原因就是工具作者默认 agent 和人类一样，能在嘈杂上下文里灵活取舍。但现实是，agent 更像一个极其勤奋、但对接口质量高度敏感的执行器。你让它在结构混乱的原始输出里反复打捞信息，它当然也能做，只是成本高、失败率高，而且线程会越来越脏。
所以这条经验真正有价值的地方，是它提醒大家不要把“全接入”误当成“全可用”。如果你反复把同一类文档、日志、对话、API 怪脾气交给 Codex，说明你要的已经不是上下文补丁，而是一个命令。
再往前一步，Nick 还提到一个我觉得更重要的点，CLI 外面最好再包一层 skill。因为光有二进制还不够，你还需要把操作约定写清楚，比如默认用 JSON、长文本用 body file、哪些动作默认不允许直接执行、哪些涉及发布删除覆盖必须单独批准。这相当于把“工具能力”再加工成“可持续复用的代理习惯”。
风险与不确定性
当然，这条路也不是没有代价。
第一，定制 CLI 本身有维护成本。你今天把高频操作封成一个舒服的命令，明天上游 API 改字段、权限模型变了、认证方式调整了，还是得有人修。它不是零成本，只是把复杂度从 prompt 和线程里，挪到了一个更容易控制的软件层。
第二，CLI 也不是权限绕过。Nick 这一点说得很清楚，像 slack-cli 依然走的是批准过的 access model。这个边界很重要。因为一旦团队把“给 agent 做命令”理解成“偷偷开后门”，整套方法就会很快从提升效率变成制造风险。
第三，这种方式更适合高频、重复、可抽象的工作流，不适合所有场景。有些任务天然探索性强，需求变化大，做成 CLI 反而会把问题过早固化。什么时候该写命令，什么时候该继续直接给上下文，这还是需要经验判断。
参考链接
如果你在搭自己的 agent 工具栈，这条分享很值得反复看。它不是在讲一个花哨框架，而是在讲一条非常朴素但很少有人真正执行到位的原则，先把接口揉成 agent 擅长消费的形状，再谈让 agent 替你做更多事。
我越来越觉得，未来 agent 基础设施里最值钱的部分，不一定是“接了多少系统”，而是有多少能力被你压缩成了干净、稳定、可组合的命令。