三头盒子在游戏自动化中的实战：HID 注入原理、设备选型与全链路延迟拆解

前面三篇把"看"的问题解决了——采集卡负责把画面从 HDMI 里劫持出来，YOLO 负责从画面里找到目标，DMA 负责从内存里读精确数据。但自动化脚本不只需要"看到"，还需要"做到"——看到敌人后要移动鼠标、要点击、要按键。这一步如果用软件 API（SendInput、mouse_event、PostMessage），在带反作弊的端游里基本等于自首。三头盒子就是解决"怎么把输入送进去而不被检测"这个问题的硬件方案。

这篇文章拆三件事：三头盒子的工作原理（USB HID 协议层面），常见设备的横向对比（KMBox / Arduino / Pico），以及它在采集卡+YOLO+DMA 四件套管线里的精确角色定位和延迟贡献。

什么是三头盒子：三个连接点构成的物理桥

"三头盒子"是自动化圈子的俗称，指的是一类有三个连接端口的硬件输入注入设备。三个"头"分别对接三个独立的设备：

三个头构成的拓扑关系：

三个头各自独立，设备可以根据需要在三种模式间切换：透传模式（真实输入直达目标设备，正常玩游戏）、注入模式（控制 PC 指令合成 HID 输入送入目标设备，自动化运行）、混合模式（真实输入和注入输入叠加，比如玩家移动 + 脚本辅助瞄准）。

为什么不用软件注入？SendInput / mouse_event 这类 Win32 API 在内核层会被反作弊驱动拦截。反作弊通过两种手段检测软件注入：一是 HID 链路检测——真实 USB 设备的输入经过 USB 主控驱动 → HID 类驱动 → 输入栈，而 SendInput 直接从用户态往输入栈里塞数据，中间少了 USB 和 HID 驱动两层，反作弊一查调用来源就能分辨；二是 进程行为检测——自动化脚本进程频繁调用输入 API 的模式特征明显，即使注入到游戏进程内部也能被 hook 抓到。三头盒子从根源上绕开这两层：输入从 USB 物理接口进来，经过完整的 HID 驱动栈，和真实键鼠的电信号路径一模一样——目标设备的操作系统根本无法区分这到底是人按的还是机器按的。

USB HID 协议基础：注入为什么能骗过操作系统

要理解三头盒子的工作原理，得先搞清楚 USB HID（Human Interface Device）协议。HID 是 USB 设备类中最基础的一类，键盘、鼠标、手柄全走这套协议。三头盒子本质上就是一个可编程的 HID 设备——它向目标设备声明自己是键盘/鼠标/手柄，然后按 HID 协议的格式发送输入报告。

设备枚举过程——三头盒子插入目标设备 USB 口的瞬间，会经历以下握手：

第 4 步的报告描述符（Report Descriptor）是关键。它是一段二进制数据，告诉操作系统"我能报告什么输入"。以鼠标为例，一个典型的鼠标报告描述符会声明：

操作系统解析完报告描述符后，就知道：每次收到一份 HID 报告（通常是 4~5 字节的二进制数据），前 1 bit 是左键状态，接下来 2 bit 是右键和中键，然后 2 字节是 X 移动量，2 字节是 Y 移动量，最后 1 字节是滚轮。操作系统把这些数据翻译成鼠标事件，送入输入栈，游戏引擎从输入栈里读到鼠标移动——整个过程和真实 USB 鼠标完全一样。

VID / PID 的重要性。设备描述符里有两个关键字段：VID（Vendor ID，厂商 ID）和 PID（Product ID，产品 ID）。某些游戏的反作弊会检查输入设备的 VID/PID 白名单——如果你的设备 VID 是某个已知自动化盒子的值（比如某些量产 KMBox 的固定 VID），就会被识别。所以好的三头盒子应该支持自定义 VID/PID，伪装成罗技、雷蛇等主流外设的设备描述符。KMBox NET 版和部分 Arduino 方案支持修改 VID/PID。

输入注入全链路：从指令到屏幕响应

自动化脚本发出一条"鼠标右移 100 像素"的指令后，信号经过以下完整链路才最终在屏幕上反映出来：

