Аналіз нової роботи Anthropic: як побудувати ефективну команду співпраці людини та ШІ

6.24日，Anthropic офіційний блог опублікував нову статтю Building effective human-agent teams, автор Крістен Свансон.

Основна ідея статті полягає в обговоренні того, як парадигма командної співпраці ШІ змінюється: від «одна людина до одного чату (навіть якщо за ним стоїть багато агентів)» до «група людей і група агентів спільно використовують один робочий простір».

Автор цього допису, спираючись на основні ідеї оригіналу, поєднує їх із досвідом впровадження AI-агентів, пропонуючи структурований огляд та комплексне осмислення.

I. Головна теза: команди ШІ-співпраці перетворюються на «мережевий режим»

Раніше використання ШІ було «однокористувацьким» досвідом — одна людина співпрацювала з агентом, виконуючи особисті завдання.

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

Робота починає нагадувати «багатокористувацьку гру»: людська команда розробляє стратегію, а Claude її виконує.

Загалом, це спільні цілі, спільний контекст і, особливо, спільний робочий простір.

Як показано на малюнку нижче, відбувається перехід до складнішої робочої моделі праворуч:

А реалізує цей перехід новий продукт Anthropic — Claude Tag, форма, яка дозволяє Claude інтегруватися в командні інструменти співпраці, такі як Slack, і бути згаданим @ та призначеним, як член команди.

Отже, ця стаття — не чиста теорія, а напрямок, який просуває сам продукт Anthropic.

II. Що таке проблема «багатокористувацьких агентів»?

Оригінальна стаття дає таке визначення «multiplayer agents»: моделі ШІ, які одночасно співпрацюють з багатьма різними людьми.

Вони мають спільні риси зі звичайними агентами, але також і ключові відмінності:

• Спільне: мають власну пам'ять і навички.

• Відмінне: мають власні облікові дані,

і «живуть там, де відбувається робота» — у місці, де робота реально виконується.

В Anthropic це місце — командні інструменти співпраці, такі як Slack.

Це налаштування «мати власні облікові дані, жити в командному каналі» є надзвичайно важливим.

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

Щоб агент міг «ефективно брати участь» у командному каналі, потрібен набір специфічних базових можливостей (наприклад, форма продукту Claude Tag) + спеціально розроблена постійна пам'ять, ексклюзивна ідентичність, джерела інформації тощо.

Крім того, лише технічних можливостей недостатньо; для успіху людино-машинної команди потрібен набір робочих методів і спільних норм.

Тому наступні чотири поради в статті повністю стосуються досвіду розробки «норм» для команд ШІ-агентів.

III. Чотири поради для команди AI-агентів

Порада перша: реформуйте управління інформацією, надаючи агенту якомога ширший контекст

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

Оригінальна стаття прямо згадує щоденні муки: «Чи цей канал має бути публічним чи приватним? Чи можна поділитися цим документом з тією людиною? Чи може цей агент бачити це повідомлення?»

У межах кордонів контекст доступний кожному члену команди — як людині, так і ШІ, і навіть ШІ може, як людина, запитувати дозвіл на документи.

Цей трюк одночасно вирішує дві проблеми:

1. Розширює контекст, доступний і агенту, і людині;
2. Усуває втому від прийняття рішень, спричинену «поштучним обміном».

Віддача від відкриття доступу є реальною: більше немає втрат через передачу інформації, і оскільки агент читає текст набагато швидше за людину, він може «routinely surface relevant work that humans would otherwise have missed» (часто знаходити релевантні роботи, які інакше люди пропустили б).

На думку автора, це, по суті, зміна організаційної культури та механізму дозволів.

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

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

І для багатьох організацій із суворими вимогами до відповідності та ізоляції інформації (фінанси, медицина, міжюрисдикційна діяльність) «одномасове застосування до всього робочого простору» може бути нездійсненним.

Тому справді застосовним є спрощений механізм затвердження, який стоїть за цим: наприклад, якщо агент знаходиться в певній групі, він автоматично може читати документи, до яких ця група має доступ; навіть якщо є контроль доступу, ним можна керувати масово, а не спочатку надавати документи, а потім організовувати якість.

Порада друга: кожна людина/агент має чітку роль та інструменти

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

