Agent 流水线中的背压：当 AI 生成工作的速度快于执行速度

一个基于流行开源技术栈构建的多 Agent 研究工具陷入了递归循环，运行了 11 天才被发现。账单：47,000 美元。两个 Agent 一直在不停地互相对话，消耗着 token，而团队却以为系统在正常工作。这就是 Agent 流水线没有背压时会发生的事情。

问题是结构性的。当编排 Agent 将任务分解为子任务并生成子 Agent 来处理每一个任务，而这些子 Agent 又可以自行生成更多子 Agent 或在多个工具调用之间扇出时，你就会得到指数级的工作生成。流水线产生工作的速度超过了它能执行、完成甚至核算的速度。这与响应式系统、流式架构和网络协议几十年前解决的问题完全相同——同样的解决方案同样适用。

无界工作队列问题

在传统软件中，没有流量控制的生产者-消费者系统最终会崩溃。快速生产者会填满内存，直到进程因 OOM 错误而终止。这种故障是明显且即时的。Agent 流水线的失败方式则更加隐蔽。

考虑一个被分配分析竞争对手任务的研究 Agent。它将任务分解为五个子 Agent，每个竞争对手一个。每个子 Agent 决定它需要搜索网络、阅读财务报告并总结新闻文章——每个子 Agent 产生三到五个工具调用。

编排器的上下文随着每个响应而增长。五个子 Agent 每个产生 2,000 个 token 意味着每个周期有 10,000 个 token 反馈给编排器。经过十个周期，这就是 100,000 个累积上下文 token，加上原始任务，加上中间推理。上下文窗口被填满，响应质量下降，Agent 要么崩溃，要么开始产生幻觉，因为它已经无法关注自己的指令了。

但上下文耗尽只是一种失败模式。其他失败模式同样具有破坏性：

• **速率限制级联。**来自生成的子 Agent 的二十个并发工具调用达到了你的 LLM 提供商的速率限制。每个子 Agent 的重试加剧了问题。一个每秒处理五个请求的系统现在每秒产生五十个重试请求。
• **预算超支。**多 Agent 系统中的 token 成本不是线性增长的——它们是复合增长的。每个工具调用都会增加上下文。每个子 Agent 的响应都会反馈到编排器中。没有刻意的预算管理，一个失控的任务就能在几小时内烧完你的月度 API 配额。
• **递归循环。**两个指令略有冲突的 Agent——比如，一个编辑要求"专业语气"，一个写作者被指示保持"随意且亲切"——可能进入无限修改循环。每个 Agent 都拒绝对方的输出并要求再来一轮。系统看起来很忙，但什么也没完成。

MAST 研究（多 Agent 系统失败分类学）于 2025 年 3 月发布，分析了七个开源 Agent 框架中超过 1,600 个执行轨迹。失败率从 41% 到 87% 不等。非结构化的多 Agent 网络与单 Agent 基线相比，将错误放大了高达 17 倍。这些失败大多不是模型失败。它们是编排失败——是背压可以预防的那种。

背压对 Agent 的真正含义

在响应式系统中，背压是慢速消费者向快速生产者发出信号以降低其输出速率的机制。TCP 流量控制使用滑动窗口。Kafka 在消费者跟不上时节流生产者。Node.js 流在可写目标无法跟上时暂停可读源。

对于 Agent 流水线，这个类比完全适用。"生产者"是生成子任务的规划或分解步骤。"消费者"是实际执行工作的执行层——工具调用、LLM 推理、外部 API 请求。背压意味着执行层可以告诉规划层：在我赶上之前停止生成新工作。

没有这个信号，规划层会继续分解、继续生成、继续扇出。它没有理由不这样做。生成计划的 LLM 不知道执行队列已经有 200 个待处理项，也不知道你已经用掉了每小时 token 预算的 80%。你必须显式地构建这个反馈循环。

实际实现有三个组成部分：

1. **有界工作队列。**规划和执行之间的每个缓冲区都必须有固定容量。当队列满时，规划者阻塞。无界队列只不过是带有额外步骤的内存泄漏——它通过不断增长来隐藏问题，直到更灾难性的故障发生。

2. **预算感知的规划。**在编排器生成新的子 Agent 或批准工具调用之前，它会检查剩余的 token 预算、当前的速率限制余量以及待处理工作的深度。如果资源紧张，它会合并子任务或推迟低优先级的任务。

3. **执行反馈。**已完成和失败的任务将其实际 token 消耗和挂钟时间报告回编排器。这使规划者能够调整其并发度——当执行缓慢时生成更少的子 Agent，或在速率限制紧张时批量处理工具调用。

五种真正有效的模式

模式一：自适应并发限制

不要硬编码"最多 5 个子 Agent"，而是测量执行层的实际吞吐量并动态调整。从并发度 2 开始。如果任务在延迟目标内完成且没有速率限制错误，则增加到 3。如果你开始看到 429 错误或上下文增长超出预算，则降回到 1。