从这个链路可以看出一个关键事实：三头盒子本身的注入延迟（2~7ms）在整个链路里占比很小。真正的大头是游戏帧渲染（16~33ms）和画面采集（30~50ms 或 DMA 的微秒级）。所以选三头盒子时不必过度追求纳秒级延迟——只要设备本身的注入延迟控制在 10ms 以内，对整条链路的影响就是可控的。

常见种类对比：KMBox / Arduino / Pico / 专用设备

市面上能买到的三头盒子类设备大致分四类，技术参数和适用场景差异很大：

逐项说几个关键差异：

KMBox 系列是自动化圈子里最主流的选择。B 版是最基础的——串口通信，115200 波特率，指令格式简单，Python pyserial 直接对接。B+ 版在 B 的基础上优化了固件，降低了串口到 HID 的转换延迟。NET 版是最强的——通信方式从串口换成了 UDP/TCP，好处是控制 PC 和盒子可以在不同机器甚至不同网段，适合多开场景（一台控制 PC 同时控制多个盒子）。NET 版还支持手柄输入注入（XInput 协议），对主机游戏自动化非常重要。NET 版的 VID/PID 可以通过配置修改，伪装成主流外设。

Arduino 方案是 DIY 最便宜的路线。选 Leonardo 或 Pro Micro，因为它们用的 ATmega32U4 芯片有原生 USB HID 能力——不需要额外的 USB 转串口芯片，直接通过 USB 口模拟键鼠。Arduino 官方的 Keyboard.h 和 Mouse.h 库封装了 HID 报告的构造，写几行代码就能注入输入。优点是便宜、开源、完全可控；缺点是没有透传功能——Arduino 只有一个 USB 口，不能同时接真实键鼠和目标设备，自动化运行时真实键鼠得拔掉。另外 ATmega32U4 只有 32KB Flash 和 2.5KB RAM，跑复杂逻辑够呛。

Raspberry Pi Pico 是 DIY 方案里性价比最高的。RP2040 芯片是双核 ARM Cortex-M0+，一个核跑 USB HID 协议栈，另一个核处理串口通信，互不干扰。26 个 GPIO 引脚可以接额外的 USB Host 模块实现透传。Pico 的 USB HID 能力比 ATmega32U4 更强——可以同时声明为键盘+鼠标+手柄的复合 HID 设备，目标设备看到的是一个"全功能外设"而不是单独的键鼠。Pico 用 C/C++ 开发（基于 TinyUSB 库）或 MicroPython，门槛比 Arduino 高一些但社区资源够用。25 元的价格让它在 DIY 圈子里正在取代 Arduino 的位置。

专用硬件盒子是成品方案，通常集成了采集+注入功能（有些还带 DMA 读取能力），适合不想折腾硬件的团队。价格较高但省去了调试成本，部分产品还提供配套的自动化框架 SDK。缺点是闭源，出问题只能找厂商。

KMBox 串口对接：完整封装类

KMBox B/B+ 的通信协议是二进制串口，指令格式为指令头 + 参数，固定字节长度。下面是完整的 Python 封装类，覆盖鼠标移动、点击、滚轮、键盘全功能：

import serial
import struct
import time

