低延迟系统中工具制作与自进化LLM代理

arXiv cs.CL 论文

摘要

本文提出了一种方法,将重复的标准操作流程步骤编译为经过验证、有版本管理的工具,在部署前完成,替代推理时的代码生成。在一个配送中心的报警分类系统中,该方法将p50延迟降低了42%,端到端错误率降低了最多53%。

arXiv:2607.08010v1 公告类型: 新 摘要: 生产环境中的LLM代理往往由于在每次请求中为相同流程步骤重复生成代码而导致延迟和可靠性问题。我们使用一种代理工具制作流水线替代这种推理时的编码循环,该流水线在部署前将重复的SOP步骤编译为经过验证、有版本管理的工具。工具制作者在实时环境中进行综合,收集执行轨迹,观察后端模式和数值,生成候选工具,并根据标注案例进行修复。运行时,生产代理直接调用这些工具,仅在必要时回退到代码生成。我们将该方法部署在一个配送中心的报警分类系统中,代理根据一个包含44个节点的SOP对异构指标后端进行报警诊断。在生产环境中,工具调用将p50延迟降低了42%。在1500个历史报警上,通过抑制重复步骤中逐次运行的方差,端到端错误率降低了最多53%。由于工具返回紧凑的结构化判决,还实现了更简单的直接调用架构,在受控消融实验中进一步将p50延迟降低了62%。版本化的工具还提高了可审计性,并暴露了规格缺口和上游数据漂移。我们的结果表明,自进化代理可以使工业级LLM系统更快、更可靠、更易于操作。
查看原文
查看缓存全文

缓存时间: 2026/07/10 06:12

# 低延迟系统中的工具制作与自我进化LLM代理 来源:https://arxiv.org/html/2607.08010 Kalle Kujanpää Ning Liu Shahnawaz Alam Yeshwanth Reddy Sura Tianyu Yang Kristina Klinkner Shervin Malmasi Amazon, Fulfillment Technologies & Robotics \{kujanpaa,malmasi\}@amazon\.com

###### 摘要

生产环境中的LLM代理常因每次请求都重新生成相同流程步骤的代码而浪费延迟和可靠性。我们用一个代理式工具制作流水线取代这种推理时编码循环,该流水线在部署前将重复的SOP步骤编译成经过验证和版本管理的工具。工具制作器在收集执行轨迹、观察后端模式和数值、生成候选工具并针对标注案例进行修复的过程中,将合成过程扎根于实际运行环境。运行时,生产代理直接调用这些工具,仅在必要时回退到代码生成。我们在一个物流中心(FC)的告警分类系统中部署了该方法,代理根据包含44个节点的SOP,在异构指标后端上诊断告警。在生产中,工具调用将p50延迟降低了42%。在1,500个历史告警上,通过抑制重复步骤的运行间变化,端到端错误率最高降低53%。由于工具返回紧凑的结构化判定结果,它们还支持更简单的直接调用架构,在受控消融实验中将p50延迟进一步降低62%。版本化工具还提高了可审计性,并暴露了规范缺口和上游数据漂移。我们的结果表明,自我进化代理可以使工业LLM系统更快、更可靠、更易于运维。

低延迟系统中的工具制作与自我进化LLM代理

Kalle Kujanpää Ning Liu Shahnawaz Alam Yeshwanth Reddy Sura Tianyu Yang Kristina Klinkner Shervin Malmasi
Amazon, Fulfillment Technologies & Robotics
\{kujanpaa,malmasi\}@amazon\.com

## 1 引言

