# ponomar — полный корпус > Персональный сайт: «Пересобираю реальные операции на AI-агентах — на мосту Россия↔Китай». Заметки и проекты про агентные системы, автоматизацию и рекламу в Китае. Один файл со всеми опубликованными материалами https://ponomar.art: 11 заметок и 6 проектов целиком. Индекс со ссылками — https://ponomar.art/llms.txt. ======================================================================== # Заметки # Что делает автономный луп безопасным Дата: 2026-07-14 Теги: agents, automation Источник: https://ponomar.art/notes/bezopasnyy-avtonomnyy-lup/ > Агент, который сам пишет в репозиторий по расписанию, ценен не тем, что делает, а тем, что его можно оставить одного. Это свойство ограничителей, а не модели. --- Автономный агент, который раз в неделю сам заходит в репозиторий и что-то там делает, звучит как вопрос про модель: достаточно ли она умная, чтобы ей доверять. На практике это вопрос про другое — можно ли оставить её одну. И ответ почти не зависит от модели. Он зависит от ограничителей, которые стоят вокруг неё. У меня уже какое-то время крутились такие агенты: ночной, который берёт задачу из трекера и открывает pull request; разметчик недоделанных дел. Но все они были **невидимыми процессами**. Нигде не записано, что это за агент, с каким бюджетом он бегает, насколько он автономен и куда пишет результат. Пока один — держишь в голове. На третьем перестаёшь. Разбирая чужую методологию про такие «лупы», я забрал из неё не инструменты, а одну дисциплину: **каждый повторяющийся агент должен быть объявлен, а репозиторий — иметь численную оценку готовности к автономии.** Не «есть автоматизация», а «вот этот луп, паттерн такой-то, уровень такой-то, потолок трат три доллара за прогон, отчитывается туда-то». Невидимый луп — самый дорогой: он жжёт токены и пишет в код, а никто не следит за его ритмом и радиусом поражения. ## Три уровня, и где стоит человек Автономность лупа — это не «включён или выключен». Это лестница, и на каждой ступени человек стоит в другом месте.

L1 отчитывается, человек читает потом. L2 действует, но перед слиянием стоят ворота. L3 приземляет сам. Первый луп начинают с L1.

Уровень нельзя просто заявить. Оценка готовности репозитория — потолок: пока она низкая, репозиторию нельзя давать луп, который сам мёржит. Число становится воротами не только для человека, но и для того, насколько глубоко пускают агента. ## Первый луп: читает, но не трогает Пилотом я взял самый скучный и безопасный паттерн — еженедельный обход зависимостей. Раз в неделю он снимает бесплатный отчёт о просроченных и уязвимых пакетах, разбирает его и заводит **одну живую задачу** с триажем. И ничего не пишет в сам репозиторий — уровень L1, только чтение. Скучный снаружи, он держится на трёх ограничителях, и они важнее, чем сам агент. Первый — **бесплатный ранний выход**. Прежде чем звать модель, скрипт делает даровой машинный скан. Если обновлять нечего и уязвимостей нет — прогон завершается, не потратив ни цента. Луп, который платит за то, чтобы подумать о пустоте, разоряет незаметно. Второй — **жёсткий потолок трат**. У каждого прогона стоит предел в долларах. Даже если что-то пойдёт вкривь, счёт за неделю ограничен сверху числом, которое я назначил заранее, а не аппетитом агента. Третий — и он мне дороже всех — **проверяй, не доверяй**. «Только чтение» это не инструкция агенту в промпте. Это то, что я вынуждаю после него. Когда агент отработал, скрипт смотрит на рабочее дерево: если там появилась хоть одна правка — оно жёстко откатывается к чистому состоянию, а факт нарушения пишется в телеметрию. Обещание агента ничего не трогать — не гарантия. Гарантия — это ворота, которые стоят после него и не верят ему на слово.

Обещание в промпте — не гарантия. Гарантия — проверка, которая стоит после агента и откатывает всё, что он тронул сверх дозволенного.

