Реализация глубокого Q-обучения (DQN) с нуля с использованием RLax, JAX Haiku и Optax для обучения агента по обучению с подкреплением в среде CartPole

от

В этом руководстве мы реализуем агента по обучению с подкреплением (RL) с помощью RLax — исследовательской библиотеки, разработанной Google DeepMind для создания алгоритмов обучения с подкреплением с использованием JAX. Мы объединяем RLax с JAX, Haiku и Optax, чтобы создать агента глубокого Q-обучения (DQN), который учится решать задачу CartPole.

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

Установка необходимых библиотек и импорт модулей

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

«`python
import os
os.environ[«XLAPYTHONCLIENT_PREALLOCATE»] = «false»

import random
import time
from dataclasses import dataclass
from collections import deque

import gymnasium as gym
import haiku as hk
import jax
import jax.numpy as jnp
import matplotlib.pyplot as plt
import numpy as np
import optax
import rlax

seed = 42
random.seed(seed)
np.random.seed(seed)

env = gym.make(«CartPole-v1»)
eval_env = gym.make(«CartPole-v1»)

obsdim = env.observationspace.shape[0]
numactions = env.actionspace.n
«`

Определение Q-сети

«`python
def q_network(x):
mlp = hk.Sequential([
hk.Linear(128), jax.nn.relu,
hk.Linear(128), jax.nn.relu,
hk.Linear(num_actions),
])
return mlp(x)

qnet = hk.withoutapplyrng(hk.transform(qnetwork))
«`

Настройка буфера воспроизведения

«`python
@dataclass
class Transition:
obs: np.ndarray
action: int
reward: float
discount: float
next_obs: np.ndarray
done: float

class ReplayBuffer:
def init(self, capacity):
self.buffer = deque(maxlen=capacity)

def add(self, *args):
self.buffer.append(Transition(*args))

def sample(self, batch_size):
batch = random.sample(self.buffer, batch_size)
obs = np.stack([t.obs for t in batch]).astype(np.float32)
action = np.array([t.action for t in batch], dtype=np.int32)
reward = np.array([t.reward for t in batch], dtype=np.float32)
discount = np.array([t.discount for t in batch], dtype=np.float32)
nextobs = np.stack([t.nextobs for t in batch]).astype(np.float32)
done = np.array([t.done for t in batch], dtype=np.float32)
return {
«obs»: obs,
«action»: action,
«reward»: reward,
«discount»: discount,
«nextobs»: nextobs,
«done»: done,
}
«`

GitAgent: Docker для агентов ИИ, который наконец решает проблему фрагментации между LangChain, AutoGen и Claude Code

Текущее состояние разработки агентов ИИ характеризуется значительной архитектурной фрагментацией. Разработчики программного обеспечения, создающие автономные системы, обычно вынуждены выбирать одну из нескольких конкурирующих экосистем: LangChain, AutoGen, CrewAI, OpenAI Assistants или более поздний Claude Code.

GitAgent, инструмент с открытым исходным кодом и интерфейс командной строки (CLI), вводит фреймворк-независимый формат, предназначенный для отделения определения агента от его среды выполнения. Обращаясь с агентом как со структурированной папкой в репозитории Git, GitAgent стремится предоставить «универсальный формат», который позволяет разработчикам определять агента один раз и экспортировать его в любую из основных слоёв оркестрации.

Компонентная архитектура GitAgent

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

  • `agent.yaml`: центральный файл манифеста. Он содержит метаданные агента, включая информацию о поставщике модели, версии и зависимостях среды.

  • `SOUL.md`: файл Markdown, определяющий основную идентичность агента, личность и тон. Это заменяет неструктурированные «системные подсказки», часто разбросанные по разным файлам Python в традиционных реализациях.

  • `DUTIES.md`: в этом файле описаны конкретные обязанности и разделение обязанностей (SOD). Он определяет, что разрешено делать агенту, и, что особенно важно, что ему запрещено делать.

  • `skills/` и `tools/`: эти каталоги содержат функциональные возможности. «Навыки» относятся к поведенческим паттернам более высокого уровня, а «инструменты» — это дискретные функции Python или определения API, которые агент может вызывать для взаимодействия с внешними системами.

  • `rules/`: выделенное пространство для ограждений. Это позволяет инженерам встраивать безопасность и организационные ограничения непосредственно в определение агента, обеспечивая их сохранение независимо от того, какой фреймворк используется для развёртывания.

  • `memory/`: в отличие от традиционных агентов, которые хранят историю в оперативной памяти или в непонятных базах данных, GitAgent хранит состояние в удобочитаемых человеком файлах, таких как dailylog.md и context.md.

Надзор и уровень версионирования

Одной из основных технических проблем при развёртывании автономных агентов является отсутствие прозрачности относительно того, как поведение агента меняется с течением времени. GitAgent решает эту проблему, используя Git в качестве основного уровня надзора.

В стандартном рабочем процессе GitAgent любое обновление «внутреннего состояния» агента, такого как изменение его памяти или приобретение нового навыка, рассматривается как изменение кода. Когда агент обновляет свой context.md или изменяет свой SOUL.md на основе нового обучения, система может быть настроена на создание новой ветки Git и запроса на извлечение (PR).

Это позволяет разработчикам программного обеспечения применять установленные практики CI/CD к поведению ИИ. Человек-рецензент может проверить разницу в памяти агента или изменениях в личности, убедившись, что агент остаётся в соответствии со своим первоначальным замыслом. Если агент начинает проявлять галлюцинации или отклоняется от своей личности, разработчик может просто выполнить git revert до предыдущего стабильного состояния.

Интерoperability фреймворков и рабочий процесс экспорта

