Интерпретация новой работы Anthropic: Как построить эффективную команду сотрудничества человека и ИИ

6 июня компания Anthropic опубликовала в официальном блоге новую статью Building effective human-agent teams, автором которой является Кристен Суонсон.

Основная идея статьи заключается в обсуждении смены парадигмы командного взаимодействия с ИИ — от «одного человека к одному окну чата (даже если за ним стоит множество агентов)» к «группе людей и группе агентов, работающих в одном общем рабочем пространстве».

В данной статье я, пересказывая основные идеи оригинала, объединю их с практическим опытом внедрения ИИ-агентов и дам систематизированный анализ.

I. Основная идея: ИИ-команды становятся «многопользовательским режимом»

Раньше использование ИИ было «однопользовательским (single-player)» опытом — один человек и агент сотрудничали для выполнения личных задач.

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

Работа начинает походить на «многопользовательскую игру (multiplayer game)»: человеческая команда разрабатывает стратегию, а Claude её выполняет.

В общем, это общие цели, общий контекст и, особенно, общее рабочее пространство.

Как показано на рисунке, происходит переход к более сложной модели работы справа:

Эту трансформацию обеспечивает новый продукт Anthropic — Claude Tag, форма, позволяющая Claude «поселиться» в командных инструментах, таких как Slack, и быть упомянутым через @ и получать задания, как член команды.

Так что эта статья — не чистая теория, а направление, в котором движется сам продукт Anthropic.

II. Что такое проблема «многопользовательских агентов»?

В оригинале «многопользовательские агенты (multiplayer agents)» определяются как: ИИ-модели, которые одновременно сотрудничают со многими разными людьми.

У них есть сходства и ключевые отличия от привычных нам обычных агентов:

• Сходство: у них есть собственная память и навыки (skills).

• Отличие: у них есть собственные учётные данные (credentials),

а также они «живут там, где происходит работа (living where work happens)» — то есть в месте, где реально выполняется работа.

В Anthropic таким местом являются командные инструменты, такие как Slack.

Этот параметр — «иметь собственные учётные данные, жить в командном канале» — очень важен.

Он означает, что агент больше не использует чью-то учётную запись, не работает в чьём-то приватном чате, а является независимым командным субъектом с собственной идентичностью: его видят все члены команды, его результаты видны всем, контекст, который он читает, — это контекст уровня команды, а не личный. Как показано на рисунке ниже, он становится частью вашего офисного ПО.

Чтобы агент мог «эффективно участвовать» в командном канале, требуется набор базовых возможностей (например, продукт Claude Tag) + специально разработанные механизмы постоянной памяти, уникальной идентичности, источников информации и т.д.

Кроме того, одних технических возможностей недостаточно: для успеха человеко-машинной команды необходимы рабочие методы и общие нормы.

Поэтому последующие четыре практических совета в статье посвящены описанию того, как разрабатывать «нормы» для ИИ-команд.

III. Четыре практических совета для ИИ-команд

Совет 1: Реформируйте управление информацией, предоставьте агенту максимально широкий контекст

Anthropic считает, что не нужно решать, какие документы или каналы делать доступными агенту по одному, а следует использовать чётко определённые границы безопасности (security boundaries), которые применяются ко всему рабочему пространству Slack, транскрипциям встреч, библиотекам документов.

В оригинале специально упоминается ежедневная мука: «Этот канал сделать публичным или приватным? Можно ли поделиться этим документом с тем человеком? Может ли этот агент видеть это сообщение?»

Внутри границ контекст должен быть виден каждому члену команды — будь то человек или ИИ, и даже ИИ может, как человек, запрашивать доступ к документам.

Хитрость этого подхода в том, что он одновременно решает две проблемы:

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

Отдача от открытия доступа ощутима: больше нет потерь при передаче информации, и, поскольку агенты читают текст быстрее людей, они могут «routinely surface relevant work that humans would otherwise have missed» (регулярно выявлять релевантную работу, которую люди иначе бы упустили).