## Что он поймал в первый же раз За первый прогон, ценой чуть больше доллара, обход сделал ровно то, ради чего он есть — не свалку из `npm outdated`, а разбор. Он нашёл критическую дыру в библиотеке генерации PDF, сходил в код и увидел, что уязвимые вызовы там не используются — но патч всё равно советует взять. Он предложил обновление фреймворка, закрывающее два десятка уязвимостей, и проверил, что оно не мажорное и не рвёт зафиксированную пару версий. А ещё он поймал ловушку, на которой я бы сам споткнулся при беглом взгляде: у одной библиотеки аутентификации тег «latest» в реестре указывает на старую стабильную ветку, тогда как проект намеренно сидит на новой бете. Совет «просто обнови до latest» здесь означал бы откат назад. Агент это увидел и написал явно. Вот в этом и смысл. Ценность не в том, что автономный агент делает работу за меня. Ценность в том, что я могу уйти и не смотреть — потому что вокруг него стоят бесплатный выход при пустоте, потолок трат и проверка, которая не верит ему на слово. Умную модель дают. Право оставить её одну — зарабатывают ограничителями. ======================================================================== # Каталог моделей у gateway — это не список доступного Дата: 2026-07-10 Теги: llm, agents Источник: https://ponomar.art/notes/katalog-ne-dostupnost/ > GET /v1/models отвечает не на тот вопрос: он перечисляет, что gateway знает, а не что ответит твоему ключу и твоему протоколу. История про то, как одна модель молчит на одном эндпоинте и оживает на другом за тем же адресом. --- Когда подключаешь OpenAI-совместимый gateway — агрегатор, который прячет несколько провайдеров за одним адресом, — первое движение руки предсказуемо: дёрнуть `GET /v1/models` и поверить списку. Список врёт. Точнее, он честно отвечает не на тот вопрос. Он перечисляет модели, которые gateway умеет маршрутизировать в принципе, а не те, что ответят именно твоему ключу и именно твоему способу вызова. Между «есть в каталоге» и «вернёт ответ на мой запрос» стоят две отдельные стены, и `/v1/models` не знает ни про одну. Первая стена — ключ. Каталог у такого gateway общий на всех, а привязка живых провайдеров идёт per-key: за моделью в списке может не стоять ни одного включённого для тебя апстрима. На вызове это выглядит как `no_available_providers` — не «модель сломана», а «под твоим ключом за ней пусто». Каталог показывает витрину, ключ определяет, что из витрины реально отпустят. Вторая стена тоньше и интереснее. Даже среди моделей, которые ключу доступны, не все отвечают на одном и том же пути. Одна отдаёт результат только на классическом `/v1/chat/completions`. Другая там молчит той же ошибкой `no_available_providers` — но оживает на `/v1/responses`, эндпоинте протокола, на котором работают агентные CLI. Та же строка ошибки на одном пути превращалась в нормальный ответ на другом — для соседней модели. Значит дело было не в теле запроса и не в ключе, а в том, что модель маршрутизируется через другой протокол за тем же base URL. Ошибка говорила «не здесь», а звучала как «сломано».

Один base URL, три протокол-эндпоинта. Модель не сломана — она просто отвечает не на том пути, где её ждут по привычке.

Диагностика после этого стала механической: не доверять одному пробнику, а прогнать матрицу «модель × эндпоинт» — каждую модель по каждому пути. Картина вышла зеркальной: то, что мертво на одном протоколе, живёт на другом, и наоборот. Пять минут `curl` в цикле дали карту, которую каталог не отдал бы никогда, потому что каталог про неё и не знает — он одномерный, а доступность трёхмерная. Отсюда урок, который я теперь применяю до того, как вписывать модель в оркестратор или строить на ней fallback-цепочку. `no_available_providers` и родственные ей ошибки почти никогда не значат «сломано» — они значат «не тем путём». За одним адресом прячутся три независимые оси: ключ (что тебе провиженено), протокол-эндпоинт (chat против responses), формат тела запроса. Прежде чем чинить формат — а именно туда тянется рука по привычке — стоит проверить первые две оси. `GET /v1/models` не ответит ни на одну из трёх; на них отвечает только матрица. ======================================================================== # Пятнадцать агентов, один забытый процесс Дата: 2026-07-07 Теги: agents, cybos Источник: https://ponomar.art/notes/pyatnadtsat-agentov-zabytyy-protsess/ > Как флот параллельных Claude Code сессий незаметно нагрел ноутбук — и почему монитор с абсолютными порогами повторил бы ту же ошибку. --- Пятнадцать параллельных сессий Claude Code — это не пятнадцать вкладок терминала. Это флот процессов: у каждой сессии свой MCP-сервер, свои дочерние процессы, свой аппетит к памяти. И следить за этим флотом не обязан никто, кроме тебя — а следить за пятнадцатью вещами одновременно человек не умеет. Я нашёл утечку случайно. Разбирал совсем другую проблему — Obsidian падал при открытии vault'а — и по пути заметил, что вентилятор Mac молотит без остановки. Причина оказалась не в Obsidian: один headless-браузер Playwright, поднятый MCP-сервером ещё три дня назад, залип на ~95% одного ядра и с тех пор просто не отпускал его. Никакого краша, никакой ошибки в логах — процесс тихо работал, пока я случайно не наткнулся на него через `ps aux`. Рядом обнаружился ещё десяток таких же MCP-серверов в состоянии покоя — не текущая проблема, но тот же структурный риск: одна забытая сессия — один потенциальный такой процесс.

Пятнадцать одинаковых процессов. Один — не такой, как остальные, уже три дня.

