Итак, реальная проблема: Для индексации динамически меняющихся файлов памяти (обычный markdown) необходимо стандартизировать данные для записи в Postgres с возможностью последующей фильтрации по некоторым полям
Казалось бы — отдай задачу нейросети. Она стандартизирует и добавит. А если таких задач 200+ и они вызываются ежедневно? Кто даст гарантию, что ветер подует в правильном направлении и, как следствие, стохастика модели каждый раз сработает ровно так, как нужно? Гарантия лишь в том, что умная модель догадается, что мы хотим получить
Так вот, можно сделать стандартизацию через скрипты-чекапы. Дать модели доступ к вызову скриптов. Описать что модель должна подать на вход и что получит на выходе
Логика очень простая. Но в чем инсайт? Инсайт в том, что ровно по такой логике работают MCP (есть скрипт и есть его описание; объединили несколько скриптов в предметной области — получили MCP) и, как мне кажется, подкапотные вызовы first-party тулзов. Например, по записи/редактированию файлов, — модель не может изменить файл, не прочитав его, даже если на 100% уверена в его содержимом: скрипт просто выдаст ошибку редактирования файла. Тулзы нужны для создания возможностей – что именно модель может использовать. Но как это использовать – это уже наша задача ей объяснить
В случае с постгресом — мы пишем скрипт, какие [мета]данные обязательно должны быть отражены в md-файле (файле памяти), чтобы корректно распарсить и импортировать этот файл в бд
Рядом со скриптом пишем скилл. В скилле описываем как работать со скриптом и как обобщённо-правильно фиксить непройденные проверки. Получился очень упрощенный MCP. Можно сказать, аналог first-party тулзов:
$dreams завершён и запушен.
Обработано и архивировано 24/24 draft из инвентаря: ...
Проверки прошли: proposal artifacts 5/5, ledger/proposal/diff/evidence validation, redaction, allowlist, Dreams helper tests, two gbrain sync passes, indexed timestamp stamping, target-slug get_evidence, semantic query with embedding_hnsw, query_scan, temporal searches, final staged guard
После этого у меня сложился пазл. Ведь скрипты с дополнительными проверками относятся не только к нейросетям. К этому же относится и ruff и тестирования продуктов с предкоммитными/регрессионными проверками. По сути взяли тот же механизм. Возвели из него абстракцию. Перенесли на любую другую область – тем самым избавились от предполагаемой недетерминированности