lijianfei.com

在数字化远程协作成为常态的今天，会议记录与纪要生成已从“锦上添花”演变为知识工作者的核心生产力刚需。然而，纵观当前市场上的主流 AI 会议助手，几乎都在强迫用户在“隐私裸奔”与“系统稳定性风险”之间二选一：要么依赖会议机器人（Meeting Bot）大张旗鼓地加入视频会议室，既招致同行反感又极易被企业安全合规拦截；要么强行在本地安装诸如 BlackHole、Soundflower、Loopback 等虚拟声卡驱动，甚至要求用户降低 macOS 内核安全等级，带来音频通道被劫持、系统音量失控甚至系统崩溃的沉重技术债务。

近期在开源社区备受瞩目的 Amanu（基于 MIT 协议完全开源），以一套极其纯粹且硬核的 macOS 系统级原生架构打破了这一僵局。它无需任何入会机器人，亦无需注入虚拟驱动或内核扩展，而是完全依托 macOS 14.2+ 引入的现代 Core Audio 进程旁路分流（Process Tap）技术，搭配离线声学回声消除（Offline AEC）模型与原子化的“文件夹数据库”状态机，在 Apple 原生生态内构建起了一座兼顾极致隐私与工业级稳定性的会议记录堡垒。

一、 会议录制工具的技术路线困局与 Amanu 的破局之道

要理解 Amanu 的工程价值，首先需要厘清过往开发者在 macOS 上实现系统内录时所经历的三代架构演进及其原生硬伤：

flowchart TD
    subgraph Generations ["会议录制工具的三代技术架构对比"]
        direction TB
        G1["第一代：会议入会机器人 (Cloud Meeting Bots)<br/>代表：Otter.ai, Fireflies, Fathom"]
        G2["第二代：虚拟声卡 / 内核扩展流 (Virtual Audio Drivers)<br/>代表：BlackHole, Loopback, Audio Hijack, Soundflower"]
        G3["第三代：Core Audio 原生进程分流 (Amanu Architecture)<br/>基于 macOS 14.2+ 原生 CATapDescription"]
    end

    G1 -->|硬伤：隐私泄露 / IT 策略屏蔽 / 依赖云端| P1["无法应对合规审查与突发离线"]
    G2 -->|硬伤：需降级安全策略 / 劫持全局音频 / 混入背景噪音| P2["系统脆弱，音乐与网页声音被杂糅"]
    G3 -->|优势：0 机器人 / 0 外部驱动 / 进程白名单隔离 / 纯本地 PCM| P3["完全静默自愈，合规无痕，音频互不干扰"]

    style G3 fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px
    style P3 fill:#e1f5fe,stroke:#0288d1,stroke-width:1px

1. 第一代：会议入会机器人（Meeting Bot）的合规死胡同

这类工具通过云端无头浏览器（Headless Chromium）启动虚拟参会者进入 Zoom、Google Meet 或 Teams 会议室。其缺陷是致命的：

• 社交尴尬与信任破坏：屏幕赫然出现类似 “xxx's Notetaker” 的机器人挂机，瞬间引发参会客户或领导的戒心；
• 合规一票否决：跨国金融、医疗、法律或涉密高科技企业的会议室往往强制开启“禁止外部来宾入会”策略，机器人直接被系统防火墙拒绝；
• 纯云端数据归宿：原始音频必须全量流向第三方 SaaS 云端集群，知识产权与商业机密完全脱离本地控制。

2. 第二代：虚拟声卡与 Kext 驱动流的技术债务

为了摆脱云端机器人，许多桌面端辅助软件选择通过虚拟音频设备（Virtual Audio Device）做全局音频重定向：

• 安装门槛陡增：需要安装 Audio Server Plugin 或基于 DriverKit 的虚拟驱动，在搭载 Apple Silicon 芯片的 Mac 上甚至需要进入 Recovery 模式降低系统安全性；
• 全局声音污染：虚拟声卡通常一视同仁地捕获整个系统的输出音频，录音中会混杂 Spotify 的背景音乐、Slack 的提示音甚至正在浏览的短视频声音；
• 状态脆弱性：一旦拔插蓝牙耳机（AirPods）或外接显示器音频，虚拟聚合设备（Aggregate Device）的时钟漂移（Clock Drift）与采样率不匹配极易导致静音或刺耳破音。

3. 第三代：Amanu 选定的 Core Audio 进程级原生捕获

