有人把一枚临时管理 token、一个 API key、一串 YouTube 视频 ID、一份内容模型的 TypeScript schema，再附上官方文档，一起丢给 Codex，然后起身走开。

它自己把每条视频抓下来，把元数据映射进内容模型，再逐条导入。一遍过。没有中途纠偏，没有重试循环，也没有留下需要人接手的烂摊子。

到这一步，已经足够让人闭嘴了。真正让人愣住的，是它接下来那件没人要求它做的事。

导入跑完，Codex 自己写了一个 CLI。它还在生成的 SKILL.md 里，把这把 CLI 怎么用一步步记录下来，末尾补了一行：每次运行后记得轮换管理 token。

它替下一次的自己造了一件工具，也替下一次留好了接口。

写下这段经历的人叫 Tim Benniks，是 Contentstack 的开发者体验负责人。他说自己没想到 Codex 会去考虑第二次导入。这句话点出了分量所在：我们习惯交付的是「这次做完了」，它交付的是「下次这样就能做」。

做完一件事，和让它下次更好做，是两种产出#

临时脚本和可复用接口之间，隔着一次没人要求的抽象。

人做重复的数据录入，通常抓起来就干：临时写几行，跑完，删掉，下次再写一遍。没人会为「下次」多想一步，因为想这一步本身有成本，而下一次来不来还不一定。

Codex 这次越过了那条线。具体收益可以量化：至少省下一小时手工录入，字段映射零返工，富文本块没错位，视频 ID 没漏。

但真正值钱的不止这一小时，是它顺手留下的那套东西。下次有新视频要加，机器上已经有一个能直接调用的命令，旁边还有一份说明，告诉后来者（也包括它自己）该怎么跑。原本一小时的活变成几分钟。一个晚上沉淀下来的东西，在之后每一次运行里继续打折扣。

我的判断是，这跟模型「心情好」多干一点关系不大。它会这么做，是因为 skill 这个容器就在那儿。当 agent 知道「技能」是一种能写出来的东西，它就会把做过的活往那个形状里收。会读 skill 的 agent，早晚会开始写 skill。

它为什么会想到「下一次」#

Codex 的 Skills 是 2025 年 12 月作为实验特性上线的。2026 年初，SKILL.md 变成了一个开放标准，Claude Code、Gemini CLI、Cursor、GitHub Copilot 等二十多个工具都能直接读同一份文件。

机制不复杂，但设计得克制。启动时，Codex 只读每个已安装 skill 的 name 和 description，约占上下文的 2%。只有当你这次的任务描述和某个 skill 的触发条件对上，它的完整内容才会被加载进来。对不上就什么都不加载，上下文保持干净。

这一点和 MCP 的默认行为正好相反。一个 MCP server 一旦挂上，它注册的工具定义每次会话都在吃上下文，不管你这次用不用得上。

更关键的是，skill 是可写的。它既是喂给 agent 的输入，也是 agent 能产出的东西。一个会读说明书的 agent，迟早会开始写说明书。这次 Codex 是在没有任何人提示的情况下迈过了那一步。

MCP 是不是被问倒了#

眼下的主流叙事很干脆：MCP 是 agent 的集成层，句号。

这次演示的是另一条路径。一个写得清楚的命令行工具，配上一个说清它怎么用的 skill 文件，可能就够了。在某些场景里甚至更好。

拿 CLI 去比 MCP server，它天生就占几样便宜：机器上本来就躺着的 grep、find、jq 这些现成工具；可以互相拼接的参数；能直接过滤、再加工的文本输出，不用为它专门搭一层管道；以及几乎为零的上下文开销，对面那是一个注册了十五个工具的 server，每次开场都要收费。

不过别急着把 MCP 判死。

Maxim 有一篇文章把这个争论的层次讲得比大多数人都清楚：skills 是引导层，MCP 是执行层。「Skills 是菜谱，MCP 是厨房。」 一个 skill 可以写着「去分析库里查用户留存」，但真正维持连接池、处理鉴权、执行查询、把结果结构化返回的，是 MCP。

