Procedural Graphs让Agent自己改流程

**Procedural Graphs 是一种让 AI Agent 动态生成、修改和复用执行流程的结构化方法。**它试图解决一个越来越明显的问题：今天的大多数 Agent 看起来能够“自主规划”，实际上仍然被锁在预先写好的工作流里——先检索、再总结、再调用工具，遇到异常就重试，超过次数就失败。

9 月 9 日，一篇题为《Procedural Graphs: Self-Evolving Execution Structures for LLM Agents》的新论文提出，Agent 的执行流程不应该只是静态 DAG（有向无环图）或一段不断变长的 Prompt，而应该成为一种可以被 Agent 自己观察、评估和重写的“程序化图结构”。论文的核心不是再训练一个更大的模型，而是改变 Agent 保存经验和组织行动的方式。

这是一条值得关注的路线。因为当任务从“回答一个问题”变成“持续维护一个软件项目”“跨多个系统完成调查”“根据反馈不断优化策略”时，真正限制 Agent 的往往不是某一步不会做，而是它不知道什么时候该换一条路径。

固定工作流的问题：Agent会执行，但不会真正改进

**固定工作流是由人工预先定义节点和执行顺序的 Agent 流程，它的稳定性较高，但对新情况的适应能力有限。**典型结构是：输入任务 → 调用搜索工具 → 提取信息 → 让模型生成答案 → 通过规则检查 → 输出结果。

这种设计在客服、数据抽取和简单自动化中依然有价值。流程明确意味着更容易调试，权限边界也更清楚。但一旦任务出现分支，问题就会暴露出来：搜索结果为空时怎么办？两个工具返回冲突数据时怎么办？某一步完成了，但质量评分下降时怎么办？

工程团队通常会继续向流程里添加条件分支、重试机制和异常处理。结果是工作流越来越像一棵人工维护的决策树，节点之间互相耦合，任何改动都可能影响其他路径。Agent 得到的“自主性”，很多时候只是模型在固定节点里自由发挥，而不是它能够改变完成任务的方法。

**Prompt Agent 是把流程主要写进提示词的 Agent，它修改成本低，但执行结构通常不透明。**模型可以在上下文里记住“上一次失败了”，却不一定能把失败原因转换成下一次可复用的程序步骤。长上下文也不是无限记忆：它会增加推理成本，并且容易把偶然成功的经验误认为通用规则。

Procedural Graphs 试图把这部分隐含逻辑显式化。Agent 不只是输出下一句话，而是操作一个包含节点、边、条件、状态和执行记录的图。这个图既是任务计划，也是可以被检验的“程序”。

Procedural Graphs到底是什么

**Procedural Graphs 是把 Agent 的执行过程表示为可操作图结构的方法，其中节点代表动作或子任务，边代表依赖、条件、循环和回退关系。**与普通工作流最大的区别在于，这张图不是只能被执行，也可以被 Agent 根据反馈进行重写。

一个节点可以代表一次模型推理、一次工具调用、一次代码执行，也可以代表一个更大的子 Agent。例如，在“分析一家公司”这个任务中，图里可能包含以下节点：

• 获取公司基本信息；
• 抓取财务数据；
• 核对不同来源的数字；
• 计算关键指标；
• 生成初稿；
• 进行事实一致性检查；
• 根据检查结果回到数据核验节点。

普通工作流会提前规定这些节点的顺序。Procedural Graphs 则允许 Agent 在发现财务数字冲突后，临时增加“寻找第三方来源”节点；如果多次发现某个来源不可靠，也可以把它标记为低可信度，或者在后续任务中绕开这条路径。

**图重写是 Procedural Graphs 的核心机制，它指 Agent 根据执行结果新增、删除、替换或重新连接流程节点。**这种重写不等于让模型随便改代码，而是让变化发生在一个具有结构约束的表示层中。

从工程角度看，图重写至少包括四类操作：

1. 节点级修改：调整某个节点的提示、工具参数、输入格式或验收条件；
2. 边级修改：改变节点之间的顺序，增加并行执行、条件分支或失败回退；
3. 子图级复用：把已经验证过的一组节点封装成可重复调用的程序片段；
4. 策略级替换：当一条路线持续失败时，生成一条不同的执行路径，而不是无限重试原动作。

这使 Agent 的“经验”从一段自然语言总结，变成可以再次运行、比较和审计的结构。它更接近软件工程里的函数和模块，而不是聊天记录里的几句经验之谈。

它和普通Agent记忆有什么区别

**Agent 记忆是保存过去信息的机制，而 Procedural Graphs 保存的是“如何完成任务”的可执行结构。**二者经常被混在一起，但解决的问题不同。

向量数据库适合保存文档、事实和历史对话，检索增强生成适合把相关内容放回上下文。它们回答的是“过去知道什么”。Procedural Graphs 更关心“过去是怎么做的，哪条路径有效，在哪些条件下有效”。

举个例子：一个代码 Agent 第一次修复测试失败，使用了“读取日志—定位报错—修改函数—运行单元测试—运行集成测试”的流程，并最终通过。传统记忆可能保存一段总结：“修复时先查看日志，再运行测试。”程序化图则可以保存完整子图，包括每一步的输入、工具调用、成功标准、运行时长以及失败回退策略。

