AI-агент ломает репозиторий и выдумывает факты? Как дать Claude Code память, доступ к данным и безопасные рефлексы

Я Denis Shokhirev, Agentic AI Systems Architect из Freiburg im Breisgau, Germany, и в DennisCraft AI Studio я собираю production-grade AI-системы для DACH B2B на Claude, Supabase, n8n, Doppler и self-hosted Postgres. Типичный сбой выглядит не как “модель ошиблась”, а как очень уверенный AI-агент, который меняет не тот файл, придумывает схему таблицы, которой нет, и коммитит это в ветку так, будто все проверил.

Если у Claude Code нет памяти о вашем проекте, доступа к актуальным данным и рефлексов на опасные действия, он работает как сильный junior без контекста и без привычки останавливаться перед риском. Проблема не в одной модели. Проблема в архитектуре контура вокруг нее.

Почему агент галлюцинирует не “из ниоткуда”

В production я почти всегда вижу 3 причины. Первая: агент не знает локальные правила репозитория — структуру модулей, naming, ограничения по миграциям, формат feature flags. Вторая: у него нет прямого доступа к фактам — схеме Postgres, списку доступных endpoints, актуальным секретам и средам. Третья: перед опасным действием нет обязательной проверки.

OWASP в 2025 обновляет LLM Top 10 и отдельно указывает на prompt injection, insecure output handling и excessive agency как повторяющиеся классы риска: https://owasp.org/www-project-top-10-for-large-language-model-applications/. Это хорошо совпадает с практикой: чем больше агенту разрешено делать, тем дороже отсутствие локальных ограничений.

Что такое память в инженерном смысле

Я не имею в виду “магическую long-term memory”. Для Claude Code память — это набор проверяемых артефактов: README для агента, индекс репозитория, краткие summaries по сервисам, карта зависимостей, список допустимых команд, журнал прошлых ошибок и решений. Если памяти нет, модель каждый запуск заново “угадывает” устройство системы.

#!/usr/bin/env bash
set -euo pipefail

cat > AGENT_CONTEXT.md <<'EOF'
Project: b2b-ops-platform
Rules:
- Never edit generated files
- DB access only through repository layer
- Migrations require human approval
- Secrets only from environment variables
- Before commit run: pytest -q, semgrep --config p/ci
EOF

git ls-files > .agent_file_index.txt

Память без доступа к данным бесполезна

Следующий слой — факты из живой системы. Если агент не может проверить текущую схему БД, он выдумает колонку. Если не видит реальный API response, он создаст парсер под несуществующее поле. Если не знает, какие таблицы содержат персональные данные, он легко нарушит ваши же внутренние правила по DSGVO.

Для этого я обычно разделяю доступ на 2 уровня: read-only introspection и write-path через узкий контролируемый интерфейс. В Supabase или self-hosted Postgres агенту почти никогда не нужен прямой write-доступ. Ему нужен способ задать вопрос: “какие таблицы есть?”, “какие foreign keys существуют?”, “какие migration-файлы уже применены?”

import os
import psycopg
from psycopg.rows import dict_row

dsn = os.environ["READONLY_DATABASE_URL"]

with psycopg.connect(dsn, row_factory=dict_row) as conn:
    with conn.cursor() as cur:
        cur.execute("""
            select table_name, column_name, data_type
            from information_schema.columns
            where table_schema = 'public'
            order by table_name, ordinal_position
        """)
        rows = cur.fetchall()

for row in rows[:20]:
    print(f"{row['table_name']}.{row['column_name']} -> {row['data_type']}")

Такой доступ можно отдавать агенту через отдельный tool wrapper, а не напрямую. Тогда каждый запрос логируется, лимитируется и при необходимости проходит allowlist.

Guardrails — это не баннер “будь осторожен”, а исполняемые проверки

Самая частая ошибка — считать, что safety живет в system prompt. Нет. Prompt полезен, но его недостаточно. Без исполняемых проверок агент все равно попытается сделать опасный commit, сгенерировать секрет в коде или написать SQL строковой конкатенацией.

