lijianfei.com

在操作系统生态中，“应用多开（Multi-Instancing）” 始终是无数高阶用户与开发者的刚性需求：

• 工作与生活需要两套独立的微信、QQ、Telegram、飞书（Lark）；
• 跨国业务与跨境运营需要多套独立的 Chrome、Edge 或 Arc 浏览器，各自绑定专属的独立 SOCKS5 / HTTP 代理与隔离 Cookie；
• 在 AI Coding Agent 爆发的今天，开发者更需要在同一台 Mac 上并发运行多个登录不同团队配额与 API Key 的 Cursor、Claude Desktop、OpenAI ChatGPT / Codex、Google Antigravity 与 Gemini。

然而，在 Windows 和 Android 上轻而易举的多开，在 macOS 上却是一道令人望而生畏的技术天堑。

传统的 macOS 多开方案几乎全军覆没：

• 方案一：终端 open -n /Applications/WeChat.app —— 仅仅是拉起同一个二进制，共享同一份 ~/Library/Application Support/ 本地数据库。由于 SQLite 锁互斥，轻则两边同时掉线、记录覆盖，重则直接导致数据库死锁损坏；
• 方案二：复制 App 包并修改 Info.plist —— 在 macOS 严格的代码签名机制下，篡改 Plist 会直接破坏签名哈希，触发 Gatekeeper 拦截报“应用已损坏”；
• 方案三：编写 Shell 启动脚本替换二进制（Wrapper Script） —— 脚本中执行 exec /path/to/real_bin 会迫使 Darwin 内核递增进程版本号（PIDVersion）。macOS 14 (Sonoma) 和 macOS 15 (Sequoia) 的 RunningBoardServices (RBS) 在接收 XPC 连接时校验 audit_token，发现 PIDVersion 失配便会静默丢弃连接 —— 其惨痛后果是：顶部菜单栏状态图标（NSStatusItem）消失、系统通知中心（usernoted）弹窗彻底哑火、Dock 栏多图标乱跳！
• 方案四：Electron / Chromium 的进程单例锁（ProcessSingleton） —— 飞书、Chrome、ChatGPT 等现代跨平台应用在启动阶段会执行跨进程单例探测（ProcessSingleton::NotifyOtherProcessOrCreate），检测到已有实例在运行便立即向前台发送信号并闪退退出（Exit code 34）。

近期在 GitHub 斩获高度关注的开源神器 aitobox/ATBClone，以近乎“降维打击”的底层系统工程与逆向技艺，给出了 macOS 上迄今为止最优雅、最彻底的工业级答案：

它不仅支持极速零磁盘开销的“软分身”与深度隔离的“硬分身”，更独创了纯 Python 的 Mach-O 动态库原生无感注入（Zero-Execv）、ARM64 汇编指令级 ProcessSingleton 单例锁修补、CEF 混合架构沙盒剥离、独立代理路由，以及数据与逻辑完全解耦的“母体升级永不丢数据”架构！

本文将以系统架构、汇编逆向与 Mach-O 底层工程的第一视角，深度剖析 ATBClone 的全链路设计精髓。

🧭 一张图看清：macOS 多开的四大深坑与 ATBClone 的解法

在拆解源码之前，我们先通过架构流向图看清传统方案为何崩溃，以及 ATBClone 的动态分流拓扑：

flowchart TD
    subgraph TraditionalPains["传统 macOS 多开方案的四大致命硬伤"]
        T1["open -n 共享目录 ➔ SQLite 死锁 / 凭据互相踢下线"]
        T2["篡改 Info.plist ➔ 代码签名破损 / Gatekeeper 拦截提示损坏"]
        T3["Shell Wrapper 脚本 ➔ execv 导致 PIDVersion 递增 ➔ RBS 抛弃通知与托盘图标"]
        T4["Chromium / Electron 单例锁 ➔ ProcessSingleton 检测到主进程直接闪退 (Exit 34)"]
    end

    TraditionalPains ==>|ATBClone 底层引擎彻底降维打击| ATBArchitecture

    subgraph ATBArchitecture["ATBClone 双引擎架构与核心技术"]
        InputApp["目标应用 (.app)"] --> Prober{"App Prober 架构研判<br/>(Frameworks / Entitlements / Mach-O)"}
        
        Prober -->|Chromium / 现代代码编辑器| SoftEngine["<b>软分身引擎 (Soft Clone)</b><br/>• &lt; 200KB 轻量 App 外壳<br/>• 启动参数注入 --user-data-dir<br/>• 软链接白名单 (Keychain / SSH)"]
        
        Prober -->|Cocoa 原生 / 社交应用 / AI 客户端| HardEngine["<b>硬分身引擎 (Hard Clone)</b><br/>• CFBundleIdentifier 身份基因重组<br/>• Mach-O LC_LOAD_DYLIB 原生动态库注入<br/>• ARM64 汇编单例锁字节级修补<br/>• 沙盒剥离与 Ad-Hoc 深度递归重签名"]
    end

