论文链接：https://arxiv.org/abs/2405.20455

文章主要讲的是利用Agent制作一个自动的依赖管理系统，涉及依赖的KG的建立、漏洞检测、RAG。

1、什么是Retrieval-Augmented Generation (RAG)——知识增强检索

LLM 本身有两个局限：知识时效性限制：只能回答训练时已见过的知识，无法访问外部数据库或新信息。缺乏验证机制：不能检查自己答案的正确性。

RAG 的解决思路：通过“检索 + 生成”结合来弥补这些问题。

流程如下：

          （1）LLM 接收到用户问题 Q。

1. （2）从知识库或数据库中检索出最相关的 k 条信息 D = {d_1, d_2, …, d_k}。

2. （3）将这些信息连同原始问题重新组合成新的提示（prompt）：

3. “Given the following data [d₁, d₂, …, dₖ], provide an answer to this question Q, based ONLY on these data, and indicate which data support your answer.”

4. LLM 在生成答案时只能依据检索到的这些数据，并给出引用来源。

简单理解：RAG 就是让大模型“先查资料、再作答、还能标注来源”

这样可以增强：时效性（能回答训练后产生的新知识）；可验证性（能指出依据来源）；准确性（减少幻觉）

第三章  Motivating Example and Challenges

作者用一个典型的软件依赖分析任务作为例子：

对于软件包 X（版本 Y，生态系统 Z），X中哪些包被最多其他包依赖？若这些关键包存在漏洞，其风险有多大？

文章指出构建一个能处理这类任务的 AI 智能助手非常困难，主要有以下六点挑战：

        复杂的层级依赖结构：软件依赖是多层次的（直接 / 间接），使得传统 RAG 方法难以直接应用。

        LLM 的脆弱性： 模型可能出现指令偏离、幻觉、不准确输出。

        任务分解困难：必须把复杂问题拆解为多个可执行子任务，从依赖图中提取信息并评估风险。

        数据聚合复杂：需要从多个来源（依赖图、漏洞库、Web）整合信息，形成完整答案。

        多智能体的路由与调度：如何在不同 Agent 之间分配任务、传递信息，同时避免死循环或阻塞。

        结果验证与精度提升：需要一个 Critic 机制来检查 LLM 输出并不断修正，以确保最终答案可靠。

针对上述问题，作者将复杂任务拆解为三个子任务（Sub-Tasks），由不同 （4个）Agent 负责完成：

子任务	主要目标	执行 Agent / 工具
Sub-Task 1	构建依赖图（Dependency Graph）	由 DependencyGraphAgent 调用 ConstructKGTool
Sub-Task 2	找出依赖图中入度最高的节点（即被最多依赖的包）	同样由 DependencyGraphAgent 执行，通过 GraphSchemaTool 与 CypherQueryTool 生成查询语句
Sub-Task 3	对关键包逐一查询漏洞数据库，生成结构化风险报告	由 SearchAgent 使用 VulnerabilityTool 查询漏洞信息

        AssistantAgent 充当“调度员”，负责：拆分任务；指定目标 Agent；汇总各子任务结果；将最终结果交由 CriticAgent 审查。CriticAgent 负责反馈与修正：对结果的逻辑性、准确性进行评价；若有问题，要求重新生成；直到 Critic 批准为止（Agent–Critic 循环）。

第四章 DEPSRAG: Multi-Agent System for Dependency Management

核心机制：

（1）Agent-Critic 框架

整体结构参考了强化学习（Reinforcement Learning）中的 Actor-Critic 模型。

• Agent 是主要执行者，负责处理输入、调用工具、生成结果。

• Critic 是评审者，检查 Agent 的推理与输出是否符合任务要求，并提供改进反馈。

• 这种循环让模型能在多轮迭代中自我纠错与优化，直到 Critic 认可结果。

（2）Agent 的职责

Agent 是任务执行的核心，它：负责理解任务目标并规划执行步骤；通过调用外部工具（API、数据库、Web 检索等）来完成任务；

• 在输出中要包含：生成的答案；推理过程说明；引用的依据。

Critic 随后根据这些内容给出评价与修改建议。

LLM Minimization Principle（LLM 最小化原则）

        DEPSRAG 并不是所有任务都交给 LLM 完成。对于可以通过确定逻辑实现的任务（如查询语句生成、图结构访问等），直接用程序完成，而不是让 LLM 生成。

        这样能：减少幻觉；提高可靠性；节省计算开销和延迟。

第五章 DEPSRAG Proof-of-Concept（实验章节）