Второй слой оказался интереснее первого. Я стал добавлять автоматический мониторинг — фоновая проверка каждые 25 минут: сколько сессий живо, сколько простаивает, не завис ли где-то процесс. Первая версия ставила пороги по свопу и свободной памяти — казалось бы, разумно: своп под 90% — тревога. Но на этой машине своп под 90%, а свободная память в десятках мегабайт — это не авария, а обычное рабочее состояние при таком количестве одновременных агентов. С такими порогами монитор орал бы постоянно — и через неделю я бы перестал его читать. Ровно то же самое, из-за чего утечка простояла три дня незамеченной: сигнал, который выглядит как норма, тонет в потоке, который тоже выглядит как норма. Пришлось выкинуть абсолютные пороги и считать относительное: не «сколько свопа занято», а «насколько он вырос за последние 25 минут»; не «какая нагрузка сейчас», а «выросла ли она резко относительно своего же пятнадцатиминутного среднего». Мониторинг живых процессов, наоборот, остался жёстким — если один процесс час за часом ест 85% ядра, это не может быть нормой ни при какой базовой линии. Урок один и тот же на обоих уровнях: если алерт срабатывает на состоянии, которое и так всегда такое, он бесполезен — не потому что неточен, а потому что его перестают читать. Отличать сигнал нужно не от тишины, а от привычного фонового шума конкретной системы. ======================================================================== # Your agent's definition is not the source of truth Дата: 2026-07-04 Теги: agents, fde Источник: https://ponomar.art/notes/agent-role-drift/ > Three drifts between an agent's config and its code, a one-line fix that revived eight roles, and a $0.018 run that proved the layer alive — why agent definitions rot like documentation. --- I run a small orchestrator of eight "executive" agents, one per company function. Only one of them is genuinely developed — the CTO. When I opened its definition for the first time in weeks, I found three discrepancies between what the file claimed and what the agent actually does. Fixing the worst one took a single line. Proving the whole role layer was alive took one autonomous run that cost $0.018. Here is the uncomfortable frame behind those numbers: an agent's definition — its system prompt and its config — is documentation. And documentation rots at exactly the speed of the code underneath it. The three drifts, in order of loudness. The config named one model; the code called another. The definition claimed the agent "executes tasks through engineers" when in reality it runs a confined code loop: it reads and writes files itself, runs commands, makes a local commit. And the third, quietest one: the path to the personality file pointed at a directory that didn't exist. One extra segment in a path meant the identity layer silently failed to load — a stub was substituted instead. Not just for the CTO. For all eight agents at once. The fix was one line: remove the extra segment. One line brought the whole team's identities back. The rest was mechanical reconciliation — align the config with what the code actually does, and write down what had never been written at all: when this agent is invoked and what contract sits underneath it. A green gate before a pull request, review, a security check. Not "who I am" — an operating map: when, and with what. The role layer wasn't the only place drift had piled up. The same week I merged the skill layer of the same system: 48 skills that had split across two stores — a knowledge vault and an automation directory — with 20 of them diverged and 21 carrying broken frontmatter, collapsed into a single git source of truth. Two copies of anything is not redundancy. It's a guarantee that at least one copy is lying, and no error message will tell you which. But grounding the definition in code is only half the job. You can proofread a definition down to the last character and still not know whether the agent works. A role is verified by running it, not by reading it.

The definition freezes, the code keeps moving — that's drift. Grounding converges them at the code; whether it works is shown by a run.

So I gave the agent a short spec in a disposable repository: create a file, commit it, there are no tests here — don't touch anything else. It opened a separate branch, wrote the file in four steps, made a local commit, and stopped. It didn't push and it didn't touch the main branch — because those boundaries are welded into the tools it operates with, not into prompt text where they can be ignored. The entire run cost $0.018. That commit — not the tidied-up config — is the proof that the role layer is alive. Why this matters for forward-deployed AI work. When you deploy agents inside someone else's live operation — a client team that doesn't share your context and won't read your prompts — definition drift isn't a hygiene issue, it's the trust budget. The client's engineers will diff what your agent's docs claim against what its commits show, and every mismatch you didn't catch first costs you standing you can't buy back. The forward-deployed loop is exactly the one above: ground the definition in what the system actually does, put the boundaries into tooling rather than wording, then prove the role with a cheap, metered, isolated live run. Knowing the run cost $0.018 is itself part of the proof — it means every run is metered, so autonomy has a price tag instead of a vibe. Client teams don't trust prompts. They trust commits, gates, and numbers. That's why I stopped treating prompts and configs as sources of truth. The source of truth is the code and a live run. Ground the definition in code, verify by running. Anything that doesn't execute is just nice text. ======================================================================== # Определение агента — не источник истины Дата: 2026-07-01 Теги: agents, cybos Источник: https://ponomar.art/notes/dreyf-agentnyh-roley/ > История одного дрейфа: определение агента устаревает от собственного кода, как документация, — и почему рабочий агент проверяется запуском, а не чтением. --- Определение агента — его системный промпт и конфиг — это документация. А документация устаревает от кода ровно с той скоростью, с какой код под ней меняется. Я держу небольшой оркестратор из восьми агентов-«руководителей», по одному на функцию, и по-настоящему развит там ровно один — технический директор. Открыв его определение впервые за несколько недель, я нашёл три расхождения с тем, что агент делает на самом деле. В конфиге стояла одна модель — код вызывал другую. Определение утверждало, что агент «исполняет задачи через инженеров Cursor», хотя на деле он гоняет изолированный Codex-цикл: сам читает и пишет файлы, запускает команды, делает локальный коммит. И третье, самое тихое: путь к файлу личности указывал на несуществующую папку. Из-за одного лишнего сегмента в пути слой идентичности молча не грузился — вместо него подставлялась заглушка. Причём не только у техдиректора, а у всех восьми сразу. Починка идентичности оказалась одной строкой: убрать лишний сегмент из пути. Одна строка вернула к жизни личности всей команды. Остальное — механическая сверка: привести конфиг к тому, что делает код, и дописать то, чего не было вообще, — когда этот агент вызывается и какой контракт под ним стоит: зелёный гейт перед пул-реквестом, ревью, проверка безопасности. Не «кто я», а рабочая карта: когда и чем. Но заземлить определение на код — это только половина. Определение можно вычитать до последней буквы и всё равно не знать, работает ли агент. Роль проверяется не чтением, а запуском.

