Procedural Graphs:面向 LLM 智能体的自演化执行结构
大型语言模型正日益被部署为 agent,需在长时程上规划并通过外部工具行动。多数 agent 在累积历史上无约束地生成动作,使「做什么、按何顺序、在何条件下做」的过程性知识 保持隐含;轨迹变长后,agent 易偏离目标、乱序调用工具并重复无效操作。 作者提出 Procedural Graph:如同知识图谱以 (entity, relation, entity) 三元组组织事实知识以回答 what-is 问题,它以 (procedure, relation, procedure) 三元组组织过程知识以回答 what-to-do 问题。每个决策步先定位 激活节点,再由 guidance model 把周边子图转译为步级情境引导,在不强制指定动作的前提下偏置 solver 的选择。 该图可自演化:一个 LLM refiner 对比失败与成功轨迹,编辑图的拓扑与属性,仅提交能保持或提升留出集验证性能的编辑,并保留被拒编辑以抑制重复。从最小骨架出发即可构建出比肩甚至超越人工设计的图,也能修复有缺陷的专家先验。 在多个数据集、任务类型与 LLM 上,它相对基于记忆的基线取得一致增益,自演化进一步免去人工工程并提升性能。
论文精读
TL;DR 用 (procedure, relation, procedure) 三元组构建自演化过程图,在每一步给 LLM agent 局部情境引导,并通过轨迹对比优化图结构,超越人工设计的规划先验。
问题
问题背景
LLM 智能体在长程规划与工具调用中需管理复杂过程性知识,业界关注如何让智能体可靠执行多步任务。
现有方法局限
现有主流范式通过 非约束生成 在累积历史上选择动作,过程性知识完全隐式存储在上下文中。这导致三个具体缺陷:
- 目标漂移:长轨迹中模型易遗忘原始目标,重复无关步骤。
- 顺序错误:缺乏显式拓扑约束,工具调用顺序易乱。
- 不可修正:隐式知识难以针对失败轨迹进行结构化修正。
此外,手工设计的结构化先验(如状态机、流程图)虽可缓解,但依赖专家、缺乏自适应,无法从经验中改进。
为什么这个问题难/重要
技术难点在于:如何在不牺牲 agent 灵活性的前提下,注入 可演化 的结构化过程性知识?既要约束动作选择避免错误,又要保留 LLM 的开放性推理能力;同时自演化机制必须保证修改不会损害已有性能,需要可靠验证与回滚。业界对长程 agent 的可靠性要求极高(如客服自动化、数据流水线),错误累积代价大,因此结构化过程性记忆成为关键研究方向。
行业类比
类似 自动驾驶规划器 使用显式行为树 / 驾驶策略图来保证安全与效率,而非仅依赖端到端模型隐式记忆——过程性图就是智能体的“驾驶策略图”。
核心洞察
- 程序性知识的结构化表示:将 agent 的工具调用与决策流程编码为 `(procedure, relation, procedure)` 三元组,构建可局部定位的过程图。不同于把历史轨迹作为扁平记忆检索,过程图显式分离了做什么、按什么顺序、在什么条件下做,并在每步只输入当前活动节点周围的子图,使引导模型能生成高度相关的步骤级情境指引,避免长程轨迹中目标漂移和动作重复。
- 自进化图编辑机制:通过 LLM refiner 对比失败与成功轨迹,对图拓扑和属性进行增量编辑,并以保留或提升 held-out 验证性能为门控,同时保留被拒绝编辑以防重复探索。相比基于轨迹重放的反思或模仿学习,这种方式把改进固化在可解释、可审计的结构空间中,能修复有缺陷的手工先验,也能从最小骨架自举出优于手工设计的图。
- 软引导而非硬约束:guidance model 在每个决策点偏置 solver 的下一步动作,但不强制指定。与固定工作流或有限状态机相比,这保留了大模型对未知情况的泛化能力;同时与完全自由生成相比,又提供了足够的结构约束,在长程任务中显著降低乱序调用工具和重复无效动作的概率。
方法
输入 包括 agent 的任务目标、与环境交互的历史轨迹、当前环境观察,以及当前状态的 Procedural Graph(初始可为最小骨架或专家先验,节点表示 procedure,边表示 relation)。
关键模块与流程
- 活动节点定位:在每个决策步,框架根据当前状态与历史,定位图中的活动节点
active node,即与当前子任务最相关的 procedure 节点。 - 子图提取与指导生成:提取活动节点周围的局部子图(节点及关系),输入到 guidance model。该模型将结构化子图转换为步骤级情境指导文本,明确下一步可采取的动作、顺序约束和条件分支建议。
- 动作生成与环境交互:solver(负责执行动作的 LLM)融合情境指导、历史上下文和当前观察,生成最终动作并与环境交互,获得新状态和成功/失败反馈。
- 图自进化:收集一批成功与失败轨迹,LLM refiner 对比两者,生成对图拓扑和节点属性的候选编辑(如增删节点、修改边关系、调整节点描述)。每个候选编辑在验证集上评估:若保持或提升性能则接受提交;否则拒绝,但将拒绝的编辑记录在案,防止未来重复尝试。
输出 包括 agent 在任务上的动作序列决策,以及更新后的 Procedural Graph,后者持续编码更有效的程序性知识。
与基于记忆的 baseline 不同,该方法显式建模 (procedure, relation, procedure) 结构化关系,提供可解释、可编辑的执行图,并通过自进化机制自动优化拓扑,而非仅依赖从成功轨迹中检索相似经验。
实验
实验设计
在 BFCL、HotpotQA、MultiChallenge、EnterpriseArena 等多个 benchmark 上评估 Procedural Graph。实验从最小骨架开始,通过自我演化构建图形,对比 memory-based baselines,并验证对手工设计图的匹配/超越能力,以及修复有缺陷的专家先验的能力。
关键发现
- Procedural Graph 在多个数据集、任务类型和 LLM 上提供一致增益。
- 自我演化无需手工工程,能进一步提升性能。
- 长时程决策下,代理更稳定,减少目标丢失、顺序错误和重复动作。
- 可以修复有缺陷的专家先验,即使起点不完美也能逐步修正。
与基线对比解读
与 memory-based baselines 相比,Procedural Graph 将程序知识显式结构化,通过步骤级情境引导而非单纯依赖历史上下文,缓解了轨迹变长带来的遗忘和偏差。尤其在需要多步工具调用的复杂任务中,结构化先验显著提升了动作选择的准确性和鲁棒性。
行业影响
落地场景
Procedural Graph 可作为长程任务型 agent 的执行骨架,适用于多步骤、强依赖的工具调用场景。
- 电商运营自动化:订单处理、库存同步、营销活动执行等流程,图结构约束 agent 按正确顺序调用商品、订单、物流 API,减少漏单或错序。
- 企业级 IT 运维:故障排查、日志分析、工单流转等需要条件分支与重试的流程,情境化指引可避免死循环和无效重复动作。
商业价值
- 降本:减少无效工具调用和重试,直接降低 API 与 token 成本;自演进从失败轨迹中提炼规则,进一步压缩长任务平均步数。
- 增收 / 体验提升:任务成功率提高,用户等待时间缩短,复杂工作流自动化更可靠,支撑更高价值的服务 SLA。
与现有产品 / 工作流接口
- 作为轻量中间件嵌入现有 agent 框架(LangChain、AutoGen、自定义 ReAct 循环),每次决策前将当前激活节点的子图序列化为结构化 prompt 片段注入,不改变底层模型。
- 通过 LLM refiner 对图拓扑进行版本化编辑,类似 feature store 或 workflow engine 的规则管理,可集成到 CI/CD 流程中离线优化后再上线。
局限
- 自进化机制依赖 LLM refiner 进行轨迹对比与拓扑编辑,引入额外推理成本与潜在噪声。若 refiner 判断失误,可能错误修改图结构,导致性能下降。论文虽保留被拒绝编辑以防重复,但未深入讨论 refiner 自身可靠性及在不同 LLM 上的鲁棒性。与无需额外 refiner 的纯提示方法相比,系统复杂度与部署门槛明显提高。
- 程序图的结构约束可能限制智能体在开放域或非结构化任务中的灵活性。图是预定义或从少量轨迹演化而来,难以覆盖所有任务条件。对于需要创造性探索或动态目标变化的任务,固定拓扑可能成为瓶颈。论文实验集中于多步工具使用与长周期决策,未充分评估自由形式对话、多模态或持续变化环境下的适应性。
- 实验基线与数据集覆盖可能不够全面。虽然比较了记忆基线与手工图,但未与最新图增强规划方法如 Graph of Thoughts、Tree of Thoughts 进行详细对比,也未涵盖更广泛的开源 LLM 或超长轨迹场景。自进化的有效性受限于初始骨架质量与任务分布,从零构建可能需要大量迭代,实际成本较高。