Procedural Graphs：让 Agent 的执行结构自演化

典型 ReAct Agent 把用户请求、历史 Thought、Action 和 Observation 顺序追加到上下文，由 LLM 每一步重新推断目标、剩余步骤和动作依赖。轨迹越长，这种“从扁平日志重建过程”的成本越高。

现有方案各自缺了一块

V（节点）可抽象工具函数、技能、内部推理步骤或任务状态；R（关系词表）在实验中包含 LEADS_TO、TRIGGERS、PROVIDES_INPUT_FOR、CONVERGES_TO；Φ（边属性）说明何时转移、怎样执行、要避免什么。

图为什么比规则列表更有信息量

单独检索“提交答案”相关规则，可能遗漏前置的“检查答案”；局部连通子图同时暴露动作、前置条件和后续可能路径。过程知识的最小有用单元因此不是一条孤立规则，而是处于拓扑上下文中的转移。

为什么称为“生成式指导”

图中存的是静态条件与建议，指导模型 Ψ 会根据当前任务和最近失败，将其翻译成当下可执行的提醒，例如“先验证结果，再调用输出工具；不要重复搜索已经确认的实体”。Solver 没有被强制锁死在一条边上，所以 PG 是软控制面，不是硬执行引擎。

在线执行伪代码

active = START
while not done:
    active = exactMatch(lastProcedure, graph.nodes)
    contextGraph = active != null
        ? graph.outgoingNeighborhood(active, hops = 2)
        : graph.fullGraph()

    recent = trajectory.tail(3)
    guidance = guidanceLLM.generate(contextGraph, query, recent)
    action = solver.nextAction(query, trajectory, guidance)
    observation = environment.execute(action)
    trajectory.append(action, observation)

图在单个任务执行期间冻结。每一轮只在批量 Rollout 结束后改图，避免在线执行中的结构漂移。候选图必须先通过结构检查，再通过独立验证集门控。

候选图的结构检查

离线演化伪代码

bestGraph = initialGraph
bestScore = evaluate(bestGraph, validationSet)
rejections = []

for round in 1..K:
    traces = rollout(bestGraph, nextTrainingBatch())
    tailContext = keepLastTokens(concat(traces), L_max)
    delta = refiner.propose(bestGraph, tailContext, rejections)
    candidate, diagnostics = prepareCandidate(bestGraph, delta, cyclePolicy)

    if diagnostics.notEmpty():
        rejections.add(delta, traces, diagnostics)
        continue

    candidateScore = evaluate(candidate, validationSet)
    if candidateScore >= bestScore:
        bestGraph, bestScore = candidate, candidateScore
    else:
        rejections.add(delta, traces, candidateScore)

return bestGraph

实验覆盖七类任务，其中六类进入主结果表，EnterpriseArena 单独用于长周期决策。所有方法共享同一个 ReAct Solver、工具接口和解码设置；学习型基线与 PG 使用相同训练轨迹，主要变量是“过程经验如何保存和在推理时使用”。

主结果

PG 在 GDPval 与 BFCL v3 的四个模型上都超过全部基线，在 MultiChallenge 的四个模型上均为第一或并列第一。HotpotQA 的优势较小：相对最强基线的差值在 -0.90 到 +1.30 个百分点之间，说明结构化过程指导并非对所有任务同等有效。

长周期财务决策：四个模型的基线与 PG

十轮自演化发生了什么

这组实验揭示了 PG 的有效单元：不是把整张图“喂给模型”，而是定位后只暴露局部连通结构，再做情境翻译。完整图生成式指导在 ALFWorld 同时更贵、更差，说明不相关过程会稀释指导质量。

如果要接入现有自研 Java Agent，不需要先改造 Solver。最稳妥的做法是把 PG 作为 Solver 前方的独立“过程指导层”，先实现只读运行，再逐步加入离线演化。

建议的数据契约

{
  "version": "pg-cfo-2026-09-10.3",
  "cyclePolicy": "ALLOW_DECLARED_ONLY",
  "nodes": [
    {"id": "cash_flow_forecast", "type": "ACTION",
     "description": "Forecast cash runway"}
  ],
  "edges": [
    {"source": "cash_flow_forecast", "target": "fund_raising_request",
     "relation": "LEADS_TO",
     "condition": "Projected runway is below the safety buffer",
     "guidance": "Request capital before the expected delivery delay",
     "pitfalls": "Do not submit while another request is pending"}
  ]
}

上面是与论文表示一致的工程化示例。生产环境还应附加租户、工具版本、创建来源、评测摘要与签名字段。

Java 侧的核心接口

interface NodeMatcher {
    MatchResult locate(ToolCall lastCall, ProceduralGraph graph);
}

interface GuidanceGenerator {
    Guidance generate(GraphContext graph,
                      UserQuery query,
                      List<TraceStep> recentSteps);
}

interface GraphValidator {
    ValidationReport validate(GraphDelta delta,
                              ToolCatalog allowlist,
                              CyclePolicy cyclePolicy);
}

interface EvaluationGate {
    GateDecision compare(GraphVersion current,
                         GraphVersion candidate,
                         ValidationSuite suite);
}

请求链路

推荐优先选择的第一个场景

建议阅读顺序

1. 先读第 3.1–3.3 节，掌握图表示、在线指导和离线演化。
2. 再读表 3 的消融实验，理解为什么必须局部化。
3. 读附录 B.5–B.6，查看 Prompt 模板、编辑 JSON 与完整算法。
4. 读附录 E.2–E.3，观察候选回滚和图拓扑如何逐轮变化。
5. 最后读附录 C.3 的同一 Seed 轨迹对比，把指标与具体行为连起来。