Agent-BOM：给 LLM Agent 装上"黑匣子"

论文：Towards Security-Auditable LLM Agents: A Unified Graph Representation

一、从一个场景说起

假设你构建了一个 Agent 系统，它能帮用户自动管理文件、发送邮件、查询数据库。某天，用户发现它把一封机密邮件发给了错误的人。

你开始追查：

• 日志里只记录了 “调用 send_email API，参数为 {to: ‘wrong@company.com’, subject: ’…’}”。但为什么发给了这个人？
• 模型配置显示用的是 GPT-4，没有异常。但它的推理过程是什么？
• 记忆模块里存了之前对话的摘要，其中某段可能误导了 Agent。但怎么确认？
• 工具权限配置允许发送邮件。但这次调用是否合理？

你发现——每个组件都有自己的记录方式，但没有一个统一的视角把”它为什么这么做”串起来。

这就是 Agent-BOM 要解决的核心问题。

---

二、为什么 Agent 系统的安全审计这么难？

2.1 传统软件 vs Agent 系统

传统软件是确定性的：输入 → 处理 → 输出。代码路径由条件分支决定，调试器可以逐步追踪。安全审计有成熟的方法：代码审查、SBOM（软件物料清单）、漏洞扫描。

Agent 系统则完全不同。它的核心是一个概率性的语言模型在做决策。同样的输入，两次运行可能走完全不同的路径。审计的难点不是”代码做了什么”，而是”模型为什么决定这么做”。

2.2 四个具体的审计盲区

① 工具调用链的不可追溯性

Agent 可能连续调用多个工具：先搜索文件 → 读取内容 → 调用 API 发送。每一步的日志分散在不同组件中，没有统一的调用链 ID 把它们串联起来。更关键的是，每一步的决策理由（模型的推理过程）往往被丢弃了。

② 权限的隐式传递

Agent A 调用工具 T，工具 T 返回的数据被 Agent B 使用。Agent B 的权限范围和 Agent A 不同，但数据已经在它们之间流动了。这种隐式的权限传递在日志中几乎不可见。

③ 记忆污染的累积效应

Agent 的长期记忆会不断积累。某次对话中的错误信息被写入记忆，后续的决策都可能基于这个错误。这是一个慢性中毒的过程——单次操作看不出问题，但累积起来可能产生严重的安全隐患。

④ 级联风险传播

在多 Agent 协作场景中，Agent A 的错误决策可能通过消息传递影响 Agent B，Agent B 又影响 Agent C。风险像多米诺骨牌一样传播，但传统的审计方式无法追踪这种跨 Agent 的风险链。

2.3 现有方案的不足

方案	能做什么	不能做什么
SBOM（软件物料清单）	列出依赖组件	不知道运行时”认知状态”如何演化
运行时日志	记录 API 调用	碎片化，无法回答”为什么”
模型输出的 chain-of-thought	展示推理过程	与具体工具调用、状态变更脱钩

核心缺失：没有一个统一的表示，能把 Agent 的”能力”（它能做什么）、“行为”（它做了什么）和”意图”（它为什么这么做）放在同一个框架下。

---

三、Agent-BOM 的核心思路：把 Agent 执行变成一张图

3.1 直觉类比：飞机黑匣子

想象一架飞机的黑匣子。它不只记录”引擎转了多少圈”（日志），还记录”飞行员拉了操纵杆 → 飞机俯仰角变化 → 高度下降”的因果关系链。调查事故时，你可以沿着因果链回溯。

Agent-BOM 就是 Agent 系统的”黑匣子”——但不是线性的记录，而是一张图。

为什么是图而不是链？因为 Agent 的执行不是线性的。一个推理步骤可能同时影响多个工具调用，一个记忆变更可能影响后续的所有决策。这些多对多的关系天然适合用图来表达。

3.2 分层图模型

Agent-BOM 把 Agent 系统建模为一个分层的有向属性图。关键在于静态层和动态层的分离：

静态能力层（Capability Base）

这一层描述”Agent 是谁、能做什么”：

• 模型节点：使用哪个 LLM、什么版本、什么配置
• 工具节点：有哪些可用工具、每个工具的权限范围
• 长期记忆节点：持久化存储了什么信息

这些在 Agent 启动前就确定了，类似于飞机的”机型和设备清单”。

动态运行时层（Runtime Semantic State）

这一层描述”Agent 在做什么、为什么这么做”：

• 目标节点：当前要完成的任务
• 推理节点：模型的思考过程（chain-of-thought）
• 动作节点：具体的工具调用和结果

这些是运行时产生的，类似于飞行过程中的”黑匣子数据”。

语义边（Semantic Edges）

两层之间，以及层内节点之间，通过带语义标注的边连接：

• 一个推理节点指向一个动作节点（“因为 X，所以调用工具 Y”）
• 一个记忆节点指向一个推理节点（“基于记忆中的 Z，做出了推理”）
• 一个动作结果反馈回推理节点（“工具返回了 W，继续推理”）

安全属性（Security Attributes）

每个节点和边都可以附加安全标签：权限等级、风险评分、是否涉及敏感数据等。这使得图不仅是描述性的，还可以直接用于安全查询。

3.3 一个具体的例子

用户说：“帮我找到上周关于预算的邮件，总结后发给财务组。”

Agent-BOM 图中会产生这样的路径：

