Из интересного - поймали запуск спутников от Бюро 1440 вживую

Новость: https://habr.com/ru/news/1014064/

Хотя пытались поймать сияние...

Пользуясь случаем, хочу разместить первую нативную рекламу на этом канале (мне за нее не заплатили😢), все от чистого сердца

В общем, очень рекомендую гида Лена-Пена для путешествий: @lenapenatrip

Тур с ней - это просто 100/10

Она абсолютно отбитый на голову скалолаз, рок-джампер, сноубордист и походник. С ней вы и в метель заблудитесь, и полярное сияние с проектора посмотрите (если нормального не будет), и вина бахните, и мемы с котиками пораскрашиваете

А еще она угостит вас дошиком, отведет в общественную баню, выдаст дырявый костюм для айсфлоатинга (если вы ей не понравитесь) и попробует потерять в горах в метель (за ваши тупые шутки)

На все замечания по туру она просто трясет жопой и кричит "А че вы мне сделаете?" (заснять для отзыва каждый раз не успевал)

А еще у нее шикарный формат туров - пт, сб, вск. Можно даже не ждать отпуска, а взять 1 выходной и рвануть на "шашлыки и маяки" в Ленобласти или на каяках в Карелию. Собственно, в такую тему мы уже вписались в июле - https://lenapenatrip.ru/kayakkarelia

И она водит индивидуальные туры на Дальний Восток, Байкал и Кольский полуостров (везде, где есть снег). Так что можно попробовать организовать группу и задушить ее разговорами про IT, если кто-то еще любит ебеня, палатки и медведей

Я БОЛЬШЕ НЕ ПИШУ КОД РУКАМИ

Штош, прошел ровно месяц как я стал гордым пользователем Claude Code Max Pro Ultra Titan Power (тот, который 200$). Хочется поделиться своими впечатлениями

Ремарка: я уже полгода пользовался платным Cursor, так что я "опытный" вайбкодер

Когда я читал новости, что
- "в Anthropic уже никто не пишет руками"
- "создатель Claude Code за последние полгода не написал ни строчки руками"
- "все бигтехи запретили писать руками"
Я относился к таким новостям скептично.

Но теперь я в это верю. Я сам уже близок к тому, чтобы закрыть IDE и писать только промпты. Но тут есть важное уточнение

Я НЕ СТАЛ ЭФФЕКТИВНЕЕ.
Скорость, с которой я шиплю фичи +- та же. Ну, мб чуть быстрее (в пределах 5-10%)

Мне просто стало впадлу делать что-то руками😂 Тут сложилось сразу несколько факторов:
1) Я устал писать код. Это не то, за что я люблю разработку. Пусть пишут другие
2) Claude в худшем случае выполнит задачу с моей скоростью. Если повезет - мгновенно
3) Пока Claude работает, я могу заняться чем-то другим. Поставить параллельную задачу, почитать доку, ответить в чатике, полистать тикток в конце концов
4) Claude активно сопротивляется твоим попыткам что-то изменить (в отличии от Cursor). Если ты правишь что-то руками параллельно с ним, он ругается "там линтер чето поправил, я откатил". И ты больше нервов тратишь, чем если поставишь ему задачу в очередь

Вот так и получается, что Claude за счет
- эффекта новизны - а это и правда совершенно новый экспириенс в разработке
- эффекта казино - вдруг задача решится с первого промпта. Или со второго. Или с третьего. НУ ТЕПЕРЬ ТОЧНО ПОВЕЗЕТ. И ты продолжаешь депать токены😎
- низменных инстинктах человека - листать тикток, пока код пишется🌚
Вызывает привыкание и у тебя все меньше и меньше появляется желание писать код вручную.

Я пока держусь только за счет своего перфекционизма - всегда правлю результат генерации, чтобы результат меня удовлетворял. Но не знаю, сколько я протяну😢 И не знаю, куда это все приведет индустрию...

Но в сухом осадке - я получил совершенно новый опыт казино-разработки (веселее обычной, но вызывает привыкание), стал чуть-чуть эффективнее (наверное), ну и мини проекты бутстрапятся быстро, это не отнять

С Cursor такой херни не было

#AI #claude #cursor

Антропик опубликовали анонс, что Mythos, их следующая натренированная модель, оказалась нечеловечески крутым хакером. И что мы, конечно, попробуем избежать коллапса и объединить усилия разработчиков всего важного мирового софтвера и секьюрити нравящихся нам стран, но хз, что из этого получится.

(ВЫ НАХОДИТЕСЬ ЗДЕСЬ)

Если кто-то юзает MQTT - то в FastStream появилась его поддержка. Пока release candidate