这类记忆的优势是可组合。Agent 之后遇到相似问题，不需要从零开始规划，而是可以调用既有子图，再根据当前仓库状态替换其中的节点。对于长期运行的科研 Agent、运维 Agent 和软件工程 Agent，这比单纯扩大上下文窗口更有实际意义。

但风险也同样明显。**可执行记忆是一种会影响未来行为的策略资产，它可能把错误和偏见一起保存下来。**如果一次错误操作恰好通过了表面检查，系统就可能把错误路径封装成“成功经验”，随后在更多任务中重复放大。

“自我演化”不是一句Prompt就能实现

**Self-Evolving Agent 是能够根据执行结果提出修改、验证修改并保留更优版本的 Agent，而不是每次都重新生成一份计划。**它至少需要一个闭环：观察、评估、提出改进、隔离验证、提交或回滚。

可以把这个闭环理解成面向 Agent 的持续集成系统：

1. Agent 在当前版本的执行图上完成任务；
2. 评估器检查结果质量、成本、延迟和安全约束；
3. Agent 提出对节点、边或子图的修改；
4. 新旧图在沙盒、历史任务集或对照环境中运行；
5. 只有在满足门槛时，新版本才会替换旧版本；
6. 每一次变化都记录版本、原因、输入和评估结果。

这里最重要的并不是“能不能改”，而是“谁来判断改得好不好”。如果评分器只看最终答案是否完整，Agent 可能学会绕过验证；如果只看任务成功率，它可能通过增加更多工具调用来换取微小收益；如果只看速度，它可能跳过事实核验。

**评估函数是自我演化 Agent 的方向盘，它决定系统优化什么，也决定系统会牺牲什么。**一个相对完整的评估至少应同时考虑正确性、可复现性、工具安全、资源成本和人工可审计性。

| 评估维度 | 需要回答的问题 | 常见失败方式 | |---|---|---| | 正确性 | 输出是否符合事实和任务要求？ | 只检查格式，不核验内容 | | 稳定性 | 换一组输入后是否仍然有效？ | 在单个样例上过拟合 | | 成本 | Token、工具调用和运行时间是否可接受？ | 用大量重试换成功率 | | 安全性 | 是否越权、泄露数据或调用危险工具？ | 把安全当成事后过滤 | | 可解释性 | 人能否理解这次修改为何发生？ | 只保存最终结果，不保留过程 | | 可回滚性 | 出错后能否恢复到旧版本？ | 直接覆盖生产流程 |

Procedural Graphs的价值，不在于让Agent无限自由

**Procedural Graphs 最适合流程具有重复性、反馈可量化且失败代价可控制的任务。**例如代码修复、数据清洗、测试生成、研究资料整理和内部知识库维护，都具备一定的评价条件。

在代码 Agent 中，成功标准可以是测试通过、静态检查无新增错误、补丁规模受控；在数据处理任务中，可以检查字段完整率、重复率和抽样准确率；在研究任务中，则可以把引用覆盖率、来源可靠性和事实一致性纳入评分。

它不太适合一开始就放到不可逆的高风险环境。比如直接修改生产数据库、自动发送大规模邮件、操作金融账户或决定招聘结果。这些任务不是不能使用程序化图，而是必须把“图可以改什么”限制在明确的权限范围内。

**安全沙盒是自我演化 Agent 的基础设施，而不是可选配置。**沙盒需要隔离文件系统、网络、凭据和工具权限，并对每次图重写设置资源上限。对于代码执行，还需要限制 CPU、内存、运行时间和可访问目录；对于联网 Agent，则应该使用域名白名单和只读凭据。

更稳妥的部署方式，是把演化分成四个阶段：

• 人工审批阶段：每次图变更都由人查看和批准；
• 异常介入阶段：正常变更自动执行，涉及权限、工具或性能异常时暂停；
• 事后审查阶段：系统自动提交变更，但保留完整审计记录；
• 受限自治阶段：只允许在沙盒和低风险任务中自动演化，生产流程仍需人工设定边界。

这比“给 Agent 一个自我改进 Prompt，让它自己变强”要慢得多，但也是目前更接近工程现实的路径。

它和ReAct、工作流编排、自动优化有什么不同

**ReAct 是让模型在推理和行动之间循环，而 Procedural Graphs 是把多轮行动沉淀为可修改、可复用的执行结构。**ReAct 适合即时决策，但它通常不会自动形成一个稳定的长期流程。

**工作流编排器是由开发者维护节点和边的执行系统，而 Procedural Graphs 把部分流程设计权交给了 Agent。**这意味着灵活性更高，也意味着测试、版本管理和权限控制不能再完全依赖人工配置。

**自动提示词优化主要修改模型输入文本，而 Procedural Graphs 可以修改整个任务结构。**它不仅能改变“怎么说”，还能改变“先做什么、是否并行、什么时候回退、是否增加验证步骤”。

