给 Agent 一张会自己进化的"流程图"：Procedural Graphs 论文解读

你有没有碰到过这种情况：刚部署的 LLM Agent 头几步还挺像样，跑着跑着就开始犯迷糊——忘了自己原本要干嘛、工具调用顺序乱成一团、同一个无效动作重复好几遍。轨迹越长，这个问题越严重。

说实话，我自己调 ReAct 类 Agent 的时候就被这个折磨过。事后看 trajectory，错误往往低级得让人哭笑不得：该先查库存再下单，它直接下单；该验证结果，它闷头继续。模型能力明明够，缺的不是"脑子"，是"章法"——做什么、按什么顺序、在什么条件下做，这些程序性知识（procedural knowledge）全都隐式地埋在对话历史里，靠模型自己临场悟。

这篇来自 Google 的论文给出了一个我觉得相当漂亮的答案：给 Agent 外挂一张显式的"程序图谱"（Procedural Graph），而且这张图能自己从成败经验中进化。

核心摘要：Procedural Graph（PG）把程序性知识组织成 (procedure, relation, procedure) 三元组的有向属性图——就像知识图谱用 (entity, relation, entity) 回答"是什么"，PG 回答"该做什么"。运行时，系统定位 Agent 当前在图上的位置，由一个 guidance 模型把周围子图翻译成步级引导，软注入 solver 的 prompt（偏置而非强制下一步动作）；离线时，一个 refiner 对比失败与成功轨迹，提出图的增删改，只有验证集性能不降才提交。在 7 个基准、4 个主流 LLM 上，PG 在 24 个模型-基准组合中的 21 个排名第一或并列第一；从零骨架自进化出的图甚至能匹配或超过人工设计的图，还能把一张"有毒"的专家图从 58.93% 修复到 92.86%。这不是底层推理能力的突破，而是 Agent 工程架构层面一次干净利落的整合——但它的完成度和大规模验证，值得每个做 Agent 的人认真读一遍。

论文信息

• 标题：Procedural Graphs: Self-Evolving Execution Structures for LLM Agents
• 作者：Yuxing Lu、Yicheng Chen、Shanchan Wu、Sercan Ö. Arık
• 机构：Google（一作 Yuxing Lu 同时署名 Georgia Institute of Technology 与 Peking University）
• 链接：https://arxiv.org/abs/2609.09153 （2026 年 9 月 8 日提交，36 页含附录，6 图 11 表）

🎯 问题动机：记忆给了经验，但没给章法

现有给 Agent 注入经验的路线，大致四条，每条都有一个"差一口气"的地方：

作者的观察很直接：Agent 需要的程序性知识应该同时满足四点——足够结构化（避开无效行为）、足够灵活（别锁死推理）、对当前进度有响应、能从经验里自我改进。前面四条路线，每条都只占到其中两三个。

说到这个，知识图谱的思路其实早就摆在那儿了：把事实组织成三元组，随取随用，不用改模型权重。这篇论文做的事情，说到底就是把这个思路从"事实"平移到"流程"——但平移的工程细节，远比这句话听起来讲究。

🧠 方法核心：Procedural Graph 是什么

一句话通俗解释：PG 就是一张带注释的"流程图"，告诉 Agent 每个步骤之后可以接什么、什么条件下该接、要注意什么坑。

形式上，PG 是一个有向带属性图：

• 节点：抽象一个工具函数、一项技能、一次内部推理步骤，或一个任务状态；
• 边：(u, r, v) 三元组，表示"在关系 r 下，v 跟在 u 之后是合理的"。关系词汇表就 4 种：LEADS_TO、TRIGGERS、PROVIDES_INPUT_FOR、CONVERGES_TO——够小，不至于让 LLM 编辑时迷失；
• 属性：每条边挂三个文本字段——condition（什么时候适用）、guidance（怎么做）、pitfalls（避开什么）。

论文里给的一个例子很能说明问题。财务规划场景下，边 (cash_flow_forecast, LEADS_TO, fund_raising_request) 携带的属性是："condition：预计 runway 低于安全垫；guidance：尽早提交融资申请，给资金到账留出延迟；pitfalls：已有一笔申请在处理时不要再叠加第二笔。"

你想想看，这其实就是资深工程师写在 wiki 里的那种"踩坑笔记"，只不过被结构化成了图，能被程序精确检索。

关键设计取舍在于：这套知识完全放在模型权重之外。可检查、可逐步检索、可编辑，全程不需要重训练。

🏗️ 在线引导：定位-取子图-生成