class KMBoxSerial:
    """KMBox B/B+ 串口控制完整封装"""

    # 指令头定义
    CMD_MOUSE_MOVE = 0x01       # 鼠标相对移动
    CMD_MOUSE_CLICK = 0x02      # 鼠标按键
    CMD_KEY = 0x03              # 键盘按键
    CMD_MOUSE_WHEEL = 0x04      # 滚轮
    CMD_MOUSE_MOVE_ABS = 0x05   # 鼠标绝对移动（需设备支持）

    # 鼠标按键常量
    BTN_LEFT = 0
    BTN_RIGHT = 1
    BTN_MIDDLE = 2

    def __init__(self, port='COM3', baudrate=115200):
        self.ser = serial.Serial(port, baudrate, timeout=0.05)
        time.sleep(0.1)  # 串口稳定等待

    def move_relative(self, dx, dy):
        """相对移动鼠标，dx/dy 为像素偏移量（有符号）
        注意：移动量是 HID 报告中的逻辑单位，不等于屏幕像素。
        不同游戏灵敏度不同，需要标定转换系数。"""
        cmd = struct.pack('<Bhh', self.CMD_MOUSE_MOVE, dx, dy)
        self.ser.write(cmd)

    def move_absolute(self, x, y):
        """绝对移动到屏幕坐标（仅 KMBox B+ 以上支持）"""
        cmd = struct.pack('<BHH', self.CMD_MOUSE_MOVE_ABS, x, y)
        self.ser.write(cmd)

    def mouse_down(self, button=BTN_LEFT):
        """按下鼠标按键"""
        cmd = struct.pack('<BBB', self.CMD_MOUSE_CLICK, button, 0x01)
        self.ser.write(cmd)

    def mouse_up(self, button=BTN_LEFT):
        """释放鼠标按键"""
        cmd = struct.pack('<BBB', self.CMD_MOUSE_CLICK, button, 0x00)
        self.ser.write(cmd)

    def click(self, button=BTN_LEFT, hold_time=0.02):
        """完整点击：按下 → 保持 → 释放"""
        self.mouse_down(button)
        time.sleep(hold_time)
        self.mouse_up(button)

    def double_click(self, button=BTN_LEFT, interval=0.03):
        """双击"""
        self.click(button, hold_time=0.01)
        time.sleep(interval)
        self.click(button, hold_time=0.01)

    def wheel(self, amount):
        """滚轮滚动，正值向上，负值向下"""
        cmd = struct.pack('<Bb', self.CMD_MOUSE_WHEEL, amount)
        self.ser.write(cmd)

    def key_down(self, keycode):
        """按下键盘按键
        keycode 使用 USB HID Usage Table 值，不是 ASCII 码：
        a=0x04, b=0x05, ..., z=0x1d
        1=0x1e, 2=0x1f, ...
        Ctrl=0xE0, Shift=0xE1, Alt=0xE2, Win=0xE3"""
        cmd = struct.pack('<BBB', self.CMD_KEY, keycode, 0x01)
        self.ser.write(cmd)

    def key_up(self, keycode):
        """释放键盘按键"""
        cmd = struct.pack('<BBB', self.CMD_KEY, keycode, 0x00)
        self.ser.write(cmd)

    def press_key(self, keycode, duration=0.05):
        """完整按键"""
        self.key_down(keycode)
        time.sleep(duration)
        self.key_up(keycode)

    def combo(self, *keycodes, hold=0.05):
        """组合键：先依次按下，再依次释放（反序）
        用法：kmbox.combo(0xE0, 0x06)  # Ctrl+C"""
        for kc in keycodes:
            self.key_down(kc)
            time.sleep(0.005)
        time.sleep(hold)
        for kc in reversed(keycodes):
            self.key_up(kc)
            time.sleep(0.005)

    def close(self):
        self.ser.close()

几个工程要点：

keycode 不是 ASCII。USB HID 的键码用的是 Usage Table 值，和 ASCII 完全不同。字母 a 的 HID 键码是 0x04 而不是 0x61，数字 1 是 0x1E 而不是 0x31。写代码时建议维护一份映射表，避免手算出错。

相对移动量需要标定。HID 鼠标报告中的移动量是"逻辑单位"，不等于屏幕像素。游戏内的鼠标灵敏度设置、Windows 鼠标加速度、游戏引擎的输入处理逻辑都会影响实际移动距离。同一个 move(100, 0) 指令在不同游戏里移动的屏幕像素数不一样。标定方法：发 move(100, 0)，用采集卡截图测量实际移动像素数，算出转换系数 scale = screen_pixels / hid_units。后续所有移动指令乘以这个系数。

串口写缓冲。ser.write() 写入的数据会进入操作系统的串口写缓冲，KMBox 的固件从串口逐字节读取并解析。如果短时间内连续发送多条指令（比如移动+点击），指令会在缓冲里排队。这不是 bug——但如果你的指令发送频率远超盒子固件的处理速度（通常 > 1000Hz），缓冲会积压导致延迟增大。建议指令间隔不小于 1ms。

KMBox NET 网络版：UDP 通信与多设备控制

