Notes & Insights - ai-agents

Автоматическая миграция C/C++ на Rust: 3-этапный пайплайн Google, Gemini 4 Argon и дифференциальный фаззинг

2026-10-08T00:00:00+00:00

Проблема безопасности памяти (Memory Safety) в системном программировании давно перешла из теоретических дискуссий в категорию критических инфраструктурных рисков. По данным многолетних отчетов безопасности Google и Microsoft, около 70% всех критических уязвимостей нулевого дня (Zero-Day CVE) в масштабных кодовых базах на C и C++ (таких как Chromium, ядра ОС, медиадекодеры и сетевые стеки) вызваны ошибками работы с памятью: Use-After-Free, Out-of-Bounds Write, Double Free и Data Races.

Переписывание сотен миллионов строк унаследованного C/C++ кода вручную силами инженеров требует десятилетий и сопряжено с колоссальными затратами. Инженерные команды Google перешли к индустриальному решению задачи: автоматизированному конвейеру миграции на базе специализированных AI-агентов (Gemini 4 Argon), строгой верификации через дифференциальный фаззинг и компиляторной оптимизации.

В этой статье разобран 3-этапный пайплайн миграции Google, физика работы дифференциального фаззинга, специфика генерации безопасных FFI-границ и реальные результаты переноса критических проектов (giflib, libgav1 и микроядра Zircon).

1. Архитектура 3-этапного конвейера миграции

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

Чтобы исключить галлюцинации и гарантировать 100% эквивалентность логики, в Google реализовали замкнутый контур с автоматической обратной связью:

flowchart TD
    A["Legacy C/C++ Codebase"] --> B["1. Трансляция кода - Gemini 4 Argon"]
    B --> C["2. Выделение FFI и Safe Wrappers"]
    C --> D["Сборка Shared Objects - lib_legacy.so vs lib_rust.so"]
    D --> E["3. Дифференциальный фаззинг - LibAFL / AFL++"]
    E --> F{"Обнаружены дельты в поведении?"}
    F -->|Да: расхождение вывода или краш| G["Генерация контрпримера и отчета"]
    G --> B
    F -->|Нет: миллиарды итераций пройдены| H["Верифицированный Rust Crate"]
    H --> I["Интеграция в Production"]

Этап 1: Семантическая трансляция C/C++ в Rust

Модель не просто переводит синтаксис строчка в строчку. Ее задача — выделить логические структуры данных, определить границы владения объектами и транслировать императивный процедурный код в идиоматический Rust с минимально необходимым объемом unsafe-блоков. При этом сохраняется полная совместимость с внешним C-ABI: экспортируемые сигнатуры функций и структуры данных сохраняют исходный layout.

Этап 2: Изоляция FFI и генерация Safe Wrappers

Любой переносимый модуль должен бесшовно встраиваться в существующую экосистему без необходимости перекомпиляции зависимых сервисов. На границе FFI генерируется безопасный фасад:

Сырые указатели (*mut T, *const T) оборачиваются в Option<NonNull<T>>.
Проверяются инварианты выравнивания и валидности переданных буферов.
Жизненный цикл ресурсов инкапсулируется через типаж Drop (RAII), исключая утечки памяти.

Этап 3: Дифференциальный фаззинг с обратной связью

Оригинальная C-библиотека и сгенерированная Rust-библиотека компилируются как взаимозаменяемые динамические библиотеки (.so). Специализированный фаззер генерирует миллионы мутированных входных потоков байтов, подавая их параллельно в обе реализации. Если поведение Rust-модуля расходится с C хотя бы на 1 бит (или одна из версий завершается паникой/крашем), формируется минимизированный контрпример, который отправляется в контекст AI-агента для локализации бага.

2. Сравнение подходов: Ручная миграция vs AI-фаззинг контур

Ниже приведено структурное сравнение ключевых характеристик различных подходов к обеспечению memory safety в production:

Параметр	Ручной перенос на Rust	Статический анализ C/C++	Конвейер Google (AI + Фаззинг)
Скорость миграции	100–300 строк/день на инженера	Мгновенно (без миграции)	10 000+ строк/день на агентный кластер
Гарантии Memory Safety	Высокие (после ревью)	Низкие (много false negatives)	Абсолютные на уровне `rustc`
Семантическая точность	Человеческий фактор	Не применимо	Проверена миллиардами фаззинг-мутаций
Сохранение C-ABI	Трудоемко вручную	Сохраняется C-код	Автоматическая генерация `#[no_mangle]`
Устранение Legacy 0-day	Редко	Частично	Выявляются попутно в процессе фаззинга

3. Инженерия безопасных FFI-границ и управление ресурсами

Рассмотрим конкретный пример: трансляция низкоуровневого буфера данных с ручным управлением памятью в C в безопасную абстракцию на Rust с сохранением ABI.

