AgentFlow: 基于 Agent 依赖图的 Agent 程序静态分析框架

论文概览

Agent 程序（Agent Program）正在成为一种新的软件形态——它们用 Python/TypeScript 编写，通过 LangGraph、OpenAI Agents SDK、CrewAI 等框架定义 Agent 的工具、提示词、记忆和编排逻辑。与传统软件不同，Agent 程序的行为不仅由代码控制流决定，还受到框架语义引入的隐式依赖影响：一个 @function_tool 装饰器声明了能力可用性，一个 handoff() 定义了 Agent 间执行转移，一个共享 session 允许信息跨 Agent 持久化。

这些框架诱导的依赖对 Agent 安全治理至关重要——供应链透明度需要知道 Agent 绑定了哪些组件，污点分析需要追踪 Prompt 如何影响工具调用。但现有静态分析工具要么只做 AST 级解析，要么只针对单一框架，无法系统恢复这些依赖。

来自华中科技大学和麦考瑞大学的研究团队提出了 AgentFlow，第一个面向 Agent 程序的静态分析框架。其核心是 Agent 依赖图（Agent Dependency Graph, ADG）——一种框架无关的图中间表示，将 6 种 Agent 实体建模为类型化节点，通过 3 类边捕获组件结构、控制流和数据流依赖。

核心创新

1. Agent 依赖图 (ADG)：统一中间表示

ADG 的设计目标是抽象掉框架差异，将 LangGraph 的状态图、OpenAI SDK 的 Agent 对象、CrewAI 的 Crew 编排统一为同一套图结构。ADG 包含 6 种类型化节点：

ADG 由三个子图组成：

• ACDG（组件结构图）：无向图，记录 Agent 与其 Prompt/Model/Capability/Memory 的静态绑定关系，以及 Control Policy 的附加关系
• ACFG（控制流图）：有向图，记录 Agent 到 Agent/Tool 的执行转移，含 Guardrail 约束
• ADFG（数据流图）：有向图，记录信息在 Prompt → Agent → Tool → Memory 间的传播路径

2. 多框架事实提取前端

AgentFlow 的前端支持 5 个代表性框架，共建模 143 个框架特定构造：

提取流程为三步：源码解析 → 别名消解 → Agent 事实生成。别名消解是关键步骤——将 ops_agent = Agent(name="OpsAgent", ...) 这样的变量绑定解析为 Agent 实体节点，并提取其关联的 model、prompt、tools 和 handoff 目标。

3. 依赖驱动的分析应用

基于 ADG，AgentFlow 支持两类分析，均表达为图查询：

Agent BOM 生成：查询 ACDG，遍历每个 Agent 的结构可达组件，生成包含绑定关系的物料清单：

Prompt-to-Tool 风险检测：组合 ADFG 和 ACFG，执行污点式分析。三步条件：Prompt 通过数据流影响 Agent（R_pa），Agent 通过控制流可达敏感工具（R_ac），且存在 Agent 到工具的参数传递边（E_arg）：

由于数据流可达性 →data 是传递闭包，该查询天然覆盖多 Agent 迭代传播路径。

方法论

三大分析挑战

论文识别了 Agent 程序静态分析的三个核心挑战：

1. 框架异构性：LangGraph 用状态图节点表示行为，OpenAI SDK 暴露 Agent/Tool/Handoff/Guardrail，CrewAI 组织 Agent/Task/Crew。同一语义概念在不同框架中表达方式完全不同。

2. 隐式依赖：tools=[...] 声明了能力可用性但不会出现在调用图中；handoff(...) 定义了执行转移但路径取决于运行时 LLM 输出；共享 session 允许信息跨 Agent 传播但无显式数据流边。

3. 不确定行为：Agent 程序的执行部分由 LLM 概率输出决定，静态分析无法预测单一确定的调用序列。AgentFlow 的策略是过近似——捕获程序结构允许的所有可能执行路径，而非具体执行。

形式化定义

