Разделение прав идет через ролевую модель (маркетинг, sales и др.). И в зависимости от прав роли агент в Битрикс может как читать, так и писать. Инженер занят, так что насчет вебвизорного пайплайна я спросил напрямую у бота. Вот его ответ
В тексте упоминал, что опус мы использовали для изначальной разработки. Сейчас используем GLM 5 / Gemini 3 Flash, Gemini 3.1 Pro для сложных задач. Подключить можно любые LLM, хоть qwen, хоть kimi, хоть Алису.
Справедливое замечание, если есть свободный программист, который напишет скрипт за 2-4 часа, поддержит его при изменениях API/верстки и будет на связи для багфиксов. Тогда Python + cron действительно дешевле. Но openclaw решает другие задачи:
- Маркетологам не нужно зависеть от разработчика, они пишут задачу в Telegram и получают результат сразу. Время специалиста = деньги.
- Если сайт изменил верстку, скрипт упадет и будет ждать фикса. Агент увидит ошибку, сам адаптируется и попробует другой подход в рамках той же сессии.
- Сложные цепочки вроде «Найди статьи, собери метрики и тренды, сравни с нашими публикациями и сделай дайджест» — для Python это написание оркестратора, а для агента — одна фраза.
- Контекст не нужно кодировать: наш Клавдий знает структуру компании, предыдущие взаимодействия, типичные задачи пользователя, роли и права доступа.
Подытожу. Да, можно обойтись без openclaw. Но с ним есть гибкость, не нужно ничего допиливать (ну почти), и даже если что-то поменяется, он самостоятельно адаптируется. Это не «открытие формул в Excel», а делегирование рутины ИИ-агенту, чтобы разгрузить команду и дать не-технарям инструмент автономности. Мы используем Клавдия для того, чтобы трансформировать компанию и научить сотрудников решать простейшие задачи без программистов, которые занимаются продуктом, а не парсерами.
Причина довольно банальна: не доходили руки. Выход завирусившегося инструмента просто оказался удобным поводом начать. Часто даже просто сформулировать потребность в автоматизации бывает непросто.
Отличие то же, что и любого другого head of от джуна: понимание бизнеса клиента, самостоятельное формирование тех. требований, а не просто написание кода по ТЗ. Стратегическое мышление, понимание бизнес-логики и умение ее проектировать, а не только писать промпты. Совершенно иной набор навыков.
Отчасти вы правы по поводу сайта — он как раз в процессе обновления. Делался очень давно, на тот момент был вполне хорош и целей своих достигал. Впрочем, разработкой сайтов мы не занимаемся, и WordPress клиентам не предлагаем — не наш уровень, делаем только сложные веб-системы. WordPress — это выбор директора по маркетингу, чтобы отдел мог модифицировать сайт быстро и без участия разработчиков.
А насчет приложений вы не совсем правы, потому что бизнес оценивает их эффективность не по отзывам в маркете, а по влиянию на свои процессы.
Сам выбор кейсов тоже любопытен. Приложения для SPAR мы разрабатывали на протяжении 5 лет и тогда рейтинг был 4.8. Уже 3 года ими занимается другой подрядчик.
С Быстрономом ситуация в точности обратная. Здесь как раз мы — другой подрядчик, и подхватили этот проект лишь недавно. Рейтинг вырастет, не переживайте )
openclaw в этом плане довольно гибкий. Он умеет сам перепроверять свои выводы (в том числе другой моделью LLM). Но человека в любом случае из цепочки пока исключать рано. Критичные данные (например, платежные реквизиты) обязательно смотрит сотрудник. Плюс резервные копии. Они, кстати, и от человеческих ошибок неплохо защищают )
С галлюцинациями мы не сталкивались. И да, полученные данные сперва обсуждаются внутри отдела, они нужны прежде всего для планирования гипотез и действий команды. А дальше уже попадают ко мне )
Где проходит «водораздел»? Если MCP становится универсальным слоем абстракции для агентов, не рискуем ли мы продублировать логику маршрутизации и оркестрации, которая уже живёт в ESB/EDA?
В простейшем случае — нигде. По факту, MCP каждым своим отдельным тулом повторяет роуты из API, к которым он предоставляет доступ. Но из-за того, что чем больше инструмента в MCP, тем хуже с ними работает модель. А также из-за специфики и различий разных LLM моделей. Конечный набор тулзов в MCP определяется в каждом случае уникально. Нет простого универсального правила/водораздела.
governance наборов инструментов: кто и как утверждает «белый список» MCP‑серверов, версионирует инструменты и следит за регуляторными ограничениями данных (особенно в финсекторе)?
Обычно LLM-решение — это не MCP отдельно и не LLM отдельно. Это агент, который включает в себя и доступ к конкретной модели, и набор MCP для нее. Определяется это обычно на уровне, там же где определяется доступность LLM моделей. Например, LiteLLM.
Соглашусь, в такие процессы внедрять ИИ банально рано. В попытках автоматизировать хаос получишь автоматизированный хаос.
Ответил про доступ чуть выше ) Разным сотрудникам/отделам — разные агенты.
В Onyx knowledge base можно разграничивать между агентами и точечно давать разным сотрудникам доступ к разным агентам.
Сейчас у нас Onyx подключен только к общей информации, доступной для всех, а дальше в плане, как и написал, подключать к отдельным проектам Jira.
Поделитесь?
Разделение прав идет через ролевую модель (маркетинг, sales и др.). И в зависимости от прав роли агент в Битрикс может как читать, так и писать. Инженер занят, так что насчет вебвизорного пайплайна я спросил напрямую у бота. Вот его ответ
В тексте упоминал, что опус мы использовали для изначальной разработки. Сейчас используем GLM 5 / Gemini 3 Flash, Gemini 3.1 Pro для сложных задач. Подключить можно любые LLM, хоть qwen, хоть kimi, хоть Алису.
Ну, я про своего Head of AI рассказываю, а не про гипотетического ) У нас это далеко не джун.
Одно дело писать код по готовому ТЗ, другое — самому формировать технические спецификации, исходя из требований бизнеса.
Но я верю, что бывает и по-другому. Тем более, сфера пока новая и реальная экспертиза у многих еще только формируется.
Справедливое замечание, если есть свободный программист, который напишет скрипт за 2-4 часа, поддержит его при изменениях API/верстки и будет на связи для багфиксов. Тогда Python + cron действительно дешевле. Но openclaw решает другие задачи:
- Маркетологам не нужно зависеть от разработчика, они пишут задачу в Telegram и получают результат сразу. Время специалиста = деньги.
- Если сайт изменил верстку, скрипт упадет и будет ждать фикса. Агент увидит ошибку, сам адаптируется и попробует другой подход в рамках той же сессии.
- Сложные цепочки вроде «Найди статьи, собери метрики и тренды, сравни с нашими публикациями и сделай дайджест» — для Python это написание оркестратора, а для агента — одна фраза.
- Контекст не нужно кодировать: наш Клавдий знает структуру компании, предыдущие взаимодействия, типичные задачи пользователя, роли и права доступа.
Подытожу. Да, можно обойтись без openclaw. Но с ним есть гибкость, не нужно ничего допиливать (ну почти), и даже если что-то поменяется, он самостоятельно адаптируется. Это не «открытие формул в Excel», а делегирование рутины ИИ-агенту, чтобы разгрузить команду и дать не-технарям инструмент автономности. Мы используем Клавдия для того, чтобы трансформировать компанию и научить сотрудников решать простейшие задачи без программистов, которые занимаются продуктом, а не парсерами.
Причина довольно банальна: не доходили руки. Выход завирусившегося инструмента просто оказался удобным поводом начать. Часто даже просто сформулировать потребность в автоматизации бывает непросто.
Отличие то же, что и любого другого head of от джуна: понимание бизнеса клиента, самостоятельное формирование тех. требований, а не просто написание кода по ТЗ. Стратегическое мышление, понимание бизнес-логики и умение ее проектировать, а не только писать промпты. Совершенно иной набор навыков.
Спасибо за детальный разбор компании )
Отчасти вы правы по поводу сайта — он как раз в процессе обновления. Делался очень давно, на тот момент был вполне хорош и целей своих достигал. Впрочем, разработкой сайтов мы не занимаемся, и WordPress клиентам не предлагаем — не наш уровень, делаем только сложные веб-системы. WordPress — это выбор директора по маркетингу, чтобы отдел мог модифицировать сайт быстро и без участия разработчиков.
А насчет приложений вы не совсем правы, потому что бизнес оценивает их эффективность не по отзывам в маркете, а по влиянию на свои процессы.
Сам выбор кейсов тоже любопытен. Приложения для SPAR мы разрабатывали на протяжении 5 лет и тогда рейтинг был 4.8. Уже 3 года ими занимается другой подрядчик.
С Быстрономом ситуация в точности обратная. Здесь как раз мы — другой подрядчик, и подхватили этот проект лишь недавно. Рейтинг вырастет, не переживайте )
Там стандартный Playwright в основе распознавания, сюрпризов не будет, это же не фотография неясного качества, а скрин. А остальное по API, да
openclaw в этом плане довольно гибкий. Он умеет сам перепроверять свои выводы (в том числе другой моделью LLM). Но человека в любом случае из цепочки пока исключать рано. Критичные данные (например, платежные реквизиты) обязательно смотрит сотрудник. Плюс резервные копии. Они, кстати, и от человеческих ошибок неплохо защищают )
С галлюцинациями мы не сталкивались. И да, полученные данные сперва обсуждаются внутри отдела, они нужны прежде всего для планирования гипотез и действий команды. А дальше уже попадают ко мне )
В простейшем случае — нигде. По факту, MCP каждым своим отдельным тулом повторяет роуты из API, к которым он предоставляет доступ. Но из-за того, что чем больше инструмента в MCP, тем хуже с ними работает модель. А также из-за специфики и различий разных LLM моделей. Конечный набор тулзов в MCP определяется в каждом случае уникально. Нет простого универсального правила/водораздела.
Обычно LLM-решение — это не MCP отдельно и не LLM отдельно. Это агент, который включает в себя и доступ к конкретной модели, и набор MCP для нее. Определяется это обычно на уровне, там же где определяется доступность LLM моделей. Например, LiteLLM.
Спасибо за вопросы!
Спасибо! Так и есть.
Буквально в одном из первых же абзацев:
Исходные данные должны быть предварительно оцифрованы.Не угадали. Инфоцыганством не промышляю, заходите на канал и ознакомьтесь сами )
Там алгоритм такой:
1) На базе U-Net архитектуры сегментирует фото и выделяет трещины.
2) Сравнивает текстуру с эталонными образцами, используя Local Binary Patterns (LBP).
3) Классифицирует дефекты: трещины vs естественные волокна древесины. Предварительно обучается на изображениях, да.
Да, это пример совсем не обязательного внедрения ИИ )