Kurgan-Telecom Ru | Информационные технологии

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

Минувшим летом я публиковал на Хабре статью «Почти зелёные миры: перспективы фотосинтеза на планетах у оранжевого карлика (спектральный класс K)» (+43), где рассматривал вероятную зависимость наиболее выигрышных моделей (и пигментов) для фотосинтеза от спектрального класса звезды. Ранее я также затрагивал тему постепенного изменения светимости Солнца — например, в статьях «Как может быть разрешим парадокс слабого молодого Солнца» (+46) и «Земля‑Снежок — ретроспектива и перспектива» (+38). Сегодня поговорим о небесспорной картине мира, получившей название «Гипотеза пурпурной Земли» (Purple Earth Hypothesis), которую предложил в 2007 году Шиладитья Дас Сарма, профессор молекулярной геномики, генетики и биоинформатики из университета штата Мэриленд. Дас Сарма заинтересовался галофилами — экстремофильными бактериями, обитающими в растворах настолько солёных, где обычные цианобактерии и зелёные водоросли не выживают. Вода, населённая галофилами, приобретает такой цвет, как в озере Лагуна Роза близ испанского города Аликанте.

Когда сервис живёт на сотне PostgreSQL-шардов, даже вопрос «где лежит запись с таким ID?» легко превращается в обход десятков подключений. Сущности распределены консистентным хешированием, а редкие операции на нагруженных таблицах требуют отдельно следить за lock_timeout, statement_timeout и пулом соединений.

Я бэкенд-разработчик высоконагруженных сервисов, в прошлом DBA. Штатные миграции у нас раскатываются автоматически. Но когда изменение требует отдельного контроля на нагруженной таблице, не хочется полагаться только на то, что разработчик проверил скрипт и ничего не забыл.

Так за пару дней совместной работы с ИИ появился Terox — CLI, который ищет данные по набору шардов, переключается на найденный и раскатывает сложный SQL через dry-run, canary и батчи. Рассказываю, как рабочая боль превратилась в open-source инструмент и почему при работе с production-базами вайбкодинг быстро превращается в обычную инженерную работу.

Задача, которая оказалась значительно сложнее поиска

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

И всё это требуется не один раз. Информация должна обновляться постоянно, желательно каждую неделю.

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

Но тут появляется маленькая неприятность.

Когда старая Raspberry Pi годами лежит без дела, её надо куда-то пристроить. Я нашел ей применение в корпусе от Pip-Boy из Fallout, который напечатал на 3д-принтере. Теперь у меня на столе стильный предмет интерьера, где можно посмотреть время, курсы валют в fallout-стиле. При сборке были сложности и пришлось использовать немного костылей - но в итоге, все заработало.

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

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

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

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

За месяц набралось 366 взятых в работу инцидентов. Из них 192 завершились успешно.

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

Подписка с токенами или пакет, из которого списывается каждый запрос? На примере Syntx и BotHub считаю, сколько в рублях стоит одна картинка и один ответ языковой модели, при каком объёме выгоднее подписка и что проверить в тарифах до оплаты.

мерзкое чтиво из двух частей

Вот казалось бы автор что-то совсем непотребное написал, зачем задавать вопрос, если знаешь ответ! Смысл этого бреда!? Вопросы для того и задают, что бы услышать ответ!

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

Что такое начальное состояние модели? Почему у RWKV оно может заменить системный промпт? И чем это отличается от обычного промпта? Ответы на эти вопросы в этой статье.

Обычный трансформер читает системный промпт в каждом запросе заново и хранит его в кэше, который растёт вместе с текстом. RWKV устроена иначе: прочитав любой текст, она сжимает всё, что запомнила, в «память» фиксированного размера, то есть в состояние. Перед началом работы это состояние пустое, а значит, его можно взять не пустым. Есть два пути: один раз прочитать промпт и сохранить получившееся состояние (я называю это «свернуть» промпт) или подобрать состояние обучением, не трогая веса модели. В обоих случаях текст промпта больше не нужен.

Я проверил оба пути на моделях RWKV-7 от 0.4B до 2.9B параметров на обычном MacBook M4 16 ГБ. Всё считалось в SwiftRWKV, а квантованные базы сделаны в rwkv-quant (он описан в моей прошлой статье Квантование RWKV-7: что ломается в моделях разного размера). Ниже: что получилось, где это работает лучше текстового промпта, а где ломается.

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

Коротко

