Память агента, которой можно верить

Решения проекта, которые помнит только человек

Чем дольше работаешь с моделями на настоящем проекте, тем заметнее одна особенность. Код и архитектуру модели уже пишут неплохо, а чтобы научить ее помнить решения по проекту, приходится прикладывать отдельные усилия. Если этого не сделать, в каждой новой сессии работы придется напоминать, что “решили не трогать Elasticsearch до тех пор, пока не появится реальная боль”, что “один кусок интерфейса пока временный”, что “одна гипотеза уже проверялась и провалилась и больше мы над ней работать не будем” и так далее.

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

Руководителю проекта эта картина знакома и без всяких моделей. Меняется администратор проекта или руководитель, и вместе с человеком уходят договорённости, которые нигде не были записаны. Новый человек ещё долго наступает на те же грабли и заново выясняет, почему когда-то решили именно так.

В статье на Хабре описан опыт одного разработчика, который захотел перестать быть таким “ненадежным местом” и сделал для себя сервис “Later, Bender”: отдельное хранилище, куда модель сама кладёт то, к чему надо вернуться, и где сама находит это в следующем разговоре. Проверить он хотел одно: продолжит ли модель работу без его пересказа, и она продолжила.

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

Когда такие записи начинает вести сам агент, меняется вопрос. Раньше спрашивали, сможет ли он вспомнить. Теперь важнее, можно ли верить тому, что он записал. Мой ответ такой. Память агента помогает, только если у каждой записи видно, откуда она взялась и кто её подтвердил. Без этого она становится ещё одним пересказом, которому нельзя верить, и ошибка из неё переезжает в следующую работу уже как факт.

Запись, по которой не понять, кто решил

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

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

В проектах эту беду лечат давно, и лекарство всем известно. Решение управляющего комитета живёт в протоколе, где видно, кто присутствовал, с каким вопросом пришли, что решили и когда. Договорённость, которая в протокол не попала, через полгода превращается в “кажется, мы договаривались”, и дальше спорят уже о том, кто что помнит. Запись агента без происхождения относится ко второму случаю, хотя выглядит как первый.

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

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

Весь паспорт нужен далеко не везде. Но два вопроса обязательны для любой записи, по которой собираются действовать. Откуда это взялось и кто это подтвердил.

Как догадка одного агента становится фактом

Что бывает с записью без этих двух ответов, хорошо видно на цепочке из той же статьи о памяти компании. Первый агент прочитал три комментария и решил, что обнаружил рыночный тренд. Второй нашёл эту запись и использовал её как подтверждённый факт. Третий построил на ней рекомендацию клиенту. Догадка по трём комментариям дошла до клиента как позиция компании, и ни один человек её не принимал.

Ни один агент в этой цепочке не обманывал. Каждый добросовестно опирался на то, что нашёл в памяти. Ошибка сидит в самой записи: по ней не видно, что это догадка по трём комментариям. Будь у неё статус “гипотеза” и ссылка на эти комментарии, второй агент увидел бы, на чём она держится, и цепочка оборвалась бы на нём.

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

Главной для любой работы с агентами я считаю одну формулировку из той же статьи. Право найти информацию, право считать её истинной и право действовать на её основании Пименов называет тремя разными полномочиями. Найти запись агент может сам. Считать её истинной можно, когда видно, кто её подтвердил. Действовать по ней, особенно если это увидит клиент или заказчик, стоит только после того, как это решил человек.

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

Представим запись годичной давности: “Заказчик против размещения в облаке”. Год назад так и было, потом у заказчика сменилась политика, а запись осталась. Агент, который готовит новое предложение, честно её находит и закладывает в расчёт собственные серверы. Ошибка ничем не выдаёт себя, потому что запись была правдой, когда её делали.

Когда хватает заметок и поиска

Всё это звучит тяжело, и для одного человека во многом избыточно. Я веду решения по проектам в Obsidian и писал о том, как это устроено. Каждое важное решение живёт у меня в заметке-протоколе с тремя полями: к какому проекту оно относится, с каким запросом пришли на комитет или встречу и что в итоге решили. Заметка привязана к карточке проекта, поэтому вся история решений по нему собирается одним запросом.