核心黑科技一：原生动态库无感注入（In-Process Dylib Injection）与 Mach-O 字节重写

这是 ATBClone 最具技术含金量、也是彻底解决 “分身应用没有通知、没有菜单栏图标” 世纪难题的核心发明。

1. 为什么传统的 execv 包装在 macOS 14/15 上必死？

许多早期的多开工具，做法是将应用内部真实的主二进制（例如 WeChat）重命名为 WeChat.bin，然后用一个同名的 Shell 脚本或轻量 C 二进制作为代理壳（Wrapper）。该脚本在导出环境变量（export HOME=...）后，通过 execv 启动 WeChat.bin。

这在旧版本 macOS 上看似可行，但在现代 macOS（Sonoma / Sequoia）中引入了极度严苛的 RunningBoardServices (RBS) 机制：

1. macOS 核心守护进程 usernoted（通知中心）和 MenuBarAgent（菜单栏驻留图标）在处理应用的 XPC 注册请求时，会深入校验调用者的内核安全凭证（audit_token）；
2. 当进程执行 execv 进行二进制切换时，Darwin 内核会递增该进程的进程版本计数器（PIDVersion）；
3. RBS 发现应用在 LaunchServices 注册的 PIDVersion 与实际发起 XPC 连接的 PIDVersion 不一致，判定为非法进程劫持，直接报告 mismatched pid version 并直接丢弃连接！

最终表象就是：你的微信分身能正常打开聊天窗口，但别人发来消息时系统通知横幅从不弹出；顶部状态栏的小图标彻底消失；Dock 栏图标在点击时经常跳回主应用！

2. ATBClone 的零进程替换哲学：LC_LOAD_DYLIB 直接注入

为了从源头上消除 execv，ATBClone 研发了基于 Mach-O Load Commands 原生注入 的架构：

sequenceDiagram
    autonumber
    participant LS as macOS LaunchServices
    participant MachO as 原始 Mach-O 二进制 (未被重命名)
    participant Dylib as libatbclone_env.dylib (constructor)
    participant RBS as RunningBoardServices / usernoted
    participant Main as 原生 main() 函数入口

    LS->>MachO: 启动应用 (PIDVersion = 1)
    Note over MachO: dyld 装载 Mach-O 镜像头部
    MachO->>Dylib: 触发 LC_LOAD_DYLIB 指令，装载动态库
    activate Dylib
    Note over Dylib: 执行 __attribute__((constructor))<br/>1. 备份真实 REAL_USER_HOME<br/>2. setenv("HOME", clone_data_home)<br/>3. setenv("TMPDIR", clone_data_tmp)<br/>4. setenv("HTTP_PROXY", proxy_url)
    Dylib-->>MachO: 环境重定向完成 (进程未发生任何替换!)
    deactivate Dylib
    MachO->>Main: 进入真实程序 main()
    Main->>RBS: 发起 XPC 请求注册通知与状态栏
    Note over RBS: 校验 audit_token: PIDVersion 完美匹配 (仍为 1)!
    RBS-->>Main: 授权通过：通知横幅正常弹窗，菜单栏图标常驻！

3. 纯 Python 实现的 Mach-O 头部二进制重写

ATBClone 没有依赖外部笨重的工具（如 optool 或 insert_dylib），而是在 src/atbclone/core/engines.py 中用纯 Python 的 struct 模块实现了对 Mach-O 胖二进制（Universal Fat Binary）及 64 位单架构二进制的精准缝合：

# ATBClone Mach-O LC_LOAD_DYLIB 核心注入逻辑节选
import struct

