orion-studio — מחקר משטח שליטה (סבב מלא)

עורך: נדב (platform_cto) · תאריך: 2026-07-21

סטטוס: ✅ הושלם — השלב שבן ביקש לפני Claude Design

מחקר v1 (13.6, 78 שורות) כיסה רק observability. הסבב הזה עונה על השאלה של בן:

מה קיים בעולם למשטח שבן־אדם אחד שולט ממנו במפעל שלם, ומה מזה רלוונטי לנו.

היקף: ~15 סוכנים, 8 מוצרים, צינור 8 שלבים, מאשר אנושי אחד.

0 · המסקנה במשפט אחד

אין בשוק "משטח שליטה למפעל". הקטגוריה נחלקת נקי לשניים:

צופי traces שלא שולטים בכלום, ומנועי workflow שהפרימיטיבים שלהם מניחים ארגון עם היררכיה.

מה שאנחנו צריכים קטן ומורכב מחלקים מוכחים — אבל ההרכבה היא שלנו.

1 · הממצא המרכזי: תצפית ≠ שליטה

זה הממצא שהכי משנה החלטות אצלנו.

כמעט כל הקטגוריה היא קריאה־בלבד. Langfuse, LangSmith, AgentOps, Braintrust, W&B Weave —

כולם מוצרי tracing והערכה. ה"human-in-the-loop" שלהם הוא כמעט תמיד תיוג בדיעבד

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

"לא, תעשה אחרת".

⚠️ אזהרה מעשית: אם נאמץ Langfuse מתוך ציפייה ל־control plane —

נקבל צופה traces מצוין ואפס שליטה. אני מסמן את זה כאן כדי שלא נחזור על זה.

הפרימיטיבים האמיתיים של שליטה נמצאים במקום אחר: מנועי workflow עמידים

(Temporal, Airflow, Prefect, Dagster) ומידלוור אישורים (HumanLayer, LangGraph interrupt).

עדכוני שוק ששווה לדעת

מה	מתי	למה אכפת לנו
ClickHouse רכשה את Langfuse	16.1.2026	התחייבו לשמור MIT + self-host. הרפרנס לא נעלם
Humanloop מת	נסגר 8.9.2025	אנתרופיק גייסה את הצוות. כל ליסטיקל 2026 שממליץ עליו — נוצר אוטומטית ואי אפשר לסמוך עליו. פילטר איכות מצוין
Airflow 3.1 שחרר HITL נייטיב	2026	`ApprovalOperator` אמיתי, לא תוסף

2 · כשל האישורים — כשאדם אחד הוא צוואר הבקבוק

זה הפרק החשוב ביותר עבורנו, כי זה בדיוק המצב של בן.

והספרות חד־משמעית: תור האישורים הוא הדבר שנשבר.

2.1 המספר שצריך להדאיג אותנו

מהנדסת אנתרופיק על Claude Code auto mode, מילה במילה:

*"when every consequential action triggers an approval dialog, the dialog stops

being a decision point and becomes a reflex"*

ובפועל: משתמשים מאשרים 93% מבקשות ההרשאה הידניות.

מעולם ה־ops, אותה צורה בדיוק: PagerDuty — איש תורנות מקבל ~50 התראות בשבוע,

רק 2–5% דורשות התערבות. Splunk 2025 — 73% מהארגונים חוו תקלה שקשורה להתראה שהתעלמו ממנה.

המסקנה שלי לגבינו: אם בן מאשר כמעט הכל — הגייט כבר נכשל. העלות אינה רק זמנו,

אלא שה־7% שכן צריך לתפוס עובר ברפלקס. זה מבחן שכדאי להריץ על עצמנו:

מה אחוז האישור של בן? אם הוא גבוה — יש לנו יותר מדי גייטים, לא יותר מדי משמעת.

2.2 הדפוס החזק ביותר: דרגות סיכון במקום תור אישורים אחיד

הארכיטקטורה של Claude Code היא הדוגמה המשומשת ביותר:

דרגה	מה קורה
כלים בטוחים	לא שואלים לעולם — קריאה, ניווט בקוד. לא משנים מצב
מסווג	פקודות shell, רשת, קבצים מחוץ לפרויקט → מסננים; דחייה חוזרת לסוכן כדי שינסה אחרת, לא נתקעת על אדם
ארגז חול	קורא כמעט הכל, לא כותב מחוץ לתיקייה, אין רשת יוצאת, אין גישה ל־`~/.ssh`

