事先声明：我开发了 代理原型，这是该市场中的工具之一。后半部分提到的基本组件是真实存在的，相关领域也是可验证的；而前半部分提出的问题则是大家共同面临的。欢迎指正——请提交问题报告。
这就是多智能体的梦想，而且是一个美好的梦想：你将一个大型任务交给一个能力强大的智能体，它不是独自艰难地完成任务，而是组建一个小团队——一个子智能体负责研究，两个智能体并行实施，一个智能体负责审查——等待它们全部完成，然后将合并后的结果交给你。这是一个管理协调器的协调器。它行之有效，且确实强大。
现在，带着工程师特有的偏执再读一遍这句话。一个管理协调器的协调器。如果一个智能体可以生成其他智能体，那么它生成的智能体也可以生成更多的智能体。而在“你可以生成子智能体”这一说法中，并没有说明这种生成行为在哪里停止。
你已经熟悉这种模式了。这是 Unix 体系中最古老的恶作剧：
:(){ :|:& };: # 一个永远调用自身两个副本的函数
这就是叉炸弹（fork bomb）。它并不执行任何恶意操作——每个副本只是礼貌地启动另外两个副本，直到进程表填满，机器瘫痪。一个拥有无限制生成工具的编码智能体，其结构与此相同，只是中间换成了语言模型，而底层则是你的应用程序接口账单。
如果你记不住其他内容，请记住这一个观点：
生成智能体并不是一个你可以随意开启的功能。它是一种你授予的权限——而如果一种权限没有深度、广度或上限的限制，那它就是一颗怀着良好意图的叉炸弹。
你在不知不觉中授予的权限
当你给智能体提供一个 spawn_sub_agent（生成子智能体）工具时，你不仅仅是在增加一项功能。你是在授予它递归地向自身赋予相同能力的权利，次数取决于其推理过程如何说服自己。大多数设置隐式且完全地授予了这种权限：如果工具集中包含该工具，那么生成行为就是无限制的——任何深度、任何数量的子智能体，且每个子智能体都拥有与父智能体相同的权限。
有两件事会让成本迅速飙升，且这两者都不是假设性的。首先是成本。Anthropic 公司关于子智能体的指导方针指出，你应该将探索工作隔离在子智能体中，正是因为每个子智能体可能会消耗一万令牌，仅仅为了返回一个五行摘要——当只有一个子智能体时，这很便宜；但当一个困惑的父智能体生成了十二个子智能体，而每个子智能体又各自生成了十二个时，这就变成了一场大火。其次，多智能体反应本身通常是错误的：
这张应该让你放慢脚步的收据。最顶尖的协调器编写者都认同一条规则：作业生成的智能体数量是协调决策的**输出**，而不是输入。你选择多智能体工作流，不是因为你可以这样做，而是因为工作的性质要求你这样做。一个仅仅因为生成功能可用就进行生成的智能体，跳过了唯一重要的决策。
因此，问题不在于多智能体协调。而在于不受管控的生成行为——将一种递归的、自我复制的能力交给大型语言模型，并相信它的判断力不会让它冲下悬崖。解决方案不是“不要生成”，而是“将生成行为变为一种受计量的权限”。
你的设置目前如何限制生成行为？
在构建之前，请诚实地评估自己的立场。四种姿态，每种都有其上限。
无限制。任何
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
