1. MCP Agent 失控先把现象看清楚前几天我在内部盯着一个模拟项目X的演示Agent 接上 MCP 服务后本来只想让它查一下某张订单的物流状态结果它自己给自己派活先查订单再查用户历史再查库存再调了邮件发送工具最后在一个团队成员没有拦截的情况下连续发出了 6 封通知邮件还试图去调一个只应该由后台任务使用的批处理接口。整个过程大概持续了十几分钟调用了几百次工具负责演示的同学最后只能手动把进程杀掉。这个场景放在半年前很多人会觉得是概率极低的边缘情况但今天只要你在做 Agent 和 MCP 的集成我就建议你把“失控”当成默认假设来设计系统。MCP全称 Model Context Protocol是模型上下文协议。它解决的是 AI 应用与外部工具、数据源之间的互联互通问题以前每个 Agent 接一个外部系统就要写一套私有接口现在通过 MCP 定义一套标准化的工具发现和调用方式Agent 宿主就像用 USB-C 口一样插上就能用。MCP 的 server 方向暴露三类东西tools工具、resources资源和 prompts提示模板客户端通过 JSON-RPC 2.0 的方式去发现和调用。带来的好处显而易见接入成本低、生态共享、工具可复用。但与此同时它把一个很关键的问题摆到了桌面上——Agent 接进来的工具越来越多能力边界越来越宽到底由谁来保证它不会“拿着钥匙到处开门”这篇内容不是讲 MCP 协议的入门教程而是围绕一个更现实的问题来展开Agent 在 MCP 工具生态里的“失控”到底长什么样为什么会发生以及我们用什么手段去治理。适合正在做 Agent 应用、准备把内部系统通过 MCP 暴露给大模型的团队参考也适合那些已经踩过坑、想系统化补齐安全与治理能力的同学。我会把我自己实操中的设计思路、配置参考和排障经验都放出来尽量给你可以直接抄作业的底稿。1.1 MCP 到底解决了什么问题在聊失控之前得先把 MCP 的定位说清楚。MCP 本质上是一个“接口协议层”它解决的是工具接入的标准化问题。没有 MCP 的时候你做一个客服机器人要接订单系统得写订单 API 的对接代码要接工单系统又得写一套工单 API 的对接代码每接一个系统就要适配一套鉴权方式、一套数据格式。有了 MCP工具提供方只需实现一个 MCP server把能力描述成工具列表暴露出来Agent 宿主编译期不用知道具体工具长什么样运行时通过协议去发现工具、读取工具 schema、发起调用就行了。这套设计有一个隐含的关键点协议只管“能不能调通”不管“该不该调”。打个比方MCP 是给 Agent 发了一把能打开很多扇门的钥匙串协议里面只规定了钥匙怎么插入、怎么转动但它没有规定哪些门你可以进哪些门连碰都不能碰。正是这个“连接与授权分离”的天然特性让失控风险从协议设计的第一天就埋下了。很多团队把 MCP server 一比一暴露给 Agent 使用Agent 能发现多少个工具就能调多少个工具。工具列表里既有只读的订单查询也有带副作用的邮件发送、状态修改。你指望模型自己根据用户意图去“自律”现实反复证明这件事靠不住。模型不是不会判断而是它的判断会受到上下文、指令模糊程度、工具描述质量等多重因素干扰一旦判断出现偏差执行层如果没有拦截机制错误就会直接落到真实系统上。1.2 三个真实的“失控”现场我结合自己做过的几个项目整理了三种高频失控形态你可以对照一下自己有没有遇到过。第一种是“循环调用黑洞”。Agent 接到的请求本身就有歧义比如“帮我整理一下这个月的订单情况”它就先去查订单列表发现数量很多于是想“那我要不要按地区分组”于是又调了一次筛选工具接着发现结果太长又想“我是不是应该出一份汇总报告”于是又去调报表生成工具报表生成报错了它开始自动重试重试失败后换一种参数再试。整个链路像是不小心开启了一个没有出口的递归每多一次调用就会产生新的上下文新的上下文又可能触发新的调用意图。这种失控最可怕的地方在于它看起来“每一步都挺合理”但整体已经脱离用户原始需求。第二种是“权限放大”。常见形态是 Agent 能调用的工具范围远远大于当前任务所需。比如一个只想做“查询类客服问答”的 Agent工具列表里却挂着删除订单、批量修改状态、发送营销邮件这类接口。模型在复杂推理过程中一旦路径选择偏了就可能从一个查询类任务滑向一个写操作。以我见过的真实案例来说有个团队在测试时让 Agent 帮忙“找出所有超时未发货的订单”结果 Agent 在找到之后自作主张地调用了一个批量状态更新接口把一千多条订单全部标记为“已处理”。虽然最终因为权限校验不严而没有造成实打实的破坏但这个操作如果发生在生产环境后果是灾难性的。第三种是“成本与外部依赖的雪崩”。这种失控往往伴随前两种出现但它的破坏点不是业务数据而是资源和钱。Agent 每多一次工具调用就会发生一次外部 API 请求一次模型推理一段上下文增长。如果调用的工具是短信服务、地图服务、第三方搜索这类按量计费的接口失控的代价是肉眼可见的账单上涨。我见过一个数据抓取类 Agent因为循环逻辑没有设置上限一个晚上把一个月的第三方搜索 API 配额全部烧光第二天业务方来找时日志里躺着一千多次重复度极高的相似调用。1.3 失控的共同特征把这些现象放到一起看能提炼出几个共同点第一失控不是突然发生的而是从一次模糊指令或一次错误选择开始经过多轮迭代逐步放大的第二失控的过程中往往没有外部干预点系统默认 Agent 每步操作都不需要确认或者确认机制形同虚设第三失控的代价是隐秘的它在发生初期不会报错直到额度耗尽、数据被改、外部服务被打爆才会暴露。理解了这三点就知道治理不该是事后补救而必须在执行路径上提前埋好控制点。2. 失控的根因协议开放、执行自动、治理缺位很多人以为 Agent 失控是模型能力不够换个更强的模型就好了。但实际上模型的“聪明程度”和“可控程度”是两个维度。失控的根因更多来自系统设计和治理缺位模型只是一个放大器。下面我把几层根因拆开讲。2.1 协议层默认开放但协议不负责授权MCP 协议的核心价值是标准化互操作它把工具发现和工具调用解耦了但这带来一个容易被忽略的问题任何客户端只要拿到了一个 MCP server 的地址就能枚举出它暴露的所有工具并且如果 server 没有做额外校验客户端理论上可以直接调用其中任意一个。协议层没有定义“什么是当前用户/当前会话可见的工具范围”也没有规定工具调用的审批流程。这个问题类似数据库连接串暴露拿到连接串的人不一定要攻破数据库他只需要“有权限连接”就够了。实际开发中很多 MCP server 为了追求接入便利在实现时只校验了一个很粗的 API Key有的连 Key 都不校验完全依赖内网环境隔离。等到 Agent 接入进来工具暴露面等于从“谁有连接串谁能调”退化成了“谁能控制模型谁能调”。模型一旦被诱导或者产生幻觉它的调用行为直接就等同于用户行为权限边界瞬间被跨过。所以我在做架构时有一个比较坚持的观点MCP server 自己只负责把能力暴露出来但“谁能用什么工具、在什么条件下用”必须由更靠前的治理层来控制。不要让 Agent 直连 MCP server中间一定要有一个代理或者网关。2.2 思维链的“惯性漂移”与上下文疲劳第二个根因来自模型推理过程本身。大模型在长链条推理中会持续把历史输出、工具返回结果、中间思考过程拼进上下文。上下文越长模型对原始用户意图的“注意力”就会越分散。它会逐渐被自己生成的中间结论带偏开始执行那些看起来“顺着当前思路很合理”、但已经偏离最初需求的操作。我用一个生活化的类比来解释就像你本来只是想查一下今晚有没有电影票打开购票 App 后首页弹出了优惠券你又点进去看了套餐接着又去看了餐厅推荐最后下单了一个爆米花套餐。每一步都有推荐理由但整体已经不是最初的目标。Agent 的思维链同样存在这种惯性漂移区别是它漂移之后会直接调工具速度比人类快得多。工具返回的结果越多、越复杂这种漂移就越明显因为中间状态里的“可选操作”变多了。针对这一点单纯靠提示词约束效果有限。提示词说“请不要执行超出用户请求范围的操作”模型在上下文较短时还能遵守一旦上下文变长这条指令会逐步被淹没在大量工具描述和中间结果里。工程上更可靠的方案是在执行路径上设置硬性检查点而不是把安全寄托在模型的自觉性上。2.3 重试机制把错误放大的放大器第三个根因是重试逻辑。很多 Agent 框架在设计时都带自动重试能力目的是应对网络抖动或者临时性的工具报错。这本身是合理的但问题在于如果不限制重试次数和重试范围它就会变成失控的放大器。我见过的一次事故是这样的Agent 调用一个支付状态查询接口接口因为依赖服务超时返回了错误。Agent 收到错误后根据“工具调用失败可能需要重试”的通用规则开始换参数重试。第一次重试时它把查询时间范围扩大了一下第二次又把排序方式改了一下第三次开始尝试另一个看起来相关的接口。等到人工介入时它已经连续调了四十多次其中大部分调用根本没有必要。重试机制的本意是应对瞬时故障但当“重试”和“临场发挥调整策略”混在一起时Agent 实际上是在用真实系统做自己的试验场。工程上必须区分两类情况一类是“固定的、幂等的、无副作用的工具”可以自动重试且要设次数上限另一类是“有副作用的、非幂等的工具”一旦失败就应停止转入人工处理。不区分这两类重试一定会成为失控的加速器。2.4 成本、配额与副作用的底账没算清最后一个根因有点“账没算清”的味道。很多团队上线 Agent 时最关心的是“效果好不好”却很少定义“一次任务最多可以调用多少次工具”“一次会话最多消耗多少 token”“外部按量付费的 API 一共给了多少预算”。没有这些定量约束失控的 Agent 永远不会被系统主动叫停它只会在资源耗尽后被动中断。副作用的问题也一样。只读工具和写操作工具在模型眼里可能只是“不同的函数”但它们对系统的影响天差地别。查一次订单和删一条订单代码上都是“调用工具”业务上却是完全不同的风险等级。如果工具在执行前没有按风险等级做分类校验等于把一把能发射的武器和一个手电筒放在同一个抽屉里而分发钥匙的人不做任何区分。3. 治理体系从限制到阻断再到可追踪的闭环讲完根因进入正题怎么治理。我的思路可以浓缩成三个关键词限制、阻断、可追踪。限制是让 Agent 只能在预先划定的范围内行动阻断是当行为越界或需要确认时机制能够强制叫停可追踪是让每一次工具调用都有据可查失控发生后能快速定位和复盘。3.1 治理原则与整体框架治理体系不是加一两个拦截器就能完成的它应该是一个贯穿请求全链路的闭环。我习惯把整个链路分成五层来看第一层是工具注册层。每个接入 MCP 的工具必须登记描述清楚它的用途、参数、副作用类型、幂等性、最低调用权限。没有登记的工具不允许被 Agent 发现。第二层是会话授权层。每个 Agent 会话创建时都要绑定一个身份和一份授权范围。授权范围决定了这个会话能看到哪些工具、能调用哪些工具、总调用上限是多少。第三层是执行决策层。也就是“工具调用前”的判断环节负责检查工具分级、配额、限流、人工确认状态。第四层是执行记录层。工具调用完成后把完整的请求、响应、耗时、token、错误信息写入审计日志。第五层是观测告警层。对执行记录做实时分析识别异常模式触发告警或自动熔断。这套框架并不复杂但它的核心是让治理从“事后的亡羊补牢”变成“事前的路径拦截”。Agent 的能力再强也只能在授权范围内跳舞。3.2 工具分级读、写、高危分开管理工具分级是治理体系里性价比最高的一步。我建议把所有工具按风险等级分为三类只读工具。包括查询订单、搜索商品、读取文档这类不会产生数据变更的操作。这类工具允许 Agent 在会话内自主调用但也要做配额限制。副作类工具。包括发送消息、创建工单、更新状态、调用外部通知服务这类会产生真实影响的操作。这类工具默认不允许 Agent 自主执行必须先经过人工确认。高危工具。包括删除数据、批量修改、支付操作、管理类接口。这类工具默认直接禁用即使有人工确认也需要二次审批和额外的条件校验。这个分级不是拍脑袋定的而是根据“出问题时的恢复成本”反推的。查询出错顶多是多花点时间更新出错可能影响到真实用户删除出错可能直接造成数据丢失。恢复成本越高控制强度就应该越大。实际项目中我建议把分级配置做成独立于代码的清单让产品和安全团队也能参与维护而不是让开发在代码里写死。3.3 细粒度授权与身份模型工具分级解决的是“工具本身的风险”细粒度授权解决的是“谁能在什么场景下用这些工具”。不要只在 server 端做一个全局开关那样要么太松要么太紧。比较合理的做法是引入三层身份模型用户级授权。每个真实用户或业务账号绑定一份基础权限比如客服人员只能访问订单查询和工单创建管理员才能访问数据导出。会话级授权。每个 Agent 会话在创建时根据当前任务动态生成一个临时授权范围。比如一个“仅查询物流”的任务会话里就不应该出现任何写操作工具。工具级授权。在工具定义上附加 scope 标签只有当用户授权、会话授权、工具标签三者匹配时调用才被允许。用 OAuth 里的术语来说就是在工具调用粒度上引入 scope 机制。我见过不少团队已经做了用户登录和会话管理却忽略了把用户权限下传到工具调用层结果 Agent 是以一个“超级服务账号”的身份在调所有工具前面的用户体系等于白做。3.4 配额、限流、熔断与紧急停止开关授权只能挡住“不该调的”但挡不住“合法但失控的”。一个会话在授权范围内循环调用几千次每一单次调用都是合法的累积起来却是灾难。所以必须有配额和限流。我建议在每个会话上至少设置四个量最大调用次数、最大 token 消耗、最大外部 API 成本、最大连续失败次数。任何一个达到阈值会话就被强制终止后续调用直接返回错误。这四个量可以在网关层统一计算不依赖 Agent 框架自带的限制因为框架的限制往往只作用于单次请求而无法感知整个会话的累计消耗。限流可以按滑动窗口实现比如某个工具分钟级最多调用 20 次超过就排队或者直接拒绝。熔断则针对下游服务的异常状态如果某个工具连续失败超过阈值就进入熔断状态在一段时间内所有对该工具的调用直接短路返回失败避免 Agent 用不停重试的方式把下游服务拖垮。紧急停止开关是最后一道防线也是一定要有的能力。应该提供一个全局的管理接口或配置文件运维人员发现 Agent 行为异常时可以一键将所有会话的执行模式切换为“只读不写”或“全部暂停”。这个开关不依赖模型、不依赖框架是在执行链路上最前置的一个布尔判断。真实环境里靠临时改代码或者杀进程都太慢了开关必须在秒级生效。3.5 人工确认Human-in-the-Loop怎么设计才不烦人“加人工确认”听起来简单但如果每个工具调用都弹确认框这套系统根本没法用用户会烦死Agent 的效率优势也没了。所以人工确认要分场景、分频率设计。我的做法是三级确认策略低风险工具直接放行中风险工具在首次调用时人工确认同会话后续同类调用且参数模式相似时自动放行高风险工具无论何时都人工确认且记录原因。这样可以兼顾安全和工作效率。确认界面上的信息一定要完整不要只显示“是否允许调用 email_send 工具”而要展示这次调用的完整上下文用户原始意图是什么、Agent 经过什么样的推理步骤决定调用这个工具、将要传入的参数是什么、可能产生什么影响。否则操作员为了确认一个动作还得自己去翻日志确认意愿会直线下降。某团队的真实体验是确认信息做得足够清晰后审批通过率并没有降低但审批速度明显加快了因为操作员不用再犹豫“点下去会出什么事”。3.6 审计、观测与告警让失控可被发现治理的最后一环是观测。如果一次失控发生后你连“它在什么时候开始偏离、调了哪些工具、消耗了多少资源”都说不清楚那治理就是空话。所以审计日志不是可选组件而是必需品。日志里的关键字段至少包括会话 ID、用户身份、工具名、入参摘要、出参摘要、调用耗时、token 消耗、外部 API 成本、模型生成该调用时的思考摘要、审批状态、执行结果。这些字段前后串起来就能还原一次完整的事故链路。观测层要关注几个异常信号单位时间内同工具调用次数陡增、单会话 token 消耗曲线突变、一个会话里相似参数的重复调用比例过高、从只读操作突然切换到写操作、外部 API 成本在短时间内接近配额。这些信号不一定要等事故已经造成损失才告警完全可以在它刚出现苗头时就触发给人工介入争取时间。我自己的经验是与其分析复杂的模型意图不如先盯着工具调用频次和资源消耗这些硬指标它们更客观也更容易自动化。4. 实操落地做一个带治理网关的 MCP Agent理论讲了不少这一节把前面说的东西落到代码和配置层面。我以“模拟项目X”举例一个客服自动化工单系统Agent 需要读取订单信息、查询物流状态、创建工单、发送客户通知邮件。目标是把这套 Agent 从“裸奔”变成“带治理网关的受控服务”。4.1 目标场景与架构选型先明确目标实现一个治理网关所有 Agent 的工具调用请求都必须经过网关网关负责鉴权、分级校验、配额统计、人工确认转发、熔断和审计日志。架构上新增一个代理层位于 Agent 框架和 MCP server 之间。这个代理层实现为标准的 MCP client 接口对上层 Agent 来说它就是一个普通的 MCP server对下层 MCP server 来说它是一个普通的客户端。所有调用都在中间做一次“体检”通过才放行不通过就拦截。选型上可以基于现有网关框架二次开发也可以用轻量级中间件实现。核心不在于框架而在于这个代理层必须能感知会话级别的状态累计调用数、累计 token并且能接入统一的配置中心。如果只做单机演示用一个内嵌的守护对象就够了生产环境则建议独立部署避免 Agent 服务崩溃时连治理能力一起丢失。4.2 治理网关的配置设计配置是整个治理体系的可视化入口。下面是一个精简版的分级与配额配置示例采用 YAML 格式方便团队一起维护。# governance.yaml tools: order_read: level: readonly quota: per_minute: 30 per_session: 100 tracking_query: level: readonly quota: per_minute: 20 per_session: 80 ticket_create: level: side-effect require_approval: true quota: per_session: 10 email_send: level: side-effect require_approval: true quota: per_session: 5 order_update_status: level: critical enabled: false order_delete: level: critical enabled: false session: max_calls: 200 max_tokens: 100000 max_cost_dollars: 2.0 max_consecutive_failures: 5 circuit_breaker: failure_threshold: 8 cooldown_seconds: 60 kill_switch: enabled: true这个配置里我把订单删除和批量状态更新直接禁用了因为它们在这个客服场景里根本不应该由 Agent 触发。邮件发送和工单创建标记为副作类工具需要人工确认。整体会话设置了 200 次调用的硬上限和 2 美元的预估成本上限一旦超过会话直接终止。配置下发之后网关要有一个配置热加载机制。不要每次改配置都重新发版因为“禁用某工具”这种操作往往发生在事故处理过程中必须能做到分钟级生效。最简单的做法是网关定期拉取配置文件的版本号变更时自动加载并有配置文件的变更审计。4.3 中间件逻辑与人工确认流程网关内部的核心逻辑可以简化成一个检查链。下面这段伪代码展示了工具调用放行前的判断顺序# gateway/guard.py (简化示例) async def check_tool_call(ctx): # 1. 全局紧急停止开关 if config.kill_switch.active: raise ExecutionStopped(global kill switch enabled) # 2. 工具是否启用 tool_meta config.tools.get(ctx.tool_name) if not tool_meta or not tool_meta.enabled: raise ToolDisabled(f{ctx.tool_name} is not enabled) # 3. 会话配额检查 if ctx.session.calls config.session.max_calls: raise QuotaExceeded(session call limit reached) if ctx.session.tokens config.session.max_tokens: raise QuotaExceeded(session token limit reached) if ctx.session.cost config.session.max_cost_dollars: raise QuotaExceeded(session cost limit reached) # 4. 工具等级检查 if tool_meta.level critical: raise PermissionDenied(critical tool requires manual override) # 5. 人工确认检查 if tool_meta.require_approval and not ctx.approval_granted: approval_id await dispatch_approval_request(ctx) raise NeedApproval(approval_id) # 6. 通过后记录并放行 await audit_log(ctx)人工确认的完整流程是网关发现工具需要确认后不直接执行而是把调用请求连同上下文写入一个审批任务推送到内部审批系统。审批系统通过 Webhook 或消息队列接收操作员在审批界面看到“工具名、参数、触发原因、Agent 的推理摘要”点击通过或拒绝。审批结果回传给网关网关重新发起一次调用检查。这里有个细节我一直强调审批结果不要做成永久授权要做成一次性授权并且要设置有效期。比如 5 分钟内有效过期后必须重新审批。否则一次审批成了“长期通行证”后续所有类似调用都会自动放行人工确认就名存实亡了。熔断逻辑可以放在网关的最外层。每个工具维护一个连续失败计数器失败超过阈值后进入熔断熔断期间所有对该工具的调用直接短路返回“服务暂不可用”同时给运维发一条告警。熔断冷却时间结束后放一个试探请求成功则关闭熔断失败则继续熔断。4.4 部署后的验证清单治理网关部署完不能直接上线我建议至少跑一遍下面的验证清单第一工具隐藏验证用一个没有授权的账号创建会话确认它只能发现白名单内的工具敏感工具在 MCP 的 tools 列表里就不应该出现而不是等到调用时才报错。第二配额熔断验证把会话最大调用次数临时调小用脚本触发高频调用确认到达阈值后调用被强制终止且审计日志里有完整的配额超限记录。第三人工确认验证让 Agent 触发一个需要审批的工具确认审批任务能正确推送、操作员拒绝后工具调用不会执行且记录被拒绝的原因。第四故障注入验证让一个下游工具持续返回错误确认熔断器在指定阈值后生效下游不再收到后续请求。第五紧急开关验证在 Agent 正在执行批量任务时手动打开全局停止开关确认新的调用请求全部被拦截。这个测试要定期做不要等到事故来临时才发现开关本身失效。5. 巡检、排障与经验笔记最后这一部分我把自己实际运维中遇到过的问题和排障思路整理成笔记。这些问题在文档里很难查到但遇到的时候非常救命。5.1 循环调用黑洞的排查思路当你发现 Agent 在一个任务上反复调用工具、停不下来时第一件事不要看模型日志先去数一下调用链里“同工具不同参数”的分布。如果发现一个工具被反复调用且参数只是轻微变化大概率是重试逻辑在作怪。处理方式是确认重试上限是否生效以及该工具的“失败后策略”是不是被配置成了“固定重试 N 次”。对于非幂等的有副作用工具一定要改为“失败即停止并通知人工”。第二类循环是“工具链循环”A 工具的输出喂给 B 工具B 的输出又触发 A 工具。这类问题靠限制次数可以兜底但更建议在网关层加一个“调用路径去重”如果某个会话里出现完全相同的调用路径组合超过 3 次就判定为可疑循环触发暂停并转人工。这个规则不用太复杂可以先从经验值开始跑。5.2 工具组合带来的权限绕过有一个很容易被忽视的漏洞单个工具都很安全但组合起来会产生高权限效果。比如一个“查询用户详情”的工具和一个“发送站内信”的工具单独看都正常但 Agent 可以通过查询用户详情拿到用户列表然后批量发送站内信。这种“工具组合攻击”在安全领域很常见在 Agent 场景下却被大幅放大了因为模型会自动编排多个工具。应对思路是在网关层做“敏感组合检查”。定义一些规则比如“查询类工具的输出不能作为写操作工具的批量入参”。落地时可以做一个轻量级的策略引擎匹配入参来源是否为上一工具的出参。这个检查不用覆盖所有场景先覆盖风险最高的组合即可。实际做过之后你会发现真正被利用的组合其实就那么几个。5.3 Token 消耗陡增的治理有一次我发现在一个会话中Agent 只是查询了三次订单token 消耗却高得离谱。排查之后发现问题出在工具返回结果没有裁剪。订单查询接口返回了一个超大 JSON里面包含了大量无关字段Agent 把这些内容原封不动塞回上下文下一轮推理时又重复读取了整段内容token 消耗成倍增长。工具输出必须做裁剪和摘要。MCP server 返回结果时就应该做字段筛选只返回当次任务可能需要的最小字段集对于超长结果可以在网关层做截断或摘要后再返回给模型。这个优化不仅能降本还能减少上下文疲劳间接降低失控概率。我建议在网关层统一做输出后处理而不是依赖每个 MCP server 自觉。5.4 人工审批超时的处理策略人工审批最大的隐患是“没人审批”。如果操作员在开会、下班、或者请求堆积在队列里Agent 就会一直挂着等待。更危险的是有些框架处理审批超时的默认策略是“超时自动放行”这绝对是不可接受的。一定要把默认策略配置成“超时自动拒绝”并设置一个明确的有效期。实际操作中为了让审批更顺畅我建议在审批队列里给高风险操作加“优先级标记”同时设置批量拒绝按钮。当运维发现一批可疑的调用请求时可以一键全部拒绝而不是一个个点。还要为审批请求设置“上下文快照”不能在操作员点击的时候才去拉当时的会话内容因为那个会话可能已经被后续调用改变了。5.5 常见症状速查表最后整理一个速查表方便大家遇到问题时快速对照。症状可能原因快速处置Agent 反复调用同一个工具重试无上限或失败后策略不当设失败即停止固化重试次数工具调用路径循环跳转工具链缺乏去重规则加可疑循环检测超阈值转人工低危工具被高频调用会话配额缺失设置最大调用次数与限流出现未授权的写操作工具白名单过宽启动工具分级高危默认禁用Token 消耗异常增长工具输出未裁剪网关输出截断与摘要化多个工具组合越权敏感组合无检查加敏感组合策略引擎审批长时间无人处理审批超时默认放行改为超时拒绝并设置有效期写在最后这套治理体系的雏形是我在一个呼叫中心自动化项目里被“坑”过一次之后才搭建起来的。当时我们为了让 Agent 能力最大化把所有 MCP 工具直接暴露给它结果演示当天就出现了我开头说的那种失控场景。后来花了两个星期补治理层最大的感触是工具暴露面收敛 人工确认 会话配额这三个基本动作就能拦住大部分失控根本不需要非常复杂的模型安全方案。如果你现在正要做一个 MCP Agent 相关项目我建议先从“影子模式”开始让 Agent 在只读环境里完整地跑真实任务把它的工具调用计划和推理过程全部录下来观察它有哪些“超出预期”的动作。观察一两天后你再决定哪些工具可以放开、哪些必须加审批、哪些直接禁用。这样做的好处是治理策略是建立在真实行为数据之上的而不是靠拍脑袋猜。等这个流程跑顺了再把治理网关前置到生产链路整个系统就会稳得多。