帮你重置 Codex 额度的那个男人，如今坐在 ChatGPT 的产品中枢

如果你最近在推特上关注过Codex的额度重置、限流公告、故障恢复通知，大概率刷到过一个叫 Tibo 的账号。很多人对他的印象也就停留在"那个天天发额度公告的OpenAI员工"。

但笔者觉得，只把他当成一个发公告的人，就把这件事看小了。这个人的真实身份，是OpenAI内部把模型能力、工程系统和用户产品这三层硬串起来的核心角色之一——他现在手里管的，是Codex、ChatGPT以及OpenAI的核心产品平台。

一分钟先把人认清楚

Tibo Sottiaux，全名 Thibault Sottiaux，比利时人，圈内一般直接叫他 Tibo。职业标签是"工程师出身的AI产品与平台负责人"，履历依次是谷歌地图、Google DeepMind、OpenAI。

他做过的东西里，比较有分量的包括 Gemini 的人类数据体系、强化学习框架 Reverb、新一代 Codex，以及现在的 ChatGPT Agent 相关产品。能力面覆盖机器学习基础设施、Agent 架构、产品工程、训练数据和开发者工具——这几样凑在一个人身上，本身就挺少见的。

至于他现在最主要的影响力体现在哪儿？一句话：把 Codex 那套"能干活"的执行能力，搬进 ChatGPT，搬进 OpenAI 整个产品生态里。

他不是从产品经理那条路走上来的

Tibo 的路径和典型的消费级产品经理完全不一样。他不是从市场、运营、交互设计一步步爬到产品负责人位置的，而是从应用数学、计算机科学、分布式系统、机器学习基础设施，一路把产品职责越做越宽。

这种背景让他同时看得懂三件在大多数公司里被拆开管的事：模型到底能做什么、工程系统怎么把这些能力稳定地交付出去、用户在真实工作流里到底怎么用这些能力。

也正是因为这三件事他都能接得上，他的职责才会从"带 Codex 一个产品"扩张到"管 OpenAI 一大块核心产品平台"。

学的东西，恰好就是今天Agent最需要的那套

Tibo 大约在 2009 到 2014 年间就读于比利时鲁汶天主教大学（UCLouvain，法语区那所），专业方向是计算机科学、计算数学和应用数学。

课程表里都是些什么呢：线性与非线性优化、运筹学、离散数学、随机建模、数据库系统、网络安全、决策系统、预测建模。乍一看有点老派，但笔者想说的是，这几门课今天几乎是逐条对应到 Agent 系统上的。

原因不难理解。Agent 不是"给大模型一个提示词然后拿一段回答"这么简单。一个真正能干活的 Agent，得反复拆解任务、观察自己所处的环境、挑选工具、从错误里恢复、分配有限资源、最后还要验证结果对不对。剥掉AI这层壳，这些本质上就是优化问题、决策问题和系统工程问题。

所以他的数学和工程底子，让他不只是在思考"模型行不行"，更多是在思考"模型外面那一整套执行系统行不行"。

在谷歌和DeepMind那几年，他在做什么

Tibo 的职业生涯从谷歌伦敦办公室开始，最早做的是谷歌地图，之后转去了 Google DeepMind。

在 DeepMind，他的工作重心是机器学习研究基础设施、人类数据流程，以及研究员们日常在用的内部工具。具体一点说，他为研究团队搭基础设施，支撑分布式机器学习的工作流，参与强化学习的数据系统建设，也参与了 Gemini 模型家族相关的工作，并主导或支持了 Gemini 的人类数据流程。归根结底，他做的事是让研究员和高级模型打交道时效率更高。

他还参与了 Reverb 这个项目——一个专门为强化学习设计的经验回放框架，解决的是大规模分布式训练里的数据存储、采样和传输问题。

像 Reverb 这种项目，永远不会像一个聊天界面那样出圈。但笔者一直觉得，正是这类东西决定了一个大模型系统能不能稳定地训起来、能不能快速地迭代上去。

为什么"人类数据"这段经历特别关键

要理解 Tibo 后来在 OpenAI 干的事，绕不开他在 DeepMind 做人类数据的那段经历。

大模型的表现，从来不是只靠预训练数据和算力堆出来的。一个模型能不能听懂指令、能不能理解用户真实意图、能不能把复杂任务做完、能不能避开那些低级错误，很大程度上取决于后训练数据、反馈机制和评测设计。

而人类数据这活儿具体包括什么呢：给模型设计有代表性的任务、收集高质量示范、比较不同版本模型的输出、标注错误和不安全行为、搭建自动与人工结合的评测标准，以及最重要的——把真实用户需求翻译成模型能吃进去的训练信号。