NET 版把通信从串口换成了 UDP，指令格式基本一样但传输层完全不同。UDP 的好处是延迟更低（局域网内 0.2~0.5ms，串口通常 0.5~2ms）、支持一对多（一个控制 PC 通过 UDP 广播控制多个盒子，适合多开自动化）：

import socket
import struct
import time

class KMBoxNET:
    """KMBox NET 网络版 UDP 控制封装"""

    CMD_MOUSE_MOVE = 0x01
    CMD_MOUSE_CLICK = 0x02
    CMD_KEY = 0x03
    CMD_MOUSE_WHEEL = 0x04

    def __init__(self, ip='192.168.1.100', port=10000):
        self.sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
        self.sock.settimeout(0.05)
        self.addr = (ip, port)

    def move_relative(self, dx, dy):
        cmd = struct.pack('<Bhh', self.CMD_MOUSE_MOVE, dx, dy)
        self.sock.sendto(cmd, self.addr)

    def mouse_down(self, button=0):
        cmd = struct.pack('<BBB', self.CMD_MOUSE_CLICK, button, 0x01)
        self.sock.sendto(cmd, self.addr)

    def mouse_up(self, button=0):
        cmd = struct.pack('<BBB', self.CMD_MOUSE_CLICK, button, 0x00)
        self.sock.sendto(cmd, self.addr)

    def click(self, button=0, hold_time=0.02):
        self.mouse_down(button)
        time.sleep(hold_time)
        self.mouse_up(button)

    def key_down(self, keycode):
        cmd = struct.pack('<BBB', self.CMD_KEY, keycode, 0x01)
        self.sock.sendto(cmd, self.addr)

    def key_up(self, keycode):
        cmd = struct.pack('<BBB', self.CMD_KEY, keycode, 0x00)
        self.sock.sendto(cmd, self.addr)

    def press_key(self, keycode, duration=0.05):
        self.key_down(keycode)
        time.sleep(duration)
        self.key_up(keycode)


class MultiKMBox:
    """多设备控制器：一个控制 PC 管理多个 KMBox NET"""

    def __init__(self, configs):
        """configs: [{'ip': '192.168.1.100', 'port': 10000}, ...]"""
        self.boxes = [KMBoxNET(c['ip'], c.get('port', 10000)) for c in configs]

    def move_all(self, dx, dy):
        """所有设备同步移动"""
        for box in self.boxes:
            box.move_relative(dx, dy)

    def click_all(self, button=0):
        """所有设备同步点击"""
        for box in self.boxes:
            box.click(button)

    def move_individual(self, targets):
        """各设备独立移动
        targets: [(dx, dy), (dx, dy), ...] 长度等于设备数"""
        for box, (dx, dy) in zip(self.boxes, targets):
            box.move_relative(dx, dy)

UDP 的丢包问题。UDP 不保证送达——如果交换机或网卡在指令发送瞬间拥塞，数据包直接丢弃，KMBox 收不到指令就不会注入输入。对于移动指令，丢一次影响不大（下一帧会补上）；对于点击指令，丢包意味着漏了一次攻击。关键操作（如射击点击）建议发三遍冗余——连续发三次相同指令，只要有一次到达就行：

def reliable_click(self, button=0, hold_time=0.02):
    """冗余点击：连发三次降低丢包影响"""
    for _ in range(3):
        self.mouse_down(button)
        time.sleep(hold_time)
        self.mouse_up(button)
        time.sleep(0.002)  # 间隔 2ms 避免被合并

Arduino HID 方案：Python 端 + 固件端

Arduino 方案需要两端代码：Python 端通过串口发送指令，Arduino 端解析指令并调用 HID 库注入输入。Python 端封装和 KMBox 类似，但指令格式是 ASCII 字符串（方便调试）：

import serial
import time