1、总体框架        

        DEPSRAG 的实现是基于 Python + Langroid 框架 完成的。Langroid 是一个用于构建多智能体（Multi-Agent）LLM 应用的框架，支持多个 Agent 之间的交互与任务编排。它能无缝集成不同的大语言模型（如 GPT-4、Llama-3），并且内置了许多 RAG 相关功能（如，Web 检索、访问图数据库（Neo4j）、管理多轮对话和反馈循环等）。​​​​​​DEPSRAG 利用了 Langroid 的这些特性，并自定义开发了新的路由工具。

2、主要组件与工具设计

（1）QuestionTool

• 这是作者自己实现的一个路由工具；

• 功能是：把 AssistantAgent 分解出来的子问题传递给正确的目标 Agent；

• 通过 JSON 消息中的 "target_agent" 字段来指明任务目标（如图 1 的步骤 2 和 3）。

（2）ForwardTool

• 这是 Langroid 框架自带的工具；

• 用于在不同 Agent 之间路由消息；

• DEPSRAG 在此基础上进行了扩展。

3、知识图谱结构（KG Schema）

        用户输入：包名（package name）、版本（version）、生态系统（ecosystem）。系统根据这些信息生成依赖关系图（KG）：

• 节点（Node）：实体：Package，属性：version、name

• 关系（Edge）：只有一种类型——depends_on。

即，一个包依赖于另一个包，用箭头表示依赖关系。

4、依赖数据来源     

        DEPSRAG 使用 Google 的 Deps.dev API 来获取依赖信息：Deps.dev 会自动从多个源（如 GitHub、PyPI）抓取最新依赖数据；提供每个包的直接依赖和传递依赖；返回的结果是一个 JSON 文件，其中列出该包的完整依赖列表；DEPSRAG 的 ConstructKGTool 会解析这个 JSON 并据此构建知识图谱（KG）。

这一机制保证：数据持续更新；可支持多生态系统（如 PyPI、npm）；图结构可用于后续的 Cypher 查询与风险分析。

5、RQ1:Accuracy of Cypher Query Generation（查询语句生成的准确性）

验证 DEPSRAG 的 DependencyGraphAgent 是否能：将自然语言问题准确地转换为 Cypher 查询语句；并在 Neo4j 的依赖知识图谱（KG）中正确检索出结果。

测试了两个大语言模型：GPT-4-Turbo、Llama-3 (70B-Instruct)

任务：基于包 Chainlit v1.1.200 的依赖图回答以下三个问题：图的深度是多少？图中是否存在循环？图中有多少条依赖路径？

不启用 Critic-Agent（因为 Critic 只在最终回答阶段介入）。

分析

• 两个模型都能生成 Cypher 语句，但 Llama-3 不稳定：

  容易生成语法正确但逻辑错误的查询。

• GPT-4-Turbo 的查询在第一次就能正确返回结果。

• 作者为此增加了“schema 检索 + 错误重试机制”：

  先让模型读取数据库结构（schema），如出错则自动重试。

• Llama-3 的错误原因：查询太笼统，没有指定起点节点（root node），

  导致返回了整个图的路径总数而非以 Chainlit 为根的结果。

结论：GPT-4-Turbo 在 Cypher 查询生成任务中更可靠、语义更精确，而 Llama-3 尽管开源，但在结构化查询翻译上仍存在稳定性问题。

6、RQ2:Efficiency of the Critic-Agent interaction（Critic-Agent机制可否提高准确率）

验证在 DEPSRAG 中引入 Critic-Agent 循环后，是否能显著提高系统回答的正确率。

实验设计

• 使用模型：GPT-4-Turbo；

• 设计三个多步推理任务（T1, T2, T3）；

• 

• 对比两种设置：无 Critic-Agent；有 Critic-Agent；

• Critic 仅对最终答案进行反馈（不参与子任务）；

• 每个任务重复 10 次，人工验证正确率；

• 为避免死循环，Critic-Agent 最多交互 10 次后自动终止。

结果

Fig3：无 Critic（平均正确率-13.3%）；有 Critic（平均正确率-40.0%）

Figure 4 – 交互频率统计：

        图中显示了Critic-Agent 交互次数；任务终止次数；AssistantAgent 提问次数。

• T2（漏洞查询任务）的问题数量最多，因为需要对每个包单独查询漏洞数据库。

• 说明 Critic-Agent 循环确实带来更多交互开销，但整体提升了输出质量。

分析

• Critic-Agent 机制能显著改善回答的正确性与逻辑一致性；

• 但也会增加：token 消耗；延迟；可能出现无效反馈循环（因此设置 10 轮上限）。

• 整体而言，Critic 提供的语言级反馈让系统能自我修正，结果更可信。

结论：Critic-Agent 机制是 DEPSRAG 准确性的关键。加入后系统的回答正确率提升约 3 倍，验证了“多智能体 + 自反反馈”设计的有效性。