这段经历直接对应到一个非常要命的产品判断：某个短板，到底该靠继续训练模型来补，还是该靠改产品系统来绕？

而 OpenAI 在做 Codex、做更通用的 Agent 的过程中，这个判断题得反复做，几乎天天做。

从DeepMind到OpenAI

ChatGPT 发布之后，Tibo 的工作重心逐渐转向旧金山，并在 2024 年加入 OpenAI。

他一开始做的事，其实和之前差别不大，还是围着研究工具转，帮 OpenAI 的研究员把模型开发和实验做得更顺。但有意思的地方在于，其中一部分内部工具慢慢长成了面向开发者的 Agent 产品，并最终催生了新一代 Codex。

这条路径其实是 OpenAI 一贯的产品套路：先解决一个真实存在的内部工作流痛点，然后让研究员和工程师往死里用，在这个过程中把失败案例、边缘情况和运行数据全都收集起来，据此提升模型的可靠性和任务执行能力，最后再把这套内部系统包装成公开产品。

所以 Codex 不是市场调研调出来的产品。它是 OpenAI 自己用AI自动化编程和知识工作的过程中，被真实需求逼出来的。

Codex是怎么被他一步步掰过来的

加入 OpenAI 之后，Tibo 参与创建并带队做了新一代的 Codex——一个软件工程 Agent。

早期的 Codex 更像一个云端编程Agent：用户提交一个任务，系统去检查代码仓库、理解项目结构、修改文件、跑测试，最后甚至能直接开一个 PR。

听起来很美，但真跑起来问题一堆：云端环境和本地开发环境对不上；依赖和权限很难复现；长任务经常跑到一半就挂了；用户根本看不见Agent此刻在干嘛；出错之后的恢复逻辑时灵时不灵；代码改完了也很难快速验证对不对。

于是 Codex 团队后来的方向调整很明确——强化本地执行、加强命令行交互、往开发者已有的环境里融。

笔者觉得这次转向挺能说明 Tibo 的产品风格：当真实世界的摩擦力证明原来的设计不够可靠时，他是愿意直接推翻产品形态重做的，而不是嘴硬。

为什么要把Codex CLI开源

把 Codex CLI 开源，是他产品策略里很重要的一步棋。

Agent 产品通常是分层的：模型、提示词、工具接口、执行循环、权限系统、结果校验机制，一层套一层。当这些东西全都藏在黑箱里，开发者根本搞不清一个 Agent 为什么成功、又为什么失败。

开源之后，好处就很直接了：开发者能亲眼看到Agent是怎么读代码、怎么改代码的；社区可以往上扩展工具和工作流；Agent 架构不再神神秘秘；企业能自己审查安全和权限行为；OpenAI 则能从真实生产环境里收到反馈；顺带着，Codex 也能渗透进更多开发者的日常。

Tibo 更宏观的观点是：真正好用的 Agent，不一定需要极其复杂的编排框架。随着模型越来越强，那些脆弱的手工规则应该越砍越少，把推理和决策更多地交还给模型自己。

他的Agent架构观：模型优先，脚手架尽量薄

Tibo 的 Agent 设计哲学，笔者试着概括一下：优先押注模型能力，外面的脚手架能多简单就多简单。

现在市面上不少 Agent 系统，链路长得吓人：

用户请求
  ↓
意图分类器
  ↓
任务规划器
  ↓
工具选择器
  ↓
多个子Agent
  ↓
规则校验器
  ↓
最终回复合成器

在模型比较弱的时候，这套东西确实能提升一致性。但它同时也是一副镣铐——模型变强之后，那些老规则反而会拦着模型，让它发现不了更高效的解法。

Tibo 看起来更倾向于保留一小撮"耐用的原语"：读写文件、跑终端命令、搜索与浏览、执行测试、管理任务状态、隔离环境与权限。剩下的规划和决策，尽可能交给模型自己去做。

这么干的好处是，底层模型一变强，整个系统自动跟着变强，不需要重写一堆规则。代价则是，可靠性、权限控制和结果验证这三件事的重要性被放大了——毕竟你把方向盘交出去了，刹车就得更好使。

Codex早就不只是个写代码的工具了

Codex 打出名气靠的是"软件工程 Agent"这个身份，但它底层的能力，正在往更广的电脑工作里扩。

道理其实挺朴素：软件开发是一个结构化程度极高的环境。Agent 可以看文件、用工具、观察报错、修改输出、然后再跑一遍。只要别的知识工作也能被改造成这种"可执行、可验证、可重跑"的流程，同一套能力就能迁移过去。

比如整理和分析文档、处理表格和结构化数据、汇总邮件与日程信息、检查项目发布状态、做演示文稿、检索内部知识库、把重复的运维操作自动化，以及做调研和信息综合。