class ArduinoHID:
    """Arduino Leonardo/Micro HID 控制封装（ASCII 协议）"""

    def __init__(self, port='COM5', baudrate=115200):
        self.ser = serial.Serial(port, baudrate, timeout=0.05)
        # Arduino Leonardo 串口连接会触发重启，等待 2 秒
        time.sleep(2)

    def move(self, dx, dy):
        """鼠标相对移动，格式: M,dx,dy\\n"""
        cmd = f"M,{dx},{dy}\n"
        self.ser.write(cmd.encode())

    def click(self, button='L'):
        """鼠标点击，格式: C,button\\n"""
        self.ser.write(f"C,{button}\n".encode())

    def mouse_down(self, button='L'):
        """格式: MD,button\\n"""
        self.ser.write(f"MD,{button}\n".encode())

    def mouse_up(self, button='L'):
        """格式: MU,button\\n"""
        self.ser.write(f"MU,{button}\n".encode())

    def key_press(self, key_char):
        """按键，格式: K,key\\n"""
        self.ser.write(f"K,{key_char}\n".encode())

    def key_down(self, key_char):
        self.ser.write(f"KD,{key_char}\n".encode())

    def key_up(self, key_char):
        self.ser.write(f"KU,{key_char}\n".encode())

    def close(self):
        self.ser.close()

Arduino 端固件代码（烧录到 Leonardo / Pro Micro）：

#include <Keyboard.h>
#include <Mouse.h>

void setup() {
    Serial.begin(115200);
    // Leonardo 的 CDC 串口需要等待就绪
    while (!Serial) {
        ;
    }
    Keyboard.begin();
    Mouse.begin();
}

void loop() {
    if (Serial.available()) {
        String cmd = Serial.readStringUntil('\n');
        cmd.trim();

        if (cmd.length() == 0) return;

        char type = cmd[0];

        switch (type) {
            case 'M': {  // Mouse move: M,dx,dy
                int c1 = cmd.indexOf(',');
                int c2 = cmd.indexOf(',', c1 + 1);
                int dx = cmd.substring(c1 + 1, c2).toInt();
                int dy = cmd.substring(c2 + 1).toInt();
                Mouse.move(dx, dy, 0);
                break;
            }
            case 'C': {  // Click: C,button
                int c = cmd.indexOf(',');
                char btn = cmd.charAt(c + 1);
                if (btn == 'L') Mouse.click(MOUSE_LEFT);
                else if (btn == 'R') Mouse.click(MOUSE_RIGHT);
                else if (btn == 'M') Mouse.click(MOUSE_MIDDLE);
                break;
            }
            case 'M': {  // MD/MU: Mouse down/up
                // 已被上面的 M 匹配，实际用前缀判断
                break;
            }
        }

        // 更健壮的解析：按前缀判断
        if (cmd.startsWith("MD,")) {
            char btn = cmd.charAt(3);
            if (btn == 'L') Mouse.press(MOUSE_LEFT);
            else if (btn == 'R') Mouse.press(MOUSE_RIGHT);
        } else if (cmd.startsWith("MU,")) {
            char btn = cmd.charAt(3);
            if (btn == 'L') Mouse.release(MOUSE_LEFT);
            else if (btn == 'R') Mouse.release(MOUSE_RIGHT);
        } else if (cmd.startsWith("K,")) {
            char key = cmd.charAt(2);
            Keyboard.press(key);
            delay(50);
            Keyboard.release(key);
        } else if (cmd.startsWith("KD,")) {
            char key = cmd.charAt(3);
            Keyboard.press(key);
        } else if (cmd.startsWith("KU,")) {
            char key = cmd.charAt(3);
            Keyboard.release(key);
        }
    }
}

Arduino 方案的串口重启问题。Leonardo / Pro Micro 的 USB 串口是 CDC 虚拟串口，每次 Python 打开串口时 DTR 信号变化会触发 Arduino 重启。这就是为什么 __init__ 里要 sleep(2)——等重启完成。如果不想等，可以在串口打开后立即发一个复位指令，或者在 Arduino 的复位脚加一个 10μF 电容抑制自动复位。Pico 没有这个问题——RP2040 的 USB CDC 不会因 DTR 触发重启。

ASCII 协议 vs 二进制协议。上面的 Arduino 代码用了 ASCII 字符串协议（"M,100,50\n"），好处是可以直接在串口监视器里调试，坏处是每条指令的解析开销大——readStringUntil() 和 substring().toInt() 都是字符串操作，在 ATmega32U4 上每条指令解析耗时 0.5~1ms。如果追求低延迟，应该用二进制协议（和 KMBox 一样的 struct.pack），Arduino 端直接 Serial.readBytes() 读固定长度字节，解析开销 < 0.1ms。

