Один агент із добрим контекстом кращий за рій: чому передачі ламають мультиагентний код

Сім агентів, одна видалена функція

Оркестратор запустив сім агентів. Шестеро написали одну й ту саму функцію, а сьомий її видалив. Ось скорочений дифф, бо побачити це наочніше, ніж прочитати переказ:

+ def limit(req):            agents/a2.py
+ def rate_limit(req):       agents/a3.py
+ def check_limit(r):        agents/a4.py
+ def limiter(request):      agents/a5.py
+ def apply_limit(req):      agents/a6.py
+ def limit(req):            agents/a7.py
- def limit(req):            agents/a7.py  (removed a2's copy)

П'ять версій однієї функції на сорок рядків, кожна цілком розумна сама собою, і жодна не знає про існування інших. Потім сьомий агент помітив дубльоване ім'я, вчинив відповідально й видалив ту версію, яку імпортувало все інше. Спостерігаючи, як це прокручується на екрані, поки згорають справжні гроші, я відчув не роздратування, а ніяковість: найдорожча машина, яку тільки можна уявити, щойно зібрала папку, що не компілюється, за архітектурною схемою, якою хтось пишався.

Якщо ви колись малювали прямокутники з підписами Planner, Coder, Reviewer і Tester і відчували легке задоволення від того, що проєктуєте щось серйозне, це про вас.

Арифметика, якої немає на слайдах

Візьмімо агента, який має рацію в 95 відсотках випадків, а це справді добрий агент. З'єднайте п'ятьох у ланцюжок і подивіться, що буде. Цикл виконується за чотири секунди:

p = 0.95
for n in range(1, 6):
    print(n, round(p**n, 2))

1 0.95
2 0.9
3 0.86
4 0.81
5 0.77

Тверда п'ятірка перетворилася на трійку, а рахунок зріс уп'ятеро. Доповідей про оркестрацію агентів повно, але цей маленький цикл рідко потрапляє на слайд.

Ламається на передачі

Це найдовше не впадало в око. Агент, глибоко занурений у задачу, несе величезний обсяг невисловленого стану. Він знає, що middleware авторизації тримається на ізострічці, що тести завищують покриття і що очевидне виправлення вже пробували, і воно все зламало.

Під час передачі нічого з цього не переходить. Далі йде записка токенів на триста, щонайбільше на тисячу, а все інше зникає разом із процесом. Другий агент працює не з тим, що знав перший, а з переказом цього знання, і ухвалює несучі рішення поверх стиснутого залишку.

FIVE AGENTS

  [A1] --msg--> [A2] --msg--> [A3] --msg--> [A4]
   |             |             |             |
  full          ~300          ~300          ~300
  context       tokens        tokens        tokens
   |             |             |             |
  knows         guesses       guesses       guesses

ONE AGENT
   retrieval ---+
   memory    ---+---> [ AGENT ] ---> output
   tools     ---+         ^  |
   compaction---+         |  |
                          +--+
                     one head, one state,
                     nothing lost in transit

Найкращі аргументи за мультиагентність

Протилежна точка зору сильна, тож вислухаймо її як слід. По-перше, спеціалізація працює: на конкретній задачі агент із вузьким промптом обходить універсала. По-друге, вікна контексту скінченні, а п'ять вікон дають уп'ятеро більше місця. По-третє, свіжий контекст — єдиний рев'юер, якому можна довіряти. Агент, що витратив шістдесят тисяч токенів на те, щоб переконати себе в якомусь дизайні, погано підходить для його оцінки. Нарешті, дослідницькі системи, які одночасно перекопують багато джерел, справді обходять однопотокові, і цей виграш виміряно, а не розрекламовано.

Тож розпаралелювання не померло. Просто його застосовують не в тому вимірі.

Читання розпаралелюється, запис — ні

Рахувати агентів — хибний критерій. Важить інше: чи ухвалюють підзадачі рішення, які мають бути узгоджені між собою. Читання ділиться майже безкоштовно, чи то сорок джерел, сотня файлів, чи шість тверджень на перевірку, бо ніхто нічого не фіксує і немає спільного стану, який можна розірвати.

Із записом усе навпаки. Дозвольте двом агентам самостійно обрати форму API, і ви отримаєте два дизайни, кожен із яких логічний, але між собою вони не стикуються. Їх узгодження забирає більше часу, ніж виконання роботи крок за кроком.

hits = par([find(q) for q in qs])   # reads fan out
patch = run(req, ctx + hits)        # writes go through one head

Коротко: читання розпаралелюйте, запис пропускайте через одне місце. Усе правило вміщається на серветці.

Нудна частина і є справжня робота

Головне тут не «один агент», а добрий контекст, і це нудна, нефотогенічна робота:

• пошук, який знаходить потрібні чотири файли, а не топ-20 за косинусною схожістю
• стиснення контексту, яке витримує довгу сесію
• пам'ять, яка зберігає, чому підхід відкинули, а не що було набрано
• вивід інструментів, оформлений так, щоб один виклик не з'їдав пів вікна

Організатори конференцій не просять доповідей про стратегії стиснення контексту, тож люди будують рої. Схему оркестрації легко прочитати з одного погляду, а три тижні роботи над вмістом промпту так не покажеш ніколи. Ці три тижні варто витратити, а потім витратити ще раз.

Спробуйте завтра

Залогуйте кожен токен, що потрапляє у вікно агента за одну повну сесію. Потім перечитайте лог і прикиньте, яка його частка стосувалася рішення, яке агентові насправді треба було ухвалити. У нашому випадку — менше третини. Блискучу модель годували потоком шуму з пожежного шланга, а потім звинувачували в тому, що вона не влучає.