def insert_dylib(macho_path, dylib_path):
    with open(macho_path, 'rb') as fp:
        data = bytearray(fp.read())
    magic = struct.unpack('<I', data[:4])[0]
    archs = []
    
    # 识别 Fat Universal Binary (0xCAFEBABE / 0xBEBAFECA)
    if magic in (0xcafebabe, 0xbebafeca):
        nfat = struct.unpack('>I', data[4:8])[0]
        for i in range(nfat):
            cputype, cpusubtype, offset, size, align = struct.unpack('>IIIII', data[8+i*20:28+i*20])
            archs.append(offset)
    # 识别 64-bit Mach-O (0xFEEDFACF / 0xCFFAEDFE)
    elif magic in (0xfeedfacf, 0xcffaedfe, 0xfeedface, 0xcefaedfe):
        archs.append(0)
    else:
        return

    # 构造 LC_LOAD_DYLIB 结构体 (0x0c) 并进行 8 字节对齐
    dylib_bytes = dylib_path.encode('utf-8') + b'\x00'
    cmdsize = 24 + len(dylib_bytes)
    if cmdsize % 8 != 0:
        cmdsize += (8 - (cmdsize % 8))
        dylib_bytes = dylib_bytes.ljust(cmdsize - 24, b'\x00')
    load_cmd = struct.pack('<IIIIII', 0x0c, cmdsize, 24, 0, 0, 0) + dylib_bytes

    # 遍历每个架构切片 (arm64 与 x86_64)
    for offset in archs:
        m_magic, cputype, cpusubtype, filetype, ncmds, sizeofcmds, flags, reserved = struct.unpack(
            '<IIIIIIII', data[offset:offset+32]
        )
        end_of_cmds = offset + 32 + sizeofcmds
        existing_cmds = bytes(data[offset+32:end_of_cmds])
        
        # 幂等校验：防止重复注入
        if dylib_path.encode('utf-8') in existing_cmds:
            continue
            
        # 在 Load Commands 末尾的空闲 Padding 区域写入新指令
        data[end_of_cmds:end_of_cmds+cmdsize] = load_cmd
        ncmds += 1
        sizeofcmds += cmdsize
        # 回写更新后的头部头部指令数量与总大小
        data[offset:offset+32] = struct.pack(
            '<IIIIIIII', m_magic, cputype, cpusubtype, filetype, ncmds, sizeofcmds, flags, reserved
        )

    with open(macho_path, 'wb') as fp:
        fp.write(data)

注入的动态库 libatbclone_env.dylib 内部极简且高效，通过 C 语言全局构造函数拦截初始化：

#include <stdlib.h>
#include <unistd.h>
#include <stdio.h>
#include <string.h>

__attribute__((constructor))
static void atbclone_env_init(void) {
    const char *orig_home = getenv("HOME");
    if (orig_home && !getenv("REAL_USER_HOME")) {
        setenv("REAL_USER_HOME", orig_home, 1);
    }
    // 注入当前分身绑定的专属私有目录与代理
    setenv("HOME", "/Users/username/ATBClone/Data/WeChat2/Home", 1);
    setenv("TMPDIR", "/Users/username/ATBClone/Data/WeChat2/Tmp", 1);
    setenv("HTTP_PROXY", "http://127.0.0.1:7890", 1);
    setenv("HTTPS_PROXY", "http://127.0.0.1:7890", 1);
}

4. 头部安全空间探测（Headroom Probing）与自愈降级

直接修改 Mach-O Header 最大的隐患在于：如果某些应用在编译时保留的头部填充间隙（Header Padding）极小，强行插入新的 Load Command 会直接覆盖第一段代码节（Section Header），导致 Mach-O 二进制彻底损毁崩溃。

ATBClone 在 _check_macho_injection_headroom 中实现了严格的静态空间探测：

$\text{Padding} = \text{first\_section\_offset} - (32 + \text{sizeofcmds})$

• 若 $\text{Padding} \ge \text{cmdsize}$：判定为安全空间充足，全自动执行动态库无损注入（例如微信 4.x 的 Padding 冗余空间超过 50KB，极其安全）；
• 若 $\text{Padding} < \text{cmdsize}$ 或非标准编译：系统不会强行破坏二进制，而是平滑且优雅地自动降级为原生编译的 Mach-O C Launcher（动态调用 clang -O2 即时编译出专属二进制壳），确保分身构建 100% 成功。