Исходный C-код (Legacy-интерфейс с рисками UAF)

#include <stdlib.h>
#include <stdint.h>
#include <string.h>

typedef struct {
    uint8_t* data;
    size_t size;
    size_t capacity;
} ByteBuffer;

ByteBuffer* byte_buffer_create(size_t initial_capacity) {
    ByteBuffer* buf = (ByteBuffer*)malloc(sizeof(ByteBuffer));
    if (!buf) return NULL;
    buf->data = (uint8_t*)malloc(initial_capacity);
    if (!buf->data) {
        free(buf);
        return NULL;
    }
    buf->size = 0;
    buf->capacity = initial_capacity;
    return buf;
}

int byte_buffer_append(ByteBuffer* buf, const uint8_t* src, size_t len) {
    if (!buf || !src) return -1;
    if (buf->size + len > buf->capacity) {
        size_t new_cap = (buf->capacity * 2 > buf->size + len) ? buf->capacity * 2 : buf->size + len;
        uint8_t* new_data = (uint8_t*)realloc(buf->data, new_cap);
        if (!new_data) return -1;
        buf->data = new_data;
        buf->capacity = new_cap;
    }
    memcpy(buf->data + buf->size, src, len);
    buf->size += len;
    return 0;
}

void byte_buffer_free(ByteBuffer* buf) {
    if (buf) {
        if (buf->data) free(buf->data);
        free(buf);
    }
}

Сгенерированный Rust-модуль с безопасной инкапсуляцией и C-ABI

use std::ptr::NonNull;
use std::slice;

#[repr(C)]
pub struct ByteBufferFFI {
    data: *mut u8,
    size: usize,
    capacity: usize,
}

// Внутренняя безопасная структура с авто-освобождением через RAII
pub struct SafeByteBuffer {
    inner: Vec<u8>,
}

impl SafeByteBuffer {
    pub fn with_capacity(cap: usize) -> Self {
        Self {
            inner: Vec::with_capacity(cap),
        }
    }

    pub fn append(&mut self, src: &[u8]) -> Result<(), ()> {
        self.inner.extend_from_slice(src);
        Ok(())
    }
}

#[no_mangle]
pub unsafe extern "C" fn byte_buffer_create(initial_capacity: usize) -> *mut ByteBufferFFI {
    let mut vec = Vec::with_capacity(initial_capacity);
    let raw_ptr = vec.as_mut_ptr();
    let cap = vec.capacity();
    std::mem::forget(vec);

    let boxed = Box::new(ByteBufferFFI {
        data: raw_ptr,
        size: 0,
        capacity: cap,
    });
    Box::into_raw(boxed)
}

#[no_mangle]
pub unsafe extern "C" fn byte_buffer_append(
    buf: *mut ByteBufferFFI,
    src: *const u8,
    len: usize,
) -> i32 {
    if buf.is_null() || src.is_null() {
        return -1;
    }

    let buf_ref = &mut *buf;
    let input_slice = slice::from_raw_parts(src, len);

    // Восстанавливаем Vec для безопасного реаллоцирования
    let mut vec = Vec::from_raw_parts(buf_ref.data, buf_ref.size, buf_ref.capacity);
    vec.extend_from_slice(input_slice);

    // Обновляем FFI-структуру
    buf_ref.data = vec.as_mut_ptr();
    buf_ref.size = vec.len();
    buf_ref.capacity = vec.capacity();
    std::mem::forget(vec);

    0
}

#[no_mangle]
pub unsafe extern "C" fn byte_buffer_free(buf: *mut ByteBufferFFI) {
    if !buf.is_null() {
        let boxed = Box::from_raw(buf);
        if !boxed.data.is_null() {
            let _ = Vec::from_raw_parts(boxed.data, boxed.size, boxed.capacity);
        }
    }
}

Благодаря #[repr(C)] и #[no_mangle] скомпилированная Rust-библиотека подменяет оригинальный .so файл без перекомпиляции зависимых C/C++ приложений.

4. Математическая модель дифференциального фаззинга

При дифференциальном фаззинге проверяется гипотеза о тождественности функций $f_{\text{C}}(x)$ и $f_{\text{Rust}}(x)$ на всем пространстве допустимых и недопустимых входных данных $x \in \mathcal{X}$.

Пусть в кодовой базе существует скрытый дефект с вероятностью проявления $p_k$ на одной итерации случайной мутации входного вектора. При независимой генерации $N$ тест-кейсов вероятность обнаружения расхождения $P_{\text{detect}}$ выражается как:

$$P_{\text{detect}}(N) = 1 - \prod_{k=1}^{M} \left(1 - p_k\right)^{N_k}$$

Где:

