GPT-5.5当经理:程序员开始给AI带团队了

1. 先把 GPT-5.5 放到「经理位」

Graham Neubig 的实验很简单，也很有象征意义。

他给 GPT-5.5 的核心设定是：你当 manager，别当 coder。模型要找出问题、拆出可执行任务，再把任务委派给其他 agents，自己避免直接写代码。随后，他离开一小时，再回来查看这支「AI 小队」推进到了哪里。

▲ Graham Neubig 将 GPT-5.5 设成 manager，让它拆任务并委派给其他 agents。该截图来自个人使用体验，不能等同于 OpenAI 官方 benchmark。

原文里最关键的一句是：

you are a manager, not a coder

「这句话的中文含义是：让模型站到 manager 位置，承担识别问题、分工、协调的职责，避免亲自进入 coder 模式。」

紧接着的指令更直接：

Find the issues to solve and delegate to other agents. Do not write any code yourself.

「也就是：找出要解决的问题，把它们派给其他 agent；模型本体负责管理和验收路线，尽量别自己动手写代码。」

这也是这条推文让开发者兴奋的原因：它把 AI 从「代码补全器」推到了「任务编排者」的位置。人类工程师的工作重心，也跟着从逐行实现，转向给目标、设权限、看日志、跑测试、做验收。

2. Anthropic 已经把多 agent 做成工程系统

Graham 的实验是个人观察，产业侧也有更完整的工程样本。

Anthropic 在 2025 年 6 月发布的工程博客《How we built our multi-agent research system》中，详细拆解了 Claude Research 背后的多 agent 架构。它采用的是 orchestrator-worker pattern：lead agent 先制定研究策略，再创建 subagents，让它们并行搜索、筛选、汇总信息。

▲ Anthropic 官方工程博客介绍 Claude Research 的 multi-agent architecture 与 orchestrator-worker pattern。

Anthropic 对这个架构的解释是：

Our Research system uses a multi-agent architecture with an orchestrator-worker pattern

「中文解释：Research 系统使用多 agent 架构，由一个编排者协调流程，再让多个 worker / subagent 分头处理任务。」

它给出的内部评测结果也很扎眼：

outperformed single-agent Claude Opus 4 by 90.2% on our internal research eval

「中文解释：在 Anthropic 的内部 research eval 中，多 agent research system 比单 agent Claude Opus 4 高 90.2%。这里的边界很重要：这是 Anthropic 内部 research eval，不应外推成所有任务通用结论。」

这和 Graham 的 GPT-5.5 实验正好接上了同一条线：当任务足够开放、需要多个方向并行探索时，最强的单个模型也会遇到上下文、时间和搜索路径的限制。把任务拆给多个子 agent，本质上是在扩大并行工作面。

3. Codex 让「虚拟队友」开始产品化

另一条线来自 coding agent 产品本身。

TechCrunch 对 OpenAI Codex 的报道提到，Codex 是 OpenAI 在 ChatGPT 中推出的 AI coding agent，可在云端沙盒环境里连接 GitHub 仓库，执行写简单功能、修 bug、回答代码库问题、运行测试等任务。报道还写到，OpenAI 表示 Codex 可以同时处理多个软件工程任务。

▲ TechCrunch 报道 OpenAI Codex：coding agent 从回答代码片段，走向更长的软件工程任务执行。

报道里的一个关键词很有意思：virtual teammates。

virtual teammates

「中文解释：OpenAI 方面希望 coding agents 最终像虚拟队友一样，承担人类工程师需要数小时甚至数天完成的自主任务。」

这意味着，AI 编程工具的产品形态正在变化。过去很多工具强调「补全下一行」「解释这段代码」「帮我写个函数」；现在的 coding agent 更强调长任务、仓库上下文、测试执行、并行任务队列和可观察进度。

当 Codex、Claude Code、各种 workspace agent 都开始承接长任务，Graham 这类「manager prompt」就变得更有现实感：如果每个 agent 都能在独立环境里推进一部分工作，那么上层 manager agent 的价值就变成了拆解、分派、合并和检查。

4. 冷水也来了：15 倍 token，协调会反噬

多 agent 的故事很燃，但工程账单同样刺眼。

Anthropic 在同一篇文章里明确写到：

multi-agent systems use about 15× more tokens than chats

「中文解释：多 agent 系统大约消耗普通聊天 15 倍 token。能力提升背后，是更多上下文、更多工具调用、更长执行链路。」

它还提到，agents 通常会使用约普通聊天 4 倍 tokens；多 agent 适合高价值、可并行、信息量超过单个上下文窗口的任务。对低价值、强依赖、共享上下文要求极高的任务，成本和复杂度会压过收益。

▲ 社区讨论提醒：multi-agent 很容易把协调、成本、上下文同步和错误传播问题放大。

这也是社区反方讨论的重点：多个 agent 并行，会带来重复工作、遗漏依赖、上下文不同步、错误级联等问题。一个 subagent 把错误结论交给 lead agent，lead agent 再把它吸收到全局计划里，后续任务可能会沿着错误方向越跑越远。

Anthropic 的工程经验里，也出现过早期 agent 滥开 subagents、无休止搜索、给出模糊分工等问题。它们最后依靠更细的 prompt、工具边界、日志、检查点、评测和人工测试来压住风险。

所以，「GPT-5.5 当经理」听起来像科幻片开场，落到工程里更像一套复杂系统：权限、文件落盘、测试、可观测性、错误恢复、人工审核，缺一块都会影响结果。

5. 程序员的新姿势：写代码之外，还要会带 agent

这件事真正值得关注的地方，在于开发者角色正在移动。

当模型能写函数，人类要会写需求；当 agent 能跑测试，人类要会定义通过条件；当多个 subagent 能并行推进，人类要会设计任务边界、共享上下文、合并策略和回滚方案。

未来的「会用 AI 编程」，可能会越来越像工程经理能力：

• 把模糊需求拆成 agent 可执行的小任务；
• 给每个 agent 明确输入、输出格式、工具权限和停止条件；
• 让结果落盘，避免信息在多轮转述里丢失；
• 用测试、日志、review 和检查点做验收；
• 只在任务价值足够高时启用多 agent，避免用 15 倍 token 解决一个小问题。

Graham 的推文没有证明 GPT-5.5 已经稳定掌控一支 AI 工程团队。它更像一个信号：AI 编程的前沿正在从「模型能写多少代码」，走向「系统能持续推进多少工作」。

如果这个方向继续发展，程序员手里的核心工具会从 IDE 变成 agent workspace；最关键的技能，也会从提示模型写代码，升级为设计一套可执行、可验证、可追责的 AI 协作流程。