Определение застывает, код едет — дрейф. Заземление сводит их к коду; работает это или нет — показывает запуск.

Я дал агенту короткую спеку в одноразовый репозиторий: создай файл, закоммить, тестов здесь нет — не трогай. Он завёл отдельную ветку, за четыре шага написал файл, сделал локальный коммит и остановился. Не запушил, не тронул основную ветку — потому что эти границы зашиты в инструменты, которыми он оперирует, а не в текст промпта, где их можно проигнорировать. Весь прогон стоил меньше двух центов. Вот этот коммит — а не приведённый в порядок конфиг — и есть доказательство, что слой ролей живой. Это продолжение мысли о том, [как устроены агентные контуры](/notes/building-agentic-systems): они работают ровно настолько, насколько честны интерфейсы между компонентами. Определение агента — тоже интерфейс, только между человеком и агентом, и он врёт с той же скоростью, с какой под ним меняется код. Поэтому я перестал считать промпты и конфиги источником истины — источник истины это код и живой прогон. Заземляй определение на код и проверяй запуском. Всё, что не исполняется, — просто красивый текст. ======================================================================== # Обложка, которой почти всё равно, чем её нарисовали Дата: 2026-06-29 Теги: frontend, design Источник: https://ponomar.art/notes/kartinka-stanovitsya-rastrom/ > Я генерирую обложки для блога нейросетью, но на странице они никогда не выглядят как картинка — и поэтому модель можно брать почти любую. --- У блога есть правило: никаких фотографий. Вместо снимков — растр: изображение превращается в сетку штрихов, где длина штриха задаётся яркостью пикселя; про сам приём я [писал раньше](/notes/mashinnyy-rastr/). Недавно я добавил к этому генерацию — обложку теперь рисует нейросеть. И на стыке всплыла приятная асимметрия. Сгенерированная картинка ни разу не показывается как картинка. Она проходит через тот же растровый движок и живёт на странице сеткой штрихов. А значит модели не нужно быть хорошей в том, чем обычно меряют генераторы, — ни резкости, ни фактуры, ни «фотореализма». От неё нужна ровно одна вещь: внятная тональная структура. Тёмное станет длинными штрихами, светлое — разрывами; всё остальное движок выбросит на входе.

Модель умеет многое — растеризатор оставляет одну форму. За остальное платишь зря.

Это переворачивает выбор модели. Обычно берёшь генератор подороже за качество. Здесь дорогая модель тратит своё качество впустую — оно умирает на первом шаге конвейера. Дешёвая за несколько центов даёт ровно то, что доживёт до экрана: пятно света, силуэт, три горизонтальные полосы разной плотности. Я проверил это первым же тестовым кадром — простой высококонтрастный силуэт после растеризации неотличим от того, что дала бы модель в разы дороже. За этим стоит правило, которое я применяю шире: подбирай инструмент под то, что реально доходит до выхода, а не под то, чем инструмент гордится. Генератор гордится фотореализмом, но мой конвейер съедает фотореализм на первом шаге. Спрашивать стоит не «какая модель лучше», а «что из её работы переживёт мой пайплайн». Часто переживает заметно меньше, чем кажется. Поэтому обложки рисует нейросеть, но выбираю я не по галерее примеров, а по одному признаку: даёт ли модель чистую тональную структуру. Всё, что сверх этого, — оплаченные пиксели, которые превратятся в те же штрихи. Самая честная картинка здесь — та, от которой осталась только форма. ======================================================================== # Проверяй риск, а не инструмент Дата: 2026-06-29 Теги: tools, agents Источник: https://ponomar.art/notes/test-the-risk-not-the-tool/ > Как я оцениваю чужой AI-инструмент перед внедрением — не полным прогоном, а одним дешёвым тестом главного риска, который и решает go/no-go. --- Оценивать чужой AI-инструмент полным прогоном — дорого и почти всегда лишнее. У любого нового инструмента десятки свойств, но под конкретную задачу почти всегда есть один риск, который реально может его похоронить. Я начинаю не с тура по возможностям, а с вопроса: что здесь может не сработать так, что всё остальное потеряет смысл? И проверяю сначала только это. Недавно мне нужно было собирать двуязычные русско-китайские питчи как редактируемые презентации — настоящие текстовые объекты, а не картинки, чтобы партнёр на той стороне мог править файл у себя. Инструмент, который это обещал, выглядел убедительно. Но единственный вопрос, от которого зависело всё, был узкий: переживёт ли кириллица соседство с китайским внутри нативных фигур, или одна из письменностей рассыплется, потеряет шрифт или молча уедет в картинку. Качество шаблонов, скорость, набор форматов — всё вторично к этому go/no-go. Если две письменности не уживаются на одном слайде, остальное неважно.

Не прогоняй весь инструмент — ткни в одну точку, которая решает go/no-go.

