程序员的新岗位是监工：Codex负责人谈多Agent调度与关键审批

• 原文链接：https://mp.weixin.qq.com/s/jsAMm52Nj0hROpNCytLTzw
• 来源：51CTO技术栈对 Matthew Berman 访谈 Tibo 的中文整理
• 获取时间：2026-08-27

核心结论（一句话）

多 Agent 的产品目标不是让人学会同时监督更多 Agent，而是让系统接手分工、上下文、进度和通知，人只在目标偏离、方案取舍或高风险动作时介入。

分类提炼

• 场景：Codex、多 Agent 编程、任务编排、权限与通知设计
• 类型：访谈解读 / 工作流趋势 / 产品控制面
• 标签： #主题/AI-Coding #主题/多-Agent #主题/Codex #主题/Harness #主题/注意力管理 #场景/公众号长文

知识节点

• 注意力调度：并行数量增加会放大通知和上下文切换，系统应优化“何时打断人”，而非只优化执行速度。
• 统一执行系统：一个入口可在后台分配研究、改码、测试和日志分析等角色，用户不必手动管理多个窗口。
• 任务三态：每个后台任务需要可见的状态、上下文来源和完成标准，才可被安全地调度与汇总。
• 风险驱动审批：按动作影响与可逆性决定是否请求批准，避免每个低风险步骤都消耗人类注意力。
• 通知抑制：Agent 可以继续修复的失败不应立刻打断；通知应携带偏离原因、拟执行动作和可逆性。
• 主调度层：调度层维护业务背景、分工、进度和结果收束，执行 Agent 专注局部任务。
• 可撤销动作：读仓库、搜索、运行本地测试可默认执行；共享写入、依赖变更和数据访问需缩小范围并留痕。
• 人类最终判断：人负责目标、边界与高影响决定，不能退化为持续批准低价值操作的消息分拣员。

关联图谱

上游（基于 / 来自）

• [[01-ai-agents/万字长文拆解Agent-架构设计-四-多-Agent-协作]]：提供上下文切分、权限交集与结果回传的多 Agent 运行时解释。
• [[02-ai-coding/OpenAI最新报告解读-Codex正在进入知识工作的主战场]]：指出多任务并行使人从执行者转向工作流编排者。

下游（应用于 / 验证于）

• [[02-ai-coding/Codex配置下一步改造-从规则层走向线程工具目标与共享记忆]]：把任务三态落到长期线程、稳定工具、目标/验证和共享记忆四个配置层。
• [[01-ai-agents/从零设计生产级-Multi-Agent-Harness]]：将风险驱动审批和主调度层扩展为生产级多 Agent Harness 的控制面。

同级（横向 / 并列）

• [[02-ai-coding/Loop-Engineering-详解-把反馈循环放进工程现场]]：一篇侧重多任务如何少打扰人，一篇侧重长任务如何用验证闭环收敛。

正文要点

1. 当 10-15 个任务并行、每项等待数十分钟时，瓶颈从生成速度转为谁理解任务进度、谁处理上下文切换、谁决定何时通知。
2. Skill、Memory、Subagent 若由用户手动维护，会形成新的配置债：旧路径、过期架构和并行改同一文件都要求人补救。理想调度层应将这些运行细节消化在系统内。
3. “一个入口”不意味着单一 Agent。后台可按任务拆给不同执行者，但主界面应呈现当前目标、关键进展、证据和待审批项，而不是所有中间消息。
4. 审批应基于风险：低影响、可撤销操作自动进行；涉及生产、凭据、数据删除、付款或难以恢复的变更才暂停并交由人决断。
5. 多 Agent 系统仍需要人，但人的职责升到目标选择、边界设定、冲突裁决和最终验收。若系统把所有小问题都抛回给人，并行只会制造新的低效。

备注

• 文中对产品演进和统一 Harness 的描述来自受访者口述，不能等同于 OpenAI 已发布的功能清单或时间表。
• “监工”是传播性表达；更准确的角色是定义目标、审阅证据和批准高影响动作的人类控制面，而不是替 Agent 做持续微观管理。

相关链接

• [[02-ai-coding/Codex配置下一步改造-从规则层走向线程工具目标与共享记忆]]
• [[01-ai-agents/万字长文拆解Agent-架构设计-四-多-Agent-协作]]
• [[02-ai-coding/OpenAI最新报告解读-Codex正在进入知识工作的主战场]]