LLM生成树架构的机制与代价

来源：X @itianjio

“现在都是 llm-generated tree，llm 自动生成 dag 了。“^[0] 这句判断描述的是正在发生的架构迁移：执行流从单一线性变为模型自动生成有向无环图（DAG）来求解 ^[0]。该判断已有研究支撑：有公开研究让 LLM 生成 DAG、把复杂任务划分成带依赖关系的子任务 ^[53]，有论文把执行历史组织成调用树构成的 DAG ^[4]，LangChain 生态中也有”演进式 DAG”的实践 ^[8]。但”生成一棵树”只是表面现象，需要拆解的是树下面的三层机制：沙箱如何隔离状态、调度器如何在 DAG 上执行、剪枝如何决定这棵树”长满”还是”长对” ^[0,49,43]。

一棵由 LLM 生成的执行树

素材描述的架构分三层 ^[0]。最外层是 Session：一个会话不再对应单一路径，而是作为根节点向下分发并管理多个并行的 Sandbox ^[0]。每个 Sandbox 是独立执行环境，负责一个 Task，隔离保证不同任务的状态互不干扰 ^[0]；这正是沙箱范式在工程上的核心——AgentScope 把状态按作用域划分，SESSION 级天然隔离，跨会话共享的 USER/AGENT/GLOBAL 级必须加显式并发保护 ^[19]。中间层是 Workflow 调度，在 Task 层面控制整体流程与依赖 ^[0]；最内层是 Step 里的 ReAct 循环，包含观察、思考、工具调用、结果，如今只是整棵决策树的一个叶子 ^[0,48]。

任务的拆解是递归的：根节点把问题拆成多个子任务（Task），每个 Task 再拆成多种可能的计划（Plan），Plan 细化为具体 Step ^[0]。节点以 Pending（等待调度）、Running（执行中）、Finished（已完成）标记，全部 Finished 即 Tree Completed ^[0]。遇到不确定性时并行尝试不同 Plan，是这套架构最直观的卖点 ^[0]。

这套结构与已有研究一脉相承。树搜索框架把推理从单遍解码推广为”系统性展开、评估、聚合多条候选轨迹” ^[2]；Chain/Tree/Graph of Thoughts 的通用架构被拆解为生成器、评估器、终止器、控制器四个模块 ^[3]。Agent 工作流的模式库（链式、并行化、路由、编排器-工作者、评估器-优化器）与素材的分层对应，静态的 DAG 图与动态的 ReAct 循环被统一进同一谱系 ^[48]；节点拓扑包括非线性链、循环、分叉-汇聚、树、网格，路由方式从静态、条件分支扩展到 LLM 动态决策 ^[51]。

为什么是 DAG：线性链的结构性缺陷

素材给出的理由是容错：线性链一旦某一步出错，后续全部失败 ^[0]。更准确地说，线性链的结构性缺陷是控制流僵化。条件路由（“检索失败就回退到网页搜索，再失败就上报人工”）只能写在链条外面，无法进入执行模型内部 ^[49,55]。

DAG 的执行机制是：每个任务一个节点、每个依赖一条边，按拓扑排序推进。一个节点的所有前序完成后才进入就绪状态，调度器只评估就绪性，不必预先知道工作流形状 ^[49]。这带来线性链没有的三样能力。独立节点真正并行：LLMCompiler 把工具调用表示为 DAG 节点并同步分发，比顺序执行快 3.6 倍；1000–1500 字内容的工作流从顺序切到并行，端到端时间减少 36–37% ^[49]。条件路由成为一等公民的边：LangGraph 的边携带基于共享状态的谓词，失败模式、回退路径、上报分支都编码在图里，执行模型与控制流模型合二为一 ^[49,55]。局部故障恢复：调度器精确知道哪些下游被阻塞、哪些没有，未受影响的分支继续执行，配合检查点从最后一个成功的节点恢复 ^[49,55]。素材对比表里的”局部失败不影响其他分支”正是这条结构性保证，而”资源消耗极高”则是它的代价 ^[0]。素材据此断言该架构”极大地提高了复杂任务的成功率”，但现有证据没有给出成功率提升的基准，可查证的是速度与稳定性收益 ^[49,4]。

不过这套能力远未普及：一份 Agent 工作流综述指出，75% 的系统只支持基础的链式或并行模式，缺少条件分支、循环迭代、异常处理等高级控制流 ^[48]。素材把适用场景从”简单查询、固定流程自动化”推进到”复杂研发、多步骤代码生成、深度搜索”，描述的其实是少数先行者的状态 ^[0,48]。

被忽略的第二重收益：上下文按深度生长

