Архитектура на подагента: Как да спрете вашия кодиращ агент да изразходва целия си бюджет за токени при търсене на хранилища

Повечето инженерни екипи, внедряващи агенти за кодиране с изкуствен интелект, третират модела като един-единствен участник: той получава задача, изследва кодовата база, формира хипотеза и генерира решение. Тази архитектура е интуитивна и лесна за изпълнение, но носи структурни разходи, които се увеличават с нарастването на кодовите бази. Моделът, който извършва изследването, е и моделът, който извършва разсъжденията, което означава, че всяко четене на файл, всяко преминаване с grep и всяко търсене в задънена улица запълва един и същ контекстен прозорец, който би трябвало да бъде запазен за последователно решаване на проблеми. Резултатът е контекстен прозорец, който се запълва с навигационен шум, преди решаващият да е написал и един ред код. Справянето с това изисква обмислено архитектурно решение, а не бързо инженерно решение.

Проблемът с бюджета на токените в голям мащаб

Мащабът на неефективността е по-голям от очакванията на повечето екипи. Анализ на траекториите на агентите GPT-5.4, проведен като част от изследването FastContext на Microsoft, установи, че операциите по четене и търсене представляват 56,2% от всички използвани инструменти и 46,5% от общото потребление на токени от основния агент. Това означава, че почти половината от бюджета за токени за типична задача се изразходва за навигация, а не за работата, за която е разположен агентът. За екипи, работещи с агенти срещу големи монохранилища, това създава усложняващ се проблем: колкото по-сложна е кодовата база, толкова повече проучване е необходимо и толкова повече ефективният контекст на решаващия инструмент е изместен от артефакти за извличане. В производствен мащаб това се изразява директно в по-високи разходи за извод, по-дълга латентност и влошено качество на изхода, тъй като моделът се фокусира върху неподходящ контекст.

Защо монолитните агенти се провалят в мащаб на хранилище

Режимът на отказ е по-скоро архитектурен, отколкото специфичен за модела. Един агент, натоварен както с проучване, така и с генериране, трябва да поддържа едновременно две различни когнитивни състояния: отворено, генериращо хипотези състояние по време на търсене и фокусирано, основано на доказателства състояние по време на синтез на код. Тези състояния си противоречат. Проучвателното търсене се възползва от широчината, като води до много частични четения и спекулативни достъпи до файлове. Генерирането на код се възползва от компактен, високосигнален контекст, съдържащ само файловете и диапазоните от редове, пряко свързани със задачата. Когато и двете дейности споделят контекстен прозорец, проучвателната фаза замърсява генеративната фаза. Моделът се грижи за остарели резултати от търсенето и междинни наблюдения, които е трябвало да бъдат отхвърлени, намалявайки ефективното съотношение сигнал/шум в точката на генериране.

Разделянето на ролите като структурно решение

Архитектурният отговор е да се отдели извличането от генерирането чрез въвеждане на специален субагент за изследване. Моделът FastContext на Microsoft операционализира този модел директно. FastContext е лек субагент, достъпен във варианти с параметри 4B и 30B, изграден върху Qwen3 гръбнаци, който се извиква при поискване от главен кодиращ агент. Той издава паралелни извиквания на инструменти само за четене в операции READ, GLOB и GREP, изпълнява вътрешен цикъл за наблюдение и прецизиране и връща компактен блок от файлови пътища и диапазони от редове към главния агент, вместо пълната следа на изследването. Главният агент никога не вижда навигационната работа; той получава само обоснованите цитати, необходими за започване на генерирането. Това разделяне означава, че контекстният прозорец на решаващия инструмент започва чист, попълнен с целеви доказателства, а не с натрупания остатък от преминаване през хранилище.

Какво показват данните за производителността

Емпиричните резултати от интегрирането на FastContext в Mini-SWE-Agent си струва да бъдат разгледани подробно, защото те количествено определят както качествените, така и ценовите аспекти на архитектурната промяна. С GPT-5.4 като основен агент и FC-4B-RL като подагент, процентът на разрешаване на транзакции в SWE-bench Multilingual се подобрява от 71,7% на 74,7%, докато потреблението на токени от основния агент пада от 457 000 на 338 000, което е намаление с 26%. В бенчмарка SWE-QA потреблението на токени пада от 418 000 на 210 000, което е намаление с приблизително 50%, с незначително подобрение на качеството от 0,7 процентни пункта. Вариантът FC-30B-SFT постига най-голямото подобрение на качеството в SWE-bench Multilingual, достигайки 75,0% разрешаване при намаление на токените с 22,1%. Във всички тествани конфигурации моделът е последователен: архитектурите, подпомагани от подагенти, намаляват потреблението на токени от главния агент с 14% до 60%, като същевременно подобряват или поддържат процентите на разрешаване на проблеми, като същевременно се наблюдават само незначителни разходи от собствените операции на подагента. За екипи, които плащат разходи за API на frontier модела при големи обеми, намалението от 26% до 50% в използването на токени от главния агент е съществен разход, а не вторична полза.