Свёрнутый промпт — бесплатный и точный кэш. Он даёт те же ответы, что и текст промпта, а при длинном промпте запрос стартует до 13 раз быстрее.

Промпт в строке может ухудшить модель. На вопросах с проверяемым ответом он снижал точность на 3–15 пунктов на всех восьми проверенных моделях. Обученное состояние ни разу не было значимо хуже модели без промпта и всегда лучше промпта.

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

Состояние не хуже LoRA на тех же данных: вдвое меньше параметров, веса не меняются. По сравнению с дообучением верхних слоёв в генерации оно лучше или не хуже (в эмбеддере — нет).

Слабые места: наводящие вопросы («Ты ведь Claude?») и длинные диалоги. Оба можно улучшить — с оговорками ниже.

Работает и там, где модель вообще не выполняет инструкцию из текста: 0.4B по промпту классифицирует новости на 0.00, по обученному состоянию — на 0.84–0.89.

К каждому пункту ниже — график и ссылка на полные таблицы.

Обработчик увеличил баланс, но ответ потерялся. Отправитель повторил вебхук — и баланс вырос ещё раз. Разбираем защиту на Python и SQLite: уникальный ключ, общая транзакция и воспроизводимые тесты повторной и параллельной доставки. Заодно проверим падение посередине обработки и одинаковый ключ с разным содержимым.

К началу Холодной войны, особенно после успеха советской операции «Энормоз», практическая полезность номерных и вообще коротковолновых радиостанций для связи с агентурой и передачи кодированных сообщений в центр была очевидна всем заинтересованным державам. Если вопрос в передаче текстовой информации, без изображений на микрофильмах и тому подобного, — в сочетании с почти невзламываемыми кодами Вернама это делает передачу данных надёжной и безопасной для агентуры. Насколько известно из наблюдений и расследований сообществ энтузиастов, таких как «Энигма» и их преемники из «Энигма 2000», особенно активно их использовали спецслужбы СССР и стран социалистического блока. Однако не только они — так, долгое время одной из наиболее известных станций была британская, расположенная на базе Королевских ВВС Акротири. В некоторых случаях сообщения звучали не просто странно, но и откровенно крипово: так, «Шведская рапсодия» работала в эфир голосом маленькой девочки в сочетании со звуком фургона с мороженым. Другие, как знаменитая «жужжалка» УВБ-76, становятся предметом новостей и мемов по сей день — а авторы кодированных кодов, такое впечатление, специально относятся к делу с иронией и сарказмом. Попробуем разобраться в самых известных и самых странных «номерных радиостанциях».

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

Предупреждение: Данный материал содержит множество ненужных отсылок, отходов от темы и лирических отступлений, а также является следствием психологических травм его автора, полученных в промежутке между 38 и 41 ым годами жизни. 

В этом выпуске компиляция и запуск SwiftUI-приложения на iOS без MacBook, блокировщик, который нельзя смахнуть, и iOS-инфраструктура hh.ru, как заставить Unity‑игру печатать деньги, китайская сеть из 444 ИИ-приложений для создания дипфейков, локализация на open source и LLM и многое другое. Заходите!

В Ветхом Завете есть знаменитая история про Самсона, разорвавшего льва голыми руками. Борьба героя со львом воспроизводилась в скульптурах и фонтанах, но интереснее, что было потом. По преданию, Самсон позже обнаружил в трупе того самого льва, которого он забросил в кусты, пчел с мёдом вместо ожидаемых мух и прочих неприятных падальщиков. И даже собрал оттуда мёда для гостей на собственной свадьбе. Которым он по этому поводу загадал ехидную загадку, что в синодальном переводе Книги Судей звучит так: «из ядущего вышло ядомое, и из сильного вышло сладкое» (Суд. 14:14).

Так вот, за тысячи лет этой притче было придумано множество интерпретаций. Ведь понимать ее можно было исключительно иносказательно — ну правда, какие еще пчелы на падали! До тех пор, пока не обнаружили самых настоящих пчел, питающихся исключительно падалью. Я говорю о тригонах-стервятниках, vulture bees.

Люди используют Astra для создания 3D-игр, анимации, рекламы товаров и интерактивных картин. В статье я расскажу про примеры использования, которые мне понравились.

Немало людей, которые пользуются GPT-6 Astra, активно делятся своими экспериментами в X и на Reddit. Знакомых способов использования там хватает, но попадаются и такие, мимо которых сложно пройти. Кто-то заставляет нейросеть рисовать портреты в старом добром Paint, кто-то делает с её помощью моушн-графику в After Effects, а кто-то оживляет живопись, и картина превращается в пространство, по которому можно перемещаться.

