概述
在前面的章节中，我们讨论了如何通过摘要压缩管理上下文，以及如何通过人工审批控制高风险操作。现在我们要解决另一个常见但很重要的问题：如何防止AI智能体无限调用模型或工具，导致成本失控或陷入死循环。
有时候，AI智能体可能会因为理解错误、逻辑问题或者其他原因，不停地调用模型或工具，就像陷入了死循环。这不仅会消耗大量资源，产生巨额费用，还可能导致系统负载过高，影响正常使用。
调用次数限制中间件就是为了防止这种情况发生。通过设置调用次数的上限，一旦超过限制就停止执行，有效控制成本和风险。
使用场景
成本控制
在按调用次数或token计费的场景下，防止因为意外情况导致费用激增。
防止死循环
当AI智能体的逻辑出现问题时，防止无限循环调用，避免系统资源耗尽。
资源管理
在多租户或共享资源的场景下，合理分配资源，防止单个任务占用过多资源。
核心功能需求
两个维度的限制
我们需要从两个维度来控制调用次数：Run级别和Thread级别。
Run级别（单次调用限制）
Run指的是用户发起一次请求，AI智能体处理并返回结果这一完整流程。这是AI智能体交互的最小单元。
- 定义：从用户发起一次请求开始，到AI智能体返回结果结束
- 特点：每次调用后自动重置计数
- 用途：控制单次请求的资源消耗，防止单次请求占用过多资源
产品建议：建议为所有场景都设置Run级别的限制，这是一个安全底线。可以根据任务的复杂度设置不同的限制，简单任务3-5次，复杂任务10-20次。
Thread级别（线程级限制）
Thread指的是同一场连续的对话或任务流程，包含多轮用户请求和AI响应。
- 定义：从用户发起第一个任务开始，到对话结束为止的整个会话过程
- 特点：跨多轮Run持续累计计数，需要依赖状态保存机制
- 用途：控制整场对话的总资源消耗，防止长时间对话成本过高
产品建议：对于需要长期对话的场景，建议设置Thread级别的限制。可以根据业务场景设置，比如客服对话可以设置更高，数据分析任务可以设置较低。
限制触发后的行为
当达到调用次数上限后，我们需要决定系统如何响应。
优雅终止（end）
- 行为：停止执行，向用户返回友好的提示信息，说明已达到调用次数限制
- 优点：用户体验好，不会看到技术错误
- 适用场景：大多数生产场景
抛出异常（error）
- 行为：直接抛出异常，停止执行
- 优点：便于测试和调试，可以及时发现问题
- 适用场景：开发测试环境
产品建议：生产环境建议使用优雅终止，给用户返回友好提示；开发测试环境可以使用抛出异常，便于发现问题。
PRD需求描述
功能需求
FR-1: Run级别调用限制
- 描述：限制单次请求中模型或工具的最大调用次数
- 配置方式：可配置，支持为不同场景设置不同的限制
- 重置机制：每次新请求自动重置计数
- 优先级：P0（核心功能）
FR-2: Thread级别调用限制
- 描述：限制同一场对话中模型或工具的总调用次数
- 配置方式：可配置，需要依赖状态保存机制
- 累计机制：跨多轮请求持续累计计数
- 优先级：P0（核心功能）
FR-3: 限制触发处理
- 描述：当达到调用次数上限时，执行预设的处理策略
- 处理策略：支持优雅终止和抛出异常两种方式
- 用户提示：优雅终止时需要返回友好的提示信息
- 优先级：P0（核心功能）
FR-4: 限制类型区分
- 描述：支持分别限制模型调用次数和工具调用次数
- 模型限制：控制对LLM的调用次数
- 工具限制：控制工具调用的次数（需要使用ToolCallLimitMiddleware）
- 优先级：P0（核心功能）
非功能需求
NFR-1: 状态管理
- Thread级别限制：需要依赖状态保存机制（Checkpointer）才能生效
- 状态持久化：生产环境需要支持状态持久化，确保限制计数准确
NFR-2: 监控与告警
- 限制触发监控：记录每次触发限制的详细信息（触发时间、调用次数、请求内容等）
- 告警机制：当频繁触发限制时，发送告警通知，可能需要优化AI智能体逻辑或调整限制值
NFR-3: 异常处理
- 用户友好提示：限制触发时，给用户返回友好的提示信息，避免暴露技术细节
- 日志记录：记录详细的异常日志，便于后续排查问题原因
产品设计要点
限制值设置建议
Run级别限制：
- 开发阶段：建议先设置较小的值（3-5次），快速发现是否存在逻辑问题
- 生产环境：根据任务复杂度设置，简单任务3-5次，复杂任务10-20次
Thread级别限制：
- 客服对话：可以设置较高（50-100次），因为需要多轮交互
- 数据分析任务：可以设置较低（20-30次），因为通常是单次任务
- 复杂工作流：根据实际需要设置
限制优先级
如果同时设置了Run级别和Thread级别的限制，以先触发的为准。比如：
- Run限制：5次
- Thread限制：10次
- 如果单次Run就调用了6次，会在第6次触发Run限制，不会等到Thread限制
产品建议：建议同时设置两个级别的限制，既控制单次请求的风险，又控制整场对话的成本。
异常处理设计
用户提示信息：
- 不应该暴露技术细节（如"ModelCallLimitExceededError"）
- 应该友好、清晰，比如"抱歉，此次请求处理时间较长，请稍后重试或简化您的问题"
- 可以提供解决建议，如"您可以尝试将问题拆分成多个小问题"
日志记录：
- 记录触发限制的详细信息
- 记录AI智能体的执行路径，便于分析为什么触发了限制
- 如果是逻辑问题导致的，需要及时修复
使用建议
什么时候应该使用
- 成本敏感场景：按调用次数计费，需要严格控制成本
- 防止死循环：AI智能体的逻辑可能存在问题，需要设置安全底线
- 资源限制：系统资源有限，需要防止单个任务占用过多资源
配置建议
- 开发阶段：设置较小的限制值，快速发现问题
- 生产环境：根据实际业务需求设置合理的限制值
- 监控告警：设置告警，当频繁触发限制时及时通知
注意事项
- 区分模型限制和工具限制：ModelCallLimitMiddleware只限制模型调用，如果需要限制工具调用，需要使用ToolCallLimitMiddleware
- Thread限制需要状态保存：Thread级别的限制需要配置Checkpointer，否则无法跨请求累计
- 限制值需要平衡：设置太小可能影响正常使用，设置太大起不到保护作用
与其他中间件的配合
调用次数限制可以与其他中间件配合使用：
- 与Human-in-the-loop配合：人工审批通过后，调用才计入限制
- 与RetryMiddleware配合：重试次数不计入调用限制，避免因重试导致误触发限制
- 与FallbackMiddleware配合：模型回退到备用模型时，调用次数也会计入限制
后续优化方向
- 动态限制调整：根据历史数据和业务情况，动态调整限制值
- 分级限制：不同用户或不同场景可以设置不同的限制值
- 限制预测：根据当前执行情况，预测是否会触发限制，提前提醒用户
- 智能优化建议：当触发限制时，分析原因并给出优化建议