https://github.com/ag2ai/faststream/releases/tag/0.7.0rc0

Ждем ваш фидбек, чтобы выкатить стабильную 0.7.0 версию🙂

Блин, я совсем пропустил, что у нас на канале AG2 вышло превью поддержки A2UI протокола от Google

https://www.youtube.com/watch?v=ps-gn4j3_g8

Это прикольная фича, т.к. она позволяет реализовать Generative UI другим способом, нежели AG-UI

Если в случае AG-UI у вас есть client-side инструменты, которые агент может дергать, чтобы срендерить какие-то компоненты на фронте, то A2UI - это специальный формат ответа агента (используя structured output фичу), которую мы скидываем на фронт и там рендерер превращает ее в компонентики

Т.е. в случае A2UI агенту достаточно объяснить синтаксис разметки, а он будет скидывать компоненты на фронт в свободном виде. В отличии от Tool-based GenUI, где у вас фиксированная разметка и агент просто выбирает, какие именно компоненты дернуть, в случае A2UI у агента полная свобода творчества)

Кстати, есть прикольный похожий проект - https://github.com/thesysdev/openui (смысл тот же, но токенов меньше)

А вот полная статья из блога с примерами A2UI кода - https://docs.ag2.ai/latest/docs/blog/2026/03/20/AG2-A2UI/#transport-options

(А еще это хорошо сочетается с UCP)

В эту пятницу я гонял в Нижний Новгород чтобы рассказать про разработку AI-агентов (на примере устройства OpenClaw) на митапе у Никиты Соболева: @opensource_findings
Было круто! Ребята тусили до 5 утра, мб в следующий визит я осилю тусу целиком😂

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

Если вы считаете, что разработка AI-агентов - это магия и rocket science, то в ближайшее время я постараюсь вас переубедить. Ведь написать своего агента не сложнее, чем CRUD😂

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

В общем, планируется 9-10 постов про контекст, инструменты, память, скилы и все прочие хайповые слова. Посты будут выходить каждый день ближайшее время. Так что вам лучше заранее замутить канал / отписаться😂 Всем остальным придется читать

А пока просто прилагаю презентацию с доклада

#доклад

Как работает агент

Начнем с очень базового вопроса - "что такое AI-АГЕНТ?"

Проблема в том, что никто точно не знает. Или просто я спрашивал не тех людей. Общепринятого формального определения нет. Но все, кто занимается разработкой агентов, +- интуитивно понимают, что это такое.

Самое последнее хайповое определение

Agent = LLM + Harness

Оно несет в себе не очень много смысла, т.к. в слово Harness просто засунули все те невырозимые 10000 приседаний, которые нужно сделать вокруг LLM, чтобы превратить ее в агента.

В Harness могут входить
- ваш механизм управления контекстом
- тулы, которые вы прикрутили к нему
- память
- скилы
- мультиагентная логика
- интеграции с внешними системами
- и тд и тп

Т.е. Harness - это весь тот код, что вы пишете, чтобы превратить LLM в что-то, что закрывает реальные задачи.

А что такое LLM в этой парадигме? Очень просто: LLM - это мозг, который принимает решения HTTP ручка. И делает она ровно одну вещь: принимает JSON и отдает JSON

User -- {
    "role": "user",
    "content": "Привет!"
} --> LLM

User <-- {
    "role": "assistant",
    "content": "Господи, ну что опять!?"
} -- LLM

Все остальное - это Harness

#Agents

Контекст агента

Context - это полная история вашего взаимодействия с моделью. Т.к. API LLM - это stateless сервис, то вам нужно передавать весь контекст на каждый запрос.

Поэтому диалог в ChatGPT изнутри выглядит как-то так

User -- {
    "role": "user",
    "content": "Привет!"
} --> LLM

User <-- {
    "role": "assistant",
    "content": "Господи, ну что опять!?"
} -- LLM

User -- [
    // history
    {"role": "user", "content": "Привет!" },
    {"role": "assistant", "content": "Господи, ну что опять!?"},

    // new message
    {"role": "user", "content": "Да так, заскучал" }
] --> LLM

Все, что вы запихнули в запрос к модели и есть контекст. Контекстное окно - это то, насколько большую JSONнину модель в принципе способна переварить.

И вот тут мы сталкиваемся с основной проблемой контекста - он растет.

                    500t
                  | user   |
           300t   | agent  |
         | user   | user   |
  100t   | agent  | agent  |
| user   | user   | user   |
| system | system | system |

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

