Что именно сделал ваш ИИ-агент: журнал, который нельзя переписать

Когда ИИ-агент отвечает клиентам или трогает вашу базу, рано или поздно случается вопрос: что он сделал и почему. У большинства инструментов ответа нет — есть окно чата, которое можно листать, и всё. Появился класс решений, где ответ есть по устройству, а не по доброй воле: работа агента пишется в журнал, а интерфейс лишь показывает этот журнал. Разберу на примере Apache Maka, что это меняет и кому нужно уже сейчас.

Зачем агенту журнал

История чата и журнал работы — разные вещи, и путать их дорого.

История чата отвечает на вопрос «что было написано». Журнал отвечает на вопрос «что было сделано»: к какому инструменту агент обратился, какие права ему для этого дали, чем всё закончилось. Если агент отправил не тот ответ, списал не ту сумму или полез не в ту таблицу, разбираться придётся именно по второму, а по первому вы увидите только вежливый текст.

Вторая причина скучнее и важнее: разбирательство с клиентом. «Наш бот вам этого не писал» — слабая позиция, когда единственное доказательство лежит в окне, которое можно закрыть. Запись, которая только дополняется и не переписывается задним числом, превращает спор в проверку факта.

Где проходит граница того, что агенту вообще можно поручать, я разбирал отдельно: граница автономности ИИ-агента.

Что именно записывается

В Maka единицей записи является событие исполнения, и лента этих событий только растёт — старые записи не правятся. В неё попадают четыре вещи: сообщение модели, вызов инструмента, решение по разрешению и завершение задачи.

Третий пункт — тот, ради которого стоит смотреть на такие инструменты. Решение по разрешению значит: агент попросил доступ, кто-то этот доступ дал или не дал, и это записано. В обычной сборке агента такое решение либо зашито в конфиг, либо принимается молча, и через месяц никто не вспомнит, кто открыл боту запись в базу.

Сессии, настройки и записи о запусках остаются на вашем устройстве. Подключить при этом можно что угодно: облачный API, локальную модель или совместимый шлюз. То есть приватным становится не сам разговор с моделью — запрос всё равно уходит туда, куда вы его направили, — а вся обвязка вокруг него: что вы настраивали, что запускали и чем это кончилось.

Одно ядро на три интерфейса

Настольное приложение, терминальный интерфейс и командная строка здесь не три отдельные программы, а три тонких клиента к одному исполняющему ядру. Ядро одно и решает всё, клиенты только показывают.

Практический смысл простой. Начали задачу в окне — продолжили из терминала, не потеряв контекст. Скрипт запускает то же самое ядро, что и человек руками, а значит ведёт себя так же. И падение интерфейса перестаёт быть потерей работы: состояние живёт в журнале, а не в окне.

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

Чего ждать от проекта в таком возрасте

Здесь нужна честность, потому что название обманчиво солидное. Полное имя проекта — Apache Maka (Incubating). Слово в скобках значит, что проект находится в инкубаторе фонда, а не в числе его зрелых продуктов. Лицензия Apache 2.0 настоящая, фонд настоящий, но статус — «проходит инкубацию».

Возраст соответствующий: репозиторий создан в конце мая 2026 года. За это время он собрал больше пяти тысяч отметок и почти пять сотен ответвлений, правки идут ежедневно — проект живой и востребованный. Но разработчики прямо предупреждают, что форматы данных, команды и экспериментальные возможности ещё могут измениться.

И отдельно про сборки. Полноценные выпуски есть только для macOS. Версии для Windows и Linux существуют, но это неподписанные предварительные сборки — на рабочем компьютере с включённой защитой они потребуют ручного разрешения на запуск, а в компании с политиками безопасности могут не запуститься вовсе.

Кому это нужно уже сейчас

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

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

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

Тем, кто проектирует свою обвязку. Документация по архитектуре открыта, и разобрано там как раз то, на чём обычно спотыкаются: хранение состояния, восстановление после сбоя, границы компонентов, удалённые подключения.

Кому пока рано. Если у вас один агент отвечает на типовые вопросы в Telegram и ничего важнее не трогает, отдельный журнал исполнения — избыточная сложность. Хватит обычных логов.

Частые вопросы

Это делает работу с ИИ приватной?

Частично. Локально хранятся сессии, настройки и записи о запусках. Но если вы подключили облачную модель, сам запрос уходит к её провайдеру. Полная замкнутость получается только с локальной моделью.

Чем это отличается от обычных логов приложения?

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

Можно ли ставить это на рабочие машины сотрудников?

На macOS — да. Под Windows и Linux сборки неподписанные, и в компании с настроенными политиками их придётся отдельно разрешать. Ставить неподписанное приложение на машину бухгалтера я бы не стал.

Проект от Apache — значит, надёжно?

Не автоматически. Инкубация значит, что фонд взял проект под крыло, а не что проект уже прошёл его проверки. Лицензия и открытость реальны, а зрелость — вопрос времени.

Что делать, если формат данных поменяется?

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

Коротко о главном

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

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

Что предлагаю конкретно. Если ваш агент уже трогает деньги, заявки или данные клиентов — опишите, что именно ему доверено и как сейчас выясняется, что он сделал. Я скажу, нужен ли вам отдельный журнал исполнения или хватит правильно настроенных логов, и соберу контур с разграничением доступа. Напишите в Telegram, MAX или VK.