Amazon提出自进化Agent：离线编译工具让延迟降62%！
Tool-Making and Self-Evolving LLM Agents in Low-Latency Systems
在当今的大模型应用中，基于代码生成的智能体（Agent）正逐渐成为处理复杂软件和操作系统的主流交互方式。面对各种长尾的故障排查、工作流调度和数据查询，Agent 可以通过阅读自然语言指令、实时编写代码并执行来达成目标。这种被称为 CodeAct 风格的即兴编程能力赋予了系统极大的灵活性，但在要求极高的工业生产环境中，这种灵活性却悄悄转化为效率和可靠性的致命瓶颈。
ArXiv URL：https://arxiv.org/abs/2607.08010v1
试想在一个高度耦合的现代物流履约中心（Fulfillment Center）里，一条传送带的堵塞或一个机器人传感器的异常，都会在几分钟内引发整个设施的连锁停顿。在这种场景下，人类工程师通常会遵循标准操作程序（SOP）来诊断和处理警报。如果我们让现有的 Agent 介入自动化处理，它们往往会在每次收到警报时，重新阅读一遍 SOP 文本，重新摸索一遍后台数据库的接口模式（Schema），然后现场编写出一套全新的查询代码。即便面对的是和上一秒完全相同的警报，大模型也会在推理时重新经历数十轮的交互。这不仅浪费了大量的时间，推高了系统延迟，更引入了极大的运行间差异（Run-to-run variance），使得一次原本简单的恢复操作变得充满不确定性。
为了解决这一痛点，Amazon 的研究团队在最近的一项工作中提出了一套全新的自进化 Agent 架构。他们放弃了让 Agent 每次都在“现场写代码”的传统路径，而是引入了一条离线的工具制造流水线（Tool-making pipeline）。该系统能够在部署前，将反复出现的 SOP 步骤提前编译成经过严格验证、带有版本控制的确定性工具。在线上运行时，生产级 Agent 只需要直接调用这些工具即可。
这套系统目前已经成功部署在亚马逊物流履约中心的警报分类系统中。实际生产数据显示，采用这套工具调用架构后，系统的 p50 延迟降低了 42%。在针对 1500 个历史警报的测试中，端到端错误率最高下降了 53%。更值得注意的是，因为工具返回的是紧凑的结构化结果，系统甚至可以砍掉冗余的子代理架构，进一步在控制变量的消融实验中将 p50 延迟斩断 62%。
这篇研究揭示了一个重要的工业落地趋势：大模型在企业内部的最强形态，或许并不是一个永远都在临场发挥的聪明大脑，而是一个能够将自身经验固化为基础设施，从而实现低延迟和高一致性的工具制造者。
告别推理时编程：让经验沉淀为工具
在传统的层次化多智能体架构中，通常会有一个主智能体负责遍历决策树，并将每一个需要评估的 SOP 节点委托给一个子智能体。这个子智能体会利用模型上下文协议（MCP）编写代码去查询真实的业务指标。在最复杂的情况下，为了处理一次警报，这种子智能体的查询和修复循环甚至会超过 100 个大模型交互轮次。这就是延迟的罪魁祸首。
Amazon 团队的解法是，把这种多轮的动态探索前置到构建阶段（Build-time）。他们设计了一个由大模型驱动的离线工具制造者（Tool-maker），它的任务是为 SOP 中的每一个节点量身打造一个函数式的工具。一旦构建完成，这些工具就具有完全确定的输入输出逻辑，在线上被触发时只占用极少的计算资源。
然而，让大模型读一读 SOP 文本就直接写出完美的工具代码，在现实中是行不通的。人类编写的 SOP 往往充满了大量的省略。人类工程师凭借领域常识知道某个字段该怎么处理，知道遇到空数据如何应对，但仅靠文本输入的大模型对此一无所知。为了填补这种“规格信息缺失”，研究人员为工具制造流水线设计了两个至关重要的接地（Grounding）机制。
第一个机制是数据收集轨迹（Data-collection trace）。在让模型生成工具代码之前，系统会先派出一个数据收集子智能体，去真实的生产环境中运行一遍相关的操作。这就好比让模型先去实地考察一下，看看数据库里真实的表结构长什么样，具体的阈值和数据类型是什么。通过拿到真实的执行轨迹，模型就能准确理解 SOP 文本与后端系统接口之间的映射关系。
第二个机制是测试与修复循环（Test-repair loop）。生成工具后，不能直接上线，必须经过实战检验。研究团队为每个 SOP 节点准备了一套由人类领域专家标注的测试集。新生成的候选工具会在这些测试集上运行，如果结果与人工标注的标准答案（如：True、False 或无数据）不符，失败的日志就会被送入一个反思器（Reflector LLM）中。反思器会分析代码哪里写错了，并指导工具制造者进行修改。整个过程反复循环，直到工具能够完美通过所有测试用例。
在部署到线上时，系统仍然保留了极强的韧性。主 Agent 会优先调用这些稳定、快速的离线工具；但如果遇到了意料之外的情况，比如某个新类型的警报缺少对应的工具，或者工具在执行时抛出了异常，Agent 就会无缝降级回传统的代码生成模式，靠临场发挥来应对危机。这种设计完美兼顾了生产系统对速度的极致追求与对边缘情况的兜底需求。
实验揭示：环境交互是生成可靠工具的底线
为了验证这套流水线的有效性，研究团队对 44 个 SOP 决策节点进行了工具生成实验，并对比了不同的配置对生成成功率（Pass@1）的影响。这里的通过标准极其苛刻：一个生成的工具必须在保留的独立验证集上全部判断正确，才能算作通过。
上图展示了使用 GLM-4.7 模型作为工具制造者时的表现。如果我们仅仅将 SOP 文本扔给大模型让它写代码，生成的工具几乎无法在严格的验证集上存活，通过率极低。当我们引入了数据收集轨迹（+D）后，模型通过观察真实的环境反馈，表现有了显著提升。当我们进一步加入测试与修复循环（+R）时，也就是最终部署的 SOP+D+R 配置，系统的整体通过率一跃达到了 94.5%。
消融实验的结论非常明确：真实的环境轨迹和基于标注数据的修复循环，缺一不可。如果移除修复循环，通过率会暴跌近 10 个百分点；如果移除数据收集轨迹，仅仅依靠修复循环去盲目试错，通过率也会下降超过 5 个百分点。更深入的分析表明，如果没有真实环境的执行轨迹打底，大模型在修复代码时往往会陷入幻觉，甚至越改越错。这也印证了一个重要的工程原则：再强大的大模型，如果没有与物理世界或底层数据的坚实对接，其推理能力也只能是空中楼阁。
有趣的是，当系统的通过率卡在 94.5% 时，研究人员发现剩下的那几个失败节点，错并不在大模型，而在于人类编写的 SOP 本身。有些边缘情况（比如负的分母、空值）在 SOP 中根本没有定义，标注数据也没有覆盖到。在一个节点中，甚至因为 SOP 对“平均时间窗口”的描述过于模糊，导致模型在修复循环中为了迎合测试用例，反而写出了违背 SOP 本意的代码。当研究人员人工澄清了这些模糊的 SOP 规范后，工具生成的通过率直接飙升到了 99.9%。这说明，当 Agent 的自我演进能力达到一定高度后，系统能力的上限将取决于人类提供的业务规范究竟有多清晰。
架构演进与意想不到的系统审计收益
由于工具化大幅降低了推理成本，这也驱动了系统架构层面的简化。原本由于要处理复杂的多轮代码生成逻辑，系统必须维持主智能体加多个子智能体的庞大架构。而现在，由于工具是一次性编译好的，它们返回的结果变成了非常精简的结构化判定。这使得主智能体可以直接内联调用这些工具，不再需要中间层的子智能体进行任务翻译。
这种被称为“直接调用（Direct-call）”的架构改变，极大地释放了性能红利。在严格控制变量的离线测试中，仅因为省去了子智能体架构所带来的通信与调度开销，系统的 p50 延迟就进一步下降了 62%，p99 延迟也降低了 30%。对于分秒必争的履约中心来说，这种量级的延迟缩减意味着系统可以在故障蔓延到其他环节之前，更快地掐断风险。
与此同时，为了在资源受限的生产环境中运行如此敏捷的系统，研究团队采用了小模型微调的策略。他们使用更强大的模型（如 GLM-4.7）在离线阶段承担高昂的推理和试错成本来生成工具，并将正确处理警报的轨迹记录下来。随后，他们利用这些轨迹去微调更小巧的线上模型（如 Qwen3 32B 或 GLM-4.5-Air）。为了保证线上模型在工具失效时能够成功降级，训练数据中特意混合了部分工具被随机禁用的轨迹，强制小模型学习如何回退到自己写代码的模式。实验证明，这种混合轨迹微调法使得线上 Agent 在没有工具可用时的准确率依然维持在 97% 以上的极高水平。
除了延迟和错误率的直接收益，将动态的代码生成固化为版本控制的工具，还为工业系统带来了极具价值的可审计性。在过去，如果上游数据库的接口发生了一些微小的变化，具备自我修复能力的 Agent 会在每次请求时默默地通过报错和重试来适应新接口，最终依然给出正确答案。在表面上看，这体现了 AI 的鲁棒性，但从系统工程的角度来看，这掩盖了严重的数据漂移危机。
当所有操作被固化为具体的工具版本后，工具拥有了确定的输入和输出。监控智能体通过批量审查工具的执行日志，迅速发现了上游环境中的多处隐患。例如，系统曾经捕获到一个数据端点悄悄地将返回格式从百分比（75）改成了小数（0.75）。如果是每次即兴写代码的 Agent，很可能在一连串冗长的自我纠错后稀里糊涂地把这个问题掩盖过去，甚至会在某些边界情况下导致灾难性的误判。而固化的工具由于逻辑确定，能够立刻在数据分布中暴露出异常，帮助工程师精准定位问题。
通过让大模型在离线阶段消耗算力去“造工具”，而在对时间高度敏感的线上阶段直接“用工具”，Amazon 探索出了一条极具参考价值的 AI 落地路径。这种自进化的 Agent 范式证明了，想要让大模型在严苛的工业级流水线中站稳脚跟，我们需要的不是让它在每一次请求时都去展示惊人的从零编程能力，而是要教会它将聪明才智沉淀为枯燥但绝对可靠的标准工具。这不仅让响应速度和稳定性得到了指数级的提升，更为那些难以被彻底重构的老旧工业系统，提供了一座通向智能化的稳固桥梁。