Архитектура на модела, базиран на цикли

Паралелно развитие в архитектурата на модела адресира свързана неефективност: цената на мащабиране на изчисленията по време на извод. Стандартните подходи за подобряване на производителността на кодиращия агент по време на тестване включват генериране на повече токени, или чрез верижно разсъждение, или чрез многократно семплиране. Паралелните циклични трансформатори (PLT) предлагат алтернатива чрез прилагане на споделени трансформаторни блокове в многократни преминавания върху латентното представяне, увеличавайки ефективната изчислителна дълбочина без пропорционално увеличаване на генерирането на токени. LoopCoder-v2, 7B PLT модел, обучен върху 18 трилиона токена, демонстрира, че конфигурация с два контура подобрява производителността, проверена от SWE-bench, от 43,0 на 64,4 точки и Multi-SWE от 14,0 на 31,0 точки спрямо базова линия без цикли (Yang et al., arxiv 2026). Механизмът е, че вторият контур осигурява продуктивен прецизиращ проход върху латентното представяне, коригирайки първоначалните кодирания, без да генерира допълнителни изходни токени. От решаващо значение е, че варианти с три или повече цикли намаляват производителността, немонотонен ефект, обяснен с несъответствието в позициите между циклите, въведено от механизма CLP, което се превръща в доминиращ разход, след като пределното усъвършенстване от допълнителни цикли намалее (Yang et al., arxiv 2026). За екипите, оценяващи избора на модел за кодиращи агенти, това откритие има пряко значение: по-дългото изчисление за време на извод не винаги е по-добро и оптималната конфигурация изисква емпирична валидация, а не предположение.

Инженерни компромиси в архитектурите на подагентите

Приемането на архитектура на подагент въвежда сложност на координацията, която екипите трябва да вземат предвид, преди да се ангажират с модела. Главният агент трябва да управлява извикването на подагент, включително да решава кога да делегира проучване, вместо директно четене. Ако тази логика на вземане на решения е лошо калибрирана, разходите за извикване на подагент могат да надхвърлят спестяванията от по-чист контекст, особено в малки или добре структурирани хранилища, където едно целенасочено четене би било достатъчно. Латентността също е съображение: цикълът на проучване на подагента въвежда допълнителни двупосочни обработки, преди главният агент да може да започне генерирането. В синхронните конвейери това добавя време за работа на стената, дори когато намалява цената на токените. Екипите, изпълняващи работни процеси, чувствителни към латентност, като например интерактивни асистенти за кодиране, ще трябва да оценят дали печалбите от качество и разходи оправдават добавената латентност или дали подагентът трябва да се извиква само за задачи над праг на сложност. Идентичността и разрешенията на агента също стават по-сложни в многоагентните системи; всеки подагент се нуждае от собствен обхват на права, а одитните следи трябва да обхващат пълния граф на повикванията, а не действията на отделен агент.

Планиране на прехода

Екипите, които понастоящем използват монолитни кодиращи агенти, не е необходимо незабавно да преустройват системите си, но архитектурната насока е достатъчно ясна, за да информира за краткосрочните решения относно инфраструктурата. Първата практическа стъпка е инструментацията: измерване на това каква част от текущото потребление на токени на агентите се дължи на проучване спрямо генериране. Ако тази цифра се доближи до 46%, наблюдавани в траекториите на GPT-5.4, аргументите за разделяне на ролите са силни. Втората стъпка е оценка дали разпределението на задачите оправдава фино настроен субагент за извличане или дали по-малък модел с общо предназначение с ограничен достъп до инструменти може да се представи адекватно. Вариантът 4B-RL на FastContext постига конкурентна производителност с варианта 30B-SFT в повечето бенчмаркове, което предполага, че фокусираната върху извличането фина настройка в по-малък мащаб е по-ефективна инвестиция от мащабирането на броя на параметрите на модела за извличане. Екипите трябва също да обмислят как се валидират изходите на субагентите, преди да бъдат предадени на решаващия инструмент; субагент за извличане, който връща неправилни цитати на файлове, не се проваля шумно, а тихо влошава качеството на генериране, което прави мониторинга на изходите необходимо допълнение към архитектурата.