腾讯新作 GraSP：给 LLM Agent 塞更多技能反而更笨？把技能编译成 DAG，奖励飙 19 分、步数砍 41%

一句话讲清楚👉🏻 腾讯提出 GraSP ，把扁平的技能列表编译成一张带"前置条件-效果"依赖的类型化 DAG ，一次失败只修局部 O(d^h) 子图而不是重规划整条链 O(N)，在 ALFWorld / ScienceWorld / WebShop / InterCode 上用 8 种大模型跑全部 48 个配置全部胜出，奖励最多提升 19 分，环境交互步数最多减少 41%。

一、先说一个反直觉的现象：技能越多， Agent 越笨

过去一年多， Agent 社区有一个基本假设：只要我们给 LLM 配上足够多的技能（ skills / tools / APIs ），它就能应付足够复杂的任务。于是大家疯狂扩充技能库， Voyager 囤了一屋子， Gorilla 对着几千个 API 学， ToolLLM 、 ToolNet 一路卷到几万。

但是，近期一批基准测试揭露了一个让人有点尴尬的现象：给 Agent 更多技能，并不会单调地提升性能，反而经常让性能掉下来。

论文里有一组非常干脆的数据：

用最粗暴的话说：瓶颈已经不是 技能够不够用了，而是 Agent 不知道怎么把技能搭起来用。技能生态从"不够多"切换到"不知道怎么编排"。

这个现象背后，有两个很具体的技术根因。

第一个是认知过载。 把检索到的所有技能一股脑塞进 prompt ，会吃掉宝贵的上下文预算，而且技能描述本身就很长，模型注意力被稀释，相关信息反而被淹没。

第二个问题更致命：扁平执行丢掉了因果结构。 真实任务里的技能之间是有前置条件、效果和依赖关系的：你得先拿到钥匙才能开门，先登录才能下单，先 git add 才能 git commit。但现有的 Agent 框架（ ReAct 、 Reflexion 、 ExpeL ）把技能当作一个个独立的动作线性执行，一旦中间任何一步失败，整条后续都作废，必须从头重规划——这是 O(N) 的开销。

腾讯这篇 GraSP 直接给这个问题拍了板：在"技能检索"和"技能执行"之间，缺了一层叫"技能编排（ orchestration ）"的编译层。检索告诉你"哪些技能相关"，执行告诉你"现在做什么"，但中间没人告诉你"这些技能之间怎么依赖"。这一层缺失，才是扁平 Agent 脆弱的根源。

二、 GraSP 的核心主张：把技能列表编译成一张带类型的 DAG

GraSP 的全称是 Graph-Structured Skill Compositions。思路非常朴素：既然扁平序列不行，那就把技能搭成一张图。

整个系统有四阶段流水线，每个阶段都对应一个具体的问题：

阶段一：记忆条件检索（ Memory-conditioned Retrieval ）。 从大技能库里选出一个聚焦子集。这里不是只做语义匹配，而是把情景记忆也融合进来——以前成功轨迹里频繁出现的技能组合会被更高权重地选出来，同时还会输出一个校准过的置信度分数。

阶段二： DAG 编译（ DAG Compilation ）。 这是 GraSP 最核心的创新。把选出来的技能编译成一张类型化有向无环图，每条边都明确标注是哪种依赖关系。

阶段三：带校验的执行（ Verified Execution ）。 按拓扑顺序遍历图，每个节点执行前检查前置条件，执行后检查后置条件，出了问题立刻发现。

阶段四：局部修复（ Local Repair ）。 节点失败时只修它所在的局部子图，不碰已经验证过的其它部分；修不动再升级到全局重规划；还不行就降级到 ReAct 兜底。

三种边：把"技能之间的关系"显式写出来

DAG 上的每一条边都是类型化的，这个设计是让"局部修复"能成立的关键前提。

State 边(u, state, v)：表示 u 的某个效果 满足 v 的某个前置条件。比如 pick_up_key 的效果是"持有钥匙"，open_door 的前置条件是"持有钥匙"，两者之间就是一条 state 硬边。

Data 边(u, data, v)：表示 u 的输出 直接绑定到 v 的输入。比如 search_product(query) 返回商品 ID ，add_to_cart(product_id) 需要用这个 ID 。这也是硬边。

Order 边(u, order, v)：来自经验记忆或者资源冲突的软优先约束。没有严格因果依赖，只是"按这个顺序成功率更高"。这是软边，修复时可以断开重连。

硬边是骨架不能动，软边是润滑剂可以调整，这个区分让系统在修复时能精准知道哪些约束不能破、哪些可以灵活变通。

每个节点的属性结构

GraSP 用一个八元组描述每个技能节点：

其中 κ_v 是技能 schema ，θ_v 是绑定的参数，φ_v^pre 和 φ_v^eff 分别是前置条件和后置条件，ν_v 是校验器，ζ_v 是执行状态， c_v 是置信度， b_v 是修复预算。

这套属性不是装饰，每一项在后续的编译、校验、修复阶段都会被用到。特别是修复预算 b_v ，它决定了一个节点最多能被修复多少次，防止陷入无限修复循环。

