夜雨聆风生产环境中的 AI Agent 会调用几十个甚至上百个外部工具：搜索引擎、数据库查询、API 接口、文件系统操作、代码执行沙箱。这些工具各有不同的可用性特征——有的响应在毫秒级，有的需要几秒，有的偶尔会超时或返回 5xx。
当其中一个工具开始变慢或频繁失败时，如果没有适当的隔离机制，故障会迅速扩散。一个慢速的搜索引擎查询阻塞了 Agent 的整个工具调用循环，导致其他无关的工具调用也被排队等待。一个返回 429 限流状态的 API 被反复重试，直到耗尽 Agent 的 token 预算和上下文窗口。
传统分布式系统中的断路器模式和隔板模式，在 Agent 的工具调用场景下有了新的含义和实现方式。这不是简单的"把 Hystrix 搬过来"，而是需要重新思考：当调用方是一个非确定性模型，而不是一个确定性的服务消费者时，断路和隔离的语义应该是什么。
工具调用断路器的状态语义
传统断路器的三个状态——Closed、Open、Half-Open——在 Agent 语境下需要重新定义。
在 Closed 状态，工具调用正常进行。断路器统计最近一段时间内的失败率，当失败率超过阈值（比如连续 5 次超时或 30 秒内错误率超过 50%），断路器跳闸到 Open 状态。
在 Open 状态，断路器直接拒绝调用，而不是让模型去尝试。关键区别在于：传统微服务中，断路器 Open 后调用方会收到一个异常，由上游服务决定如何处理。但在 Agent 场景中，断路器需要返回一个结构化信号给 Agent 的推理循环，而不是抛出一个异常让代码崩溃。
这个信号应该包含：
工具当前不可用（circuit_open） 预计恢复时间（retry_after） 可选的替代工具建议（fallback_suggestions）
Agent 收到这个信号后，可以决定等待重试、切换到备用工具，或者向用户报告工具不可用。这种设计把断路器的决策权交给了 Agent 的推理层，而不是让断路器在 Agent 不知情的情况下静默失败。
Half-Open 状态在 Agent 场景下也有特殊之处。传统断路器在 Half-Open 状态放行少量请求来探测恢复情况。Agent 场景中，Half-Open 状态下放行的请求应该具有较低的优先级——如果 Agent 同时有其他可用的工具完成相同任务，应该优先使用它们，只在必要时才尝试探测已恢复的工具。
按工具类型隔离的隔板架构
隔板模式的核心思想是：把资源池分割成独立的部分，一个部分的失败不会耗尽其他部分的资源。
对于 Agent 工具调用，隔板隔离需要关注三个维度：
并发隔离。每个工具或每组工具拥有独立的信号量或线程池。一个慢速工具最多占用自己池中的线程，不会抢占其他工具的执行槽位。比如搜索工具分配 5 个并发槽位，代码执行工具分配 2 个并发槽位，数据库查询工具分配 3 个并发槽位。当搜索工具全部槽位被占满时，后续的搜索请求排队等待，但数据库查询和代码执行不受影响。
超时隔离。每个工具拥有独立的超时配置。搜索引擎查询可以容忍 10 秒的超时，但文件读取操作应该 5 秒内完成，而 LLM 二次调用可能需要 30 秒。传统的"全局超时"设置在 Agent 场景下会带来一个矛盾：超时设置太短，长耗时工具频繁失败；设置太长，慢速工具阻塞整个 Agent。
错误域隔离。来自同一供应商或同一基础设施的工具应该被分到同一个错误域。如果一个云服务商的 API 全面故障，该域下的所有工具都应该同时切换到 Open 状态，而不是逐个失败再逐个探测。这需要断路器之间能够共享状态，而不是各自为政。
自适应限流与背压
工具调用隔离的另一个维度是限流。Agent 经常在短时间内生成大量工具调用——一个信息检索任务可能同时发起 10 个搜索查询，一个代码生成任务可能同时调用 5 个文件操作。
这里的关键问题是：Agent 框架应该用什么标准来决定限流阈值？
几个参考维度：
工具的 API 配额：如果工具底层 API 的每分钟请求上限是 100 次，Agent 框架应该在这个配额内分配执行槽位，而不是让模型无限制地调用直到触发 429。 工具的响应时间分布：如果一个工具的平均响应时间是 200ms，但偶尔出现 5 秒的延迟，限流器应该基于 P99 而不是平均值来设计排队深度。 Agent 的优先级：用户交互优先的 Agent 步骤应该比后台批处理步骤获得更高的工具调用优先级。这需要限流器支持优先级队列，而不是简单的 FIFO。
实现自适应限流的一种实用模式是：为每个工具维护一个滑动窗口计数器，记录最近 N 秒内的调用次数和失败次数。当窗口内的失败率或延迟超过阈值时，限流器自动降低该工具的并发上限，直到状态恢复。
降级策略与备用工具链
隔离和断路只是手段，最终目标是让 Agent 在部分工具不可用时仍然能完成任务。这就需要在架构层面预置降级策略。
降级策略可以分为几个层级：
参数降级。工具本身可用，但部分功能受限。比如搜索引擎返回结果较慢，但 Agent 可以接受减少搜索深度、缩短超时时间，换取更快的响应。这需要工具定义本身就支持可选参数，并且 Agent 的推理循环能够感知到"当前处于降级模式"。
语义降级。用不同的工具完成相同的语义任务。比如搜索引擎不可用时，切换到知识库检索；代码执行沙箱不可用时，切换到静态分析。这种降级要求工具注册时声明其语义能力（capability），而不是仅仅声明工具名称和参数。断路器的 Open 信号应该触发 Agent 的能力路由层去查找具有相同 capability 的备用工具。
人工降级。当所有自动降级路径都不可用时，Agent 应该向用户报告当前状态，而不是静默返回空结果或错误信息。这种降级报告应该包含：哪个工具不可用、尝试了哪些备用工具、当前任务可能受影响的范围。
实现时的工程细节
在具体实现中，有几个容易忽略但影响很大的细节。
断路器的状态持久化。Agent 会话可能持续数分钟甚至数小时。如果断路器状态只保存在内存中，一次进程重启就丢失了所有状态积累。对于高频调用的工具，可以考虑将断路器状态持久化到 Redis 或本地存储，让状态在 Agent 重启后仍然有效。
隔板大小与线程模型。Agent 框架的线程模型直接影响隔板的实现方式。异步框架（如 Python asyncio、Go goroutine）天然适合轻量级隔板，每个工具池可以是一个独立的协程组。同步框架则需要更重的线程池隔离，带来的上下文切换开销需要注意。
熔断信号的传递。断路器 Open 后，Agent 的下一次推理应该看到这个信号。实现方式有两种：一是通过异常或错误码在工具调用层传递，然后由 Agent 的推理循环处理；二是直接在系统提示词（system prompt）中注入当前工具的状态信息，让模型在规划时就知道哪些工具可用、哪些不可用。第二种方式更优雅，因为它让模型在决策阶段就避开不可用的工具，而不是在调用阶段才发现失败。
与重试策略的配合。断路器和重试是互补的，但配合不当会产生反效果。常见的错误是：重试逻辑在断路器 Open 后仍然尝试调用，导致断路器反复 Open-Close 震荡。正确的做法是：重试计数器应该在断路器 Open 时暂停，等到 Half-Open 探测成功后重置。
从工具级隔离到 Agent 级隔离
最后，隔离的粒度不应该止步于单工具。当多个 Agent 共享同一个工具集时，还需要 Agent 级别的隔离。
一个典型场景：同一个部署中运行着面向用户的 Agent 和后台管理的 Agent。面向用户的 Agent 对延迟敏感，后台 Agent 对吞吐量要求高。如果没有 Agent 级隔离，后台 Agent 的大量工具调用可能耗尽共享的线程池，导致用户 Agent 的调用排队。
实现 Agent 级隔离的方式是在现有工具隔离之上再加一层：每个 Agent 实例拥有独立的隔板配置，共享工具池的总容量在所有 Agent 之间按权重分配。这种两层隔离架构在资源利用率和故障隔离之间取得了更好的平衡。
从工程角度看，工具调用的断路和隔离不是锦上添花的功能，而是生产级 Agent 的基础设施。当 Agent 从原型走向生产，从单工具走向多工具集，从单实例走向多 Agent 协作时，没有这些隔离机制，系统的可靠性会随着工具数量的增加而指数级下降。这不是一个"以后再加"的问题，而是一个"一开始就要设计"的问题。
#AI应用架构 #AI应用开发 #Agent应用架构 #Agent应用开发