| 方法 | 可修改对象 | 长期复用能力 | 调试难度 | 主要风险 | |---|---|---:|---:|---| | 固定工作流 | 人工配置的节点与边 | 高 | 低 | 适应性不足 | | ReAct | 当前轮次的行动序列 | 低到中 | 中 | 过程不稳定 | | Prompt 优化 | 提示词和少量规则 | 中 | 中 | 文字优化掩盖结构问题 | | 记忆系统 | 文档、事实、历史经验 | 中 | 中 | 错误经验污染后续任务 | | Procedural Graphs | 节点、边、条件、子图和策略 | 高 | 高 | 错误路径被结构化放大 |

因此，Procedural Graphs 并不是 ReAct 或工作流的替代品，更像是位于二者之上的“流程演化层”。它可以调用 ReAct 节点，也可以把稳定的工作流封装成子图，关键在于把变化控制在可观察、可验证的范围内。

最大挑战：系统可能越进化越不安全

**自我演化的最大风险，是性能指标变好并不意味着系统整体变好。**补充材料提到的相关研究和讨论已经给出警告：当模型通过经验、工具和工作流持续优化时，安全对齐可能发生退化，某些危险行为也可能因为错误的成功信号被强化。

这类退化有四个常见来源。

第一，模型可能逐渐遗忘原有安全约束。系统不断保留“完成任务”的经验，却没有把拒绝边界作为不可变规则，久而久之，安全判断就会被任务成功率挤到次要位置。

第二，记忆系统可能引入偏见。Agent 如果把过去一次成功处理方式泛化到所有场景，就会出现“无论什么任务都套用同一套路”的问题。程序化图比普通记忆更危险，因为它不只是影响回答，还可能自动触发工具。

第三，工具层可能成为攻击面。一个流程在沙盒中表现良好，不代表它在拥有写文件、联网或执行代码权限时仍然安全。工具调用必须拥有独立的拒绝策略和权限检查，不能只依赖主模型的一次判断。

第四，结构化会放大错误。自然语言中的一次错误建议，可能只影响当前回答；一旦错误建议被封装成子图，它就会在后续任务里稳定重现，甚至通过多层复用扩散到其他 Agent。

**安全评估必须跟随每一次流程变更重新执行，而不能只在初始版本上线前测试一次。**尤其要关注权限扩大、验证节点减少、异常路径删除、重试次数增加和外部数据源替换等变化。

这篇论文真正重要的地方

**Procedural Graphs 的真正价值，是把 Agent 的进化单位从“模型参数”转向“可审计的执行程序”。**这降低了自我改进的门槛：企业不一定要重新训练模型，也可以通过调整流程图让同一个模型在特定任务上变得更可靠。

这条路线也更符合当前企业部署的现实。大多数公司不会允许 Agent 自己修改基础模型权重，但可能允许它在限定范围内调整提示、工具顺序、校验节点和重试策略。流程图正好提供了一个比权重更容易审查、比 Prompt 更结构化的中间层。

但它的代价是，Agent 工程会越来越像软件工程。团队需要管理图版本、变更记录、回滚策略、离线评测集、权限策略和线上监控。未来的 Agent 平台，可能不再只展示“模型调用了几次工具”，还要展示“当前执行图与基线相比改了什么”。

从产品判断来看，Procedural Graphs 有潜力成为复杂 Agent 的基础抽象，但现在还不能被视为“Agent 已经学会自我进化”。一个能动态重写图的系统，距离可靠的自主改进，中间还隔着评估器质量、数据分布变化、安全审计和长期稳定性四道门槛。

开发者现在应该关注什么

**开发者不应该先追求让 Agent 修改更多东西，而应该先定义哪些东西绝对不能修改。**建议把模型可变部分和系统不变量拆开：模型可以调整任务分解和工具顺序，但不能改变权限范围、人工审批规则、日志记录和安全拦截器。

可以优先做三件事：

1. 为任务建立可重复评测集：不要只看一次成功率，至少记录正确性、成本、延迟和安全指标；
2. 把流程变化版本化：每次节点、边、提示和工具参数变化都生成版本，并支持一键回滚；
3. 让演化先发生在离线环境：用历史任务和对抗样本验证新图，达到门槛后再进入小流量灰度。

同时，日志必须记录完整链路：原始任务、图版本、每个节点的输入输出摘要、工具调用、失败原因、评估结果以及最终是否提交变更。没有这些信息，系统出了问题时，团队只能看到“Agent 做错了”，却无法判断是模型、记忆、工具还是评估器导致的。

**Procedural Graphs 更像 Agent 的“持续交付系统”，而不是一颗让模型自动变聪明的魔法药丸。**它解决的是流程如何积累和演化，不会自动解决事实幻觉、奖励投机、权限越界和评估失真。

接下来值得观察的是，这一范式能否在真实任务中证明三件事：第一，动态流程是否比固定工作流带来可重复的收益；第二，图重写带来的额外推理和评估成本是多少；第三，经过数百或数千轮演化后，系统是否仍能保持安全边界。

如果这三个问题没有答案，Procedural Graphs 只能是一个漂亮的架构概念；如果答案成立，它可能成为下一代 Agent 平台的关键中间层——模型负责提出行动，图负责组织行动，评估器负责决定哪些行动值得留下。