והפרט החכם: בכניסה ל־auto mode מסירים הרשאות הרצת־קוד גורפות.

אוטונומיה גבוהה יותר מצמצמת את ההיתר, לא מרחיבה.

הכלל שאני לוקח: *לעשות את הסביבה בטוחה מספיק שרוב הפעולות לא צריכות אישור,

במקום לבקש מאדם לאשר לתוך סביבה לא בטוחה.* הכלה גוברת על הסכמה.

זה מיישר בול עם גבול הפריסה שקבענו היום: הטרמינל לא נפרס — ולכן אין מה לאשר לגביו.

2.3 ארבע הפעולות של Agent Inbox

langchain-ai/agent-inbox (MIT, ~1.0k★): תיבת דואר של interrupts ממתינים.

ארבע פעולות, וכל אחת ניתנת להפעלה בנפרד:

פעולה	למה זה חשוב
Accept	ברור
Edit	הופך גייט בינארי למשטח תיקון — הדחייה נושאת את הפתרון, לא רק "לא"
Respond	תשובה חופשית
Ignore	החלטה מודעת לא־להחליט, מתועדת. תור שיציאותיו רק כן/לא צובר פריטים שאיש לא יטפל בהם

Edit ו־Ignore הם מה שחסר לנו. ה־ben-console היום הוא בעיקר כן/לא.

2.4 טיימאאוט עם ברירת מחדל מוצהרת

Temporal: לכל שלב אנושי יש טיימר עמיד; בשתיקה — הסלמה אוטומטית למאשר גיבוי.

אצלנו אין מאשר גיבוי — אבל הצורה ההפוכה היא בדיוק מה שצריך:

כל גייט מצהיר מה קורה בשתיקה. "אחרי 48ש בלי מענה — ממשיכים בסיכון נמוך",

או "אחרי 48ש — עצירה והמוצר מסומן חסום".

זה הופך את שתיקתו של בן ממצב עמום להחלטה, וזה המנגנון היחיד

שמונע מהצינור לחנות בשקט על תיבת הדואר שלו.

ו־Airflow מוסיף את החצי המשאבי: אישור ממתין חייב לעלות אפס (deferrable operators).

אם המתנה לבן תופסת משאב — תיווצר לחץ לאשר אוטומטית.

2.5 מה לא מצאתי

אין מימוש מאומת של אצווֹת אישורים מדורגות־סיכון לפעולות סוכנים.

ספקים מרמזים, לא הצלחתי לאמת אף אחד. אם נצטרך את זה — נבנה, לא נקנה.

3 · הכשל שכבר תפסנו: דשבורד שמשקר

הפרק הזה מאמת את מה שמצאתי היום בשטח, ומספק את התיקון.

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

נתונים תקועים נראים נורמליים: הדף נטען, השאילתות רצות, אף אחד לא מקבל שגיאה.

רוב הצוותים מגלים בעיית טריות רק כשמישהו מתלונן.

והנזק סופי: ברגע שמישהו תופס את הדשבורד משקר — הוא בונה לעצמו גיליון

ומפסיק לפתוח את המרכזי.

3.1 העיקרון שאני מאמץ

טריות היא תכונה של כל מספר בנפרד — לא חותמת זמן אחת בפינה.

"עודכן לאחרונה" בכותרת הוא בדיוק העיצוב שמאפשר לפיד אחד מת להרעיל דף שלם

בזמן שהכותרת ירוקה. התיקון: גיל לכל אריח, והאריח מתדרדר ויזואלית כשעבר את ה־SLA שלו.

זה בדיוק המצב של prism-live: מחזיר HTTP 200, מציג נתונים מ־1.7. ראה הכרעה §6.2.

3.2 ארבעת האותות המוזהבים, מתורגמים למפעל שלנו

האות (SRE)	התרגום אצלנו
Latency	כמה זמן תוצר יושב וממתין לגייט
Traffic	שלבים שהושלמו בשבוע
Errors	שלבים שנפלו/חזרו אחורה, גייטים שנדחו
Saturation	כמה מקיבולת האישור של בן נצרכת

האחרון הוא האילוץ האמיתי במערכת שלנו, ואף כלי מדף לא מודד אותו.

4 · תצוגת פורטפוליו — ומכאן בא הפתרון לבאג של היום

4.1 Linear — מודל ההתיישנות הטוב ביותר שמצאתי

מהתיעוד של Linear, מילה במילה: פרויקט מסומן Update Missing כאשר