Основная полезность GitAgent заключается в его механизме экспорта, управляемом CLI. После того как агент определён в универсальном формате, его можно перенести в специализированные среды «Пяти фреймворков»:

  • OpenAI: стандартизирует агента в соответствии со схемой, необходимой для Assistants API.

  • Claude Code: адаптирует определение для использования в терминальной среде агентов Anthropic.

  • LangChain/LangGraph: отображает логику агента в виде узлов и рёбер графа для сложных, управляемых состоянием рабочих процессов RAG.

  • CrewAI: форматирует агента в ролевую сущность, способную сотрудничать в рамках многоагентной «команды».

  • AutoGen: преобразует определение в диалогового агента, способного вести асинхронный диалог с несколькими агентами.

Используя команду `gitagent export -f [framework_name]`, разработчики программного обеспечения могут переключать механизмы выполнения, не изменяя основную логику, хранящуюся в их SOUL.md или каталоге skills/. Эта модульность предотвращает блокировку поставщиков и позволяет командам выбирать уровень оркестрации, который лучше всего подходит для конкретной задачи.

Соответствие корпоративным требованиям и разделение обязанностей (SOD)

Для разработчиков и исследователей ИИ в регулируемых секторах GitAgent предоставляет встроенную поддержку стандартов соответствия, таких как FINRA, SEC и Федеральная резервная система. Это достигается с помощью фреймворка разделения обязанностей (SOD), определённого в репозитории.

В сложных финансовых или юридических рабочих процессах часто требуется, чтобы человек (или агент), инициирующий процесс, не был тем, кто его утверждает. GitAgent позволяет разработчикам определять матрицу конфликтов, в которой конкретным агентам назначаются роли, такие как создатель, проверяющий или исполнитель. Перед развёртыванием команда `gitagent validate` проверяет конфигурацию на соответствие этим правилам, чтобы гарантировать, что ни один агент не обладает чрезмерными полномочиями, которые нарушили бы протоколы соответствия.

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

  • Фреймворк-независимая переносимость: GitAgent отделяет логику агента от среды выполнения. Используя команду `gitagent export`, вы можете определить агента один раз и развернуть его в Claude Code, OpenAI, LangChain, CrewAI или AutoGen без переписывания основной логики.

  • Git-Native Supervision (HITL): он заменяет пользовательские информационные панели утверждения стандартными запросами на извлечение (PR). Когда агент обновляет свою память или приобретает новый навык, он создаёт ветку и PR, позволяя людям просматривать, сравнивать и утверждать изменения в поведении ИИ, как стандартный код.

  • Управление состоянием, понятным человеку: в отличие от непрозрачных векторных баз данных, GitAgent хранит долговременную память в каталоге memory/ в виде файлов Markdown (context.md, dailylog.md). Это делает состояние агента полностью доступным для поиска, контролируемым версиями и обратимым с помощью git revert.

  • Встроенная корпоративная совместимость: формат включает встроенную поддержку FINRA, SEC и Федеральной резервной системы. Через DUTIES.md разработчики могут обеспечить «разделение обязанностей» (SOD), гарантируя, что критические действия (например, одобрение транзакции) требуют многоагентной или валидации с участием человека.

  • Декларативная «Душа» и навыки: личность и возможности агента определяются в структурированных файлах, таких как SOUL.md (личность/инструкции) и skills/ (модульные функции). Эта стандартизированная структура позволяет агентам разветвляться, форкаться и совместно использоваться в виде модульных репозиториев с открытым исходным кодом.

1. Какие инструменты и библиотеки используются для реализации агента глубокого Q-обучения (DQN) в среде CartPole?

В статье для реализации агента глубокого Q-обучения (DQN) в среде CartPole используются следующие инструменты и библиотеки: RLax (исследовательская библиотека, разработанная Google DeepMind для создания алгоритмов обучения с подкреплением), JAX, Haiku и Optax.

2. Какие основные компоненты включает в себя тренировочный конвейер для обучения агента с подкреплением?

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

3. Какие проблемы решает GitAgent в контексте разработки агентов ИИ?

GitAgent решает несколько проблем в контексте разработки агентов ИИ:
* архитектурную фрагментацию между различными экосистемами (LangChain, AutoGen, CrewAI, OpenAI Assistants, Claude Code);
* необходимость написания шаблонного кода, специфичного для фреймворка;
* отсутствие прозрачности относительно того, как поведение агента меняется с течением времени;
* блокировку поставщиков и невозможность переключения механизмов выполнения без изменения основной логики.

4. Какие файлы и каталоги определяют поведение и состояние агента GitAgent?

Поведение и состояние агента GitAgent определяют следующие файлы и каталоги:
* `agent.yaml` — центральный файл манифеста, содержащий метаданные агента;
* `SOUL.md` — файл Markdown, определяющий основную идентичность агента;
* `DUTIES.md` — файл, описывающий конкретные обязанности и разделение обязанностей (SOD);
* `skills/` и `tools/` — каталоги, содержащие функциональные возможности агента;
* `rules/` — выделенное пространство для ограждений, позволяющее встраивать безопасность и организационные ограничения;
* `memory/` — каталог для хранения состояния агента в удобочитаемых человеком файлах.

5. Какие механизмы обеспечивает GitAgent для обеспечения соответствия корпоративным требованиям и разделения обязанностей (SOD)?

GitAgent обеспечивает соответствие корпоративным требованиям и разделение обязанностей (SOD) через следующие механизмы:
* определение матрицы конфликтов, в которой конкретным агентам назначаются роли, такие как создатель, проверяющий или исполнитель;
* команда `gitagent validate`, проверяющая конфигурацию на соответствие правилам SOD;
* встроенная поддержка стандартов соответствия, таких как FINRA, SEC и Федеральная резервная система.

Источник