图2：框架全貌。三个角色共用同一个底层 LLM——solver 负责执行，guidance 模型负责"看图说话"生成引导，refiner 负责离线改图。蓝色箭头是"读图引导"，绿色箭头是"记录轨迹"，橙色箭头是"更新图"。

运行时的引导机制叫 Generative PG Guidance，三步：locate、extract、generate。

1. 定位：把最近一个动作（比如一次工具调用）精确匹配到图节点，得到当前位置 \(u_t\)。第一步固定在 Start 节点；
2. 取子图：取 \(u_t\) 的 h-hop 出边邻域作为主图上下文（主实验 h=2）；匹配失败就回退用全图；
3. 生成引导：guidance 模型读子图 + 查询 + 最近 w 步轨迹（w=3），生成一段步级引导 \(g_t\)，追加进 solver 的 prompt。

这里有一个值得展开说的设计判断：为什么不直接检索单条边的属性，非要取连通邻域再过一遍 LLM？

作者给的动机例子很实在：如果只 top-k 检索到"submit"的指南，而漏掉它的前置节点"check_answer"，Agent 就不知道提交前要先验证。程序步骤之间的连接关系本身就是知识的一部分，独立检索会把它切碎。而再过一遍 LLM 而不是直接塞原始属性，是因为静态边属性是写给"一般情况"的，guidance 模型要结合当前轨迹，翻译成"此刻你具体该干嘛"——比如"next: verify result; avoid repeating search"。

另外一个我很欣赏的克制：软注入，不是硬约束。引导只是 prompt 里的一段话，solver 理论上可以不听。这保住了 LLM 的推理灵活性，也让 PG 跟 TOOLDEC 那类硬状态机拉开了身位。

🔧 离线自进化：一个带"拒绝记忆"的爬山循环

这部分是论文标题里 "Self-Evolving" 的落点。整个循环（Algorithm 1）每轮四步，我捋成大白话：

1. 诊断性展开：拿当前图在训练批次上跑，记录每条轨迹的最终得分（0 到 1），refiner 对比高分和低分轨迹；
2. 反馈驱动变异：refiner 从失败轨迹里找"重复错误循环"，从成功轨迹里找"多步推理捷径"，提出结构化编辑——加缺失的验证节点/边、删反复引轨迹入坑的节点/边、改边属性（改属性复用同一接口：删旧边加新边）。编辑后自动做循环修复等结构检查，比如要求每个节点都有通向终端节点的有向路径；
3. 验证门控：候选图在独立验证集上评估，\(S_{val}\) 不降就接受——平局也接受（鼓励探索），否则回滚；
4. 拒绝记忆：被拒的候选连同它的编辑、关联轨迹、验证结果一起记入黑名单，下一轮 refiner 提案时能看到这些负面证据，避免重蹈覆辙。

拆开看，这就是一个以图结构为基因、以验证集为环境的进化搜索，但有两个细节让它比裸爬山靠谱：一是所有编辑是 LLM 在"对比成败轨迹"之后提出的，变异方向有依据；二是拒绝记忆防止同一个坑反复踩——没有它，refiner 很可能下轮又把删掉的坏边加回来。

图的初始化也灵活：可以从专家先验出发，也可以从一个极简骨架（Start、End 加几个核心节点）从零进化。实际用的图都很小——除 BFCL v3 因函数目录庞大达到 131 节点 265 三元组外，其余基准的图只有 7 到 17 个节点、7 到 27 个三元组。小图，大用。

📊 实验：7 个基准 × 4 个 LLM × 7 个 baseline

实验铺得相当开。基准覆盖七种任务类型：HotpotQA（多跳问答）、MultiChallenge（多轮指令保持）、GDPval（开放式专业任务）、ALFWorld（具身家务）、τ-bench（政策合规工具使用）、BFCL v3（多轮函数调用）、EnterpriseArena（长周期金融决策，有延迟反馈和宏观冲击）。模型用 Claude Sonnet 4.6、Gemini 3.1 Pro、Gemini 3.5 Flash、Grok 4.1 Fast 四个，全部 greedy decoding。baseline 七个：Vanilla ReAct、MemoryBank、RAP、ExpeL、AutoGuide、AWM、KnowAgent——都共享同一个 ReAct solver，学习类 baseline 还消费同样的训练轨迹，这个对照做得算干净。

主结果（Table 1）的整体结论：