На цій основі агенти мають розподіл обов'язків:

• один агент володіє аналізом даних певного проекту;
• інший тримає та виконує дизайн-специфікації;
• третій відповідає за синтез досліджень.

На старті проекту люди спочатку спілкуються з агентом, вирішуючи, як розподілити ролі та як людина й агент співпрацюватимуть.

Потім створюється комбінація ролей, правил і часу втручання, як показано нижче.

Після визначення ролей агент може навіть «spin up» (запускати) інших агентів, гарантуючи, що кожне конкретне завдання буде передано агенту з правильною пам'яттю та правильним доступом.

Ключовим є наявність необхідних інструментів: агенту для аналізу даних може знадобитися доступ до BigQuery, агенту для QA — Playwright MCP.

Люди тримають ролі, які можуть виконувати лише люди, гарантуючи, що людське судження використовується для найважливіших рішень.

На думку автора: це також архітектура попередніх досліджень Anthropic щодо механізмів робочих процесів.

Використання головного агента для координації всього, делегування завдань спеціалізованим під-агентам, які працюють паралельно. Такий механізм справді практичний, показники якості майже подвоюються (на 90,2% вище), хоча вартість токенів зростає в 15 разів. Однак «більше агентів — сильніше» не є універсальним висновком, а скоріше «покращення на певному типі завдань за рахунок значних обчислювальних витрат».

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

І потрібно ретельно проектувати, добре розбивати завдання та ізолювати ролі, а не просто «накидати більше агентів».

Інакше це буде нове покоління непорозумінь на кшталт «урожай 18 000 цзинів з му».

Багато цих ідей також присутні в попередній статті про те, як використовувати Dynamic Workflows від Claude для глибоких досліджень.

Порада третя: встановіть Полярну зорю, дозволяючи агенту активно вирішувати проблеми

Оригінальна стаття розрізняє два типи агентів: одні просто «виконують призначені завдання», а найважливіші з них активно пропонують нові проекти та робочі процеси.

Останні зазвичай з'являються в команді, яка вже має багатий контекст і чіткі ролі, плюс додаткове керівництво — Полярна зоря.

Полярна зоря відповідає за допомогу команді визначити, «які завдання та робочі процеси є правильними».

Оригінальна стаття наголошує на кількох правилах:

• Полярна зоря завжди встановлюється людиною і ґрунтується на місії та бізнес-цілях компанії; • Після того, як Полярна зоря чітко записана, людина ділиться нею з агентами команди; • Потім — і це ключовий крок — людина обирає, які агенти повинні активно пропонувати нові робочі процеси.

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

Як у режимі маршрутизації (Classify-And-Act) у статті про глибокі дослідження з Dynamic Workflows від Claude: спочатку один агент визначає тип завдання, а потім передає його найбільш підходящому спеціалізованому агенту.

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

Перше — «динамічно керує власним процесом та використанням інструментів, контролюючи, як виконати завдання». А друге — детермінована система, «оркестрована через попередньо визначені шляхи коду».

Тому для створення ШІ-команди слід дати агенту Полярну зорю, а не список завдань, — це свідоме просування системи від workflow до агента.

Команда з метою принесе певну творчість, а не буде шукати роботу в обмеженому просторі.

Звісно, багато ШІ-команд, які ми створюємо зараз, насправді є програмованими або ШІ-зованими робочими процесами, і це вже вирішує багато проблем. Якщо нам потрібна творчість, самостійність, здатність активно вирішувати проблеми, тоді потрібно проектувати саме такі агентські команди.

Порада четверта: дозволяйте агенту зростати з часом

Тут офіційні дані мене дуже здивували: він сказав, що інженери Anthropic вже змогли змусити агента в команді самостійно обробити 500 виправлень помилок — але одразу підкреслив: «things certainly didn't start off that way (спочатку було зовсім не так)».

Він порівнює агента з новим людським колегою: потрібно багато раундів зворотного зв'язку, щоб зробити явними неявні знання про те, «як найкраще виконувати завдання».

Користувач повинен неодноразово тестувати агента різними завданнями, щоб зрозуміти межі його можливостей, як чітко описувати цілі, які файли навичок йому потрібні, який промпт найкраще викликає бажану поведінку.

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