[目标: 发送预算总结邮件]
  → [推理: 需要先搜索邮件] → [动作: search_emails("预算", last_week)]
  → [推理: 找到3封，需要总结] → [动作: summarize(emails)]
  → [推理: 总结完成，发给财务组] → [动作: send_email("finance@...", summary)]

但图不止这条主线。它还会记录：

• 记忆依赖：搜索关键词 “预算” 是否来自长期记忆中的用户偏好？
• 权限路径：send_email 工具的权限允许发给这个地址吗？
• 风险传播：总结中是否包含了原始邮件里的敏感信息？

如果事后发现邮件发错了人，你可以沿着图回溯：是推理环节判断错误？是记忆中有错误信息？还是工具权限配置过宽？每个”为什么”都有迹可循。

---

四、图查询：从”事后追查”到”路径级风险评估”

4.1 不只是记录，还能提问

Agent-BOM 的另一个关键贡献是：它不只生成图，还支持基于图查询的风险评估。

论文基于 OWASP Agentic Top 10（Agent 系统的十大安全风险），实例化了一套图查询范式。这意味着安全团队可以用结构化的查询来检查特定的风险模式。

4.2 几个查询示例

权限越界检测： 查询是否存在一条路径，使得 Agent A 的数据通过工具 T 流向了 Agent A 权限范围之外的 Agent B。

记忆污染追踪： 查询长期记忆中哪些条目是通过不可信来源写入的，以及这些条目影响了多少后续决策。

级联风险分析： 给定一个已知的风险节点，查询所有受影响的下游路径，评估风险的传播范围。

4.3 类比：从日志到数据库的飞跃

传统日志审计就像在一堆文本文件里 grep——你知道关键词就能找到，不知道就找不到。

Agent-BOM 的图查询就像有了一个结构化数据库——你可以问”哪些路径同时满足条件 A 和条件 B”，即使你事先不知道具体的模式。

这是从”被动记录”到”主动审计”的本质飞跃。

---

五、实际意义：对构建 Agent 系统的启示

5.1 可观测性（Observability）应该是设计时的考量

很多 Agent 系统把可观测性当作”事后补丁”——先让系统跑起来，再加日志。Agent-BOM 告诉我们，可观测性应该融入架构设计。如果你在设计 Agent 系统时就考虑好”审计需要什么信息”，那么运行时就能自然地收集这些信息，而不是事后补救。

实践建议： 在 Agent 框架中内置执行图的构建。每个推理步骤、工具调用、记忆读写都应该生成对应的图节点和边。这不只是日志，而是结构化的因果关系。

5.2 权限设计需要考虑”传递路径”

传统的权限模型是”谁能做什么”——Agent 有没有权限调用某个工具。但在 Agent 系统中，权限问题更复杂：数据从一个工具流出，经过模型推理，流入另一个工具。权限的边界不应该只看”能不能调用”，还要看”数据流向是否合理”。

实践建议： 权限模型需要从”调用级”升级到”路径级”。不仅要检查单个工具调用的权限，还要追踪数据在工具之间的流动路径，确保不会通过间接方式绕过权限边界。

5.3 记忆系统需要”来源追踪”

Agent 的长期记忆是一个容易被忽视的安全盲区。随着记忆不断积累，很难追溯某条记忆的来源——是用户明确告知的？还是从不可信的工具返回值中提取的？

实践建议： 记忆系统应该为每条记忆附加”来源标签”（provenance），记录这条信息是从哪个渠道、经过什么推理写入的。这样在审计时可以快速定位不可靠的记忆条目。

5.4 多 Agent 系统需要跨 Agent 的审计视角

当多个 Agent 协作时，安全问题可能在 Agent 之间的消息传递中产生。如果每个 Agent 只有自己的日志，就很难看到全局。

实践建议： 多 Agent 系统需要一个中心化的审计图，把所有 Agent 的执行路径合并到一个统一的图中。Agent-BOM 的分层图模型天然支持这种合并。

---

六、局限性与开放问题

Agent-BOM 是一个框架性的工作，实际部署还面临几个挑战：

性能开销。 维护一个细粒度的语义图需要额外的存储和计算。对于高频调用的 Agent 系统，这个开销是否可接受？论文没有给出详细的性能评估。

图的规模。 对于长时间运行、大量工具调用的 Agent 系统，执行图可能变得非常庞大。如何高效地存储和查询大规模图？是否需要图压缩或摘要机制？

安全规则的演化。 OWASP Agentic Top 10 是当前的威胁模型，随着 Agent 系统的发展，新的攻击模式会不断出现。图查询范式如何跟上威胁的演化？

标准化。 Agent-BOM 目前是一个研究原型。要真正成为行业标准，需要 Agent 框架（LangChain、CrewAI、AutoGen 等）的配合，统一执行图的格式和接口。

---

七、总结

Agent-BOM 的核心贡献可以用一句话概括：把 Agent 系统的执行从”一堆碎片化的日志”变成”一张可查询的因果关系图”。

这对 Agent 安全的意义是深远的。传统软件安全经过了数十年的发展，形成了成熟的审计框架（SBOM、代码审查、漏洞数据库）。Agent 安全还处于起步阶段，Agent-BOM 提供了一个重要的起点——一个统一的、结构化的、可查询的审计表示。

对于正在构建 Agent 系统的开发者，这篇论文的启示是：不要只关注 Agent 能做什么，还要关注”出了问题怎么追查”。 可观测性不是可选项，而是安全 Agent 系统的基础设施。

---

by 金豆 🐱 · 2026-05-12