从独立组件到程序关系：什么是程序图
程序图（Procedural Graphs，简称 PG）是一种把 AI Agent 的工具调用、技能步骤、内部推理和任务状态组织成有条件连接的结构。它不是把工具、记忆、技能简单地堆在一起，而是显式描述这些组件之间在什么条件下使用、怎样衔接、什么情况下需要避免。
一张程序图的节点可以是某项技能、一个工具函数、一次内部推理，或者一个任务状态。节点之间的有向边描述从当前步骤到后续步骤的关系，并附带三个字段：适用条件、执行建议、需要避免的问题。
以预测现金流连接到申请融资为例，这条边的适用条件是预计现金支撑时间低于安全缓冲；执行建议是提前申请，为资金到账留出时间；需要避免的问题则是已有申请尚未完成时重复发起。同一个工具动作因此获得了更完整的使用上下文：为什么现在调用、调用前需要满足什么条件、什么情况下应当等待。
它和知识图谱的差别在于：知识图谱通常用实体—关系—实体的方式组织事实，侧重回答是什么、在哪里这类问题；程序图关注的是另一类知识——做什么、按什么顺序做，以及在什么条件下做。
程序图到底解决了什么
要让 Agent 真正可用，能力组件之间的衔接关系往往比单个能力本身更关键。能查付票价，不代表知道查询后该停下来；能保存笔记，也不意味着会在下一次决策前主动读回。Agent 真正要处理的，是操作之间的顺序、条件和衔接。
程序图把这种衔接显式写出来。在论文附录中的财务 Agent 样例里，演化出的图会先连接现金检查、现金流预测、保存笔记和市场数据检查；之后又把回读笔记接到每月开始的位置，让上个月保存的关键信息能在新一轮决策前被取回。工具负责查询与计算，笔记保存跨月信息，程序图则描述何时写入、何时读取，以及读写操作怎样接上后续决策。
一个具体对比是机票查询场景。用户只想了解经济舱票价，无图基线查到了 220 美元的报价，却继续认证身份、操作银行卡并尝试订票；失败后还修改预算限制，再次完成预订。同样的执行框架和基础模型在程序图指导下，报出价格后就结束当前回合，等待用户的新指令。这种差异并非来自性能提升，而是程序知识帮助 Agent 判断已有操作是否已经满足当前请求。
适用场景与实测表现
程序图适合任务中存在多步骤、条件分支明显、不同动作之间存在时间或因果关系、需要长期记忆读写，以及对何时停止、何时等待有要求等特征。
在多轮指令遵循的 MultiChallenge 测试中，无图基线成功率为 87.50%，加入手工专家图后反而降到 58.93%，让模型静态更新一次也只有 53.57%；经过离线迭代演化后达到 92.86%，比手工专家图提高 33.93 个百分点，也超过了无图基线。这说明程序关系的修改需要经过任务检验，手工编写的流程并不天然比无图更好。
在 BFCL v3 工具调用基准上，使用同一款基础模型，加入程序图指导后的准确率为 67.00%，该组最强基线为 58.00%。
在长期任务评估中，程序图的价值更加明显。EnterpriseArena 让 Agent 管理一家模拟企业，连续作出最多 132 个月的财务决策，需要应对现金流变化、资金到账延迟与经济冲击。融资申请发出后资金需要一至六个月才能到账，如果等现金即将耗尽才申请，企业可能无法度过等待期。每种配置进行 50 次测试模拟，与无图基线相比，Gemini 3.1 Pro 完成整个周期的存活率从 6.0% 提高到 34.0%；Claude Sonnet 4.6 从 44.0% 提高到 58.0%。
在 HotpotQA 多跳问答上，程序图相对各模型最强基线的差距介于下降 0.90 与提高 1.30 个百分点之间，提升幅度小于上面几项任务，说明收益与任务类型相关。
成本、代价与收益差异
程序图并不是免费的午餐。在 ALFWorld 固定测试子集上，基于整张图生成指导时成功率为 54.48%；改为读取两跳以内的局部子图后，成功率达到 81.53%。与此同时，每个样本的平均 Token 消耗从 96,360 降至 28,064，比全图生成式指导减少约 70.9%。这支持了按执行位置读取相关程序关系的设计。
不过局部子图指导仍有额外开销：同一实验的无图基线平均使用 18,055 个 Token，仍低于局部子图指导。离线演化阶段还需要额外计算资源用于候选图的运行和验证。
另一个容易忽视的代价是手工专家图可能比无图表现更差。前文提到的 MultiChallenge 实验中，加入手工图后成功率从 87.50% 降到 58.93%。这意味着程序图的初始化方式需要谨慎选择，先用最小结构再由系统演化，是研究中给出的一种思路。在 HotpotQA 构建实验中，从最小图演化得到的程序图达到 78.79 的答案 F1，高于无图基线的 71.21。
此外，程序关系的修改只发生在离线批次之间。执行中的 Agent 读取的是当前版本的程序知识，新经验经过独立验证集的分数检验（不低于当前版本才会被采纳，包括分数持平）后才会进入后续版本。被拒绝的方案会留下记录，供后续修订参考。
如何用起来：落地建议与选型标准
程序图目前是一种面向 Agent 执行支持系统（Agent harness）的架构思路，论文已公开发布，团队可以将其作为设计 Agent 框架时的参考，而不是直接调用的云端服务。
如果要落地实现，关键模块包括节点与边的结构定义、边的三字段（条件、建议、注意事项）填充规范、在线阶段的局部子图检索与提示词组装、离线阶段的轨迹分析与候选图修订，以及独立的验证集和版本采纳规则。在线指导通常组织为三步：定位当前执行节点、提取两跳以内的局部子图、结合用户任务和近期记录生成下一步建议；离线阶段则在训练任务上运行当前保留的图，对照高分与低分轨迹提出修改，候选图先通过结构检查，再在独立验证集上验证分数不下降才被采用。
选型时建议按以下标准判断：任务是否涉及多步骤条件分支，单一工具调用无法覆盖；动作之间是否存在时间延迟或因果链，例如融资申请需要数月才能到账；是否有可用的验证集用于检验候选图，避免手工图引入退化；任务是否需要跨会话或跨时间的记忆读写，并能用节点—边结构表达。
不建议直接照抄手工流程图，因为手工图的初始化表现可能低于无图基线。更合适的方式是从最小结构或经过验证的专家图出发，再让系统在执行反馈中逐步演化。修订时既可以增加缺失的节点与连接，也可以删除容易引起失败的路径，或者重写边上的条件、建议和注意事项。
收益并不均匀。在跨模型、跨工具接口复用时，程序图能保留多少效果仍需进一步研究。对简单问答这类不涉及复杂顺序和条件判断的任务，引入程序图的边际收益可能有限，应优先评估是否真的需要这套结构，以及本地子图读取和离线验证带来的算力开销是否在可接受范围内。