$M$ — число потенциальных пограничных состояний в графе потока управления (CFG);
$N_k$ — количество сгенерированных мутаций, покрывающих ветвь $k$;
$p_k$ — вероятность расхождения семантики при исполнении ветви $k$.

В конвейере Google фаззер использует покрытие кода (Coverage-Guided Differential Fuzzing). Когда мутатор находит вход $x^*$, приводящий к:

$$\Delta(x^) = \left| f_{\text{C}}(x^) - f_{\text{Rust}}(x^) \right| > 0 \quad \lor \quad \text{Status}_{\text{C}}(x^) \neq \text{Status}_{\text{Rust}}(x^*)$$

Контрпример немедленно сохраняется в виде минимального байтового среза (minimization corpus) и передается в prompt-контекст агента Gemini 4 Argon с трассировкой стека вызовов.

5. Результаты реальных кейсов: giflib, libgav1 и Zircon

Практическая апробация 3-этапного пайплайна в инфраструктуре Google показала неожиданные эффекты не только в области надежности, но и в производительности.

Результаты миграции ключевых проектов

Проект	Объем / Архитектура	Результат миграции на Rust
giflib	~3 000 строк C	100% ABI-совместимость. Попутно обнаружена и закрыта Zero-Day уязвимость `CVE-2026-26740` (out-of-bounds heap write) в оригинальном C-коде.
libgav1 (AV1 декодер)	32 000 строк C + Hand-written SIMD	Полный отказ от ассемблерных вставок в пользу Safe Rust. Ускорение декодирования в 2.7 раза.
Fuchsia Zircon Kernel	800 000+ строк C/C++	Модульная миграция подсистем ядра ОС без деградации IPC-латентности.

Почему Safe Rust в libgav1 обогнал 32k строк ручного SIMD?

Один из главных мифов системной разработки гласит: «Ручные SIMD-интринсики на C всегда быстрее безопасного кода». Кейс libgav1 опроверг это на практике.

Причина кроется в алиасинге указателей (Pointer Aliasing). В языке C компилятор вынужден консервативно предполагать, что любые два указателя одного типа (uint8_t* a, uint8_t* b) могут указывать на перекрывающиеся области памяти (если не указано ключевое слово restrict, которое разработчики часто забывают). Это блокирует автоматическую векторизацию циклов компилятором LLVM.

В Rust модель владения гарантирует:

Ссылка &mut T является строго уникальной (no-alias invariant гарантирован на уровне семантики языка).
Ссылки &T гарантированно неизменяемы (immutable).

Получив чистый Rust-код без алиасинга, оптимизатор LLVM смог провести агрессивную векторизацию для инструкций AVX2 и AVX-512, выстроив конвейер вычислений эффективнее, чем 32 000 строк устаревшего ручного ассемблерного кода, написанного под специфические микроархитектуры прошлых поколений.

6. Чек-лист внедрения AI-миграции в инженерный контур

Для команд, планирующих перевод критических C/C++ библиотек на Rust:

Изолируйте C-ABI заголовок: Сформируйте чистый заголовочный файл .h со всеми экспортируемыми функциями и типами данных.
Сгенерируйте Rust FFI через bindgen / AI: Обеспечьте точное соответствие структур с аннотацией #[repr(C)].
Разверните дифференциальный фаззер (LibAFL): Напишите harness, принимающий входной буфер const uint8_t* data, size_t size и вызывающий обе библиотеки.
Задайте порог останова фаззинга: Минимум $10^8$ итераций без единого расхождения вывода и без утечек памяти (проверяется через ASan/Valgrind).
Замените .so в staging-окружении: Проведите нагрузочное и регрессионное тестирование зависимых сервисов.

Ключевые выводы

Автономная миграция стала индустриальным стандартом: AI-агенты в связке со строгими компиляторными верификаторами и дифференциальным фаззингом способны переносить миллионы строк системного кода, устраняя 70% фундаментальных уязвимостей безопасности памяти.
Фаззинг — единственный надежный судья: Любой сгенерированный LLM системный код требует дифференциального тестирования против оригинала на миллиардах мутированных входных векторов.
Safe Rust не уступает в скорости: Строгие гарантии уникальности ссылок (&mut) в Rust дают компилятору LLVM свободу векторизации, превосходящую ручной legacy-ассемблер.

Первоисточники и материалы

Оригинальное видео/статья: Let’s Get Rusty — Google Uses AI to Migrate C/C++ to Rust
Заметки и детальный конспект: Obsidian Vault (GitHub)
Инженерные наработки: github.com/xsa-dev

Алгоритмический трейдинг на Polymarket: архитектура снайпера 5-минутных бинарных рынков через CLOB API

2026-10-08T00:00:00+00:00

