$ man how-to/orchestrating-multi-agent-workflows

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

PATTERN

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

PATTERN

כל סוכן מקבל פרומפט משלו עם ההקשר שלו. סוכנים לא חולקים הקשר ביניהם. סוכן ב' לא יודע מה סוכן א' עושה. זה פיצ'ר, לא באג. זה אומר שיש לך שליטה מלאה על מה שכל סוכן רואה ועושה. פרומפט סוכן טוב כולל: המשימה הספציפית ("צור את הקובץ website/packages/shared/data/how-to-wiki.ts"), התבנית לעקוב אחריה ("שקף את המבנה של clay-wiki.ts"), הנתונים או התוכן הספציפי לכלול, הפניות לקבצים שהוא צריך לקרוא להקשר, וקריטריון ההצלחה ("הקובץ צריך לייצא מערך מוקלד של 17 ערכים עם תוכן WikiSection מלא"). פרומפטים גרועים לסוכנים הם מעורפלים. "בנה את הויקי." פרומפטים טובים לסוכנים הם ספציפיים. "צור how-to-wiki.ts עם ממשק HowToWikiEntry, 6 קטגוריות, 17 ערכים, ופונקציות עזר בעקבות התבנית המדויקת של context-wiki.ts."

FORMULA

השק סוכני גל 1 במקביל. עקוב אחרי ההתקדמות שלהם. כשכל סוכני גל 1 מסיימים, אמת את הפלט שלהם לפני השקת גל 2. אימות בין גלים תופס שגיאות מוקדם. רשימת אימות לכל גל: - האם הקבצים שנוצרו קיימים בנתיבים הצפויים? - האם הטיפוסים והממשקים תואמים למה שהצרכנים למטה מצפים? - האם הbuild עדיין עובר אחרי השינויים של הגל? - האם יש שגיאות TypeScript או linting? רק אחרי שהאימות עובר אתה משיק את הגל הבא. אם סוכן ייצר פלט גרוע, תקן את זה לפני שממשיכים. תשתית גרועה מגל 1 פירושה שכל סוכן בגל 2 בונה על הנחות שגויות. אימות סופי אחרי כל הגלים: בנה את כל הפרויקט, בדוק שכל הנתיבים מרנדרים, ודא שקישורים צולבים עובדים, אשר שמטא-נתוני SEO נכונים. זה שער האיכות האחרון לפני שהפיצ'ר יוצא.

PRO TIP

כשבניתי את Clay Wiki, התזמור היה: גל 1 - סוכן אחד כתב את קובץ הנתונים (כל 17 הערכים, טיפוסים, פונקציות עזר). גל 2 - שלושה סוכנים רצו במקביל: רכיב דף מרכזי, רכיב דף פרטים, והגדרת נתיב ShawnOS. גל 3 - שני סוכנים רצו במקביל: עדכוני ניווט ומילוי קישורים צולבים. גל 4 - סוכן אחד הריץ build ואימת את כל הנתיבים. זמן כולל: מתחת ל15 דקות. הערכת זמן סדרתי: מעל 45 דקות. הפרש המהירות הגיע מתכנון. זיהוי אילו משימות עצמאיות. קיבוץ שלהן לגלים. מתן ההקשר המדויק שכל סוכן צריך. הביצוע עצמו היה מהיר. התכנון הוא מה שאיפשר את הביצוע.