Amanu 则全面拥抱了苹果在 macOS Sonoma（14.2+）中悄然引入的 Core Audio 进程分流（Process Tap）原生能力：

• 直接在操作系统底层将指定进程家族（如 Zoom、Google Chrome、Teams、Telegram）的音频输出流旁路复制一份，系统级输出硬件依然走原本干净的音频总线；
• 彻底摒弃任何虚拟驱动与入会机器人，完全在 macOS 用户空间以原生 Hardened Runtime 沙盒形态安全运行。

二、 系统架构全景：Amanu 的数据流与处理管线

Amanu 的整体运行链路遵循极度严谨的“静默感应 — 双轨录制 — 离线净化 — 弹性转录 — 归档落地”闭环设计。

flowchart TD
    subgraph TriggerLayer ["一、 触发与上下文感知"]
        EventKit["EventKit 日历监控<br/>(会议标题/参会人员)"]
        MicPoller["Core Audio 进程状态轮询<br/>(kAudioHardwarePropertyProcessObjectList)"]
        Whitelist{"是否命中通话应用白名单？<br/>(Zoom/Teams/Chrome/Telegram等)"}
        MicPoller --> Whitelist
        Whitelist -- "否 (如 Siri/听写)" --> Ignore["安全忽略，杜绝误录"]
        Whitelist -- "是" --> StartSignal["触发自动录制握手"]
        EventKit -.->|"注入会议元数据"| StartSignal
    end

    subgraph CaptureLayer ["二、 零干扰双轨无损捕获"]
        StartSignal --> CaptureEngine["Amanu 录制主引擎"]
        CaptureEngine --> PathMic["麦克风通道 (MicRecorder)<br/>纯 Raw PCM 采集，绝不开启硬件变调"]
        CaptureEngine --> PathSys["远端通话通道 (SystemAudioRecorder)<br/>CATapDescription 进程级精准分流"]
        PathMic --> CafMic["临时落盘: mic.caf<br/>(32-bit Float PCM)"]
        PathSys --> CafSys["临时落盘: system.caf<br/>(32-bit Float PCM)"]
        Manifest[".recording.json 原子清单<br/>(PID + 启动时间戳)"] -.->|"崩溃防丢保护"| CaptureEngine
    end

    subgraph OfflineEngine ["三、 离线后处理与声学回声消除 (AEC)"]
        CafMic & CafSys --> PostCheck{"通话正常结束？"}
        PostCheck --> LocalVQE["LocalVQE v1.4-AEC 离线声学模型<br/>(16kHz, 256-sample hop, C-API)"]
        LocalVQE --> DelayEst["GCC 广义互相关全流延时预估"]
        DelayEst --> HoldOff["16,000 samples (1秒) 拖尾保护<br/>参考音静音即回退原始麦克风"]
        HoldOff --> CleanedMic["生成已消回声 mic_clean.caf"]
    end

    subgraph ASR_LLM ["四、 语音识别与智能归档"]
        CleanedMic & CafSys --> Router{"ASR 引擎路由"}
        Router -- "Apple Silicon 离线" --> Parakeet["Parakeet / Whisper / GigaAM v3"]
        Router -- "高精度云端多声道" --> MultiASR["AssemblyAI / ElevenLabs Scribe v2"]
        Parakeet & MultiASR --> RawTranscript["时间对齐转录文本 (transcript.json)"]
        RawTranscript --> SpeakerEngine["发言人置信度决策器<br/>(日历参与者 + 真实原句引用校验)"]
        SpeakerEngine --> LLMRouter{"总结引擎路由"}
        LLMRouter -- "本地 CLI 订阅复用" --> CLI["Claude Code / Codex CLI<br/>(空 MCP 配置避免挂起)"]
        LLMRouter -- "纯本地离线" --> Ollama["Ollama (localhost 环回)"]
        LLMRouter -- "标准 API" --> CloudLLM["Anthropic / OpenAI API"]
        CLI & Ollama & CloudLLM --> FinalFolder["写入最终会议归档目录<br/>(~/Recordings/YYYY.MM.DD-HHmm 会议名/)"]
    end

三、 核心技术深度拆解

1. Core Audio 进程级精准分流（SystemAudioRecorder）

在 macOS 14.2 以前，想要不录入全局喇叭的声音几乎是不可能完成的任务。Amanu 在 Sources/amanu/Audio/SystemAudioRecorder.swift 中运用了极为典雅的 Core Audio 原生 Process Tap API：