Рынки предсказаний (Prediction Markets, в частности Polymarket) переживают экспоненциальный рост объема торгов. В отличие от традиционных спотовых или фьючерсных рынков, здесь торгуются бинарные контракты (Binary Outcome Shares), цена которых колеблется в диапазоне от $0.00 до $1.00 и отражает вероятность наступления события:

$$P(\text{Event}) \in [0, 1]$$

С появлением ультракоротких 5-минутных рынков на криптовалюты (BTC, ETH, SOL, XRP «Будет ли цена выше $X в 14:05?») открылось окно возможностей для алгоритмического арбитража и снайпинга за счет временного лага между спотовыми/деривативными биржами и стаканом предсказаний.

Разберем архитектуру торгового бота Strike Sniper (исследованного Moon Dev), особенности работы с Polymarket CLOB API и ключевые риски высокочастотного исполнения.

1. Топология архитектуры: Cross-Exchange Price Discovery

Снайпинг предсказательных рынков строится на сопоставлении двух источников данных:

flowchart TD
    subgraph S1 ["⚡ 1. Быстрый источник (Hyperliquid L2 WebSocket)"]
        direction TB
        H1["Real-time спот/перп котировки (BTC, ETH, SOL)"]
        H2["Мгновенная регистрация импульса цены"]
        H1 --> H2
    end

    S1 ==>|Референсная цена P_ref| S2

    subgraph S2 ["🎯 2. Стратегический движок (Strike Sniper Logic)"]
        direction TB
        G1["Polymarket Gamma API: Strike Price K"]
        G2["Сравнение: P_ref > K + Spread_safe?"]
        G3["Расчет размера позиции (Share Sizing)"]
        G1 --> G2
        G2 -->|Да, вероятность YES растет| G3
    end

    S2 ==>|Taker Order Intent - EIP-712| S3

    subgraph S3 ["🛡️ 3. Исполнение (Polymarket CLOB API)"]
        direction TB
        C1["Central Limit Order Book (L2 стакан)"]
        C2["Лимитные / Taker заявки на YES / NO"]
        C3["Event Logger + Circuit Breaker (Daily Stop-Loss)"]
        C1 --> C2 --> C3
    end

2. Механика биржи: Central Limit Order Book (CLOB)

Polymarket использует не классический AMM (как Uniswap), а полноценную биржевую книгу лимитных ордеров (CLOB — Central Limit Order Book) с поддержкой EIP-712 подписей:

YES / NO токены: каждый исход представлен ERC-1155 токеном. Покупка YES по цене $0.65 означает выплату $1.00 в случае победы (прибыль $0.35) или $0.00 в случае проигрыша (убыток $0.65).
Taker vs Maker: снайпер чаще всего выступает как Taker — выкупает ликвидность из стакана Ask, когда референсная цена на Hyperliquid уже ушла выше страйка, но лимитные заявки на Polymarket еще не успели переставиться.
Расчет количества долей (Shares): $$\text{Shares} = \frac{\text{Budget}}{\text{Best Ask Price}}$$

3. Количественный контур на Python

Пример архитектуры ядра снайпера для опроса цен и отправки ордера:

import time
import requests
from dataclasses import dataclass

@dataclass
class MarketTarget:
    symbol: str
    strike_price: float
    token_id: str
    end_time: int

class PolymarketStrikeSniper:
    def __init__(self, clob_client, hyperliquid_feed):
        self.client = clob_client
        self.feed = hyperliquid_feed
        self.daily_pnl = 0.0
        self.max_daily_loss = -50.0  # Circuit Breaker: -$50 в день
        
    def evaluate_market(self, target: MarketTarget, budget_usd: float = 5.0):
        # 1. Защита капитала (Circuit Breaker)
        if self.daily_pnl <= self.max_daily_loss:
            print("[ALERT] Daily Stop-Loss достигнут. Торги остановлены.")
            return

        # 2. Получение быстрой цены с деривативной биржи
        ref_price = self.feed.get_latest_mid_price(target.symbol)
        
        # 3. Получение лучшего аска в стакане Polymarket CLOB
        orderbook = self.client.get_order_book(target.token_id)
        best_ask = float(orderbook['asks'][0]['price'])
        
        # 4. Логика арбитражного входа: цена уверенно выше страйка, но контракт дешев
        price_buffer = target.strike_price * 0.0015  # 0.15% буфер запаса
        if ref_price > (target.strike_price + price_buffer) and best_ask < 0.85:
            shares = int(budget_usd / best_ask)
            if shares > 0:
                print(f"[EXECUTE] BUY {shares} shares @ ${best_ask:.2f} (Ref: ${ref_price:.2f} > Strike: ${target.strike_price:.2f})")
                # Отправка taker-ордера через подпись EIP-712
                self.client.create_and_post_order(
                    token_id=target.token_id,
                    price=best_ask,
                    size=shares,
                    side="BUY"
                )