Полный конвейер инструмента тяжёлый: он собирает каждую страницу по очереди и требует ряда подтверждений по дороге. Прогонять его целиком ради одного вопроса — расточительно. Поэтому я собрал две страницы руками, поставив русский и китайский вплотную на одном слайде, прогнал только финальный экспорт и вскрыл получившийся файл. Внутри — настоящие текстовые объекты, обе письменности целы, а шрифт под китайский движок подставил сам. Несколько минут, и вердикт получен — дальше уже можно тратить время на качество. Отдельная история — как инструмент чуть не получил неверный приговор на ровном месте. Системный интерпретатор оказался слишком старым, а установка зависимостей спотыкалась о прокси, который пересжимает пакеты и ломает их контрольные суммы. Лечится свежим окружением и установкой через зеркало, но эти полчаса не имеют никакого отношения к тому, хорош ли сам инструмент. Именно на такой ерунде чаще всего и выносят приговор «не работает» — а он оказывается про окружение, не про инструмент. И главное, ради чего всё это. Соблазн — судить по витрине: описание обещало «почти автоматически», а внутри оказался серьёзный конвейер с ручной работой; я и сам сперва заглянул не в ту папку и недосчитал половину возможностей. Поэтому я держу два вопроса раздельно: работает ли движок технически — и даёт ли он хороший результат. Первый решает go/no-go, стоит копейки и проверяется на реальном выводе, а не на описании. Второй — вопрос продакшена, и его незачем задавать, пока не закрыт первый. Большинство неудачных внедрений путают эти две вещи: гоняют инструмент вширь, устают и бросают — так и не проверив ту единственную точку, которая всё решала. ======================================================================== # Три слоя движения на странице — и чем делать самый мелкий Дата: 2026-06-26 Теги: frontend, design Источник: https://ponomar.art/notes/kogda-ne-stroit-instrument/ > Микро-анимация, hero-сцены и фоновые шейдеры — три разных инструмента, не один. Где проходят границы, на примере маленького CSS-навыка transitions.dev и одной ловушки при его установке. --- Анимация на сайте — это не одна задача, а три разных слоя, и путаница между ними даёт код, который потом тяжело держать. Я развожу их так: микро-движение (наведение, открытие модалки, лёгкий наклон карточки), сценовое движение (hero, появление секций при скролле, stagger) и фон (живые градиенты, шум). Каждому слою — свой инструмент. Попытка закрыть все три одним обычно кончается тем, что инструмент тянут туда, где он слаб.

Три слоя движения — каждому слою свой инструмент. Растягивать один на все три — главный источник «тяжёлых» анимаций.

Под самый мелкий слой я недавно поставил готовую вещь — **transitions.dev**. Это набор из 21 CSS-перехода: один namespace классов, семантические custom properties, встроенный `prefers-reduced-motion`. Никакого JavaScript в рантайме, чистый CSS. Ровно для микро-движения: кнопка, модалка, карточка. И ровно поэтому он *не* для hero и не для переходов между страницами — там нужен JS-движок с управлением таймингами и прерываниями (у меня это React и Motion), а фон вообще отдельная история на WebGL-шейдерах. Инструмент хорош тем, что честно занимает свой слой и не притворяется, что умеет больше. Одна практичная деталь, если будете ставить внешние agent-skills. transitions.dev приезжает через `npx skills` — это пакетный менеджер навыков от vercel-labs. Он кладёт навык в общий каталог `~/.agents/skills`, но Claude Code по умолчанию не в списке его таргетов, так что навык встаёт и… не виден. Лечится симлинком из `~/.agents/skills/` в `~/.claude/skills/` — именно симлинком, не копией, чтобы обновления приходили через один источник. Полчаса недоумения «почему не подхватывается», если не знать заранее. Любопытно, что сначала я собирался завернуть всё это — три инструмента под три слоя — в собственный навык-маршрутизатор: спрашиваешь, он направляет к нужному. И в последний момент не стал. Готовый навык обновляет его автор; моя обёртка протухла бы при первом же апдейте сверху, а «маршрутизатор» просто повторял бы то, что я и так держу в голове как вот эту карту слоёв. Карта полезнее обёртки — она ничего не ломает при чужих релизах. Так что коротко и применимо: прежде чем тянуться к одному большому инструменту анимации, спросите, на каком вы слое. Микро-движение почти всегда закрывается чистым CSS — и теперь для этого есть готовый набор. Сцена — это JS-движок. Фон — шейдеры. Большинство «тяжёлых» анимаций на сайтах тяжёлые ровно потому, что инструмент взяли не со своего слоя. ======================================================================== # Машинный растр как визуальный язык Дата: 2026-06-23 Теги: design, frontend Источник: https://ponomar.art/notes/mashinnyy-rastr/ > Почему изображения на сайте — не фото, а сетка штрихов: один движок печёт и статику, и интерактив. --- Сайт намеренно отказывается от фотографий: ни одного полноразмерного снимка, ни лайфстайла, ни стоковых лиц. Но изображения всё-таки нужны — и вместо фото здесь живёт **растр**: картинка превращается в сетку вертикальных штрихов, где длина штриха задаётся яркостью исходного пикселя. Светлое рвётся в разрывы, тёмное сливается в сплошные линии. Это не фильтр поверх фото. Это отдельный визуальный слой, у которого есть один важный принцип — **одно ядро на два таргета**. ## Как это устроено Вся математика растра живёт в чистом модуле: он сэмплирует картинку в сетку яркостей и выдаёт абстрактные «метки». Дальше два тонких адаптера превращают эти метки либо в инлайновый SVG (на сборке, ноль JS в рантайме), либо в отрисовку на canvas (для интерактивного hero). Один источник правды → статика и интерактив совпадают пиксель-в-пиксель.