По мнению автора, это по сути смена организационной культуры и механизма прав доступа.

«По умолчанию всё открыто внутри компании» для многих компаний — это серьёзное культурное изменение, требующее перестройки.

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

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

Поэтому реально применимая идея — это упрощённый механизм одобрения: например, если агент находится в определённой группе, он автоматически может читать документы, к которым у этой группы есть доступ. Даже если есть контроль доступа, им можно управлять оптом, а не сначала выдавать документы, а потом проверять качество.

Совет 2: У каждого человека/агента должна быть чёткая роль и инструменты

В оригинале яркая картина: человеко-машинная команда делит общий список участников, общий набор продуктов, одно рабочее пространство.

Поверх этого агенты разделяют функции:

• один агент отвечает за анализ данных по проекту;
• другой владеет и применяет дизайн-стандарты;
• третий отвечает за синтез исследований (research synthesis).

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

Затем создаётся комбинация ролей, правил и моментов вмешательства, как на рисунке ниже.

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

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

Человек сохраняет за собой только те роли, которые может выполнять только человек, чтобы человеческое суждение использовалось в самых важных решениях.

По мнению автора: это также архитектура, основанная на ранее изученных механизмах рабочих процессов Anthropic.

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

Особенно в широко ориентированных, параллелизуемых задачах, и благодаря более сильным механизмам перекрёстной верификации точность информации выше.

Кроме того, требуется тщательное проектирование декомпозиции задач и изоляции ролей, а не просто «накидать ещё агентов».

Иначе это снова будет недопонимание, как «урожай 18 000 цзюней с му».

Многие из этих идей также освещены в предыдущей статье о том, как использовать Dynamic Workflows от Claude для глубоких исследований.

Совет 3: Установите «полярную звезду» (роль), чтобы агент активно решал проблемы

В оригинале различают два типа агентов: одни просто «выполняют порученные задачи», а самые важные из них активно предлагают новые проекты и рабочие процессы.

Последние обычно появляются в команде, уже имеющей богатый контекст и чёткие роли, с добавлением дополнительного ориентира — полярной звезды (north star).

Полярная звезда отвечает за помощь команде в определении «какие задачи и рабочие процессы правильные».

В оригинале подчёркивается несколько правил:

• Полярная звезда всегда устанавливается человеком и укоренена в миссии компании и бизнес-целях;
• После того как полярная звезда чётко записана, человек делится ею с агентами в команде;
• Затем — и это ключевой шаг — человек выбирает, какие агенты должны активно предлагать новые рабочие процессы.

Предположим, что продукт и компания ориентированы на операции: тогда ведущим агентом должен быть операционный, а не продуктовый, технологический или финансовый.

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

По мнению автора, в предыдущих статьях Anthropic уже прослеживалось различие между тем, что они считают агентом и рабочим процессом (workflow).

Первый — «динамически управляет своим собственным процессом и инструментами, контролирует выполнение задачи».

Второй — это детерминированная система, «оркестрируемая через предопределённые пути кода».

Поэтому, чтобы создать ИИ-команду, нужно дать агенту полярную звезду, а не список задач — это осознанное смещение системы от рабочих процессов к агентам.

Команда с целью будет проявлять некоторую креативность, а не заниматься поиском занятий в ограниченных рамках.

Конечно, многие из текущих ИИ-команд, которые мы создаём, на самом деле являются программными или ИИ-рабочими процессами, и они уже решают многие проблемы. Если в будущем нам потребуется креативность, самоуправление, способность активно решать проблемы, тогда нужно проектировать такие агентские команды.

Совет 4: Позвольте агенту расти со временем

Здесь у меня были удивлены официальные данные: они говорят, что инженеры Anthropic уже смогли заставить агента в команде самостоятельно обрабатывать 500 исправлений ошибок (bug fixes) — но сразу же подчёркивают: «things certainly didn't start off that way (с самого начала было не так)».

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