在自动化图色脚本中的角色定位

把前面四篇文章串起来，完整的自动化架构是这样的：

三头盒子是整个管线的最后一环——前面所有环节做的都是"感知"，只有三头盒子做的是"行动"。没有它，你的脚本看得到敌人但打不了枪、找得到资源但采不了矿。它的延迟（2~7ms）在整条链路里占比不大，但如果选错设备或代码写得不好，这个数字可以膨胀到 20ms 以上，直接影响操作的实时性。

四件套完整管线：采集卡 + YOLO + 三头盒子

把采集卡（数据采集）+ YOLO（目标检测）+ 三头盒子（输入注入）串成完整的三线程管线。DMA 作为可选的精确数据源可以旁路接入决策层，但核心管线是这三个：

import cv2
import serial
import struct
import threading
import time
import numpy as np

class FullAutoPipeline:
    """采集卡 + YOLO + 三头盒子 完整自动化管线
    三线程架构：采集线程 + 检测线程 + 执行线程，各跑各的，锁解耦"""

    def __init__(self, capture_device=1, kmbox_port='COM3',
                 yolo_engine=None, screen_w=1920, screen_h=1080):
        # === 数据采集层：采集卡 ===
        self.cap = cv2.VideoCapture(capture_device, cv2.CAP_DSHOW)
        self.cap.set(cv2.CAP_PROP_FRAME_WIDTH, screen_w)
        self.cap.set(cv2.CAP_PROP_FRAME_HEIGHT, screen_h)
        self.cap.set(cv2.CAP_PROP_FPS, 60)
        self.cap.set(cv2.CAP_PROP_BUFFERSIZE, 1)
        self.cap.set(cv2.CAP_PROP_FOURCC, cv2.VideoWriter_fourcc('Y','U','Y','V'))

        # === 执行层：三头盒子（KMBox 串口）===
        self.kmbox = serial.Serial(kmbox_port, 115200, timeout=0.05)
        time.sleep(0.1)

        # === YOLO 引擎（伪代码占位，实际用 TensorRT 推理器）===
        self.yolo = yolo_engine
        self.screen_w = screen_w
        self.screen_h = screen_h
        # 鼠标移动标定系数（需实测）
        self.move_scale_x = 1.5
        self.move_scale_y = 1.5

        # === 共享状态 ===
        self.latest_frame = None
        self.frame_lock = threading.Lock()
        self.latest_detections = []
        self.det_lock = threading.Lock()
        self.running = True
        self.stats = {'capture_fps': 0, 'detect_fps': 0, 'action_fps': 0}

        # === 线程 ===
        self.threads = [
            threading.Thread(target=self._capture_loop, daemon=True),
            threading.Thread(target=self._detect_loop, daemon=True),
            threading.Thread(target=self._action_loop, daemon=True),
        ]

    def _capture_loop(self):
        """采集线程：持续抓帧，帧覆盖策略（只保留最新帧）"""
        frame_count = 0
        last_fps_time = time.time()
        while self.running:
            ret, frame = self.cap.read()
            if ret:
                with self.frame_lock:
                    self.latest_frame = frame
                frame_count += 1
                now = time.time()
                if now - last_fps_time >= 1.0:
                    self.stats['capture_fps'] = frame_count
                    frame_count = 0
                    last_fps_time = now

    def _detect_loop(self):
        """检测线程：取最新帧做 YOLO 推理"""
        det_count = 0
        last_fps_time = time.time()
        while self.running:
            with self.frame_lock:
                frame = self.latest_frame.copy() if self.latest_frame is not None else None
            if frame is None:
                time.sleep(0.001)
                continue

            # YOLO 推理（实际调用 TensorRT 推理器）
            if self.yolo:
                detections = self.yolo.detect(frame)
            else:
                detections = []

            with self.det_lock:
                self.latest_detections = detections

            det_count += 1
            now = time.time()
            if now - last_fps_time >= 1.0:
                self.stats['detect_fps'] = det_count
                det_count = 0
                last_fps_time = now

    def _action_loop(self):
        """执行线程：根据检测结果通过三头盒子注入输入"""
        act_count = 0
        last_fps_time = time.time()
        while self.running:
            with self.det_lock:
                dets = self.latest_detections.copy()

            if not dets:
                time.sleep(0.001)
                continue

            # 决策逻辑：选择最优先目标
            target = self._select_target(dets)
            if target is None:
                continue

            # 计算鼠标移动量：目标中心 → 屏幕中心
            tx = target['x'] + target['w'] // 2
            ty = target['y'] + target['h'] // 2
            cx, cy = self.screen_w // 2, self.screen_h // 2
            dx = int((tx - cx) * self.move_scale_x)
            dy = int((ty - cy) * self.move_scale_y)

            # 限制单次移动量，防止过冲
            dx = max(-200, min(200, dx))
            dy = max(-200, min(200, dy))

            # 通过三头盒子注入鼠标移动
            self._kmbox_move(dx, dy)
            time.sleep(0.01)

            # 如果目标在准星附近（距离 < 30px），注入点击
            if abs(tx - cx) < 30 and abs(ty - cy) < 30:
                self._kmbox_click()

            act_count += 1
            now = time.time()
            if now - last_fps_time >= 1.0:
                self.stats['action_fps'] = act_count
                act_count = 0
                last_fps_time = now

    def _select_target(self, detections):
        """从检测结果中选择最优先目标
        策略示例：选择离屏幕中心最近的目标"""
        if not detections:
            return None
        cx, cy = self.screen_w // 2, self.screen_h // 2
        best = None
        best_dist = float('inf')
        for det in detections:
            tx = det['x'] + det['w'] // 2
            ty = det['y'] + det['h'] // 2
            dist = ((tx - cx) ** 2 + (ty - cy) ** 2) ** 0.5
            if det.get('class_name') == 'enemy' and dist < best_dist:
                best = det
                best_dist = dist
        return best

    def _kmbox_move(self, dx, dy):
        cmd = struct.pack('<Bhh', 0x01, dx, dy)
        self.kmbox.write(cmd)

    def _kmbox_click(self):
        self.kmbox.write(struct.pack('<BBB', 0x02, 0, 0x01))  # left down
        time.sleep(0.015)
        self.kmbox.write(struct.pack('<BBB', 0x02, 0, 0x00))  # left up

    def run(self):
        for t in self.threads:
            t.start()

    def stop(self):
        self.running = False
        time.sleep(0.1)
        self.cap.release()
        self.kmbox.close()

    def get_stats(self):
        return self.stats.copy()