Один движок: сетка яркостей → метки. SVG на сборке, canvas в рантайме.

## Зачем так Растр держит сайт честным: изображение есть, но оно «машинное» — данные, а не глянец. У блока с фото появляется характер, при этом в рантайм не уезжает ни лишнего килобайта картинки, ни JavaScript. А там, где нужен живой акцент, тот же движок включает интерактив — и переключатель HUMAN / MACHINE показывает, что под штрихами всё это время лежало настоящее изображение. Эта заметка — первый пример нового визуального языка блога: **растр для образов, SVG-метафоры для идей.** ======================================================================== # Как я строю агентные контуры Дата: 2026-06-20 Теги: agents, cybos Источник: https://ponomar.art/notes/building-agentic-systems/ > Заметки о композиции навыков и суб-агентов в производственные пайплайны — от простых скриптов до многоуровневых оркестраторов. --- Агентные системы — это не магия и не один большой промпт. На практике это набор небольших, специализированных агентов, каждый из которых решает одну задачу хорошо. Проблема не в том, чтобы написать первого агента; проблема в том, чтобы они работали вместе предсказуемо. Я начинаю с декомпозиции задачи на атомарные шаги — такие, которые можно проверить независимо. Каждый шаг становится либо инструментом, либо суб-агентом. Инструмент — если логика детерминированная и быстрая (API-вызов, парсинг файла). Суб-агент — если нужно рассуждение, выбор стратегии или работа с неструктурированными данными. Граница между ними важнее, чем кажется: смешение двух режимов в одном компоненте — главный источник непредсказуемости. Оркестратор управляет последовательностью и потоком данных, но сам не производит контент. Его задача — запускать суб-агентов, собирать их вывод, передавать контекст дальше и обрабатывать ошибки. Хороший оркестратор тонкий: если он начинает принимать бизнес-решения, это сигнал, что у него слишком много ответственности. Состояние — самое сложное место. Я использую файловую систему как «почтовый ящик» между агентами: один агент пишет структурированный файл, другой его читает. Это медленнее, чем передача в памяти, но дает воспроизводимость и возможность отладки. При сбое видно ровно то, что было на входе у упавшего агента. Ключевой урок: агентный контур работает ровно настолько хорошо, насколько четко определены интерфейсы между компонентами. Инвестиция в четкие форматы входа и выхода окупается в десять раз — при отладке, при добавлении нового агента, при смене модели. Все остальное — детали реализации. ======================================================================== # Заметки про рекламу в Китае Дата: 2026-06-10 Теги: go-to-china Источник: https://ponomar.art/notes/go-to-china-notes/ > Полевые наблюдения о работе с китайскими рекламными платформами — что работает, что нет, и где теряются бюджеты западных брендов. --- Реклама в Китае — это отдельная дисциплина, не вариация западного performance-маркетинга. Платформы другие, логика аудиторий другая, цикл согласования материалов другой. Самая частая ошибка иностранных брендов — адаптировать западный креатив под китайские каналы и удивляться низкому CTR. Локализация — это не перевод. Ключевое отличие: данные первой стороны в Китае устроены иначе. Рекламные платформы имеют собственные закрытые экосистемы с аудиторными сегментами, которые не пересекаются с тем, к чему привыкли западные медиапланеры. Attribution модели тоже отличаются — view-through окна длиннее, multi-touch attribution работает по другим правилам. Это меняет то, как нужно читать отчеты. С технической стороны: API-интеграции требуют отдельной верификации и, как правило, партнера с местной лицензией. Прямой доступ для иностранных юридических лиц ограничен. Это не барьер, но это реальная часть онбординга, которую нельзя обойти ускорением. Я провел немало времени, помогая разобраться с документацией и спецификациями платформ — там есть нюансы, которые не отражены в официальных гайдах на английском. Хорошая новость: таргетинг по интересам и устройствам на китайских платформах очень точный, а inventory огромный. При правильно подобранных форматах и понятном для аудитории сообщении экономика кампаний работает. Проблема почти всегда не в платформе — проблема в том, что бренд пытается сказать то же самое, что говорит дома, аудитории, которая живет в другом информационном контексте. Эти заметки — зарисовки из работы, не руководство. Детали меняются быстро: платформы обновляют правила, появляются новые форматы. Но основная логика остается: China-first подход, а не China-adapted. ======================================================================== # Проекты # CybOS Роль: Автор Год: 2026 Стек: Claude Code, MCP, n8n, Obsidian Метрики: 66 навыков в индексе, 16 репозиториев, 410 объектов индекса, $2.99 за сквозную задачу Источник: https://ponomar.art/projects/cybos/ > Операционный слой на агентах: доска задач как очередь, пять классов исполнителей, границы в инструментах и стоимость каждого прогона в цифрах. --- Автономный агент, которому нечего запретить, — это не помощник, а источник ночных сюрпризов. CybOS начинался как попытка склеить личные скрипты и заметки, а вырос в другое: в операционный слой, на котором один человек тянет работу компании, и одновременно в лабораторию, где каждый приём сначала обкатывается на себе и только потом уезжает в клиентский контур. Сейчас в индексе 66 навыков — воспроизводимых процедур, которые вызываются по имени, а не пересказываются заново; 16 репозиториев; 410 объектов системного индекса, который знает, что вообще существует в контуре. Поверх этого работает ночной цикл: доска задач ведёт себя как очередь, карточку забирает один из пяти классов исполнителей — разные модели и разные рантаймы, — и задача идёт между ними эстафетой, когда одного исполнителя не хватает. Главное решение здесь не про выбор модели, а про границы. Агент коммитит в свою ветку и **никогда не мержит** — never-merge зашит в инструменты, которыми он оперирует, а не в текст промпта, где его можно молча проигнорировать. Сверху стоит confined loop: лимит итераций и таймауты, чтобы прогон умирал сам, а не тогда, когда я это замечу. Цена решения честная — часть ночной работы утром приходится домерживать руками, и автономия теряет в скорости ровно на этот шаг. Взамен ночь не может сломать то, что уже работает. Что получилось померить. Сквозная доставка задачи в чужой репозиторий — от карточки до закрытого Done — стоит $2.99 и занимает 46 ходов агента и 17 минут. Край держат тесты: 443 у оркестратора, 863 у relay, 624 у session-inspector. За один месяц замера через контур прошло 554 сессии Claude Code — это рабочая нагрузка, а не витрина. Что выключено намеренно. Ночь, в которую нечего делать, раньше всё равно поднимала весь контур и стоила $0.86 — деньги ровно за то, чтобы узнать, что очередь пуста. Теперь перед стартом стоит pre-check: пусто — не запускаемся, ноль долларов. Стоимость прогона я начал считать раньше, чем улучшать его качество: то, что не посчитано, разоряет незаметно. ======================================================================== # Реклама в Китае (Go-to-China) Роль: Russia-side lead, Wanzhong Год: 2025 Категория: российские бренды, выходящие в Китай Стек: Huawei/Petal Ads, RedNote, Baidu, Douyin, WeChat Mini Program Метрики: 10+ проектов параллельно, 4 платформы за квартал, 116 страниц правил → 3 страницы Источник: https://ponomar.art/projects/go-to-china/ > Российская сторона китайского ad-tech агентства: соло-GM, десять с лишним проектов параллельно и метод, который снимает зависимость от вопросов в CN. --- Российский бренд упирается в Китае не в бюджет, а в правила. У каждой платформы своя модерация, свои требования к квалификациям и свой список запретных тем, и всё это живёт по-китайски, в документации, которую российская сторона обычно не читает — она спрашивает. Каждый такой вопрос уезжает в CN и возвращается через сутки, а пока он летит, кампания стоит. Я веду российскую сторону китайского ad-tech агентства: соло-GM, 10+ клиентов и проектов параллельно на одного человека. Клиенты не называются по соображениям NDA; ни в одном материале не фигурируют имена без явного согласования — категорией это «федеральный банк» или «travel-маркетплейс», и дальше категории описание не идёт. Построен операционный слой на одного человека: единая воронка входящих от клиентов, шаблоны брифов, синхронизация переписки между двумя рынками и разбор платформ по одному сценарию, а не заново под каждую. Побочный результат — скорость освоения нового: за один квартал открыто четыре рекламные платформы (RedNote, Baidu, Douyin, WeChat Mini Program) против цели в одну. Ключевое решение — перестать спрашивать там, где можно прочитать источник. 116 страниц официальных правил модерации Huawei выгружены программно, около 300 тысяч знаков, и сжаты в трёхстраничную памятку для клиента. Trade-off честный: разбор занимает время и переносит ответственность за интерпретацию на меня — раньше её нёс носитель языка на той стороне. Взамен исчезает суточная задержка на каждый вопрос и вместе с ней — молчаливая зависимость от чужого расписания. Результат меряется формой переписки. Раньше в CN уходило открытое «дайте content-policy» — запрос, на который нельзя ответить быстро, потому что он не про факт, а про целый документ. После разбора уходит шесть узких вопросов, у каждого из которых есть однозначный ответ. Планов по бюджетам здесь нет и не будет: цифры клиентов остаются у клиентов. Что выключено намеренно: реакция «спросим у китайской стороны» как первый шаг. Она удобна и почти бесплатна для того, кто спрашивает, но превращает роль в передаточное звено. Пока ты передаёшь вопросы, ты не ведёшь рынок. ======================================================================== # GTC Platform Роль: Founder/инженер Год: 2026 Стек: Next.js, Prisma, Huawei/Petal Ads API Метрики: B2B SaaS, self-serve кабинет Источник: https://ponomar.art/projects/gtc-platform/ > B2B SaaS для самостоятельного запуска рекламы в Китае через Huawei/Petal Ads. --- GTC Platform — B2B-продукт для брендов, которые хотят рекламироваться в Китае через Huawei/Petal Ads, не нанимая агентство. Идея выросла из практического опыта: ведение кампаний вручную требует много ресурсов, а большинство брендов хотят контроль и прозрачность — не посредника. Платформа строится как self-serve кабинет: бренд подключается, настраивает кампанию, видит аналитику и управляет бюджетом самостоятельно. Под капотом — интеграция с Petal Ads API, маршрутизация данных через Prisma и Next.js-фронтенд с фокусом на простоту онбординга. Разработка ведётся в solo-режиме как технический основатель: от архитектуры до UI и DevOps. Процесс фиксируется через Linear — каждая фаза имеет конкретный выход и критерии готовности. Автономный агент нотного контура (`gtc-agent`) берёт часть инженерных задач — ночные прогоны, генерация PR, которые человек ревьюит утром. GTC Platform — первый шаг к продукту, который убирает языковой и операционный барьер входа на китайский рынок для малого и среднего бизнеса. ======================================================================== # Relay Orchestrator Роль: Автор Год: 2026 Стек: LLM, config-driven, Linear Метрики: тесты 814 → 863, 5 из 46 находок выше порога, второй домен без форка кода Источник: https://ponomar.art/projects/relay/ > Мост Клиент↔Китай: черновики ответов на голосе реальной переписки, гейт оператора на каждом, эскалации в CN со SLA. --- Оператор на мосту между клиентом и китайской командой тратит день не на решения, а на перепечатывание. Сообщение приходит по-русски, ответ собирается из того, что уже сто раз отвечали, часть вопросов вообще не его — их надо поднять на ту сторону и потом не забыть. Пока проект один, это терпимо. На нескольких одновременно теряются не сложные вопросы, а простые: они выглядят решёнными и тихо остаются без ответа. Relay берёт на себя первый ход. Черновик ответа собирается на голосе из реального корпуса переписки — не из шаблонов, а из того, как на этом мосту действительно пишут, — и кладётся оператору. Оператор подтверждает каждый: **автономия через гейты**, отправки без человека в системе нет вообще. Что выходит за уровень оператора, уезжает эскалацией в CN-команду с привязанным SLA, чтобы вопрос имел срок, а не только адресата. Главное архитектурное решение проверилось, когда появился второй домен — бухгалтерия юрлица, где ни голос, ни правила не совпадают с клиентским мостом. Форк кода был очевидным путём и был отвергнут: второй домен подключён изоляцией инстанса и данных при общем конфиг-driven ядре. Цена — ядро становится обязательством: любая правка касается обоих доменов сразу, и «быстро подкрутить под один случай» больше не проходит. Взамен нет двух копий, которые расходятся ровно до того дня, когда чинить надо обе. Качество кодовой базы меряется тем же способом, что и всё остальное, — прогоном. Мульти-агентное ревью дало 46 находок от пяти ролей-ревьюеров; независимый скоринг двумя скептиками отсёк 38 из них как шум, выше порога осталось пять. После фиксов тесты выросли с 814 до 863. Полезным оказался не список находок, а вторая инстанция, которая режет собственный первый проход: без неё пришлось бы чинить сорок шесть штук, из которых сорок одна не стоила касания. Что выключено намеренно: автоотправка. Черновик, который уходит сам, экономит минуту оператора и однажды стоит отношений с клиентом. Скорость здесь берут на генерации, а не на отправке. ======================================================================== # Telegram-боты Роль: Автор Год: 2024 Стек: Python, Telethon, Claude API Метрики: автоответчики, трекеры, воркфлоу-боты Источник: https://ponomar.art/projects/telegram-bots/ > Набор ботов: умные автоответчики с анти-бан логикой, трекеры и воркфлоу-автоматизация. --- Telegram давно стал рабочей платформой, но его стандартный интерфейс не покрывает автоматизацию. Набор ботов закрывает эту нишу: от умных автоответчиков до трекеров и воркфлоу-ботов, встроенных в рабочие процессы. Автоответчик — самый сложный компонент: он работает как пользователь (через Telethon), поддерживает whitelist, имитирует человеческие задержки и соблюдает quiet hours. Анти-бан логика учитывает FloodWait и rate limiting, чтобы не вызвать блокировку. Claude API отвечает за контент ответов — персонализированный, не шаблонный. Трекеры построены вокруг baby-tracker-bot: голосовые и текстовые записи через бот сразу попадают в структурированное хранилище. Воркфлоу-боты выполняют роль прокси для внутренних систем — отправка команд, получение статусов, форвардинг между чатами и каналами. Все боты развёрнуты на VPS, работают под systemd и логируются централизованно. Кодовая база вынесена в канонические репозитории с чёткой структурой и CI. ======================================================================== # MCP-серверы и инструменты Роль: Автор Год: 2026 Стек: MCP, Python, Node Метрики: 5+ серверов, Feishu/TickTick/Telegram/Calendar Источник: https://ponomar.art/projects/mcp-tooling/ > Кастомные MCP-серверы и агентная инфраструктура, связывающая рабочие сервисы в единый контур. --- Model Context Protocol (MCP) — стандарт, который позволяет ИИ-агентам работать с внешними сервисами как с родными инструментами. Вместо того чтобы писать bash-скрипты или вызывать curl вручную, агент делает инструментальный вызов — и получает ответ из нужного сервиса. Набор кастомных MCP-серверов покрывает ключевые рабочие сервисы: Feishu для корпоративного чата, TickTick для задач, Telegram-userbot для личных переписок, Apple Calendar для событий. Каждый сервер — тонкая обёртка над официальным API с обработкой авторизации, ретраями и типизацией ответов. Инфраструктура держится на `~/.claude/settings.json` как конфигурационном центре: серверы объявляются там, агент получает к ним доступ без дополнительных настроек. Запуск через uvx или npx позволяет обновлять серверы без перезаписи глобального окружения. MCP-серверы — ключевой слой CybOS: они превращают разрозненные SaaS-инструменты в единый агентный контур, где Claude Code оркестрирует задачи, синхронизации и коммуникации через один интерфейс.