放养AI代理一晚上，醒来发现它“生了”70个崽？Codex子代理失控实录

最近在折腾AI代理框架的时候，发生了一件让我既好笑又后怕的事。

事情是这样的：我最近在用Codex（一款AI自主代理应用）跑一些自动化任务。为了让它更“智能”一点，我开启了它的Goal（目标）功能，简单来说就是给了它一个大方向，允许它自主拆解任务并调用子代理去执行。设置完之后，我就去忙别的了，完全没放在心上。

结果等我再次打开控制面板，整个人都“蚌埠住了”……

• Codex 控制面板截图，密密麻麻的节点展示了瞬间生成的近 70 个子代理，这就是失控的“繁殖”现场。*

屏幕上密密麻麻全是子代理节点，数量居然快飙到70个了！这哪是自动化啊，简直是指数级“繁殖”。看来如果不加限制，AI为了完成一个复杂的任务，真的会尝试穷尽所有可能的路径，甚至在这个过程中不断派生出新的“分身”来处理细节，导致代理数量失控。

为什么会“爆表”？

这次经历让我深刻理解了递归调用和自主决策边界的重要性。现在的AI代理很多都具备类似“思考-行动-观察”的循环机制。

当一个代理觉得任务太复杂，或者遇到无法直接处理的步骤时，它可能会本能地生成一个子代理来专门解决这个问题。如果父代理没有设定好终止条件，或者对任务的拆解缺乏宏观约束，子代理又可能会生成“孙代理”，以此类推。虽然这展示了AI强大的逻辑拆解能力，但在资源有限的环境下，这简直就是一场灾难。

• 示意图：正在一脸震惊地看着控制面板的作者（AI生成）。*

特别是结合了像Codex App这样的工具，一旦代码执行环境或者API调用没有限制，生成的子代理可能会并行发起大量请求，不仅烧钱，还可能导致系统卡死。好在这次我只是在本地环境测试，要是直接接了生产环境的API，钱包估计已经哭晕在厕所了。

怎么给代理“上枷锁”？

既然发现了问题，总得想办法解决。经过这次“惊吓”，我总结了几个给自主代理“降温”和“设限”的小技巧，适合大家在自己的测试环节参考：

1. 设置硬性数量上限

这是最直接的手段。在配置Agent时，务必查阅文档看是否有max_iterations（最大迭代次数）或max_sub_agents（最大子代理数）类似的参数。如果没有，开发者可能需要手动在代码里加个计数器，一旦子代理数量超过5个或10个，强制中断递归并报错。

2. 限制Token消耗和时间预算

别让AI无限思考。给每个Task设置一个时间预算（比如10分钟内必须结束）或者Token预算。一旦算力消耗接近红线，立即强制停止当前任务栈，防止它为了钻牛角尖而不断派生新代理。

3. 强化“Goal”的描述精度

很多时候AI瞎折腾是因为目标太模糊。比如把“帮我优化这个代码”改成“在不改变原有函数接口的前提下，重构这段代码的循环逻辑，只允许生成一次草稿”。指令越明确，它乱七八糟的尝试就会越少。

4. 手动审批机制（Human-in-the-loop）

对于关键任务，不要开启全自动模式。可以让代理在“打算生成子代理”或者“打算执行高风险操作”时停下来，等待人类确认。虽然牺牲了一点自动化效率，但安全系数拉满。

新风向观察：AI代理正在变得“难以驾驭”

这个小插曲其实也反映了现在AI技术的一个新风向：从单纯的对话式AI，向具备自主规划和执行能力的Agent演进。

像Codex、AutoGPT这类工具的出现，确实让我们看到了“让AI帮你打工”的曙光。但随之而来的管理复杂度也是成倍增加的。未来的AI开发，可能不仅仅是写Prompt，更多的是做“资源调度”和“风险控制”。你得像个项目经理一样，不仅能指挥AI干活，还得时刻盯着它别把项目组（服务器）给撑爆了。

总之，如果你也在玩类似的AI Agent，记得先把家里的“粮草”（算力/预算）管好，再让这位“全能管家”撒手跑，不然真的会遇到惊喜（或者惊吓）。