ChatGPT、Codex实战：为什么Subagent开得越多，主Agent的Context反而可能越来越重？

很多人第一次接触Codex里的Subagent时，会有一个很自然的判断：

既然一个Agent忙不过来，那就多开几个。

一个负责查Bug。

一个负责读测试。

一个负责看依赖。

一个负责分析调用链。

主Agent只负责汇总结果。

听起来非常合理。

甚至很像真实工程团队：

把复杂任务拆给不同的人并行处理，最后由负责人统一决策。

但真正跑过复杂Agent任务以后，你会发现一个反直觉现象：

Subagent越多，主Agent不一定越轻松，反而可能越来越“重”。

任务确实被拆开了。

执行也确实并行了。

但与此同时，主Agent需要处理的：

上下文。

中间结论。

重复信息。

冲突假设。

工具输出。

也越来越多。

最后可能出现一种非常尴尬的情况：

执行速度提高了，但决策质量开始下降。

这背后真正的问题，不是Subagent不好用。

而是：

Multi-Agent并不等于Free Context

多Agent不是免费的上下文扩容。

一、真实场景：你开了4个Subagent，为什么主Agent最后反而更乱？

假设你让Codex排查一个线上性能问题。

主Agent把任务拆成四份：

Subagent A：

分析数据库查询。

Subagent B：

检查缓存逻辑。

Subagent C：

检查网络调用。

Subagent D：

分析最近Commit。

很快，四个Agent都返回结果。

A说：

慢查询可能是核心原因。

B说：

缓存Miss比例异常。

C发现：

某个外部API延迟增加。

D认为：

最近一个重构可能改变了请求链路。

这时候主Agent要做什么？

不是简单选择一个答案。

而是要重新理解：

四份Evidence。

四套假设。

四条调用链。

它们之间是否互相矛盾。

哪些是Root Cause。

哪些只是Secondary Effect。

甚至还要把这些结论重新映射回：

原始任务。

于是你会发现：

工作被并行拆开以后，信息却重新汇聚到了主Agent。

这就是Multi-Agent系统里一个非常典型的问题：

Context Convergence——上下文汇聚

二、为什么Subagent没有真正“消灭”Context？

因为任务拆出去以后，

最终结果还是要回来。

Subagent可以减少主Agent亲自执行的工作，

但不能自动消除：

信息整合成本。

一个Subagent可能返回：

分析结论。

代码位置。

日志。

假设。

修改建议。

测试结果。

如果开5个Subagent，

主Agent最后可能收到五套类似信息。

于是原来一个Agent需要处理的一条执行链，

变成了：

五条执行链的总结。

所以多Agent真正做的是：

Execution Parallelism

执行并行化。

但不一定带来：

Context Compression

上下文压缩。

如果没有专门设计，

甚至可能出现相反结果。

三、工程机制：Subagent会产生三类隐藏Context成本

第一类是：

Input Duplication

输入复制。

为了让Subagent理解任务，

通常需要给它：

Repository背景。

原始Goal。

相关文件。

约束。

已有Evidence。

如果每个Subagent都拿到大量相似背景，

同一份信息实际上被重复处理了很多次。

从系统角度看，

你不是只读了一遍Context。

而是可能让多个Agent：

分别读取。

分别理解。

分别推理。

第二类是：

Output Accumulation

输出累积。

每个Subagent都会产生自己的结果。

如果结果很长，

主Agent就要重新消费这些内容。

例如：

A返回1500字。

B返回2000字。

C返回1800字。

D返回2200字。

你本来希望：

“让它们帮主Agent减负。”

最后主Agent却突然收到：

一大包新的Context。

第三类是：

Semantic Conflict

语义冲突。

这是最麻烦的一类。

Subagent A认为：

问题来自缓存。

Subagent B认为：

缓存只是表象。

Subagent C认为：

真正问题是并发。

如果每个人都非常确定，

主Agent就必须重新判断。

这时候真正增加的不是文字长度。

而是：

Decision Complexity——决策复杂度。

四、为什么Subagent越专业，冲突反而可能越明显？

因为不同Agent看到的是：

不同局部视角。

数据库Agent会优先关注：

Query。

索引。

锁。

缓存Agent会关注：

