פגישות ותמלול

Control Center יכול להקליט שיחה ולהחזיר לכם מסמך כתוב ומסודר — סיכום, משימות לביצוע והחלטות — כשזיהוי דיבור והפרדת דוברים פועלים על החומרה שלכם. חשבו על Granola, אבל בהתארחות עצמית ומחובר לאותה סביבת עבודה שבה הסוכנים שלכם חיים.

ההקלטה דורשת מודל קול והפעלה מחדש של השרת

ההקלטה וההכתבה מתחילות לאחר שמודל דיבור (ASR) נמצא על הדיסק וגם השרת הופעל מחדש. אתחול רגיל מתקין בכוח את המודל הנבחר (Parakeet TDT 0.6B v3 כברירת מחדל) ברקע, אך השרת מפענח את נתיבי מודלי הקול פעם אחת בלבד בסמוך לתחילת האתחול — דקות לפני שההורדה הזו יכולה להסתיים. לאחר שהמודל מדווח כמותקן, הפעילו מחדש את cc_server. כדי לבחור גרסה אחרת, השתמשו בהגדרות ← שרת ← מודלי קול ופגישות — גם זה דורש הפעלה מחדש.

מהי פגישה

פגישה היא סשן מוקלט ומתומלל. היא לא אותו דבר כמו אירוע בלוח שנה: אירוע הוא התחייבות מתוזמנת המסונכרנת מ-Google, בעוד שפגישה היא משהו שהקלטתם בפועל. אפשר לקשר בין השניים, שכן אפשר להתחיל הקלטה מאירוע, אך הם נשארים רשומות נפרדות.

כל פגישה מוגבלת לסביבת העבודה שלה, כמו כל דבר אחר ב-Control Center. פגישות שהוקלטו בסביבת עבודה אחת לא יופיעו באחרת.

היכן מתבצעת העבודה

“על המכשיר” הוא אינסטינקט נכון אך שם עצם לא נכון. הלקוח לוכד אודיו ומשדר מסגרות 16 kHz PCM16 אל המכונה שמריצה את cc_server. המארח הזה עושה את כל השאר: הוא כותב את קבצי ה-WAV של כל ערוץ תחת <dataDir>/meetings/<meetingId>/, מתמלל ב-isolate של עובד, מסנן הד ומפריד דוברים בדיעבד. במחשב שולחני עצמאי המארח הזה הוא אותה מכונה. כשמכוונים אותו לשרת מרוחק, זה כבר לא כך — ולכן “שום דבר לא יוצא מהמחשב הנייד שלי” נכון רק כשהשרת הוא המחשב הנייד שלכם.

יש חריג אחד נוסף, והוא החשוב.

הסיכום עוזב את המארח

התמלול וההערות שלכם נשלחים לספק המודל שסוכן הסיכום מוגדר מולו. אצל כל ספק ענן משמעות הדבר היא שהתמלול המלא נשלח ל-API של אותו ספק. אם תמלול אסור ביציאה מהמארח, כוונו את סוכן הסיכום לנקודת קצה מקומית (Ollama, LM Studio או שרת מקומי אחר).

כל מה שלפני הסיכום — לכידה, תמלול, ביטול הד, הפרדת דוברים והתאמת טביעות קול — פועל בשרת בלי שום קריאת רשת.

אילו מודלים נכללים

מודלי ההטמעה, הפרדת הדוברים והדיבור (ASR) מותקנים בכוח באתחול הראשון (ומדולגים בדמו), כך שהפרדת דוברים והקלטה קיימות בלי ביקור בהגדרות. ASR עדיין ניתן לבחירה — הוא תופס כמה מאות מגה-בייט, וארבע גרסאות נכללות בבורר. גם הדיבור דורש הפעלה מחדש אחת לאחר ההורדה הראשונה הזו, משום שהמתמלל מפענח את המודל שלו לפני שההורדה יכולה להסתיים.

ארבעת הפריטים בבורר, הנבדלים בגודל, בכיסוי השפות ובדיוק:

• 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”): פלט האודיו של הפגישה, הנקלט בלולאת החזרה ללא דרייבר — הקלטות תהליך והתקן של Core Audio ב-macOS, לולאת החזרה של WASAPI ב-Windows, ומוניטור PipeWire / PulseAudio ב-Linux.

מכיוון ששני הערוצים נקלטים בנפרד, התמלול משויך לדוברים מלכתחילה: המילים שלכם מתויגות me, וכל מי שבשיחה מתויג them.

הקול שלכם מדליף מפלט המערכת חזרה אל המיקרופון, וללא הטיפול היה מתומלל פעמיים. שני מסננים מונעים זאת. מסנן AEC3 ברמת האות פועל בכל הקלטה במצב מרוחק והוא חובה — אם ספריית ה-AEC המקורית לא נטענת, ההקלטה מסרבת להתחיל במקום להזרים בשקט מיקרופון רווי הד. (מצב נוכחות פיזית אינו כולל אות עזר מקצה מרוחק לבטל מולו, ולכן AEC הוא שם העברה ללא שינוי.) מעליו פועל בכל הפלטפורמות מסנן הד ברמת הטקסט, בצד המארח.