素材把树的价值归结为并行与容错 ^[0]，但证据指向更根本的一层：上下文管理。上下文窗口像内存，模型推理时只能基于其中内容，但容量有限、按 token 计费昂贵 ^[14]。窗口数字一直在涨（GPT-4o 128,000 token、Claude 200,000、Gemini 2.5 Pro 超过一百万），团队以为问题解决了：把指令、工具结果、历史全塞进去跑 ^[14]。结果是 demo 能跑通、生产环境就崩，原因是架构性的，不是模型问题 ^[14]。已有工作用”指针”把大数据放回上下文之外，让模型只接触短标识符 ^[13]。

LLM-as-Code 给出了树/DAG 在这一层的关键作用：当控制权在程序手里，LLM 的上下文由执行历史的调用树构成，形成 DAG；每次调用的上下文长度由调用深度决定，而不是随步骤累积 ^[4]。它的参考实现里，每个 LLM 调用点是一个带装饰器的 Python 函数，装饰器把提示模板、模型、输入输出模式藏在函数签名之后 ^[4]。也就是说，DAG 同时处理了线性 Agent 的两大死因：错误的级联传播 ^[0,49]，与上下文随步骤膨胀 ^[4,14]。论文对计算机使用型 Agent 的案例研究表明这是实际效果——长视觉操作序列的稳定性得到显著改善 ^[4]。

一致性：靠隔离与检查点，不靠共享

素材的质疑很具体：多个 Sandbox 并行时，如何保证全局状态一致？一个任务改了数据库，其他任务怎么感知 ^[0]？工程上的做法是承认共享有边界，不要求沙箱共享状态。AgentScope 的状态作用域说明：SESSION 级天然隔离；USER/AGENT/GLOBAL 级跨会话共享需要显式并发控制，本质是”顺序复用”而非”并发共享”——并发请求各自跑独立容器，结束时都写同一个 state slot，最后写入的生效 ^[19]。分布式系统对一致性同样按级别取舍，从强一致性到最终一致性是一道谱系，会话一致性是最广泛使用的级别 ^[20]。

把”树”与”一致性”真正绑在一起的是沙箱检查点系统。DeltaBox 提供毫秒级沙箱 checkpoint/rollback ^[25]；一致性靠 CRIU 的 SIGSTOP 屏障在单一瞬间冻结文件 I/O 与内存变更，保证 (文件系统, 内存) 快照对在同一时刻截取 ^[25]。它的 StateManager 分两层：宿主机侧的 Sandbox Controller 做全局协调，访客侧的 Guest State Daemon 做本地执行 ^[25]。Sandbox Controller 维护的全局快照索引树与搜索树同构，每个节点记录快照 ID、CRIU dump 路径与 overlayfs 层配置 ^[25]——素材图里”回退到父节点、尝试另一个 Plan”，在实现层面就是”恢复父节点对应的快照”。状态一致性通过让每个分支独立回到某个一致的时刻实现，分支之间不直接观察 ^[0,25]。

成本与死锁：两个真实但性质不同的风险

成本是树架构最直接的代价：为生成一棵树，模型需要调用数十甚至上百次 API ^[0]，并行分支与多次调用把资源消耗推到极高 ^[0]。这一点素材说得很直白，没有捷径可绕。

死锁则需要拆开看。DAG 作为执行模型，其无环约束本身就是”不存在循环等待”的结构保证 ^[49]；真正的风险在于 LLM 生成的逻辑出现闭环、Step 间依赖判断失误，图就可能不满足无环前提，从而卡死 ^[0]。这与前文提到的”高级控制流普遍缺失”吻合 ^[48]。死锁的防线不在执行引擎，而在生成与校验层：无环是 DAG 的前提而非结果 ^[49]，LLM 生成的图必须先满足这个前提 ^[0]。

剪枝：把盲目展开变成有选择的探索

素材预测的演进方向是剪枝：早期放弃成功率低的分支，而不是盲目展开所有可能性 ^[0]。这个方向已有系统落地，剪的对象不止是”分支”。ToolTree 给 LLM 智能体引入 MCTS 启发的搜索、双重评估与双向剪枝，目标是自我纠正与资源的高效分配 ^[40]。针对长上下文导致的性能退化，Prune4Web 把”语义过滤”改写成”代码生成”任务：LLM 不再直接解析 DOM，而是生成轻量的 Python 程序，对 DOM 元素打分并剪掉冗余，走 Planning → Programmatic Filtering → Action Grounding 的多阶段流程 ^[43]——同样是”剪掉低价值节点”的思路，只是对象换成了真实的 DOM 树 ^[0,43]。剪枝还有一个原则：剪枝决策一旦依赖模型判断，就失去了对下一轮对话的可预测性。有人为此构建了纯确定性的提示剪枝层，使用 dataclass、正则、字典查找，不调用模型 ^[44]。让”该剪哪里”由规则说了算，比让模型自由发挥更稳 ^[44]。

原文更正：素材称该架构”极大地提高了复杂任务的成功率”，但可查证的收益是并行速度（LLMCompiler 较顺序执行快 3.6 倍）与长视觉序列稳定性，没有公开基准支撑”成功率大幅提升”的幅度。 ^[4]