Пользователь должен многократно проверять агента на различных задачах, чтобы понять границы его возможностей, как чётко формулировать цели, какие файлы навыков ему нужны, какой промпт лучше всего вызывает желаемое поведение.

В оригинале также специально предупреждают об одной зачастую упускаемой детали: модели обновляются, задачи нужно перетестировать — промпты, возможно, придётся переписывать, а старые полезные ограждения (Harness) могут сковывать более умную модель в поиске более креативных решений.

Самое ценное в этой практике — это обсуждение верификации (verification):

Мы обнаружили, что лучшие долгосрочные агенты, прежде чем их отдадут на проверку человеку, используют множество способов верификации своей работы.

• У кода есть тесты, это очевидно;
• Но большинство других видов работы тоже можно проверить: техническую документацию можно оценить с помощью рубрик (rubric) и руководств по стилю (style guide);
• Когда человек задаёт стандарты и гарантирует, что вся работа, передаваемая агенту, может быть проверена, качество сохраняется и не отклоняется от цели;
• Кроме того, можно поручить одному агенту выполнять работу, а другому — проверять — это известная схема «Doer-Verifier» (исполнитель—верификатор) в агентских средах.

В оригинале есть полный пример: один инженер-руководитель принял новую команду с большой накопленной работой (backlog). Он привлёк несколько человек и несколько агентов для совместного определения приоритетов.

Одна группа агентов просматривает все накопленные задачи, определяет, кто над ними работает, оценивает сложность задач без владельца;

Другая группа отбирает из списка задачи средней и низкой сложности и напрямую генерирует изменения в коде.

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

Еженедельно команда также поручала агенту составлять отчёт, включающий «уроки и ошибки (lessons & missteps)», чтобы агент запоминал ошибки и избегал их повторения. Со временем руководитель мог поручать агенту всё более сложные изменения, а сам тратил всё меньше времени на повседневное руководство, как показано на рисунке ниже:

Очень похоже на процесс выращивания умных омаров.

Последний абзац — это самое глубокое понимание во всей статье, которое мне больше всего понравилось: когда агенты становятся более независимыми, руководитель начинает обучать агента относиться к «человеческому вниманию» как к ценному ресурсу:

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

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

Другие устанавливают для агента ограничение «максимальное количество работы в день», чтобы человек мог осмысленно участвовать и сохранять свои важные навыки от атрофии.

По мнению автора, эти практики являются самым глубоким аспектом статьи в области «человеко-машинных отношений».

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

IV. Эра человеко-машинного сотрудничества безжалостно выявит организационное качество исходной команды

Самая честная и часто упускаемая фраза в статье появляется в конце:

Вышеупомянутые четыре практических совета на самом деле не новы — они существовали задолго до появления ИИ. У хорошей команды должны быть сильная полярная звезда, чёткие роли, надёжная документация, общие стандарты качества, пространство для обучения на ошибках — это всё давно известные нам здоровые командные привычки.

И ИИ-агентные команды лишь делают эти основы ещё более важными.

Если нет разумного построения механизмов, ИИ не сделает команду сильнее автоматически; наоборот, он может создать давление и в конечном итоге внести хаос, например:

• Команды с размытым контекстом (например, те, кто управляет с помощью информационного неравенства) после подключения агентов станут ещё более размытыми (чем больше информационная изоляция, тем сильнее отклонение результатов);
• Команды с путаницей в ролях: агенты только воспроизведут хаос, взаимные рабочие обязанности станут неупорядоченными, источники решений исказятся.
• Команды без культуры верификации: ошибки агентов будут масштабироваться с ускоренной скоростью; скорость генерации кода ИИ уже намного превышает скорость человеческого ревью.

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

Для организаций, делающих ставку на ИИ-агентов, настоящим уроком из этой статьи, возможно, является не «как использовать Claude», а вернуться и серьёзно пересмотреть четыре старые вещи в своей команде: контекст, роли, цели и стандарты качества.