一旦一个Agent开始工作，最自然的下一步就是引入更多Agent。一个研究员、一个写手、一个审稿人，各自配上独立的提示词和工具。 有时候这是对的。但更多时候，这只是一个穿上戏服的工具调用——你把一个函数变成了一个完整的模型循环，它有自己的轮次、自己的预算、以及自己迷路的可能。 真正值得问的问题其实很窄：**子Agent到底买到了什么是工具买不到的？** 这就是全部关键：子Agent拥有自己的消息历史。因此，它的中间推理过程不会污染父上下文；它可以在隔离的上下文里独立运行；它可以在多轮调用中保持自己的状态。相比之下，一次工具调用会把完整结果直接塞回父上下文，并在之后的每一轮中反复重新发送。 这个框架给出了一条可用的规则： **如果一次工作产生的中间材料远多于最终答案，隔离就是划算的；如果结果很小且流程是确定性的，那就该用工具。** ### 什么时候该用子Agent **搜索并提炼。** 十二份文档读下来，只返回一段话。如果内联执行，这十二份文档会一直留在父窗口中，你在之后的每一轮都要为它们反复付费。用子Agent，读完即弃，只把最终那段话带回来。 **独立的并行工作。** 三个互不需要中间状态的调研。分离的上下文让它们可以并发运行，不会交织成一条混乱的单一历史。 **真正需要不同立场的工作。** 一个不能看到作者推理过程的批评者，或者一个被故意只给予"主张+来源"的核验者。隔离本身就是核心特性——正是它让第二意见保持独立。 ### 什么时候该用工具 **确定性工作。** 解析、格式化、校验、用已知参数调用API。这是函数。中间塞一个模型只会增加延迟、成本和随机性，毫无回报。 **单次工具调用加一层包装提示词。** 如果子Agent的工作只是"调用get_order然后告诉我状态"，你只是在建造一个昂贵的别名。 **需要父完整上下文的工作。** 如果你发现自己把对话的大部分都传进了子Agent，隔离并没有真正发生，你只是为同样的token付了两次钱。 **任何在延迟路径上的东西。** 子Agent是一个完整的循环：多次模型调用，按顺序依次执行。当用户在等待时，这是最糟的选择。 ### 一句话总结 子Agent的价值不在于"更聪明"，而在于**隔离**。中间产物多、可以并行、需要独立立场——用子Agent；结果小、流程确定、只是调用一次API——用工具。别让工具穿上戏服，也别让子Agent戴上工具的面具。
热门跟贴