Hit Rate。

Invalidation。

TTL。

网络Agent会关注：

Latency。

Retry。

Timeout。

每一个局部判断都可能成立。

但：

局部正确，不代表全局正确。

这和真实工程团队非常像。

数据库工程师会说：

数据库有问题。

网络工程师会说：

网络有问题。

业务工程师会说：

代码逻辑有问题。

最后真正困难的工作还是：

谁来判断系统级Root Cause？

在Multi-Agent系统里，

这个责任通常回到：

主Agent。

五、所以多Agent真正的瓶颈，可能从执行变成“整合”

单Agent时代，

瓶颈通常是：

执行慢。

分析慢。

工具调用慢。

但Subagent越来越多以后，

新的瓶颈会出现：

Synthesis Bottleneck

整合瓶颈。

也就是：

Agent已经跑完了。

结果也有了。

但主Agent需要大量时间：

阅读。

比较。

验证。

去重。

重新建立全局模型。

如果整合速度赶不上Subagent产生信息的速度，

系统会形成：

Context Backlog——上下文积压。

这时候继续增加Subagent，

未必会继续增加效率。

六、一个很实用的指标：Context Return Ratio

可以建立一个指标：

Context Return Ratio

上下文回流比。

简单理解就是：

Subagent执行过程中处理了多少信息，最终又有多少信息重新回到主Agent。

例如：

一个Subagent读了30个文件。

但最后只返回：

Root Cause。

3个关键文件。

2条Evidence。

一个建议。

这是低回流。

非常高效。

但另一个Subagent：

读了30个文件。

最后把所有分析过程、日志、候选路径全部返回。

这就是高回流。

如果多个Subagent都是高回流，

主AgentContext很快就会膨胀。

所以Subagent真正应该追求的不是：

“返回得越详细越好。”

而是：

返回最少但足够做决策的信息。

七、什么任务适合拆Subagent？

最适合的是：

边界清晰、结果可压缩、互相独立的任务。

例如：

检查三个独立模块。

分别跑三组测试。

分别搜索不同类型安全问题。

分别分析几个独立Commit。

这类任务有一个共同特点：

每个Subagent最终都可以返回一个：

非常明确的Summary。

例如：

发现问题。

没有发现问题。

关键文件。

Evidence。

建议动作。

主Agent很容易整合。

八、什么任务不适合乱拆Subagent？

第一种：

问题边界还没确定。

例如：

“整个项目为什么慢？”

如果一开始就开很多Agent，

很容易出现大量探索性结果。

最后主Agent收到：

十几个可能原因。

Context立刻爆炸。

第二种：

多个任务高度依赖同一状态。

比如多个Agent同时修改：

同一模块。

同一配置。

同一测试环境。

这时不仅有Context问题，

还会出现：

State Conflict。

第三种：

需要连续推理的问题。

有些Bug必须按照：

Evidence A → Hypothesis B → Test C → Result D

一步步推进。

如果强行拆给多个Agent，

反而会失去完整推理链。

这种任务单Agent有时候更干净。

九、Subagent最重要的设计，不是“怎么分工”，而是“怎么回来”

很多人设计多Agent时只考虑：

怎么拆任务。

但真正关键的是：

Return Contract

也就是：

Subagent回来时必须按照什么格式交付。

例如只返回五项：

结论。

Evidence。

关键文件。

置信度。

下一步建议。

不要把整个探索过程全部塞回来。

这样主Agent收到的不是：

一堆聊天记录。

而是：

Decision Packet——决策包。

这会明显降低Context压力。

十、再建立一个机制：Evidence before Narrative

Subagent最容易产生大量自然语言解释。

但主Agent真正需要的通常不是故事。

而是：

证据。

所以更好的返回顺序应该是：

先Evidence。

再Conclusion。

最后才是必要解释。

比如：

文件：

session.ts:128

现象：

Token Refresh后缓存未更新。

测试：

Case 17稳定复现。

结论：

缓存状态可能是主要原因。

而不是先写：

“经过深入分析，我发现该系统整体存在若干潜在……”

这种文字看起来完整，

但对于主Agent整合Context并不友好。

十一、什么时候单Agent反而比多Agent更好？

