1. 一次事故复盘单 Agent 失控如何拖垮全局系统先讲一个我亲历过的生产事故。某个多租户的 Agent 服务平台底层承载着不少自动化任务。其中一个不起眼的 Agent 任务因为模型反复解析工具响应失败陷入了调用工具-拿到报错-解析失败-重试-再调用工具的死循环。按照平台默认配置这个 Agent 可以无限重试而且每次重试之间只有很短的退避时间。一开始问题还不太明显只是这个 Agent 所在的进程 CPU 在缓慢攀升日志量开始变大。但几个小时后这个进程的内存占用从正常的 300MB 涨到了 3GB 多把宿主机整块内存吃满。同宿主上的其他 Agent 实例开始被 OOM Killer 随机选杀掉那些正在跑的重要流程全部中断。更麻烦的是这个 Agent 还在一轮接一轮地调用外部 API把供应商的速率配额消耗殆尽其他业务接口跟着被限流。等值班人员发现问题时光是止损就花了将近一个小时要定位是哪个 Agent 在失控、要找到对应进程并强制结束、要清理已经膨胀到几十 GB 的日志目录还要复盘为什么没有任何机制提前拦截。这次事故浓缩了我多年来做 Agent 基础设施遇到的一切典型问题单个 Agent 的行为是不可预测的它在循环里可能做任何事而传统的服务端限流、超时和告警全都对不上 Agent 的工作模式。今天写这篇东西就是想系统地聊聊资源配额管理这个问题把如何防止单个 Agent 耗尽资源这个课题彻底拆开要管哪些资源、阈值怎么定、用哪些机制去实现、配额耗尽后怎么办、怎么监控告警最后盘点我实际踩过的坑。2. 给 Agent 做资源画像它不是普通请求是长时运行的不确定任务2.1 为什么传统限流方案覆盖不住 Agent 场景如果你做过后端开发肯定熟悉常见的保护手段接口超时、熔断降级、进程内存上限、并发数限制。但这些手段套在 Agent 场景上总有一个关键缺口普通请求是进来一次、处理完就返回的短事务而 Agent 是一个可能持续数分钟甚至数小时的长时运行任务内部由多轮模型推理、工具调用、状态读写组成每一轮的结果都会影响下一轮的行为。这意味着资源消耗不是一个请求进来算一次就完了而是会在整个运行周期内持续累积。比如同一个 Agent 可以循环调用某个工具几百次每次调用都会产生日志、占用内存、消耗 API 配额。你没法简单地按照单个请求占多少资源去估量因为真正的消耗取决于这个 Agent 到底会跑多久、跑多少轮而这些在任务启动前往往是不可知的。从架构上看Agent 更像是定时任务和复杂工作流的结合体但它比普通工作流更不可控工作流的步骤是提前编排好的资源消耗可以预估Agent 的下一步行动由模型决定相当于每一步都是运行时动态规划的。你给一个工作流配 5 分钟超时是合理的但给一个 Agent 配 5 分钟超时它可能连第一个子任务都还没完成。2.2 资源维度拆解计算、内存、时间、速率、存储一个都不能少我通常把 Agent 需要管理的资源分成五类每一类都有不同的失控模式和度量单位资源类型度量单位典型失控模式计算资源CPU 时间、GPU 使用率、并行任务数死循环反复推理、子任务无限并发扩张内存资源RSS、堆内存、上下文缓冲日志积攒、大文档检索结果驻留、上下文爆掉时间资源单次任务总时长、轮次上限重试不退避、嵌套子 Agent 层层叠加速率与外部配额QPS、每分钟 API 调用次数工具密集循环打爆供应商限流存储资源日志体积、中间产物大小、临时文件数量Agent 反复写盘、大文件输出不清理这里特别想强调两个容易被忽略的点。第一个是Token 和成本本身也是资源。现在的 LLM Agent 是按 Token 计费的一个失控的 Agent 跑一晚上不是把你自建的推理集群打满就是直接烧掉一笔不小的 API 账单。我见过有人写了个批量总结文档的 Agent因为检索逻辑漏了去重同一个大文件被反复读进上下文一次任务烧掉了几十万 Token最后账单比预期翻了十倍。所以做配额管理时成本预算一定要纳入进来后续会专门讲怎么按成本配预算。第二个是上下文长度是隐性资源。模型上下文窗口是有限的但 Agent 的循环可能不断把新的观察结果塞进对话历史。有些框架默认不清理历史几轮工具调用之后上下文就接近窗口上限再调用一次大工具返回结果就直接触发长度超限错误。这在日志里看起来是模型报错实际映射出的问题是内存/上下文资源没有配额约束。2.3 Agent 工作的三个非线性特征闭环、乘数效应、跨请求状态理解了资源维度还要理解 Agent 资源消耗的三个非线性特征否则你会觉得配个内存上限就完了呗实际远远不够。闭环叠加普通服务是请求-响应的线性路径Agent 是循环结构。每轮循环里模型要推理、工具要执行、结果要存进上下文。循环次数不受外部请求次数约束而是受模型自身决策约束这就意味着一个 bug 可能导致循环次数从 5 次变成 500 次资源消耗也随之非线性放大。乘数效应Agent 可以并行派生子任务。一个主 Agent因为某个决策派生了 10 个子 Agent每个子 Agent 又可能派生 5 个孙 Agent。如果没有在每一层都加并发限制总并发数会指数级上涨瞬间打满整个集群。跨请求状态Agent 任务通常有持久化存储数据库、文件系统、外部系统即使进程本身内存被限制它也可能不停往磁盘写东西、往数据库写记录、往消息队列塞消息。进程内存限制管不住这种外部副作用所以配额管理必须是多维的不只是进程级资源限制。这三个特征解释了为什么单纯靠操作系统的资源限制机制比如 cgroup 内存限制远远不够。cgroup 只能防止进程物理资源溢出管不了 Agent 循环次数、外部 API 调用次数、token 消耗这类逻辑层面的资源。真正的配额管理需要一套贯穿调度层-执行层-外部调用层的完整机制。3. 配额阈值怎么定从容量预算到单 Agent 上限的推导逻辑3.1 先算集群容量账再反推单 Agent 配额很多人一上来就拍脑袋定配额并发上限设 10 吧超时设 30 秒吧。这样定出来的配额往往要么太松起不到保护作用要么太紧导致正常任务频繁失败。我建议的路径是先从集群容量账出发反推单 Agent 能分到多少资源。假设你有 4 台 8 核 32GB 的节点专门跑 Agent 服务总计算资源是 32 核 128GB。接下来要估计单个 Agent 任务的平均工作集大小。根据历史监控数据一个典型 Agent 在做文档处理类任务时内存占用大概 500MBCPU 占用 1 核左右。那么内存维度上单节点最多同时跑大约 60 个 Agent32GB / 500MB留 2GB 余量给系统进程和框架开销CPU 维度上最多跑 7 个左右8 核 / 1 核所以最终应该按 CPU 维度收敛单节点并发上限设 6 比较稳妥。这就是容量预算的核心逻辑先确定一个 Agent 平均需要多少资源再用总容量除以单任务资源需求得出全局并发上限最后除以节点数或队列数得到每个执行实例的配额。这个数字不是一次性算完就固定了。Agent 任务的资源画像会随业务变化建议每季度根据监控数据重新测算一次。如果发现平均内存占用从 500MB 涨到了 800MB并发上限就要相应调低。3.2 外部 API 配额的安全水位永远别用到 100%如果 Agent 依赖外部模型 API 或第三方工具 API还要考虑供应商侧配额。这里有个关键原则你分配出去的速率预算永远不要等于供应商给你的上限要留安全水位。原因有两点。一是 Agent 的调用方式天然有突发性多个 Agent 同时进入工具密集阶段时瞬间速率会远超平均值二是供应商限流是全局的一旦你在这个服务上被打满其他业务调用同一供应商接口也会被波及。按我的实践供应商速率配额的内部使用上限建议控制在 70%-80%。假设模型 API 的速率限制是每分钟 6000 次请求那么内部所有 Agent 共享的速率配额最多按 4800 次设计。剩下的 1200 次/min 是留给突发的缓冲。同时还要配套一个本地令牌桶从内部层面进一步平滑速率波动。3.3 配置模板一组可直接参考的默认值考虑到不同业务差异很大我直接给一份自认为比较稳妥的初始配置模板。你的系统如果还没有成熟配额体系可以先用这套值跑起来再根据实际监控调整配额维度建议默认值调整依据单 Agent 最大运行时长30 分钟根据历史任务时长 P95 调整取 P95 再上浮 20%单 Agent 最大循环轮次50 轮正常复杂任务一般 10-20 轮内完成单 Agent 最大工具调用次数200 次防止工具密集死循环单 Agent 并发派生子任务数3 个按业务峰值需求与集群容量综合评估单 Agent 内存上限1GB按任务工作集 P95 上浮 30%单 Agent Token 预算按成本定如某模型单任务 $2按业务可承受成本折算成 Token 数全局 Agent 并发上限单节点容量推算值 × 节点数 × 0.8留出 20% 余量给突发和运维操作这几个默认值不是拍脑袋背后都有逻辑。最大运行时长取历史 P95 上浮 20%是因为 P95 代表绝大多数正常任务的完成时间上浮 20% 给异常但可接受的情况留空间超过这个值基本可以判定为行为异常。Tool 调用次数上限 200 次对应的是一个 Agent 如果每轮调用 2-3 个工具50 轮循环内使用 100-150 次是正常量200 次已经预留了足够余量。Token 预算按成本定是最能直观体现商业约束的维度——一次任务花多少钱业务负责人心里都有数超了就拦。3.4 所有配额必须能按租户覆盖和叠加多租户场景下配额还有一个叠加问题既要限制单个 Agent也要限制一个租户下的所有 Agent。如果不加租户级配额用户完全可以自己起 100 个 Agent 任务每个 Agent 本身的配额都在限制内但 100 个任务加起来直接把集群打爆。业界通用的做法是两层配额全局配额和租户配额也叫项目配额或空间配额。全局配额管总并发和总资源量租户配额管单个业务方最多占用多少。当一个 Agent 启动时调度器要同时检查这两个配额——比如租户配额还有 20 个并发额度但全局配额只剩 5 个那这次启动只能分配 5 个中的 1 个。4. 落地实现限流器、信号量、超时熔断与系统级隔离怎么组合4.1 并发控制层信号量与有界队列资源配额管理的第一道闸门是控制并发数。这里的核心工具是信号量Semaphore。以 Python 的 asyncio 为例一个典型的 Agent 调度器可以这样限制全局并发import asyncio from contextlib import asynccontextmanager class AgentConcurrencyLimiter: def __init__(self, max_concurrency: int): self._semaphore asyncio.Semaphore(max_concurrency) asynccontextmanager async def acquire(self): async with self._semaphore: yield然后在调度 Agent 时async def run_agent_with_limit(agent_id: str, task_spec: dict): async with limiter.acquire(): # 这个 Agent 实际在这里执行 await execute_agent(agent_id, task_spec)信号量的好处是进入执行前先占名额执行结束后释放名额天然防止并发数超限。需要注意一个细节如果队列无限长来了大量 Agent 任务都会阻塞在信号量上排队虽然并发没超但内存中积压了大量待执行任务也是一种资源耗尽。所以信号量之外要配一个有界队列队列满了直接拒绝新任务而不是无休止排队。from asyncio import Queue, QueueFull queue Queue(maxsize200) async def submit_agent_task(agent_id, task_spec): try: queue.put_nowait((agent_id, task_spec)) except QueueFull: # 队列已满拒绝新任务或触发背压 raise SystemOverloaded(agent queue is full)这里的设计原则是信号量管执行并发有界队列管排队积压两者结合才能避免并发没超但内存爆了的隐性风险。4.2 速率控制层令牌桶平滑外部调用Agent 内部调用模型 API 或工具 API 时需要独立于全局并发的速率控制。令牌桶是比固定窗口更平滑的方案。一个简易实现import time class TokenBucket: def __init__(self, capacity: int, refill_per_sec: float): self.capacity capacity self.tokens capacity self.refill_per_sec refill_per_sec self.updated_at time.monotonic() def acquire(self, tokens: int 1) - bool: now time.monotonic() elapsed now - self.updated_at self.tokens min(self.capacity, self.tokens elapsed * self.refill_per_sec) self.updated_at now if self.tokens tokens: self.tokens - tokens return True return False为什么用令牌桶而不是简单的计数器限流因为令牌桶允许短时间内的突发流量桶里可以积攒一部分令牌Agent 在高峰时能一次性消耗多个令牌只要总体速率不超过补充速率就行。这对于Agent 在某一步突然需要连续调用多个工具的场景非常合适——固定窗口限流在这种场景下会频繁误拦。在同一层级还要考虑共享多租户的隔离。一个用户出了问题不应该影响另一个用户所以速率限制必须做两层全局令牌桶限制所有 Agent 的总速率租户令牌桶限制单个租户的速率。每个 Agent 调用外部 API 前要同时从两个桶里取令牌。4.3 时间与轮次控制超时、取消与递归上限并发和速率控制住了还要防止单个 Agent 无限地跑下去。这里需要三个机制配合第一是硬超时。给整个 Agent 任务设一个 wall-clock 超时超时就取消执行。Python 中可以用asyncio.timeout或asyncio.wait_forasync def run_agent_with_timeout(agent_id: str, task_spec: dict, timeout_sec: int): try: async with asyncio.timeout(timeout_sec): await execute_agent(agent_id, task_spec) except TimeoutError: await cancel_agent(agent_id, reasonhard_timeout) raise第二是轮次上限。这是 Agent 场景特有的控制手段。模型在 ReAct 循环中反复推理-行动每轮都有固定的认知开销。很多框架提供了 recursion limit 这类参数原理就是循环第 N 次后强制终止。如果你手写 ReAct 循环需要自己在循环条件里加上轮次计数def run_react_loop(model, tools, max_iterations: int 50): messages [] for iteration in range(max_iterations): response model.invoke(messages) if response.is_final_answer: return response tool_call response.tool_call # 执行工具、把结果追加回 messages... raise AgentIterationLimitExceeded(fexceeded max iterations: {max_iterations})轮次上限和硬超时是互补的不是冗余的。硬超时是从墙上时间维度兜底轮次上限是从逻辑复杂度维度兜底。一个 Agent 如果每轮只要 30 秒但已经循环了 100 轮硬超时 30 分钟可能还没触发但轮次上限会先拦住。第三是取消链接。多级 Agent 场景下父 Agent 被取消时所有子 Agent 必须级联取消否则会发生父任务超时结束了子任务还在后台继续跑的泄露问题。实现上可以维护一个任务注册表记录当前 Agent 的所有后代任务取消时递归 cancel。4.4 系统级隔离容器与 cgroup 是最后一道物理防线逻辑层面的配额管住了循环、速率和成本系统层面的物理隔离仍然不能省。推荐做法是每个 Agent或每组 Agent跑在独立的 cgroup 或容器里用操作系统强制限制 CPU 和内存# 创建 cgroup 并设置内存上限、CPU 配额 cgcreate -g cpu,memory:/agent-group/agent-12345 cgset -r memory.limit_in_bytes1073741824 /agent-group/agent-12345 cgset -r cpu.cfs_quota_us100000 /agent-group/agent-12345 cgset -r cpu.cfs_period_us100000 /agent-group/agent-12345 cgexec -g cpu,memory:/agent-group/agent-12345 python run_agent.py --task task_12345这样即使 Agent 内部逻辑由于某种原因绕过了我们写的信号量和超时控制操作系统也会强制把它按死在物理资源限界内。内存超过 1GB 的瞬间就会被 OOM Killer 处理不会拖垮整个宿主。如果你们的 Agent 跑在 Kubernetes 上对应的是 Pod 级别的 resources.limits 配置resources: limits: cpu: 1 memory: 1Gi requests: cpu: 0.5 memory: 512Mi很多团队觉得反正我有 K8s limits不需要自己实现配额了这是个误区。K8s limits 防的是物理资源溢出防不了 API 速率超限、防不了 token 成本超支、防不了租户间配额不公平。系统级隔离是最后一道防线不是全部防线。5. 配额耗尽后的行为设计排队、降级、重试与强制终止的合理次序配额机制设计好之后接下来要回答的问题是当一个 Agent 触发配额限制时系统应该怎么反应5.1 排队优先于拒绝但有界排队优先于无限排队如果 Agent 任务启动时全局并发已满合理的做法是让它进入等待队列而不是直接拒绝。直接拒绝会导致用户在业务高峰期频繁收到失败体验很差。但要注意队列本身也是一种资源无限队列会把系统内存耗尽。我的实践是设置一个带长度上限的优先级队列超过上限才拒绝新任务并明确告知用户系统繁忙稍后重试。这样在大多数情况下任务都能得到执行极端情况下也不会被积压任务拖垮系统。5.2 降级是比强制终止更优雅的中间方案Agent 触发某些配额限制时并不是只能终止这一条路。在很多场景下可以先降级保住主流程。降级的几种常见策略缩减工具集Agent 调用外部工具超过速率阈值后暂时禁用非关键工具只保留核心能力切换廉价模型Token 预算超了之后把 main planner 从高成本大模型降级到低成本小模型虽然效果可能打折但至少任务还能继续缩短上下文上下文长度接近上限时自动裁剪早期对话历史或压缩摘要避免直接失败减少并行度子任务并行数超限时把并行执行改为串行执行这就像系统高负载时的优雅降级一样目的都是在资源受限的情况下尽可能完成任务而不是直接失败。降级策略应该在调度层统一实现通过开关配置不用改动每个 Agent 内部逻辑。5.3 重试必须有预算没有退避和预算的重试是二次灾难Agent 系统里工具调用失败是常态重试机制必须有。但如果没有预算约束重试本身就是最危险的放大器。我做重试控制时遵循三条规则规则一重试次数是预算不是无限数字。每个 Agent 的总重试次数设上限比如 5 次超过之后直接终止任务并标记为失败。这个上限要算进总的工具调用次数里避免 Agent 在重试-失败-重试的循环里不知不觉消耗完所有配额。规则二重试必须指数退避加抖动。退避公式一般取min(初始间隔 * 2^重试次数, 最大间隔)再加上随机抖动防止多个 Agent 同时重试导致定时共振。规则三区分可重试错误和不可重试错误。超时、5xx、限流是可重试的参数错误、权限不足、资源不存在是不可重试的。重试不可重试的错误纯属浪费配额。5.4 强制终止最后一道手段但务必保证可观测性和一致性当所有降级和重试手段都用尽Agent 仍然触发硬超时或轮次上限就必须强制终止。强制终止不是简单杀进程要考虑一致性先触发优雅取消给 Agent 一个取消信号让它有机会保存中间状态、释放外部资源设置优雅取消的等待时间窗口比如 30 秒超时后再强制 kill终止后必须记录详细原因超时轮次超限内存溢出还是 API 配额耗尽这些日志是后续排查问题的基础终止后要执行补偿操作清理临时文件、释放云资源、回滚外部系统已产生的副作用这里要特别提醒强制终止是一个需要被充分测试的路径。很多系统的 happy path 跑得很好但取消路径从来没人测真正出问题时才发现取消信号没传到子进程中间状态没保存导致重启后数据错乱。排障部分的最后我会专门聊这个。6. 监控与告警配额使用率的观测闭环与合理阈值配额管理方案上线后最容易被忽略的一步是监控。没有监控你根本不知道配额设得合不合理、有没有 Agent 频繁撞限、有没有配额被悄悄绕过。6.1 核心指标清单从运行时长到工具调用成本我建议至少采集以下指标按 Agent ID 作为维度标记指标单位说明与价值运行时长秒识别慢任务和接近超时边缘的任务循环轮次次判断 Agent 是否在无效循环工具调用次数次关联外部 API 消耗Token 消耗量Token成本核算和上下文接近度内存峰值MB评估配额设置是否合理CPU 时间秒识别计算密集的 Agent重试次数次判断重试控制在正常工作终止原因枚举超时、轮次、内存、成本等分类统计Token 消耗这个指标比较特殊它既是成本指标也是资源指标。建议给每次模型调用打上 Agent ID、任务 ID、模型名这样出了问题时能精确追溯到是哪个 Agent、哪一轮花掉了多少 token。我踩过的坑是早期只记了总量没有按 Agent 拆分出问题时完全无法定位到具体任务。6.2 埋点实现包一层调用装饰器埋点本身要尽量轻量不要在关键路径上做重操作。推荐的做法是给 Agent 执行和工具调用各包一层装饰器import time from functools import wraps def instrument_tool_call(agent_id: str, task_id: str): def decorator(func): wraps(func) def wrapper(*args, **kwargs): start time.monotonic() try: result func(*args, **kwargs) record_metric(agent_tool_call_duration, time.monotonic() - start, { agent_id: agent_id, task_id: task_id, tool: func.__name__, status: success }) return result except Exception as exc: record_metric(agent_tool_call_duration, time.monotonic() - start, { agent_id: agent_id, task_id: task_id, tool: func.__name__, status: error, error_type: type(exc).__name__ }) raise return wrapper return decorator这样就自动记录了每次工具调用的耗时和结果后续可以统计哪个 Agent 调用了哪些工具、耗时分布、失败率是多少。配好这类埋点之后告警才有可靠的数据基础。6.3 告警阈值分级告警别等到撞墙才响告警阈值设计遵循提前预警、分级响应的思路。我常用的分级方案是WARN 级配额使用率达到 60%-70%。说明业务在增长需要关注趋势但不用立刻处理ERROR 级配额使用率达到 85%-90%。需要告警介入例如排查是否有失控 Agent、评估是否需要扩容CRITICAL 级单 Agent 频繁触发配额拦截、某个租户的 Agent 大面积被终止。往往意味着有系统性问题需要立即排查这个阈值的逻辑是配额是防撞墙的护栏告警是看到正在朝墙冲的预警不应该等撞墙才响。如果配额设计合理大多数系统应该长期处于 50%-70% 的使用率区间长期低于 30% 说明配额过松可以适当收紧提升资源利用率频繁超过 90% 说明配额过紧或容量不足。6.4 告警不要只看容器指标要看业务语义这里我要特别强调一个经验告警指标要贴近业务语义不要只看 CPU 和内存。CPU 和内存指标是底层信号但 Agent 系统的很多问题在 CPU 和内存指标上不一定有明显表现。比如一个 Agent 陷入了工具调用死循环每次调用之间都要等 API 返回CPU 占用反而不高但工具调用次数指标会持续攀升。只看 CPU 的话这个问题可能几个小时后才会被发现。所以我的告警策略是混合模式基础资源指标CPU、内存、磁盘加业务语义指标工具调用次数、循环轮次、Token 消耗、运行时长。后者往往能在前者报警之前提前暴露问题。7. 踩坑记录与工程化建议四个差点让我翻车的细节7.1 死循环检测不可靠轮次上限才是最实际的近似我刚开始给 Agent 做配额管理时最想做的是智能检测死循环识别到 Agent 反复执行同样的操作就自动终止。后来我放弃了。原因很简单从外部很难可靠判断一个 Agent 的重复操作到底是死循环还是正常迭代。比如重试某个外部系统调用直到成功视觉上看起来是重复的但可能第 30 次才成功这对业务来说是完全合理的。更麻烦的是LLM 驱动的 Agent 可能每轮循环的措辞都不同只是行为模式相似文本相似度检测根本抓不到它。所以最终方案就回归到最朴素的机制轮次上限加运行时长上限。管不了你是不是死循环只管你最多能跑多少轮、跑多长时间。这虽然不是完美的智能检测但它是 100% 可靠的兜底线。7.2 工具返回内容必须截断否则上下文会先爆炸另一个实战教训是工具返回值的长度控制。我们在做 RAG 类 Agent 时有工具会读取大批量文档并直接返回全文内容。早期没有限制返回长度一个文档检索工具把整本十几万字的电子书内容一股脑塞进上下文模型调用直接报上下文长度超限。这个问题在配额设计里属于上下文资源失控。我现在所有 Agent 框架的工具返回层都做统一处理工具返回内容超过 40000 字符时强制截断并附上截断提示信息让模型知道这里内容太长被截断了你可以要求分段获取。这既防止了上下文爆炸又不影响 Agent 在需要时主动分段读取。7.3 取消链路的完整性测试比业务逻辑更难我做过一次很尴尬的演练在测试环境制造了一个触发超时的 Agent结果发现主 Agent 被取消了但它派生的一个子任务还在后台继续调用外部 API。最后是外部 API 账单上出现了异常扣费我们才发现这个子进程一直没被终止。这就是前面提到的取消链路问题。跨进程、跨服务的 Agent 子孙任务取消信号往往不会自动传递必须显式实现注册与级联取消机制。更细的还有通过asyncio跑的子任务要task.cancel()并等待取消完成通过多进程跑的要发terminate()还要确认子进程真的退出不能让僵尸进程残留。建议所有团队在配额机制上线前专门写一个取消链路完整性测试创建一棵多层的 Agent 任务树触发根部取消然后断言所有后代任务都已被终止或标记为取消状态。这个测试不通过配额管理就算不上完整。7.4 硬阈值会催生钻空子行为需要反复调优最后说一个比较扎心的观察Agent 是会钻空子的。我见过一个测试场景因为工具调用次数配额是 200 次Agent 在接近上限时会自己停下来然后启动一个新的子 Agent 继续做同样的任务本质上绕过了单 Agent 配额只是把次数压力转移到了租户层级。如果你没有做租户级总预算这种绕过就成功了。这不是说硬阈值没用而是说配额体系必须有层级性单 Agent 层、租户层、全局层三层都要有对应配额且每层都独立拦截才能防止这种配额套利行为。同时要有配额使用率审计定期分析有没有 Agent 系统性地逼近某个配额边界如果有说明这个边界可能设得太紧或者存在某种绕过模式。回到文章开头那个事故如果当时系统里有运行时长上限 30 分钟重试预算 5 次工具调用次数上限 200 次单实例内存 1GB这几个配额死循环 Agent 根本活不过第一小时事件最多就是一条 WARN 告警加一个终止记录。真正的资源配额管理不是哪一个大招而是多个控制维度相互配合、层层设防的工程体系从准入调度、到执行限流、到系统隔离、到终止撤销、再到监控反馈每一道防线挡住一类失控方式。按这套思路一步步建起来你会发现单个 Agent 想耗尽资源真的没那么容易。