הגיע הזמן למחרוזות חיבור llm://

פשטו את תצורת המודל והספק עם כתובות llm://

עדכון: מאמר זה הוביל לטיוטת אינטרנט עבור סכמת ה‑URI llm://.

זוכרים את הימים הקשים כשהתחברות למסד נתונים דרשה לנהל קופסה של משתני סביבה שונים?

זה היה מגדל של קונפיגורציה עדינה. DB_HOST, DB_PORT, DB_USER, DB_PASSWORD, DB_NAME… או רגע, זה היה DB_USERNAME? זה DB_PASS או DB_PWD? האם צריך את הקידומות PG_* הפעם? והיכן בכלל הולך הגדרת ה‑timeout?

זה היה בית קלפים שבור, מוכן לקרוס את בניית ה‑production שלך רק בגלל ששכחת להגדיר את HOST באותיות גדולות.

ואז מישהו הגיע עם הרעיון המבריק להשתמש ב‑URL¹:

postgres://user:pass@host:5432/dbname

מחרוזת אחת. כל מה שצריך. ניתנת לפירוש אוניברסלי. ניידת. אפשר לומר… יפה?

אז למה אנחנו מתייחסים ל‑LLM‑ים כאילו זה 1999?

פיצוץ משתני הסביבה

כרגע קובץ ה‑.env שלי נראה כמו בית קברות של מפתחות API שננטשו. OPENAI_API_KEY, ANTHROPIC_API_KEY, MISTRAL_API_KEY, GROQ_API_KEY. ואל תתחילו עם Azure—צריך נקודת קצה, שם פריסה, גרסת API, ומפתח רק כדי לומר “היי”.

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

מה אם פשוט… גנבנו השאלנו את רעיון כתובת ה‑DB?

הצגת מחרוזות חיבור LLM

דמיינו שאתם מגדירים את כל ממשק המודל שלכם בשורה אחת:

llm://api.openai.com/gpt-5.2?reasoning_effort=none&temp=0.7&max_tokens=1500
llm://api.z.ai/glm-4.7?top_p=0.9&cache=true

מבנה של מחרוזת חיבור LLM

הסכמה היא llm://. המארח הוא כתובת הבסיס של ה‑API של הספק. הנתיב הוא שם המודל. פרמטרי השאילתה מטפלים בכל אפשרויות הריצה שלרוב מציפות את הקוד שלכם.

צריך אימות? מצוין, הוסיפו אותו.

בדיוק כמו postgres://, אפשר לשלב אימות ישירות במחרוזת:

llm://app-name:sk-proj-123456@api.openai.com/gpt-5.2?reasoning_effort=none&temp=0.7

הערה: כן, הכנסת אישורים ל‑URL יכולה להיות סיכון אבטחה אם אתם מדביקים אותם ביומני ציבור. אבל שירותי יומן מודרניים טובים למדי בניקוי תבניות כאלה, ובכנות, האם אתם מתייחסים לקובץ .env שלכם הרבה יותר טוב? אמתו, נקהו, והשתמשו בזהירות.

עמידות? למה שלא.

ספריות רבות לבסיסי נתונים תומכות במעבר סיבובי (round‑robin) על‑ידי ציון כמה מארחים. למה שלא סוכני ה‑AI שלנו יהיו באותה רמת אמינות?

llms://primary.gpt,backup.gpt/gpt-6?temp=0.9

אות ה‑s ב‑llms:// איננה טעות הקלדה. היא ריבוי. אם primary.gpt נתקע, הלקוח מנסה אוטומטית את backup.gpt. אין צורך בלוגיקה מורכבת של נתב.

מחרוזת אחת שמכילה את כל מה שצריך – אימות, קצה, פרמטרים.

פורמטים חלופיים

אני לא קשור ל‑llm://. הסכמה הספציפית חשובה פחות מהסטנדרט עצמו.

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

ollama://localhost:11434/llama3
vercel://anthropic/sonnet-4.5?temp=0.8&web_search={"maxUses":3}
bedrock://us-west-2.aws/anthropic/sonnet-4.5?temp=0.8&cacheControl=ephemeral

ללא קשר לסינטקס המדויק, היתרונות המרכזיים אינם ניתנים להכחשה:

1. ניידות: העתקה והדבקה של כל הקונפיגורציה שלכם מסקריפט מקומי לעובד ענן.
2. ידידותי ל‑CLI: העברת ארגומנט יחיד לסקריפטים שלכם. my-agent --model "llm://..." מנצח על my-agent --model gpt-4 --temp 0.7 --key $KEY --host ....
3. שפה‑אגרגטית: לכל שפת תכנות יש parser URL חזק. אנחנו מקבלים ולידציה, ניתוח, וניקוי בחינם.

עולם מסדי הנתונים לקח עשרות שנים להבין זאת.
חדשות טובות, בקנה מידה של AI זה רק לפני חצי שנה‑וויב.

המסקנה

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

בואו נפסיק להמציא את הגלגל מחדש ונתחיל להתייחס לחיבורים שלנו ל‑LLM באותו כבוד שאנו מעניקים למסדי הנתונים. קובץ ה‑.env שלכם (והשפיות שלכם) יודה לכם.