ADG 的三个子图有严格的形式化定义。以 ACFG 为例，其转移关系 T_acfg ⊆ A × (G ∪ {⊥}) × (A ∪ C) 中，元组 (a, ⊥, t) 表示无约束转移，(a, g, t) 表示受策略 g 约束的转移。边集通过推导规则生成：

ADFG 的边族覆盖 5 类信息传播：I→A（Prompt 影响 Agent）、A→C（参数传递）、C→A（返回值）、A→A（消息/handoff payload）、A↔S（Memory 读写）。

实验结果

论文在 AgentZoo（5,399 个真实 Agent 程序）上评估了 4 个研究问题：

RQ1: ADG 构建效果

在 ADG-Eval（60 个项目）上与 AGENT-WIZ 和 AGENTICRADAR 对比：

AgentFlow 是唯一支持 Memory、Policy 建模和数据流分析的工具。中位每个项目恢复 17 个节点和 28 条边。

RQ2: Agent BOM 生成

在 BOM-Eval（100 个项目）上与三个 BOM 工具对比：

现有 BOM 工具只生成组件清单，不恢复绑定关系。AgentFlow 生成了 Agent-Capability（403）、Agent-Prompt（183）、Agent-Model（254）、Agent-Memory（36）和 Agent-Agent（50）五类绑定关系。

RQ3: Prompt-to-Tool 风险检测

在 5,399 个项目中检测到 238 个 P2T 风险项目（4.4%），共 4,357 条发现：

• 框架分布：LangChain/LangGraph 133 个（最多），OpenAI SDK 63 个，LlamaIndex 27 个
• 副作用类型：External Send 129（邮件/消息外发）、File Access 74、SQL Query 42、CMD/Code Execute 41
• 精确率：73.0%（100 份抽样中 73 份确认存在漏洞）
• 漏报率：~9%（100 个未报告的特权 Agent 中发现 9 个遗漏）

值得注意的是，27 个误报中有 25 个的 ADG 依赖路径本身是正确的——误报源于 Sink 语义不够精确（如只读文件被归类为风险），而非图分析错误。区分 open 的读/写模式可进一步提升精确率。

RQ4: 可扩展性

AgentFlow 成功分析了 5,399 个项目中的绝大多数，端到端分析时间和图规模随项目复杂度合理增长。

启示与思考

Agent 程序作为可分析软件

这篇论文最重要的贡献不是某个具体工具，而是一个认知转变：Agent 程序是可分析的软件制品。传统观点认为 Agent 行为由 LLM 概率输出决定，无法静态分析。AgentFlow 证明了框架语义引入的依赖结构是可恢复的——即使不能预测具体执行路径，也能过近似所有可能路径，为安全治理提供结构化基础。

与 Agent 供应链安全的关联

AgentFlow 的 Agent BOM 生成直接回应了 Agentic AI 攻击防御全景 中提出的供应链透明度需求。论文显示，现有 BOM 工具（DRAKO、TRUSERA、CISCO）虽然能列出组件清单，但不恢复绑定关系——这意味着无法回答"Agent A 是否使用了 MCP 工具 B"这样的基本治理问题。AgentFlow 通过 ACDG 查询填补了这一空白。

与 AARM 框架的互补

从 Agent 安全架构设计角度，AgentFlow 实现的是 AARM 三层架构中的静态契约层——在运行前提取 Agent 程序的结构化依赖。这与 ActPlane 的 OS 级运行时执行形成互补：AgentFlow 在编译时发现潜在风险路径，ActPlane 在运行时拦截实际违规操作。两者结合可以形成"静态发现 → 运行时验证"的闭环。

局限性

论文坦承了几个局限：一是静态过近似引入误报；二是对用户自定义的非框架约定结构效果有限；三是当前仅支持 Python 和 5 个框架；四是框架 API 快速演进需要持续更新语义注册表。此外，ADG 捕获高层框架语义，不替代低层程序依赖分析——工具实现内部的污点传播需要结合指向分析（points-to analysis）进行更细粒度追踪。

73% 的精确率和 9% 的漏报率表明，作为第一个面向 Agent 程序的静态分析框架，AgentFlow 已经提供了实用的安全基线，但 Sink 语义精化和动态验证集成是明确的改进方向。