如果任务满足：

Scope很小。

推理链连续。

文件集中。

状态高度共享。

结果必须一步步依赖前一步。

单Agent通常更好。

因为它不用：

复制Context。

同步结果。

处理冲突。

重新整合。

所以不要把：

“能开Subagent”

理解成：

“应该开Subagent。”

真正成熟的策略应该是：

Parallelism only when useful

只有当并行收益大于整合成本时，

才值得拆。

十二、自测指标：Subagent整合成本

你可以在一次Multi-Agent任务结束以后问：

第一，主Agent花多少时间在重新读Subagent结果？

如果很多：

整合成本高。

第二，不同Subagent有没有重复分析相同内容？

如果很多：

存在Context浪费。

第三，是否产生大量互相冲突的Hypothesis？

如果是：

拆分边界可能不合理。

第四，最终真正影响决策的信息有多少？

如果20页输出最后只用了三条：

回流比过高。

第五，如果只开一个Agent，这个任务真的会明显更慢吗？

如果答案是不会：

那多Agent可能只是增加复杂度。

十三、未来真正成熟的Multi-Agent系统，一定会有Context Routing

未来Agent系统不会只是：

主Agent。

Subagent A。

Subagent B。

Subagent C。

全部互相共享所有信息。

更成熟的方式一定是：

Context Routing

也就是：

什么信息应该给谁。

谁只需要Goal。

谁需要Repository片段。

谁需要完整Evidence。

谁只返回结构化结论。

这其实和之前的Task Routing很像。

只不过这里路由的不是：

任务。

而是：

Context。

十四、为什么这件事会越来越重要？

因为未来Codex真正的发展方向一定不是：

一个Agent越来越忙。

而是：

多个Agent协作。

后台任务。

并行分析。

长任务。

多Repository。

当执行能力变强以后，

新的瓶颈会越来越集中在：

Context。

State。

Coordination。

Synthesis。

也就是说：

未来AI开发效率不一定取决于：

你能开多少Agent。

而更可能取决于：

你能不能让每个Agent只看到它真正需要的信息。

十五、什么时候Plus通常够用？

如果你的主要场景是：

单Agent开发。

偶尔开一两个Subagent。

任务范围比较明确。

Repository规模中等。

那么Plus通常已经能覆盖大量实际工作。

真正应该先优化的是：

任务拆分。

Return Contract。

Context Routing。

不要一遇到复杂任务就无限增加Agent。

十六、什么时候Pro才真正开始匹配？

如果你的工作流已经比较成熟：

Subagent职责清晰。

不会重复读大量相同Context。

结果会结构化压缩。

主Agent只接收关键Evidence。

你已经把Context Return Ratio控制得很好。

但日常仍然需要：

多个复杂Agent持续并行。

大型Repository分析。

多个高价值任务同时推进。

此时Agent容量和高强度执行仍然成为真实瓶颈，

Pro才真正开始匹配。

判断逻辑不是：

“我想开更多Subagent，所以我要Pro。”

而是：

“我的多Agent协作已经优化，但真实高价值并发负载仍然持续超过当前容量。”

这才是容量问题。

最后：Subagent不是越多越强，而是越“干净”越强

多Agent最容易产生一个错觉：

Agent数量越多，

系统越智能。

但工程上真正重要的不是：

多少Agent在工作。

而是：

它们有没有制造重复Context。

有没有重复分析。

有没有输出大量低价值信息。

有没有让主Agent陷入整合瓶颈。

真正成熟的Multi-Agent系统，不是让所有Agent：

什么都知道。

而是让它们：

只知道完成自己任务所必需的内容。

一个Agent负责执行。

一个Agent负责验证。

一个Agent负责安全检查。

最终只把：

最关键的Evidence。

结论。

风险。

交给主Agent。

这样多Agent才能真正产生：

并行收益。

而不是：

上下文债务。

所以未来AI Coding真正高级的能力，可能不是：

一次能开多少Subagent。

而是：

开了很多Subagent以后，主Agent仍然保持一个干净、稳定、可决策的Context。

持续更新Codex、大模型开发相关技术内容。
长期使用各类代码大模型，整理了稳定的Plus/Pro会员订阅渠道，有需要可自取！