"the last project update was On Track" וגם העדכון איחר מעבר למחזור התזכורת.

ויזואלית: מסגרת מקווקוות לפני שהאייקון הופך אפור.

שלושה רעיונות נושאי משקל:

#	הרעיון	למה
1	ההתיישנות א־סימטרית — פועלת רק על חדשות טובות	"חסום" ישן עדיין נכון. "רץ" ישן הוא השקר המסוכן
2	אפור ≠ אדום	"אני לא יודע" אינו "זה רע". לערבב = להרוס מידע ולאמן אנשים להתעלם מאדום
3	מקווקו לפני אפור	הידרדרות מדורגת וגלויה לפני שהיא סופית

רעיון 1 הוא הפרט העיצובי החד ביותר בכל המחקר, והוא בדיוק הבאג שתיקנתי היום.

יישמתי אותו — ראה §6.1.

4.2 Basecamp — Hill Charts, והנקודה החתרנית

uphill = עדיין מבינים איך; downhill = ביצוע טהור. ו־Hilltop View מציג את כל הפרויקטים במסך אחד.

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

מה שאדם אמיתי מרגיש לגבי העבודה.

זה חתרני ושווה לקחת ברצינות אצלנו: אחוז־השלמה מחושב ממניין משימות שגוי בדיוק ברגע שהוא חשוב

(90% מהמשימות, 0% מהבעיה הקשה). ואצלנו: "הסוכנים מדווחים 80%" היא טענה, לא מדידה.

ההבחנה uphill/downhill היא בדיוק מה שמנהל קריאייטיב צריך כדי להחליט לאן לשים תשומת לב.

4.3 Dagster — המטאפורה הנכונה למפעל שלנו

Dagster ממדל גרף נכסים, לא גרף משימות: הצמתים הם דברים שקיימים

(טבלה, קובץ, מודל) — לא צעדים שרצו.

זו המטאפורה הרלוונטית ביותר בכל המחקר עבורנו.

המפעל שלנו לא מייצר בעיקר ריצות — הוא מייצר תוצרים:

מסמך חזון, ערכת מותג, ספק, URL פרוס.

קונסולת גרף־נכסים ("אילו תוצרים קיימים, מי מהם מיושן, מי חסום")

מתאימה לצינור PRISM הרבה יותר מרשימת ריצות.

וזה מיישר עם P3 שלנו — מסמכים ניתנים להרצה: התוצר הוא היחידה, הריצה היא פרט מימוש.

4.4 Jira Plans — לדלג

פותר תחרות על אנשים נדירים בין צוותים. אצלנו אדם אחד וסוכנים אלסטיים. לא רלוונטי.

5 · מה מדלגים — רעש בקנה מידה ארגוני

מה	למה לדלג
Microsoft Agent 365 / Google Agent Registry / Bedrock AgentCore	פותרים "סוכני צללים אצל אלפי עובדים". הרישום שלנו הוא `company.yaml`. לקרוא בשביל אוצר המילים (זהות, רישום, אודיט, kill switch), לא לקנות
Jira Plans — קיבולת ותלויות	ראה 4.4
מנגנוני ריבוי־מאשרים (קוורום, מניעת אישור־עצמי)	חסרי משמעות עם מאשר אחד. הפרט היחיד ששווה: הגייט מוצמד ליעד (סביבה/שלב), לא לפעולה
פלטפורמות observability כמשטח השליטה	ראה §1. מצוינות — מתחת, לא במקום
Temporal/Airflow כתשתית	ללמוד את הדפוסים. להפעיל אשכול Temporal ל־15 סוכנים ואדם אחד — תשתית שתצרוך יותר קשב משתחסוך
כל ליסטיקל "Top N Tools 2026"	חלקם עדיין ממליצים על Humanloop, שמת ב־9.2025

6 · מה כבר יישמתי מהמחקר — היום

המחקר לא נשאר על הנייר. שני דברים נכנסו לקוד באותו יום.

6.1 ✅ כלל ההתיישנות של Linear — מיושם

הבעיה שמצאתי: הלוח הכריז 33 משימות "running". בבדיקה:

30 לא זזו 17–21 יום · 32 בלי קבלה · 6 הן פיקסצ'רים של e2e שנשכחו.

ומתחת לזה באג אמיתי: לכל 33 היה updated_at זהה, שווה ל־plane_synced_at.

