Разработката на AI агенти получава хибриден модел за памет
OpenAI разработчиците получиха нов практически модел за разработка на AI агенти на 12 май 2026 г., когато MarkTechPost публикува подробно ръководство за автономен агент с хибридна памет, модулни инструменти и дългосрочно запаметяване. Това е важно, защото урокът излиза отвъд демонстрациите с промптове и показва точните компоненти, от които екипите имат нужда, ако искат агентите им да извличат факти, да извикват функции и да запазват решения между отделни сесии. Според изходната статия на MarkTechPost, дизайнът тръгва от абстрактни интерфейси и стига до работещ агент, който „управлява собствената си дългосрочна памет“.
Урокът на OpenAI показва модел за агент с хибридна памет
Основният ход в урока е прост: не третирайте паметта като една функция. Разделете я на семантично извличане, извличане по ключови думи и цикъл с инструменти, който може да действа върху това, което намери. В notebook-а embeddings на OpenAI поемат векторното търсене, rank_bm25 поема съвпаденията по точни термини, а Reciprocal Rank Fusion обединява двете класации в един резултат от търсене.
Харесвам този модел, защото решава проблем, който виждам в реални внедрявания: паметта само с вектори изглежда умна в демо, но после пропуска номера на поръчки, продуктови SKU кодове или точни имена на проекти в продукционна среда. BM25 хваща буквалния низ. Embeddings улавят перифразата. Заедно дават по-стабилно припомняне.
Това прави агента и нещо повече от обвивка около чат. Кодът му дава инструмент memory_store, инструмент memory_search, калкулатор и симулирано уеб търсене. Това е базовата форма на персонализирани AI агенти, които трябва да вършат работа, а не просто да отговарят на въпроси.
Защо модулните интерфейси са важни още преди първото извикване на инструмент
Най-силното инженерно решение в notebook-а не е трикът с паметта. То е разделянето на отговорностите. MemoryBackend, LLMProvider и Tool са абстрактни интерфейси, така че основният цикъл не се интересува дали паметта днес е в Python списъци, а следващото тримесечие ще е в управлявана векторна база данни.
При един клиентски проект миналия месец установихме, че първата версия на вътрешен агент смесваше логика за инструменти, API retry механизми и форматиране на разговор в един файл. Всяка промяна чупеше нещо друго. Модулните договори забавят старта в първия ден, но излизат по-евтино до третия месец. Това е разликата между демо и поддържана архитектура за AI интеграция.
Изходният урок следва тази дисциплина чисто. Python SDK на OpenAI обработва извикванията към модела, NumPy поема нормализирането на векторите и cosine scoring, а BM25 се изгражда наново след всяка операция по запис. Ако по-късно замените това с по-новите developer patterns на OpenAI за tool calling, останалата част от дизайна може да остане почти непроменена.
За екипи, които преминават от notebook към продукционна среда, следващата практична стъпка обикновено не е повече prompting. Тя е по-добър dispatch, мониторинг и интеграционна свързаност, затова този модел се връзва добре с услуги като AI DevOps workflow automation, когато целта е да се operationalise AI automation agents, а не да останат в лабораторията.
Какво демото доказва за готовността за продукционна среда
Notebook-ът изпълнява четири демонстрации и всяка тества различен оперативен въпрос.
Първо, предварително зарежда дългосрочната памет с потребителски предпочитания, факти за проекта, дати и номер на поръчка. Това е важно, защото много примери с агенти пропускат трудната част: качеството на паметта преди първото реално взаимодействие. Второ, изпълнява директни тестове за търсене като order 4821 и Alice's language preference, което показва защо хибридното извличане помага едновременно при точни идентификатори и неясно формулирано намерение. Трето, изпълнява многоходови разговори, в които агентът си спомня факти за проекта, изчислява оставащи часове и записва ново решение за storage engine. Четвърто, подменя уеб инструмент в runtime.
Последната част е по-важна, отколкото звучи. Подмяната на инструмент по време на изпълнение е реален модел за внедряване в enterprise AI solutions. Ако API за търсене промени ценообразуването, лимитите или латентността си, искате да подмените адаптера, без да пренаписвате ядрото на агента. Урокът демонстрира това със subclassed инструмент за уеб откъси.
Все пак остават очевидни липси преди реално внедряване: устойчиво съхранение, граници за достъп, логове за повторяемост, обработка на rate limits и evaluation. Notebook-ът използва състояние в паметта, а калкулаторът използва ограничен eval, което е приемливо за урок, но не е мястото, където бих спрял в продукционна среда.
Как хибридната памет комбинира вектори и търсене по ключови думи
Дизайнът на извличането е най-силният технически урок в статията. Класът HybridMemory съхранява embedding за всеки chunk и изгражда наново BM25 индекс от токенизиран текст. При търсене той изчислява cosine similarity за семантичните съвпадения, BM25 оценки за буквалните съвпадения, след което обединява ранговете чрез Reciprocal Rank Fusion.
Ако досега не сте внедрявали такъв тип извличане, ето практическата причина да работи. Семантичното търсене често пропуска точни токени с ниска контекстуална близост: номера на фактури, кодове за грешки, кратки акроними. Търсенето по ключови думи често пропуска перифрази: потребителят пита за „метода за репликация“, а записаният факт е „Raft consensus algorithm“. RRF дава глас на всеки метод, без да ви принуждава да настройвате ръчно крехко правило за тежести.
Този подход съвпада с това, което search екипите използват от години в други контексти. Elasticsearch документира BM25 като своята функция по подразбиране за релевантност, а хибридното извличане вече е обичайно в RAG стековете, защото търсенето само с вектори рядко е достатъчно. Насоките на Pinecone за retrieval и дизайн моделите на Microsoft за агенти водят в същата посока: смесвайте извличане и действие целенасочено.
Неочевидният оперативен детайл е цената. В примерния код всяко записано споменаване на памет задейства ново извикване за embedding и ново изграждане на BM25. Това е приемливо в notebook с едва седем факта. Става скъпо и бавно, когато агент записва стотици или хиляди събития на ден. За AI API интеграция в мащаб бих пакетирал embeddings, бих запазил векторното хранилище и бих обновявал индексите по ключови думи асинхронно.
Кога екипите трябва да изградят този модел вместо обикновен чатбот
Бих използвал тази архитектура, когато работният процес изисква едновременно три неща: постоянен контекст, използване на инструменти и възстановимо състояние. Добри примери са вътрешни support copilots, асистенти за операции, агенти за проучване на акаунти и workflow ботове, които трябва да помнят предишни решения. Именно в такива среди AI автоматизация на работни процеси печели от дългосрочна памет вместо от гигантски промпт.
Не бих започнал оттук за презентационен чатбот, едностъпков FAQ асистент или каквото и да е с ниска стойност на взаимодействията и без нужда от памет. В такива случаи по-просто RAG приложение се тества и поддържа по-лесно.
По-големият извод от този урок от май 2026 г. е, че разработка на AI агенти става по-модулна, а не по-магическа. Екипите се насочват към едни и същи градивни елементи: интерфейси, слоеве за извличане, схеми за инструменти и runtime контроли. Следете какво идва по-нататък около устойчивостта на паметта, evaluation и ops tooling, защото точно там все още стои реалната разлика между прототип и надежден агент.
Martin Kuvandzhiev
CEO and Founder of Encorp.io with expertise in AI and business transformation