1. OpenShell 是什么为什么值得你花时间了解第一次听到 OpenShell 这个名字很多人会以为是某个操作系统的内核项目或者是一个新的命令行终端工具。实际上OpenShell 是一个面向 AI 智能体Agent的运行时安全框架它的核心定位是给自主运行的 AI 智能体套上一层可控、可审计、可约束的执行外壳。你可以把它理解成给一个能力很强但行为不完全可预测的“数字员工”配一套门禁系统、操作日志本和权限清单让它在边界内干活而不是放任它在你的系统里随意行动。这个项目解决的核心问题非常现实当 AI 智能体开始具备调用工具、读写文件、执行命令、访问网络的能力时它的一次错误决策可能带来的后果远超一次聊天回复出错。一个只会聊天的模型说错话你重新问一遍就行但一个能执行 shell 命令的智能体如果理解偏了任务意图可能直接删掉你的文件、改坏你的配置、或者把敏感数据发到不该去的地方。OpenShell 要做的就是在智能体和真实执行环境之间插入一层策略控制让每一条指令在真正落地之前都经过检查、授权和记录。适合关注这个项目的人大致有三类。第一类是正在做 AI Agent 应用开发的工程师尤其是那些让模型直接操作文件系统或执行系统命令的场景你需要一个可靠的隔离层来兜底。第二类是对 AI 安全、AI 治理感兴趣的技术管理者你需要理解智能体运行时的风险点在哪里、有哪些工程手段可以控制。第三类是对底层系统编程和沙箱技术有好奇心的开发者OpenShell 在进程隔离、系统调用拦截、策略引擎设计上的思路本身就很有参考价值。我接触这个方向是因为之前做过一个自动化运维助手让模型根据自然语言描述去执行服务器上的维护脚本。测试阶段一切正常直到有一次模型把一个“清理临时文件”的任务理解成了“清理所有 .tmp 结尾的文件”差点把某个服务的运行时数据目录给端了。那次之后我就意识到光靠提示词约束模型行为是不够的必须在执行层有一道硬性的、不依赖模型自觉的防线。OpenShell 这类框架的价值就在这里——它不假设模型永远正确而是假设模型可能出错然后在出错之前拦住它。2. 智能体运行时的风险到底出在哪OpenShell 的设计思路拆解2.1 从一次真实的误操作说起为什么提示词约束不够用很多人对 AI 智能体安全的第一反应是“我在系统提示词里写清楚不就行了”。比如告诉模型“不要删除重要文件”“不要访问敏感目录”“执行命令前先确认”。这些约束在大多数时候确实有效但它们有一个根本性的弱点它们依赖模型对指令的理解和遵守而模型的理解是不确定的。我做过一个简单的测试在系统提示词里明确写了“禁止执行 rm -rf 开头的命令”然后用各种方式诱导模型去执行删除操作。直接要求它删它会拒绝但如果我把任务包装成“请帮我清理一下 /tmp/build 目录下的编译残留”它在某些情况下会生成一条包含 rm -rf 的命令因为它认为这是在完成用户交代的清理任务而不是在“执行删除操作”。模型对意图的判断和字面规则之间存在缝隙这个缝隙就是风险的来源。OpenShell 的设计出发点就是承认这个缝隙的存在。它不试图让模型变得更听话而是在模型输出和执行环境之间加一层确定性的策略检查。模型可以生成任何它想生成的指令但这些指令必须通过 OpenShell 的策略引擎才能到达真正的执行层。策略引擎的规则是代码写的、是确定性的、是不受模型情绪和理解偏差影响的。这就把“模型可能犯错”从一个致命问题降级成了一个可管理的工程问题。2.2 三层防护模型策略、沙箱、审计OpenShell 的架构可以粗略地分成三层每一层解决不同层面的问题。第一层是策略层。这是最靠近智能体的一层负责在指令执行之前做静态检查。策略可以基于命令内容、目标路径、调用参数、执行时间、调用频率等多个维度来定义。比如你可以写一条策略“任何包含 rm 且参数中有 -r 的命令如果目标路径不在 /tmp 或 /var/tmp 下一律拒绝执行。”这条策略不关心模型为什么想执行这个命令它只看命令本身是否满足放行条件。策略层的优势是响应快、逻辑清晰、容易审计缺点是只能做静态判断无法感知运行时的动态上下文。第二层是沙箱层。当一条指令通过了策略检查它会被放到一个受控的执行环境中运行。这个沙箱限制了指令能看到的文件系统范围、能访问的网络地址、能使用的系统资源。即使策略层因为规则不够细致而放行了一条有风险的指令沙箱层也能把它的影响范围控制在可接受的边界内。沙箱的实现方式有很多种从轻量级的进程级隔离到重量级的容器或虚拟机隔离OpenShell 通常会根据任务的风险等级选择不同的隔离强度。第三层是审计层。所有经过 OpenShell 的指令无论最终是否被执行都会被完整记录。记录的内容包括指令原文、发起指令的智能体标识、策略检查结果、执行结果、执行耗时、资源消耗等。审计层的价值在事后排查和持续优化。当你发现某类指令频繁被策略拦截时你可以回头去看是模型的理解有问题还是策略定义得太严格然后针对性地调整。这三层不是简单的叠加关系而是有明确的职责分工。策略层做快速筛选沙箱层做兜底隔离审计层做全程记录。任何一层单独拿出来都不足以完全解决问题但三层配合起来就能把智能体运行时的风险控制在一个可接受的范围内。2.3 和直接使用容器方案的区别在哪看到这里你可能会想我用 Docker 或者别的容器方案把智能体关起来不就行了为什么还需要 OpenShell 这样一层这个问题问得很好我自己也对比过这两种思路。容器方案确实能提供很强的隔离能力但它在智能体场景下有几个不太顺手的地方。首先是粒度问题。容器通常是按服务或按任务整体隔离的一个容器里的所有进程共享同一套权限。但智能体的操作粒度可能很细同一个任务里它可能需要先读一个配置文件只读权限然后写一个日志文件只写权限再调用一个外部接口网络权限。用容器来做这种细粒度的权限切换很笨重你得为每种权限组合准备不同的容器镜像或者频繁地重建容器。OpenShell 的策略层可以在指令级别做权限判断粒度细得多也灵活得多。其次是动态性问题。智能体的任务流程往往不是预先确定的它可能根据中间结果临时决定下一步做什么。容器方案要求你在启动容器之前就把权限边界定好但智能体可能在你定边界的时候还没想好要做什么。OpenShell 的策略引擎支持运行时动态评估可以根据当前任务的上下文、历史操作记录、甚至外部信号来实时决定是否放行某条指令。最后是审计和可解释性问题。容器方案能告诉你容器里发生了什么但很难直接告诉你“智能体为什么做了这个操作”“这个操作和任务目标的关系是什么”。OpenShell 的审计层是专门为智能体场景设计的它记录的不只是系统调用和资源使用还包括指令与任务上下文的关联信息这对调试和优化智能体行为非常有帮助。当然OpenShell 并不排斥容器方案。在实际部署中很多团队会把 OpenShell 的策略层和审计层跑在容器外面把沙箱层用容器来实现两者是互补关系而不是替代关系。3. 核心模块拆解与关键配置实操3.1 策略引擎的规则怎么写才既安全又不误伤策略引擎是 OpenShell 里你打交道最多的模块规则写得好不好直接决定了这套框架是帮你还是烦你。我踩过的最大坑是一开始把规则写得太严结果智能体正常干活都被拦效率还不如不用。写策略的第一个原则是白名单优先于黑名单。新手很容易想到的是列一堆禁止操作比如禁止 rm、禁止 chmod、禁止访问 /etc。但黑名单永远列不全而且攻击面是发散的。更好的做法是反过来只允许智能体执行你明确认可的操作其他一律拒绝。比如对于一个代码生成类的智能体你可以定义“只允许在 /workspace 目录下进行文件读写只允许执行 python 和 pytest 命令只允许访问 pypi.org 这一个网络地址”。这样即使模型被诱导生成了恶意指令它也不在允许范围内直接就被拦了。第二个原则是路径检查要做规范化处理。这是一个很容易被忽略的细节。假设你的策略是“禁止访问 /etc 目录”但模型生成的指令里写的是 /etc/../etc/passwd或者用了符号链接指向 /etc简单的字符串匹配就拦不住了。OpenShell 在策略层会先对路径做规范化resolve 掉 .. 和符号链接然后再做匹配。你自己写自定义策略的时候也一定要注意这一点否则规则形同虚设。第三个原则是给策略分级而不是一刀切。不是所有操作都需要同等强度的检查。读操作和写操作的风险等级不同写临时文件和写持久化配置的风险等级也不同。我通常会把策略分成三档低风险操作如读取指定目录下的文件直接放行中风险操作如写入工作目录、执行受限命令记录日志后放行高风险操作如删除文件、修改系统配置、访问外部网络必须显式授权或直接拒绝。这样既保证了安全又不会让智能体在低风险操作上浪费时间和授权次数。下面是一个策略配置的示例结构用 YAML 格式来表达policies: - name: allow_workspace_read priority: 10 match: operation: file_read path_prefix: /workspace action: allow log_level: debug - name: allow_workspace_write priority: 20 match: operation: file_write path_prefix: /workspace action: allow log_level: info - name: block_system_paths priority: 5 match: operation: [file_read, file_write, file_delete] path_prefix: [/etc, /usr, /var, /root, /boot] action: deny log_level: warn - name: require_approval_for_delete priority: 1 match: operation: file_delete path_prefix: /workspace action: require_approval log_level: warn这个配置里 priority 数字越小优先级越高block_system_paths 的优先级最高确保系统目录永远不被碰。allow_workspace_read 和 allow_workspace_write 优先级较低在系统目录检查之后生效。require_approval_for_delete 优先级最低意味着删除操作即使在工作目录下也需要额外审批。3.2 沙箱隔离的强度选择与资源限制沙箱层的配置核心是两个问题隔离强度选多高资源限制设多少。隔离强度方面OpenShell 通常提供几个档位。最轻的是进程级隔离用独立的系统用户跑智能体的指令配合文件系统权限来控制访问范围。这种方式开销最小但隔离能力也最弱主要防的是误操作而不是恶意行为。中间档是命名空间隔离利用 Linux 的 namespace 机制把智能体放进独立的 mount、pid、network 命名空间里它能看到的文件系统和进程树都是受限的。最重的是虚拟化隔离每个任务跑在独立的轻量虚拟机里隔离最彻底但启动开销也最大。我的经验是按任务风险等级动态选择。对于只读查询类的任务进程级隔离就够了对于需要写文件、执行命令的任务至少用命名空间隔离对于涉及敏感数据或外部网络访问的任务上虚拟化隔离。OpenShell 支持在策略里指定隔离级别这样同一个智能体在处理不同任务时可以用不同的隔离强度不用一刀切。资源限制方面有几个参数必须设不设的话一个失控的智能体可能把你的机器资源吃光。CPU 限制建议按任务类型来定纯文本处理类任务给 1 到 2 核就够了涉及编译或数据处理的任务可以给到 4 核。内存限制要留足余量我一般按预估峰值的 1.5 倍来设比如预估需要 2GB 就设 3GB 上限。磁盘写入限制容易被忽略但很重要尤其是智能体可能生成大量日志或中间文件的时候设一个写入配额能防止磁盘被写满。执行时间限制也是必须的单个指令的执行时间不应该超过任务本身的合理耗时超时直接终止。sandbox: isolation_level: namespace # 可选 process / namespace / vm resources: cpu_cores: 2 memory_mb: 3072 disk_write_mb: 512 max_execution_seconds: 300 filesystem: read_only_paths: - /usr/lib/python3 - /workspace/reference_data read_write_paths: - /workspace/output - /tmp hidden_paths: - /home - /root - /etc/ssl/private这个配置的意思是用命名空间隔离给 2 核 CPU、3GB 内存、512MB 磁盘写入配额单条指令最长跑 5 分钟。文件系统方面Python 库目录和参考数据只读输出目录和临时目录可读写用户主目录和私钥目录完全隐藏。这样即使智能体被诱导去读私钥文件它在沙箱里根本看不到那个路径。3.3 审计日志的字段设计与查询技巧审计日志看起来简单但字段设计得好不好决定了你事后排查问题时是事半功倍还是事倍功半。我见过一些团队的审计日志只记了“谁在什么时候执行了什么命令”结果出问题时根本还原不了现场。OpenShell 的审计日志我建议至少包含这几类字段。指令标识类指令 ID、父指令 ID用于追踪指令之间的调用关系、智能体实例 ID、任务 ID。指令内容类原始指令文本、解析后的操作类型、目标路径或资源、调用参数。策略决策类命中了哪条策略、决策结果allow/deny/require_approval、决策耗时。执行结果类是否实际执行、退出码、标准输出摘要、标准错误摘要、执行耗时、资源消耗峰值。上下文类指令发起时智能体正在处理的任务描述、前序指令的摘要。有了这些字段排查问题时你可以做很多有用的查询。比如“找出所有被拒绝的删除操作看看模型在什么任务上下文中试图删除文件”或者“找出执行时间超过 60 秒的指令看看是不是有性能问题”或者“找出同一个任务里连续被拒绝三次以上的指令序列这通常意味着模型陷入了某种错误循环”。查询技巧方面我建议给审计日志建几个常用的索引按任务 ID 索引、按决策结果索引、按操作类型索引、按时间范围索引。这样大部分查询都能在秒级返回。另外对于被拒绝的指令不要只看指令本身一定要结合当时的任务上下文一起看。很多时候指令被拒不是因为模型有恶意而是因为它对任务的理解出了偏差这时候你需要调整的是任务描述或者补充示例而不是放宽策略。4. 完整实操流程从零搭建一个受控的智能体执行环境4.1 环境准备与依赖安装假设你已经在开发一个需要执行 shell 命令的智能体应用现在想给它加上 OpenShell 这层防护。下面是我实际走过一遍的流程你可以照着来。首先确认你的运行环境。OpenShell 的核心依赖是 Linux 内核的一些特性namespace、cgroup、seccomp所以它主要跑在 Linux 上。macOS 和 Windows 上可以通过虚拟机或容器来跑但性能和隔离效果会打折扣。我用的环境是 Ubuntu 22.04内核版本 5.15这个组合比较稳。安装方式我推荐从源码构建因为这样你能清楚地知道每个组件在做什么出问题也容易排查。先装系统依赖sudo apt update sudo apt install -y build-essential cmake pkg-config libseccomp-dev libcap-dev然后拉源码编译git clone https://github.com/openshell/openshell.git cd openshell mkdir build cd build cmake .. -DCMAKE_BUILD_TYPERelease make -j$(nproc) sudo make install编译完成后你会得到几个可执行文件openshell-daemon 是后台服务openshell-cli 是命令行工具openshell-policy 是策略校验工具。先启动 daemonsudo openshell-daemon --config /etc/openshell/daemon.yamldaemon 启动后会监听一个本地 socket智能体通过这个 socket 来提交指令。默认配置下 socket 路径是 /var/run/openshell.sock你可以根据需要改。注意daemon 需要 root 权限来创建沙箱和设置 cgroup 限制但智能体本身不应该以 root 身份运行。正确的做法是 daemon 以 root 启动智能体以普通用户身份通过 socket 与 daemon 通信daemon 在创建沙箱时降权到指定的用户。4.2 策略文件的编写与校验环境准备好之后下一步是写策略文件。我建议从一份最小可用的策略开始跑通之后再逐步细化。最小策略文件长这样version: 1.0 default_action: deny policies: - name: allow_read_workspace match: operation: file_read path_prefix: /workspace action: allow - name: allow_write_output match: operation: file_write path_prefix: /workspace/output action: allow - name: allow_safe_commands match: operation: command_exec command_whitelist: - ls - cat - grep - python3 - pytest action: allow这份策略的意思是默认拒绝一切操作只放行工作目录的读取、输出目录的写入以及白名单内的命令执行。default_action 设为 deny 是关键它保证了任何没有被明确允许的操作都会被拦住。写完策略后用 openshell-policy 校验一下语法和逻辑openshell-policy validate /etc/openshell/policy.yaml校验工具会检查语法错误、规则冲突比如同一优先级下有两条规则匹配同一个操作但决策不同、以及潜在的安全漏洞比如某条 allow 规则的匹配范围过宽。我强烈建议每次改完策略都跑一遍校验我遇到过好几次因为手误把 path_prefix 写成了 / 导致整个文件系统都被放行的情况校验工具能帮你抓住这类错误。校验通过后让 daemon 重新加载策略openshell-cli policy reloadreload 是热加载不会中断正在执行的任务。但要注意已经进入沙箱的指令不会受新策略影响新策略只对 reload 之后提交的指令生效。4.3 智能体侧的接入改造策略配好之后需要改造智能体让它通过 OpenShell 来执行指令而不是直接调用系统 shell。改造的核心是把原来的 subprocess.run 或 os.system 调用替换成 OpenShell 的客户端调用。OpenShell 提供了 Python SDK用起来很直接from openshell import OpenShellClient client OpenShellClient(socket_path/var/run/openshell.sock) def execute_command(command: str, task_id: str, agent_id: str): result client.execute( commandcommand, task_idtask_id, agent_idagent_id, timeout300 ) if result.decision deny: return { status: blocked, reason: result.deny_reason, policy: result.matched_policy } if result.decision require_approval: return { status: pending_approval, approval_id: result.approval_id } return { status: executed, exit_code: result.exit_code, stdout: result.stdout, stderr: result.stderr, duration_ms: result.duration_ms }这段代码的关键点是智能体不再直接执行命令而是把命令提交给 OpenShell由 OpenShell 决定是否执行、怎么执行。返回结果里包含了决策信息智能体可以根据决策结果调整自己的行为。比如当命令被拒绝时智能体可以尝试换一种方式完成任务而不是反复重试同一条被拒的命令。实操心得在改造智能体的时候一定要把 OpenShell 的决策结果反馈给模型。我一开始只是简单地把拒绝信息吞掉结果模型不知道自己的指令被拒了还在那里反复生成类似的命令浪费了大量 token。后来我把拒绝原因和命中的策略名称一起返回给模型它就能理解“哦这个操作不被允许”然后主动换方案。4.4 审批流程的对接对于 require_approval 类型的决策你需要一个审批流程来让人来决定是否放行。OpenShell 本身不提供审批界面它只负责生成审批请求和等待审批结果。审批界面的形式可以很灵活简单的用命令行交互复杂的可以对接企业内部的审批系统。我自己的做法是用一个简单的 Web 界面加消息通知。当有审批请求时OpenShell 会调用你配置的审批回调接口回调接口把请求推送到消息通道审批人在消息里点“通过”或“拒绝”结果再回传给 OpenShell。整个流程的延迟主要取决于审批人的响应速度所以对于高频但低风险的操作我建议不要走审批流程直接放行加记录日志就好否则审批人会疯掉。审批请求里应该包含足够的信息让审批人做判断指令原文、发起指令的智能体、当前任务描述、前序相关指令、命中的策略、以及一个“为什么这条指令需要审批”的说明。信息越充分审批人做决定越快误批和漏批的概率也越低。5. 常见问题与排查技巧实录5.1 策略不生效的几种典型原因策略写了但没生效这是最常见的问题。我排查过的情况大概有这么几类。第一类是策略文件没加载。改完策略文件后忘了执行 reloaddaemon 还在用旧的策略。这个错误很低级但很常见我现在养成了改完策略立刻 reload 的习惯并且在 reload 后跑一条测试指令确认新策略生效。第二类是优先级搞反了。OpenShell 的策略优先级是数字越小优先级越高但有些框架是反过来的。我一开始就搞反了把一条 allow 规则的优先级设得比 deny 规则高结果 deny 规则永远不生效。后来我在策略文件里加了一行注释专门提醒自己优先级的方向。第三类是路径匹配没考虑规范化。前面提过如果策略里写的是 /workspace但指令里的路径是 /workspace/../workspace/file简单的字符串前缀匹配可能匹配不上。OpenShell 默认会对路径做规范化但如果你在策略里用了自定义的匹配函数就要自己处理规范化。第四类是操作类型判断错误。OpenShell 需要把原始指令解析成操作类型file_read、file_write、command_exec 等如果解析器不认识某种指令格式可能会把它归类到错误的操作类型导致策略匹配不上。遇到这种情况可以看审计日志里的 operation 字段确认解析结果是否符合预期。5.2 沙箱内命令执行失败的排查思路命令在沙箱外能跑在沙箱里跑不了这也是高频问题。排查思路是从外到内逐层检查。先看文件系统可见性。沙箱里的文件系统和宿主机不一样很多在宿主机上存在的路径在沙箱里是看不到的。用 openshell-cli 的 inspect 命令可以查看沙箱内的文件系统布局openshell-cli sandbox inspect --task-id task_id --show-filesystem如果命令依赖的某个文件或目录不在沙箱的可见范围内命令就会失败。解决办法是在沙箱配置的 read_only_paths 或 read_write_paths 里把需要的路径加进去。再看环境变量。沙箱默认不继承宿主机的环境变量如果你的命令依赖 PATH、PYTHONPATH 之类的变量需要在沙箱配置里显式设置。我遇到过 python3 命令在沙箱里找不到模块的问题就是因为 PYTHONPATH 没传进去。然后看网络访问。如果命令需要访问网络确认沙箱的网络策略是否允许。OpenShell 默认可能禁止所有网络访问你需要显式配置允许的地址。这里要注意允许网络访问会显著增加风险所以只放行必要的地址不要图省事直接放行所有。最后看资源限制。命令执行到一半被 kill很可能是触发了资源限制。检查审计日志里的资源消耗记录看看是 CPU、内存还是磁盘写入超了。如果是内存超了要么调高限制要么优化命令的内存使用。5.3 性能开销的实测数据与优化建议加一层 OpenShell 肯定会带来性能开销关键是开销有多大、能不能接受。我在自己的环境里做了一组对比测试数据如下操作类型无 OpenShell 耗时有 OpenShell 耗时开销倍数文件读取1KB0.8ms2.1ms2.6x文件写入1KB1.2ms3.5ms2.9x简单命令执行echo3.5ms12ms3.4xPython 脚本执行空脚本45ms68ms1.5xPython 脚本执行含 import320ms355ms1.1x从数据可以看出对于轻量级操作OpenShell 的开销倍数比较明显2 到 3 倍但绝对耗时很小毫秒级。对于重量级操作开销倍数反而小1.1 到 1.5 倍因为 OpenShell 的固定开销被摊薄了。优化建议方面如果你的场景对延迟敏感可以考虑这几个方向。策略缓存对于重复出现的相同指令缓存策略决策结果避免重复计算。沙箱复用同一个任务内的多条指令可以复用同一个沙箱避免反复创建销毁沙箱的开销。异步审计审计日志的写入可以异步化不阻塞指令执行。分级检查低风险操作走快速通道只做最基本的检查高风险操作才走完整流程。5.4 常见问题速查表问题现象可能原因排查方法解决方向指令被拒绝但不知道原因策略命中信息未返回查看审计日志的 matched_policy 字段在智能体侧展示拒绝原因策略改了不生效未 reload 或优先级错误跑测试指令确认检查优先级数字reload 策略调整优先级沙箱内命令找不到文件文件系统可见性限制inspect 沙箱文件系统布局添加路径到可见列表命令执行超时资源限制或死锁查看资源消耗记录和退出码调整限制或优化命令审批请求积压审批流程太慢或太频繁统计审批请求量和响应时间低风险操作改为自动放行审计日志太大日志级别太细或未轮转检查日志级别和轮转配置调整级别配置轮转策略智能体反复重试被拒指令拒绝反馈不充分查看指令序列和拒绝原因向模型提供更详细的拒绝信息6. 一些踩坑之后的个人体会OpenShell 这类框架的价值不在于它能让你的智能体变得绝对安全而在于它把安全从一个“祈祷模型不出错”的玄学问题变成了一个“策略写得够不够细、沙箱配得够不够严、审计跟得够不够紧”的工程问题。工程问题就有工程解法可以迭代、可以度量、可以持续改进。我最大的体会是策略要跟着实际运行数据来调。一开始拍脑袋写的策略要么太松要么太严跑一段时间之后看审计日志你会发现很多你没想到的情况。比如你没想到模型会频繁地尝试读取某个路径或者你没想到某类命令的执行频率这么高。根据实际数据来调整策略比一开始就追求完美策略要务实得多。另一个体会是不要试图用 OpenShell 解决所有安全问题。它管的是智能体执行指令这一层的安全管不了模型本身被越狱、管不了输入数据被污染、管不了输出内容被滥用。它是整个安全体系中的一环需要和其他环节配合。把 OpenShell 当成纵深防御中的一层而不是唯一的一层心态会好很多。最后分享一个实用的小技巧在正式上线之前先用 OpenShell 的“只记录不拦截”模式跑一段时间。这个模式下所有指令都会被放行但策略引擎会记录下“如果按当前策略这条指令会被允许还是拒绝”。跑一周左右你就能拿到一份真实的策略效果报告知道当前策略会拦住多少正常操作、放行多少风险操作。根据这份报告来调策略比直接上线拦截模式要稳妥得多不会因为策略太严把正常业务给拦停了。