三线程解耦的核心价值。采集线程以 60fps 持续抓帧（~16ms/帧），检测线程以 30~60fps 做推理（~15ms/帧），执行线程以 50~100Hz 注入输入（~10ms/次）。三者频率不同，如果不解耦，最慢的环节会拖垮整条管线——比如如果串行执行，一帧的处理时间 = 采集 16ms + 检测 15ms + 决策 1ms + 注入 5ms = 37ms，实际只能跑 27fps。三线程后，每个环节独立跑满自己的频率，采集 60fps、检测 50fps、执行 80fps 互不拖累。

输入注入延迟全链路拆解

把"从看到目标到完成点击"的全链路延迟拆开，对比采集卡方案和 DMA 方案：

从这张表可以看出两个关键结论：

结论一：三头盒子不是延迟瓶颈。在采集卡方案里，三头盒子（传输 + 注入 = 2~7ms）只占总延迟的 5~10%。瓶颈是采集卡的 30~50ms 和游戏帧渲染的 16~33ms。即使把三头盒子换成纳秒级延迟的理想设备，总延迟也就降低几个百分点。所以选三头盒子时不需要纠结那 2~3ms 的延迟差异——稳定性、兼容性、透传功能比延迟更重要。

结论二：DMA 方案的优势在数据采集层不在执行层。DMA 方案总延迟 22~60ms，比采集卡方案快了 30~45ms——但这 30~45ms 全部来自数据采集层（DMA 读内存 5~20μs vs 采集卡抓帧 30~50ms），和三头盒子无关。三头盒子在两种方案里的延迟贡献一模一样。如果追求极致实时性，应该投入精力到数据采集层（换 DMA）而不是执行层。

