14 октября 2026 г.
За последние полтора года я бок о бок работал с CTO компании Postman Анкитом Собти (Ankit Sobti) над платформой агентов, которую мы используем для развертывания всех наших внутренних агентов в процессе трансформации компании в AI-native. Это продолжение его статьи обAgentic OS, которую мы создали; в ней рассказывается о бизнес-потребностях, приведших нас к этому, об архитектурном обзоре и техническом фундаменте, сформировавшем наше видение. В этой статье я обсужу круг проблем, связанных с созданием агентов для корпоративного сектора, в частности для не поддающихся формальной проверке качественных доменов (не программирование/математика), наш подход к их решению и оставшиеся открытые вопросы. Надеюсь, это послужит полезным руководством для инициативных инженеров или инженерных лидеров, стремящихся возглавить подобную работу.
Контекст
Я пришел в Postman после работы в стартапе. Существует стереотип, что технические фаундеры предпочитают решать проблемы с помощью кода, а не общения с клиентами. К сожалению, эти стереотипы порой оказываются правдой. Не имея продавцов и бюджета, я тоже гнался за мечтой о продукте, который продвигает сам себя с помощью самодельных инструментов аутрича на базе LLM, но на собственном горьком опыте усвоил, что никакой объем автоматизированного выхода на рынок (GTM) не поможет вырасти тому, у чего нет рынка. Придя в Postman, я целенаправленно искал противоположную проблему. Postman уже достиг 40 миллионов пользователей за счет प्रोडक्ट-ориентированного роста (product-led growth). Таким образом, главной задачей было просто конвертировать возрастающую часть этих существующих пользователей в платящих клиентов за счет реальной ценности для бизнеса, а также продолжать формировать продукт на основе того, что они рассказывали нам о своих новых потребностях в области ИИ.
Я помог основать нашу команду инженеров передового развертывания (FDE), написал ее первый регламент и выпустил наши первые крупные релизы, что привело к значительному многомиллионному росту годового регулярного дохода. Хотя нам удалось достичь отличных результатов с этими отдельными клиентами, стоящий за этим процесс не поддавался масштабированию. Мы полагались на интуицию наших руководителей при выборе правильных аккаунтов. Мы могли прослушать лишь ограниченное число звонков, прочитать определенное количество писем, продуктовой телеметрии и тикетов поддержки по каждому из них, и даже то, что мы читали, упускало контекст, который хранился исключительно в головах команды по работе с клиентами, вне наших систем учета. Заполнение пробелов означало проведение дополнительных исследований по графику клиента, а все, что мы узнавали, не доходило до продавцов, поэтому даже решенная нами проблема возвращалась к нам снова.
Все, что нам было нужно, — это GTM-машина, которая неуклонно набирает обороты. Все, что мы знаем о клиенте, должно храниться в наших системах учета, а машина должна считывать все это и подсказывать нашим сотрудникам, к каким аккаунтам обращаться, с чем именно и что попросить команду основного продукта или FDE изменить в нашем продукте. Все, что наша команда создала однажды, должно стать тем, что продавцы смогут продавать самостоятельно, что освободит FDE для финального этапа нестабильной инженерии. Каждый раз, когда наши сотрудники действовали на основе указаний машины, результат превращался в новые данные, благодаря чему ее следующая рекомендация становилась более точной. Она также должна быть достаточно дешевой в обслуживании для каждого аккаунта каждую неделю и продолжать работать по мере изменения лежащих в ее основе моделей и данных.
Поэтому я снова попытался автоматизировать выход на рынок. На этот раз у меня было преимущество в виде продукта, который уже нашел свой рынок. Моя наивность, обусловленная стартапным прошлым, относительно ускорения сферы, которая всегда строилась на интуиции и отношениях в масштабах предприятия, сдерживалась фаундерами наших инструментов для разработчиков, которые разделяли мой розовый взгляд на то, что мы должны быть одержимы ИИ (AI-pilled) и применять агентное мышление за пределами разработки ПО. Усвоив урок, я хотел взять лучшее как от людей, так и от ИИ, и все свелось к одному принципу.
Абстрактно
Рис. 1: Кольцо людей образует единственную границу, с которой соприкасается клиент, а внутри него скрывается плотная зеленая сеть анализа.
Максимум человеческого фактора в внешних коммуникациях. Максимум ИИ во внутреннем анализе. Таким должен быть цикл самосовершенствования любого предприятия.
Максимум человеческого фактора в внешних коммуникациях. Максимум ИИ во внутреннем анализе. Таким должен быть цикл самосовершенствования любого предприятия.
Начнем с внешней половины. Насколько это возможно, каждый клиент должен чувствовать, что его проблему услышал неравнодушный человек и что решение было создано под его конкретный сценарий использования. В наших крупнейших аккаунтах насчитывается в среднем 45 заинтересованных лиц, указанных в сделках, а средняя продолжительность отношений составляет около трех лет, поэтому поддержание прочности этих отношений — одно из лучших применений времени наших людей. ИИ может справляться с простыми вещами, такими как ответ службы поддержки в полночь или автоматизированный процесс онбординга. Но ИИ-аватар на звонке по продажам или массово сгенерированное холодное письмо, вслепую угадывающее проблемы клиента, обесценивают бренд, и это совсем не то, что значит быть одержимым ИИ.
Внутренняя половина — идеальное место для одержимости ИИ. Вам нужно, чтобы решения принимались с такой скоростью, пропускной способностью и точностью, с какими ни один человек не может справиться ментально, и причина этого биологически обусловлена. Исследования рабочей памяти показывают, что мы можем одновременно удерживать в фокусе внимания лишь около четырех «чанков» (осмысленно сгруппированных кусочков информации) (Cowan, 2001), где в нашем случае 1 звонок будет примерно равен 1 чанку. Даже для одного крупного аккаунта за год может набраться сотки звонков и тысячи писем. Что еще хуже, самые эффективные инсайты часто носят тематический характер для разных аккаунтов, и объем может достигать значения {звонки, письма, телеметрия, поддержка, документация и т. д.} × годы × аккаунты. Это терабайты данных, которые ни один человек не способен удержать в голове, пытаясь выстроить самую эффективную логическую цепочку по всем этим точкам данных.
Рис. 2: Каждая ячейка представляет собой годовой архив записей одного аккаунта. Зеленый путь связывает точки данных, которые анализирует агент на пути к ответу, а небольшая рамка показывает, как мало из этого один человек может удерживать в голове одновременно.
Возьмем продавца, который хочет связаться с каждым клиентом из своей базы, кому может пригодиться что-то из того, что мы недавно выпустили. Чтобы сделать это качественно, нужно изучить информацию по каждому аккаунту, и при наличии пары сотен аккаунтов у каждого на это попросту не хватит времени в неделе. Здесь важна синхронизация, поскольку передовой край движется быстро, а функции устаревают. Агент может пройтись по каждому аккаунту за них, вычленить то, что имеет значение для каждого конкретного случая, и применить ко всем им стратегии, с помощью которых наши лучшие продавцы уже добились успеха. Затем продавец может написать каждому клиенту и адаптировать сообщение для нужного ЛПР, точно описав, какую пользу оно принесет.
По мере того как мы обретаем все большую уверенность в стратегиях, используемых нашими лучшими продавцами, мы можем поручать агенту выполнять все больше этой работы автономно. Вопросы, которые продавцы задают снова и снова, превращаются в навыки, навыки, которые они запускают каждую неделю, превращаются в запланированные отчеты, и в конечном итоге агент сохраняет собственную память по каждому аккаунту, задавая вопросы, которые он считает важными для выполнения наших ключевых показателей эффективности (KPI).
Чтобы приблизиться к созданию агента, способного выполнять больше задач самостоятельно, мы можем обратиться к тому, как в разработке ПО решалась проблема уровней абстракции. Когда-то инженеры писали машинные инструкции вручную, пока эту работу не взял на себя ассемблер. Затем компиляторы позволили им писать на удобочитаемых языках, таких как C, а объектно-ориентированные языки вроде Java дали возможность объединять данные с кодом, который с ними работает, чтобы строить крупные системы из повторно используемых компонентов. Эта лестница работала, потому что каждая ступень сочетала в себе генерацию и верификацию. Генерация означала, что инструмент мог создавать результат на новом уровне. Верификация означала, что инженеры могли проверить его правильность. Компилятор выдает один и тот же результат при получении одного и того же кода и отказывается собирать код с целыми классами ошибок, поэтому инженеры могли доверять каждой ступени и строить на ней следующую.
В качественных доменах до появления ИИ не было ни автоматизированной генерации, ни верификации. Корпоративные процессы Go-To-Market (GTM) — один из таких качественных доменов. Ответы на вопросы вроде «Какова оптимальная стратегия продажи функции продукта Y клиенту X?» носят открытый характер и не имеют единственно правильного ответа. Раньше было невозможно автоматически сгенерировать ответ о следующем шаге по учетной записи без участия человека — Account Executive. Теперь агент с набором инструментов генерирует ответ на основе подмножества данных, которые он находит во время выполнения. Однако по-прежнему сложно понять, достиг ли агент оптимального подмножества данных по сравнению со всем их глобальным массивом. Нашел ли он тот самый звонок, где обсуждалась новая стратегия в области ИИ? Посмотрел ли он на ту единственную точку данных в телеметрии продукта, которая показывает, что они действительно использовали вашу новую функцию, но необычным способом? Верификация остается открытой проблемой. Мы ее не решили, но каждый подход, который для нас сработал, начинается одинаково: с разбиения задачи на более мелкие, проверяемые части.
Рис. 3: Каждая подкрепленная ступень ПО соединяется с проверкой — от оборудования до тестов, в то время как ступени выше линии, такие как следующий шаг по учетной записи, обрываются без проверки.
Я решил, что аспект генерации достаточно перспективен, чтобы развивать его дальше, и начал с GTM-коучинг-агента, который отвечает на вопросы наших продавцов о клиентах на основе тысяч записанных с ними звонков. Как и любой традиционный агент, он начинался с модели, системного промпта, определяющего его роль, и инструментов, возвращающих данные. Все это работало в среде выполнения, которая принимает вопрос и циклически повторяет процесс, пока не получит ответ. Со временем это переросло в платформу ускоренного развертывания агентов, которая теперь позволяет быстро запускать агентов для любого конечного пользователя в компании. С конца мая почти 400 сотрудников использовали их — от продавцов и руководителей до продакт-менеджеров, маркетологов и инженеров — через Slack, веб-интерфейс, MCP и командную строку. Агенты используются как для ответов на запросы, так и для проактивной отправки отчетов и оповещений. Только коучинг-агенты охватывают практически всех наших продавцов (около 220 человек в месяц), и им было задано почти 10 000 вопросов. Ежемесячный объем вопросов вырос на 76% с июля по сентябрь при показателе удержания 80% и сильном степенном распределении использования: каждый десятый пользователь задал более 100 вопросов.
Быстрый запуск агентов и предоставление ответов оказались самой легкой частью создания этой платформы. Помимо верификации, необходимой для того, чтобы со временем улучшать агента, серьезным препятствием было привлечение нужных людей к работе над теми частями агента, в которых они разбираются лучше всего. У каждой команды есть свои цели, стимулы, определение хорошего ответа и собственное мнение о том, кому какие данные должны быть доступны, и каждая из них права по-своему, поэтому мы изначально не собирались писать агентов за них извне. Платформа работает потому, что каждая команда пишет только ту часть, которую понимает, а все остальное находится в общей инфраструктуре, которую мы поддерживаем для них. Агент становится конфигурацией общего объекта, а не чем-то совершенно новым, поэтому каждое улучшение инфраструктуры автоматически применяется к каждому агенту, который на ней базируется. Именно это позволяет GTM-механизму развиваться по нарастающей.
Рис. 4: Четыре агентские команды различаются по структуре, а также по промптам, инструментам, данным, защитным механизмам и настройкам доступа, но при этом все они опираются на единую общую инфраструктуру, которая совершенствуется под ними.
1. Каждый создает своего агента
Создание агентов внутри компаний достигло небывалого накала, поскольку любой, кто умеет писать инструкции и подключать источник данных, теперь может создать агента. Даже внутри одной команды несколько человек создают агентов, у которых общие функции, конечные пользователи и источники данных. Никто не хочет, чтобы их агент просто бездействовал на ноутбуке, поэтому они спешат предоставить его остальным. К сожалению, у всех остальных возникает та же идея, и они запускают свои разработки в ответ. Каждая из таких инициатив развертывает собственный пайплайн поверх одних и тех же данных, поэтому каждый новый агент оставляет где-то копию записей о ваших клиентах с меньшим контролем, чем предыдущий. Эти пайплайны остаются без присмотра в тот момент, когда истекает срок доступа или меняется зависимость, и именно тогда агент начинает уверенно отвечать на основе данных, которые перестали обновляться несколько недель назад. Существует две распространенные попытки решить эту проблему, и обе поначалу кажутся эффективными.
Первая попытка — позволить доменной команде или отдельному человеку создать агента самостоятельно. Наши продавцы сделали это через Claude Desktop, вручную настраивая коннекторы. Это позволяет запустить систему за полдня, причем разработчик понимает свой собственный рабочий процесс лучше, чем любая команда платформы. Чего вы не можете сделать, так это масштабировать решение на всю команду и управлять им на глобальном уровне. Результаты сильно различались у разных продавцов, поскольку каждый из них писал разные инструкции и подключал разные наборы источников, поэтому два продавца, спрашивающие об одном и том же клиенте, могли получать ответы, основанные на кардинально отличающихся данных. Когда руководство хотело, чтобы каждый агент задействовал новую схему продаж, ее просто некуда было внедрить. Она существовала в виде презентации, а агенты работали в рамках отдельных сеансов, поэтому ни один из них так и не получил к ней доступ, а создаваемый нами механизм как раз и зависит от наличия такого общего контекста. Тот же пробел проявляется в том, как они воспринимают данные за чистую монету. Если клиент говорил, что продукт слишком дорог, агент советовал продавцу предложить скидку. Это редко бывает правильным ответом, поскольку любой клиент любого продукта в любой индустрии может попросить скидку, независимо от того, приносит ли продукт ему пользу. То, что на самом деле нужно продавцу, — это намек на необходимость повторно квалифицировать ЛПР или сместить фокус внимания обратно на тот результат, который приобретает клиент. Это стратегии, которые выработали наши опытные продавцы и руководители, и у персонального агента нет возможности их получить.
Рис. 5: Шесть продавцов подключили к своим агентам разные наборы источников, а новая схема продаж остается в презентации, до которой ни один агент не может добраться.
Вторая попытка заключается в том, чтобы передать работу команде развернутых на передовой или прикладных специалистов по ИИ. Это квалифицированные разработчики программного обеспечения и систем, которые научились работать с ИИ. Объединившись в небольшую команду, они могут вручную создавать по одному агенту под каждый внутренний сценарий использования. Это решает проблему управления, поскольку эти инженеры владеют единственной копией каждого агента, развернутого для команды, так что одно изменение доходит до всех, кто им пользуется. Чего это не решает, так это всего, что идет после первой версии. Каждый агент изготавливается на заказ, поэтому его некому передать обратно, и он остается у тех, кто его создал. Каждый выпущенный агент превращается в нечто, что кто-то должен поддерживать в рабочем состоянии, а внесение одинаковых исправление в каждого выпущенного агента — не самое эффективное использование времени квалифицированного инженера.
Рис. 6: Инженеры добавляют одну и ту же новую тактику в четыре кастомных агента по очереди, а четвертый, подготовка к переговорам, все еще ждет своей копии.
Как только несколько таких агентов оказались рядом, стало очевидно, что они представляют собой вариации одного и того же ограниченного списка. Агент — это системный промпт, подмножество инструментов и источников данных, которые вы уже подготовили, модель и бюджет времени, в течение которого ей разрешено думать, горизонт выполнения, определяющий, отвечает ли агент по запросу или работает по расписанию, набор защитных барьеров и правило о том, кто может его вызывать и какие поля ему разрешено читать. И этот список всегда можно расширить по мере обнаружения новых примитивов, которые вы хотите внедрить во всех своих агентах.
Нам нужно, чтобы платформа была настраиваемой, чтобы каждый из заинтересованных участников в компании мог написать ту часть агента, которая относится к нему, остальное оставив другим. Контроль доступа — жесткие детерминированные правила, определяющие, кто к какому агенту и каким полям данных может получить доступ, — лучше всего контролировать силами ИТ-отдела. Системный промпт лучше всего писать профильной команде, так как они знают свой собственный рабочий процесс и то, что они хотят от агента в рамках своих задач. Защитные барьеры — мягкие управляющие маркдаун-инструкции, которые удерживают агента от нежелательного поведения, о котором узнаешь только после его развертывания, — лучше всего писать руководителю. Вместо того чтобы одна из этих команд писала каждый компонент или чтобы внешняя команда инженеров угадывала их все, каждый компонент определяется людьми, которые ближе всего к нему находятся. Команда платформы агентов может просто работать над улучшением общей основы.
Рис. 7: Каждый медведь, созданный одной командой, ломается по-своему, а объединенный медведь берет контроль доступа, промпт, среду выполнения и защитные барьеры у команды, которая ближе всего к каждому из компонентов.
2. Развертывание каждого агента из монорепозитория
Чтобы обеспечить универсальные решения для функциональности, которую платформа не поддерживала из коробки, мы позволили разработчикам агентов писать кастомный код поверх того агента, которого они обслуживали. Этот код оказался именно тем сигналом, который нам был нужен. Когда наши инженеры обнаружили, что пишут патчи одинаковой формы в третий или четвертый раз, эта форма получила повышение: она стала полем, которое любой агент может объявить в своем манифесте вообще без какого-либо кода.
Каждый агент написан в едином монорепозитории, который развертывается при слиянии PR (пулл-реквеста). Агент представляет собой каталог. Все, что относится конкретно к этому агенту, находится внутри него. Две папки, общие для всех агентов, находятся за его пределами: глобально подготовленный набор инструментов, подмножество которого указано в каждом манифесте, и защитные барьеры, в которых указаны агенты, к которым они применяются. В приложении приведен пример каждого из этих элементов.
Рис. 8: Помимо своего файла SKILL.md, каждая настройка в deal-coach-pro представляет собой выбор из фиксированного набора, включая 52 из 54 инструментов и 32 из 45 защитных барьеров.
Когда дело дошло до развертывания, нам потребовался механизм, который позволял бы разработчикам агентов быстро развертывать своих агентов, не выводя из строя общую инфраструктуру. Astropods, наша платформа для развертывания и управления агентами, сделала это очень удобным. По своей сути это обычный Docker. Каждый агент собирается из одного и того же Dockerfile с тем же контекстом сборки (весь бэкенд), поэтому инструкция COPY . . встраивает каждый навык в образ. Каждый агент затем содержит манифест — короткий YAML-файл, в котором указывается этот Dockerfile и объявляются переменные окружения, необходимые для его контейнера. Одной из таких переменных является имя каталога навыков для обслуживания. Адаптер считывает ее при загрузке и обслуживает только этот каталог, что означает: кодовая база является артефактом, а переменная — указателем: каждый под запускает одно и то же дерево с подсвеченным внутри него разным путем.
Рис. 9: Переменная SKILL_NAME активирует каталог deal-coach/ и указанные в нем общие файлы, инструменты и защитные барьеры, при этом каждая серая запись поставляется в том же образе без загрузки во время выполнения.
3. Достижение результатов с большим горизонтом на скорости выполнения
Одно свойство было общим для всех наших агентов: чем дольше мы позволяли выполнению продолжаться, чем больше токенов мы давали ему сжечь и к какому большему объему данных мы предоставляли ему доступ, тем лучше были результаты. Это, пожалуй, микрокосм «Горького урока» Ричарда Саттона, который утверждает, что масштабные вычисления сводят на нет алгоритмическую итерацию на последней миле. Ограничение при создании агентов времени выполнения, подобных описанным выше, заключается в том, что пользователи ожидают ответа в разумные сроки — около двух минут.
Рис. 10: В пределах двухминутного окна ручная настройка дает лучший ответ, но после точки пересечения большее количество токенов и более длительные запуски продолжают улучшать результат задолго после того, как ручная настройка перестает давать эффект.
Вы можете дать им возможность настроить задачу, которая выполняется намного дольше — десять минут или более (и мы так сделали), но это влечет за собой собственный набор проблем. Во-первых, если все начнут запускать ресурсоемкие задачи по своему усмотрению, расходы на токены выйдут из-под контроля. Во-вторых, вы мешаете вашим пользователям глубоко погружаться в рабочий процесс и доходить до понимания более высокого порядка. Когда ответы приходят быстро, они продолжают погружаться в суть проблемы, и общее использование инструмента растет экспоненциально. Это также можно рассматривать сквозь призму парадокса Джевонса, который гласит, что чем дешевле вы что-то делаете, тем больше этого люди используют, за исключением того, что на предприятии то, что ваши сотрудники пытаются сберечь — это часто не затраты, а их собственное время. Так что если они считают, что это экономит им реальное время, и этого времени у них в избытке, они будут использовать инструмент чаще, что повышает их общее потребление ИИ и стимулирует вашу трансформацию.
Нам нужно было найти способ предоставить преимущества более длительных задач, сделав при этом вывод во время выполнения быстрым и дешевым. Нам нужно найти способ для ИИ-агента выяснить, какие части информации имеют наибольшую ценность для учетной записи, и обновлять их по мере поступления новой информации каждую неделю. «Наибольшая ценность» — это расплывчатый термин, специфичный для потребностей вашей компании, поэтому для фильтрации нам потребуется еще один вероятностный агент, управляемый подсказками (промптами), чтобы отфильтровывать большой объем поступающей информации. Я обсужу два подхода, которые я здесь применил: обвязку (harness), позволяющую агенту рекурсивно и параллельно порождать субагентов для более качественного исследования учетной записи, и второй подход — собственный примитив «сновидений» (dreaming primitive) от Anthropic. Первый был создан вручную до появления второго, но с тех пор оба доказали свою пользу.
Рис. 11: Потоки данных поступают в течение всей недели, и один агент, определяемый своей моделью, промптом, инструментами и бюджетом токенов, отбирает несколько элементов, которые заполняют документ по учетной записи.
Первый собственный метод — это то, что мы называем конвейером исследований, который запускается раз в неделю на 8 часов. Каждый процесс исследования учетной записи начинается с детерминированного набора вызовов API, который вытягивает все новые данные с момента запуска на прошлой неделе из каждого из наших API данных в общее хранилище. Сюда входят запись в Salesforce, ее возможности, план счета и роли контактных лиц, а также расшифровки всех звонков в Zoom, телеметрия продукта и тикеты поддержки. Отсюда пакетками по 4 порождаются 24 субагента, которые используют это хранилище в качестве основы, чтобы решить, какие ветки они хотели бы исследовать дальше. То, что они ищут, определяется субагентом заранее и зависит от того, что они видят в основе, что вернули агенты из предыдущих пакетов, а также от ключевых принципов, важных для команды по работе с клиентами (риск оттока, путь расширения, карта стейкхолдеров, препятствия для внедрения, недавние настроения клиента). Каждый из этих субагентов анализирует вызываемые им инструменты, пока не найдет то, что искал, или пока не исчерпается бюджет токенов.
Путь, который каждый из них проделывает через данные, очень напоминает обход графа, потому что на каждом шагу агент может двигаться вертикально — глубже в тот же источник — или горизонтально — к другому источнику. Например, он может читать фрагмент звонка в Zoom, где клиент говорит, что какая-то функция больше не работает для него, и пойти вертикально назад по более ранним звонкам, чтобы увидеть, отключали ли они ее, или горизонтально в телеметрию продукта, чтобы проверить, пользуются ли они ей вообще. В итоге он делает комбинацию горизонтальных и вертикальных шагов, что напоминает поиск A*, за исключением того, что эвристикой является вероятностная оценка модели того, принесет ли вызов инструмента ценность, в то время как в A* использовалась бы детерминированная функция. В конце каждый агент возвращает свои находки более умной модели с большим контекстом, которая синтезирует точки данных и пишет подробное досье на учетную запись. Это досье сохраняется в реляционной базе данных, а также внедряется в векторную базу данных. Оно доступно в качестве инструмента во время выполнения, и агенту в определении инструмента и системном промпте указано отдавать ему предпочтение, поскольку, если оно содержит ответ на заданный вопрос, тратить токены на запросы к исходному источнику данных больше не нужно.
Рис. 12: Исследовательские субагенты обходят исходные данные, углубляясь или переходя к другим на каждом шаге, а их выводы объединяются в единый синтез, формирующий досье.
Хотя конвейер исследований — это наша лучшая попытка предоставить агентам наиболее эффективную аналитику во время выполнения, Anthropic выпустила концепцию Dreaming как примитив для непосредственного управления памятью агента. Создание собственной системы делает управляемую память независимой от конкретной модели. Использование API «черного ящика» для dreaming имеет смысл по противоположной причине. Провайдер модели с наибольшей вероятностью знает, какая обвязка лучше всего структурирует информацию, чтобы их собственная модель извлекала ее так, как вам нужно, во время выполнения.
Учитывая это, я настроил второй конвейер параллельно, на базе Dreams. Чтобы понять концепцию Dreaming от Anthropic, нужно начать с их управляемых хранилищ памяти.
Рис. 13: SQL-запрос возвращает одну строку Acme, а поиск по вложениям — четыре фрагмента по онбордингу, но фрагмент с обзором безопасности, содержащий ответ, оказывается вне зоны действия обоих.
Рис. 14: Агент перечисляет все файлы, ищет с помощью grep упоминания развертывания, сужая их до трех, а затем читает timeline.md, который указывает на security-lead.md — файл, который grep никогда не находил.