核心黑科技二：ARM64 指令级 ProcessSingleton 汇编修补

对于基于 Electron 或 Chromium 内核的应用（如飞书/Lark、ChatGPT 桌面版、网易云音乐等），即使修改了 CFBundleIdentifier 并更换了数据目录，应用依然无法实现真正的多开。

1. 致命的单例互斥锁（ProcessSingleton）

Chromium 底层设计了 ProcessSingleton 机制：

1. 启动时，它会向目标配置目录尝试创建 SingletonLock 符号链接与 SingletonSocket IPC 管道；
2. 如果检测到锁被占用，或者框架内部的共享总线被同一机器上的其他实例占用，它会调用嵌入式框架中的：
   ProcessSingleton::NotifyOtherProcessOrCreate()
3. 这个函数会向已经运行的主实例发送 IPC 激活通知，随后当前进程直接调用 exit(34) 退出！

2. 反汇编特征扫描与 ARM64 字节原地 Patch

在 engines.py 的 _build_singleton_patch_cmd 中，ATBClone 展现了极高水准的二进制逆向功底：它在克隆时直接对 Contents/Frameworks/ 下的大型二进制框架进行动态汇编修补！

# 汇编级单例锁修补核心机制解析
target_str = b"Failed to create a ProcessSingleton for your profile directory."
# 1. 在嵌入式 Mach-O 框架中搜索特征错误字符串
str_idx = data.find(target_str)
page = str_idx & ~0xFFF
page_offset = str_idx & 0xFFF

# 2. 向前反查引用该字符串的 ARM64 ADRP + ADD 指令对 (PC-Relative 寻址)
for i in range(0, len(data) - 8, 4):
    w1, w2 = struct.unpack_from("<II", data, i)
    if (w1 & 0x9F000000) == 0x90000000: # 匹配 ADRP
        # 还原 imm 偏移量...
        if (i & ~0xFFF) + (imm << 12) == page:
            if (w2 & 0xFFC00000) == 0x91000000 and ((w2 >> 10) & 0xFFF) == page_offset: # 匹配 ADD
                found_pc = i
                break

# 3. 继续向前定位进行单例状态比较的 CMP 指令与关键跳转分支 BL
# 将 BL NotifyOtherProcessOrCreate 的调用点直接篡改为:
# mov w0, #0 (0x52800000); nop (0xD503201F)
# 彻底伪造单例创建永远返回成功 (0)!
struct.pack_into("<II", data, pos, 0x52800000, 0xD503201F)

通过将这几个机器码字节原地打入动态库中，任何基于 Chromium 的应用在启动时，单例检查函数永远判定为“当前进程是全机唯一的首发主实例”，从根本上解除了多开互斥魔咒！

核心黑科技三：CEF (Chromium Embedded Framework) 与沙盒穿透

部分大型复杂客户端（如早期企业微信、特定内部协同工具）采用了混合架构的 CEF。针对这类硬核应用，ATBClone 在 _build_cef_patch_cmd 中提供了深度二进制穿透补丁：

1. 强制开启 no_sandbox = 1：搜索 cef_initialize 设置结构体的拷贝点，将 no_sandbox 标志位由 0 硬编码改写为 1（28008052）；
2. 剔除 Seatbelt 子进程沙盒限制：自动扫描 ChildProcessLauncherHelper 中编译 Apple Seatbelt Profile 的代码分支，将其直接 patch 为 b launch 强制无条件直跳执行，彻底规避 macOS 内核沙盒对 Helper 子进程的访问拦截；
3. 消除 GPU 崩溃死锁：针对无沙盒环境下 Chromium 频繁抛出的 GPU process isn't usable. Goodbye. 致命中断（FallBackToNextGpuMode FATAL），精准拦截并使其安全返回，保障图形渲染管线平稳运转。

核心黑科技四：v1.4.0 独门武器 —— 飞书/Lark 与 ChatGPT 桌面版专属 Hook

在最新发布的 v1.4.0 里程碑中，ATBClone 攻克了社区呼声最高的两大难关：飞书（Lark） 与 OpenAI ChatGPT 桌面版 的彻底物理多开。

1. 飞书/Lark 多实例深度隔离（libatbclone_feishu_hook.dylib）

飞书（com.electron.lark）的多开难点在于：它的内部不仅有 Electron，还在底层大量调用了 Cocoa 原生 API：

