Tibo：“Maintenance is ... a tax.”
Tibo：“维护就像一笔持续支付的税。”
对开发者来说，这笔“税”一点都不抽象。
功能上线只是一次性开支，后面的每一次修改维护，都是一笔账单。
Tibo认为，Coding Agent会先改变这部分账单。大量令人拖延的维护工作，会被Agent代替。
备注：Tibo是Codex早期创建者之一，如今负责OpenAI核心产品与平台，Codex也在他的管理范围内。
最近的一场访谈中，他聊了Rust、开源、模型、代码审查、系统重构和Codex与ChatGPT的合并。
Tibo还反复提到一个容易被忽略的部分：模型只提供推理能力，决定Agent能否进入真实项目的，是包在模型外面的harness。
这些话题看起来很散，放到一起却指向同一件事：OpenAI并不只想让Codex更会写代码，而是想让它进入软件的整个生命周期。
Tibo认为，维护仍然必要，但其中很多步骤会被自动化
以下为访谈内容，我们进行了翻译与整理。
软件写完只是开始，贵的是以后每一次修改
Tibo举了一个最直接的例子，依赖升级。
Tibo：“只要更新版本号、读懂变更日志，再根据代码判断影响，这类任务完全可以自动化。”
以前，团队往往会把这类工作一拖再拖。
它不会直接带来新功能，却可能打破构建、引入兼容问题，还要补测试和准备回滚。很多技术债，就是从一句“下个迭代再处理”开始的。
当Agent可以读变更日志、搜索全仓库、修改调用点、运行测试并继续修错，这笔小账开始变得好算。开发者不用一个文件一个文件地搬迁，而是先给它一个明确终点：哪些测试必须通过，哪些行为不能变，哪些目录不允许碰。
但“自动维护”有一个前提。Tibo特意提到了写得清楚的变更日志和文档。一个没有测试、没有边界、连启动命令都要靠老员工口口相传的项目，换成再强的模型也不会突然好维护。
Codex开始接触的，是整个项目
OpenAI内部给了一个很直观的使用场景。
Tibo：“Have you asked Codex?”
Tibo：“你问过Codex吗？”
新员工想知道一个项目进展到哪，谁在处理某个问题，以及当初为什么做了某个技术决定，同事会先让他去问Codex。原因也很直接：它已经接上了Slack、文档和代码。
Codex在OpenAI内部已经接入沟通记录、文档和代码
这和在编辑器里点一次“补全”完全是两件事。
当Agent只能看当前文件，它是一个代码生成器。当它能追查需求来源、查历史讨论、读接口文档、运行命令并查看日志，它才开始参与项目。
开发团队会很快碰到一个现实问题：你是否愿意让Agent读到这么多东西？
接入越广，Agent越了解项目；接入越广，权限和数据风险也越集中。公开频道、可搜索的决策记录、分级权限和操作日志，不再是文档团队的“卫生工作”，它们直接决定Agent能不能进入真实研发流程。
Agent能不能干活，模型只决定了一半
Tibo花了不少时间讲harness。这是整场访谈中最值得开发者细看的一部分。
Tibo：“The harness ... is always a little bit ahead.”
Tibo：“harness总会比模型往前多走一小步。”
Harness要把上下文、工具、安全边界、开发者指令和反馈循环装起来，再把模型放进去。
当模型还不够稳定时，harness用工具、规则和反馈提高可靠性
模型提供推理能力，harness负责把它变成可执行、可检查的工程过程
OpenAI团队每天都要做一个取舍：某个缺陷是应该改harness，还是等模型本身升级？
Tibo：“如果模型一个月后就能修好，也许不必写上万行代码去绕过它的缺陷。”
这对企业自建Agent同样适用。不要遇到模型失败，就继续叠加提示词、规则和分支逻辑。先把问题归类：是上下文没给到，工具返回不稳定，验收条件不清楚，还是模型确实不会。这四类问题，修法完全不同。
Codex Agent循环，Agent会在工具结果和模型判断之间反复迭代
Codex为什么开源，还允许接入其他模型
Codex CLI开源时，Tibo的理由很简单：他们正在做一个会改代码的Agent，早晚会让它反过来改自己。如果代码对社区开放，开发者可以直接参与，OpenAI也能从真实使用中学到东西。
Tibo：“如果你在做一个优秀的编程harness，为什么一定要把它和某个模型绑死？”
Tibo认为，编程harness不必与单一模型供应商绑定
这句话决定了Codex的一个重要边界：它可以是OpenAI产品，底层harness却不必只服务OpenAI模型。
对开发团队来说，这比“又多一个模型可选”重要得多。
模型会迭代，价格会变，限额和合规条件也会变。如果任务编排、工具接入、验收规则和历史记录都只能跟着一家模型走，团队换模型的成本会非常高。
真正值得留在自己手里的，是任务记录、评测集、权限边界、工具协议和可回放的执行日志。这些东西能带着走，模型才是真的可替换。
代码审查不会消失，逐行找错正在失去价值
Tibo：“The role of code review is changing.”
Tibo：“代码审查的作用正在改变。”
Tibo早期参与过Codex的代码审查模型。
他说，模型已经能沿着依赖向下追三四层，去查一个第三方库的真实实现，再判断文档里的承诺是否和代码一致。这类问题，人工审查往往要花几个小时，甚至只有熟悉那个库的人才能看出来。
模型可以追踪多层依赖，帮人找出逻辑、正确性和安全问题
那人还审什么？
看意图。这次修改是否真的解决用户问题，有没有为了跑绿测试而绕开需求，是否引入了团队不愿意承受的长期复杂度。
看证据。测试通过是否足够，有没有需要看压测、监控指标、历史数据回放和灰度结果。
看责任。这个改动如果在生产环境出问题，谁能叫停，怎样撤回，怎样定位数据影响。
审查不会少，审查对象会从一串diff，扩大到整个任务的证据链。
一百个Agent涌入仓库，架构反而更重要
有一种看法认为，代码可以随时重写后，模块、文档和架构都没那么重要了。Tibo给出的场景恰好相反。
Tibo：“以前一个项目可能要一年才扩到50到100名工程师，现在100个Agent一个周末就可能进来。”
Agent让项目的“贡献者数量”在很短时间内暴涨
人类团队缓慢扩张时，大家还有时间补文档、分拆模块、约定接口。Agent涌入的速度快得多，原本可以晚点再补的工程规矩，一开始就得在。
否则，一个Agent在改鉴权，一个Agent在换数据结构，第三个Agent根据旧接口补测试。它们都很勤快，也都可能在局部正确。最后需要人收拾的，却是一个无法合并的仓库。
团队要提前写清服务边界、模块所有权、接口契约、禁止修改区域和合并顺序。每个Agent使用独立分支或worktree，用契约测试卡住跨模块改动，才能让并行不变成冲突。
Tibo还谈到了更大的系统重构。
过去需要数年的改造，有了Agent后可能大幅加速。但重构变快，不代表可以随便改。迁移路径、兼容期、数据校验和回退策略只会变得更重要。
团队依靠Agent和工程约束持续扩展代码库
Codex与ChatGPT走到一起，目标是把本地Agent推向云端
Codex起初是一套本地工具，可以直接读仓库、跑终端、改文件。ChatGPT则是一套托管在云端、面向大规模用户的产品。Tibo说，合并的难点恰恰来自这两套完全不同的技术栈。
Tibo：“问题是，如何保留本地Coding Agent的能力，又把它做成能服务更多人的产品。”
Codex与ChatGPT的融合，需要把本地Agent能力放进可扩展的云端环境
这一步做成后，Codex的工作对象就不再局限于开发者当前打开的电脑。任务可以在云端持续运行，中途保留状态，必要时再把人叫回来。
Tibo：自己会把白天没有想完的大问题交给Codex，让它过夜调查，第二天早上再看结果。
Codex的任务开始从几分钟的修改，延长到可以持续一整夜的调查
这也是为什么OpenAI在做的已经不止是一个CLI。一个要长时间运行、并行处理任务、接入企业资料和工具的Agent，需要计算环境、任务队列、权限、快照、日志和回滚。它的形状已经越来越像研发基础设施。
同一套harness可以服务CLI、IDE和Web等多种客户端
评论区：有人从Claude转向Codex，也有人追着问“为什么停不下来”
Tibo这期访谈的评论区里，讨论很快从“请再重置一次额度”转向了工具信任。
一位用户反馈，他在macOS版ChatGPT里中途取消提示后，Agent循环没有快速停止，原提示也无法编辑。
这类问题看起来只是交互瑕疵，放进长时间Agent任务里就会变成控制问题：人发出停止指令后，系统必须真的停下来。
YouTube用户反馈，中途取消任务后Agent循环没有快速停止
另一位用户说，他曾经因Codex变慢转向Claude，如今又更信任Codex团队的开放程度和沟通方式。这也说明，开发者选编程Agent时，已经不只看一次榜单，还会看速度、额度、开源程度和团队的响应。
YouTube用户表示，自己会根据速度和信任在不同Coding Agent之间切换
还有用户说，Tibo的产品方向和使用体验，让他从长期使用的Claude转向Codex。这是很明确的支持，但也提醒了一点：Agent成为基础设施后，用户信任的是整套工程系统，不是某一次漂亮的回答。
YouTube用户评论，Tibo的产品方向促使他从Claude转向Codex
写在最后
Coding Agent最容易展示的能力，是几分钟写完一个功能。Tibo这次谈得更多的，却是功能写完以后的事。
依赖要升级，Bug要追，系统要重构，代码要审查，项目历史要查，一百个Agent同时改仓库时还要避免互相踩脚。
这些工作没有演示一段代码那么刺激，却占了软件生命周期的大部分。只要Agent开始稳定地接手这些事，它就不再只是写代码的工具。
那时候，团队真正要重做的，是一套能让Agent长期干活，同时又可以被人验收、限制和追责的软件工程系统。返回搜狐，查看更多