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希望技术适应用户，而不是让用户学习管理十个Agent
Skill、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开始替人管理Agent，AI编程才算从“多开几个助手”走到一种新的工作方式。
参考链接：
https://www.youtube.com/watch?v=4qjEgPojjzM
文章来自于微信公众号 “51CTO技术栈”，作者 “51CTO技术栈”