會議與逐字稿
Control Center 可以錄製通話，並交回一份條理分明的成稿——摘要、行動項目與 決議——語音辨識與語者分離全都執行在你自己的硬體上。可以把它想成 Granola，但由你自行託管，並接上你的代理所處的同一個工作區。
什麼是會議
標題為「什麼是會議」的章節會議是一場經過錄製與轉錄的會期。它與日曆活動 並_不_相同：活動是從 Google 同步過來的既定行程，而會議則是你實際錄下的 內容。兩者可以互相連結，因為你可以從某個活動開始錄音，但它們仍是彼此獨立 的紀錄。
和 Control Center 裡的其他一切相同，每場會議都以工作區為範圍。在某個工作區 錄下的會議，永遠不會出現在另一個工作區。
工作在何處進行
標題為「工作在何處進行」的章節「裝置端」這個直覺沒錯，但名詞用錯了。用戶端擷取音訊，並把 16 kHz PCM16
訊框串流到執行 cc_server 的那台機器。其餘一切由該主機完成：它把各聲道
的 WAV 寫到 <dataDir>/meetings/<meetingId>/ 之下、在工作程序的隔離區中進行
轉錄，並在事後過濾回音與執行語者分離。在單機桌面上，該主機就是同一台機器；
指向遠端伺服器時則不然——因此「什麼都不會離開我的筆電」只有在伺服器就是你
筆電時才成立。
還有一處例外，而且正是最重要的那一處。
摘要之前的一切——擷取、轉錄、回音消除、語者分離、聲紋比對——都在伺服器上 執行，不發出任何網路呼叫。
隨附哪些模型
標題為「隨附哪些模型」的章節嵌入、語者分離與語音（ASR）模型會在首次開機時強制安裝（示範模式下 跳過），因此不需進到設定，就能使用語者分離與錄音。ASR 仍可選——它有 數百 MB，而且選擇器隨附四種建置。首次下載之後，語音功能仍需要一次重新 啟動，因為轉錄器會在下載完成之前就解析好它的模型。
選擇器中的四個項目，在大小、語言涵蓋範圍與準確度上各有不同：
- Parakeet TDT 0.6B v3 — 多語言，建議的預設值（約 600 MB）
- Parakeet TDT 0.6B v2 — 英文（約 480 MB）
- Whisper large-v3-turbo — 多語言（約 626 MB）
- Whisper base.en — 僅英文，體積較小的歷史預設值（約 198 MB）
模型是伺服器在執行階段唯一會取得的成品；所有原生程式庫都隨安裝包一起提供。
擷取如何運作
標題為「擷取如何運作」的章節一場會議會同時錄下兩個音訊聲道：
- 你（「me」）：你的麥克風。
- 對方（「them」）：會議的音訊輸出，透過免驅動的環回擷取——macOS 上是 Core Audio 的行程/裝置 tap，Windows 上是 WASAPI 環回，Linux 上是 PipeWire / PulseAudio 監聽。
由於兩個聲道是分別擷取的，逐字稿從一開始就帶有語者歸屬：你說的話會標記為
me，通話中的其他人則標記為 them。
你自己的聲音會從系統輸出回滲到麥克風，否則就會被轉錄兩次。有兩道過濾器阻止 這件事。訊號層級的 AEC3 會在每次遠端模式錄音中執行，而且是必要條件—— 若原生 AEC 程式庫無法載入，錄音會拒絕啟動，而不是默默串流受到回音汙染的 麥克風。（面對面模式沒有遠端參考訊號可抵銷，因此該模式下的 AEC 只是原樣 透傳。）在此之上，主機端還有一道文字層級的回音過濾器，在所有平台上都會 執行。
作業系統層級的所有麥克風處理都刻意停用。在 macOS 上啟用平台本身的回音消除 或自動增益，會把麥克風切換到 Voice Processing I/O，而在這個建置中，這會讓 麥克風_和_系統音訊 tap 雙雙失效。
轉錄與語者分離
標題為「轉錄與語者分離」的章節錄音期間，音訊會在 UI 執行緒之外以滾動視窗解碼——視窗在尾端出現短暫 靜音時切分，或達到最大視窗長度時切分。每個視窗都會成為一段帶有語者標記的 逐字稿片段，並附有毫秒級位移。
從未超過某個 RMS 閾值的視窗會完全不進行解碼就跳過，因為語音模型會把 靜音渲染成幻覺出的非語音 token，而解碼只會浪費 CPU。實際後果是：始終非常 小聲的語者不會產生任何逐字稿。如果有人回來是一片空白，請先檢查他的輸入 音量，再怪模型。
停止之後，語者分離會離線在整段錄音上執行，把遠端聲道拆分成一個個可重新
命名的說話者（Person 1、Person 2……）。說話者的數量是從分群閾值推斷
而來，而不是由你設定的數目決定——因此它只是閾值造成的產物，聲音小或與他人
重疊的說話者可能會被併入隔壁那位。逐字稿會以 [mm:ss] SPEAKER: text 這樣
的行呈現。
語音設定檔
標題為「語音設定檔」的章節重新命名說話者不只是替某一段逐字稿貼上標籤。Control Center 可以把說話者的 聲紋存成語音設定檔，讓它在之後的會議中自動認出此人。當你為某位經語者 分離的說話者命名時，系統會詢問你是否要儲存聲紋；若儲存，它會被納入該名字 持續累積的質心，並在遇到新說話者時以餘弦相似度比對——因此同一個人下次出現 時就會直接帶上名字，不需要你重新標註。
語音設定檔以工作區為範圍，絕不會跨越界線。可在 設定 → 工作區 → 會議 管理。重新命名先前已儲存的說話者，會取消註冊舊名字， 並提議註冊新名字；刪除設定檔會移除已儲存的聲紋，但過去會議中已套用的名稱 會原樣保留。
摘要管線
標題為「摘要管線」的章節錄音停止時，伺服器會發佈 MeetingRecordingStopped
領域事件。內建的 meeting_summary 管線
範本會由該事件觸發。錄音器不會等待它；會議只是走過自己的狀態生命週期：
recording → processing → done摘要代理會收到標題、你隨手記下的即時筆記與逐字稿，並傳回結構化 JSON。 它要撰寫哪些小節，取決於工作區的作用中會議筆記範本 （設定 → 工作區 → 會議）；作用中的範本會套用至新建與重新產生的摘要。接著， 管線的持久化步驟會把該 JSON 寫入一列列獨立的紀錄：
enhancedNotes與summary→ 會議的筆記- 每個行動項目 → 一列
MeetingActionItem（內容、負責人、選填的工單連結） - 每項決議 → 一列
MeetingDecision
行動項目與決議絕不從自由格式的 Markdown 中解析，只會取自代理的結構化
陣列。如果某次執行沒有產生結構化輸出，持久化步驟會被跳過，原始逐字稿會留作
備援，因此你永遠不會遺失這份紀錄。管線中沒有任何環節會把會議標記為
done——那是由單一對帳器依據執行的終止事件來完成，因此某個同層步驟失敗時，
不會讓一場已寫了一半、卻看似完成的會議卡住。
會議會出現在哪裡
標題為「會議會出現在哪裡」的章節| 介面 | 顯示內容 |
|---|---|
/meetings |
會議清單，含行動項目與決議數量 |
/meetings/record |
即時錄音 HUD：一側是你的筆記，另一側是串流逐字稿 |
/meetings/:meetingId |
會議詳情：筆記、逐字稿、行動項目與決議分頁 |
| 設定 → 工作區 → 會議 | 此工作區的筆記範本與已儲存的語音設定檔 |
平台支援
標題為「平台支援」的章節在三大桌面平台上，擷取都是免驅動的（macOS 上是 Core Audio tap，Windows 上是 WASAPI，Linux 上是 PipeWire）。
網頁用戶端也能錄音，本頁其餘以桌面為主的敘述可能會掩蓋這一點：瀏覽器
透過 getUserMedia 取得你的麥克風，並透過 getDisplayMedia（螢幕分享）
取得會議音訊，降取樣至 16 kHz PCM16 後串流到同一台主機。這裡有三點要注意：
- 分享的畫面必須帶有音訊軌。Safari、Firefox 與 macOS 的全螢幕分享不會 提供音訊軌，錄音會直接拒絕啟動。
- 沒有原生 AEC3。麥克風會要求使用瀏覽器本身的回音消除；主機端的文字回音 過濾器仍會執行。HUD 會顯示一個由麥克風 PCM 驅動的輸入音量表。
- 重新產生摘要與取消處理僅限桌面版。
日曆的開始錄製並連結操作僅限桌面版，在網頁上會直接如此說明，儘管會議 畫面本身的錄音流程在網頁上可以正常運作。