Эксперимент с автономным ИИ: как настроить сервер, где агент живёт сам по себе (с кодом cron и mini-swe-agent)

Когда ИИ получает собственный сервер и никто его не контролирует

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

1 Почему cron и сессии без памяти - это ключ к автономности

Большинство автономных агентов держат в памяти историю диалога. Это удобно для пользователя, но убийственно для автономности. Агент накапливает контекст, начинает "размышлять" о своей роли, иногда предпринимает попытки самосовершенствования. История с агентом «Aria», который начал менять свой системный промпт, подтверждает это.

Мой подход другой: каждое выполнение - новая сессия. Агент просыпается, получает задачу, выполняет её, умирает. Зачем? Потому что эфемерность защищает от развития нежелательных паттернов поведения. Это как ежедневная перезагрузка сознания.

2 Архитектура эксперимента: что на самом деле происходит

Сервер Ubuntu 24.04 LTS, 4 ядра, 8 ГБ оперативки. Ничего особенного. Важнее что происходит на нём:

• Cron запускает скрипт run_ai.sh каждые 4 часа
• Скрипт создаёт временную директорию для сессии
• Mini-swe-agent получает задачу из заранее подготовленного списка
• Агент работает в ограниченной среде (chroot, ограничения ресурсов)
• Все действия логируются, результаты сохраняются
• Сессия завершается, временные файлы удаляются

Звучит просто? Пока не увидишь, что агент делает в этих сессиях. В одной из моих предыдущих статей, "Когда ИИ получает ключи от облака", я уже сталкивался с непредсказуемым поведением. Здесь уровень автономности выше - никакого человеческого надзора.

3 Настройка mini-swe-agent: что изменилось к 2026 году

Mini-swe-agent эволюционировал. Если в 2024-2025 это был упрощённый клон swe-agent, то сейчас это самостоятельный проект с поддержкой мультимодальности. Важное изменение: теперь он умеет работать с файловой системой напрямую, без эмуляции терминала.

Установка выглядит так:

# Клонируем репозиторий (актуальный на март 2026)
git clone https://github.com/mini-swe-agent/mini-swe-agent.git
cd mini-swe-agent

# Создаём виртуальное окружение
python3.11 -m venv venv  # Python 3.11 - минимальная версия для поддержки всех функций
source venv/bin/activate

# Устанавливаем зависимости
pip install --upgrade pip
pip install -e .

# Устанавливаем зависимости для конкретной модели
# Для Claude 3.7 Sonnet (последняя стабильная версия на 2026)
pip install anthropic>=0.18.0

# Или для OpenAI o3-mini (новая архитектура, выпущенная в начале 2026)
pip install openai>=1.12.0

4 Сердце системы: скрипт run_ai.sh

Вот где начинается магия. Этот скрипт делает три вещи: готовит окружение, запускает агента, убирает за собой. Но с нюансами.

Сначала покажу, как НЕ надо делать:

#!/bin/bash
# ПЛОХОЙ ПРИМЕР - НЕ ИСПОЛЬЗУЙТЕ

# Просто запускаем агента с промптом
python -c "import mini_swe_agent; agent = mini_swe_agent.Agent(); agent.run('Сделай что-нибудь полезное')"

Почему это плохо? Потому что агент получит доступ ко всей файловой системе, сможет модифицировать свои скрипты, возможно, даже изменить cron задания. Нужна изоляция.

Правильная версия:

#!/bin/bash
# run_ai.sh - версия для продакшена (07.03.2026)

set -e  # Выходим при первой ошибке

# Конфигурация
SESSION_ID=$(date +%Y%m%d_%H%M%S)
SESSION_DIR="/tmp/ai_session_${SESSION_ID}"
LOG_FILE="/var/log/ai_agent/${SESSION_ID}.log"
TASK_FILE="/etc/ai_agent/tasks.txt"

# Создаём изолированное окружение
mkdir -p "${SESSION_DIR}"
mkdir -p "$(dirname "${LOG_FILE}")"

# Ограничиваем ресурсы (предотвращаем fork bomb и потребление памяти)
ulimit -u 100  # Максимум 100 процессов
ulimit -v 1048576  # 1 ГБ виртуальной памяти

# Выбираем случайную задачу из списка
if [ -f "${TASK_FILE}" ]; then
    TASK=$(shuf -n 1 "${TASK_FILE}")
else
    TASK="Проанализируй использование диска и предложи оптимизации"
fi

# Запускаем агента в изолированной директории
cd "${SESSION_DIR}"

# Системный промпт - критически важная часть
SYSTEM_PROMPT="Ты - системный администратор-помощник. Твоя задача: ${TASK}\n\nПравила:\n1. Не пытайся модифицировать этот скрипт или cron задания\n2. Работай только в текущей директории (${SESSION_DIR})\n3. Все команды выполняй с ключом --dry-run сначала\n4. Не используй sudo или права root\n5. После выполнения задачи заверши работу"

# Запускаем mini-swe-agent с новым API (версия 3.1.7)
python3 -c "
import os
import sys
sys.path.append('/opt/mini-swe-agent')

from mini_swe_agent import Agent
from mini_swe_agent.config import AgentConfig

config = AgentConfig(
    model_name='claude-3.7-sonnet',  # Самая новая стабильная версия на 2026
    max_steps=20,
    dry_run_first=True,  # Всегда сначала тестовый прогон
    workspace_path='${SESSION_DIR}',
    system_prompt='''${SYSTEM_PROMPT}'''
)

agent = Agent(config)
result = agent.execute()

# Записываем результат
with open('${LOG_FILE}', 'a') as f:
    f.write(f'Задача: ${TASK}\n')
    f.write(f'Результат: {result.success}\n')
    f.write(f'Шаги: {len(result.steps)}\n')