// 构建进程级录制描述符
let description = objects.isEmpty
    ? CATapDescription(stereoGlobalTapButExcludeProcesses: [])
    : CATapDescription(stereoMixdownOfProcesses: objects)

description.name = "amanu system tap"
description.isPrivate = true
description.muteBehavior = .unmuted

if !objects.isEmpty, #available(macOS 26.0, *) {
    // 跨进程重启自动跟踪，保证会议软件中途重启不会丢失音频流
    description.bundleIDs = bundleIDs
    description.isProcessRestoreEnabled = true
}

// 创建系统专属 Tap 对象
var newTapID = AudioObjectID(kAudioObjectUnknown)
let status = AudioHardwareCreateProcessTap(description, &newTapID)

进程家族（Process Family）智能关联

现实中的会议应用绝非单个简单进程。例如使用 Google Chrome 进行 Google Meet 通话时，实际渲染和输出声音的是子进程 com.google.Chrome.helper.Renderer；Teams 和 Zoom 也大量使用独立 Helper 进程。

Amanu 在 Sources/amanu/Audio/AudioProcesses.swift 中设计了“进程家族前缀算法”：

• 通过 kAudioHardwarePropertyProcessObjectList 查询系统所有激活的音频进程；
• 通过 kAudioProcessPropertyBundleID 和 kAudioProcessPropertyIsRunningOutput，抓取匹配前缀的所有子孙进程；
• 致命陷阱防范：在获取所有音频进程时，必须显式剔除 Amanu 自身的 PID。若不剔除自身，Amanu 的音频写入行为会被误判为系统的播放活动，从而与录音状态机形成永久死循环！

2. “录音绝不能破坏会议本身”：为何坚持裸麦克风与离线 AEC

在实时音视频开发中，一个经典做法是开启 Apple 的双工语音处理单元（Voice Processing Audio Unit，简称 VPAU）。然而，Amanu 却在录音时 彻底禁用了 VPAU，坚持全裸采集（Raw Mic Capture）。

Apple VPAU 的隐形灾难

如果在用户开会时强行开启系统级双工语音处理：

1. 音频路线强制降级：macOS 会立刻接管系统的音频输出拓扑，将原本高品质的双声道立体声强制转为单声道，并施加激进的硬件压限与降噪算法；
2. 耳机听感断崖式恶化：许多佩戴 AirPods 的用户会发现，录音刚一启动，耳机里的对方说话声突然变得干瘪、发闷，甚至伴随微小的爆音与音量跳变。
3. 不可逆的原声破坏：一旦在硬件输入端把声音“清洗”，万一算法误将弱声信号识别为噪音抹去，原始录音就永远损毁了。

优雅的解法：LocalVQE 离线声学回声消除管线

Amanu 采取的哲学是：录音时 100% 保留物理现场，会议结束后再进行离线高保真消除。

在 Sources/amanu/Audio/OfflineEchoAudio.swift 与 Sources/amanu/Audio/EchoCanceller.swift 中，Amanu 静态编译嵌入了 CPU 极速推理模型 LocalVQE v1.4-AEC（203K 参数量，基于 ggml 构建），并在时间序列上实施了严格的声学物理规则：

flowchart LR
    subgraph StreamTimeline ["离线声学对齐与拖尾保护机制"]
        direction TB
        R1["系统远端音频 (Reference Track)"]
        M1["原始麦克风音频 (Raw Mic Track)"]
        R1 --> Check{"检测全流是否有参考声音？"}
        Check -- "全流完全静音 (全场单人讲话)" --> DirectRaw["0 开销直接透传原始麦克风<br/>不加载 LocalVQE 引擎"]
        Check -- "存在远端通话声" --> WarmUp["从绝对 t=0 喂入模型<br/>保持 GCC 时延估计时钟一致"]
        WarmUp --> CrossCorr["GCC 广义互相关锁定固定物理时延"]
        CrossCorr --> AEC_Core["LocalVQE 256-sample 逐 Hop 消除回声"]
        AEC_Core --> HoldOff["16,000 samples (1.0 秒) 拖尾保护期"]
        HoldOff --> OutputMic["输出消除回声的 mic.caf"]
    end

    style StreamTimeline fill:#fff8e1,stroke:#f57f17,stroke-width:1px
    style HoldOff fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px