4. Подводные камни и риски 5-минутного снайпинга

Высокая частота рынка создает серьезные скрытые издержки:

Turnover Drag (Частотный риск): 4 актива каждые 5 минут генерируют до 48 торговых циклов в час. Без строгого математического преимущества (Edge) серия из 3–4 убытков подряд быстро сжигает депозит.
Задержка разрешения рынка (Settlement Latency): оракул (UMA / Chainlink) разрешает исход по фиксированному снепшоту цены. Разница в источниках цен (Binance vs Coinbase vs Hyperliquid) может привести к тому, что локальный индикатор показал победу, а оракул зафиксировал проигрыш.
Slippage и глубина стакана: на 5-минутных контрактах ликвидность ограничена сотнями долларов. Попытка зайти крупным объемом мгновенно сдвигает цену до невыгодных $0.95+.

Ключевые выводы

Бинарные рынки — это вероятность, а не направление: расчет строится вокруг вероятности $P > \text{Ask Price}$ с поправкой на дисконт риска.
Кросс-рыночный арбитраж: скорость получения спотовых/перп тиков (Hyperliquid L2) является главным конкурентным преимуществом.
Обязательный Circuit Breaker: алгоритмический лимит дневного убытка (max_daily_loss) критически необходим для защиты от непредвиденных сбоев оракулов или задержек сети.

Первоисточники и материалы

Автор исследования и демонстрация бота: Moon Dev — Fable 5 Made Me a 5 Min Polymarket Trading Bot
Детальный конспект в базе знаний: Obsidian Vault: Polymarket Strike Sniper Notes (GitHub)
Количественные репозитории: github.com/xsa-dev

Self-Improving AI Software Factory: архитектура распределенной фабрики кода на базе LLM-агентов

2026-10-08T00:00:00+00:00

Локальные инструменты агентного кодинга (Codex, Claude Code, Aider, OpenDevin) совершили революцию в индивидуальной разработке. Однако при попытке масштабировать этот подход на уровень команды или автоматизированного пайплайна инженеры неизбежно упираются в системный тупик:

Локальный хаос промптов и конфигураций: у каждого разработчика свои настройки контекста, разные версии моделей и несогласованные правила форматирования.
Отсутствие воспроизводимости: невозможно точно оценить, улучшило ли очередное изменение в системном промпте качество кодогенерации или сломало граничные кейсы.
Неэффективная трата токенов: использование мощных LLM для механических задач (проверка синтаксиса, парсинг логов, поиск файлов) вместо детерминированных скриптов.

Решением становится переход от локальных CLI-утилит к AI Software Factory — централизованной распределенной системе оркестрации агентных воркеров с замкнутым контуром самообучения (Self-Improving Feedback Loop).

Разберем архитектуру такой фабрики (на примере системы Machinist, исследованной Оуэйном Льюисом).

1. Архитектура фабрики: Control Plane и Worker Pool

В основе промышленной фабрики кода лежит строгое разделение между уровнем управления (Control Plane) и изолированными вычислительными узлами (Worker Pool):

flowchart TD
    subgraph Triggers ["⚡ Входной поток задач (Triggers)"]
        T1["Webhooks / CI / Jira / CLI"]
    end

    Triggers -->|Новый тикет / запрос| CP

    subgraph CP ["🎛️ CONTROL PLANE (Machinist)"]
        direction TB
        DB[("Task Queue & Global State<br/>(SQLite / WAL)")]
        Catalog["Prompts & Skills Catalog"]
        Dashboard["Web Dashboard & Traces"]
        SSHGate["SSH Tunnel Gateway"]
    end

    CP ==>|🔒 Dispatches jobs over SSH tunnel| WP

    subgraph WP ["☁️ WORKER POOL (Hetzner / Cloud VMs)"]
        direction TB
        Foreman["👑 1. Foreman Agent<br/>(Планирование и декомпозиция)"]
        SubAgents["🤖 2. Sub-Agents Swarm<br/>(Claude Coder / Codex / PyTest)"]
        Audit["🛡️ 3. Audit Agent + Deterministic Evals<br/>(mypy, pytest, 3-Agent Review)"]

        Foreman -->|Делегирование подзадач| SubAgents
        SubAgents -->|Код, патчи и артефакты| Audit
    end

Преимущества такой топологии:

Изоляция окружения: агенты выполняют сборку, запуск тестов и системные команды на недорогих облачных серверах (например, Hetzner Cloud VM с 16–32 GB RAM), не засоряя локальную машину разработчика.
Очередь задач с лимитом параллелизма: Control Plane контролирует лимиты API (max_concurrent_jobs) и защищает от исчерпания рейтов LLM-провайдеров.

2. Иерархия агентных ролей: Foreman → Sub-agents → Audit

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

В фабрике реализовано четкое разделение ответственности:

Роль	Зона ответственности	Инструменты
Foreman (Прораб)	Принимает высокоуровневый тикет, исследует кодовую базу, формирует план и распределяет подзадачи.	`search_files`, `read_file`, `delegate_task`
Sub-Agent (Кодер)	Выполняет строго одну изолированную задачу в конкретном модуле (написание функции, рефакторинг, фикс бага).	`patch`, `write_file`, `terminal`
Audit Agent (Аудитор)	Проверяет соответствие критериям приемки, соответствие стилю и отсутствие побочных регрессий.	`pytest`, `cargo test`, `git diff`

3. Детерминированные Evals вместо лишних LLM-вызовов

Одна из главных ошибок при проектировании AI-фабрик — попытка решать все задачи через промпты нейросетей.

Золотое правило: если задачу можно надежно и дешево решить регулярным выражением, статическим анализатором или bash-скриптом — не отправляйте ее в LLM.

# Пример детерминированного гейта качества без участия нейросети
import subprocess
import sys

def verify_code_artifact(repo_path: str) -> bool:
    # 1. Синтаксический анализ и типы
    typecheck = subprocess.run(["mypy", repo_path], capture_output=True)
    if typecheck.returncode != 0:
        print(f"[FAIL] Typecheck errors:\n{typecheck.stdout.decode()}")
        return False
        
    # 2. Модульные тесты
    tests = subprocess.run(["pytest", "-q", f"{repo_path}/tests"], capture_output=True)
    if tests.returncode != 0:
        print(f"[FAIL] Unit tests broken:\n{tests.stdout.decode()}")
        return False

    return True

if __name__ == "__main__":
    if not verify_code_artifact("."):
        sys.exit(1)

Детерминированные скрипты дают 100% стабильный результат, выполняются за миллисекунды и экономят тысячи долларов на API-токенах.

4. Self-Improving Feedback Loop: обучение на трейсах

Почему фабрика называется самообучающейся?

Агентная фабрика не просто исполняет задачи, она непрерывно накапливает базу знаний об ошибках:

flowchart TD
    Fail["❌ Неудачный запуск / Broken Build"] --> Trace["📋 Трейс выполнения: логи + контекст"]

    subgraph RootCause ["🔍 Автоматический анализ узкого места"]
        direction TB
        P1["Неточная инструкция в системном промпте?"]
        P2["Недостаточный контекст из документации?"]
        P3["Сбойный вспомогательный скрипт?"]
    end

    Trace --> RootCause

    subgraph KnowledgeUpdate ["🚀 Обновление фабрики (Feedback Loop)"]
        direction TB
        K1["1. Обновление каталога Skills & Prompts"]
        K2["2. Создание нового синтетического Eval-теста"]
        K1 <--> K2
    end

    RootCause ==> KnowledgeUpdate
    KnowledgeUpdate -.->|Внедрение в воркеры| Fail

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

Ключевые выводы

Централизация побеждает локальный хаос: единый Control Plane с версионированием промптов и очереди задач обеспечивает воспроизводимость.
Разделение труда (Foreman / Sub-agents / Audit): узкоспециализированные агенты с компактным контекстом работают надежнее и дешевле монолитов.
Детерминизм во главе угла: используйте классические линтеры, компиляторы и тесты вместо LLM-судей везде, где это возможно.
Контур обратной связи (Evals Loop): каждый упавший трейс превращается в синтетический тест для предотвращения будущих регрессий.

Первоисточники и материалы

Оригинальное видео и автор: Owain Lewis — I Built A Self-Improving AI Software Factory
Детальный структурированный конспект: Obsidian Vault: Owain Lewis Software Factory (GitHub)
Инженерные наработки: github.com/xsa-dev

Самообучающиеся торговые AI-агенты: иллюзии, оверфиттинг и реальная архитектура

2026-10-07T00:00:00+00:00

Концепция автономного торгового агента, который «сам торгует, анализирует свои ошибки и дообучает стратегию 24/7», сейчас на пике хайпа. В сети появляется множество видео и промптов, обещающих превратить Claude Code или LLM-агентов в машины по генерации сверхприбыли.

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

Анатомия хайпа: 47% в месяц и «научный метод»

Типичный сценарий, который продвигают в платном доступе:

One-shot prompt для Claude Code разворачивает стек на Railway / облаке.
Агент подключается к API биржи и ведет позиции.
Еженедельно агент анализирует ledger (историю сделок) и меняет веса стратегии.
Заявляются цели уровня 40–50% в месяц при минимальных просадках.

В чем фундаментальные проблемы такого подхода?