这就是 TCP 用于拥塞控制的 AIMD（加法增加、乘法减少）算法，应用于 Agent 编排。它会收敛到正确的吞吐量，而不需要你提前预测。

模式二：层级化预算分配

在三个层级分配 token 预算：

• **作业级别。**整个任务有一个上限——比如 500,000 个 token。这是防止失控消费的硬性上限。
• **Agent 级别。**每个子 Agent 获得作业预算的一部分，与其预期复杂度成比例。简单的查找 Agent 可能获得 10,000 个 token。复杂的分析 Agent 获得 50,000 个。
• **函数级别。**单个工具调用获得最严格的限制。网络搜索可能被限制为 5,000 个上下文 token。代码执行调用可能获得 20,000 个。

当任何级别耗尽其预算时，执行在该级别停止——它不会向上级联消耗父级的配额。这与 Linux cgroups 限制每个进程组的资源消耗是相同的原理。

模式三：工具调用的熔断器

如果某个特定的工具或外部 API 开始失败或响应缓慢，就停止调用它。熔断器在滚动窗口内跟踪错误率。当失败超过阈值——比如最近 10 次调用中的 50%——熔断器打开，所有后续对该工具的调用立即返回缓存的后备值或明确的"不可用"信号。

这可以防止对已经陷入困境的服务产生重试风暴从而放大负载。Agent 收到一个明确的信号表明工具已关闭，可以相应地调整其计划，而不是在不会成功的重试上浪费 token。

模式四：深度限制分解

为子 Agent 生成的层数设置硬性限制。编排器可以生成子 Agent（深度 1）。这些子 Agent 可以进行工具调用，但不能生成自己的子 Agent（深度 2 被禁止）。这可以防止递归分解将简单任务变成指数级扩展的 Agent 树。

如果子 Agent 确定它需要进一步分解，它会带着请求将控制权交还给编排器。然后编排器可以决定——根据当前队列深度、预算和进度——是否批准额外的分解或进行合并。

模式五：带优先级队列的负载卸除

并非所有 Agent 工作都同等重要。当系统处于压力之下——高队列深度、接近预算限制、错误率升高——首先卸除低优先级的工作。优先级系统可能如下：

• **P0（永不卸除）：**面向用户的响应、安全检查、最终输出组装。
• **P1（重负载下卸除）：**富化步骤、额外上下文收集、交叉引用。
• **P2（积极卸除）：**锦上添花的阐述、冗余验证、外观改进。

编排器在调度每个任务之前检查系统压力。在正常条件下，一切都运行。在负载下，P2 任务被丢弃。在极端负载下，P1 任务被推迟直到压力消退。

检测工具：在账单到来之前发现失控扩张

如果看不到压力正在积聚，就无法施加背压。Agent 流水线的最低限度检测工具包括四个指标：

• **队列深度随时间变化。**持续增长的队列意味着你的消费者跟不上。这是背压问题最早的信号。
• **Token 消耗速率。**跟踪每分钟的 token 数，而不是每个请求的。少数大型请求可以在保持请求每分钟限制以下的同时耗尽你的预算。基于 token 的监控能捕捉到请求计数遗漏的问题。
• **Agent 生成深度。**当前存在多少层子 Agent 嵌套？如果这个数字持续增长，说明你有没有终止条件的递归分解。
• **任务完成率。**在滚动窗口内测量的已完成任务与已创建任务的比率。健康的流水线保持在 1.0 附近。比率降至 0.5 意味着你创建工作的速度是完成速度的两倍——这就是需要背压的系统的定义。

在这些指标上设置告警。五分钟内队列深度翻倍、token 速率在前十分钟内超过每小时预算的 60%、或生成深度超过 3——任何一个都应该在人类需要查看仪表板之前触发自动限流。

根本性权衡：吞吐量与安全性

背压是有代价的。一个限制并发、强制执行预算和卸除负载的系统，其总输出量将少于一个不受限制全速运行的系统。没有护栏的 Agent 平均会探索更多可能性、收集更多上下文、尝试更复杂的计划。

它偶尔也会花 47,000 美元自言自语 11 天。

这里的工程纪律与任何分布式系统相同。你不会让数据库在 100% CPU 利用率下运行，因为第一次流量峰值就会把它压垮。你不会把消息队列填到 95% 容量，因为一个慢消费者就会导致级联故障。你也不应该让你的 Agent 流水线生成无界工作，因为一旦它进入递归循环，你在账单到来之前都不会知道。

背压不是一种优化。它是一种生存机制。成功交付可靠 Agent 系统的团队不是那些拥有最复杂模型的团队——而是那些以对待任何处理生产流量的分布式系统同样的工程严谨态度来对待 Agent 流水线的团队。有界队列、预算强制执行、熔断器、负载卸除和自适应并发不是新概念。它们是经过验证的概念，正等待被应用到最需要它们的最新一类系统中。