כל עיבוד המיקרופון ברמת מערכת ההפעלה מושבת בכוונה. הפעלת ביטול ההד או ההגבר האוטומטי של הפלטפורמה ב-macOS מעבירה את המיקרופון ל-Voice Processing I/O, ובגרסה הזו הדבר הרג גם את המיקרופון וגם את הקלטת אודיו המערכת.

תמלול והפרדת דוברים

בזמן ההקלטה האודיו מפוענח בחלונות מתגלגלים — נחתכים בסוף שקט קצר, או באורך חלון מרבי — מחוץ ל-thread של ה-UI. כל חלון הופך למקטע תמלול מתויג בדובר, עם היסטים באלפיות שנייה.

חלונות שלא חצו סף RMS מדולגים בלי לפענח אותם כלל, משום שמודל דיבור ממיר שקט לאסימונים מדומים של לא-דיבור, והפענוח מבזבז 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 — מתאם יחיד עושה זאת מהאירוע המסיים של ההרצה, כך שכשל של שלב אחים לא יכול להשאיר פגישה חצויה למחצה שנראית כבר כמוגמרת.

סוכנים אינם יכולים לקרוא את הפגישות שלכם

אין כלי MCP לפגישות או ללוח שנה. סוכן שמחובר דרך MCP לא יכול להציג רשימת פגישות, לקרוא תמלול או לראות פריטי משימה והחלטות — הנתונים האלה מגיעים ללקוחות אנושיים רק דרך RPC. לעומת זאת, החלטות כן מגיעות לסוכנים בעקיפין, כעובדות זיכרון בתחום decisions.

היכן פגישות מופיעות

משטח	מה הוא מציג
/meetings	רשימת הפגישות, עם מספרי פריטי משימה והחלטות
/meetings/record	תצוגת ההקלטה החיה: ההערות שלכם בצד אחד, והתמלול הזורם בצד אחר
/meetings/:meetingId	פרטי פגישה: לשוניות הערות, תמלול, משימות לביצוע והחלטות
הגדרות ← סביבת עבודה ← פגישות	תבניות הערות ופרופילי קול שמורים לסביבת העבודה הזו

תמיכה בפלטפורמות

הלכידה נעשית בלי דרייבר בכל שלוש פלטפורמות השולחן (הקלטות Core Audio ב-macOS, WASAPI ב-Windows, PipeWire ב-Linux).

גם לקוח הווב מקליט, מה ששאר המסגור השולחני של העמוד הזה עלול להסתיר: הדפדפן לוקח את המיקרופון שלכם דרך getUserMedia ואת אודיו הפגישה דרך getDisplayMedia (שיתוף מסך), ממיר כלפי מטה ל-16 kHz PCM16 ומשדר לאותו מארח. שלוש הסתייגויות חלות שם:

• המשטח המשותף חייב לשאת רצועת אודיו. שיתוף ב-Safari וב-Firefox, ושיתוף מסך מלא ב-macOS, לא מספקים כזו, וההקלטה מסרבת להתחיל.
• אין AEC3 מקורי. ביטול ההד המובנה של הדפדפן מתבקש על המיקרופון; מסנן ההד הטקסטואלי בצד המארח עדיין פועל. התצוגה מציגה מד עוצמת כניסה הנגזר מה-PCM של המיקרופון.
• הרצה מחדש של הסיכום וביטול העיבוד זמינים במחשב השולחני בלבד.

הפעולה התחל הקלטה וקישור של לוח השנה זמינה במחשב השולחני בלבד ומדווחת על כך בבירור בווב, אף שזרימת ההקלטה של מסך הפגישות עצמו עובדת שם.

מחיקת פגישה משאירה את האודיו שלה מאחור

מחיקת פגישה מסירה רק את השורות שלה במסד הנתונים. תיקיית האודיו הנשמרת לכל ערוץ, <dataDir>/meetings/<meetingId>/, לא מנוקה לעולם — אין עבורה מדיניות שימור, תקרת גודל או סריקת GC. שחזור אותו שטח דיסק הוא עבודה ידנית במארח השרת.

ראו גם

• לוח שנה ותזמון: הקליטו פגישה ישירות מאירוע בלוח שנה
• פייפליינים ואוטומציה: המנוע שמאחורי meeting_summary
• כרטיסים והאצלה: קשרו את פריטי המשימה של הפגישה לכרטיסים
• אירועי תחום: MeetingRecordingStopped ו-MeetingStartingSoon
• הקלטה וסיכום של פגישה