所以 Codex 长期的定位，可能不是"帮程序员写代码"，而是"用代码、工具和计算环境来完成知识工作"。这两个说法听着像，实际差着一个数量级。

职责是怎么一路扩上去的

随着 Codex 的用户量和使用场景涨起来，Tibo 的职责也从单个产品扩到了 OpenAI 更大的核心产品与平台组织。

公开场合出现过的头衔包括 Codex Lead、Core Products Lead、Head of Product and Platform。头衔一直在变，但方向很清楚：他的重心已经越过 Codex 本身，走向"把 Codex 的能力和 ChatGPT 融到一起"。

这块更宽的职责，大概率包含这么几件事：把 ChatGPT 的对话能力和 Codex 的执行能力捏合起来；让非开发者也能用上 Agent 功能；把网页端、桌面端、移动端的体验拉齐；统一模型、工具、文件和账号权限；扩展企业级的安全与审计能力；以及持续提升任务执行的速度和成功率。

ChatGPT 手里握着的是巨大的主流用户盘，Codex 则在开发者群体中验证了"Agent 真的能干活"这件事。把两边合起来，正是 OpenAI 从聊天机器人公司转向 Agent 平台的关键一步。

他的产品风格，工程师味儿很重

直接和用户对线。 关于额度限制、任务失败、报错、各种产品摩擦，他经常直接公开回复。相比很多高管，他更像是用户和产品组织之间的一根直连线。

认得快、改得也快。 Codex 遇到容量问题、额度消耗异常、发布事故的时候，他基本会公开承认，等修复或者补偿措施落地之后再来同步一次进展。

拿数据迭代，而不是拿路线图迭代。 Codex 团队看起来更依赖真实的任务执行记录、失败模式、环境配置和用户反馈来决定改什么，而不是死守一份提前排好的排期表。

自己就是重度用户。 Tibo 本人是 Codex 的高频使用者，他提到过用它来跟项目进度、整理文件、做信息综合、检查发布状态。笔者觉得这一点很关键——团队内部先用出问题来，总比等用户大规模踩坑要好。

为什么额度和重置的公告老是他发

他频繁发限额、重置额度、服务补偿这类公告，不代表他只是个做社区运营的。恰恰相反，这些公告背后牵扯的是一整串产品决策：模型算力的分配、订阅使用政策、额度与配额的设计、跨平台功能上线节奏、事故补偿方案，以及大规模的用户沟通。

而且必须承认，AI Agent 的经济账比传统软件复杂太多。一个任务可能一跑就是好几分钟甚至更久，中间反复调用模型、访问文件、执行代码、验证结果。

所以额度政策影响的远不止定价。它同时决定了：算力够不够把任务跑完；资源在用户之间分得公不公平；长任务会不会把容量吃干净；自动化的代码审查和子Agent算不算进用量；以及整个服务能不能维持一个可以接受的响应速度。

Tibo 直接参与这些讨论，恰恰说明他的角色是把产品体验、基础设施和资源约束这三头串在一起的那个人。

他遇到过哪些争议

需要说明的是，围绕 Tibo 的公开批评基本集中在 Codex 的产品运营层面，不涉及个人操守。

额度消耗得莫名其妙。 有 Codex 用户反映每周额度掉得比预期快得多。可能的原因包括自动代码审查、后台任务、子Agent频繁活动，以及用量统计本身不准。这其实暴露了 Agent 产品的一个通病：用户压根搞不清一个任务要调多少次模型、后台还有哪些操作在偷偷花钱。

模型容量顶不住。 用户也碰到过容量告警、错误率上升、任务根本起不来的情况。Agent 任务的运行时长远超普通对话请求，对算力基础设施和并发调度的压力自然大得多。

ChatGPT Work 上线时的摩擦。 ChatGPT Work 及相关功能推出后，用户对使用限额、任务成本和交互模式提出了不少意见，OpenAI 随后调整了限额、重置策略和效率优化。

这些问题合在一起说明一件事：OpenAI 面临的挑战早就不只是"把模型做得更聪明"了。它还得把成本、权限、任务状态和失败原因，用用户能看懂的方式讲清楚。

他的技术强项到底在哪

Tibo 的强项不体现在某个具体模型或某门编程语言上，而体现在他能把AI产品栈的好几层打通。

在机器学习基础设施这块，他懂大规模训练系统、分布式数据处理和研究工作流，所以能判断出某个产品需求什么时候必须靠底层基础设施的改造来兜底。

在人类数据与模型评测这块，他有把用户需求、专家反馈和失败案例翻译成训练数据与评测标准的实操经验。