帧同步与输入频率匹配

一个容易被忽略的问题：采集帧率、检测帧率和输入注入频率三者之间的关系。如果三者不匹配，会出现"看到的目标已经过时了但还在往那个位置移动"的情况——这在快速移动的场景（FPS 对枪）中尤其致命。

采集 60fps + 检测 60fps + 注入 100Hz 的匹配策略：

def _action_loop_with_prediction(self):
    """带预测补偿的执行线程"""
    while self.running:
        with self.det_lock:
            dets = self.latest_detections.copy()
            det_timestamp = self.latest_det_time  # 检测完成的时间戳

        if not dets:
            time.sleep(0.001)
            continue

        # 计算从检测完成到现在的延迟
        detection_lag = time.time() - det_timestamp

        target = self._select_target(dets)
        if target is None:
            continue

        # 如果有目标速度信息，做预测补偿
        if 'velocity' in target:
            # 目标在 detection_lag 时间内移动的距离
            pred_x = target['x'] + target['velocity'][0] * detection_lag
            pred_y = target['y'] + target['velocity'][1] * detection_lag
        else:
            # 没有速度信息，用上一帧位置差估算
            if self._last_target_pos is not None:
                dt = det_timestamp - self._last_det_time
                if dt > 0:
                    vx = (target['x'] - self._last_target_pos[0]) / dt
                    vy = (target['y'] - self._last_target_pos[1]) / dt
                    pred_x = target['x'] + vx * detection_lag
                    pred_y = target['y'] + vy * detection_lag
                else:
                    pred_x, pred_y = target['x'], target['y']
            else:
                pred_x, pred_y = target['x'], target['y']

        self._last_target_pos = (target['x'], target['y'])
        self._last_det_time = det_timestamp

        # 计算移动量
        tx = pred_x + target['w'] // 2
        ty = pred_y + target['h'] // 2
        cx, cy = self.screen_w // 2, self.screen_h // 2
        dx = int((tx - cx) * self.move_scale_x)
        dy = int((ty - cy) * self.move_scale_y)
        dx = max(-200, min(200, dx))
        dy = max(-200, min(200, dy))

        self._kmbox_move(dx, dy)

        if abs(tx - cx) < 30 and abs(ty - cy) < 30:
            self._kmbox_click()

输入频率不要超过游戏帧率。如果游戏跑 60fps（每 16.7ms 渲染一帧），你的执行线程以 200Hz（每 5ms 注入一次）狂发移动指令，结果就是：游戏在一帧内收到了 3~4 条移动指令，但只会用最后一条来渲染下一帧——前面的指令全浪费了，还白白占用了三头盒子的串口带宽。输入注入频率应该和游戏帧率匹配或略高（60~100Hz 足够），没必要追求 1000Hz 的注入频率。

常见踩坑记录

选型建议：不同场景推荐方案

四篇技术栈串联总结

到这里，采集卡、YOLO、DMA、三头盒子四篇文章形成了一个完整的技术栈闭环。把四者在自动化管线中的定位最终汇总：

四者构成的完整管线：采集卡/DMA 把数据从目标设备物理隔离出来 → YOLO 在控制 PC 上做识别 → 决策逻辑判断该做什么 → 三头盒子把决策转化为物理输入送回目标设备。整条链路在目标设备上不留任何软件痕迹——没有截屏 API 调用、没有进程注入、没有驱动 hook、没有可疑进程。这就是物理隔离方案相对于软件方案的核心价值：不是"能不能做到"的问题，而是"做了之后能不能不被发现"的问题。

但要注意：物理隔离不是万能的。反作弊系统的检测手段也在升级——PCIe 设备白名单、IOMMU 硬件隔离、内存加密等技术正在缩小物理方案的生存空间。这套技术栈的寿命取决于反作弊厂商和硬件厂商之间的博弈。在它能用的窗口期内，把它做到极致就是最好的策略。