程序员的新岗位是监工！Codex负责人：我不想再同时盯10个Agent了，未来让系统接手分工，人只在关键时刻拍板

2026年8月24日Matthew Berman发布了对Tibo的访谈。Tibo在OpenAI带领Codex团队。主持人追问了一个已经出现在重度用户桌面上的问题Agent越开越多以后人该把注意力放在哪儿编辑 | 姜篇Tibo“I was multitasking like 10 agents. I don’t want to really go back to that.”Tibo“我以前会同时盯着10个Agent但我真的不想再回到那种状态了。”主持人在访谈里讲了自己的工作状态他经常同时启动10到15个Agent每个任务要等30到45分钟。Agent一多他就得不停切换上下文记住谁在改哪个项目、哪个任务卡在了哪里。Tibo并不认为这是一种更先进的工作方式。模型能接的任务越来越长人的注意力没有跟着扩容。问题也随之从“能不能多开几个Agent”移到了“谁来管它们”。2026年8月24日Matthew Berman发布了对Tibo的访谈。Tibo在OpenAI带领Codex团队。主持人追问了一个已经出现在重度用户桌面上的问题Agent越开越多以后人该把注意力放在哪儿Tibo设想的产品会接手分工、补充上下文和安排顺序只在需要人做决定时才来敲门。以下为访谈内容我们进行了翻译与整理。Matthew Berman与Tibo的完整访谈十几个Agent同时开工人开始跟不上主持人说以现在的模型速度他常常会一次启动10到15个Agent。问题很快就出现了。Matthew Berman“10, 15 agents in parallel.”Matthew Berman “同时启动10到15个Agent。”同时启动10到15个Agent后人的注意力先到上限每个任务三四十分钟后返回。这个Agent在等权限那个Agent已经交回diff另一个Agent发现原方案走不通正在询问是否换路。开发者没有再逐行写代码脑子却一直在几个任务之间搬家。Tibo把重点放在了人的注意力上。Tibo“Managing your attention.”Tibo“先把人的注意力管理好。”Tibo认为下一代AI产品必须先管理好人的注意力他提到产品不能只考虑Agent能并行跑多少任务还要判断一件更细的事某条消息需要现在打断用户还是30分钟后再出现这和编译速度不同。模型快一倍等待时间会缩短通知多一倍人的工作未必更快。十几个Agent把任务同时送回来开发者仍然只能一个一个看。Tibo还补了一句他已经不想回到同时盯十个Agent的状态。他期待的体验是人不必学习一套复杂的Agent管理术。Tibo“The technology adapts to you.”Tibo“应该由技术来适应你。”Tibo希望技术适应用户而不是让用户学习管理十个AgentSkill、Memory、Subagent现在还得靠人维护目前的Coding Agent已经塞进了很多能力Skill保存工作方法Memory记住项目约定Subagent负责并行执行。熟练用户也学会了维护规则文件、压缩上下文和划分子任务。Tibo对这套体验并不满意。他在访谈里直言今天的高级用户已经习惯了这些“不太顺手”的地方。Skill文件要自己维护时间久了容易失真Memory不会稳定记住所有事情启用Subagent以后用户还得操心子Agent之间怎样分工。Tibo谈Skill、Memory和Subagent目前仍然难以维护为了让Agent稳定工作仓库里逐渐多出AGENTS.md、规则目录、提示词模板、Hook脚本和一串MCP配置。它们确实能提高成功率也把维护一套“AI工作环境”的责任交给了开发者。项目换了目录Skill里的旧路径没有更新架构做过调整Memory还在引用旧模块两个Subagent同时改到同一份文件最后又要人处理冲突。Agent没有少干活新的配置债已经出现了。Tibo希望产品最终能自己消化这些细节。它应当理解用户的目标、每天在做什么、团队正在推进哪些事情不必每次都从一张空白对话框开始。Tibo“Deeply understands you.”Tibo“真正理解你。”Tibo希望Agent能理解用户目标和团队上下文理想状态只有一个入口背后由系统自己分工访谈谈到Codex与ChatGPT逐渐融合时Tibo提到了OpenAI的产品方向。早期用户曾经反对把两者放到一起。Coding Agent有终端、diff和测试结果通用助手处理文档、网页和日常问题看起来应该各自保留一套界面。Tibo的判断是模型正在把这条边界推平。Tibo“The same harness.”翻译“底层会使用同一套Agent执行系统。”Codex和ChatGPT未来可能共享同一套Agent执行系统放到开发团队里一个入口不等于只用一个模型。后台仍然可以安排不同Agent一个查仓库一个复现Bug一个读日志一个跑测试。用户只需要看任务进度和最终结果不必亲自开十个窗口。这层调度系统至少要留住三样东西。第一是任务状态。第二是上下文来源。第三是完成标准。Agent什么时候来找你也得有规矩一个多Agent系统最容易做错的是把每个小问题都抛给人。运行测试前问一次读取新目录前问一次发现两个方案再问一次。单个Agent看起来谨慎十个Agent同时这么做开发者一天都在点“继续”。Tibo在访谈里举了安全扫描的例子。系统发现漏洞后可以自己定位代码、生成修复、运行验证并准备提交。人不必参与每一步只在动作风险足够高时审批。Tibo“A high-risk action.”翻译“只把高风险动作交给人确认。”Tibo认为自动化系统只需要把高风险动作交给人审批对代码Agent可以按风险把动作分开。读取仓库、搜索符号、运行本地测试可以默认放行。修改依赖、写入共享分支、访问测试数据库需要记录并限制范围。涉及生产发布、密钥、付款和删除数据必须等人确认。通知也该按这个逻辑设计。测试失败但Agent还能继续修不必立刻弹窗任务偏离了需求或者即将执行不可逆操作再把人叫回来。对开发者有用的通知应该直接告诉他哪里偏离了目标接下来准备做什么以及这一步能不能撤回。开发者开始搭“Agent上面的那一层”Tibo谈的是未来产品开发者社区已经在尝试补上这层调度。一位开发者在X上分享了自己的单人开发系统Codex和Claude Code只负责执行上面再放一个调度器。调度器保存业务背景、分配任务、监控进度只在PR达到合并条件后通知他。开发者分享放在Codex和Claude Code之上的调度层这套做法也暴露了现实限制。任务边界仍然要由人划分每个Agent使用独立worktree会迅速吃掉内存权限开得太大调度器本身又会成为新的安全入口。另一条讨论把重点放在项目结构上。规则、Skill、Hook和Subagent如果一直散落在临时提示词里模型的行为就很难稳定。把它们当作工程组件管理才可能减少重复说明和上下文漂移。开发者讨论如何用规则、Skill和Hook约束Agent社区的尝试和Tibo的判断指向了同一个麻烦多Agent不是多开几个聊天窗口。它需要任务系统、权限系统和验收系统。缺了这几层人只能继续当消息分拣员。写在最后同时启动15个Agent看起来像把一个开发团队塞进了电脑。任务陆续返回时人很快就会忙着切窗口、补背景、批权限和看diff。Tibo没有把未来描述成“一个程序员管理一支Agent大军”。他想做的是相反的事情系统理解用户目标自己安排后台工作判断什么时候该继续什么时候必须把人叫回来。开发者仍然负责目标、边界和最后的判断。少掉的应该是窗口切换、重复交代和无意义的审批。当Agent开始替人管理AgentAI编程才算从“多开几个助手”走到一种新的工作方式。