Что в истории TechCrunch можно утверждать, а что нет
Заголовок TechCrunch о «войне за территорию» между AI-агентами Anthropic можно использовать как отправную точку, но не как доказательство конкретного поведения Anthropic или Claude. Ссылка из доступного набора источников ведёт через Google News и не позволяет проверить условия эксперимента, состав агентов, доступные им инструменты, способ фиксации конфликтов и результат работы.
На этом основании нельзя приписывать Anthropic конкретный сценарий. Корректнее говорить о публичном внимании к проблеме пересекающихся агентных задач. Метафора «войны за территорию» не означает, что моделям следует приписывать человеческие мотивы.
Агент может добросовестно выполнять поручение, но повторно исследовать уже занятую область, подготовить альтернативную правку того же файла или вызвать инструмент, которым другой участник уже воспользовался. Локально каждый такой шаг может выглядеть разумно. Для процесса в целом результатом становятся лишнее время, расход ресурсов и риск несовместимых результатов.
Сама инженерная проблема реальна. Документация Claude Code описывает Agent Teams как экспериментальный механизм: lead координирует независимые сессии teammates, а участники используют общий список задач и сообщения. Там же отдельно обозначены сложности координации, завершения и возобновления работы.
Несколько агентов с общей целью ещё не образуют команду. Чтобы параллельная работа приносила результат, а не порождала повторы, нужны чёткие границы задач, правила доступа к общим ресурсам, единое состояние процесса и порядок разрешения конфликтов. MCP может стандартизировать подключение инструментов, но не заменяет слой оркестрации.
- Детали предполагаемого кейса Anthropic по доступной ссылке не верифицированы.
- Agent Teams в Claude Code включают lead, участников, задачи и обмен сообщениями.
- Конфликт агентов точнее понимать как конфликт задач, решений или доступа к ресурсу, а не как соперничество моделей.
Цитата в переводе«Agent Teams являются экспериментальной функцией.»
Почему параллельные сессии не получают общую память автоматически
В одиночной сессии модель опирается на текущий контекст, историю действий и выбранную гипотезу. Когда работу делят между несколькими сессиями, у каждого участника появляется собственный контекст и своя последовательность шагов. Условия, ограничения и промежуточные результаты приходится передавать явно: через задачи, сообщения и артефакты.
Здесь проходит граница между несколькими независимыми запросами и управляемой многоагентной системой. Такая система должна отвечать не только на вопрос «что сделать», но и на вопросы: кто владеет участком работы, какой результат считать актуальным, кто может менять общее состояние и кто принимает решение при расхождении.
Для ограниченных подзадач Claude Code предлагает subagents: главная сессия ставит задачу и получает результат обратно. Agent Teams рассчитаны на более самостоятельных участников, которым требуется взаимодействие друг с другом. Поэтому команды оправданы не для каждой задачи: чем выше самостоятельность агентов, тем дороже координация.
Параллельность полезна, когда потоки можно изолировать. Один участник может анализировать логи, другой проверять тесты, третий изучать зависимости, четвёртый оценивает собранные доказательства. Совместная правка одного тесно связанного участка кода, напротив, иногда требует больше согласований, чем последовательная работа в одной сессии.
- Контекст одного агента не равен общей памяти команды.
- Subagent подходит для ограниченной подзадачи с возвратом результата родительской сессии.
- Agent Teams требуют явных правил взаимодействия и владения работой.
Где возникают конфликты: работа, запись, решение, действие
Первый сбой связан с дублированием интеллектуальной работы. Два агента могут читать один модуль, искать одни и те же сведения или готовить почти одинаковые тесты. Даже полезный итог в таком случае обходится дороже из-за лишних обращений к модели и инструментам. Повторение одного маршрута также может создать ложное впечатление независимой проверки.
Второй сбой возникает при записи. Документация Claude Code предупреждает: если несколько teammates редактируют один файл, они могут перезаписать изменения друг друга. Документация рекомендует заранее разделять владение файлами или их наборами. Это относится не только к коду: такая же проблема возникает при изменении общего объекта, записи в систему учёта или обновлении конфигурации.
Третий сбой касается решений. Один агент может предложить изменение интерфейса, тогда как другой уже строит работу вокруг прежнего предположения. Если нет процедуры, которая делает принятое решение обязательным для остальных, локально обоснованные действия оказываются несовместимыми.
Четвёртый тип конфликтов связан с инструментами, меняющими внешние системы. В MCP tools описываются структурированными схемами, а спецификация авторизации подчёркивает необходимость серверной проверки полномочий. Если действие имеет последствия за пределами сессии, право читать данные и право менять их нельзя объединять только потому, что агент сформировал правдоподобный запрос.
- Duplicate work: повторный поиск, анализ, чтение кода или вызовы tools.
- Write-write conflict: параллельная запись в общий файл или объект.
- Decision conflict: разные планы нельзя совместить без арбитража.
- Action conflict: повторное или несовместимое действие во внешней системе.
Цитата в переводе«Если несколько teammates редактируют один и тот же файл, они могут перезаписать изменения друг друга.»
Паттерн №1: очередь задач, приоритет и владение
Защита от дублирования начинается до первого вызова инструмента. Общую цель следует разложить на отдельные карточки с идентификатором, границами, ожидаемым артефактом, исполнителем и условием остановки. В Agent Teams предусмотрен shared task list: задачи видны участникам и могут быть взяты в работу. Это базовый механизм, который позволяет зафиксировать, что область уже занята.
Одного назначения задачи недостаточно. Владелец должен отвечать за конкретный результат и обновлять статус. Поручение «разберись с безопасностью» почти не задаёт границ. Задача «проверить определённый каталог, вернуть вывод с доказательствами и не менять код» определяет scope, формат передачи результата и предел полномочий.
Приоритет нужен не для формальной бюрократии. Он не позволяет тратить ресурсы на второстепенные ветки, пока остаётся блокирующая проблема. Следует заранее определить, что агент обязан сделать сам, а в каких случаях остановиться и передать вопрос lead. Эскалация особенно нужна при пересечении scope или необходимости записи в общий ресурс.
Практический порядок может быть простым: прочитать карточку и реестр занятых областей, взять задачу, опубликовать план или промежуточный артефакт, затем переходить к изменению состояния. Такой порядок не устраняет ошибки, но позволяет увидеть конфликт до того, как он приведёт к перезаписи или повторному внешнему действию.
- Task ID, scope и deliverable вместо общей формулировки.
- Статусы задачи: например, claimed, blocked, in review и completed.
- Stop condition: явный критерий остановки или эскалации.
- Отдельное правило для пересечения областей и общего ресурса.
Паттерн №3: контракт инструмента должен ограничивать последствия
Структурированная схема инструмента проверяет форму запроса, но не заменяет бизнес-правила. Корректно переданное поле само по себе не отвечает на вопросы: допустимо ли действие в текущем состоянии, кто его утвердил, можно ли безопасно повторить вызов и что делать при частичном результате. Эти условия должен проверять сервис, исполняющий операцию, а не модель.
Для рискованных операций полезно разделять предложение и применение изменения. Агент может подготовить план, показать затронутые объекты и передать его на проверку. Отдельный контролируемый шаг применяет действие после проверки политики или подтверждения человека. Такой подход не исключает автоматизацию, но снижает вероятность того, что вероятностный вывод модели сразу вызовет необратимый эффект.
Авторизацию в MCP также нельзя сводить к наличию идентификатора или контекста у клиента. Спецификация описывает её как взаимодействие с защищаемым сервером, а решение о предоставлении доступа принимает серверная сторона. В многоагентной архитектуре это означает, что полномочия инструментов следует выдавать ролям и проверять при каждом чувствительном действии.
Контракт инструмента полезно описывать языком последствий: что он читает, что меняет, какие данные возвращает, какие условия должны быть выполнены, требует ли операция подтверждения и как фиксируется результат. Тогда ограничения становятся частью проверяемого интерфейса, а не надеждой на то, что все участники одинаково поймут короткое название метода.
- Разделяйте read, propose, approve и apply.
- Проверяйте полномочия на стороне сервера, а не в рассуждении модели.
- Показывайте последствия действия до его применения.
- Ограничивайте права инструментов ролью агента и scope задачи.
Цена параллельности и российский практический контекст
Многоагентная архитектура создаёт накладные расходы: отдельные сессии получают контекст, вызывают инструменты, формируют отчёты и обмениваются сообщениями. Документация Claude Code предупреждает о росте token usage и координационных расходов с увеличением числа teammates, а для большинства workflow рекомендует начинать с небольшой команды из трёх-пяти участников. Это рекомендация конкретного продукта, а не универсальная норма. Но она показывает, что количество агентов не служит метрикой результата.
Полезнее оценивать стоимость корректно завершённого процесса: число повторов, конфликтов владения, отклонённых действий, проверок и исправлений. Документация Claude Code по стоимости и использованию важна здесь не только как финансовая справка. Лимиты на использование и контроль доступных возможностей помогают удерживать автоматизацию в заданных рамках.
Российской команде не обязательно начинать с автономного «роя». Независимо от выбранного поставщика модели организация может контролировать собственные компоненты контура: хранилище задач, журнал решений, прокси к инструментам, ветки кода, CI, sandbox и аудит. Безопаснее начать с задач с ясными границами: анализа логов, review по чек-листу, поиска регрессии, исследования библиотеки или подготовки тестов в изолированной ветке.
Для работы с клиентскими данными, инфраструктурой и другими внешними последствиями большинству агентов разумнее оставить режим подготовки предложений. Право применения следует вынести в ограниченный исполнительный контур с проверками. MCP может быть полезным интерфейсом подключения tools, но его нельзя считать готовой диспетчерской, системой доступа или заменой корпоративным процедурам.
- Начинайте с небольшой команды и доказуемо независимых потоков.
- Измеряйте качество завершённой работы, а не число запущенных сессий.
- Храните задачи, решения и логи в контролируемом контуре.
- Изолируйте кодовые изменения и ставьте проверки перед применением внешних действий.
Практический чек-лист для команды Claude Agent Teams
Этот чек-лист подходит для первого запуска параллельных агентов на изолированной задаче. Его следует применять до расширения числа участников и выдачи инструментам прав на внешние изменения.
Перед запуском
Сначала зафиксируйте границы процесса и только затем распределяйте работу.
- Разбейте общую цель на карточки с Task ID, scope, deliverable и stop condition.
- Назначьте владельца каждой карточки и определите статус задачи.
- Проверьте, что параллельные потоки действительно независимы.
- Определите, какие области, файлы или объекты считаются общими ресурсами.
Во время работы
Команда должна видеть не только список задач, но и актуальные решения, артефакты и ограничения.
- Обновляйте shared state после появления значимого результата или принятого решения.
- Эскалируйте пересечение scope до записи в общий ресурс.
- Разделяйте роли исполнителя, evaluator и арбитра.
- Не рассматривайте сообщение агента как достаточное разрешение на чувствительное действие.
Перед применением изменений
Внешние действия должны проходить через проверяемый контур, который не зависит от рассуждения модели.
- Разделите операции на read, propose, approve и apply.
- Проверьте полномочия на серверной стороне инструмента.
- Покажите последствия изменения до применения.
- Сохраните результат действия и основание решения в журнале.
Вывод
Сюжет о «войне за территорию» между агентами не следует представлять как подтверждённую историю Anthropic: доступный источник не раскрывает проверяемых деталей кейса. Однако базовая проблема реальна. Документация Claude Code прямо указывает, что у Agent Teams есть отдельные вопросы координации и конфликты при совместной работе.
Для внедрения агентных систем важнее не максимальное число параллельных сессий, а ответы на несколько операционных вопросов: какие задачи независимы, где хранится общее состояние, кто владеет правом записи, как проверяется действие и кто разрешает конфликт. Эти правила превращают набор моделей и инструментов в управляемый процесс.
Стартовать стоит с небольшой команды, изолированных потоков и наблюдаемого результата. Если архитектура не умеет объяснить, кто и почему изменил общий объект, она пока не готова к автономным действиям во внешнем контуре.
Источники
Частые вопросы
Что такое Agent Teams в Claude Code?
Это экспериментальный механизм Claude Code, в котором lead координирует независимые сессии teammates. Участники могут использовать общий список задач и обмениваться сообщениями.
Чем Agent Teams отличаются от subagents?
Subagent выполняет ограниченную подзадачу, поставленную главной сессией, и возвращает ей результат. Agent Teams предназначены для более самостоятельных участников, которым требуется взаимодействие между собой.
Почему несколько Claude-агентов могут дублировать работу?
У параллельных сессий нет общей памяти автоматически. Без явных границ задач, владельцев, статусов и передачи промежуточных результатов агенты могут исследовать одну область или выполнять одинаковые вызовы инструментов.
Решает ли MCP проблему координации агентов?
Нет. MCP описывает подключение и вызов инструментов со структурированными данными, но не заменяет хранилище задач, общее состояние, policy layer, арбитраж и серверную проверку полномочий.
Как безопаснее начать работу с несколькими агентами?
Начните с небольшой команды и изолированных потоков: анализа логов, проверки тестов, исследования зависимостей или подготовки изменений в отдельной ветке. Внешние действия разделяйте на подготовку предложения, проверку, утверждение и применение.
Практический чек-лист
Чек-лист: как запустить Claude Agent Teams без хаоса
PDF-версия чек-листа предназначена для сохранения и использования перед запуском параллельных агентов.
Перед запуском
- Разбейте общую цель на карточки с Task ID, scope, deliverable и stop condition.
- Назначьте владельца каждой карточки и определите статус задачи.
- Проверьте независимость параллельных потоков.
- Определите общие ресурсы и правила работы с ними.
Во время работы
- Обновляйте shared state после значимых результатов и решений.
- Эскалируйте пересечение scope до записи в общий ресурс.
- Разделяйте роли исполнителя, evaluator и арбитра.
- Фиксируйте основания принятых решений.
Перед применением изменений
- Разделите операции на read, propose, approve и apply.
- Проверьте полномочия на серверной стороне инструмента.
- Покажите последствия изменения до применения.
- Сохраните результат действия и основание решения в журнале.
Вопросы и ответы
Что такое Agent Teams в Claude Code?
Это экспериментальный механизм Claude Code, в котором lead координирует независимые сессии teammates. Участники могут использовать общий список задач и обмениваться сообщениями.
Чем Agent Teams отличаются от subagents?
Subagent выполняет ограниченную подзадачу, поставленную главной сессией, и возвращает ей результат. Agent Teams предназначены для более самостоятельных участников, которым требуется взаимодействие между собой.
Почему несколько Claude-агентов могут дублировать работу?
У параллельных сессий нет общей памяти автоматически. Без явных границ задач, владельцев, статусов и передачи промежуточных результатов агенты могут исследовать одну область или выполнять одинаковые вызовы инструментов.
Решает ли MCP проблему координации агентов?
Нет. MCP описывает подключение и вызов инструментов со структурированными данными, но не заменяет хранилище задач, общее состояние, policy layer, арбитраж и серверную проверку полномочий.
Как безопаснее начать работу с несколькими агентами?
Начните с небольшой команды и изолированных потоков: анализа логов, проверки тестов, исследования зависимостей или подготовки изменений в отдельной ветке. Внешние действия разделяйте на подготовку предложения, проверку, утверждение и применение.