• 它通过 NSSearchPathForDirectoriesInDomains 获取沙盒路径；
• 在固定公共路径下抢占 LarkShell 和 IPC Socket；
• 如果同时安装两个飞书，系统外部点击 feishu:// 链接时会发生 URL Scheme 抢占冲突。

ATBClone 创新构建了针对飞书的专用拦截库：

• 动态方法 Interposing：拦截底层 POSIX stat/open 与 Cocoa 目录获取函数，将飞书内部对宿主公共目录的寻址强制重定向至当前分身的专属隔离数据目录；
• 自动净化 URL Scheme：克隆引擎会自动解析并剥离分身 Info.plist 中的 CFBundleURLTypes，确保分身绝不抢夺母体应用的系统级协议调度。

2. OpenAI ChatGPT 桌面版与 Codex 多账号独立

ChatGPT 桌面版（com.openai.chat）包含极强的原生 Cocoa 封装：

• ATBClone 注入 libatbclone_chatgpt_hook.dylib，完全隔离其 Application Support 与 Caches 存储；
• 修复了传统多开工具在初始化 CODEX_HOME 时不慎把宿主 ~/.codex/auth.json 拷贝过去导致的“共享 Token 串号”缺陷，真正实现了多账号零串号、零污染的并行运作。

核心黑科技五：“数据-逻辑解耦”架构：为什么母体升级永不丢记录？

使用传统多开工具最痛苦的经历莫过于：App Store 一旦推送微信升级，旧分身因协议过期无法登录，而重新制作分身又会导致几百个 G 的聊天记录与照片缓存全部灰飞烟灭。

ATBClone 彻底终结了这一噩梦，其秘诀在于数据持久层与程序逻辑层的物理级解耦：

[ 程序逻辑层 (无状态，可随时销毁与重构) ]          [ 数据持久层 (永久保存，绝对安全隔离) ]
~/ATBClone/Apps/WeChat2.app                      ~/ATBClone/Data/WeChat2/
  ├── Contents/Info.plist                          ├── Home/
  ├── Contents/MacOS/WeChat (原生 Mach-O)           │   ├── Library/Application Support/com.tencent.xinWeChat/
  └── Contents/Frameworks/libatbclone_env.dylib    │   ├── Library/Preferences/
                                                   │   └── Library/Keychains (软链接回系统钥匙串)
                                                   └── Tmp/

• .app 实体：仅仅是一个包含重定向动态库的“执行壳”，不保存任何本地数据；
• Data/ 目录：独立存放在用户目录甚至外接移动固态硬盘（SSD）中，承载全部 SQLite 数据库、加密密钥与聊天缓存；
• 一键无损更新：当母体应用升级后，只需在终端运行：

  atbclone update WeChat2
  

  或者在 GUI 界面点击“更新”，ATBClone 会自动关闭分身进程，按最新母体重新复刻 .app 壳，并重新挂载原有数据目录。整个升级过程耗时仅数秒，历史聊天记录、登录凭据与草稿 100% 毫发无损！

🤖 专为 AI Coding Agent 打造的多实例矩阵

作为面向未来的现代多开引擎，ATBClone 开箱即用地内置了针对当前主流 AI 智能体生态的深度隔离配方：

🛠️ 实战全流程：极速安装与双模交互指南

ATBClone 同时提供了精美原生的 macOS GUI 桌面端与高度脚本化的 CLI 终端工具。

1. 快速安装

方式 A：GUI 桌面端（适合日常用户）

前往 GitHub Releases 下载 ATBClone-arm-x.x.x.dmg，双击拖拽 ATBClone.app 到系统的 Applications 目录即可。

方式 B：CLI 命令行端（适合高阶开发者与自动化流水线）

# 1. 确保已安装 Xcode 命令行工具
xcode-select --install

# 2. 下载并解压 CLI 独立二进制
curl -sL https://github.com/aitobox/ATBClone/releases/latest/download/ATBCloneCli.tar.gz | tar -xz
sudo mv atbclone /usr/local/bin/

# 3. 运行环境体检
atbclone doctor

[!TIP]
atbclone doctor 会自动对你的 macOS 环境进行全项体检，包括 Xcode Command Line Tools、codesign 签名权限、PlistBuddy、SIP 状态及目标写入目录权限，确保分身构建万无一失。

