跳转至

Nikunj Handa

OpenAI API 团队产品负责人，入职约三年，前 Stripe。自述工作内容是"每出一个新模型就和后训练团队、研究团队密切合作，搞清楚里面有什么新东西，然后把那些能力暴露到 API 里"。

本库收录他的理由：⚠️ 他给了本库第一份"前沿实验室怎么把能力做成平台原语"的一手口径——缓存保证、预热、压缩的三种做法、以及抽象层该放在哪这个他自己承认没想清楚的问题。同时他是 Decisions API 照着 Jev 做了一遍 这件事的当事方。

核心观点（2026-09-30）

来源：Latent Space / OpenAI Dev Day 现场

⚠️ Decisions API：被 Jev 启发，而且"没训新模型"

  • 时间线（[00:24:20]–[00:25:20]）："四周前这东西完全不存在。" 他的叙述是致意 + 把动因归给文化："巨大的致意给 Diogo 和 Jev 团队，他们真的启发了市场上一整个板块……我们的用户在找我们，但我们内部团队也在说：我们需要一个快得多的分类系统。" 以及"OpenAI 有非常强的 hacker 文化……推理团队的一个人、基建团队的一个很厉害的人说'这太棒了，我们要去黑一下'，他们做了个原型，它能跑"。
  • ⚠️ 主持人当面说"你们正式成为第一家克隆并采用这个的前沿实验室"，他没有否认，但也没有承认——本库保留这个区分："第一家克隆"这句评价出自主持人，不出自 OpenAI。
  • ⚠️ 实现方式比"抄"这件事本身更值得记（[00:28:25]）："我们没有为这个训新模型。我们纯粹建在我们已有的同一批 Luna 权重之上。" 做法是结构化输出约束 + 推理栈优化（把 TTFT 做得非常快）+ 多问题并行批处理；白送的一项优势是从 Luna 免费拿到视觉，而 Jev 没有视觉（[00:29:26]）。
  • ⚠️ 他被主持人逼出的一次坦白，本库认为这是他这一期最有价值的一条（[00:29:26]–[00:30:27]）。主持人的设问是："我可以拿 Luna、关掉 reasoning、加上结构化输出——我就有 Jev 了吗？不，对吧。那里头有一个 confidence"，并接上本库已有的那条线（RLHF 会把你坍缩到你想听的答案，而不是真实置信度）。
  • 他的回答："我很想看它怎么发展。也许这些就会是我们要靠未来某个模型版本去爬坡的关键领域。"
  • ⚠️ 本库的记法：第一版复制了 Jev 的接口与速度，但没有复制它的校准——而按主持人的论证，校准才是这类模型的实质。这是一条可在下一版本上直接检验的判断，见 评估与基准。
  • 架构猜测他不接（[00:30:27]–[00:31:28]）：对外界关于 Jev 的两种猜测（扩散而非自回归；mech interp 式地从中间层读激活直接输出）他只说两种都有过公开 demo（Gemini / Gemma diffusion 做过 Jev 风格输出；也有人从中间层拉过 interp），"这全是猜测"。
  • 用例（[00:26:22]–[00:27:23]、[00:31:28]）：最主要是非常快的分类（内部 user ops 团队"马上扑上来"要分类所有支持工单）；computer use 的一个可能方向——"让 Astra 写一段 JavaScript 控制电脑，和让 Luna 一次挑一个动作，不一样；智能水平不会相同，但也许有些任务这就够好了"；以及与 GPT Live 配合——GPT Live 是"前端模型 + 后端模型"结构（talker 超快、擅长委派，后面坐 Astra），而"工具调用在 GPT Live 里一直感觉很慢"。

API 的新原语，以及一条工作原则

（[00:21:19]–[00:24:20]）

  • async function calling：动因是"在 Codex、dots 这些东西里，工具调用耗时太长，以至于你不该在工具运行时把模型执行暂停掉"——"踢出一个工具调用，继续跑、继续推理，然后再回来查"。
  • mid-turn steering：推理中途可插入消息；⚠️ 主持人指出这同时是对齐能力，他的回答把"早就有"和"现在才够好"分开："我们在 app 里一直有，只是以前不够好，现在好多了。"
  • 底座是 websockets："打开了与模型的整个双向通信"；他说第一次上 websockets 是为了 "5.3 codex spark"——"不敢相信我们给一个模型起了这个名字"。
  • ⚠️ 他说出的一条工作原则，本库认为值得单记："我们在 API 的主要目标是：等某个东西被训进 harness 之后，再把它放进 API——所以我们会等那个时刻，等它足够好。"
  • UltraFast 首次进 API，而他给的幕后是一条顺序：⚠️ "至少有几个月，重点都放在效率和把成本压下来——这就是我们能把 Luna 价格砍 80% 的来路；然后他们现在换挡到了'怎么让它跑得尽可能快'。"
  • ⚠️ 一个被明确拒答的问题（[00:24:20]）：主持人指出 5.3 spark 是明确归功于 Cerebras 的，而 UltraFast 与 Cerebras 的关系"你们不确认也不否认"，并补"你们自己也有硅"。他没有回应。 本库记为公开未确认；相关背景见 Sean Lie / Cerebras 那期。

