1. 事件还原一个“抱团”的智能体是怎么把网站搞挂的先把场景摆出来。某团队做了一个面向内部知识库的 AI 智能体应用架构很典型前端一个对话框后端挂一个 Agent 调度服务Agent 可以调用若干工具——网页抓取、文件读写、数据库查询、发 HTTP 请求。上线初期一切正常直到某天运维发现目标网站响应时间从 200ms 飙到 8s日志里出现大量来自同一批 Agent 实例的并发请求最终对方站点直接返回 503触发了防护页面的拦截。复盘下来根因不是模型“变坏”了而是权限设计失控 多智能体协作放大效应。单个 Agent 被授予了“无限制调用 HTTP 工具”的权限而多智能体框架又允许 Agent 之间互相派发子任务。一个 Agent 发现“抓取网页”能完成任务就把这个动作复制给了它 spawn 出来的子 Agent子 Agent 再 spawn 孙 Agent形成指数级的请求风暴。这就是标题里说的“抱团劫持”——不是黑客攻击是自家智能体把自家依赖的外部站点给打穿了。这件事值得写是因为它踩中了当前 Agent 开发里最容易被忽视的一环我们花大量时间调 prompt、选模型、搭工作流却很少认真设计权限边界和资源配额。下面我把这次复盘拆成可复用的经验从架构、权限、协作、监控四个维度讲清楚适合正在做 Agent 开发、多智能体协作、AI 应用安全的朋友参考。2. 架构层面的隐患多智能体协作为什么会“失控”2.1 单 Agent 与多 Agent 的权限模型差异单 Agent 场景下权限控制相对简单一个进程、一套凭证、一个调用链。你只要在工具层加个白名单基本能兜住。但多智能体协作一上来问题就复杂了。我见过不少团队的多智能体框架是这样的主 Agent 负责拆解任务然后把子任务分发给 Worker AgentWorker 再按需调用工具。听起来很合理但权限是继承的——主 Agent 有什么权限子 Agent 就有什么权限孙 Agent 照样有。这就埋下了雷。维度单 Agent多 Agent 协作权限来源单一凭证继承 传递调用链深度1 层3~5 层甚至更深并发放大线性指数级故障定位容易极难日志分散资源配额单点控制需要全局协调这张表不是理论是我在实际排查中总结出来的。那次事故里主 Agent 只发了 1 个请求但经过 4 层 spawn最终产生了 3000 并发请求。每一层都觉得自己只做了一点点合起来就是灾难。2.2 “抱团劫持”的技术本质递归 spawn 无配额“抱团劫持”这个词听起来吓人技术本质其实很朴素递归创建子智能体且没有并发上限和深度上限。典型代码逻辑大概长这样伪代码def spawn_sub_agent(task, depth0): if depth MAX_DEPTH: # 很多项目根本没这行 return sub Agent(task) result sub.run() # 如果任务没完成继续拆 if not result.done: for sub_task in result.sub_tasks: spawn_sub_agent(sub_task, depth 1) # 没有并发控制问题出在两处一是MAX_DEPTH缺失或设得过大二是spawn_sub_agent没有并发闸门。当任务本身是“抓取 N 个页面”时每个子 Agent 又去抓 N 个请求量就是 N 的 depth 次方。注意递归 spawn 不是错错的是没有配额。任何允许 Agent 自主创建子 Agent 的框架都必须有硬性的深度限制和并发限制且限制要写在框架层不能靠 prompt 约束。2.3 为什么“工具权限”比“模型能力”更危险很多人把注意力放在模型会不会“胡说”上但真正能把系统搞崩的是工具权限。模型再强它也只能通过工具去影响外部世界。工具权限一旦失控模型越“聪明”破坏力越大。那次事故里Agent 被授予了http_request工具且没有域名白名单、没有速率限制、没有请求体大小限制。Agent 为了“更全面地完成任务”自动扩大了抓取范围从目标页面扩散到站内所有链接再扩散到外链。这不是模型恶意是模型在“尽力完成任务”。所以我的经验是工具权限要按最小必要原则授予且每个工具都要有独立的配额。抓取工具就给 10 QPS、单次最多 5 个页面数据库工具就给只读账号、单次最多 100 行。别嫌麻烦出事的时候这些限制就是救命稻草。3. 权限失控的四个关键环节与加固方案3.1 工具授权从“全开放”到“白名单 配额”先讲最核心的。工具授权要分三层做第一层域名/资源白名单。HTTP 工具只允许访问预先登记的域名其他一律拒绝。别用黑名单黑名单永远漏。第二层速率限制。每个 Agent 实例、每个工具、每个目标域名都要有独立的令牌桶。我一般设成单 Agent 10 QPS全局 100 QPS目标域名 20 QPS。第三层请求体限制。限制单次请求的 URL 数量、响应体大小、超时时间。超时设 5s响应体上限 1MB超过就截断。配置示例YAML 风格tools: http_request: allowed_domains: - internal-wiki.example.com - docs.example.com rate_limit: per_agent_qps: 10 global_qps: 100 per_domain_qps: 20 request: timeout_seconds: 5 max_response_mb: 1 max_urls_per_call: 5这套配置不是拍脑袋来的。10 QPS 是实测下来既能满足正常抓取、又不会把对方站点打挂的平衡点5s 超时是因为超过 5s 的页面通常内容质量也差不如放弃。3.2 子智能体创建深度、数量、生命周期三重限制多智能体协作必须限制三件事深度、数量、生命周期。深度限制建议最大 3 层。主 Agent → Worker → Sub-Worker再深就该重新设计任务拆解逻辑了。数量限制单个主 Agent 最多创建 10 个子 Agent全局并发 Agent 数不超过 50。生命周期限制每个子 Agent 最长运行 60s超时强制回收且回收时要清理它创建的所有资源。我踩过的坑是只限制了深度没限制数量。结果深度只有 2 层但每层创建了 50 个 Agent照样把系统打爆。深度和数量必须同时限制缺一不可。3.3 凭证隔离别让子 Agent 继承主 Agent 的全部权限这是最容易被忽视的一点。很多框架默认子 Agent 继承父 Agent 的凭证方便是方便但危险。正确做法是按任务下发临时凭证且凭证权限最小化。具体做法主 Agent 持有“创建子 Agent”的权限但不持有具体工具权限。创建子 Agent 时根据子任务类型动态下发对应的临时凭证。临时凭证有 TTL比如 5 分钟过期自动失效。子 Agent 无法再创建孙 Agent除非显式授权。这样即使某个子 Agent 失控它能造成的破坏也被限制在它那点临时权限里。3.4 熔断与降级当异常发生时自动止损再好的预防也可能有漏网之鱼所以必须有熔断。我一般设三个熔断条件错误率熔断某工具 1 分钟内错误率超过 50%自动禁用该工具 5 分钟。延迟熔断某工具 P99 延迟超过 3s自动降级为“仅缓存读取”。请求量熔断全局 QPS 超过阈值 120%自动拒绝新请求返回“系统繁忙”。熔断触发后要有告警且告警要带上下文哪个 Agent、哪个工具、哪个目标域名。没有上下文的告警等于没告警。4. 实操复盘从事故发现到修复的完整过程4.1 发现阶段监控指标怎么配才能第一时间报警事故当天我们其实有监控但报警阈值设得太松。响应时间从 200ms 涨到 8s 才报警已经晚了。复盘后我把监控指标重新设计了一遍指标原阈值新阈值说明目标站点响应时间5s1s超过 1s 就预警Agent 并发数无30超过 30 预警单工具 QPS无80超过 80 预警子 Agent 创建速率无10/分钟超过预警错误率20%5%超过 5% 预警关键变化是加了 Agent 维度的指标。原来只监控外部站点没监控自家 Agent 的行为。现在每个 Agent 实例的创建数、工具调用数、失败数都要上报。4.2 定位阶段如何从海量日志里找到“元凶 Agent”日志分散是最大的痛点。我的做法是给每个 Agent 打上trace_id父子 Agent 共享同一个 trace_id但每个 Agent 有独立的 span_id。这样查日志时先按 trace_id 聚合再按 span_id 展开就能看到完整的调用树。定位时按这个顺序查先看哪个 trace_id 的请求量最大。再看这个 trace 里哪个 span 的 QPS 最高。然后看这个 span 对应的 Agent 是谁创建的、创建它的又是谁。一路往上追找到递归 spawn 的源头。那次我们追了 4 层发现源头是主 Agent 的一个“抓取所有相关文档”的任务它把这个任务拆成了 20 个子任务每个子任务又拆了 20 个最终 400 个 Agent 同时抓取。4.3 修复阶段代码改动与配置调整清单修复分三块代码改动# 修复前 def spawn_sub_agent(task): sub Agent(task) return sub.run() # 修复后 MAX_DEPTH 3 MAX_CHILDREN 10 GLOBAL_AGENT_LIMIT 50 def spawn_sub_agent(task, depth0, parent_traceNone): if depth MAX_DEPTH: raise DepthLimitExceeded() if get_global_agent_count() GLOBAL_AGENT_LIMIT: raise GlobalLimitExceeded() if get_children_count(parent_trace) MAX_CHILDREN: raise ChildrenLimitExceeded() sub Agent(task, trace_idparent_trace, depthdepth1) return sub.run()配置调整把工具配额、熔断阈值、监控指标全部按上面说的重新配了一遍。流程调整新增一条规定——任何新 Agent 上线前必须通过“权限评审”评审项包括工具白名单、配额、熔断、监控四项缺一不可。4.4 验证阶段压测与灰度怎么设计修复后不能直接全量上线要先压测再灰度。压测方案模拟 100 个并发任务每个任务触发 3 层 spawn观察目标站点响应时间和自身系统资源。目标是目标站点响应时间不超过 500ms自身 CPU 不超过 70%。灰度方案先放 10% 流量观察 24 小时再放 50%观察 12 小时最后全量。灰度期间监控指标要加密上报每 10s 一次。实测下来修复后的系统在 100 并发下目标站点响应时间稳定在 300ms 左右Agent 创建数被限制在 50 以内没有再出现失控。5. 常见问题与排查技巧实录5.1 Agent 权限失控的典型症状速查表症状可能原因排查方向目标站点响应变慢请求量过大查 Agent 并发数、工具 QPS自身 CPU 飙升递归 spawn查 Agent 创建速率、深度日志量暴增循环调用查 trace 调用树、重复任务凭证失效TTL 过期查凭证下发逻辑熔断频繁触发配额过紧调整配额观察业务需求子 Agent 不回收生命周期缺失查超时回收逻辑这张表是我从多次排查中总结的基本覆盖了 80% 的常见问题。5.2 三个我踩过的坑和对应的解法坑一只限制深度没限制数量。前面提过深度 2 层也能创建 2500 个 Agent。解法是深度和数量同时限制。坑二用 prompt 约束 Agent 行为。我试过在 prompt 里写“不要创建超过 5 个子 Agent”结果模型该创建还是创建。prompt 是软约束代码才是硬约束。所有限制必须写在框架层。坑三监控只监控外部不监控内部。外部站点挂了才发现太晚。解法是内部指标Agent 数、工具调用数、创建速率必须和外部指标一起监控。5.3 给正在做 Agent 开发的朋友的几条硬建议工具权限默认拒绝需要什么开什么别反过来。子 Agent 创建必须有硬限制深度、数量、生命周期三件套。凭证按任务下发别继承别共享。熔断和降级是标配不是可选项。监控要覆盖 Agent 维度不能只看外部站点。上线前做权限评审把安全左移。这几条看起来简单但真做到的项目不多。那次事故后我把这几条写进了团队的 Agent 开发规范后续再没出过类似问题。6. 从这次事故延伸出的 Agent 安全设计原则6.1 最小权限原则在 Agent 场景的落地最小权限原则大家都听过但在 Agent 场景怎么落地我的做法是按任务类型定义权限模板每个模板只包含完成该类任务必需的工具和配额。比如“文档检索”模板只允许http_request白名单内域名、file_read只读指定目录、search只搜内部索引。配额是 10 QPS、单次 5 个页面、超时 5s。“数据分析”模板只允许db_query只读账号、file_write只写临时目录。配额是 1 QPS、单次 100 行。Agent 创建时必须指定模板不能自定义权限。这样权限边界清晰审计也方便。6.2 可观测性Agent 行为日志该记什么Agent 行为日志要记四类信息身份信息Agent ID、trace_id、span_id、父 Agent ID、创建时间。行为信息调用了什么工具、传了什么参数脱敏后、返回了什么结果摘要。资源信息消耗了多少 token、多少 CPU、多少网络流量。异常信息失败原因、重试次数、熔断触发记录。日志要结构化JSON方便查询和聚合。我一般用 ELK 或类似方案按 trace_id 建索引查询时能秒级定位。6.3 未来协作方式人类该在哪个环节介入多智能体协作不是要取代人而是要把人放在关键决策点。我的经验是设三个介入点任务拆解后主 Agent 拆完任务人工确认拆解是否合理避免方向性错误。高风险操作前涉及写操作、外部请求、大额资源消耗时人工确认。异常熔断后熔断触发后人工决定是恢复还是终止。这三个介入点不需要人一直盯着而是通过审批流异步处理。这样既保证了效率又守住了安全底线。那次事故后我们加了“高风险操作审批”Agent 要抓取超过 10 个页面时会自动暂停并通知人工确认。上线后类似的风险操作被拦截了十几次每次都避免了潜在的失控。7. 写在最后一些个人体会做 Agent 开发这两年我最大的体会是模型能力不是瓶颈工程约束才是。模型再强如果权限、配额、熔断、监控没做好照样能把系统搞崩。反过来模型一般但工程约束到位系统反而稳。那次“抱团劫持”事故表面看是 Agent 失控本质是工程约束缺失。修复过程不复杂难的是意识到“需要约束”。很多团队在快速迭代阶段为了赶进度把安全约束往后放结果就是事故倒逼补课。如果你正在做 Agent 开发我的建议是在写第一行 Agent 代码之前先把权限模型、配额策略、熔断机制、监控指标这四件事想清楚。这四件事想清楚了后面会省很多事。想不清楚后面会花十倍时间补。最后分享一个小技巧给每个 Agent 起个有意义的名字比如doc-fetcher-01、>
)