2. 交互式向导（CLI Guided Mode）

如果你不想记忆繁琐的命令行参数，只需在终端中敲入：

atbclone wizard

终端将进入直观的 Rich 交互式引导：

1. 拖入应用：直接把 /Applications/WeChat.app 拖进终端窗口；
2. 自动匹配：引擎自动检索 33+ 内置应用规则；
3. 命名与图标：自动自增编号（如 WeChat2），支持设置自定义展示名称与 .icns 图标；
4. 路径配置：支持指定专属数据目录（可外挂至移动移动硬盘）；
5. 代理配置：按需直接分配独立的 HTTP / SOCKS5 代理 IP 与端口。

3. 高阶命令行实操速查

一键极速克隆

# 1. 极速克隆微信，自动生成 WeChat2
atbclone clone /Applications/WeChat.app

# 2. 指定名称并绑定专属 HTTP 代理 (如用于多地区业务隔离)
atbclone clone /Applications/Telegram.app \
  --name "Telegram-Tokyo" \
  --proxy-host 127.0.0.1 \
  --proxy-port 7890 \
  --proxy-type http

# 3. 为 Chrome 指定外接固态硬盘数据目录
atbclone clone /Applications/Google\ Chrome.app \
  --name "Chrome-Dev" \
  --data-dir /Volumes/ExtremeSSD/ChromeData

查看全部分身状态

atbclone list

终端将输出精美的 Rich 卡片式列表：

┏━━━━━━━━━━━━━━┳━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ 名称         ┃ 原 APP   ┃ Bundle ID                  ┃ 策略       ┃ 创建时间         ┃ 代理                   ┃
┡━━━━━━━━━━━━━━╇━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━┩
│ WeChat2      │ 微信     │ com.tencent.xinWeChat      │ hard_clone │ 2026-09-06 17:30 │ 未开启                 │
│ TG-Tokyo     │ Telegram │ ru.keepcoder.Telegram      │ hard_clone │ 2026-09-06 17:45 │ http://127.0.0.1:7890  │
│ Claude-Work  │ Claude   │ com.anthropic.claudefordes │ hard_clone │ 2026-09-06 18:00 │ 未开启                 │
│ Cursor-Work  │ Cursor   │ com.todesktop.230313mzl4w4 │ soft_clone │ 2026-09-06 18:05 │ 未开启                 │
└──────────────┴──────────┴────────────────────────────┴────────────┴──────────────────┴────────────────────────┘

冷门小众应用深度探测与配方生成（App Prober）

对于没有内置预设规则的小众软件或自研工具，只需执行：

atbclone probe /Applications/MyCustomApp.app --save

Prober 引擎会自动提取该应用二进制的 CPU 架构、链接的 Framework 框架类型（CEF / Electron / Cocoa / Qt / Flutter）以及当前的沙盒 Entitlements，并在 ~/ATBClone/recipes/ 下全自动生成一份最优的 YAML 规则！

🎯 深度总结与技术思考

在开源世界中，许多工具往往止步于“能跑就行”的粗糙拼凑；而 ATBClone 的代码实现，展现出了极具极客精神的底层纯粹感与工程自洽性：

1. 对系统机制的敬畏与精准驾驭：它没有粗暴地尝试绕过或对抗 Apple 的安全体系，而是深入理解了 RBS、LaunchServices、Mach-O Load Commands 与 audit_token 的契约细节，用最轻巧的原生 Universal Dylib 注入取代了破坏性的 execv 进程替换；
2. 教科书级的逆向改造：通过纯 Python 解析二进制与精准的 ARM64 机器码 Patch，将 Chromium 顽固的 ProcessSingleton 单例锁悄无声息地化解于无形；
3. 以用户资产安全为第一原则：通过数据与程序实体的物理隔离设计，彻底解决了 macOS 软件升级带来的数据丢失恐惧。

无论你是需要在 Mac 上多开办公通讯的重度用户，还是需要构建高并发、多账号隔离流水线的 AI Coding 极客，ATBClone 都是目前 macOS 平台上最值得信赖的底层基石。

项目仓库：GitHub - aitobox/ATBClone
开源协议：GPL-3.0 License
核心架构：Python 3.12+ / Universal Binary (arm64 & x86_64) / Cocoa & Mach-O Low-Level Engineering