Найціннішою в цій пораді є дискусія про верифікацію:

Ми виявили, що найкращі довгострокові агенти, перш ніж показати людині, мають багато способів перевірити свою роботу.

• Код має тести — це звісно;
• Але більшість іншої роботи також можна перевірити: технічну документацію можна оцінювати за критеріями (rubric) та стилістичними вказівками (style guide);
• Коли людина встановлює стандарти та гарантує, що вся робота, передана агенту, може бути перевірена, якість підтримується, не відхиляючись від початкової мети;
• Крім того, можна доручити одному агенту працювати, а іншому перевіряти — це так званий «Doer-Verifier» (виконавець-перевіряльник) harness для агентів.

Оригінальна стаття містить повний приклад: певний керівник інженерної команди взявся за нову команду з великим відставанням (backlog). Він зібрав кількох людей + кількох агентів, щоб разом визначити пріоритети.

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

Інша група відібрала пункти з низькою та середньою складністю, безпосередньо генеруючи зміни в коді.

Спочатку людина перевіряла кожне рішення агента і позначала ті, які потребують втручання; потім людина «навчила» агента передавати такі рішення безпосередньо людині, гарантуючи, що важкі рішення завжди залишаються під «human in the loop».

І щотижня команда доручала агенту складати звіт, що містить «уроки та помилки (lessons & missteps)», щоб агент запам'ятовував помилки та уникав їх повторення. З часом керівник міг доручати агенту все складніші зміни, витрачаючи все менше часу на щоденне керівництво, як показано на малюнку нижче:

Дуже схоже на процес вирощування розумних омарів.

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

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

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

Інші встановлюють для агента обмеження на «скільки роботи можна виконати за день» — щоб людина встигала осмислено брати участь і не втрачала важливі для себе навички.

На думку автора, ці поради є найглибшими в усій статті щодо «людино-машинних відносин».

• По-перше, в ідеології Anthropic: ефективний нагляд — це не схвалення кожного кроку, а «перебування в позиції, де можна втрутитися, коли це має значення» (being in a position to intervene when it matters).
• По-друге, явне ставлення до «людської уваги» як до дефіцитного ресурсу для оптимізації — це сильно недооцінений принцип проектування. Більшість дискусій про агентів зосереджені на оптимізації «можливостей агента», тоді як реальним вузьким місцем ефективності вже є «когнітивна пропускна здатність людини».
• По-третє, harness-інженерія в людино-машинній команді повинна повністю імітувати спосіб роботи ефективної команди, адже деяким хорошим коням справді не потрібна вуздечка, а лише ціль.

IV. Ера людино-машинної співпраці нещадно посилить організаційну якість початкової команди

Найчесніше і найлегше проігнорувати речення в статті з'являється в кінці:

Він каже, що наведені вище 4 поради насправді не є новими; вони існували задовго до появи ШІ. Хороша команда повинна мати сильну Полярну зорю, чіткі ролі, надійну документацію, спільні стандарти якості, простір для навчання на помилках — це все здорові командні звички, відомі нам десятиліттями.

А команда AI-агентів лише робить ці базові принципи ще більш важливими.

Без належного механізму ШІ не зробить команду сильнішою автоматично; навпаки, він може спричинити тиск і врешті призвести до хаосу, наприклад:

• Команди з розмитим контекстом (наприклад, ті, що керуються через інформаційну асиметрію) після підключення агента стануть ще більш розмитими (чим більша ізоляція інформації, тим більше відхилення результатів);
• Команди з нечіткими ролями: агент лише відтворить хаос, призводячи до плутанини в обов'язках та спотворення джерел рішень.
• Команди без культури перевірки: помилки агента поширюватимуться з більшою швидкістю, адже швидкість ШІ-коду вже набагато перевищує швидкість людського CR.

Тому, на думку автора, «команди, які отримають найбільше від цієї хвилі агентів, — це ті, які найбільш свідомо практикують ці базові принципи».

Для організацій, які роблять ставку на AI-агентів, справжнє завдання цієї статті, можливо, не в тому, «як використовувати Claude», а в тому, щоб повернутися і серйозно переробити ці чотири старі речі: контекст, ролі, цілі та стандарти якості своєї команди.