Хорошо, что контекст кешируется. Т.е. на самом деле вы отправляете что-то такое

                    50t
                  | user   |
           50t    |        |
         | user   |        |
  100t   |        |        |
| user   | 250ct  | 450ct  |
| system | cached | cached |

Кешированные токены могут или просто стоить дешевле, или вообще быть бесплатными (в подписке Claude Max). Но даже так они активнее сжигают ваши лимиты, так что общее правило - если закончили с текущей задачей, новую начинайте в другом чате. И модель умнее будет, и токены сильно сэкономите

Context Compaction - это самый базовый функционал, который необходим агенту. Если контекст слишком разросся, надо его как-то сжимать. А т.к. это просто JSON, то сжимать его можно каким угодно образом - учитывать только последние N сообщений, выкидывать определенные или случайные. Или сжимать весь текущий диалог в одно <summary></summary> сообщение с помощью той же LLM - и поехали дальше. Последний вариант самый простой и популярный.

Да, к слову: здесь вы уже способны написать ChatGPT (веб-приложение, не модель)

#Agents

Инструменты

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

С точки зрения модели, Tool - это просто JSON (снова), котороый мы подложили в контекст

Выглядит он следующим образом:

{
   "name": "get_weekday",
   "description": "Call this tool each time you want to know current weekday",
   "arguments": JSONSchema
}

• Название инструмента - это уникальный айдишник, по которому модель будет его вызывать.
• Описание - наша попытка объяснить модели, для чего этот инструмент нужен и когда его стоит дергать
• Аргументы - это JSONSchema с описанием того, как вообще вызывать этот инструмент. Мы просто надеемся, что модель сможет отдать нужный JSON

Теперь, если мы спросим модель о текущем дне недели, последовательность запросов будет выглядеть примерно следующим образом:

User -- {
    "role": "user",
    "content": "Привет, чем займемся сегодня?"
} --> LLM

LLM -- {
    "role": "assistant",
    "tool_calls": [{
        "call_id": "...",
        "name": "get_weekday",
        "arguments": "{}"  // JSON string
    }]
} --> Agentic Framework

LLM <-- {
    "role": "tool",
    "content": "Friday"
} -- Agentic Framework

User <-- {
    "role": "assistant",
    "content": "Friday! It's the time to drink beer!"
} -- LLM

И контекст выполнения будет выглядеть следующим образом:

| assistant         |
|  tool result      |
|  tool call        |
| user              |
| tools definitions |
| system            |

С точки зрения кода, инструмент - это просто функция

from autogen.beta import Agent, config

agent = Agent("my-lovely-agent", config=config.OpenAIConfig("gpt-5"))

@agent.tool
def get_weekday() -> str:
    return "Friday"  # всегда пятница, всегда пьем пиво

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

Основная проблема инструментов в том, что их может быть МНОГО. Если ваш контекст на 95% состоит из описания инструментов и пользовательский запрос просто теряется на их фоне - не удивляйтесь, если модель творит дичь. О способах борьбы с этим мы поговорим чуть позже. Пока - просто старайтесь не включать инструменты, которые вам не нужны

К слову об MCP (я уже писал пост про них) - это те же инструменты, только раздаются по HTTP / сокету. С точки зрения модели и контекста - это то же самое

Собственно, на этом все. Контекст + Инструменты - это два кита, на которых плывут агенты. Все остальное реализовано поверх них.

#Agents #MCP

Память

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

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

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

Что-то вроде этого

class Memory:
    def write_conversation_memory(summary: str) -> None: ...

    def list_conversations() -> list[tuple[UUID, datetime]]: ...

    def read_conversation(conversation_id: UUID) -> str: ...

В самом простом случае, память - это просто директория на файловой системе. Например, вот такая (OpenClaw):

memory/
├── PERSONALITY.md // личность агента
├── USER.md        // профиль юзера
├── 04_16_2026/    // история диалогов
│   ├── Write_Blogpost.md
│   └── Make_Presentation.md
└── 04_17_2026/
    └── Find_NN_Restaurants.md

Имея такую директорию и парочку инструментов для работы с ней, OpenClaw уже умеет:
- самодописывать свой системный промпт (PERSONALITY.md)
- обновлять информацию о своем хозяине (USER.md)
- писать историю диалогов, искать по ним и доставать оттуда факты

К слову, RAG - это точно такой же набор инструментов с точно такими же возможностями. Отличается только реализация тулов: вместо файловой системы внутри - векторная база данных.

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

#Agents

Господа, мы приплыли. 500ые на проде уже с нами

Сабагенты

Теперь представим такую ситуацию: вы спросили агента "мы на прошлой неделе бронировали ресторан, напомни время". А агент умеет смотреть историю чатов только по дням. И в итоге получается что-то вроде этого:

User -- "Мы на прошлой неделе выбирали, куда пойти в НН. Что мы там решили?" --> LLM

LLM -- {
    "name": "list_memories",
    "arguments": '{"date":"04_15_2025"}'
} --> Agentic Framework

LLM <-- [] -- Agentic Framework

LLM -- {
    "name": "list_memories",
    "arguments": '{"date":"04_16_2025"}'
} --> Agentic Framework

LLM <-- [
    "Write_Blogpost", "Make_Presentation"
] -- Agentic Framework

LLM -- {
    "name": "list_memories",
    "arguments": '{"date":"04_17_2025"}'
} --> Agentic Framework

LLM <-- [
    "Find_NN_Restaurants"
] -- Agentic Framework

LLM -- {
    "name": "read_file",
    "arguments": '{"path":"04_17_2025/Find_NN_Restaurants.md"}'
} --> Agentic Framework

User <-- "Да, это было 17го! Ты решил сходить в Ель и мы забронировали столик на 21:00" -- LLM

Контекст в данном случае выглядит следующим образом

| assistant         |
|  tool result      |
|  tool call        |
|  tool result      |
|  tool call        |
|  tool result      |
|  tool call        |
| user              |
| tools definitions |
| system            |

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

Т.е. наш вопрос породил *"подзадачу"* (subtask), выполнять которую желательно в изолированном контексте. Кодинг-агенты часто сталкиваются с такими подзадачами: планирование, запуск тестов, линтеров, ревью - это все мелкие технические шаги, детали которых не так важны в контексте глобальной задачи "ЗАПИЛИ ФИЧУ".

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

from autogen.beta import Agent, config, tools

memory_agent = Agent(
    "memory-agent",
    config=config.OpenAIConfig("gpt-5"),
    tools=[
        tools.FilesystemToolkit("./memory"),
    ]
)

def call_subagent(prompt: str) -> str:
    return await memory_agent.ask(prompt)

agent = Agent(
    "ag-claw",
    config=config.OpenAIConfig("gpt-5"),
    tools=[
        call_subagent,
        # memory_agent.as_tool() - или так
    ]
)

Теперь вместо одного зашумленного контекста у нас появилось 2 изолированных

| assistant         |                   |
|  subagent result  | assistant         |
|                   |   tool result     |
|                   |   tool call       |
|                   |   tool result     |
|                   |   tool call       |
|                   |   tool result     |
|                   |   tool call       |
|  subagent call    | user              |
| user              |                   |
| subagent tools    | memory tools      |
| claw prompt       | subagent prompt   |

Сабагенты - это самый распространенный паттерн мультиагентного взаимодействия сейчас. Потому что самый простой и при этом достаточно эффективный. Про хореографические паттерны поговорим в другой раз. Но концепция всегда одна и та же - если задачу можно разбить на шаги / подзадачи, которые для своего решения не требуют понимания всего контекста - лучше выделить нескольких агентов. Также сабагенты частично решают проблему overtooling (когда у одного агента слишком много инструментов и он сходит с ума).

Тут важно понимать, что

Subagent - это не сервис и не модуль. Это просто подконтекст. У него свой системный промпт, своя история. Но модель чаще всего та же.

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

#Agents

Background, Dynamic Subagents

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

Что-то вроде такого:

| assistant         |                   |
| user              |                   |
| // кладем результат в контекст        |
| subagent result   | assistant         |
|                   |   tool result     |
|  assistant        |   tool call       |
|  user             |   tool result     |
|                   |   tool call       |
|                   |   tool result     |
|  // отпускаем основной контекст       |
|  subagent called  |   tool call       |
|  // делегируем задачу                 |
|  subagent call    | user              |
| user              |                   |
| subagent tools    | memory tools      |
| claw prompt       | subagent prompt   |

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

Стоит упомянуть, что тут существует 2 паттерна:
1. сабагент сам приносит результат по готовности
2. сабагент отдает TaskId, а основной агент спрашивает о готовности по этому ID

Какой вариант использовать - зависит от задачи. Поиграйтесь

Ну и последнее, о чем хочется сказать - динамические сабагенты. Это когда модель сама понимает, что вот эту задачу нужно делегировать кому-то, сама генерирует этого "кого-то" и отправляет делать задачу.

Как вы понимаете, это тоже инструмент. В AG2 у нас для этого есть специальный формат спеки, которую мы умеем превращать в агента. Т.е. инструмент имеет 2 аргумента:
- JSON с описанием желаемого агента
- Промпт, с которым его запустить

