研究工具也需要与真实用户相连
查看原文 07:46在这次 The Pragmatic Engineer 访谈中，Tibo Sottiaux 从研究工具、产品选择和工程实践的变化讲述 Codex。反复出现的问题是，怎样让别人更有效地工作，同时保持快速变化的系统连贯。
他先纠正了对话里的一个细节：在 Google 的第一个项目是让移动网页更快，之后才加入 Maps。小团队解决了困难的技术问题，但项目因为没有达到所需规模而被取消。他从中学到，即使技术工作很有趣，也要持续追问用户反馈和实际影响。
在 DeepMind，他做研究基础设施与工具。早期语言模型的内部聊天界面在研究人员中流传开来，但要变成外部产品，面对的是另一套组织和生产环境。后来，他希望加入研究与产品能够共同设计的地方。
内部研究智能体变成产品项目
查看原文 15:48加入 OpenAI 后，Sottiaux 最初仍做研究基础设施。推理模型让团队开始问，能否用这些模型加快研究本身。他们训练熟悉公司 Python 代码库的内部模型，并围绕模型搭建小型智能体。
这项工作后来与自主软件工程项目合并，目标从帮助内部研究人员，扩展为向外部用户提供产品。他描述，最初的云端 Codex 使用摩擦较高，产品与需求的匹配并不好；与此同时，团队推出并继续推进 CLI。
因此，这条路径并不是先有模型，再接上完成的界面。内部使用、训练和产品实验一直相互影响。
Rust 帮助建立智能体核心的边界
查看原文 18:53团队把产品界面与智能体当作两件事。智能体核心需要可靠、安全、高效，并能扩展。Rust 提供编译期检查，团队也有很强的 Rust 开发者；Sottiaux 说，内部模型当时也已具备足够的 Rust 能力。
他并不认为 TypeScript 或 Python 会让成功变得不可能。用它们也可以做，之后再重写。更重要的是，核心应当有清晰边界，能够独立于某个具体产品存在。
使用不同语言，也加强了这条边界。他说，如果所有东西混在一起，就更容易把本应分离的部分缠住，影响后续创新。语言选择支持的是架构决定，而不是适用于所有智能体项目的通用规定。
开源带来反馈，也带来维护账单
查看原文 21:39一个公开仓库的编程智能体可以用来改进自身。团队希望社区能够检查、贡献和实验，也希望学习其他项目，而不是宣称自己已经知道所有答案。
Sottiaux 提到了实际收益：新同事可能入职前就读过代码，外部贡献者会带来有用的改动。真正参与社区，也给团队带来动力。
代价同样具体。工作需要跨越原本不必存在的仓库边界；竞争者可以在功能仍公开开发时复制，并抢先发布；项目还会收到大量低质量贡献，需要有人处理。
在他的解释里，支持其他模型提供者也出于相似逻辑。限制一个开放 harness，只会促使别人为了这点支持另建小分叉。保留选择，让用户换模型时不用重建整套环境，也让团队了解不同模型的使用反馈。
本地工具与云端资源面对不同限制
查看原文 32:28按访谈当时的描述，Sottiaux 说默认是在本地沙箱中执行，需要额外权限时再请求授权。他也介绍了托管云端执行：工作发生在远程环境，本地设备发送输入、接收输出。
主持人指出，本地执行有个现实优势：开发者已经配置好数据库、服务和工具。Sottiaux 的回应是，随着智能体能自己配置并维护云端开发环境，这些准备成本可以降低。
他把更自然地组合本地与云端资源视作发展方向。论点是，更强的智能体可能需要超过笔记本的计算资源，而不是说所有本地工作流程都已经可以无成本地搬到云端。
Harness 可以先领先模型，再逐渐缩小
查看原文 37:18Sottiaux 将 harness 描述为提供安全边界、效率、可控性和指令的系统，帮助模型更可靠地工作。“记得运行测试”可以是一种临时支持，后来的模型可能不必被提醒，就能理解这个要求。
所以，训练与 harness 工程要共同设计。发现缺点或希望增加能力时，团队会判断应当修改模型还是运行环境。时间也重要：如果训练很快就能解决，就未必值得先做一套复杂补偿。
目标不是永远增加指令。模型行为改善后，一些指令和脚手架可以减少。团队仍然需要表达能力与控制执行的机制，但会尽量避免只为暂时的模型缺陷搭起庞大结构。
依据访谈整理的模型与 harness 修改决策示意图，并非 Codex 官方架构图。
共享组织上下文帮助工程师了解情况
查看原文 41:57新同事经常听到的问题是：“问过 Codex 吗？”Sottiaux 说，内部系统能访问代码、文档和对话，帮助理解项目状态，以及某个决定为什么形成。
这也依赖团队的工作方式。公开频道和访问范围较广的文档，让同事与他们的智能体能够获取信息。它是围绕工具建立的流程，而不是没有组织上下文也会凭空出现的能力。
他强调责任感、用户价值与产品连贯性。提出改动，需要有证据说明值得增加并持续维护。按他的描述，自动化承担了很多审查、部署和回归工作，人则更多关注改动的目的。
审查转向意图和明确契约
查看原文 47:52Sottiaux 介绍，有些模型会深入多层依赖，寻找逻辑错误和被破坏的假设，包括文档说法与实现不一致的情况。他还提到，内部自动安全检查可以阻止有问题的拉取请求合并。
这些是他对团队工具和评测的报告。他认为，人仍需讨论的是意图：这个改动究竟想完成什么，是否值得尝试。
他举的例子是，一个有明确契约的盒子，对资源使用、数据访问和安全给出严格不变量。如果这些保证始终满足，盒子内部的改动就可以少一些重复讨论。先把保证本身讲清楚，就是有价值的工程工作。
维护更便宜，没有消除好抽象的价值
查看原文 52:36维护仍然必要。Sottiaux 预计，智能体将自动化更多维护工作，从依赖升级到较大的架构修改，尤其是在文档和变更记录提供了可靠推理基础时。
他也再次回到边界问题：形状合适的抽象，让组件能够快速变化，而不打扰周围服务。重写成本降低使迭代更快，但隔离改动的结构仍然有帮助。
项目增长速度也变了。大量智能体加入一个项目，可能远快于过去招聘并带教同等数量的人。文档、模块化和契约，因此更早承受压力。
把本地能力带进托管云端产品
查看原文 63:26对话中的“合并”是指将 Codex 带入 ChatGPT。Sottiaux 说，难点在于连接不同技术栈：一边是本地智能体，一边是面向更广泛用户的托管云端产品。
这需要基础设施与效率工作，也要协调插件、库和产品差异。他还提到，项目过程中 Codex 记录了团队的争论与决定。
他把更统一的体验描述为持续推进的方向。希望实现的是，用户可以通过喜欢的界面使用同样的智能，而不是永久维持彼此不同的能力。
好奇心和清晰意图仍是工作的一部分
查看原文 70:41Sottiaux 利用会议间隙，通过手机语音提出问题、获取定制报告和进行探索。他也做原型，把想法交给同事看；原型是用来批评和学习的对象，并不自动意味着决定发布。
他的建议是，快速理解系统、问出好问题，并与需要解决问题的人保持联系。解释意图、识别用户需求，仍然是做出有用工作的重要部分。
本文整理自 The Pragmatic Engineer《Building Codex with Tibo Sottiaux》。产品行为与内部实践均按访谈中的描述呈现，不作为当前配置说明；赞助段落已省略。