想象一下你的日常工作：这个礼拜把一批 Kubernetes 集群拉起来，跟私有链接、配额和 Terraform 的各种坑较劲；下个礼拜又开始跑新一轮模型评估，跟 grader、配置和 PyTorch 搏斗。等这一切终于跑通、模型顺利发布，下一个循环立刻开始，你回到原点，重新拧一遍一模一样的发条。

这正是 OpenAI 工程师 Jeremy Lewi 过去职业生涯的写照。他把这种状态叫作「turning a crank」，拧发条。他在最近一篇开发者博客里写道：云基础设施和 Kubernetes 本意是让部署和运维更简单，结果我们得到的是一整个庞大到要靠 CNCF landscape 才画得下的工具生态。解决一个问题，往往又制造出一个新问题，选工具、学工具、维护工具。

于是 Jeremy 换了个思路：把重复的机械劳动交给 Codex，把自己从「拧发条的人」变成「造发条的人」。他把这套实践沉淀成了一个开源项目，Runme。

Runme：给 Codex 配一个会记笔记的工作台#

Runme 是一个开源 Web 应用，专门用来跟 Codex 一起写笔记本。你可以把它理解成智能体版本的 Jupyter 或 Colab：它支持 Markdown、代码单元格和 HTML，能把指令、命令、执行结果、表格和图表放进同一份文档里。

Jeremy 做 Runme 的目标很明确，就三件事：

  1. 收集和整理围绕一个工作流的上下文。
  2. 守住审核与审批的边界，让关键决策始终由人拍板。
  3. 用上一次运行学到的东西，改进下一次 Codex 的运行。

这三点恰好对应智能体落地时的三个老大难问题：上下文从哪来、权限怎么收、经验如何复用。Runme 的答案不是另起炉灶去造一套重基础设施，而是把这三件事都塞进一个「活的文档」里。

一次评估是怎么跑起来的#

以跑评估为例。OpenAI 发布新模型和新特性时，需要跑评估来确认它们符合预期。Jeremy 的做法是：新建一个 Runme 笔记本，写一小段目标概要：

# Goal: 对当前模型跑一次评估
- 先回顾上一次运行，理解工作流
- 在本笔记本里写出详细计划
- 等我审批通过后再开始
- 记录你执行的命令、输出，以及你如何解读结果

然后让 Codex 把这段目标当成任务起点：读目标、写计划、等审批。Codex 一边执行一边更新笔记本；计划写完，Jeremy 先审一遍，不合适就改。

有意思的地方在于，Jeremy 说人工真正有价值的参与，往往不是写代码，而是帮 Codex 在几个方案之间做选择：用哪套评估系统、要不要新开基础设施、现有资源到底够不够用。这些是判断力层面的东西，恰恰是模型最难替人做决定的地方。

执行过程中，Jeremy 有时只从手机上看进度，偶尔在 Codex 卡住时推它一把。比如某个开发环境因为配额耗尽而建不起来，他会建议复用现有的环境，或者换个已批准的方案。

最后产出的，是一份记录了完整步骤、连同那些走不通的死胡同的笔记本。收尾之前，他还会跟 Codex 一起把那些「本该消失在对话里」的决策捞回来：为什么选了 A 而不是 B、现在更推荐哪种做法、下次应该怎么做。

让上下文可被发现，而不只是被写下#

很多智能体工作流的问题不在「没记录」，而在「记了也没用」。信息散落在终端历史、Slack、runbook、文档和仪表盘里，下次要用时根本找不到。

Runme 的解法很轻：笔记本直接存到 Google Drive，团队里的人用熟悉的工具就能找到和分享成果，不必再引入一套新的文档仓库。每份笔记本还会生成一个配套的 Markdown 索引文件（*.index.md），Google Drive 可以索引它。这样一来，智能体下次需要例子、操作上下文或某次运行的结果时，就能自己搜到。

Jeremy 的观察一针见血：文档有用的难点，从来不是「证明它有用」，而是「让它在工作发生的当下，足够便宜地生成出来」。

WebMCP：把工具能力留在浏览器里#

Runme 和智能体之间的交互，走的是 WebMCP。应用加载时，会在浏览器里注册一批工具，智能体可以用它们来读取 Runme 的操作说明、执行受控的 JavaScript 程序去读写笔记本内容、查阅应用文档。

这个架构选择的动机非常实际：Runme 是一个纯客户端的静态网站。如果为了暴露一个传统的 MCP endpoint 而单独加一个服务器，等于凭空引入一套基础设施和运维复杂度，还改变了笔记本数据的处理位置。WebMCP 让应用直接在浏览器里把能力暴露出去，省掉了这层负担。

真正的飞轮：让每一次运行喂养下一次#

把上面的环节串起来，你会看到一条清晰的反馈闭环：

跑评估 → Codex 按已审批的计划执行 → 记录命令、结果和决策 → 沉淀成可复用上下文 → 下次评估从现有上下文起步，跑得更快。

这就是 Jeremy 说的「collect and curate」：每一次重复劳动，都是一次把工作方式记录下来的机会。而工作流每改进一轮，产生的上下文就更值钱，反过来又让 Codex 处理下一版任务更顺手。这是一个能自我加速的飞轮。

写在最后：拿回那些「心跳」#

文章结尾，Jeremy 说了一句很戳人的话。他职业生涯很大一部分时间，都花在琢磨那些能驯服别扭机器的咒语上。云和 Kubernetes 承诺让一切更简单，结果带来了更庞大的工具迷宫。

Codex 对他的吸引力在于：它能把重复的运维工作接过去，同时让他在真正重要的决策里保持在场。他半开玩笑地说，希望拿回那些被浪费的「心跳」，然后花在陪狗玩上。

这句话点破了 AI 编程工具真正的价值主张。它不是把人从工作里赶出去，而是把人从「拧发条」里解放出来，送回到那些需要判断、需要拍板、需要人的位置上去。Runme 的价值也正在于此：它把「人类决策」和「机器执行」之间的那条线划得清清楚楚，又让每一轮执行都为下一轮积累养料。

参考来源：Jeremy Lewi《Automating repetitive work at OpenAI with Codex》，OpenAI 开发者博客，2026 年 8 月。 原文链接：https://developers.openai.com/blog/automating-repetitive-work-at-openai-with-codex