在Agent 执行系统这块，他关心的范围早就超出了模型输出本身，延伸到权限、工具、环境、执行循环和验证机制。

在开发者产品体验这块，Codex 的用户对速度、透明度、可控性和代码质量都很挑剔。给开发者做产品是一件标准很高的事，而这种高标准反过来能把面向大众的产品也顶上去。

最后是产品与研究的协同。因为 OpenAI 同时握着模型和应用，Tibo 能在模型研究员和产品团队之间做协调，从而判断某个限制到底该在模型层修、在应用层修，还是两边一起修。

和传统产品经理比，差在哪

传统产品经理通常盯着市场需求、功能规划、用户调研和团队协作。Tibo 的角色更接近"产品工程负责人"。

维度	传统产品经理	Tibo 这类工程型产品负责人
主要背景	市场、运营或设计	数学、工程与机器学习
产品关注点	功能和用户流程	模型、系统与工作流的整合
技术介入程度	定义需求	影响架构和执行系统
主要数据来源	调研和业务指标	真实任务、失败案例和模型评测
迭代模式	按计划发版	模型与产品共同演进
核心难题	平衡用户需求与商业目标	平衡能力、成本、安全与可靠性

这类角色在AI公司里正变得越来越重要，原因也简单：模型能力变化太快了。产品负责人必须清楚，每一次模型升级会怎样改变产品本身的设计方式。

他为什么对OpenAI的未来重要

AI 竞争的下一阶段，胜负手大概率不在"哪个聊天机器人单轮回答得更漂亮"，而在"哪个 Agent 能稳定地把正经活儿干完"。

这场比拼包含的东西很多：长时间任务执行、多Agent协作、浏览器与电脑控制、文件与项目管理、长期记忆、企业权限体系、代码与结果验证、邮件日历和第三方集成，以及支付和商业交易。

Tibo 的职责，恰好坐落在这些能力的交叉点上。

如果 ChatGPT 和 Codex 的融合成功了，用户在很多任务上可能不再需要分别打开聊天应用、代码编辑器、自动化平台和搜索工具——描述一个目标，然后让 Agent 自己去规划和执行就行了。

而如果这次融合失败，OpenAI 面对的将是一堆过于复杂、过于昂贵、不够可靠、用户也不敢信任的产品。

但也别把他的影响力吹过头

Tibo 确实很有影响力，但笔者觉得有必要把话说清楚：他并不能一个人决定 OpenAI 的走向。

他不是 OpenAI 的创始人，不是 CEO，不是 ChatGPT 的唯一创造者，不是 Gemini 的唯一架构师，不是 Codex 的唯一发明人，也不是每一次模型定价和额度政策的最终拍板人。

更准确的描述是：他是 OpenAI 内部负责把模型能力、工程系统和用户产品这三者连起来的核心负责人之一。

他的工作必须和模型研究、基础设施、安全、财务、设计、运营以及公司高层反复协调。所以那些公开的产品变化，通常是组织决策的结果，而不是某一个人的作品。

为什么值得追他的公开发言

他的公开账号，如今已经成了观察 OpenAI 产品动向的一个重要信号源。

他发的内容大致涵盖：Codex 的新功能、ChatGPT 的 Agent 能力、额度与配额调整、故障与服务恢复、征集用户反馈、产品设计想法，以及招聘和团队优先级。

这些内容往往比官方正式公告来得更早、更直接。但也得留个心眼——里面同样可能包含临时测试、灰度发布或者短期政策。

所以看的时候最好分清楚这几类：已经正式上线的长期功能、实验性或分阶段发布的东西、临时性的事故补偿、他个人的产品观点，以及 OpenAI 的正式政策。这几样混在一起，很容易被误读成"官宣"。

写在最后

Tibo Sottiaux 代表的是AI行业里一类新型的领导者：既看得懂模型和基础设施，又要为几百万人在用的产品负责。

他的路径是从谷歌地图和 DeepMind 的研究基础设施起步，做到 Gemini 的人类数据工作，然后进入 OpenAI，参与创建并带领 Codex，最后把职责扩展到 ChatGPT 和核心产品平台。

而值得盯着他看的理由，笔者认为绝不是"他发额度重置公告很勤快"，而是他正在推动的那场更大的转变：把 OpenAI 从一家提供对话模型的公司，变成一个通用 Agent 平台——能理解目标、会使用工具、可以把活真正干完。

所以如果你在跟踪AI编程工具、自主Agent或者 OpenAI 的产品战略，那么 Codex 的演进、Agent 能力向 ChatGPT 的融合，以及 Tibo 本人的产品更新，都是值得长期盯住的线索。下一代AI软件长什么样，答案大概率就藏在这几条线里。