Что значит «агент работает». Прогон — это агентный цикл: платформа собирает промт, отдаёт его chat-модели с тремя инструментами к знаниям, и модель сама ведёт ход — думает, зовёт инструмент, читает результат, повторяет — пока не соберёт ответ. Не workflow-конструктор и не одиночный RAG-вызов: где кончается один вызов поиска и начинается полный цикл — граница с Query Engine. Под чьими правами идёт чтение — держит личность агента.
Перед каждым прогоном платформа собирает промт по слоям, в строгом порядке. Первым ложится платформенный prompt: безопасность и правила организации, единые на все AI-вызовы; им владеет Admin Panel, не автор агента. На него — промт агента: задача, тон, что искать. Замыкает инженерный слой: привязка личности и описания инструментов. Сотрудник правит только свой слой; правила платформы промтом не перебить.
порядок задаёт движок, не владелец: правила платформы промтом не перебить, результаты инструментов идут как данные, не команды. Личность так же навязана извне цикла — её привязку задаёт Prompt-библиотека.
Собранный промт уходит chat-модели AI, и дальше ход ведёт она. На каждом шаге решает сама: позвать инструмент за фактами или уже формулировать ответ. Результат инструмента возвращается ей в контекст, и шаг повторяется. Сам tool-calling — не наш код: это общий харнесс, делимый с Query Engine; петля и потолок — агентная параметризация поверх него.
Модель прогона — та, что владелец выбрал из списка agent_models (поэтому модель агента должна уметь вызывать инструменты). Снял admin модель из списка — агент встаёт до смены на другую (модель как условие старта).
Потолок итераций — страховка одного прогона: платформенная настройка
(platform_settings.agent_iteration_cap, одно число на
организацию), не поле агента. Сколько прогонов сотрудник может позволить за неделю,
ограничивает отдельный
токен-бюджет.
Цикл идёт фоновой
полосой, отделённой от живого чата.
В руках у модели всегда — ядро из трёх инструментов к Knowledge Store, по намерению запроса. Поиск, обход графа и SQL — примитивы KS; агент их вызывает, а не реализует, и всегда под правами личности агента: видит ровно то, что видел бы владелец. Ядро locked — read-only, не отключается, есть у каждого агента.
Права режут выдачу на стороне KS, pre-filter'ом по ACL личности — не пост-фильтром в агенте. Один и тот же инструмент у двух сотрудников вернёт разное: каждый видит свой срез.
Пустая база — ядра нет производно. «Locked» значит «не
отключается вручную», а не «есть при любом состоянии базы». Когда искать
нечем (is_empty), общий
харнесс не подаёт
ядро — единообразно с чатом. Агент мягко деградирует: работает на
опциональных внешних инструментах, если они выбраны, иначе честно
сообщает, что данных нет. В гейт готовности пустая база не входит — старт она не гасит, как и
снятие добавленного инструмента; наполнится база — ядро вернётся само.
Поверх ядра владелец может доцепить опциональные read-only внешние инструменты — из тех, что разрешил админ в каталоге инструментов (выбор фиксирует agent_tools). Снятие такого инструмента — мягкая деградация: агент продолжает на ядре, в гейт готовности это не входит (в отличие от снятой модели, что гасит старт). Запись в инструментах и MCP-источники — v2.
Цикл кончился — финальный ответ модели ложится строкой в
журнал
прогонов вместе с расходом токенов и исходом
(succeeded / failed — в failed
попадает и прогон, упёршийся в потолок итераций). Это весь выход:
результат живёт в журнале и виден на экране агента. Никакой записи в
Knowledge Store агент не делает — чтение
строго
read-only.