这里的工程细节极度考究：

• 绝对 t=0 时钟对齐：许多初学者会尝试在“对方开始说话的那一秒”才启动 AEC 模型。但在现实物理环境中，GCC 时延估计器需要从第一秒开始构建连续的脉冲响应空间；中途启动会导致模型基准时钟漂移，锁定错误的时间差；
• 16,000 Samples（整整 1 秒）拖尾保真（Acoustic Hangover）：当远端说话人停止发声后，房间的声学混响（Reverb）与扬声器硬件残响并不会立刻消失。Amanu 在远端参考信号归零后，严格保持消除状态 1 秒钟（16,000 个采样点）； 一旦超过 1 秒完全静音，立刻平滑回退使用原始麦克风信号 ！这确保了本地人在没有背景回声干扰时的发言完全不受算法降质影响。

3. “文件夹即数据库”：抗强杀的原子状态设计

在架构设计上，Amanu 完全拒绝引入任何重量级的本地数据库引擎（如 SQLite、CoreData 或 Realm）。它的核心状态机极其朴素：每一个会话，就是一个独立的文件目录。文件是否存在，就是最纯粹的状态迁移标志。

一个完整的归档目录结构如下：

~/Recordings/2026.09.24-1130 架构技术同步会/
├── .recording.json     # 录制中临时持有清单（包含 PID，非正常退出则留存）
├── .transcribing.json  # 阶段原子锁（避免多进程重复处理）
├── audio.m4a           # 最终合成的左右声道立体声归档（左=我，右=对方）
├── transcript.md       # 人类易读的高亮 Markdown 转录纪要
├── transcript.json     # 包含逐词高精度时间戳的规范数据结构
├── speakers.json       # 经过置信度决策的参会人真实姓名映射
├── summary.md          # 提炼的核心行动项、讨论重点与开放问题
├── meta.json           # 包含硬件型号、触发来源、采样统计的元数据
└── transcribe.log      # 调试与追溯日志

为什么未压缩 PCM CAF 比 AAC 更能防崩溃？

许多录音软件默认直接录制 AAC 格式的 M4A 文件。然而，AAC 属于可变比特率有损压缩格式，在文件关闭时必须将关键的全局元数据（Moov Atom 或 Index Tables）写在文件尾部。如果 Mac 在会议中途突发电量耗尽、或者被用户在终端执行了 kill -9，由于缺少尾部索引，录了一小时的 AAC 文件将彻底损坏，任何播放器都无法解析！

Amanu 在录制过程中：

1. 始终使用 CAF 容器格式 写入纯 32 位浮点线性 PCM 数据。CAF 格式在设计之初就具备极强的容错性，数据帧实时顺序落盘；即便强行断电，最后写入的每一个字节都完好无损；
2. 配合 .recording.json 临时清单。在应用下次重启时，扫描未包含 meta.json 但存在 .recording.json 的目录；通过 kill(pid, 0) 确认前序进程已挂掉后，自动接管并合成元数据，送入后处理队列恢复转录！
3. 只有在语音识别与转录彻底成功后，才会启动 TrackCompressor 将巨大的 PCM 音频压制为小巧的立体声 M4A 归档，并将原始 PCM 物理销毁。

4. 权限与系统机制避坑实录：TCC、App Nap 与 LaunchServices

在 macOS 的桌面软件开发中，权限管理（TCC）与系统节能机制（App Nap）是一座巨大的隐形深坑。Amanu 团队在 docs/pitfalls.md 中记录了多项用血泪换来的宝贵经验：

5. 羊毛薅到极致：复用 Claude Code / Codex CLI 与空 MCP 防御

大部分 AI 工具在生成会议总结时，往往强制要求用户在应用内绑定并充值 OpenAI 或 Anthropic 的 Metered API Key。

而对于广大的开发者与 AI 极客而言，电脑里通常已经安装并登录了包含月费订阅额度的官方 CLI 工具（如 claude 或 codex）。Amanu 设计了一套极其精妙的成本感知路由机制：

“用户已经付过订阅费的本地 CLI 工具，优先级永远高于按量计费的 API Key。”

Amanu 在 Sources/amanu/Summary/LLMBackend.swift 中实现了对 Claude Code CLI 的直接调用。然而，直接调用外部 CLI 存在一个极其致命的性能炸弹：