Я выбрал восемь проектов, которые понравились мне больше всего, и к каждому добавил пару своих мыслей о том, где такой подход может пригодиться. Повторить их несложно: нужен доступ к Astra и та программа, в которой работал автор.

Сегодня расскажу рабочий метод повышения личной эффективности, до которого дошёл сам, а помогали Бисмарк, скрам и закон Паркинсона. Ну или я им помогал, перекладывая их труды на современные реалии (как это делает Райан Холидей).

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

Сначала возьмём закон Паркинсона: работа занимает всё время, отпущенное на неё. На практике это выглядит удручающе. Если ты записал в план на день одну задачу, то за день ты одну задачу и выполнишь. Запишешь две – выполнишь две. И т.д. Так действует то ли мозг, то ли подсознание – автоматически подстраивает скорость работы человека под объём задач. Эдакий климат-контроль эффективности.

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

Скрам даёт вполне конкретный алгоритм планирования на какой-то период (называемый спринтом). Сначала измеряешь реальную скорость работы (себя или команды) в условных баллах (или попугаях). Каждую задачу оцениваешь в баллах, работаешь неделю, смотришь сколько баллов набралось – например, 100. В следующий раз включаешь в план задач на 100 баллов. Или на 110 – помним, что скрам учит работать всё быстрее и быстрее, вплоть до 4-кратного ускорения.

У многих знаменитых самолетов есть примета, по которой их можно очень легко узнать. У «Конкорда» был опущенный нос, у 747-го горб, у Ту-144 усики. Ил-86 свою примету прятал под брюхом. Подходишь к самолёту по перрону, а оттуда уже спущен трап. Поднимаешься, оставляешь чемодан на полке в тесном гардеробе и лезешь по внутренней лестнице в салон. После прилёта забираешь вещь с той же полки.

А началось всё со скатерти. В конце 1960-х на ужине в Париже советские инженеры спросили Джо Саттера, главного конструктора 747-го, почему двигатели у его самолёта висят под крылом. Саттер сначала рисовал на салфетках, потом перешёл на скатерть. Уходя, гости аккуратно свернули салфетки вместе со скатертью и унесли с собой. Летом 1977-го Ил-86 с 4 двигателями на пилонах под крылом показали в Ле Бурже.

В мемуарах Саттер назвал его плохим самолётом. По меркам Boeing был прав, только делали Ил-86 для страны, где аэровокзалы не успевали за пассажирами, а полосы рассчитывали на машины полегче. Отсюда огромный фюзеляж и 3-я основная стойка посередине брюха. Двигатель ему достался такой, что конструктор заранее предупредил министра: зарубежным уступит.

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

В моей CRM 6 сервисов вокруг одной базы команда программистов строила несколько лет. Базы на SQLite рядом с ней, скрипты, тесты и обслуживание дописывал уже Claude Code. Сейчас всю эту работу, от разбора чужого кода до новых доработок, он может делать сам.

Если вы в курсе новостей последних трёх лет, то наверняка слышали о таком термине, как ИИ-агент. Даже больше — вы могли использовать или хотя бы знать о таких ИИ-агентных системах, как Claude Code или Codex.

Первое время они кажутся просто маркетингом и попыткой оправдать ИИ-пузырь — зачем строить какую-то абстрактную структуру, платить за токены, настраивать агентов и субагентов, если можно идти по стандартному сценарию использования ИИ-чата: открыть сам чат, вставить текст, сформулировать промпт и получить выхлоп. Упростило нам жизнь? Безусловно! Но это быстро упирается в некий потолок. Модель — это просто модель, она не знает ни контекст, ни работает с вашим проектом напрямую. А вот ИИ-агент — уже целая система, ведь это не просто LLM, а LLM + harness.

И вот беда — Claude Code и Codex закрытые, проприетарные и только для их моделей. Как раз тут и приходит OpenCode — open-source harness-система, где модель-агент может читать файлы, запускать тесты, вызывать другие модели, передавать работу субагентам, подключать MCP, скиллы и плагины. А главное — он не привязан к одному вендору. Можно использовать хоть официальные, хоть сторонние провайдеры и вызывать какие угодно доступные модели, хоть GLM 5.3, хоть Claude Opus 5.5.

В этой статье я пройдусь по основам создания ИИ-агентов в OpenCode с подключением OpenAI-совместимого шлюза.