三、五个类型化修复操作符：局部化修复的"代数"

这是 GraSP 第二个核心贡献。当某个节点 v_f 执行失败，系统不会去重规划整条链，而是根据失败类型，在 v_f 的 h-跳邻域内应用五个形式化操作符之一。

举一个具体的例子：在 ALFWorld 里， Agent 想 heat_object(tomato, microwave) 失败了，原因是微波炉的门是关的。

论文给出了这个"局部化"的规模界限：每次修复补丁节点数 |ΔV| ≤ L_max （默认 3 ），补丁边数 |ΔE| ≤ E_max （默认 5 ），邻域半径 h=2 。在 ALFWorld 典型任务里，出度 d ≈ 2 ，受影响子图稳定控制在 4~5 个节点，与计划总长度无关。

为什么 O(N) → O(d^h) 是本质差异

这个复杂度的跳变值得多解释两句。

扁平链的脆弱性在于：第 k 步失败时，后续的 N-k 步都是基于"第 k 步成功"的假设写出来的，全都要作废。任务越长 N 越大，一次失败的代价就越惨烈。

而 DAG 结构有一个关键性质：节点 v 的失败，只让它的拓扑后代作废。如果 v 的出度是 d ，往下走 h 层受影响的节点数是 d + d² + ... + d^h = O(d^h)。只要 d 和 h 有界（实际工程里 d=2, h=2 ），这个开销就是常数级的，和整个计划的长度 N 完全脱钩。

这也解释了为什么 GraSP 的优势会随着任务复杂度放大：短任务 N 小，扁平模式也没吃多大亏；任务越长， O(N) 和 O(d^h) 的差距被放得越开。

四、两个关键公式：检索与置信度的数学表达

融合检索分布（ Eq. 1 ） 把语义匹配和情景记忆组合起来：

其中 p_dir 是直接语义分布，后半部分是基于检索到的 top-k 成功轨迹 τ 中技能出现频率的加权平均，ρ_j 是记忆相似度， Z 是归一化常数。默认 λ=0.5 ，检索和记忆各占一半。

校准检索置信度（ Eq. 2 ） 输出一个 0~1 之间的置信度用于后续路由：

特征向量 f 有四维：平均记忆相似度 ρ̄、分布一致性 1−JSD 、 top 技能差距 p₁−p₂、以及目标覆盖率。σ 是 sigmoid 。η=0.7 时，学习到的置信度占七成、历史成功率占三成。

这个置信度会接到一个三档路由：低于 τ_low=0.40 时直接回退到 ReAct ，高于 τ_high=0.65 时用完整 DAG ，中间地带用简化版。这个设计让 GraSP 在"图结构能帮上忙的任务"和"不适合用图的任务"之间自动切换，而不是一条路走到黑。

五、实验： 48 个配置全胜， 4 个基准 + 8 个大模型

实验规模相当扎实。 4 个经典 Agent 基准：

8 个大模型后端： DeepSeek V3.2 、 Gemini 2.5 Pro 、 GLM-5 、以及 5 个其它主流模型。总共 48 个 (模型, 划分) 配置，GraSP 全部胜出。

主表： DeepSeek V3.2 后端下的代表性数据

只看最核心的几列（ R 表示奖励， S 表示步数，越高越好 / 越低越好）：

对比最强基线， GraSP 的奖励提升 +5~7 分，步数同时降低 1.5~3 步，效果和效率同时变好，而不是一边涨一边跌的 trade-off 。

单模型极端案例

整体统计结论

六、消融实验：哪个组件最重要？

消融结果按组件逐个加回来（ DeepSeek V3.2, ALFWorld / ScienceWorld ）：

几个发现值得关注：

DAG 编译是贡献最大的单一组件。 从扁平的 74.9 跳到带编译的 78.4 ，是整个系统里最大的一跃。

Monolithic 反而比选择性检索更差。 把全部技能塞进去拿到 67.1 ，比只给筛选后 3-5 个技能的 74.9 低 7 分——这是"少即是多"最直接的数据证据。

全局重规划拖后腿。 把 GraSP 的局部修复换成全局重规划，效果降到 77.4 / 81.8 ，验证了"不能因为一个节点失败就扔掉所有已验证的进展"这个原则。

七、三层容错机制：从直接成功到兜底

把失败处理拆成三层是 GraSP 的一个工程智慧：

这种分层设计的好处是：大部分任务用便宜的 O(d^h) 修复就解决了，真正昂贵的全局重规划只在少数 hard case 上触发，整体效率自然就上来了。

前置条件失败的修复成功率是 84.2%，比全局重规划的 61.8% 高了整整 22.4 个百分点——因为局部修复能精确定位"缺了什么前置条件"，而全局重规划相当于重新打一遍牌，还不一定能打到关键那张。

八、鲁棒性：扛得住过度检索和质量退化

两个鲁棒性实验特别能说明问题。

对过度检索的鲁棒性： 扁平模式在 M=3 时到达峰值， M=8 时下降约 6%。 GraSP 在 M=8 时拿到 79.4 ，仍高于扁平最优 M=3 的 74.9。原因是 DAG 编译自带一层"过滤"，编译过程中低置信度的软边会被砍掉，相当于给检索结果做了二次清洗。