Я обычно ставлю 3 класса барьеров: статический анализ до commit, policy checks на уровне CI и подтверждение человека на irreversible actions. Для Python-репозиториев минимальный набор часто включает semgrep, bandit и gitleaks. У всех трех есть реальная ценность именно в agentic workflows.

name: agent-guardrails
on: [push, pull_request]
jobs:
  checks:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: returntocorp/semgrep-action@v1
        with:
          config: p/ci
      - run: pip install bandit
      - run: bandit -r .
      - uses: gitleaks/gitleaks-action@v2

Anthropic в документации по tool use прямо показывает идею: модель не должна “воображать” внешний мир, если может получить факт через инструмент. Для Claude Code это особенно важно, потому что код и окружение быстро расходятся. Источник: Anthropic documentation, tool use, 2024–2025, https://docs.anthropic.com/.

Как собрать контур Claude Code в production

1. Дайте агенту локальную операционную память

Минимум: AGENT_CONTEXT.md, список команд, карта сервисов, правила по миграциям, known pitfalls. Обновлять это надо вместе с кодом, а не как отдельную wiki, которую никто не читает.

2. Подключите инструменты только для фактов

Read-only Postgres introspection, чтение файлов, grep по репозиторию, запуск тестов, запрос к внутреннему каталогу API. Не начинайте с широкого shell-доступа. Сначала узкие операции с предсказуемым результатом.

3. Разделите генерацию и исполнение

Пусть Claude Code сначала предлагает patch или план. Отдельный шаг — применение изменений. Еще отдельный — commit. Чем меньше “одним движением” может сделать агент, тем легче отследить сбой.

4. Логируйте причины, а не только действия

Полезно хранить не только “что изменено”, но и “на основании каких фактов принято решение”. Тогда после инцидента можно понять: агенту не хватило доступа к данным, память устарела или guardrails были слишком мягкими.

type Action = "read" | "patch" | "commit";

function requireApproval(action: Action, path: string) {
  const sensitive = path.includes("migrations") || path.includes(".github");
  if ((action === "patch" || action === "commit") && sensitive) {
    throw new Error(`Human approval required for ${action} on ${path}`);
  }
}

requireApproval("patch", "db/migrations/20261110_add_users.sql");

Что реально работает в европейском B2B

В regulated среде побеждает не самый “умный” агент, а самый предсказуемый. Я вижу это на проектах в логистике, fintech и industrial automation: бизнес готов давать агенту больше автономии только после того, как появляется трассируемость, журнал доступа к данным и понятная схема эскалации на человека.

OpenAI Cookbook в 2024 тоже последовательно рекомендует использовать инструменты и retrieval вместо ответа “по памяти” там, где важна точность фактов: https://cookbook.openai.com/. Это не спор школ. Это просто дешевле, чем потом разбирать инцидент в проде.

FAQ

Достаточно ли хорошего system prompt?

Нет. Хороший prompt снижает часть ошибок, но не заменяет доступ к фактам и исполняемые проверки. Когда агент пишет код под реальный репозиторий, prompt без tools быстро упирается в выдумки.

Нужен ли RAG для Claude Code?

Не всегда. Для многих команд хватает индексированного репозитория, AGENT_CONTEXT.md и read-only доступа к схеме БД. RAG полезен, если у вас много сервисов, длинная документация и часто меняющиеся внутренние стандарты.

Можно ли давать агенту прямой доступ в Postgres?

Я советую начинать с read-only пользователя и узких запросов через wrapper. Прямой write-доступ к БД агенту в production почти никогда не нужен.

Какие проверки поставить в первую очередь?

semgrep, bandit и gitleaks закрывают большой процент типовых ошибок. После этого добавляйте approval gates на миграции, удаление файлов и изменения CI.

Как понять, что память устарела?

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

На каком этапе ваш LLM pipeline ловит больше всего проблем в production — статический анализ, runtime sandbox или human review перед опасными действиями? Мне правда интересно сравнить это с тем, что я вижу на DACH B2B проектах.
Я провожу бесплатный 30-минутный stack audit для DACH founders, которые строят AI в regulated markets. Напишите мне в LinkedIn или в @ger_dennis_ai.