Происхождение у такой записи заложено в сам документ. Это протокол комитета или встречи, и все важные протоколы проходят через моё согласование. На вопросы “откуда” и “кто подтвердил” отвечает сам протокол.

Цена у схемы тоже есть. Пропустил поле проекта, и заметка выпала из всех запросов, как будто её не существует. Структура держится только на моей дисциплине.

Если к таким заметкам подключить агента, одному человеку обычно хватает того, чтобы агент показывал исходную строку, а не пересказывал её. Так устроен, например, Echo, бесплатный MCP-сервер для папки markdown-заметок. Агент получает от него исходный фрагмент с путём файла, заголовком и диапазоном строк и может сослаться на источник. На вопрос “какие компромиссы я фиксировал, когда выбирал стратегию кэширования” агент может ответить ссылкой на строки, которые человек когда-то написал сам, и проверить ответ можно, открыв файл.

Так где проходит граница? Проще всего провести её по размеру команды: одному хватит заметок, а десяткам агентов нужен паспорт. Но размер здесь ничего не решает. Решает, кто ещё читает запись и действует по ней. Пока записи пишет и читает один человек, о происхождении многих он помнит сам, а остальное видно из документа. Как только запись попадает к тому, кто не видел, как она появилась, ему нужно, чтобы это было написано в ней самой.

Таким читателем может оказаться коллега, другой агент или та же модель в новом чате. Даже один человек, у которого два агента передают друг другу работу, уже живёт по правилам команды. Скажем, первый агент разбирает документы проекта и пишет по ним записи, а второй готовит из этих записей отчёт для заказчика. Второй не видел, как появилась запись первого, и знает о ней ровно то, что в ней написано. Если первый записал “архитектура согласована”, прочитав черновик протокола, второй так и напишет заказчику.

Кто переводит запись в решение

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

Статусы “подтверждённый факт” и “решение” ставит человек, и лучше тот, кто это решение принимал. Свой вывод агент в факт сам не переводит. В цепочке из трёх агентов не хватило именно этого правила, ведь второй агент сам повысил чужую догадку до факта.

У каждой записи, по которой собираются действовать, есть ссылка на исходник. Это письмо, протокол, файл или строка заметки. Запись без ссылки остаётся пересказом, и читать её надо как пересказ. На комитете никто не примет решение по фразе “кто-то говорил, что подрядчик согласен”. Запись агента без ссылки звучит ровно так же, только напечатана аккуратнее.

Возьмём ту же запись о подрядчике. Статус у неё “наблюдение”, ссылка ведёт на письмо менеджера подрядчика, и в графике её пока не учитывают. Решением она станет, когда руководитель проекта получит подтверждение от того, кто вправе его дать, и сам поставит отметку. Почти всю работу сделал агент, который нашёл письмо, вытащил суть и связал её с поставкой. От человека потребовалось одно действие, но только после него по записи можно перестраивать график.

У временной записи есть условие и дата проверки. Решение “пока не трогаем Elasticsearch” записывают вместе с условием, при котором к нему вернутся, и с датой, когда проверят, не наступило ли оно. Когда дата наступает, запись подтверждают заново или закрывают. У записи “не делаем никогда” стоит ещё и имя того, кто так решил. Такие записи переживают людей, которые помнили причину. Через два года фраза “с этим подрядчиком больше не работаем” без имени превращается в легенду, а с именем это вопрос, который можно задать конкретному человеку.

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

Нового в этом порядке почти ничего нет. Перед нами тот же протокол комитета, только записи ведёт агент, и ведёт быстрее и подробнее, чем успел бы человек. Помощь настоящая, и отказываться от неё незачем.

Вспомним, где у разработчика с Хабра хранилось “мы это уже обсуждали”: в нём самом. Хорошая память агента забирает у человека почти весь этот груз. Остаётся одно, и отдавать его не стоит: решение, что запись верна.