WorkSwarm 0.2.7: команды AI-агентов упираются в контекст

30 сентября 2026 года сообщество openJiuwen выпустило WorkSwarm v0.2.7.

Это открытый фреймворк, в котором несколько AI-агентов работают одной командой. Следом вышла бета 0.2.8.

Главные изменения релиза - Proactive Context Service и сессии, общие для нескольких агентов.

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

В привычной схеме агент сам достаёт данные, когда понимает, что они нужны: ищет по базе знаний (RAG) или вызывает инструмент.

Если агент не догадался спросить, он строит ответ без нужных данных. PCS меняет порядок.

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

Детальной архитектуры PCS в release notes нет, поэтому качество отбора данных пока гипотеза: её надо проверить на своих задачах. Cross-Agent Sessions отвечают за передачу задачи от агента к агенту.

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

Самоэволюция означает, что система по итогам выполненных задач сама правит свои навыки.

Для продакшна это самый рискованный механизм.

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

WorkSwarm решает задачу оркестрации.

Три вопроса остаются на стороне компании: 1. Доступ к данным.

Проактивный контекст полезен ровно настолько, насколько полны источники.

Если остатки лежат в 1С, атрибуты товаров в PIM, а заказы в Magento, кто-то должен подключить эти системы с правильными правами. 2. Безопасность.

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

Российской компании с персональными данными клиентов по 152-ФЗ нужен контроль того, какие поля уходят во внешнюю LLM. 3. Управляемость.

Самоэволюция навыков требует версионирования, тестов и отката.

Без них ИТ-директор не может отвечать за поведение системы.

В KT.Team мы строим агентные системы так же, как интеграции последних лет: сначала шина данных и правила доступа, потом умные компоненты. Доступ к системам мы даём агентам через MCP - стандартный протокол, по которому модель вызывает инструменты с типизированными параметрами. Агент получает операцию «найти контрагента» в 1

С или «получить атрибуты SKU»

в Akeneo и Pimcore, прямого доступа к базе у него нет.

Если в компании уже работают Apache Kafka, Datareon или MuleSoft, мы превращаем события из шины в тот самый проактивный контекст: агент получает изменение заказа сразу, без опроса. Безопасность держит LLM & Security Gateway.

Шлюз маскирует персональные данные до отправки в модель, ведёт журнал запросов, ставит лимиты бюджета и распределяет задачи между GigaChat, YandexGPT, Qwen и Claude по требованиям к данным и цене. Общий контекст хорошо виден на PIM-проектах.

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

WorkSwarm 0.2.7 стоит поставить в песочницу и проверить, как PCS отбирает контекст на ваших задачах. В продакшн я бы его пока не брал: версия молодая, а самоэволюция навыков без тестов рано или поздно выстрелит в отчёте для собственника. Правило для руководителя простое.

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

Если эту страницу никто в компании не может заполнить, фреймворк результата не даст.

Если может, фреймворк становится заменяемой деталью, и первый измеримый результат появляется за недели, а не за кварталы.