子代理嵌套子代理：多少层深度才算太多？

代理正在开始生成代理。当你给一个代理足够大的任务时，一种越来越常见的策略是委派。父代理决定部分工作应该交给其他地方处理，于是启动一个拥有自己上下文和指令的子代理，等待结果，然后继续。那个子代理最终也可能做同样的事情。

这种工作方式有充分的理由。子代理可以拥有更窄的任务范围、更干净的上下文窗口、不同的工具，或者专门针对所给任务定制化的指令。它还可以做大量探索性工作，而无需把所有上下文都倾倒回父代理。然而，一旦代理能够递归地委派，一个显而易见的问题就出现了：我们该让它们深入到多少层？

我不认为存在一个神奇的数字。两层并不天生安全，五层也不天生鲁莽。更有用的问题是，当每一层出现问题时会发生什么，以及图中有多少部分会因此受到错误影响。

子代理将代理执行变成一张图

你可以把父代理生成子代理想象成一棵树。父代理委派给多个工作代理，有些工作代理再次委派，结果最终流回顶层。但真实系统很快就会变得比树复杂得多。

一个代理的研究成为另一个代理的输入。多个分支被合并在一起。评审者评估工作代理的输出。规划者生成一个计划，多个执行者遵循该计划。有些分支并行运行，而另一些分支必须等待其依赖完成后才能开始。到了这个程度，你就拥有了一张图。

这大致就是人们开始称之为图工程（graph engineering）的东西：将代理工作各部分之间的节点、依赖、路由和状态转换显式化。这种框架改变了我们思考子代理的方式，因为我们可以不再仅仅问“有多少代理在运行？”或“它们嵌套得多深？”，而是问每个节点产生什么、哪些其他节点消费它，以及最终结果中有多少部分依赖于它。

这是一种更有用的可靠性推理方式，因为并非每个节点承担相同的风险。有些节点位于图的边缘，产生小而孤立的贡献。另一些节点位于图的上游，为后面许多节点建立前提。

错误具有爆炸半径

想象一个代理生成一份竞争分析。第一个代理决定哪些竞争对手重要。三个子代理研究这些公司。它们的输出再喂给另一个比较产品的代理。这个比较结果传给另一个识别战略威胁的代理，最后还有一个代理撰写建议。

如果最后的撰写代理对一个建议措辞不当，你会遇到一个相对局部的问题。大多数底层工作仍然完好。如果第一个代理选错了竞争对手，那么下游所有环节都可能执行得很完美，但最终答案仍然可能是错的。

重要的区别在于错误是在图的哪里进入的，以及有多少工作依赖于它。上游节点不仅仅是贡献了一个错误的输出。它可以为许多下游代理的操作建立前提，而那些代理随后可能会强化这个错误，因为从它们的角度看，这个坏输出只是它们输入的一部分。

叶子节点上的错误可能只损害一片叶子。靠近根部的错误可以毒害整个分支，而且问题会随着扇出而变得更糟。假设一个规划代理生成一个任务分解，喂给十个工作代理。该计划中的一个错误现在有十个传播机会，而那些工作代理可能各自产生输出，再喂给更多节点。

层数很重要，但每一层的下游影响力更重要。一个深度嵌套的代理在孤立任务上工作，对最终结果的影响可能很小；而一个浅层代理做出的早期路由或规划决策，可能决定后续的一切。

每一次交接都可能让错误固化

深度嵌套的子代理还有另一个问题：信息在每个边界都会发生转换。一个子代理可能检查二十份文档，然后返回一段五段式摘要。它的父代理利用这份摘要制定计划。另一个代理接收部分计划并将其转化为分析，而最后一个代理将几份分析综合成一项建议。

每一步可能单独看都合理，但每一步都是在处理上一步产生的工件，而不一定是在原始证据上操作。这意味着一个小错误可能逐渐变成一个假设。

递归委派让这一点特别容易被忽视，因为父代理通常看不到其后代看到的一切。上下文隔离是子代理的好处之一，但它也在最终决策和最初支持该决策的证据之间制造了距离。

图工程应该是依赖工程

这就是为什么我认为图工程最重要的部分之一，将是决定什么可以依赖什么。如果一个代理产出具有巨大下游影响力的东西，那么这个节点比产出最终响应中孤立部分的节点更应该受到严格审查。

也许它应该有一个验证者。也许它的输出需要结构化。也许原始证据应该与其结论一起传递。也许在图的流程继续推进之前，应该由几个代理独立产生相同结果。在某些情况下，可能需要人工批准后，工件才被允许扇出到图的其余部分。

图让这些决策变得可见。不再是一个代理递归地生成工作代理、按自己的想法传递摘要，而是可以显式建模类似“证据 → 分析 → 计划 → 执行 → 综合”的流程，并决定哪些工件跨越每个边界。

你还可以决定分支在哪里扇出、在哪里汇合、在哪里需要保留来源追踪，以及在一个高影响力工件成为另外五个节点的前提之前，应该在哪里进行检查。图工程给我们的不仅仅是协调代理的方式。它给了我们一种控制系统内不确定性传播的方式。

那么多少层才算太深？

我不认为答案是三个代理、四层，或者其他某种通用限制。一个深层图，如果每个节点都有狭窄的职责、扎实的输入、明确的输出和有限的下游影响力，可能相当可靠。而一个浅层图可能极其脆弱，如果早期某个代理做出了一个宽泛的判断，其他代理都不加质疑地接受的话。

我关心的衡量标准更接近爆炸半径。对于任何代理生成的工件，问一问：如果这个工件错了，还有什么也会跟着错？如果答案是最终输出中一小部分，那么你可能可以容忍一个相当自主的节点。如果答案是工作流中剩下的每一个步骤，那么这个节点就需要一个截然不同的工程标准。

随着代理越来越擅长生成子代理，构建令人印象深刻的委派高塔将变得越来越容易。代理 A 请求代理 B，B 又请求代理 C 和 D，C 和 D 各自启动自己的工作代理，最终一个打磨过的结果冒泡回到表面。工程挑战不在于我们能把那些图建得多深，而在于我们是否理解哪些节点拥有足够大的下游影响力，足以把图的其余部分一起拖垮。