LLM编码代理正在成为复杂软件和运维系统的实用接口。与每个任务使用固定API或手动编写自动化不同,这些代理读取自然语言指令,编写并执行代码,并迭代直到产生答案或动作。这种灵活性已在值班事件分类(Chen et al., 2024b (https://arxiv.org/html/2607.08010#bib.bib8); Wang et al., 2024b (https://arxiv.org/html/2607.08010#bib.bib9))、工作流引导的运维(Ye et al., 2025 (https://arxiv.org/html/2607.08010#bib.bib10))以及通用基于代码的工具使用(Wang et al., 2024a (https://arxiv.org/html/2607.08010#bib.bib11))中得到了部署。在工业环境中,许多流程被记录为标准操作程序(SOP),而执行它们所需的数据则存在于指标存储、日志、仪表板和工单系统中。

在线:代理运行时

| 之前 | 之后 |
|------|------|
| 触发 | 触发 |
| 主代理 | 主代理 |
| 子代理 3–10次/告警 | 工具 3–10次/告警 |
| 动作 | 动作 |

离线工具制作

| SOP节点描述文本 |
| 数据收集子代理 |
| 工具制作器LLM |
| 测试:标注案例 |
| 反射器LLM |
| 工具通过/修复/部署 |

图1:离线(顶部),每个SOP节点被编译成一个工具:数据收集子代理针对MCP运行,产生一条轨迹;工具制作器LLM据此编写候选工具;反射器-工具制作器循环根据标注案例修复候选工具。在线(底部),基线子代理针对每个节点编写新的MCP查询代码,需要10–20次LLM轮次;而我们的代理内联调用已编译的工具,每个节点只需一次调用。

然而,这种灵活性造成了效率和可靠性瓶颈。在流行的CodeAct风格范式(Wang et al., 2024a (https://arxiv.org/html/2607.08010#bib.bib11))中,代理在推理时为每个请求生成并执行全新的代码。当相同的工作流在稳定的后端上重复执行时,代理会重新解释相同的指令,重新发现相同的模式,并重新生成相似的代码,从而增加延迟、成本和运行间变化。先前的基准测试表明,代理在处理工作流引导的任务时仍然存在困难(Nandi et al., 2025 (https://arxiv.org/html/2607.08010#bib.bib12); Wang et al., 2025b (https://arxiv.org/html/2607.08010#bib.bib13); Riddell et al., 2026 (https://arxiv.org/html/2607.08010#bib.bib14)),即使是SOP增强的多代理系统在运维诊断上也留下了显著的准确性差距(Pei et al., 2025 (https://arxiv.org/html/2607.08010#bib.bib15))。在我们的设置中,大部分延迟和正确性错误是由将描述不完整的SOP文本转换为针对生产指标后端的具体查询引起的。

这促使了从推理时编码代理向自我进化代理的转变:这类系统通过在生产需要之前构建可重用的工具、技能或程序,随时间改进自身的动作空间。近期的工作通过从示例或任务描述中单次合成工具(Cai et al., 2024 (https://arxiv.org/html/2607.08010#bib.bib17); Yuan et al., 2024 (https://arxiv.org/html/2607.08010#bib.bib18); Wang et al., 2024c (https://arxiv.org/html/2607.08010#bib.bib19))、采用基于环境或测试验证的迭代构建时构造(Wang et al., 2023 (https://arxiv.org/html/2607.08010#bib.bib20), 2024d (https://arxiv.org/html/2607.08010#bib.bib21); Wölfle et al., 2025 (https://arxiv.org/html/2607.08010#bib.bib23))以及相邻的运维文档如策略(Zwerdling et al., 2025 (https://arxiv.org/html/2607.08010#bib.bib24))和故障排查指南(Mao et al., 2025 (https://arxiv.org/html/2607.08010#bib.bib25))来探索这一点。关键思想是分摊成本:重复执行的流程步骤被一次性编译成经过测试的工具,然后在运行时廉价且一致地调用。

我们在一个物流中心(FC)的生产代理中研究这种方法,其中SOP规定了如何诊断和处理机器人进料、输送和分拣子系统的告警。这些SOP根据来自异构指标后端的阈值进行分支,并选择从低成本流量重新分配到高成本人员调整、工单升级和设备待命等干预措施。延迟和正确性紧密耦合:故障在几分钟内级联到各个子系统,而针对错误原因采取的高成本行动难以逆转。由现场操作员手动执行在并发告警下速度慢,且由于指标、模式和条件分支的数量多而容易出错。

我们报告了针对此设置的一个代理式工具制作流水线的设计及生产部署,用于根据书面SOP对出库站台告警进行分类。该系统有两种模式(图1 (https://arxiv.org/html/2607.08010#S1.F1))。在构建时,工具制作器针对生产环境构建每个SOP步骤的工具库,观察模式和执行轨迹,并针对标注案例验证候选工具,而不是仅依赖SOP文本。在推理时,代理针对每个告警调用这些工具,仅在工具不可用或失败时回退到代码生成。这保留了编码代理的灵活性,同时将重复的、延迟敏感的工作转移到可重用且可审计的工具库中。

我们做出两个主要贡献:一个将重复SOP步骤编译成经过验证的工具的代理式工具制作流水线,以及将其集成到一个已部署的告警分类代理中,该集成将p50延迟降低了42%,支持在受控消融实验中通过架构重新设计进一步降低62%,并将端到端错误率降低最多53%。我们还报告了三个发现。数据收集轨迹和测试-修复循环都是必要的。剩余的误差集中在描述不完整的SOP步骤上,针对性的修复将pass@1从94.5%提高到99.9%。具有稳定输入输出的版本化工具揭示了先前存在的上游不一致性,这些不一致性在运行间变化时通常被隐藏。我们的结果表明,将自身经验编译成可重用工具的代理是将编码代理的灵活性引入延迟敏感的工业工作流的实用途径。

## 2 生产设置与任务

出库站台是物流中心中的最终作业环节,包裹在此处被分拣和装载,然后离开前往下游物流环节。站台紧密耦合:一个退化的子系统会阻塞其上游的作业,并在几分钟内级联到整个站台,从而将局部故障放大为重大的延迟,威胁交货承诺。代理对告警进行分类,例如机器人工作站因上游输送堵塞而空闲,或因相机、传感器、标签或包装缺陷而产生异常错误率。

代理遵循一个SOP,该SOP被编码为一个包含44个决策节点和19个动作节点的决策树。决策节点分为三种类型。观测节点测试某个指标是否超过告警阈值,并作为告警入口点;根因节点识别潜在的故障;约束节点对最昂贵的动作进行门控。动作范围从低成本(处理告警、流量重新分配)到高成本(设备停机、人员调整)。每个节点指定查询哪些数据以及如何处理。代理评估观测节点以定位故障,达到候选根因,并执行动作。例如,在关闭带有故障吸盘的机器人之前,约束节点会验证关闭是安全的(剩余容量足以覆盖物品流)还是不可避免的(错误率使得操作更差)。

## 3 方法

我们基于Eluna(Liu et al., 2026b (https://arxiv.org/html/2607.08010#bib.bib56))的分层多代理架构进行构建,其中一个主代理遍历决策树,并通过自由文本问题将每个评估节点委托给一个CodeAct风格子代理(Wang et al., 2024a (https://arxiv.org/html/2607.08010#bib.bib11))。子代理生成并执行通过MCP(模型上下文协议)查询指标的代码,迭代直到返回一个自由文本答案,主代理将其解析为一个判定结果(真/假/无数据)以指导后续遍历。委托将多轮数据处理上下文保持在子代理内,而决策树层内的子代理调用并行运行。每个告警,代理评估3–10个节点,在最复杂的情况下子代理循环可能超过100次LLM轮次。该架构中每个告警的主要成本是子代理的循环,因为其大部分轮次将相同的SOP文本转换为对不变接口的相同MCP查询。

我们用每个节点的工具替换这个循环,每个工具是循环在构建时的一次性编译,在推理时直接返回判定结果。工具是模型无关的,并且可以独立于代理微调进行重新生成。

### 3.1 工具制作流水线

SOP由人类编写,SOP文本省略了人类读者通过领域知识或检查数据来解析的执行细节,例如字段名、数据类型、空值处理和边界情况约定。当工具制作器只被给予SOP文本时,这些省略会导致持续失败。流水线通过两种基础机制来弥合这一差距(图1 (https://arxiv.org/html/2607.08010#S1.F1),顶部):一个*数据收集轨迹*,即针对实时模式的真实执行;以及一个*测试-修复循环*,即针对标注案例纠正每个候选工具。

每个工具都是一个函数,具有统一的签名:将(仓库、时间戳、上下文)输入映射到节点的判定结果(真、假或无数据)和支撑细节。上下文携带站点特定参数和来自父节点的判定结果。每个节点都有一个标注训练集,由来自离线标注器的(输入、判定)对组成,该标注器的逻辑由领域专家指定。

流水线有三个模型组件,在图1 (https://arxiv.org/html/2607.08010#S1.F1)中从左到右显示。*数据收集子代理*是基线CodeAct子代理,作为推理时的回退方案,具有对生产MCP的访问权限。对于每个节点,它在三个跨判定标签平衡的采样训练案例上运行,编写并执行查询代码,迭代到最终判定,并与案例标签进行比对。产生的轨迹(传递给工具制作器)包含查询代码、MCP响应和观察到的模式(字段名、数据类型、值范围)以及比对后的判定,提供了SOP省略的执行细节。

*工具制作器LLM*基于SOP节点文本、节点在决策树中的位置(其父节点和子节点)以及数据收集器的轨迹,生成一个候选工具。然后候选工具在完整的标注训练集上进行测试,不一致之处传递给测试-修复循环。

*反射器LLM*编写一个简短的故障诊断,之后工具制作器基于诊断和不一致之处进行重写。反射器接收失败的(输入、预期、预测)三元组和先前的候选工具,工具制作器接收相同内容以及反射器的诊断。循环预算为三轮,一旦候选工具通过完整的训练集则提前终止。通过训练集通过率最高的候选工具被部署。附录D (https://arxiv.org/html/2607.08010#A4)展示了一个从生成工具中提取的示例。

在推理时,工具以两种配置之一使用:主代理将节点委托给调用该节点工具的子代理,或者主代理直接调用工具(图1 (https://arxiv.org/html/2607.08010#S1.F1),底部)。每个工具返回判定结果、观测值、阈值和文本解释。"无数据"保留用于缺失的指标,异常情况触发回退到基线的CodeAct子代理。

### 3.2 代理微调

生产延迟约束将部署的告警分类代理限制在较小的模型尺寸,而小型现成模型无法可靠地遵循SOP。因此,我们将一个较大的教师模型蒸馏到小型学生模型:教师模型在告警分类任务上生成轨迹,拒绝采样只保留那些提取的观测、根因和动作都与真实情况匹配的轨迹(Yuan et al., 2023 (https://arxiv.org/html/2607.08010#bib.bib49)),然后使用LoRA(Hu et al., 2022 (https://arxiv.org/html/2607.08010#bib.bib55))对学生模型进行微调。为了保持学生模型在工具缺失或失败时的鲁棒性,教师模型在变化的工具可用性下生成轨迹:在75%的轨迹中,生成的工具可用,但每个轨迹中随机禁用25%的工具;在剩下的25%中,所有节点工具被移除,因此教师模型为每个节点回退到子代理。

## 4 工具制作实验

参考图注

图2:在GLM-4.7上,每种消融配置的每个节点pass@1(左)和生成成本(令牌数,右)。+D添加数据收集轨迹(第3.1节);+R添加测试-修复循环。只有部署的配置(SOP+D+R)超过90%的pass@1。

表1:按工具制作器和配置划分的每个节点pass@1(%)。+D添加数据收集轨迹;+R添加测试-修复循环。部署的SOP+D+R列以粗体显示,GLM-4.7已部署。置信区间和显著性检验见表9 (https://arxiv.org/html/2607.08010#A6.T9)。

### 4.1 实验设置

#### 数据。
流水线在44个决策节点上进行评估。每个节点有一个由流水线使用的标注训练集和一个单独保留的评估集,构建为时间分割。每个节点的案例数量从100到200不等,总计8,011个训练案例和8,022个评估案例。数据标签分布均匀。

#### 模型。
我们比较以下四个模型作为工具制作代理(第3.1节)。

相似文章

LLM代理已经知道何时调用工具——甚至无需推理

Hugging Face Daily Papers

本文介绍了When2Tool,一个研究LLM代理实际何时需要调用工具的基准,并揭示模型已从隐藏状态知道工具的必要性但未能采取行动。提出的Probe&Prefill方法将不必要的工具调用减少了48%,且精度损失极小。

面向低延迟多智能体工具调用的有状态推理架构

arXiv cs.LG

本文提出了一种用于多智能体工具调用的有状态推理架构,该架构在多次调用之间复用KV缓存,并采用推测解码技术,相较于vLLM和SGLang,在智能体工作流上实现了2.1倍至4.2倍的加速。