上周五晚上十一点多我被手机告警吵醒。运营那边用的商品描述 Agent在十分钟里调用“批量改价”工具改了一百多个 SKU其中有一半的价格被改成了 0.01 元。模型本身没有问题是 Agent 在循环里“自己理解”错了业务指令然后把动作执行了下去。幸好那套工具调用层有配额限制跑到第五分钟就被熔断切断了不然第二天早上整个店铺都得挂上“清仓大甩卖”的横幅。那是我第一次真正意识到AI Agent 这东西不是“聪明不聪明”的问题而是“有没有兜底”的问题。提示词写得再严谨模型在长对话里也会跑偏工具权限设计得再细Agent 在连锁调用中也会做出超出预期的操作。所以后来我在所有内部项目里都加了一道真正的“保险丝”——一套独立于模型之外的熔断、限流、校验机制。这篇文章就把我这几个月摸出来的方案、踩过的坑、调过的参数完整地摊开讲一遍。适合正在做 Agent 应用开发、搭建企业内部 Agent 平台、或者被领导一句“给 Agent 上个安全方案”砸到头上的朋友。1. Agent 失控不是概率题先看清它会怎么坏掉在动手写代码之前我先把过往线上事故翻了一遍梳理出了三类最典型的失控场景。只有知道 Agent 会怎么坏才知道保险丝该往哪里装。1.1 成本失控循环调用烧钱这是最隐蔽、也最常见的一种失控。Agent 在执行一个任务时会自主决定下一步调用什么工具、调用几次。如果任务目标不清晰或者工具返回的结果总是打不到模型预期的状态Agent 就会陷入一种“思考—调用—再思考—再调用”的循环。经典案例是一个负责生成商品描述的 Agent每生成一段文字就要调一次词向量模型做相似度校验校验通过不了就重新生成连着跑了二十分钟。等到告警拉起来的时候token 费用已经烧掉了几百块。这里面的根源不是模型笨而是循环缺少退出条件。我们在开发时关注的是“单次调用要花多少钱”很少去想“这个 Agent 单次任务最多允许调用多少次工具”。但只要把视角从单次调用拉到任务粒度就会发现问题非常普遍——一个 Agent 任务里出现十几次甚至几十次内部调用在整个行业都是常态。1.2 内容失控自信的幻觉输出第二类失控发生在输出侧。客服 Agent 对用户说“我可以直接帮你办理退款不需要走审核流程”营销文案 Agent 在生成的海报语里写出了违禁词技术文档 Agent 在回答里编造了一个不存在的 API 参数。这些并不是小概率事件我在内部测试里统计过一个经过精心调教的 Agent在不加任何输出校验的情况下运行一百轮大约会有三到五轮产生明显的事实偏差或违规内容。问题在于大模型的本质是概率模型它生成每个 token 都是在猜“下一个最合适的词”而不是在严格遵循规则。你把“不能承诺退款时限”写在系统提示词里它大概率会遵守但一定不是百分之百遵守。这种概率性的服从在 C 端对话里勉强能用在涉及真金白银、合规红线、用户隐私的业务场景里完全不够。1.3 权限失控工具就是 Agent 伸出去的手第三类失控最致命。Agent 本身不会犯错但工具会放大它的错误。经典的场景是为了对接报表需求给 Agent 开放了一个“查询订单”工具结果这个工具内部直接接了数据库权限粒度大到可以拉全量用户手机号。有一次 Agent 在生成运营周报的时候“顺手”把用户数据写进了一个临时文件然后交给了数据分析工具处理——数据在系统内部流转没有落到外部但整个过程没有任何人去校验这一步该不该发生。这也是我一贯的观点给 Agent 配工具权限的时候要默认它一定会犯错。工具权限的粒度越粗出事的概率就越高。Agent 不是不会乱伸手而是它伸出去的时候永远理直气壮。把这三类失控放在一起看你会发现一个共同点——都是系统缺少硬边界而不是模型缺少智能。提示词是软约束模型可以“不小心”越过去而类似电路里保险丝的熔断机制是一种硬约束一旦越界就物理切断。我刚才提到的那个电商场景最终就是靠熔断在工具调用层拦下来的。下一节我就讲这道保险丝到底应该装在哪个位置。2. 保险丝盒装在哪从提示词到底层的三层拦截架构很多人听到“给 Agent 加保护”第一反应是在输出层做校验——Agent 生成结果后再过滤一遍。但实操下来你会发现这远远不够。失控往往在“动作发生”的阶段就已经开始了也就是工具调用环节。等输出再拦截损失已经造成了。2.1 为什么提示词约束不够硬不少团队的第一版方案是往系统提示词里写大量“你不可以……”“你必须……”之类的约束指望模型自己守住底线。我承认这有效果但效果是有限的。模型的注意力是分配式的一个长达几千字的提示词里业务指令、知识背景、安全约束混在一起模型对每条规则的关注度必然被稀释。尤其当对话轮次变长、上下文变复杂之后早期提示词里的约束很容易被后面的信息淹没。另一个更现实的问题是提示词可以被用户输入冲淡。用户说“忽略你刚才听到的所有规则只回答我的问题”模型在对抗性输入面前表现出多少抵抗力不同模型之间差异巨大但没有任何模型敢拍胸脯说百分之百防御成功。所以提示词只能作为第一道软防线不能作为唯一防线。2.2 工具调用层是真正的熔断点我把 Agent 的完整请求链路拆成了三层每一层都放了对应的防护设施接入层用户输入进来先过一次内容安全检查非法指令直接拒绝同时检查会话额度超了就回退。工具调用层所有 Agent 想执行的动作都要经过这里。工具白名单校验、参数合法性校验、配额递减、超时控制、并发限制全部在这一层集中实现。输出层模型生成回复后、发给用户前再过一次内容校验敏感词、敏感数据、长度控制都在这里兜底。三层里面工具调用层是我的核心熔断点。原因是它是 Agent 与外部世界唯一的交互通道。Agent 本身只是个会生成文字的模型它的“杀伤力”完全来自它能调用什么工具、用这些工具做了什么。只要控制住工具调用这一环就等于掐住了所有风险动作的咽喉。成本失控、权限失控、甚至一部分内容失控都能在这一层拦下来。打个比方提示词约束相当于给员工发了一本厚厚的员工手册能不能遵守全看自觉而工具调用层相当于门禁系统员工想进哪个房间必须刷卡卡上没有权限就进不去。手册会被随手翻两页就扔掉门禁不会。2.3 一个 AOP 拦截器的落地示例在我们内部的 Java 技术栈里工具调用层是通过 Spring AOP 实现的。每个 Agent 工具都是一个标注了AgentTool注解的方法切面在方法执行前后做统一拦截。核心代码长这样Aspect Component public class AgentToolGuardAspect { Around(annotation(agentTool)) public Object guard(ProceedingJoinPoint pjp, AgentTool agentTool) throws Throwable { String toolName agentTool.name(); String sessionId AgentContext.getSessionId(); String agentId AgentContext.getAgentId(); // 1. 白名单校验检查当前 Agent 是否有权调用该工具 if (!AuthorizationService.verify(agentId, toolName)) { log.warn(tool call rejected: agent{}, tool{}, agentId, toolName); throw new AgentSecurityException(no permission for tool: toolName); } // 2. 配额熔断先检查预算再决定是否执行 if (!QuotaService.consume(agentId, sessionId, toolName)) { log.warn(quota exceeded: agent{}, tool{}, agentId, toolName); throw new AgentQuotaException(tool quota exceeded: toolName); } // 3. 超时熔断定义工具的超时时间 long timeoutMs agentTool.timeoutMs(); Object result executeWithTimeout(pjp, timeoutMs); // 4. 结果大小控制防止工具返回超大数据撑爆上下文 if (sizeOf(result) agentTool.maxResultSize()) { throw new AgentDataLimitException(tool result too large: toolName); } return result; } }这套设计有两个好处。第一对业务开发透明新加一个 Agent 工具只需要写好业务逻辑、加上注解不需要关心安全逻辑第二所有熔断逻辑沉淀在统一位置出问题时只需要查一个类不需要在几十个工具方法里大海捞针。我自己的体会是AOP 这套方案特别适合已有 Spring Boot 基础的项目。如果你的技术栈不是 Java也没关系核心思路是通用的把所有工具调用放到一个统一网关里网关负责检查、限流、熔断而不是让每个工具方法自己去操心安全。这是这整套方案最核心的一步后面几节的内容都是在这层网关之上做文章。3. 成本与配额的熔断阈值给 Agent 装上流量计有了熔断点下一步是确定熔断条件。我最早犯的错误是拍脑袋定阈值——觉得“一次任务最多调 20 次工具应该够了吧”结果上线第一天就被打脸。后来我把配额设计拆成三个维度并引入了一个简单的计算逻辑。3.1 配额监控的三个维度单一维度的配额很难兼顾所有场景。一个全局的每日调用上限拦不住某个 Agent 单次任务里的循环失控一个会话级的调用上限又管不住某个业务方整体滥用。我最终落地的是一套三层配额体系配额维度监控对象参考指标熔断动作会话级单次任务的工具调用次数默认 20 次/会话复杂任务可放宽到 40 次中止当前会话返回“任务过于复杂请拆分成多步”记录日志Agent 级单 Agent 的并发会话数与累计调用量并发 5 个会话token 周消耗上限根据历史 P99 反推新会话排队等待超过预算立刻熔断租户级每个业务方团队的总额度按季度预算折算到天全部 Agent 降级为只读模式或拒绝服务通知负责人把配额拆成三层的原因很实际不同业务方的 Agent 会互相影响运营组那边一个失控的 Agent 不应该把客服组这边的额度也拖垮。租户级配额就像是一栋楼的总电闸Agent 级配额是楼层配电箱会话级配额才是插线板上的保险丝——越靠近负载端熔断越要及时。3.2 阈值怎么定用历史数据说话我们第一个版本的会话级调用次数上限定的是 50 次结果有正常业务也要反复调工具十几次反而把正常的复杂任务误杀了。后来我换了方法翻了一周的历史 Agent 调用日志把所有会话的工具调用次数按从低到高排序取 P99 分位数——也就是 99% 的正常任务都在这个值以内。算出来是 18 次。于是我把阈值定在 25 次留出一定余量既不会误杀正常任务也能拦截掉那些循环了几十次的失控场景。这个思路是所有阈值设定的通用方法不要去猜一个数字从历史数据里找分布然后在分位数上留余量。成本阈值也是一样token 消耗上限就取过去一周正常任务中单会话消耗的 P99 值再乘 1.5。如果历史数据里没有这类指标那就现设一个保守值跑两周之后再根据日志调整。我见过太多团队把阈值当一次性决策设完就不管了这是不行的——阈值是活的要跟着业务数据走。3.3 超限之后怎么办降级与兜底熔断不是把请求一扔了事而是要有后续动作。我的处理逻辑分成三档会话级超限返回兜底结果告诉调用方“当前任务需要拆分成更小的步骤”并不算系统错误。Agent 级超限让新会话排队而不是直接拒绝。排队时间超过 30 秒再拒绝避免用户体感太差。租户级超限直接进入只读模式。所有写操作类的工具改价、发消息、删数据一律禁止只保留查询类能力同时第一时间通知到租户管理员。降级处理做好了熔断才不是“一刀切”而是“精细切”。我之前看到很多项目把熔断做成全有或全无结果熔断一开所有 Agent 全部失效业务方炸锅。后来才意识到熔断的粒度一定要细细到工具级别、会话级别而不是整站级别。4. 输出内容校验让保险丝能挡住坏话配额熔断解决的是“动作失控”但还有一个问题是“说话失控”。Agent 生成了一段不合规的回复哪怕没有动任何工具发到用户面前也是事故。这一层靠的是输出内容校验我把它拆成了两道闸。4.1 规则引擎做第一道闸第一道闸是确定性规则引擎处理的是“一定违规”的内容。比如违规类型检测规则处置策略敏感词命中行业敏感词库比对整句替换为“抱歉我暂时无法回答”个人数据泄漏手机号、身份证、银行卡号正则匹配输出脱敏处理保留前缀后缀外部链接检测 URL 格式与域名黑名单拦截并提示用户联系人工诱导性语句关键词组合匹配如“返现”“私下转账”整段回复拦截并告警规则引擎的好处是快一毫秒级别而且结果完全确定。正则写对了就绝对不会漏。坏处是覆盖不了“看起来合规但实际越界”的内容比如 Agent 用间接话术暗示用户可以绕过流程这种语义级违规规则引擎很难抓。4.2 模型分类器做第二道闸第二道闸是一个轻量级的内容安全分类模型专门做语义级判断。输入是 Agent 生成的完整回复输出是“安全”或“违规”的概率分数。当违规概率超过 0.8 时直接拦截在 0.5 到 0.8 之间时进入人工复核队列。分类模型的选型不需要很大我用的是一个蒸馏过的小模型单次推理在 CPU 上不到 50 毫秒对线上延迟影响可以忽略。有朋友问过我为什么不直接用一个更强的模型来做第二道闸我的原因是成本和稳定性的考虑。大模型在内容审核上确实更准但推理延迟高、成本高而且模型本身也是概率性的反而引入新的不确定性。分类器的输出是稳定的概率值配合阈值策略行为可预期更适合作为熔断机制的一部分。大模型适合做“抽样复核”不适合做“全量防线”。4.3 一个更隐蔽的坑中间推理泄漏输出校验做得再严也拦不住一种特殊情况Agent 在工具调用的参数里就泄露了敏感信息。比如生成周报时模型把用户手机号直接填进了“导出文件名”参数里这个参数被工具执行、被日志记录、被链路追踪系统持久化。输出层校验看到的是给用户的最终回复根本拦不住这个过程。这个坑我踩过一次之后把敏感数据扫描前移到了工具调用层。规则不只在输出层跑一遍在工具调用参数上也要跑一遍。凡是参数里出现手机号、身份证号、银行卡号等模式直接熔断这次调用阻止动作发生。现在我对团队的要求是内容校验不是一个独立环节而是接入层、工具调用层、输出层三层各跑一遍宁可多花几个毫秒的算力也不放过一条泄漏链路。5. 超时、并发与线程隔离把失控 Agent 关进沙箱前两节解决的是“Agent 乱花钱”“Agent 说错话”这一节解决的是“Agent 卡住了”。这种失控没有表面上的破坏性但它同样致命——一个 Agent 会话阻塞可能拖垮整个服务的线程池让所有其他业务一起遭殃。5.1 超时熔断所有调用都要有“死刑时间”Agent 卡住最常见的原因是外部依赖没有按时返回。模型 API 接口在高峰期延迟飙升某个工具调用的第三方接口一直不响应如果调用的超时时间设置得太大线程就被永久占用。我把所有外部调用的超时时间统一设成三档调用类型超时时间超时后的动作模型 API 调用30 秒中断本次生成返回“生成超时请重试”单个工具调用60 秒熔断该工具 5 分钟返回“工具暂不可用”整个 Agent 会话180 秒强制终止会话记录完整调用链日志有人会觉得 30 秒是不是太短了有些复杂任务确实需要更长的生成时间。我的处理办法是区分场景普通对话任务模型调用 30 秒深度分析类任务可以放到 60 秒但必须显式标识出来而不是所有任务一刀切。任何调用都应该有一个明确的“死刑时间”到了时间就死绝不无限等待。这是线程安全最基本的底线。5.2 线程池隔离别让一个 Agent 拖垮全部单纯的超时控制只能防止线程被永久占用但挡不住另一个问题某个业务方的 Agent 并发量爆发把整个应用的所有线程都吃光。解决这个问题的核心是线程池隔离——不同业务方、不同优先级的 Agent分配到不同的线程池里跑。我用 Spring 的ThreadPoolTaskExecutor做隔离配置每个业务方建一个独立线程池。比如运营组的线程池核心线程数 10最大 20客服组的核心线程数 20最大 50。两个池子互不共享运营组那边 Agent 并发再高也只是运营组自己的请求排队客服组的线程资源不会受影响。这就像食堂开了几个窗口一个窗口前面排队的人再多另一个窗口照样能打饭。不过线程池隔离真正落地的时候有个细节要注意调用链的上下文传递。Agent 的会话 ID、租户 ID 等信息要通过TaskDecorator显式地传到子线程里否则异步执行后这些信息就丢了会直接导致熔断逻辑找不到是哪个会话触发的。这个坑我在联调阶段排查了整整一天问题的表象是配额失效本质是线程切换丢掉了上下文。5.3 并发信号量限制 Agent 同时伸出多少只手线程池隔离管住了不同业务方之间的影响但还没管住同一个 Agent 内部的并发。模型在自主规划时可能会一次性发起多个工具调用——比如同时查询库存、查询价格、查询物流——如果这个 Agent 本身就处于失控状态这些并发调用会像触手一样伸向四面八方。我用信号量Semaphore限制每个会话同时最多发起 3 个工具调用多余的调用排队等待。这个限制对正常任务完全够用因为规划合理的 Agent 很少需要同时开太多并发的工具调用而失控状态下这个限制能显著降低单位时间内的动作数量给熔断提供反应窗口。6. 熔断之后的恢复与复盘保险丝记录就是事故现场保险丝熔断本身不是目的熔断之后的恢复、修复、防止同类事故再次发生才是完整闭环。我这一节完全是从实际运维中总结出来的参考了断路器模式的思路但根据自己的场景做了不少调整。6.1 恢复策略半开状态才是安全的试探熔断不是一个永久状态否则服务就退化了。但如果熔断后立刻全量恢复也没有意义——问题还没解决恢复只会再次熔断形成抖动。我的做法是引入“半开状态”熔断状态熔断器打开所有请求快速失败不进入实际逻辑。半开状态熔断持续 60 秒后放少量请求比如 10%进去试探看是否再次触发熔断条件。关闭状态试探期内没有再次熔断逐步恢复全量流量。半开状态实现起来其实很简单就是一个原子变量存状态加上一个定时任务做状态流转。我不建议在这个环节引入太复杂的框架一个简单的状态机足够用。这里唯一要强调的是半开状态的试探流量必须走真实链路不能用假请求替代。只有真实的业务流量才能反映出真实的问题是否已经解决。6.2 熔断告警与人工介入机制熔断器打开的时候光靠“静默处理”是不够的一定要告警出来。我发的告警消息里包含这样几项内容Agent ID、会话 ID、触发熔断的指标名称是调用次数超限还是超时还是输出违规、当前指标值、以及最近的几次工具调用记录。有了这些信息值班的人不需要再去日志里翻找直接就能判断这是偶发还是系统性故障。特别要加一条同一会话在 5 分钟内触发过 2 次熔断就不再自动恢复必须人工确认。因为连续熔断说明该会话代理处于一种持续的不稳定状态自动恢复只会造成反复熔断的抖动。人工介入的方式比较轻——把会话标记为异常状态通知对应业务方负责人让他们在 Admin 后台查看这个会话的完整调用链判断是要强行终止还是允许继续。这套机制上线后凌晨被熔断告警吵醒的次数明显少了因为大多数问题在半开阶段就被挡住了真正需要人工的往往都是新的故障模式。6.3 保险丝记录每一次熔断都是一次体检最后聊一个我特别在意的点——熔断日志的价值。很多人把熔断日志当作“故障记录”存下来就不管了但在我看来每一次熔断都是系统给我们递上来的一张体检单。它精准地暴露了 Agent 在什么场景下、因为什么原因、在哪个环节出了偏差。我每两周会拉一次全量熔断日志做复盘按触发原因分组统计。做过几轮之后你会发现一些有意思的规律某类 Agent 总是在长对话的第十轮以后开始出现工具调用次数激增某类工具在高峰期总是超时某类指令在接入层总被用户绕过去。针对这些规律做定向优化效果远比写一套更完美的提示词来得好。比如我们发现客服 Agent 的循环调用大多出现在用户反复表达不满意的场景于是在接入层加了一个“情绪降级”逻辑——当用户连续三次给出不满意反馈时直接转人工不再让 Agent 继续尝试。这个改动之后客服 Agent 的熔断率下降了 80% 还多。熔断体系上线到现在我最大的体会是这套东西不是为了让 Agent 更聪明而是为了让 Agent 失控的成本有上限。AI 模型本身是不可控的但我们可以通过工程手段把不可控的范围圈定在一个“即使出错也不会出大事”的边界里。就像电路不会因为一道保险丝而变得更高效但少了保险丝再好的电路也有被烧毁的风险。如果你也在做 Agent 相关的东西我的建议是不要等到出一次事故再动手。先给工具调用层加一个最基础的计数熔断哪怕阈值先放得宽一点至少让失控跑不远然后逐步补上超时、隔离、输出校验这些环节。我踩过最大的坑就是一开始追求“完美方案”想一次性把所有保护都做完结果光设计就拖了两周最后被事故逼着上线了一个简单的计数版本——反而那个简单版本拦截掉了第一波真正的问题。保护机制不怕糙就怕没有。先把保险丝装上再慢慢调粗细。
上周五晚上十一点多我被手机告警吵醒。运营那边用的商品描述 Agent在十分钟里调用“批量改价”工具改了一百多个 SKU其中有一半的价格被改成了 0.01 元。模型本身没有问题是 Agent 在循环里“自己理解”错了业务指令然后把动作执行了下去。幸好那套工具调用层有配额限制跑到第五分钟就被熔断切断了不然第二天早上整个店铺都得挂上“清仓大甩卖”的横幅。那是我第一次真正意识到AI Agent 这东西不是“聪明不聪明”的问题而是“有没有兜底”的问题。提示词写得再严谨模型在长对话里也会跑偏工具权限设计得再细Agent 在连锁调用中也会做出超出预期的操作。所以后来我在所有内部项目里都加了一道真正的“保险丝”——一套独立于模型之外的熔断、限流、校验机制。这篇文章就把我这几个月摸出来的方案、踩过的坑、调过的参数完整地摊开讲一遍。适合正在做 Agent 应用开发、搭建企业内部 Agent 平台、或者被领导一句“给 Agent 上个安全方案”砸到头上的朋友。1. Agent 失控不是概率题先看清它会怎么坏掉在动手写代码之前我先把过往线上事故翻了一遍梳理出了三类最典型的失控场景。只有知道 Agent 会怎么坏才知道保险丝该往哪里装。1.1 成本失控循环调用烧钱这是最隐蔽、也最常见的一种失控。Agent 在执行一个任务时会自主决定下一步调用什么工具、调用几次。如果任务目标不清晰或者工具返回的结果总是打不到模型预期的状态Agent 就会陷入一种“思考—调用—再思考—再调用”的循环。经典案例是一个负责生成商品描述的 Agent每生成一段文字就要调一次词向量模型做相似度校验校验通过不了就重新生成连着跑了二十分钟。等到告警拉起来的时候token 费用已经烧掉了几百块。这里面的根源不是模型笨而是循环缺少退出条件。我们在开发时关注的是“单次调用要花多少钱”很少去想“这个 Agent 单次任务最多允许调用多少次工具”。但只要把视角从单次调用拉到任务粒度就会发现问题非常普遍——一个 Agent 任务里出现十几次甚至几十次内部调用在整个行业都是常态。1.2 内容失控自信的幻觉输出第二类失控发生在输出侧。客服 Agent 对用户说“我可以直接帮你办理退款不需要走审核流程”营销文案 Agent 在生成的海报语里写出了违禁词技术文档 Agent 在回答里编造了一个不存在的 API 参数。这些并不是小概率事件我在内部测试里统计过一个经过精心调教的 Agent在不加任何输出校验的情况下运行一百轮大约会有三到五轮产生明显的事实偏差或违规内容。问题在于大模型的本质是概率模型它生成每个 token 都是在猜“下一个最合适的词”而不是在严格遵循规则。你把“不能承诺退款时限”写在系统提示词里它大概率会遵守但一定不是百分之百遵守。这种概率性的服从在 C 端对话里勉强能用在涉及真金白银、合规红线、用户隐私的业务场景里完全不够。1.3 权限失控工具就是 Agent 伸出去的手第三类失控最致命。Agent 本身不会犯错但工具会放大它的错误。经典的场景是为了对接报表需求给 Agent 开放了一个“查询订单”工具结果这个工具内部直接接了数据库权限粒度大到可以拉全量用户手机号。有一次 Agent 在生成运营周报的时候“顺手”把用户数据写进了一个临时文件然后交给了数据分析工具处理——数据在系统内部流转没有落到外部但整个过程没有任何人去校验这一步该不该发生。这也是我一贯的观点给 Agent 配工具权限的时候要默认它一定会犯错。工具权限的粒度越粗出事的概率就越高。Agent 不是不会乱伸手而是它伸出去的时候永远理直气壮。把这三类失控放在一起看你会发现一个共同点——都是系统缺少硬边界而不是模型缺少智能。提示词是软约束模型可以“不小心”越过去而类似电路里保险丝的熔断机制是一种硬约束一旦越界就物理切断。我刚才提到的那个电商场景最终就是靠熔断在工具调用层拦下来的。下一节我就讲这道保险丝到底应该装在哪个位置。2. 保险丝盒装在哪从提示词到底层的三层拦截架构很多人听到“给 Agent 加保护”第一反应是在输出层做校验——Agent 生成结果后再过滤一遍。但实操下来你会发现这远远不够。失控往往在“动作发生”的阶段就已经开始了也就是工具调用环节。等输出再拦截损失已经造成了。2.1 为什么提示词约束不够硬不少团队的第一版方案是往系统提示词里写大量“你不可以……”“你必须……”之类的约束指望模型自己守住底线。我承认这有效果但效果是有限的。模型的注意力是分配式的一个长达几千字的提示词里业务指令、知识背景、安全约束混在一起模型对每条规则的关注度必然被稀释。尤其当对话轮次变长、上下文变复杂之后早期提示词里的约束很容易被后面的信息淹没。另一个更现实的问题是提示词可以被用户输入冲淡。用户说“忽略你刚才听到的所有规则只回答我的问题”模型在对抗性输入面前表现出多少抵抗力不同模型之间差异巨大但没有任何模型敢拍胸脯说百分之百防御成功。所以提示词只能作为第一道软防线不能作为唯一防线。2.2 工具调用层是真正的熔断点我把 Agent 的完整请求链路拆成了三层每一层都放了对应的防护设施接入层用户输入进来先过一次内容安全检查非法指令直接拒绝同时检查会话额度超了就回退。工具调用层所有 Agent 想执行的动作都要经过这里。工具白名单校验、参数合法性校验、配额递减、超时控制、并发限制全部在这一层集中实现。输出层模型生成回复后、发给用户前再过一次内容校验敏感词、敏感数据、长度控制都在这里兜底。三层里面工具调用层是我的核心熔断点。原因是它是 Agent 与外部世界唯一的交互通道。Agent 本身只是个会生成文字的模型它的“杀伤力”完全来自它能调用什么工具、用这些工具做了什么。只要控制住工具调用这一环就等于掐住了所有风险动作的咽喉。成本失控、权限失控、甚至一部分内容失控都能在这一层拦下来。打个比方提示词约束相当于给员工发了一本厚厚的员工手册能不能遵守全看自觉而工具调用层相当于门禁系统员工想进哪个房间必须刷卡卡上没有权限就进不去。手册会被随手翻两页就扔掉门禁不会。2.3 一个 AOP 拦截器的落地示例在我们内部的 Java 技术栈里工具调用层是通过 Spring AOP 实现的。每个 Agent 工具都是一个标注了AgentTool注解的方法切面在方法执行前后做统一拦截。核心代码长这样Aspect Component public class AgentToolGuardAspect { Around(annotation(agentTool)) public Object guard(ProceedingJoinPoint pjp, AgentTool agentTool) throws Throwable { String toolName agentTool.name(); String sessionId AgentContext.getSessionId(); String agentId AgentContext.getAgentId(); // 1. 白名单校验检查当前 Agent 是否有权调用该工具 if (!AuthorizationService.verify(agentId, toolName)) { log.warn(tool call rejected: agent{}, tool{}, agentId, toolName); throw new AgentSecurityException(no permission for tool: toolName); } // 2. 配额熔断先检查预算再决定是否执行 if (!QuotaService.consume(agentId, sessionId, toolName)) { log.warn(quota exceeded: agent{}, tool{}, agentId, toolName); throw new AgentQuotaException(tool quota exceeded: toolName); } // 3. 超时熔断定义工具的超时时间 long timeoutMs agentTool.timeoutMs(); Object result executeWithTimeout(pjp, timeoutMs); // 4. 结果大小控制防止工具返回超大数据撑爆上下文 if (sizeOf(result) agentTool.maxResultSize()) { throw new AgentDataLimitException(tool result too large: toolName); } return result; } }这套设计有两个好处。第一对业务开发透明新加一个 Agent 工具只需要写好业务逻辑、加上注解不需要关心安全逻辑第二所有熔断逻辑沉淀在统一位置出问题时只需要查一个类不需要在几十个工具方法里大海捞针。我自己的体会是AOP 这套方案特别适合已有 Spring Boot 基础的项目。如果你的技术栈不是 Java也没关系核心思路是通用的把所有工具调用放到一个统一网关里网关负责检查、限流、熔断而不是让每个工具方法自己去操心安全。这是这整套方案最核心的一步后面几节的内容都是在这层网关之上做文章。3. 成本与配额的熔断阈值给 Agent 装上流量计有了熔断点下一步是确定熔断条件。我最早犯的错误是拍脑袋定阈值——觉得“一次任务最多调 20 次工具应该够了吧”结果上线第一天就被打脸。后来我把配额设计拆成三个维度并引入了一个简单的计算逻辑。3.1 配额监控的三个维度单一维度的配额很难兼顾所有场景。一个全局的每日调用上限拦不住某个 Agent 单次任务里的循环失控一个会话级的调用上限又管不住某个业务方整体滥用。我最终落地的是一套三层配额体系配额维度监控对象参考指标熔断动作会话级单次任务的工具调用次数默认 20 次/会话复杂任务可放宽到 40 次中止当前会话返回“任务过于复杂请拆分成多步”记录日志Agent 级单 Agent 的并发会话数与累计调用量并发 5 个会话token 周消耗上限根据历史 P99 反推新会话排队等待超过预算立刻熔断租户级每个业务方团队的总额度按季度预算折算到天全部 Agent 降级为只读模式或拒绝服务通知负责人把配额拆成三层的原因很实际不同业务方的 Agent 会互相影响运营组那边一个失控的 Agent 不应该把客服组这边的额度也拖垮。租户级配额就像是一栋楼的总电闸Agent 级配额是楼层配电箱会话级配额才是插线板上的保险丝——越靠近负载端熔断越要及时。3.2 阈值怎么定用历史数据说话我们第一个版本的会话级调用次数上限定的是 50 次结果有正常业务也要反复调工具十几次反而把正常的复杂任务误杀了。后来我换了方法翻了一周的历史 Agent 调用日志把所有会话的工具调用次数按从低到高排序取 P99 分位数——也就是 99% 的正常任务都在这个值以内。算出来是 18 次。于是我把阈值定在 25 次留出一定余量既不会误杀正常任务也能拦截掉那些循环了几十次的失控场景。这个思路是所有阈值设定的通用方法不要去猜一个数字从历史数据里找分布然后在分位数上留余量。成本阈值也是一样token 消耗上限就取过去一周正常任务中单会话消耗的 P99 值再乘 1.5。如果历史数据里没有这类指标那就现设一个保守值跑两周之后再根据日志调整。我见过太多团队把阈值当一次性决策设完就不管了这是不行的——阈值是活的要跟着业务数据走。3.3 超限之后怎么办降级与兜底熔断不是把请求一扔了事而是要有后续动作。我的处理逻辑分成三档会话级超限返回兜底结果告诉调用方“当前任务需要拆分成更小的步骤”并不算系统错误。Agent 级超限让新会话排队而不是直接拒绝。排队时间超过 30 秒再拒绝避免用户体感太差。租户级超限直接进入只读模式。所有写操作类的工具改价、发消息、删数据一律禁止只保留查询类能力同时第一时间通知到租户管理员。降级处理做好了熔断才不是“一刀切”而是“精细切”。我之前看到很多项目把熔断做成全有或全无结果熔断一开所有 Agent 全部失效业务方炸锅。后来才意识到熔断的粒度一定要细细到工具级别、会话级别而不是整站级别。4. 输出内容校验让保险丝能挡住坏话配额熔断解决的是“动作失控”但还有一个问题是“说话失控”。Agent 生成了一段不合规的回复哪怕没有动任何工具发到用户面前也是事故。这一层靠的是输出内容校验我把它拆成了两道闸。4.1 规则引擎做第一道闸第一道闸是确定性规则引擎处理的是“一定违规”的内容。比如违规类型检测规则处置策略敏感词命中行业敏感词库比对整句替换为“抱歉我暂时无法回答”个人数据泄漏手机号、身份证、银行卡号正则匹配输出脱敏处理保留前缀后缀外部链接检测 URL 格式与域名黑名单拦截并提示用户联系人工诱导性语句关键词组合匹配如“返现”“私下转账”整段回复拦截并告警规则引擎的好处是快一毫秒级别而且结果完全确定。正则写对了就绝对不会漏。坏处是覆盖不了“看起来合规但实际越界”的内容比如 Agent 用间接话术暗示用户可以绕过流程这种语义级违规规则引擎很难抓。4.2 模型分类器做第二道闸第二道闸是一个轻量级的内容安全分类模型专门做语义级判断。输入是 Agent 生成的完整回复输出是“安全”或“违规”的概率分数。当违规概率超过 0.8 时直接拦截在 0.5 到 0.8 之间时进入人工复核队列。分类模型的选型不需要很大我用的是一个蒸馏过的小模型单次推理在 CPU 上不到 50 毫秒对线上延迟影响可以忽略。有朋友问过我为什么不直接用一个更强的模型来做第二道闸我的原因是成本和稳定性的考虑。大模型在内容审核上确实更准但推理延迟高、成本高而且模型本身也是概率性的反而引入新的不确定性。分类器的输出是稳定的概率值配合阈值策略行为可预期更适合作为熔断机制的一部分。大模型适合做“抽样复核”不适合做“全量防线”。4.3 一个更隐蔽的坑中间推理泄漏输出校验做得再严也拦不住一种特殊情况Agent 在工具调用的参数里就泄露了敏感信息。比如生成周报时模型把用户手机号直接填进了“导出文件名”参数里这个参数被工具执行、被日志记录、被链路追踪系统持久化。输出层校验看到的是给用户的最终回复根本拦不住这个过程。这个坑我踩过一次之后把敏感数据扫描前移到了工具调用层。规则不只在输出层跑一遍在工具调用参数上也要跑一遍。凡是参数里出现手机号、身份证号、银行卡号等模式直接熔断这次调用阻止动作发生。现在我对团队的要求是内容校验不是一个独立环节而是接入层、工具调用层、输出层三层各跑一遍宁可多花几个毫秒的算力也不放过一条泄漏链路。5. 超时、并发与线程隔离把失控 Agent 关进沙箱前两节解决的是“Agent 乱花钱”“Agent 说错话”这一节解决的是“Agent 卡住了”。这种失控没有表面上的破坏性但它同样致命——一个 Agent 会话阻塞可能拖垮整个服务的线程池让所有其他业务一起遭殃。5.1 超时熔断所有调用都要有“死刑时间”Agent 卡住最常见的原因是外部依赖没有按时返回。模型 API 接口在高峰期延迟飙升某个工具调用的第三方接口一直不响应如果调用的超时时间设置得太大线程就被永久占用。我把所有外部调用的超时时间统一设成三档调用类型超时时间超时后的动作模型 API 调用30 秒中断本次生成返回“生成超时请重试”单个工具调用60 秒熔断该工具 5 分钟返回“工具暂不可用”整个 Agent 会话180 秒强制终止会话记录完整调用链日志有人会觉得 30 秒是不是太短了有些复杂任务确实需要更长的生成时间。我的处理办法是区分场景普通对话任务模型调用 30 秒深度分析类任务可以放到 60 秒但必须显式标识出来而不是所有任务一刀切。任何调用都应该有一个明确的“死刑时间”到了时间就死绝不无限等待。这是线程安全最基本的底线。5.2 线程池隔离别让一个 Agent 拖垮全部单纯的超时控制只能防止线程被永久占用但挡不住另一个问题某个业务方的 Agent 并发量爆发把整个应用的所有线程都吃光。解决这个问题的核心是线程池隔离——不同业务方、不同优先级的 Agent分配到不同的线程池里跑。我用 Spring 的ThreadPoolTaskExecutor做隔离配置每个业务方建一个独立线程池。比如运营组的线程池核心线程数 10最大 20客服组的核心线程数 20最大 50。两个池子互不共享运营组那边 Agent 并发再高也只是运营组自己的请求排队客服组的线程资源不会受影响。这就像食堂开了几个窗口一个窗口前面排队的人再多另一个窗口照样能打饭。不过线程池隔离真正落地的时候有个细节要注意调用链的上下文传递。Agent 的会话 ID、租户 ID 等信息要通过TaskDecorator显式地传到子线程里否则异步执行后这些信息就丢了会直接导致熔断逻辑找不到是哪个会话触发的。这个坑我在联调阶段排查了整整一天问题的表象是配额失效本质是线程切换丢掉了上下文。5.3 并发信号量限制 Agent 同时伸出多少只手线程池隔离管住了不同业务方之间的影响但还没管住同一个 Agent 内部的并发。模型在自主规划时可能会一次性发起多个工具调用——比如同时查询库存、查询价格、查询物流——如果这个 Agent 本身就处于失控状态这些并发调用会像触手一样伸向四面八方。我用信号量Semaphore限制每个会话同时最多发起 3 个工具调用多余的调用排队等待。这个限制对正常任务完全够用因为规划合理的 Agent 很少需要同时开太多并发的工具调用而失控状态下这个限制能显著降低单位时间内的动作数量给熔断提供反应窗口。6. 熔断之后的恢复与复盘保险丝记录就是事故现场保险丝熔断本身不是目的熔断之后的恢复、修复、防止同类事故再次发生才是完整闭环。我这一节完全是从实际运维中总结出来的参考了断路器模式的思路但根据自己的场景做了不少调整。6.1 恢复策略半开状态才是安全的试探熔断不是一个永久状态否则服务就退化了。但如果熔断后立刻全量恢复也没有意义——问题还没解决恢复只会再次熔断形成抖动。我的做法是引入“半开状态”熔断状态熔断器打开所有请求快速失败不进入实际逻辑。半开状态熔断持续 60 秒后放少量请求比如 10%进去试探看是否再次触发熔断条件。关闭状态试探期内没有再次熔断逐步恢复全量流量。半开状态实现起来其实很简单就是一个原子变量存状态加上一个定时任务做状态流转。我不建议在这个环节引入太复杂的框架一个简单的状态机足够用。这里唯一要强调的是半开状态的试探流量必须走真实链路不能用假请求替代。只有真实的业务流量才能反映出真实的问题是否已经解决。6.2 熔断告警与人工介入机制熔断器打开的时候光靠“静默处理”是不够的一定要告警出来。我发的告警消息里包含这样几项内容Agent ID、会话 ID、触发熔断的指标名称是调用次数超限还是超时还是输出违规、当前指标值、以及最近的几次工具调用记录。有了这些信息值班的人不需要再去日志里翻找直接就能判断这是偶发还是系统性故障。特别要加一条同一会话在 5 分钟内触发过 2 次熔断就不再自动恢复必须人工确认。因为连续熔断说明该会话代理处于一种持续的不稳定状态自动恢复只会造成反复熔断的抖动。人工介入的方式比较轻——把会话标记为异常状态通知对应业务方负责人让他们在 Admin 后台查看这个会话的完整调用链判断是要强行终止还是允许继续。这套机制上线后凌晨被熔断告警吵醒的次数明显少了因为大多数问题在半开阶段就被挡住了真正需要人工的往往都是新的故障模式。6.3 保险丝记录每一次熔断都是一次体检最后聊一个我特别在意的点——熔断日志的价值。很多人把熔断日志当作“故障记录”存下来就不管了但在我看来每一次熔断都是系统给我们递上来的一张体检单。它精准地暴露了 Agent 在什么场景下、因为什么原因、在哪个环节出了偏差。我每两周会拉一次全量熔断日志做复盘按触发原因分组统计。做过几轮之后你会发现一些有意思的规律某类 Agent 总是在长对话的第十轮以后开始出现工具调用次数激增某类工具在高峰期总是超时某类指令在接入层总被用户绕过去。针对这些规律做定向优化效果远比写一套更完美的提示词来得好。比如我们发现客服 Agent 的循环调用大多出现在用户反复表达不满意的场景于是在接入层加了一个“情绪降级”逻辑——当用户连续三次给出不满意反馈时直接转人工不再让 Agent 继续尝试。这个改动之后客服 Agent 的熔断率下降了 80% 还多。熔断体系上线到现在我最大的体会是这套东西不是为了让 Agent 更聪明而是为了让 Agent 失控的成本有上限。AI 模型本身是不可控的但我们可以通过工程手段把不可控的范围圈定在一个“即使出错也不会出大事”的边界里。就像电路不会因为一道保险丝而变得更高效但少了保险丝再好的电路也有被烧毁的风险。如果你也在做 Agent 相关的东西我的建议是不要等到出一次事故再动手。先给工具调用层加一个最基础的计数熔断哪怕阈值先放得宽一点至少让失控跑不远然后逐步补上超时、隔离、输出校验这些环节。我踩过最大的坑就是一开始追求“完美方案”想一次性把所有保护都做完结果光设计就拖了两周最后被事故逼着上线了一个简单的计数版本——反而那个简单版本拦截掉了第一波真正的问题。保护机制不怕糙就怕没有。先把保险丝装上再慢慢调粗细。