⚠️ 缓存、预热与压缩：本库目前最可操作的一份平台口径

（[00:33:30]–[00:37:35]）他说 Responses API 现在重点就是性能，而性能分延迟（"重写整条链路，把 TTFT、TBT 做到最快"）与缓存两块；缓存的动因是个人 agent 的形状——"特别是这些个人 agent，基本上是一条单线程一直一直往下走"。

机制 他给的具体承诺
缓存命中保证 30 分钟（现有）
⚠️ 长缓存窗口 12 小时保证，"刚为其中一个用户上的"，目前 preview、还没有公开 API，"就是缓存多付一点钱"
缓存读取价格 在被压低，"对开发者来说应该去实现，因为显著更便宜"
⚠️ 预热（pre-warming） 已在 API 里："如果你知道接下来会用到这个 prompt，可以先预热、现在就付缓存写入费用，然后它在接下来 30 分钟是现成的"——主持人接："而我可以 spawn 很多个那条线程的实例"；他答："正是。"
诊断 prompt / cache diagnostics 工具，查"哪里掉链子了"
  • ⚠️ 压缩的三种做法（本库目前最完整的一份）（[00:36:35]–[00:37:35]）。主持人先把问题立住："缓存当然很需要，但归根结底你还是会撞上一百万 token 的上下文，而这在可预见的未来大概不会变。"
  • ① Agents API 内建在 harness 中（OpenAI 专有压缩）——"你们替我们决定"。
  • ② Responses API 服务端压缩：按 token 阈值自动压。
  • ③ /compact 手动覆盖：完全控制，自己定什么时候压。
  • ⚠️ 一条实践观察："我不知道为什么，但很多大的 coding agent 喜欢手动做。如果你看开源 Codex harness 里的实现，你会看到他们用的就是 /compact。"
  • ⚠️ 一条前瞻："我们在做一些新的压缩技术，有些你已经能在 Codex harness 里看到——是一些基于文件的系统，我们在实验。" 与 Thariq 讲 Claude Code 往文件里卸载上下文 是两家实验室在同一周给出的同方向答案。

⚠️ 他自己提出的开放问题：抽象层该放在哪

（[00:37:35]–[00:39:37]）本库认为这是他最诚实、也最值得长期回看的一段。框架来自 Stripe：

  • "我之前在 Stripe，在 Stripe 很大一部分活就是在核心支付原语之上造更高层的原语与产品。我一直很好奇在 AI 里做这件事的最好方式是什么。"
  • ⚠️ 他主动承认一次失败："我们试过几次。我们很早上过 Assistants API，那个其实不太合适。"
  • 现在的尝试与未决问题："我们现在是在走 Agents API 这条路，它给你 Codex harness——但在那里面该给多少灵活性？这是个开放问题。" 具体对象是 ⚠️ "memory vaults 这类更高层的 API 对象，用来把存储这类概念抽象掉"。
  • ⚠️ 他把困境讲成了一句可以当通用观察引用的话："AI 里很多东西就是：有一个低层 API 原语，看一个示例 harness，然后让你的 coding agent 去实现它。但其中多少应该被内建进 API 里，是我一直在想的问题。" 并直接向听众求助："如果有人有想法，我很想听。"
  • 主持人的收束框架（[00:39:37]）："你们在造一个 AI 云——这是 Sam 一年前说的话。这几乎就是在重做 AWS 的那次发明：这是 EC2、这是 S3，但你在做每一个的 AI 原生版本。"

与他人观点的交叉

  • 与 Ari Weinstein 同期出场，分别对应 API / 平台侧与harness / 产品侧。
  • 与 Diogo Almeida：⚠️ Decisions API 是本库第一次看到"前沿实验室按一家创业公司的产品形态做了一个对应物"，而 Almeida 一方在 09-21 与 09-28 两期里都讲过"模型公司正一路往上挤"这个风险的反面。本库把 Decisions API 记为这条风险的一个具体实例，并记下它尚未复制校准这一点。
  • 与 OpenRouter 一侧讲的"分发是模型实验室最被低估的短板"：⚠️ 他这一期的全部内容恰好是那条批评的反面证据——API 团队在做的就是分发与平台原语。本库并列不裁决。
  • 缓存与压缩这条线与 江鋆晨的 KV Cache 作为独立数据层、Baseten 的推理优化报价单 相接，但口径不同：那两份是基础设施供应侧，他这份是平台产品承诺侧（带 SLA 式的保证时长）。

视频