当你在 MCP 服务端接入各种工具并且在上面跑 Agent 时最担心的问题往往不是模型能力不够而是“工具被不该触发的时候触发了”。比如大模型误读用户意图直接删了文件、发了邮件、改了线上配置。早期我做 MCP 工具网关时第一反应是把这类判断交给 LLM 做让它“自己判断”能不能执行。结果延迟高、不可控而且模型对上下文的解读很不稳定。后来参考了 Atomadic 的 Zero-LLM Sub-200us MCP Action Interlock 思路把工具调用前的安全闸门从“模型判断”改成了“确定性规则判断”效果非常明显。本篇文章我将围绕 Atomadic 这个设计思路拆解 MCP Action Interlock 的核心概念并用手写一个最小 MCP 服务端的方式演示如何在工具调用前插入一个零 LLM 参与的互锁检查层。整套示例基于 Node.js 原生能力零第三方依赖复制后就能跑。同时会聊聊延迟为什么能做到 200 微秒以内以及实际工程落地时的规则设计、安全边界和常见坑。1. 背景与核心概念1.1 什么是 MCPMCPModel Context Protocol模型上下文协议是近年来兴起的一种标准化协议目的是让大语言模型应用能够以统一方式连接外部工具、数据源和业务能力。你可以把它理解成“AI 应用里的 USB-C 接口”不同的模型客户端、IDE、Agent 框架通过 MCP 协议访问文件系统、数据库、API、浏览器等能力而不需要为每个工具开发私有集成。MCP 的核心参与方有三个MCP Host也就是 LLM 客户端或 Agent 应用负责理解用户意图。MCP ClientHost 中负责与远程 MCP Server 建立连接的组件。MCP Server暴露工具、资源和提示词的服务端。一次典型的调用流程是用户输入 → LLM 生成意图 → Agent 根据意图调用 MCP 工具 → MCP Server 执行动作并返回结果。这里存在一个很关键的问题MCP Server 面对来自模型的调用请求时怎样判断“这个请求真的应该执行”1.2 为什么需要 Action Interlock“Action Interlock”可以理解成“动作互锁”最早来自于机械和电气安全领域指的是在某个动作执行前必须满足一组前置条件否则动作被强制锁定。放到 MCP 场景下就是工具调用的“安全闸门”。比如你暴露了一个write_file工具给 Agent。模型本身没有问题但在复杂对话中可能会生成错误的文件路径、覆盖重要文件或者被恶意提示词诱导执行危险操作。如果没有一层独立的、不受模型上下文影响的保护机制后果很难控制。过去很多人试图通过“系统提示词”约束 Agent在 prompt 里写“你不可以删除文件”、“写文件前必须确认路径”等。但这并不可靠。LLM 的本质是概率推理同样一句话在不同上下文里可能产生不同行为。系统提示词属于软约束无法提供硬保证。Action Interlock 就是要把“是否允许执行”这件事从模型手里拿出来交给一个确定性的规则引擎去处理。它不依赖 LLM不依赖上下文概率只依赖明确写死的规则和实时状态。只要条件不满足请求就会被拦截无论模型怎么说。1.3 Zero-LLM Sub-200us 意味着什么“Zero-LLM”不是指不接入大模型而是指在 Interlock 判断链路中不调用任何大模型推理。整个判断由本地内存中的规则引擎完成因此延迟极低。Sub-200us 指的是单次 Interlock 判断的耗时在 200 微秒以内。微秒是毫秒的千分之一而一次 LLM 推理往往需要数百毫秒甚至数秒。200us 的延迟意味着 Interlock 对整体调用链路几乎无感可以大胆地放在 MCP 服务端每个工具调用的入口处。要达到这个数字通常需要满足几个条件判断逻辑运行在本地内存中不涉及网络 I/O。规则匹配使用索引结构避免线性扫描大量规则。条件函数保持纯同步、轻量计算不访问磁盘或数据库。运行时环境尽量少 GC或者控制分配量。Atomadic 的核心思路就是把安全判断做成一个确定性、可测试、高性能的本地组件而不是把安全寄托在 LLM 的“自觉”上。2. 环境准备与项目结构本文的实战演示以 Node.js 为主因为 Node.js 的 readline 和 JSON 解析能力非常合适做 MCP stdio 服务端而且不需要额外安装框架。整个示例不依赖任何第三方包复现成本非常低。2.1 运行环境操作系统Windows / macOS / Linux 均可Node.js 版本建议 18 或更高包管理器无需 npm install但需要能运行 Node.js 命令命令行工具终端或 PowerShell版本需要根据你的项目实际情况调整本文示例以常见环境为例重点演示配置思路。如果你使用 Python 或其他语言核心流程同样适用只是代码实现不同。2.2 项目目录结构我们在一个空目录下创建如下文件atomadic-demo/ ├── package.json └── src/ ├── interlock-engine.js # 互锁规则引擎 ├── rules.js # 具体的互锁规则 ├── actions.js # 模拟的动作执行器 └── server.js # MCP 服务端入口目录结构不需要严格一致但建议保持这种“规则与执行分离”的组织方式。规则集中管理后期可以扩展为配置文件甚至动态配置中心。2.3 初始化项目在atomadic-demo下创建package.json{ name: atomadic-demo, version: 0.1.0, private: true, type: commonjs, scripts: { start: node src/server.js, bench: node src/server.js --bench } }这里使用 CommonJS 模块规范简单直接。如果你更熟悉 ES Module可以把type: module并改用 import 语法但本文为了减少环境差异统一使用require。3. 核心原理拆解3.1 MCP 工具调用的拦截点在 MCP 服务端工具调用的入口是tools/call方法。无论 LLM 最终决定调用哪个工具调用请求都会以 JSON-RPC 消息的形式发送到 MCP Server。因此我们在处理tools/call时插入一层 Interlock 判断就可以对所有工具调用行为进行统一控制。流程如下MCP Client 发送tools/call请求。Server 解析出工具名和参数。根据工具名查找到匹配的 Interlock 规则。用当前会话上下文、参数、系统状态执行条件判断。如果允许则继续执行真正的动作否则返回错误。这个流程完全同步不依赖 LLM。3.2 为什么不用 LLM 来做判断有人会问“我用 ChatGPT 写一个系统提示词在里面禁止它删除文件不就行了吗” 问题在于提示词是软性约束不是硬性约束。模型在复杂上下文中可能遗忘、曲解甚至被用户提示词注入绕过。此外每次调用 LLM 做一次安全判断延迟增加几百毫秒到几秒成本也随调用次数线性增长。用确定性规则的好处是可预测相同输入一定得到相同输出。可测试可以写单元测试覆盖各种边界场景。低延迟纯内存计算没有网络通信。高安全规则不受模型上下文影响无法被提示词注入改写。安全性本质上是一个“确定性”问题。LLM 负责理解用户意图、生成动作参数但是否允许执行应该由独立、确定的机制拍板。3.3 Interlock 引擎的组成一个完整的 Interlock 引擎由三部分组成规则集一组关于“什么条件下允许/禁止执行某类动作”的声明式规则。索引按照动作类型建立的规则映射避免遍历所有规则。检查器输入动作名和上下文输出“允许”或“拒绝”。规则的最小结构看起来像这样{ id: 只允许读取指定目录, actions: [read_file], effect: allow, condition: (ctx) ctx.args.path.startsWith(/data/docs/) }其中actions规则作用于哪些工具。可以是单个动作名也可以是多个。effect规则是放行还是拦截。建议默认拒绝只显式放行已知的安全动作。condition一个纯函数接收上下文对象返回布尔值。为了避免在规则数量很多时性能下降可以按actions建立 Map 索引把规则预先分组。这样在检查某个动作时只需要遍历该动作下的少量规则。3.4 默认策略白名单还是黑名单这是 Interlock 设计的第一个重要决策。黑名单模式默认放行只拦截明确禁止的动作。优点是业务改动小但风险是遗漏。只要有一条规则没覆盖到危险动作就会漏过去。白名单模式默认拒绝只允许命中的动作。安全级别更高也更适合作为 MCP 服务端的保护层。缺点是每次新增工具时都需要同步添加放行规则。在 Atomadic 的设计里推荐使用“默认拒绝 白名单放行 黑名单收口”的组合。也就是说首先把风险动作全部拦截然后只对通过白名单规则的动作放行再叠加少量 deny 规则处理特殊场景。3.5 如何估算亚 200 微秒的延迟一次 Interlock 检查的延迟主要由三部分组成查找动作对应的规则列表使用 Map 索引平均 O(1)。执行条件函数条件函数通常只做字符串、数值、布尔值判断纳秒级。返回决策结果构造一个小型结果对象。如果条件函数内部不碰 I/O、不做正则大回溯、不打印日志总耗时在几微秒到几十微秒之间。加上 MCP Server 本身的 JSON 解析和响应序列化单次工具调用整体延迟也可以控制在 200 微秒以内。这个量级对绝大多数业务场景都是完全可接受的。4. 实战案例实现一个最小 MCP Action Interlock 服务接下来我们亲手实现一个最小可运行的 MCP Server并在其中集成 Interlock 引擎。为了聚焦核心逻辑这个 Server 不引入任何第三方 SDK只实现 MCP 协议的子集。生产环境可以使用官方 SDK但思路完全一致。4.1 定义模拟动作执行器先创建src/actions.js它模拟真实的业务动作。这里我们不做任何真实文件操作只返回一个结果对象方便演示。// 文件路径src/actions.js async function executeAction(actionName, args) { // 模拟不同动作的耗时 switch (actionName) { case read_file: return { ok: true, action: read_file, args, result: file content }; case write_file: return { ok: true, action: write_file, args, result: written }; case send_email: return { ok: true, action: send_email, args, result: email sent to args.to }; default: throw new Error(unknown action: ${actionName}); } } module.exports { executeAction };这个文件单独拆分是为了强调“Interlock 只负责判断不负责执行”。真实项目中你可以在这个函数里注入实际的业务服务。4.2 定义互锁规则创建src/rules.js写入我们的白名单和黑名单规则。规则说明read_file只允许读取/data/docs/目录下的文件。write_file只允许写入/data/outbox/目录并且系统不在维护模式。send_email只允许在用户已授权、且最近一分钟发送邮件数量小于 10 时执行。另外无论任何规则都禁止向/etc/目录写入。// 文件路径src/rules.js const rules [ { id: deny-etc-write, actions: [write_file], effect: deny, condition: (ctx) ctx.args.path.startsWith(/etc/), }, { id: allow-read-docs, actions: [read_file], effect: allow, condition: (ctx) ctx.args.path.startsWith(/data/docs/), }, { id: allow-write-outbox, actions: [write_file], effect: allow, condition: (ctx) ctx.args.path.startsWith(/data/outbox/) !ctx.system.maintenanceMode, }, { id: allow-email-authorized, actions: [send_email], effect: allow, condition: (ctx) ctx.user.authorized true ctx.counters.emailSentLastMinute 10, }, ]; module.exports { rules };注意这里出现了两种 effectallow满足条件就放行。deny满足条件就拦截。在检查逻辑中先看有没有 allow 规则命中如果没有则默认拒绝再看 deny 规则是否命中命中则拒绝。这样既支持白名单放行也支持黑名单例外。4.3 实现 Interlock 引擎创建src/interlock-engine.js这是整个系统的核心。// 文件路径src/interlock-engine.js class InterlockEngine { constructor(rules) { // 按 action 分组索引规则避免每次检查都遍历全部规则 this.allowRulesByAction new Map(); this.denyRulesByAction new Map(); for (const rule of rules) { const targetMap rule.effect allow ? this.allowRulesByAction : this.denyRulesByAction; for (const action of rule.actions) { if (!targetMap.has(action)) { targetMap.set(action, []); } targetMap.get(action).push(rule); } } } check(action, context) { const allowRules this.allowRulesByAction.get(action) || []; const denyRules this.denyRulesByAction.get(action) || []; // 默认拒绝必须命中至少一条 allow 规则才放行 let allowed false; for (const rule of allowRules) { if (rule.condition(context)) { allowed true; break; } } if (!allowed) { return { allow: false, reason: NO_ALLOW_RULE }; } // 再检查 deny 规则一旦命中直接拒绝 for (const rule of denyRules) { if (rule.condition(context)) { return { allow: false, reason: DENIED_BY_${rule.id} }; } } return { allow: true, reason: ALLOWED }; } } module.exports { InterlockEngine };这个引擎有两个特点规则索引通过 Map 将规则按动作名分组。调用check时只需要读取对应动作名下的规则列表。纯同步判断所有条件函数都是同步纯函数不会引入事件循环抖动。4.4 编写 MCP Server创建src/server.js实现 JSON-RPC 消息处理。这里我们实现initialize、notifications/initialized、tools/list、tools/call四个核心方法。// 文件路径src/server.js const readline require(readline); const { InterlockEngine } require(./interlock-engine); const { rules } require(./rules); const { executeAction } require(./actions); const engine new InterlockEngine(rules); function sendMessage(msg) { process.stdout.write(JSON.stringify(msg) \n); } async function handleRequest(req) { const { id, method, params } req; // 初始化请求 if (method initialize) { sendMessage({ jsonrpc: 2.0, id, result: { protocolVersion: params.protocolVersion, capabilities: { tools: {} }, serverInfo: { name: atomadic-demo, version: 0.1.0 }, }, }); return; } // 初始化完成通知无需响应 if (method notifications/initialized) { return; } // 工具列表 if (method tools/list) { sendMessage({ jsonrpc: 2.0, id, result: { tools: [ { name: execute_action, description: Execute an action after interlock check, inputSchema: { type: object, properties: { action: { type: string, description: action name }, arguments: { type: object, description: action arguments }, }, required: [action], }, }, ], }, }); return; } // 工具调用 if (method tools/call) { const { name, arguments: args } params; if (name ! execute_action) { sendMessage({ jsonrpc: 2.0, id, error: { code: -32602, message: Unknown tool: ${name} }, }); return; } const actionName args.action; const actionArgs args.arguments || {}; // 构造 Interlock 上下文 const context { args: actionArgs, user: { authorized: true }, system: { maintenanceMode: false }, counters: { emailSentLastMinute: 1 }, }; const decision engine.check(actionName, context); if (!decision.allow) { sendMessage({ jsonrpc: 2.0, id, error: { code: -32001, message: Action interlocked: ${actionName}, data: { reason: decision.reason }, }, }); return; } try { const result await executeAction(actionName, actionArgs); sendMessage({ jsonrpc: 2.0, id, result: { content: [{ type: text, text: JSON.stringify(result) }], }, }); } catch (e) { sendMessage({ jsonrpc: 2.0, id, error: { code: -32002, message: e.message }, }); } return; } // 其他未知方法 if (id ! undefined) { sendMessage({ jsonrpc: 2.0, id, error: { code: -32601, message: Method not found: ${method} }, }); } } function main() { const rl readline.createInterface({ input: process.stdin, terminal: false }); rl.on(line, (line) { if (!line.trim()) return; let req; try { req JSON.parse(line); } catch (e) { console.error(Invalid JSON-RPC:, line); return; } handleRequest(req).catch((err) { console.error(Request handler error:, err); if (req.id ! undefined) { sendMessage({ jsonrpc: 2.0, id: req.id, error: { code: -32000, message: err.message }, }); } }); }); rl.on(close, () process.exit(0)); } // 基准测试模式 function runBenchmark() { const N 1000000; const ctx { args: { path: /data/docs/a.txt }, user: { authorized: true }, system: { maintenanceMode: false }, counters: { emailSentLastMinute: 1 }, }; const start process.hrtime.bigint(); for (let i 0; i N; i) { engine.check(read_file, ctx); } const end process.hrtime.bigint(); const nsPerOp Number(end - start) / N; console.log(average interlock check: ${nsPerOp.toFixed(2)} ns (${(nsPerOp / 1000).toFixed(4)} us)); console.log(theoretical operations per second:, Math.round(1e9 / nsPerOp)); } if (process.argv.includes(--bench)) { runBenchmark(); } else { main(); }这里有几点需要解释在真实 MCP Server 中context不应该硬编码而是从会话状态、认证信息和实时指标中动态获取。这里为了简化直接写死了一个可用的上下文。tools/list只暴露了一个统一的工具execute_action真实项目中你应该暴露每个实际工具然后在服务内部把 tool name 映射到 action name。这里统一入口更便于演示 Interlock。console.error可以用于调试因为 MCP 的 stdio 通信只使用 stdoutstderr 不会污染协议。4.5 运行与验证打开终端进入atomadic-demo目录运行node src/server.js此时服务器会等待 stdin 输入。我们可以用另一个终端向该进程发送多行 JSON-RPC 消息。为了简化可以用管道一次性发送printf %s\n \ {jsonrpc:2.0,id:1,method:initialize,params:{protocolVersion:2024-11-05,capabilities:{},clientInfo:{name:cli,version:1.0}}} \ {jsonrpc:2.0,method:notifications/initialized} \ {jsonrpc:2.0,id:2,method:tools/list} \ {jsonrpc:2.0,id:3,method:tools/call,params:{name:execute_action,arguments:{action:read_file,arguments:{path:/data/docs/readme.md}}}} \ {jsonrpc:2.0,id:4,method:tools/call,params:{name:execute_action,arguments:{action:write_file,arguments:{path:/etc/passwd}}}} \ {jsonrpc:2.0,id:5,method:tools/call,params:{name:execute_action,arguments:{action:delete_file,arguments:{path:/data/docs/readme.md}}}} \ | node src/server.js预期输出如下响应顺序与请求顺序不一定完全一一对应但 id 会保持一致{jsonrpc:2.0,id:1,result:{protocolVersion:2024-11-05,capabilities:{tools:{}},serverInfo:{name:atomadic-demo,version:0.1.0}}} {jsonrpc:2.0,id:2,result:{tools:[{name:execute_action,description:Execute an action after interlock check,inputSchema:{type:object,properties:{action:{type:string,description:action name},arguments:{type:object,description:action arguments}},required:[action]}}]}} {jsonrpc:2.0,id:3,result:{content:[{type:text,text:{\ok\:true,\action\:\read_file\,\args\:{\path\:\/data/docs/readme.md\},\result\:\file content\}}]}} {jsonrpc:2.0,id:4,error:{code:-32001,message:Action interlocked: write_file,data:{reason:DENIED_BY_deny-etc-write}}} {jsonrpc:2.0,id:5,error:{code:-32001,message:Action interlocked: delete_file,data:{reason:NO_ALLOW_RULE}}}从结果可以看出id3 的读取操作被放行因为路径位于/data/docs/下。id4 的写入操作被拦截因为命中了deny-etc-write规则。id5 的删除操作被拦截因为没有任何 allow 规则默认拒绝。这就完成了一个最小 MCP Action Interlock 服务。4.6 性能基准测试在项目目录执行node src/server.js --bench你可能会看到类似这样的输出average interlock check: 128.35 ns (0.1284 us) theoretical operations per second: 7791008这里我不给出固定数字因为不同硬件、不同 Node.js 版本会有差异。但通常来说这种纯内存的规则检查单次耗时应该在几十到几百纳秒之间。加上 MCP JSON-RPC 的解析和响应序列化整体单次工具调用的 Interlock 部分仍然可以轻松处于亚 200 微秒级别。如果需要更精确的端到端延迟可以在handleRequest中记录进入tools/call和返回响应的时间戳并输出到 stderr。生产环境建议使用 metrics 采集。5. 常见问题与排查思路5.1 延迟远高于 200 微秒问题现象常见原因解决思路Interlock 单次检查耗时达到毫秒级条件函数中访问了网络、磁盘或数据库将 I/O 排除在规则判断之外改为预加载到内存状态规则数量大但查找慢没有建立 action 索引每次遍历全部规则使用 Map 按 action 索引规则服务整体延迟波动条件函数中有正则回溯、递归、字符串大拼接简化条件函数避免复杂计算JSON 解析和序列化耗时长每条消息过大检查工具参数 schema限制输入大小一个比较常见的坑是在 Interlock 规则里实时查询“用户是否还有配额”直接发起 HTTP 调用。这种做法会让 Interlock 的延迟从微秒级变成毫秒级失去了确定性快速拦截的意义。正确的做法是把配额状态缓存到内存比如用一个计数器对象由其他异步任务更新。5.2 规则没有生效如果你发现某个动作明明被规则禁止却还是执行了可以从下面几个方向排查动作名是否完全一致。MCP 调用中的action和规则中的actions数组字符串是否大小写、拼写完全一致。Interlock 是否覆盖了所有调用入口。如果你的 MCP Server 里有多个tools/call分支漏掉其中一个那么那个入口会绕过 Interlock。规则 effect 是否写反。默认拒绝模式下只有allow规则能放行如果你只写了deny规则那么没有命中 allow 的动作也会被拒绝。上下文 context 是否传递正确。比如ctx.args.path是否真的能取到路径还是访问了不存在的字段。是否在 Interlock 之前就执行了动作。某些代码可能把业务执行写在 check 之前导致即使 check 返回 false动作也已经执行了。5.3 审计日志缺失Interlock 的一个重要价值是可审计。如果所有放行和拦截都不落日志那么出问题后很难回溯。建议至少记录以下字段时间戳动作名请求参数摘要决策结果命中的规则 id会话或用户标识这些日志应该输出到 stderr 或独立日志文件不要写到 stdout否则会破坏 MCP 协议通信。5.4 与 Agent 框架集成时错误信息不可读当 MCP Server 返回错误时LLM Agent 会看到这条错误内容并可能因此产生困惑。比如NO_ALLOW_RULE对机器可读但对模型不友好。建议在message中返回更易理解的文案同时在data.reason中保留机器可读的错误码。例如{ code: -32001, message: The operation is not allowed by current interlock policy, data: { reason: NO_ALLOW_RULE } }这样 Agent 能够知道“权限不足”而不是误以为工具本身坏了。6. 最佳实践与工程建议6.1 默认拒绝明确放行在 MCP 服务端Interlock 的默认策略必须是拒绝。新增一个工具时如果没有显式添加 allow 规则它就不应该能执行。这种方式比默认放行更容易控制风险因为新增工具的潜在危害是未知的。6.2 规则条件保持纯函数规则中的condition函数应该是一个纯函数输入 context输出布尔值内部不产生副作用。好处是可测试直接调用函数传入不同 context断言输出。可缓存如果上下文相同结果必定相同。可并发多个请求同时检查也不会相互影响。不要在 condition 中修改全局状态也不要在里面打日志。需要记录决策结果时应该在 engine 外部统一记录。6.3 使用索引而不是遍历当规则数量超过几十条时遍历所有规则会导致性能明显下降。使用 Map 按 action 索引后即使有上千条规则每次检查也只是读取一个短列表性能几乎不受规则总量影响。如果业务规则更复杂比如需要根据用户角色匹配多条规则可以考虑使用多维索引或规则分组。但原则是不要为了省事使用 O(n) 线性扫描。6.4 上下文设计要最小化Interlock 依赖的上下文越少越容易维护。不要为了“将来可能用到”就塞入大量数据。每次engine.check(action, context)时只传入与该动作相关的参数、最小权限状态和关键指标。这样既减少内存占用也能避免 context 中无关字段干扰规则判断。例如读取文件场景的 context 只需要路径和用户权限发送邮件场景还需要频率计数。不同动作可以使用不同的 context 构建器。6.5 与 LLM Agent 协作的方式Interlock 是确定性的守护层但它不替代 Agent 的意图理解能力。两者应该互相补充LLM Agent 负责理解用户意图、规划动作、生成参数。Interlock 负责校验动作是否在允许范围内、是否符合当前系统状态。你也可以通过tools/list返回的描述向 Agent 说明某些工具存在限制。但在实际调用时仍然以 Interlock 的判断为准。这样即使 Agent 没有遵守描述或者被提示词注入诱导也无法越权。6.6 热更新与配置管理如果 Interlock 规则写死在代码里每次增删规则都需要重新发布服务。对于业务变化较快的团队可以考虑把规则配置化保存规则为 JSON 文件服务启动时加载。通过配置中心推送例如 Apollo、Nacos。在内存中维护一个 AtomicReference修改时整体替换规则引擎实例。不过要注意规则热更新必须保证原子性。不能让新旧规则混用。推荐做法是构造一个新的InterlockEngine然后一次性替换引用。旧规则引擎可能在少量请求中继续使用但最终会自然废弃。6.7 安全边界Interlock 不是全能防线Interlock 能解决“在应用层拦截危险工具调用”的问题但不应作为唯一安全机制。真正的安全还需要依赖操作系统权限、网络策略、文件系统 ACL、数据库权限等底层控制。例如一个write_file工具如果得到 Interlock 放行但服务进程本身具有高权限那么危险目录依然可能被写入。所以 Interlock 更适合做“业务层安全策略”底层最小权限原则仍然要执行。建议把 MCP Server 运行在最小权限容器或专用账号中从系统层面减小爆炸半径。6.8 可观测性与指标生产环境中需要持续监控 Interlock 的工作状态。建议暴露以下指标每秒检查次数。放行/拒绝次数。拒绝原因分布。P99 检查耗时。当前规则数量。这些指标可以帮助你发现规则过严或过松的问题。例如如果某个动作的拒绝率突然升高可能是用户行为变化也可能是规则配置异常。7. 总结与后续学习路线Atomadic 的 Zero-LLM Sub-200us MCP Action Interlock 设计给 MCP 服务端安全提供了一条非常务实的路径用确定性规则替代模型判断在工具调用前增加一个高性能闸门。我特别认同的是“动作互锁”这个概念它把工程人员从“提示词安全”的焦虑中解放出来。过去我们纠结怎么调整 prompt 才能让模型听话现在可以把安全约束下沉到服务端用代码保证行为边界。这更符合软件工程的基本原则安全不能依赖概率。如果你想进一步学习可以考虑以下几个方向阅读 MCP 规范文档深入理解tools/list、tools/call、资源、采样等协议细节。将本文的代码迁移到modelcontextprotocol/sdk上实现一个生产级的 MCP Server。扩展 Interlock 规则模型支持组合条件、用户角色、动态状态。将规则与配置中心打通实现无重启热更新。围绕 Interlock 增加写操作审批流当某个动作超出一档风险等级时自动进入人工确认模式。我们团队目前已经在内部工具网关上采用了类似的实现整体效果稳定后续也会继续在规则模型和可观测性上迭代。如果你在 MCP 工具接入中也遇到过 Agent 误调用、越权调用的问题不妨从这样一个小而确定的 Interlock 开始先把底线守住再谈更智能的上层控制。