Сьогодні я прочитав довгу статтю про інженерію упряжки — десятки тисяч слів, майже напевно написану штучним інтелектом. Моя перша реакція була не «вау, яка потужна ідея». Це було питання: «Чи є у цих людей якісь ідеї, окрім вигадування нових термінів для старих?» Мене завжди дратувала ця закономірність у світі штучного інтелекту — постійне переосмислення існуючих концепцій. Від інженерії підказок до контекстної інженерії, а тепер до інженерії упряження. Кожні кілька місяців хтось вигадує новий термін, пише есе на 10 000 слів, додає кілька кейсів великої компанії, і вся спільнота починає гудіти. Але якщо подивитися на контент, то завжди одне й те саме: Спроектуйте середовище, в якому працює ваша модель — яку інформацію вона отримує, які інструменти може використовувати, як перехоплюються помилки, як керується пам'яттю між сесіями. Це існує з дня запуску ChatGPT. Вона не стає новою дисципліною лише тому, що хтось — з якоїсь причини — вирішив дати їй нову назву. Втім, незважаючи на скарги, дослідження та кейс-стаді, наведені в статті, мають цінність — особливо тому, що вони сильно перетинаються з тим, що я створював із інструкціями як сгленг. Тож дозвольте використати цю нагоду поговорити про помилки, які я насправді зробив. Спочатку трохи передісторії. Найпоширеніші запити у спільноті SGLang — це питання як зробити — як розгорнути DeepSeek-V3 на 8 GPU, що робити, якщо шлюз не може досягти адреси працівника, чи є розрив між GLM-5 INT4 і офіційним FP8 значним. Ці питання охоплюють надзвичайно широкий технічний шар, і чим швидше зростає спільнота, тим менше ми можемо встигати за відповідями. Тож я почав створювати багатоагентну систему для автоматичної відповіді на них. Перша ідея, звісно, була найнаївнішою — створити єдиного всезнаючого Агента, вмістити в нього всі документи, код і кулінарні книги SGLang, і дати йому відповідати на все. Це не спрацювало. Вам не потрібна теорія інженерії угод, щоб пояснити це — контекстне вікно не є оперативною пам'яттю. Чим більше ви вкладаєте в неї, тим більше увага моделі розсіюється і тим гіршими стають відповіді. Агент, який намагається одночасно розуміти квантування, PD-дезагрегацію, дифузійне обслуговування та апаратну сумісність, не розуміє жодного з них глибоко. Дизайн, на який ми зрештою зупинилися, — це багатошарова субдоменна експертна архітектура. Документація SGLang вже має природні функціональні межі — розширені функції, платформи, підтримувані моделі — з кулінарними книгами, організованими за моделями. Ми перетворили кожен піддомен на незалежного експертного агента, де менеджер з експертних дебатів відповідав за прийом запитань, їх розкладання на підпитання, консультацію з Таблицею Експертної Маршрутизації для активації потрібних агентів, паралельне розв'язання та аналіз відповідей. Озираючись назад, цей дизайн майже ідеально відповідає візерункам, які пропагує спільнота інженерів упряжі. Але коли я його створював, я й гадки не мав, що ці візерунки мають назви. І мені це не було потрібно. 1. Поступове розкриття інформації — ми не перекладали всю документацію на одного агента. Кожен експерт завантажує лише власні знання домену, а менеджер вирішує, кого активувати, залежно від типу питання. Моє внутрішнє відчуття підказує, що ця конструкція дала набагато більше покращень, ніж заміна на міцнішу модель. Вам не потрібно знати, що це називається «прогресивним розкриттям», щоб прийняти таке рішення. Достатньо було спробувати підхід «заповнити все» один раз і побачити, як це провалилося. 2. Репозиторій як джерело істини — весь робочий процес зберігається у репозиторії з інструкціями до сглангу. Усі експертні агенти отримують знання з файлів markdown у репозиторії, не залежачи від зовнішніх документів чи усних домовленостей. На початку у нас з'явилося бажання написати одну масштабну sglang-maintain.md, що охоплює все. Ми швидко зрозуміли, що це не працює. Команда OpenAI з Codex зробила ту ж помилку — вони спробували один надвеликий AGENTS.md і спостерігали, як він гниє у передбачуваний спосіб. Вам не потрібно читати їхній блог, щоб самі наступити на цю міну. Це класична проблема інженерії програмного забезпечення — «монолітна документація завжди нудьгає», але в контексті агента наслідки гірші — застаріла документація не просто залишається непрочитаною, вона активно вводить агента в оману. 3. Структурована маршрутизація — Експертна таблиця маршрутизації явно відображає типи запитань з агентами. Питання про GLM-5 INT4 активує одночасно і експерта з домену кулінарної книги, і експерта з квантування. Менеджер не здогадується; Вона слідує структурованому індексу. Прихильники інженерії упряжі називають це «механізованими обмеженнями». Я називаю це нормальною інженерією. Я не кажу, що ідеї інженерії упряжі погані. Цитовані дослідження є надійними, концепція ACI від SWE-agent справді варта знати, а архітектура Anthropic з двома агентами (ініціалізатор-агент + кодуючий агент) є цінним довідковим матеріалом для всіх, хто виконує завдання з довготривалим горизонтом. Мене втомлює постійне вигадування нових термінів — пакування усталеного інженерного здорового глузду як нову дисципліну, а потім створення тривоги навколо «ти відстаєш, якщо не знаєш цього слова». Інженерія підказок, контекстна інженерія, інженерія жгутків — це різні аспекти однієї й тієї ж речі. Наступного місяця хтось, ймовірно, запропонує інженерію риштувань або оркестровку, напише ще одне довге есе, посилаючись на ту ж роботу агента SWE, і спільнота розпочне новий цикл підсилення. Те, чого я насправді навчився з «як сглангувати», можна описати без жодної нової лексики:...