AREX Feed Article
OpenAI 工程师披露用 Codex 自动化内部评测，开源 notebook 应用 Runme
OpenAI 官方工程博客（learn.chatgpt.com/blog）上线了一篇由工程师 Jeremy Lewi 撰写的文章《》，以内部实践者的身份披露：跑新模型、新功能的评测（evaluation）这类重复工作，现在交给了 Codex。页面没有标注发布日期，长期关注 AI 评测的 于 UTC 时间 8 月 26 日 15:03 发布推文介绍这篇文章，可确认它在 8 月 26 日已在线上；同一文章也出现在 。
文章里最值得关注的是两个新东西：开源 notebook 应用 Runme 和 WebMCP 机制。Runme 类似 Jupyter，但 notebook 文件就是 Markdown；WebMCP 让应用在浏览器里注册工具供 agent 调用，不必为每个应用架一台服务器来暴露传统 MCP 端点。文章配图展示了一次真实评测留下的 notebook：目标是「对 5.6 sol 跑 terminal bench」，执行计划日期 2026-07-09，数据集 Terminal Bench 2.0 全部 89 个任务，模型 openai.gpt-5.6-sol，运行区域 us-west-2，工具链 @openai/codex@0.143.0。
把评测交给 Codex：先写计划，等我批准再动手
Lewi 在文章开头交代了自己的来路：职业生涯「大部分时间要么在摇曲柄（部署和运维软件），要么在造摇曲柄的机器」。他在 OpenAI 的第一份工作在云基础设施团队，每周批量拉起 Kubernetes 集群，和 private links、quota、Terraform 纠缠；随后转到 API 团队，负责对最新模型跑评测，处理 grader、quota、配置和 PyTorch 的问题。评测跑通、模型发布，下一个模型来了，再重复一遍。
现在这轮曲柄由 Codex 来摇。流程是：Lewi 先建一个 Runme notebook，在 cell 里写下目标纲要：
# Goal: Run the evaluation against the current model- Review a previous run to understand the workflow.- Write a detailed plan in this notebook.- Wait for me to review and approve the plan before beginning.- Document the commands you run, their output, and how you interpret the results.然后给 Codex 一条指令：「读取浏览器里打开的 Runme notebook 中的目标 cell，把它当作目标，把计划写进 notebook，等我批准后再开始。」
Codex 边推进边更新 notebook。计划写好后由 Lewi 审阅、修改，他写道，自己最有用的参与是帮 Codex 做选择题：用哪套评测系统、要不要新开基础设施、还是复用现有资源。Codex 干活时他偶尔在手机上盯进度，卡住了就推一把，比如配额耗尽、环境起不来，他会建议复用已有环境或找其他获批选项。收尾时，他会和 Codex 一起把那些「原本会消失在对话里」的决策记进 notebook：为什么选了某个方案、现在优先用哪种做法、下次该换一种什么方式。
Runme：文件就是 Markdown 的 Jupyter 式 notebook
按文章的介绍，Runme 是「用 Codex 创建 notebook 的开源 Web 应用」，与 Jupyter、Colab 一样支持 Markdown、代码 cell 和 HTML，可以把指令、命令、结果、表格和图表放进同一份文档。两个设计细节值得注意：notebook 可以直接存进 Google Drive，团队不必再引入一个文档仓库；每个 notebook 还会生成一个 *.index.md 配套索引，Google Drive 能索引这个文件，agent 以后需要范例、操作上下文或上次运行的结果时，更容易发现历史 notebook。
Hamel Husain 在推文里点出了另一个特点：这种 notebook「让你带上自己的 coding agent，文件就是 Markdown」。工具不绑定特定 agent，用户想用自己的哪个 agent 都行。
Runme 这个名字本身不新：配图中 notebook 运行在 web.runme.dev，而同名开源项目 Runme 的官网 和 GitHub 仓库 （Apache-2.0 协议，约 2.1k stars）都已公开，官网首页的推荐语区还挂着 Jeremy Lewi 的署名评价，称 Runme「已经成为我们技术栈里不可或缺的工具」。
WebMCP：工具注册在浏览器里，而不是服务器上
agent 与 Runme 的交互走 WebMCP。应用一加载，就在浏览器端注册一组工具，agent 可以用它们读取操作 Runme 及其 notebook 的说明、运行受约束的 JavaScript 程序来读写 notebook 内容、读取应用文档。
文章绕开传统 MCP 的理由很明确：Runme 是纯客户端应用，以静态网站形式提供服务，如果只为了暴露一个传统 MCP 端点而加一台服务器，会引入额外的基础设施和运维复杂度，还会改变 notebook 数据的存放位置。WebMCP 让应用直接从浏览器暴露能力。
Hamel Husain 把 WebMCP 的定位概括为：面向「agent 和人类要共同操作同一个 UI」的场景，比如一起编辑 notebook cell，它和 MCP 或 API 的区别在于直接通过浏览器暴露。
让文档在干活的同时便宜地产生
文章把重点放在上下文沉淀上。Lewi 写道，能帮到 agent 的信息其实都在日常工作里，但散落在终端历史、Slack、runbook、文档和 dashboard 中；难点不是证明文档有用，而是「让文档在干活的同时便宜地产生」。
Runme 的做法是把意图、动作、决策和结果收进同一个 artifact：常驻的目标 cell 让 Codex 不跑偏，自动审批检查可以在不改变既有权限边界的前提下审查符合条件的动作。计划是否就绪、哪些后果重大的选择需要人拍板，仍然由 Lewi 决定。因为 notebook 容易分享，「这些实践经验不必困在某个人的聊天记录里」。
文章最后一段的标题是 Getting my heartbeats back。Lewi 说，他的大半职业生涯都在「琢磨让挑剔的机器听话的咒语」；云基础设施和 Kubernetes 本应让部署变简单，结果换来的是 CNCF landscape 上一大片的工具生态，解决一个问题常常带来新问题。Codex 的吸引力在于接手重复性运维工作的同时，把他留在真正重要的决策里。他写道：「希望我能把那些心跳拿回来，花在陪我的狗玩上。」
发布当天，讨论集中在 WebMCP 的取舍上
Hamel Husain 的推文给这篇博客定了调，截至 8 月 27 日凌晨，这条推文约 6.2 万次浏览、377 个赞、696 次收藏。他还补充说，作者 Jeremy Lewi 不在 X 上，附上了他的个人网站 。
回复里，有人看到机会，有人提出疑问。在做 agent 信任基础设施（Proofpress）的 认为「这件事比我们想象的更大」：任何想让 agent 与用户协作的 Web 产品，都能用结构化的方式暴露直接操作，比如 agent 直接在浏览器里操作你的 X 账号，提出动作、人类在同一个 UI 里批准，这类体验会变得干净可靠得多。
DensityLabs 创始人 更看重另一层：Markdown 即真相才是被低估的部分。「我们的评测 runbook 一旦放进没人能 diff 的 notebook 就开始腐烂，能由 coding agent 重放的纯文本才能扛过交接，相比之下 WebMCP 几乎像是次要的。」
也有具体的技术疑问。关注 agent 可靠性的 指出，WebMCP 的协调通道活在浏览器会话里：「评测中途刷新一下标签页，agent 连接就断了。除非 Runme 有重连语义，否则这是循环里最贵的一次重启。」另一位回复者 则直接问：「人和 agent 能同时碰同一个 cell 吗？」浏览器会话掉线、人机同改一个 cell，这两个问题，博客都没有涉及。