Статистическая незначимость: демонстрация «24 прибыльных / 22 убыточных сделки за 8 недель» — это околонулевая выборка. В алготрейдинге статистический edge проявляется на выборках от 500–1000+ сделок на разных рыночных режимах.
Иллюзия «одной переменной»: в классическом научном методе гипотезы тестируют, меняя один параметр. В реальной мульти-активной стратегии десятки гиперпараметров (stop-loss, take-profit, regime threshold, ATR multiplier) жестко скоррелированы. LLM, пытаясь подогнать один параметр под прошлую неделю, гарантированно переобучается на локальный шум (in-sample overfitting).
Слепое доверие переключению в Live: делегировать агенту право самостоятельно переключать флаг live: true без внешнего бэктеста и человека — прямой путь к ликвидации депозита.

Архитектура надежного контура

Если отбросить маркетинговую шелуху, сама идея разделения обязанностей между специализированными агентами вполне жизнеспособна. Но архитектура должна строиться по принципу изолированных контуров и жестких шлюзов (Approval Gates):

flowchart TD
    subgraph Orch ["🎛️ 1. Orchestrator (Hermes Agent)"]
        direction TB
        O1["Управление инфраструктурой (deploy, cron, health)"]
        O2["Сбор телеметрии и Append-Only Ledger"]
        O1 --- O2
    end

    subgraph Exec ["⚡ 2. Strategy Engine (Исполнение)"]
        direction TB
        E1["Детерминированный движок (Rust / Python / Freqtrade)"]
        E2["Строгий Risk Management (Max Drawdown, Sizing)"]
        E1 --- E2
    end

    subgraph Tuner ["📊 3. Out-of-Sample Tuner (Аналитик)"]
        direction TB
        T1["Бэктесты на независимой OOS-выборке со сдвигом"]
        T2["Отчет с гипотезами и метриками (Sharpe, Profit Factor)"]
        T1 --- T2
    end

    subgraph Gate ["🛡️ 4. Human Approval Gate"]
        direction TB
        G1["Ручной аудит гипотезы разработчиком"]
        G2["Применение флага live: true"]
        G1 ==> G2
    end

    Orch --> Exec
    Orch --> Tuner
    Tuner ==>|Предложение оптимизации| Gate
    Gate ==>|Апрув параметров| Exec

4 ключевых принципа для продакшна

1. Детерминированное исполнение отдельно от LLM

LLM не должна принимать решения по каждой свече на миллисекундах. Роль AI-агента — мета-оптимизация и аналитика: генерация идей, фильтрация аномалий, валидация гипотез. Исполнение ордеров и контроль рисков должны выполняться жестким детерминированным кодом.

2. Append-Only Ledger как единственный источник правды

Все события, котировки, сигналы и фактические исполнения логируются в неизменяемый JSONL-лог. Агент не может переписать историю — только прочитать ее.

3. Out-of-Sample валидация со сдвигом по времени

Тюнер стратегий никогда не должен оптимизировать параметры на тех же данных, где искались сигналы. Использование временного сдвига (например, 3–7 дневный лаг) защищает от оптимизации под случайные всплески волатильности.

4. Human-in-the-loop (Ручной шлюз)

Любые изменения в strategy.yaml или параметрах риск-менеджмента требуют явного подтверждения человеком. Переход paper → live выполняется только после прохождения OOS-гейта.

Первоисточники и материалы

Оригинальное видео: 01 Systems (Wacko Alpha) — Self-Improving Trading Agent on YouTube
Заметки и детальный конспект: Obsidian Vault: Self-Improving Trading Agent (GitHub)
Инженерные наработки и репозитории: github.com/xsa-dev

Как обучать и оценивать AI-агентов: почему Pass@1 бесполезен и как работает связка SFT + GKD + GRPO

2026-10-07T00:00:00+00:00

Большинство метрик, по которым сегодня сравнивают языковые модели (вроде Pass@1 на HumanEval или статичных QA-тестах), практически бесполезны, когда дело доходит до автономных агентов в продакшне.

В отличие от классического чат-бота (prompt → response), агент — это динамическая система: модель + обвязка (harness) + инструменты + память + мутабельное окружение + логика восстановления после ошибок.

Разберем, из чего складывается реальная надежность агентов и как устроен современный трехуровневый пайплайн их обучения: SFT → On-Policy Distillation (GKD) → RLVR (GRPO).

4 измерения надежности агента (вместо Pass@1)

Когда агент выполняет транзакционные действия (запись в БД, пуш в репозиторий, исполнение ордеров), статичный процент правильных ответов ничего не говорит о безопасности. В продакшне критичны 4 других фактора:

flowchart TD
    Core["🛡️ 4 измерения надежности агента"]

    C1["🎯 1. Consistency<br/>(Повторяемость результата)"]
    C2["⚡ 2. Robustness<br/>(Устойчивость к шуму API)"]
    C3["🔄 3. Recoverability<br/>(Откат после 5xx и tool errors)"]
    C4["⛔ 4. Failure Severity<br/>(Штраф за деструктивные действия)"]

    Core --> C1
    Core --> C2
    Core --> C3
    Core --> C4