数字也不支持「替代」这个说法。SkillsMP 市场上的 skill 已经超过十一万个，OpenAI 把 Skills 收进了 Codex CLI，Anthropic 的产品线也全线接入。如果 skills 真把 MCP 杀死了，MCP 的采用曲线该走平甚至掉头。事实是两条曲线都在往上走。

更准确的说法是：skills 吃掉的是那些一开始就过度设计的 MCP 集成，也就是无状态、跑一次就完、被硬包成 server 的那一类。MCP 没有消失，它退到了自己真正该站的位置：有状态的连接、鉴权、实时数据、多步骤编排，以及企业级集成。

Hacker News 上 Skills 正式登陆 Codex 那条帖子拿到 304 分、130 条评论。有一条被顶得很高：「skills 正在变成标准，长期看它比 MCP 重要得多。」同一批讨论里还有人说得更直白：「用对了 skills，Codex 对我来说就是比 Claude Code 好。」

什么时候该用 CLI 加 skill，什么时候该上 MCP#

场景更合适的选择原因
一次性或批量的导入、迁移、数据清洗CLI + skill无状态，可组合，上下文便宜，跑完就能丢
活儿能靠机器上已有的 grep / jq / curl 拼出来CLI + skill不必引入新协议，agent 本来就熟悉这些工具
需要持久连接、OAuth、实时数据MCP连接生命周期和鉴权交给协议托管
多步骤编排，还要给别的客户端复用MCPtools / resources / prompts 三个原语天然适配
团队共享、要策展一套受控的工具集MCP权限、可见性、审计这些 CLI 给不了

这张表有个前提得说清楚。选择哪一档，跟你喜不喜欢 MCP 没关系，跟这件活要不要那层治理有关系。批量导入不需要鉴权生命周期，硬套一个 server 就是给自己找维护成本；反过来，需要跨客户端复用的受控工具集，写成十个散落的 shell 脚本，迟早会失控。

这件工具，是谁在给谁造#

还有一个容易滑过去的细节。agent 在 skill 里留的那行「每次跑完轮换 token」，把凭据卫生写进了流程本身。

它是从文档里读到的，还是自己推出来的，不重要。重要的是它把这一步留在了给下一个自己的说明里。一个会主动提醒自己换钥匙的 agent，说明它已经把自己当成这件活长期的执行者，而不是一次性的手。

另一面也随之出现：你交付的东西不再只是一段代码，而是一条以后会反复运行的路径。这把 CLI 写得脆不脆，命名清不清楚，出错时给的提示够不够明白，决定的不是今天省下的那一小时，是这条路径往后每次运行稳不稳。

所以我的建议是，把 agent 自己造的工具当成一个 PR 来审。它写的说明就是文档，它临时写的脚本，很可能变成下个月的依赖。今天没人看的十行 shell，明天可能就是某个人的 on-call。

我的看法#

这场争论真正的变化，是集成方式从「协议优先」退回了「接口优先」。

先问一句：这件活有没有一个足够清楚的命令行界面就能说明白？如果有，就不要为了显得正规去写一个 MCP server。对个人开发者和小团队，大部分批量任务都落在这一档。

MCP 的价值集中在 CLI 给不了的那一层：鉴权、权限、审计、策展。这些对大组织是真需求，对两个人的项目是纯负担。判断标准就一条，你的活到底需不需要那层治理。

更值得留意的是另一个走向。当 agent 开始主动把成果沉淀成 skill，仓库里迟早会长出一批它自己写的工具。这些工具的代码所有权归谁、谁来审、多久没人用就该淘汰，这些问题现在都还没有答案。我们刚学会让 agent 写业务代码，下一步要面对的，是它开始给自己的工具箱做设计。

参考来源#