Таким образом, основной агент превращается в волшебника, который умеет самостоятельно спавнить произвольных сабагентов. Rocket science, не иначе

#Agents

Skills

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

Яркие примеры:
• rtk
• caveman
• React best practices

Со скилами вы могли сталкиваться, если активно используете кодинг-агентов (Codex / Claude Code / Cursor / OpenCode / etc). В базе своей формула очень проста:

Skill = Context + Scripts

С точки зрения реализации, skill - это директория на системе

.agents/skills/
└── Pytest_Skill/
    ├── SKILL.md
    └── scripts/
        ├── run_pytest.sh
        └── list_tests.py

- Pytest_Skill - название скила
- SKILL.md - текстовая простыня, которую мы загрузим в контекст, когда агент захочет научиться работать с pytest
- scripts/ - директория со скриптами (python / shell), правила использования которых описаны в SKILL.md

Логично, что агент сам по себе не понимает, что такое скилы. Для этого ему нужна парочка инструментов:

class SkillsToolkit:
    def load_skill(skill_id: str) -> str: ...

    def run_skill_script(skill_id: str, script: str) -> str: ...

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

[{
    "name": "Pytest_Skill",
    "description": "Use this skill to test your python code",
    ... //  всякие бесполезные поля
}]

| assistant         |
|  script result    |
|  run script       | // исполнение скрипта из набора скила
|  skill content    |
|  load skill       | // загрузка конкретного скила в контекст
| user              |
| tools definitions |
| skills metadata   | // информация о доступных скилах
| system            |

Итого, скилы - это всего лишь:
- метаинформация в контексте
- пара инструментов
- директория на системе

Зато в совокупности это позволяет нам загружать в контекст огромные инструкции для очень специфичных задач по востребованию (а не держать их в контексте всегда).

Проблема тут в том, что после выполнения задачи нам такая большая инструкция в контексте не особо нужна. Да и слишком много скилов тоже регистрировать не стоит (их описание тоже забивает контекст). Но все эти проблемы отлично решаются сабагентами.

Последняя Rocket Science штука здесь - это загрузка нужных инструментов "на лету" из интернета. Что ж, это всего лишь вопрос пары дополнительных инструментов, которые ищут скилы на стоках по API:

class SkillSearchToolkit:
    async def search_skills(query: str, limit: int = 10) -> str: ...

    async def install_skill(skill_id: str) -> str: ...

Мы просто динамически ищем скилы на https://skills.sh по API, качаем их с гита и ставим в локальную папку. Для этого у нас тоже есть готовый инструмент autogen.beta.tools.SkillSearchToolkit

Очень темное колдунство, не иначе.

#Agents

AI не заменит разрабов, можно расслабить булки

https://vz.ru/news/2026/4/26/1413853.html - нашел оч смешную новость. Компании жалуются, что расходы на токены и так уже достигли размеров ФОТ сотрудников. Кожаные мешки оказались дешевле цифровых. А Uber вообще уже потратил все бабки на AI до конца года

Я это не фактчекал, но на правду похоже. Сам пару раз видел чеки на 500$+ в день на вайбкодинг

Интеграции Агента с мессенджером

Основная (и единственная) проблема при интеграции агента с любым UI - это то, как менеджить разные контексты.

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

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

Но эти задачи не какие-то особенные для агентной разработки. Любой веб-разработчик делал что-то такое и, я уверен, вы тоже справитесь.

В помощь могу предложить разве что вот такой код:

from autogen.beta import Agent, config, MemoryStream

agent = Agent("tg-agent", config=config.OpenAIConfig("gpt-5"))

dp = Dispatcher()
chat_state: dict[int, MemoryStream] = {}

@dp.message(F.text)
async def on_text(message: Message) -> None:
    # получаем старый контекст или создаем новый
    if not (stream := chat_state.get(message.chat.id)):
        stream = chat_state[message.chat.id] = MemoryStream()

    # дергаем агента с этим контекстом
    reply = await agent.ask(
        message.text,
        stream=stream,
        variables={"user_id": message.chat.id},
    )

    # отвечаем в TG чат
    await message.answer(reply.content)

asyncio.run(dp.start_polling(bot))

Чуть более развернутый пример я уже описывал в блоге AG2 - там пример с историей диалогов и переключением между ними

Но, я уверен, вы без труда справитесь с такой интеграцией. Если же вы хотите написать Web приложение, то советую посмотреть на фичи AG-UI протокола - там уже есть готовые фреймворки и на фронтенде. Про AG-UI я писал даже статью на Habr, но если все еще ничего не понятно, могу попробовать объяснить еще раз😅

#Agents