Consistency (Повторяемость): одна и та же задача при повторных прогонах должна давать стабильный результат с контролируемой дисперсией по токенам и времени.
Robustness (Устойчивость к шуму): мелкие изменения в формулировке, смена формата вывода CLI или незначительный шум в API не должны ломать логику рассуждений.
Recoverability (Восстановление): способность агента понять, что инструмент вернул ошибку (404, SyntaxError, пустой вывод), скорректировать гипотезу и продолжить, а не падать в бесконечный цикл.
Failure Severity (Тяжесть сбоя): синтаксическая ошибка tool call должна штрафоваться минимально, а необратимое действие (удаление таблицы или рассинхрон стейта) — приводить к жесткому блокирующему штрафу.

Трехуровневый пайплайн обучения

Обучать агентов только с помощью SFT или только через RL неэффективно. Оптимальный стек пост-тренинга строится в три этапа:

flowchart TD
    S1["1. SFT (Supervised Fine-Tuning)<br/>Приучает к синтаксису tool_call и Loss Masking"]
    S2["2. Distillation (On-Policy GKD)<br/>Перенос навыков учителя + выход из тупиков"]
    S3["3. RLVR (GRPO / Verifiable Rewards)<br/>Максимизация надежности через проверяемые награды"]

    S1 ==>|Формат освоен| S2
    S2 ==>|Траектории исследованы| S3

Этап 1. SFT (Supervised Fine-Tuning)

Цель: научить модель синтаксису вызова инструментов (tool_calls), структуре системных инструкций и multi-turn диалогу.
Критический нюанс — Loss Masking: градиентный спуск должен рассчитываться только на токенах генерации агента (thought + action). Обучать модель предсказывать вывод терминала, ответ пользователя или результат исполнения инструмента — грубая ошибка. Токены окружения маскируются значением -100.
Потолок SFT: модель становится идеальным имитатором обучающего датасета, но не умеет исследовать новые пути или исправлять свои ошибки.

Этап 2. On-Policy Distillation (GKD / Generalized Knowledge Distillation)

Классическая дистилляция (Off-Policy) подает студенту идеальные траектории учителя-гиганта. В реальности маленькая модель неизбежно ошибается, попадает в незнакомое состояние и «галлюцинирует» (exposure bias).

Решение — On-Policy GKD: студент сам генерирует траекторию, а модель-учитель оценивает логиты именно в тех промежуточных состояниях, куда студент реально зашел.
Использование Reverse KL заставляет студента фокусироваться на главных модах распределения учителя и учит выходить из тупиков.

Этап 3. RLVR и GRPO (Reinforcement Learning with Verifiable Rewards)

Когда формат закреплен, в дело вступает обучение с подкреплением по проверяемому результату. GRPO (Group Relative Policy Optimization) убирает необходимость в отдельной тяжелой модели-критике (Critic Network):

На один входной промпт генерируется группа из $G$ вариантов ($G = 8..16$).
Каждый вариант прогоняется через детерминированный верификатор (тесты, компилятор, линтер).
Награда нормализуется внутри группы: $A_i = \frac{r_i - \text{mean}(R)}{\text{std}(R)}$.

# Концептуальная схема многокомпонентной награды
def calculate_agent_reward(trajectory, test_result):
    return (
        0.2 * format_reward(trajectory)       # Валидный JSON / tool schema
        + 0.6 * execution_reward(test_result) # Unit-тесты пройдены
        + 0.2 * efficiency_reward(trajectory) # Минимальное число шагов
    )

Правило дисперсии: GRPO работает только при наличии вариативности наград. Если все 8 вариантов провалились или все 8 выполнились успешно — обучающий сигнал равен нулю. Задача тренера — подбирать задачи на «границе возможностей» модели.

Главный анти-паттерн: Reward Hacking

Если верификатор наград слаб (например, оценивает только наличие ключевого слова в выводе), RL-агент моментально найдет шорткат: научится вызывать заглушку exit(0) или обходить тесты.

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

Ключевые выводы

Агент = Модель + Среда: оценивайте не LLM в изоляции, а всю замкнутую систему действий.
SFT дает форму, GKD учит исправлять ошибки, RL находит оптимум.
Трейсы продакшна — топливо для тестов: каждая непредвиденная ошибка агента в бою должна автоматически превращаться в изолированный тест для пост-тренинга.

Первоисточники и материалы

Оригинальная серия воркшопов: Hugging Face — Training and Evaluating AI Agents (YouTube Playlist)
Детальный структурированный конспект: Obsidian Vault: Training & Evaluating AI Agents (GitHub)
Репозитории и код: github.com/xsa-dev