mcp 协议能做网络安全自动化吗

想把漏洞扫描、日志检索、资产核对串成一条自动跑的安全流程，看到 MCP 能挂工具就想直接上手，结果一跑就发现：扫描任务动辄十几分钟，模型早就超时了；批量扫全网段又把接口打到限流；出了问题日志里只剩一句调用失败。这篇不讲协议定义，只讲工程上怎么拆、怎么限、怎么兜底。

想把漏洞扫描、日志检索、资产核对串成一条能自动跑的安全流程，看到 MCP 能挂工具就想直接上手，是很自然的想法。但真跑起来通常卡在三个地方：扫描任务动辄十几分钟，模型早就超时了；批量扫全网段又把接口打到限流；出了问题日志里只剩一句调用失败，连是哪一步挂的都看不出来。

这篇不讲 MCP 的协议定义，只讲工程上怎么拆、怎么限、怎么兜底。你如果是往 Go 或 Java 写的 SOAR 里接 MCP 客户端，下面的拆分方式和参数设置可以直接拿去改。

MCP 在安全流程里能编排到哪一层

先划清边界：MCP 解决的是「模型怎么调工具」，不解决长耗时任务怎么等、并发怎么控、失败怎么重试。后面这三件事必须你在服务侧自己补上，指望协议替你处理会踩坑。所以能不能用，取决于你想编的那一步是什么性质。

判断标准很简单：这一步出错的代价是什么。只是多查一次、多拉一遍，就能自动跑；一旦动了生产配置或者要往防火墙推规则，就别让模型站在中间做决策，最多让它生成建议交给人工点确认。

把长任务拆成「下发 + 轮询 + 汇总」三段

长任务超时的根因，是你把「等扫描跑完」和「下发扫描」塞进了同一次工具调用。正确做法是让工具只负责下发并返回任务标识，轮询单独做成一步，汇总再单独一步。

1. 下发工具只做一件事：提交扫描任务，返回任务号。调用应当秒级返回，不阻塞。
2. 轮询单独一步查状态。设最大步数和总时长上限，超了就转人工或落库待后续，别让 Agent 无限转圈。
3. 汇总状态变为完成后，按任务号拉明细，模型只输出摘要字段，明细入库存档。

状态机写在服务侧，不要写在模型侧。任务状态存库，模型每次只读当前状态，这样上下文不会被历史结果撑爆。回报里只放任务号、状态、命中数量这类摘要，明细留着按需拉取。

{"task_id":"scan-8842","status":"running","hits":0}

不适用的情况也讲一下：如果你要编的是短平快的单次查询，比如查一条 IP 的归属，拆成三段反而增加往返和出错面，这种直接一次调用就行。

超时、并发、降级怎么设

超时别凭感觉写。先到 /tools/speed-test 量一遍各工具接口的延迟基线，再按基线往宽松处定。基线是几百毫秒，超时可给到秒级；基线本身就是分钟级的长任务，说明它根本不该放在同步调用里，应该走上一节的拆分。

• 并发按被调方的限流档位往回推，和供应商确认清楚配额再设
• 批量资产分成小批跑，批次之间留间隔，别一次性打满
• 被限流就退避重试，重试次数设上限，别加并发硬冲
• 每次重试都记一条日志，不然复盘分不清是超时还是限流

降级要有明确顺序，别临场拍脑袋。主模型不可用就切备用模型；工具不可用就改为只出排查线索、不出结论；全链路不可用就输出待人工处理的清单，把已知信息交出去而不是留空白。

日志与效果复盘

调不通最难受的不是报错，是日志里只有一句话。每次调用至少记这几个字段，缺一项后面就复盘不了。

会话标识

把一次流程里的所有调用串起来，方便按流程排查

工具名与入参摘要

入参别全量打，脱敏后留关键字段即可

状态码与耗时

用来判断是超时、限流还是工具内部错误

重试次数

区分首次失败和重试后成功，影响限流判断

是否命中降级

标记这一步是不是走了备用路径出的结果

还有一个容易被忽略的点：把「模型判断」和「工具事实」分两条字段记。出结论的时候要能分清哪句是工具返回的、哪句是模型推测的，否则追责和调优都无从下手。

效果复盘用小样本固定用例做回归：同一批资产、同一批日志，改完提示词或换模型后跑一遍，对比命中与误报。评测口径和基线数字到 /rankings 核对当时的记录，别拿记忆里的数当基准。

最后留一道人工复核入口。判定为高危的条目必须有人确认后才能进工单或推送到下游动作，全自动流程在高危判定上翻车一次，代价往往比省下的那点人力大得多。