Codex子代理数量可达近70个，用户惊讶

背景

在 AI 编程助手（如 GitHub Copilot 与 Codex）的使用中，用户常通过“子代理”（sub‑agent）或“任务分解”机制，让模型自动将复杂目标拆解为多个子任务并行执行。这种“goal”模式（目标导向的自主执行）允许用户只给出宏观指令，模型自行规划步骤并调用工具。论坛用户 @[匿名] 在 LINUX DO 的 AI 板块分享了一次意外发现：当他开启 goal 模式后，Codex 自主生成的子代理数量远超预期，达到了近 70 个，令其“蚌埠住了”。

核心内容

原文用户描述：“请看。也就快70个代理。看到的时候蚌埠住了。主要是开了goal以后让他可以自己跑。告诉他自带里怎么用就没去管它。打开一看惊呆我了。”

具体场景为：用户启用了 Codex 的 goal 功能（目标驱动模式），让模型根据一个高阶目标自行规划和执行。用户仅告诉了模型“自带里怎么用”（可能指某个工具或库的自带用法）后便不再干预。一段时间后，用户打开界面，发现 Codex 已经生成了将近 70 个独立运行的子代理（sub‑agents/threads），每个代理可能负责一个子任务、一个文件操作或一次推理步骤。这一数字远远超出了用户对典型自主任务分解的预期，因此发出感叹。

帖子共有 2 个参与者（包括楼主），但正文未透露后续讨论细节。

关键要点

• 子代理数量爆炸：在未刻意设定的情况下，Codex 自主生成了接近 70 个子代理，数量远超常见自主执行场景（通常十到二十个）。
• goal 模式触发：开启 goal 后，模型会不断分解任务并生成并行子代理，直至目标达成或被限制。
• 用户干预极少：用户仅提供了初始指令和“自带里怎么用”，其余全由模型自主运行，体现了当前模型在 plan‑execution 上的高度自动化。
• 意外性：用户原本预期数量较少，看到结果后感到震惊，说明该行为不在用户的常规认知范围内。
• 论坛生态：该帖出现在 LINUX DO 的 AI 板块，属于技术爱好者讨论 AI 实操经验的非官方渠道，讨论氛围偏实战与发现。

意义与影响

这一现象从侧面反映了当前大语言模型在自主代理（autonomous agent）领域的能力边界——模型不仅能够理解高维目标，还能主动将其分解为大量细粒度子任务并并行执行，且不受人类常规速率限制。对开发者而言，这意味着：

• 任务分解的失控风险：子代理数量可能指数级增长，消耗计算资源、API 调用配额甚至引发不可预料的行为循环。开发者需要引入上限、超时或人工批准机制。
• 目标设定需要更精确：用户给出的“goal”越模糊，模型分解出的子代理可能越多。未来提示词工程中，显式限制子代理数量可能成为最佳实践。
• Agent 基础设施的挑战：大量子代理的调度、状态管理、冲突解决需要更健壮的框架（如 LangChain、AutoGPT 或自己构建的 orchestration 系统）来支撑。
• 人机协作的新界面：用户从“编程者”转变为“目标监督者”，但突然发现 70 个代理并行工作时，缺乏直观可视化或暂停/汇总能力会导致失控感。这提示产品设计需要提供“代理数量仪表盘”和“任务树折叠”功能。

总之，这个帖子虽简短，却捕捉到了自主代理在实际使用中容易发生的“数量级跃迁”现象，对 Agent 系统的鲁棒性设计具有警示和启发价值。