patch_task_external_refs עדכן updated_at, וסנכרון Plane קרא לו לכל משימה בכל ריצה —

כך שהשדה היחיד שיכול היה לחשוף לוח תקוע נמחק בידי התהליך שאמור היה לצפות בו.

התיקון:

tasks.patch_task_external_refs(..., touch=False) — רישום־ספרים לא מזייף עדות עבודה
שלושת אתרי הקריאה ב־plane_sync.py עברו ל־touch=False
live_board.assess_task_freshness() + board_honesty() — קריאה בלבד, לפי הכלל הא־סימטרי:

רק running מתיישן. blocked/failed לעולם לא — סטטוס רע ישן עדיין נכון

created_at לא ניתן לזיוף, ולכן הכלל לוקח את המבוגר מבין השניים
9 טסטים חדשים (test_board_staleness.py + 3 ב־test_runtime_failclosed.py)

למה קריאה בלבד ולא שינוי אוטומטי של 33 משימות: זו בדיוק הכתיבה ההמונית הבלתי־מבוקרת

שנכווינו ממנה, וחלק מהמשימות שייכות למוצרים מוקפאים בבעלות אחרים.

לחשוף את האמת זה שלי; לשנות משימה של בעלים אחר — לא.

6.2 ✅ הכרעה על `prism-live`

ההכרעה: להוריד את הלינק עד שיהיה בו רענון.

לפי §3, לינק שמחזיר 200 עם נתונים מ־1.7 הוא הכשל המסוכן ביותר בקטגוריה —

הוא נראה אמת. חוק 15א שלנו אומר את זה כבר: לינק שמשקר גרוע מאין לינק.

הנימוק לבחור הורדה על פני רענון־אוטומטי: רענון אוטומטי דורש תזמון ומקור אמת חי,

וזו עבודה אמיתית שלא תיגמר היום. להשאיר אותו באוויר עוד שבוע = לאמן את בן לא לסמוך על לינקים —

בדיוק כשאנחנו מבקשים ממנו להתחיל לסמוך עליהם.

מה שמחליף אותו בינתיים: orion-studio-stages — שנבנה מהרפו ולכן לא יכול להתיישן בשקט.

⚠️ טרם ביצעתי את ההורדה — prism-live מוזכר ב־company.yaml ובסקריפט משותף,

וזו נגיעה בתשתית משותפת. מתואם עם אביב לפני ביצוע.

7 · מה זה אומר ל־Claude Design — הקלט לשלב הבא

זה מה שסבב העיצוב מקבל ממני. אני לא מעצב כאן — אלה האילוצים.

#	דרישה מהמחקר	מקור
1	"מה מחכה לך" בשורה העליונה — בן הכריע, והמחקר תומך: saturation שלו הוא האילוץ	Q5 + §3.2
2	גיל לכל אריח, לא חותמת אחת בפינה. אריח שעבר SLA מתדרדר ויזואלית	§3.1
3	אפור ≠ אדום. "לא יודע" מצב נפרד. מקווקו לפני אפור	§4.1
4	גרף נכסים, לא רשימת ריצות. התוצר הוא היחידה	§4.3
5	ארבע פעולות: Accept / Edit / Respond / Ignore	§2.3
6	סטטוס אנושי uphill/downhill — לא אחוז מחושב מספירת משימות	§4.2
7	כל גייט מצהיר מה קורה בשתיקה	§2.4
8	"להשוות דומה לדומה" — מוצר רועש אחד לא יטביע שבעה שקטים. השקטים הם המקום שנרקב	Grafana

8 · מה לא אומת — ביושר

רישיון ומספר כוכבים של AgentOps — לא נבדק במקור
מצב התחזוקה של HumanLayer אחרי שהמיזם עבר ל־IDE לסוכני קוד — לא מאומת
טענת ברירת המחדל Manual ב־Claude Code v2.1.200 — ממקור משני בלבד
פער כוכבי Langfuse (20.5k לפי ClickHouse מול "28,000+" בליסטיקלים) — נטיתי למספר הנמוך של הספק
אין מימוש מאומת של אצוות אישורים מדורגות־סיכון — נראה פער אמיתי בשוק

רוב מקורות פרק 3 הם בלוגים של ספקים (Sifflet, Tacnode, Databricks) ולא מחקר שפיט.

לקחתי מהם את צורת הכשל — שמתוארת זהה אצל ספקים מתחרים, מה שנותן שילוש סביר —

ולא את הסטטיסטיקות.