Випадкова розмова про те, де ми знаходимося з агентами штучного інтелекту:

Деякі не називають їх агентами, але «агенти робочого процесу» з детермінованими потоками є скрізь і працюють. Будь-хто може створювати прості агенти робочого процесу, навіть починаючи з інструментів без коду, таких як Zapier і n8n. Складні агенти робочих процесів вимагають набагато більше думок для надійної та ефективної збірки. складний робочий процес для загального та цінного випадку використання, з відповідними інтеграціями, вбудованими, може стояти окремо як бізнес, а також чудовий GTM, щоб пізніше розширитися на інші робочі процеси або більш автономну роботу.

Починають працювати більш динамічні/автономні агенти, які корисні для досліджень (особливо якщо вони базуються на вебі) та кодування. менш надійним, коли ви починаєте додавати більше джерел даних (наприклад, API). Агенти, призначені лише для читання, почуваються безпечними та простими для тестування, але дозволяти автономним агентам виконувати дії (записувати) страшно. (Випадкова ідея з цього приводу: було б круто, якби такі інструменти, як CRM, дозволяли вам «розгалужувати» дзеркало розробників і проводити експерименти з автоматизацією, які ви можете відкотити назад або об'єднати назад.)

Динамічні агенти добре працюють, коли вони можуть (1) створити та відстежувати хороший план і (2) правильно виконувати завдання, водночас (3) знаходячи правильний контекст для кожного кроку (як планування, так і кожного завдання). Нарешті, він повинен (4) розмірковувати по ходу справи (з людською участю або без неї), щоб він міг відповідним чином скоригувати план, а також покращити спосіб виконання невдалих або погано виконаних завдань.

Планування завдань: можливості міркувань LLM Чудово підходять для простих списків завдань, які не потребують особистого контексту (наприклад, глибоке дослідження, просто серія пошуків в Інтернеті під час підбиття підсумків). Якщо ви хочете дослідити багато сутностей, глибоке дослідження не працює так добре, оскільки управління списком завдань є відносно простим. Інструменти штучного інтелекту на основі електронних таблиць краще підходять для дослідження багатьох сутностей, оскільки ви фактично вивантажуєте керування завданнями в електронну таблицю, оскільки передача довгих списків завдань між підказками тут не працює. Управління завданнями в Coding Agents працює з простими задачами, простим кодом або коли ви починаєте з нуля. Як тільки ви переходите до більш складних вже існуючих проектів, вони стають менш надійними, а розробники підвищують надійність, документуючи, як працює та організований їхній код (.md файли), що дозволяє агенту створювати більш обґрунтовані списки завдань. Складний код вимагає більше документів і в кінцевому підсумку динамічно витягує з цих документів лише релевантний контекст. Багато людей/компаній мають сильні незадокументовані думки щодо правильного порядку/підходу/інструментів для вирішення проекту, і нам потрібно більше підходів до документування цього заздалегідь і на льоту. Ще одна причина, чому кодування та веб-дослідницькі агенти працюють добре, полягає в тому, що всі вони використовують один і той самий набір інструментів, тому не потрібно «вчитися», як користуватися цими інструментами (докладніше про це далі).

Виконання завдань: завданнями зазвичай є виклики API (що вимагають аутентифікації та розуміння того, як використовувати API та базову структуру даних - яка може бути унікальною, як у CRM або БД з користувацькими таблицями/стовпцями), міркування LLM (наприклад, підсумовувати), комбінацію та навіть агентів робочого процесу*. Дослідницький агент – це насправді просто пошук в Інтернеті та узагальнення по колу. Агенти кодування є CRUD на вашій кодовій базі, і, можливо, пошук в Інтернеті навчальних API. Доступ до аутентифікації та базового API здається вирішеним (MCP підходять сюди), але я хотів би бачити більше навколо контексту конкретного інструменту (запитайте користувача, але також аналізуйте при початковому підключенні, копайте в існуючих даних, щоб зрозуміти, як використовується інструмент, як структуровані дані, для яких сценаріїв/проектів ми використовуємо інструмент.), помилки/рефлексія/зворотний зв'язок повинні перетворитися на організовані знання, які повертаються у вигляді контексту, коли це доречно. Одні й ті ж інструменти можуть використовуватися для різних цілей і по-різному в різних організаціях, і нам потрібно якось зафіксувати/задокументувати це, щоб добре виконувати завдання.

Контекст: Уявіть, що ви новий співробітник у компанії. Ви багато чому вчитеся під час онбордингу (і чим краще онбординг, тим ефективніше ви працюєте), а потім є навчання на роботі, яке розпадається на вивчення досвіду організації («Ось як ми робимо речі») та навчання на власному досвіді – раніше більше переважає у великих організаціях. Управління контекстом відбувається аналогічно. є такі шари контексту, як meta (користувач/компанія), конкретний проект/відділ, конкретний завдання, конкретний інструмент тощо. ми еволюціонували від простих системних підказок до гібридних стратегій RAG (вектор, ключове слово, графік), але крім даних/контексту, нам потрібні вказівки щодо того, коли і як отримати контекст, який ми бачимо ранні версії сьогодні - але є багато можливостей для вдосконалення. Це не лише технічна проблема, а й проблема бізнесу, оскільки вам в основному потрібно створити документ для адаптації, який охоплює всі сценарії, які ви очікуєте. У міру того, як проекти ускладнюються, потрібно більше вдумливості, щоб правильно скоротити контекст, щоб у prompt потрапляла лише релевантна інформація, мінімізуючи при цьому нерелевантний контекст.

Рефлексія: у нас є інструменти моніторингу агентів, які покривають витрати на LLM/api, спостереження, але призначення успіху/невдачі є викликом - одна область, де агенти кодування мають перевагу над іншими, є детермінований спосіб помічати збої (через тестування коду). Для багатьох інших агентних завдань ми все ще з'ясовуємо, як правильно збирати людський внесок для покращення майбутнього виробництва. Афаїк, Reflection сьогодні – це «людина в циклі», де зворотний зв'язок в основному передається розробникам-людям для покращення агента, але розблокування настає, коли ми з'ясовуємо, як перетворити рефлексію на самовдосконалення – де агент бере інформацію з невдач у генерації списку завдань та виконанні завдань, щоб наступного разу працювати краще. По суті, рефлексія має перетворитися на добре організований контекст, який можна перетворити на підказки тоді і лише тоді, коли це доречно. це еволюціонує в тонке налаштування частин агента, а потім у агентичне середовище RL - тут все ще відчувається досить рано

*Раніше я згадував про передачу завдань агентам робочого процесу, що починає мати сенс, коли вашому агенту буде вигідно мати без агентів робочого процесу як інструментів (замість того, щоб щоразу з'ясовувати відомий список завдань) або коли ваша система досить складна, щоб спеціалізовані агенти зі спеціалізованим контекстом та інструментами працювали краще. Або якщо ви використовуєте агентів, створених іншими PPL (одна з моделей, яку я почав бачити тут, - це кінцеві точки API природної мови для полегшення співпраці з агентами).

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

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

Чого мені ще не вистачає?