Procedural Graphs：让 LLM Agent 自进化执行结构 · 干货攻略

  • 链接:https://x.com/omarsar0/status/2097755424007373270
  • 分类:x-tips
  • 来源:X @omarsar0
  • 作者:Jay
  • 更新:2026-09-21
  • 仓库:无（论文 arXiv:2609.09153，Google 团队，未见公开代码仓库）

这是什么

Procedural Graphs（过程图）是 Google 团队（Yuxing Lu、Yicheng Chen、Shanchan Wu、Sercan Ö. Arık）2026 年 9 月 8 日发表在 arXiv（2609.09153）的论文提出的 LLM Agent 执行结构框架。

其核心思想类比清晰：

  • 知识图谱（Knowledge Graph）→ 用（实体, 关系, 实体）三元组回答"是什么"的问题
  • 过程图（Procedural Graph）→ 用（procedure, relation, procedure）三元组回答"下一步做什么"的问题

换句话说，PG 把 Agent 的"程序性知识"——做什么、按什么顺序、在什么条件下做——从隐性的自由生成中抽离出来，变成一个显式、可查询、可编辑的有向图结构。

为什么值得关注

解决的核心痛点

LLM Agent 在长周期任务中面临三个典型退化问题（论文 Abstract 原话）：

  1. 失去目标追踪（lose track of their objectives）
  2. 工具调用乱序（invoke tools out of order）
  3. 重复无效操作（repeat unproductive actions）

这些问题在 Agent 轨迹变长时愈发严重。现有方案各有缺陷：

方案 局限
记忆/自我反思方法 以自由文本保存经验，Agent 仍需自行推理如何应用到当前步骤
状态条件规则（guidelines） 检索到的规则之间没有显式连接，无法追踪步骤间的依赖关系
工作流/状态机 需要人工设计，灵活性差

PG 提出的解法是：把程序性知识外部化到一个可编辑的图结构中，既提供足够的结构化引导，又保留推理自由度。

谁值得研究

  • LLM Agent 开发工程师：想改善 Agent 的长程规划与工具调用可靠性
  • AI 研究者：关注 Agent 记忆/规划结构的最新进展
  • Agent 框架设计者：正在设计记忆系统或工作流引擎的团队

核验过程

官方来源

来源 读取内容 关键确认
arXiv Abstract 论文标题、作者、摘要、subjects 确认作者为 Google 团队，提交于 2026-09-08，36 页
arXiv HTML 全文 Introduction、Algorithm 1、Table 1 描述、Figure 3 说明 确认（procedure, relation, procedure）结构定义；确认 self-evolution 四步循环；确认 24 组实验覆盖 7 个 benchmark
HuggingFace Papers 摘要摘要 确认摘要内容与 arXiv 一致

交叉验证结论

通过 Tavily 搜索检索到 5 篇覆盖该论文的二次解读（AI Weekly、DEV Community、YouTube 视频等），关键数据点与论文摘要高度一致：

  • 24 组实验、21 组最高分：在 AlphaXiv 摘要片段与 YouTube 视频字幕中得到交叉确认
  • ALFWorld 100% / Towbench 80%（Gemini 3.1 Pro 下）：来自 YouTube 视频描述文本，与 AlphaXiv 摘要表格描述吻合
  • rejection memory 机制：DEV Community 文章与 arXiv HTML 原文一致
  • trade-off（token 开销增加）：AI Paper Slop YouTube 视频与论文 Abstract 均提及

⚠️ 一处需标注：DEV Community 文章引用了错误的 arXiv ID（2609.08593 vs. 正确的 2609.09153），二次解读时须核对原始论文。此处攻略以 arXiv 官方 ID 为准。

核心机制解析

在线推理阶段（Online Inference）

每次决策时，框架做两件事：

  1. 节点定位（Node Localization）：根据 Agent 当前轨迹，在图中找到对应的活跃节点
  2. 生成式引导（Generative PG Guidance）：一个独立于 Solver 的 Guidance Model读取周围子图，将其转化为步级情境提示（step-level situational guidance），引导但不强制 Solver 的下一步行动

关键设计：Guidance Model ≠ Solver Model。这是两个独立模型，Guidance 负责"应该考虑哪些步骤/条件"，Solver 负责具体行动决策。

离线自进化阶段（Self-Evolution Loop）

每批任务执行完后，一个 LLM Refiner 进行四步循环（Algorithm 1）：

  1. 对比失败轨迹 vs. 成功轨迹
  2. 提出对图拓扑（节点、边）和属性（边注释）的修改建议
  3. Validation Gating：修改必须在 held-out 验证集上性能持平或提升，才会被采纳
  4. Rejection Memory：被拒绝的修改不会被丢弃，而是记录到 H_rejected，供后续轮次避免重复犯错