• PG 在 24 个模型-基准组合中的 21 个排名第一或并列第一；
• 对每个组合里的最强 baseline，战绩是 19 胜 2 平 3 负，单侧符号检验 p = 4.3×10⁻⁴；
• 最大优势出现在 BFCL v3 + Gemini 3.5 Flash：67.00% 对 58.00%，高了 9 个点；GDPval + Gemini 3.1 Pro：78.78 对 71.37，高 7.41；τ-bench + Gemini 3.1 Pro：80.00% 对 73.04%，高 6.96。

挑一块代表性的数据看（Gemini 3.1 Pro 这一列，PG 优势最明显的设置之一）：

GDPval 上 78.78 对最强 baseline 的 71.37，ALFWorld 直接满分 100——这个幅度确实能打。坦率的讲，我第一反应是检查这是不是刷出来的，但七个 baseline 横向铺开后，结论是 PG 赢得相当一致，不是靠挑对手。

不过也有例外，后面批判部分细说。

EnterpriseArena：最能体现 PG 价值的试验场

长周期金融决策这个基准值得单独说。Agent 要扮演 CFO 经营一家公司 120 多个月，期间遭遇三次宏观经济危机，融资申请要 1 到 6 个月后才到账——反馈延迟 + 长horizon + 外部冲击，专治各种"跑着跑着就乱"。

图3：每个子图上半是存活率曲线、下半是现金轨迹。可以看到蓝色（PG）曲线几乎在所有模型上都"压"在红色（baseline）上方：Sonnet 存活率 44% 提到 58%，Gemini 3.1 Pro 从 6% 提到 34%，Grok 从 26% 提到 40%。右下 Grok 的现金轨迹里，PG 曲线在三次危机后都能回血到 3000 万美元量级，而 MemoryBank 跌到 820 万。

结果里最有意思的不是"赢了多少"，而是赢的方式。PG 并没有让 Agent 调更多工具，而是改变了"调什么、什么时候调"：Gemini 3.5 Flash 的 baseline 会神经质地每个月反复查现金和市场（月均 18.94 次工具调用），PG 引导后降到 12.53 次，企业得分反而更高。跨模型唯一与存活一致相关的行为是预期性融资——在危机来之前、账面还健康时就提前申请融资。baseline 的 Flash 平均融资额是 0 美元，PG 引导后是 939 万美元；PG 引导的 Grok 更是融到 3011 万美元。

这个行为模式，恰恰是那张图里 (cash_flow_forecast, LEADS_TO, fund_raising_request) 边上写着的那条 condition："runway 低于安全垫时尽早申请"。知识写在图上，行为长在身上。

🔬 消融：两个让我印象深刻的发现

发现一：人工专家图可能是"有毒"的，进化循环能解毒

构建模式消融（Table 2，HotpotQA 和 MultiChallenge）对比了五种模式：无图、人工专家图、专家图+一次性静态更新、专家图+在线进化、从零静态构建、从零+在线进化。

MultiChallenge 上的数字把我看愣了一下：

手工设计的专家图，居然把成功率从 87.50% 拖到了 58.93%——专家先验是有缺陷的，硬塞给 Agent 还不如不给。更反直觉的是，一次性离线更新不但没修好，反而进一步降到 53.57%。只有完整的迭代进化循环把它拉回到 92.86%，比专家图初始化高了 33.93 个点。而从零骨架进化出来的图（91.07%）已经逼近专家修复版，HotpotQA 上 Mode 5 甚至全场最佳（78.79 F1，比无图 baseline 高 7.58）。

这个发现对工程的冲击挺直接的："先让专家手工画一版流程"这个直觉做法，可能是在埋雷。 与其依赖一个未经检验的先验，不如给一个最小骨架让系统自己长。

发现二：全图硬塞有害，局部化子图才对

图使用方式消融（Table 3，Gemini 3.5 Flash）对比了无图、全图原始注入、全图生成式引导、子图生成式引导四种配置。结果：把整张图塞进 prompt 看似信息最全，实际是把 ALFWorld 成功率从 72.58 干到 70.34；全图再过一遍生成式引导更惨，直接掉到 54.48——信息过载把模型搞懵了。而局部化子图方案在三个基准上全部最高（MultiChallenge 89.31、GDPval 63.99、ALFWorld 81.53），token 消耗还比全图生成式大幅缩减：ALFWorld 降了 70.9%，GDPval 降 18.1%，MultiChallenge 降 14.8%。

h=2 的邻域窗口，够看到"接下来两三步"，又不至于淹没在无关结构里。这个局部性假设，事后看是整套方法能 work 的关键支点之一。

自进化过程长什么样