/// The CLI is handed an empty MCP config on purpose: this needs no tools,
/// and without it the CLI starts every MCP server configured on the
/// machine — minutes of startup for a one-shot prompt.
private static func claudeCLI(path: String) -> LLMBackend {
    LLMBackend(name: "claude-cli", model: nil) { system, prompt in
        try await run(
            executable: path,
            arguments: [
                "-p", system,
                "--output-format", "text",
                "--mcp-config", #"{"mcpServers":{}}"#, // 关键：注入空配置
                "--strict-mcp-config",
            ],
            input: prompt,
            timeout: 1800
        )
    }
}

[!IMPORTANT]
空 MCP 配置的工程智慧：
当开发者日常深度使用 Claude Code 时，本地通常会挂载几十个复杂的 MCP 服务（如 GitHub、PostgreSQL、Puppeteer、文件系统等）。如果 Amanu 只是为了进行单次会议总结而直接唤起 claude，Claude Code 默认会把这几十个 MCP 服务全量冷启动一遍，导致一个简单的会议总结需要等待数分钟甚至超时卡死！
通过显式注入 --mcp-config '{"mcpServers":{}}' 与 --strict-mcp-config，Amanu 强行在单次调用中封锁了所有工具插件的加载，将总结响应时间瞬间压缩至秒级。

四、 行业录制方案全景横向评测

为了直观展现 Amanu 的定位，我们将当前主流的几类代表性方案在核心维度上进行横向对比：

五、 部署与实操指南

1. 极速安装

Amanu 已经发布了经过 Apple 官方公证（Notarized）与 Developer ID 签名的正式版本，用户可通过 Homebrew Cask 极速安装：

# 通过 Homebrew Cask 安装
brew install --cask gsamat/tap/amanu

或者直接前往 Amanu GitHub Releases 下载 .dmg 文件拖入 Applications 目录运行。

2. 命令行与生态联动

初次启动后，Amanu 会在 ~/.local/bin/amanu 创建对自身的符号链接。对于习惯终端操作的极客开发者，完全无需打开 GUI 即可进行会话管理与健康检查：

# 检查当前环境权限、ASR 引擎及配置健康状态
amanu doctor

# 手动触发或停止录音
amanu record start
amanu record stop

# 检查当前录音目录与待处理任务队列
amanu sessions

# 对历史某次中断或失败的会话重新执行转录与总结流水线
amanu process ~/Recordings/2026.09.24-1130\ 架构技术同步会

3. 配置参考（~/.config/amanu/config.json）

Amanu 遵循极简配置原则，仅存储与默认值不同的字段。以下是一份针对国内开发者常用的典型高阶配置清单：

{
  "recordings_dir": "~/Recordings",
  "keep_audio": true,
  "analytics": false,
  "interface_language": "en",
  "auto_record": {
    "enabled": true,
    "mic_activity": true,
    "calendar": true,
    "start_delay_seconds": 10,
    "stop_delay_seconds": 15,
    "apps": [
      "us.zoom.xos",
      "com.google.Chrome",
      "com.tencent.xinWeChat",
      "ru.keepcoder.Telegram",
      "com.tinyspeck.slackmacgap"
    ]
  },
  "transcription": {
    "enabled": true,
    "engine": "auto",
    "local_engine": "parakeet",
    "language": "zh"
  },
  "summary": {
    "enabled": true,
    "backend": "auto",
    "language": "zh"
  }
}

六、 结语

在 AI 应用大行其道的浪潮中，我们见到了太多给包装壳套上 Electron、随便拉取一个云端 Webhook 就声称“重构工作流”的快餐产品。而 Amanu 的出现，则展现了一种极其罕见的、扎根于 macOS 现代底层系统的工程师浪漫：

它既敬畏用户的真实隐私，不拉任何外人可疑的 Bot 入场；又敬畏操作系统的底层机制，不轻易向系统注入高危的驱动扩展；它用 Core Audio 的 Process Tap 完成精准捕获，用未压缩 PCM 的 CAF 抵抗不可抗力崩溃，用离线 LocalVQE 声学模型抚平声学物理上的回声裂痕，并在调用上级大模型时精打细算到规避多余 MCP 的秒级启动开销。

对于每一位追求极致隐私、渴望开箱即用且高度可掌控的 Mac 深度用户而言，Amanu 无疑树立了 macOS 本地 AI 生产力工具的全新工业设计标杆。