对技能质量退化的鲁棒性： 质量从高降到低，扁平模式掉 9%， GraSP 只掉 5%。而且 GraSP 在低质量技能下的 75.4 仍然高于扁平模式高质量下的 74.9——换句话说，GraSP 用烂技能编出来的图，比扁平模式用好技能直接执行还强。

这个结果对工程落地意义很大：现实中技能描述经常参差不齐，有人写得详细有人写得敷衍， GraSP 的容错空间给了工程师更大的回旋余地。

九、为什么 DAG 结构在 Agent 上是合适的抽象

回到一个更本质的问题：为什么图结构对 LLM Agent 有效？

论文的 Finding 4 给出了一个漂亮的规律：GraSP 的优势随任务复杂度单调增长。短任务（≤10 步）领先约 6%，长任务（≥20 步）领先约 18%。

这个规律直接印证了"O(N) vs O(d^h)"的理论分析——任务越长，扁平重规划的开销线性膨胀，而 DAG 局部修复的开销被邻域半径锁死在常数级，差距就越拉越大。

更重要的是，DAG 恰好是 Agent 任务的自然结构。大多数真实任务不是严格的单链，而是带部分序、可并行、有多条路径的有向图：做饭可以同时煮饭和切菜，网购可以同时浏览和比价。扁平链强行把这种天然的图结构线性化，损失的信息只能靠模型自己"脑补"，而 DAG 把这些结构显式写出来，模型就不用猜了。

十、和已有工作的区别在哪

对照一下几个容易混淆的相关方向：

vs HTN / PDDL 等经典规划： 经典规划要求环境完全可观察、动作确定、领域手工建模，现实中的 LLM Agent 场景全都不满足。 GraSP 借用了"前置条件-效果"这个古老思想，但把它嵌入到概率化的检索-编译-修复流水线里，不依赖完全可观察性。

vs Chain-of-Thought / Tree-of-Thoughts / Graph-of-Thoughts ： 这些是推理层 的图结构，操作对象是 thought 。 GraSP 是执行层 的图结构，操作对象是可执行技能，且有明确的前置-效果语义，不是纯文本推理。

vs Voyager / SkillWeaver 等技能学习： 这些关注"怎么学出技能"， GraSP 关注"怎么把已有技能组织起来用"，两者是互补的，不是竞争的。

vs ReAct / Reflexion / ExpeL ： 这些都是扁平执行范式， GraSP 的对照实验直接把它们按在地上摩擦。特别值得注意的是， GraSP 的最低层兜底就是 ReAct——也就是说，GraSP 是 ReAct 的严格超集，编译成功了走 DAG ，编译不了就退回 ReAct ，不会比 ReAct 更差。

十一、几个值得思考的点

DAG 编译的质量是整个系统的天花板。 编译阶段决定了前置条件、效果、依赖边是否准确。论文里编译由 LLM 提议+记忆优先级+环路检测完成，但可以想象在更复杂的真实系统里，这一步的准确率会成为瓶颈。

软边和硬边的区分是工程智慧。 硬边来自形式化的前置-效果匹配，软边来自经验。硬边保证正确性，软边提升效率。修复时只动软边不动硬边，避免了"为了快而破坏正确性"的退化。

局部修复的三层升级是关键兜底。 只做局部修复，失败率会比较高；只做全局重规划，开销又太大；只用 ReAct 又回到了起点。三层组合才把"效率"和"鲁棒性"同时拿下。

置信度路由让系统自适应。 不是所有任务都适合 DAG——如果检索置信度低，说明记忆里没有类似任务，强行编译反而会产生错误的依赖。这种情况下回退到 ReAct 是明智的选择。

这也为 Agent 架构的下一步指了方向。 过去两年 Agent 领域一直在"加技能、加工具、加文档"， GraSP 告诉我们：不需要更多技能，需要更好的编排。编排层的工程化、自动化、可验证性，会是接下来一段时间的重要战场。

十二、实用超参数参考（工程落地时的默认值）

另一组与修复预算有关：

这些参数都有很直观的工程意义： h 和 L_max 直接决定了"局部修复"的局部性； R_max 防止单节点无限修复； P_max 约束了全局重规划的触发频率。想复现的同学可以从这组默认值开始。

十三、一点小结

GraSP 的核心贡献，用一句话概括是：给 LLM Agent 加一层"编译器"。

把扁平的技能列表，编译成带显式因果依赖的类型化 DAG ，让"技能之间的结构"从隐式变成显式；把"一次失败全部重来"的 O(N) 重规划，替换成"只修受影响子图"的 O(d^h) 局部修复；把"检索-执行"的两段式架构，补全成"检索-编译-执行-修复"的四段式流水线。

48 个实验配置全胜、最高 41% 步数削减、对过度检索和质量退化双重鲁棒，这些数字背后，是一个相当本质的设计切换：Agent 系统的瓶颈从"能力"转向"编排"，解法从"更多"转向"更结构化"。

在 Agent 架构设计越来越成为系统工程问题的今天，这篇工作值得仔细读两遍。