图4：EnterpriseArena 上十轮进化的轨迹。左图存活月数从 baseline 的 33.3 一路爬到 120 上下；右图融资额从 0 美元起步，第 8 代验证达到 9432 万美元。灰色菱形的缺失（第 3 到 6 代）对应没有提交更新的轮次。

十轮进化的具体路径（EnterpriseArena，每 split 20 个 episode）很有"生物进化"的既视感：

• Round 1 就完成最大单次跃升：发现顺序骨架——融资决策前必须先审计现金、预测 runway——验证存活率从 0% 直接跳到 45%；
• Round 2 加入"复用笔记"节点，存活率冲到 80%，工具调用从月均 17.23 次降到 3.08 次；
• Round 3 到 6 连续四轮没有接受任何更新（其中一轮候选甚至没通过结构验证）——拒绝记忆和验证门控在这段平台期起了作用；
• Round 7 剪掉一个 pass_action 死分支，Round 8 引入一条 administrative bypass，验证存活率推到 90%；
• Round 10 的候选被拒，循环终止。

最终返回的图在测试集上存活率 85%，baseline 是 0%——Fisher 精确检验 p = 2.6×10⁻⁸。值得点赞的是，搜索过程中其实观察到过 95% 的单轮最佳，但作者选择报告最终返回图的测试成绩，而不是在测试集上挑樱桃。这个实验操守，在当下的 Agent 论文里不算多见。

🤔 批判性分析：几个不该被掌声盖过的问题

HotpotQA 上的收益其实很薄。 24 个组合里 PG 输了 3 个，其中两个就在 HotpotQA（Sonnet 设置下 AutoGuide 75.40、ExpeL 75.20 都高于 PG 的 74.50）。对整个基准，PG 相对最强 baseline 的边际在 −0.90 到 +1.30 分之间晃——原因不难想，事实型多跳问答这种"步骤相对直线"的任务，程序结构帮不上太多忙。PG 的主战场是长周期、强顺序依赖、政策合规类任务，论文自己的数据已经说明了边界在哪。

token 开销是真金白银的。 引导让 solver 步数明显下降（GDPval 从 28.20 降到 18.57 步），但总 token 反而涨了 33.4%（GDPval）到 55.4%（ALFWorld）——每步都要跑一遍 guidance 模型，不是免费午餐。作者的消融只跟"全图方案"比省了 token，跟"无图 baseline"比是实打实的成本上升。按 API 计费的话，这笔账得自己算。

自进化的验证样本有点小。 EnterpriseArena 每个 split 只有 20 个 episode，作者自己承认个别 accept/reject 决策取决于一两个 episode 的运气，应读作"搜索轨迹"而非显著性检验。这种规模下，验证门控的噪声有多大、拒绝记忆会不会把运气好的坏编辑锁进黑名单，其实是开放的。

三个角色共用同一个 LLM，自证嫌疑难完全洗清。 solver、guidance、refiner 全是同一个模型、greedy decoding。后果是图的进化方向受限于这个模型自身的失败归因能力——它诊断不出的错误类型，图永远也学不会。换个更强的 refiner 会不会更好？论文没做。这块我自己也还在琢磨，可能我的担心有偏差，但"裁判和运动员同源"总归是个值得追问的设定。

💡 我的判断

这篇论文的定位，我觉得要说得直白一点：它不是推理能力的突破，是 Agent 知识组织方式的一次漂亮整合。把知识图谱的三元组思路平移到程序性知识，这个类比单拎出来不算惊艳；"软注入 + 局部子图 + 验证门控进化"这几个组件，单独看每一个也都能在文献里找到亲戚。

但它把这几件事拼成了一个闭环——图上知识引导执行，执行轨迹反哺图，验证集守住进化方向，拒绝记忆防止打转——并且在 7 个基准、4 个模型上做了少见的大规模验证。完成度本身，就是贡献。

对工程实践的三点启发：

1. 如果你在维护一个经常"跑飞"的长程 Agent，与其继续堆记忆和反思 prompt，不如试试把"该做什么"显式化成一张小图。十几个节点就够，成本远低于想象；
2. 别迷信专家手工流程。Mode 1 那个 58.93% 的教训很值钱——先验要经过执行反馈的检验才算数，最小骨架 + 进化循环可能是更稳的起点；
3. 引导要局部化。全图塞 prompt 是反模式，2-hop 邻域这个默认配置可以直接抄。

还有一个更本质的问题这篇论文没碰：图的跨任务迁移。在 EnterpriseArena 上进化出的融资节奏感，能不能帮到另一个供应链场景？程序性知识的可迁移性，恐怕是下一代工作的真正分水岭。

觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我