💡 关键直觉：rejected 的编辑不是删除，而是"留档防重复犯错"——正是原帖 @omarsar0 强调的核心亮点。

图的起点与进化能力

  • 从最小骨架（minimal skeleton）出发，self-evolution 循环可以构建出与人工设计图相当甚至更好的结构
  • 还可以修复有缺陷的专家先验（repair a flawed expert prior）：即使初始图有问题，self-evolution 也能逐步修正

上手指南（概念层面）

⚠️ 注意：本文写作时（2026-09-21），论文未见公开代码仓库。以下为根据论文机制描述的概念性实现指南。

1. 图的基本结构

# 节点：抽象工具动作、推理步骤、状态
Node = {
    "id": str,
    "type": "action" | "reasoning" | "state",
    "description": str
}

# 边：标注转换条件与时机
Edge = {
    "from": str,  # source node id
    "to": str,    # target node id
    "relation": str,  # e.g., "requires", "then", "if_success", "if_failed"
    "attribute": str  # 文本：描述何时、如何进行此转换
}

# 过程图
ProceduralGraph = {
    "nodes": list[Node],
    "edges": list[Edge],
    "rejected_history": list[EdgeModification]  # rejection memory
}

2. 在线推理循环（伪代码）

def pg_step(graph, solver_model, guidance_model, trajectory):
    # Step 1: 节点定位
    active_node = localize_node(graph, trajectory)

    # Step 2: 提取局部子图（active node 的邻居）
    subgraph = get_subgraph(graph, active_node, depth=2)

    # Step 3: 生成情境引导（Guidance Model 独立调用）
    guidance_prompt = build_guidance_prompt(subgraph, trajectory)
    guidance = guidance_model.generate(guidance_prompt)  # 步级提示词

    # Step 4: Solver 在 guidance 条件下做决策
    solver_prompt = build_solver_prompt(trajectory, guidance)
    action = solver_model.generate(solver_prompt)

    trajectory.append(action)
    return action

3. Self-Evolution 循环（伪代码）

def self_evolution_round(graph, batch_trajectories, refiner_model, val_set):
    # 分离成功和失败轨迹
    successful = [t for t in batch_trajectories if t.success]
    failed = [t for t in batch_trajectories if not t.success]

    # Refiner 分析对比，提出修改建议
    edit_proposal = refiner_model.generate(
        f"对比成功轨迹 {successful} 和失败轨迹 {failed}，"
        f"提出对图的拓扑和属性的修改建议。"
        f"参考 rejection memory: {graph.rejected_history}"
    )

    # Validation gating：验证修改是否有效
    candidate_graph = apply_edit(graph, edit_proposal)
    if evaluate(val_set, candidate_graph) >= evaluate(val_set, graph):
        graph = candidate_graph  # 接受修改
    else:
        # Rejection memory：记录被拒绝的修改
        graph.rejected_history.append(edit_proposal)

    return graph

4. Benchmark 覆盖（论文评估）

Benchmark 类型 规模 说明
HotpotQA 多跳问答 — 跨文档推理
τ-bench (TAU-bench) 工具使用 — 真实工具调用场景
BFCL v3 函数调用 100 任务 多轮 function calling
ALFWorld 交互式决策 — 长程规划环境
Towbench 工具编排 — 工具使用效率
EnterpriseArena 金融模拟 132 个月/episode 长期决策韧性，含危机事件
另有 3 个未完整列举 — — 覆盖多种任务类型

坑与适用边界

✅ 适用场景

  • 长周期 Agent 任务：轨迹长、步骤多、工具调用复杂
  • 需要自进化能力：不希望每次都人工维护工作流，希望 Agent 从经验中学习
  • 已有一定基础设施：能实现 Guidance Model + Solver Model 的分离调用

⚠️ 局限与挑战

  1. Token 开销增加：每步多了 Guidance 调用，推理成本上升（论文明确提及此 trade-off）
  2. 无公开代码：目前只有论文，实现需自行参照 Algorithm 1；框架设计细节可能需要读 36 页全文
  3. Validation gating 的计算成本：每轮 self-evolution 需要在验证集上跑评估
  4. Guidance Model 的质量依赖：生成的情境提示质量直接影响 Solver 决策，Guidance Model 选型很关键
  5. 不适用的场景：短任务（Few-shot steps）、单步推理、实时性要求极高（Token 开销不可接受）

一句话结论

Procedural Graphs 通过把 LLM Agent 的程序性知识外部化为（procedure, relation, procedure）有向图，并用独立 Guidance Model 提供步级情境引导 + Self-Evolution 循环不断进化图结构，让 Agent 在长程任务中不再迷失目标、不再乱序调用、不再重复犯错——代价是每步推理多了额外的 Token 开销。

📄 论文：https://arxiv.org/abs/2609.09153 · Google · 2026-09-08 ⚠️ 代码未公开，实现需自行参照 Algorithm 1 与全文