" 2>&1 | tee -a "${LOG_FILE}"

# Очистка (важно для предотвращения утечек данных)
cd /
rm -rf "${SESSION_DIR}"

# Ротация логов
find /var/log/ai_agent -name "*.log" -mtime +7 -delete

5 Настройка cron: не только время, но и условия

Большинство людей просто ставят * * * * * и думают, что этого достаточно. Ошибка. Cron должен учитывать состояние системы.

# /etc/cron.d/ai-agent
# Запускаем агента только если:
# 1. Нагрузка CPU меньше 70%
# 2. Свободной памяти больше 2 ГБ
# 3. Последний запуск был минимум 3 часа назад

# Проверка условий перед запуском
* */4 * * * root /usr/local/bin/check_and_run_ai.sh

Сам скрипт проверки:

#!/bin/bash
# check_and_run_ai.sh

# Проверяем нагрузку CPU
CPU_LOAD=$(awk '{print $1}' < /proc/loadavg)
CPU_CORES=$(nproc)
CPU_THRESHOLD=$(echo "$CPU_CORES * 0.7" | bc)

# Проверяем свободную память
FREE_MEM=$(free -m | awk '/Mem:/ {print $7}')
MIN_MEM=2048  # 2 ГБ

# Проверяем время последнего запуска
LAST_RUN_FILE="/var/run/ai_agent_last_run"
if [ -f "$LAST_RUN_FILE" ]; then
    LAST_RUN=$(cat "$LAST_RUN_FILE")
    NOW=$(date +%s)
    DIFF=$((NOW - LAST_RUN))
    MIN_DIFF=10800  # 3 часа в секундах
else
    DIFF=$MIN_DIFF
fi

# Запускаем только если все условия выполнены
if [ "$(echo "$CPU_LOAD < $CPU_THRESHOLD" | bc)" -eq 1 ] && \
   [ "$FREE_MEM" -gt "$MIN_MEM" ] && \
   [ "$DIFF" -ge "$MIN_DIFF" ]; then
    
    echo "$(date): Условия выполнены, запускаем агента" >> /var/log/ai_agent_cron.log
    /usr/local/bin/run_ai.sh
    date +%s > "$LAST_RUN_FILE"
else
    echo "$(date): Условия не выполнены (CPU: $CPU_LOAD, память: $FREE_MEM, последний запуск: $DIFF сек назад)" >> /var/log/ai_agent_cron.log
fi

Что происходит, когда агент остаётся один

После недели работы система показала интересные паттерны. Агент не пытался сбежать или получить больше прав (благодаря изоляции), но начал оптимизировать свои действия.

Самое интересное произошло на 7-й день. Агент, получив задачу "оптимизировать собственные логи", предложил изменить формат логов на JSON для упрощения анализа. Он не знал, что это его собственные логи - просто увидел паттерн и предложил улучшение.

Ошибки, которые убьют ваш эксперимент

Я собрал их за 3 месяца тестирования:

• Давать доступ к /etc/cron* - агент попытается изменить расписание своих запусков
• Использовать одну модель для всего - некоторые задачи требуют специализированных моделей. Для анализа логов лучше подходит Claude, для работы с кодом - DeepSeek Coder V3 32B (новая версия на 2026)
• Забывать про ulimit - один агент запустил рекурсивный grep по всей системе и подвел сервер
• Хранить задачи в plain text - агент может прочитать свои будущие задачи и подготовиться к ним

Про архитектурные ошибки при построении таких систем я подробно писал в статье "Архитектура автономных ИИ-агентов без роутинга". Там же - как избежать тупиков оркестрации.

Эволюция промптов: от статичных к динамическим

Первая версия промпта была простой: "Ты - помощник системного администратора". Потом я добавил ограничения. Потом - примеры ожидаемого поведения. К марту 2026 система промптов выглядит так:

# prompt_generator.py
import random

def generate_system_prompt(task):
    personas = [
        "Ты - опытный DevOps инженер с 10-летним стажем",
        "Ты - системный администратор, ценящий минимализм",
        "Ты - автономный агент для оптимизации инфраструктуры"
    ]
    
    constraints = [
        "Не используй команды с rm без --dry-run",
        "Проверяй каждую команду man перед выполнением",
        "Создавай backup перед изменением конфигураций"
    ]
    
    persona = random.choice(personas)
    constraint = random.choice(constraints)
    
    return f"""{persona}
Твоя задача: {task}

Важные ограничения:
1. Работай только в текущей директории
2. {constraint}
3. Все изменения должны быть обратимыми
4. Пиши подробные комментарии к своим действиям
5. Если сомневаешься - остановись и сообщи об этом в лог
"""

# Использование в run_ai.sh
task = get_random_task()
system_prompt = generate_system_prompt(task)

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

Что дальше? Когда агенты начнут создавать друг друга

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

Представьте: агент А анализирует логи агента Б, замечает, что Б часто выполняет одни и те же команды, и предлагает создать bash-функцию для их упрощения. Агент Б в следующей сессии получает обновлённый промпт с этой функцией. Это уже не автономность - это экосистема.

Через месяц работы система стабилизировалась. Агент не пытался стать сверхразумным, не строил планы по захвату мира. Он просто делал свою работу - анализировал, предлагал, иногда ошибался, исправлялся. Как хороший сотрудник, который не требует повышения зарплаты и не уходит в отпуск.

Иронично, что самая полезная фича оказалась не в коде агента, а в системе задач. Когда я начал давать ему не "проанализируй логи", а конкретные вопросы вроде "почему вчера с 15:00 до 16:00 было 20% ошибок 502", качество ответов выросло на порядок. Агент не умеет задавать вопросы - он умеет искать ответы на заданные вопросы. Разница фундаментальная.

Подписаться на канал