AI Tender Radar собирает свежие закупки серверов, СХД и комплектующих, государственные и коммерческие, и присылает менеджеру по продажам ИТ-железа карточку на один экран в Telegram. Порога по цене нет, фильтр широкий; карточки приходят по будням в 9, 12 и 15 часов по Москве, а закупки с истёкшим сроком приёма не приходят вовсе. Автор описал систему в разборе на Habr, она работает в боевом режиме.
Внутри карточки четыре блока: потребность, заказчик, контакт и начало разговора. Агент сам никому не звонит и не пишет. Он готовит материал, а решение и разговор остаются за менеджером. Цен и возможностей продавца модель не знает, поэтому условий поставки в карточке нет.
Главная инженерная деталь спрятана в конце цепочки: перед сохранением карточки обычный код сверяет телефон, имя и почту с текстами, которые агент реально прочитал, и удаляет всё, что не подтвердилось. Это ответ на типичную проблему LLM, которая умеет правдоподобно собрать контакт из воздуха.
Что такое AI Tender Radar и какую задачу он закрывает
Задача будничная: менеджеру по продажам ИТ-оборудования нужно каждый день просматривать десятки закупок на серверы, СХД и комплектующие, читать технические задания на много страниц и отсеивать нерелевантное. AI Tender Radar делает первый проход. Собирает закупки, вытаскивает потребность из документов, добавляет финансовый контекст по заказчику и складывает всё в одну карточку. Государственные и коммерческие закупки идут в один поток.
Что внутри карточки в Telegram
Карточка умещается на один экран. Четыре блока, у каждого свой источник данных.
| Блок | Что внутри | Источник |
|---|---|---|
| Потребность | что закупают: серверы, СХД, комплектующие, с деталями из ТЗ | техническое задание закупки |
| Заказчик | выручка, прибыль и капитал за последний опубликованный год | отчётность ФНС |
| Контакт | телефон, а если нашёлся конкретный человек, его имя и роль | прочитанные агентом тексты |
| Начало разговора | подсказки для первого сообщения | контекст закупки |
Потребность берут из технического задания, а не из заголовка закупки: заголовок часто ничего не говорит о содержимом. Финансы по отчётности ФНС показывают масштаб заказчика и помогают понять, стоит ли тратить время на звонок. Контакт нужен, чтобы позвонить, а не вычитывать вручную весь пакет документов.
Под карточкой две кнопки: «В работу» и «Мимо». Заметку можно оставить ответом на сообщение в Telegram, а новые лиды и лиды в работе выгружаются в Excel. Условий поставки и коммерческих предложений в карточке нет: агент не знает ни цен, ни складских остатков продавца, это часть работы менеджера.
Кому и когда это полезно, а кому нет
Польза появляется там, где закупок много, а технические задания длинные и похожи по структуре. Если менеджер ежедневно вычитывает 20-30 пакетов документов и половину отбрасывает по названию, карточка на один экран экономит самый дорогой этап: первичный отсев и поиск контакта.
Ограничения начинаются с форматов. Сканы без текстового слоя, архивы RAR и старый формат XLS система не читает. Если весь пакет заказчика лежит в сканах, карточка выйдет неполной. Схема не подойдёт и тем, кто ждёт от агента автономной переписки или звонков: он только готовит материал.
Ещё один сценарий отказа: продажа сложного оборудования с индивидуальными конфигурациями. Агент вытащит потребность из ТЗ, но не посчитает смету и не сверит её с наличием на складе.
Почему автор отказался от конвейера в пользу агентного подхода
Первая версия AI Tender Radar была обычным конвейером. Документы проходили через модель по заранее заданным шагам: прочитай закупку, найди в ней контакт, если контакта нет, посмотри сайт заказчика, и так далее. Схема работает, пока реальность совпадает с ветвлениями, которые в неё заложили. На закупках с десятком вложений и разной структурой ТЗ ветвления начинают множиться.
Определения, на которые опирается автор, стандартные: цепочкой (workflow) называют систему, где шаги заранее прописаны в коде, агентом - систему, где модель сама решает, какой шаг сделать дальше. Так их разделяют Anthropic, OpenAI и LangGraph (разбор агентных подходов).
Чем цепочка отличается от агента на практике
Разница видна на поиске контакта. В конвейере правило «контакта нет, идём на сайт заказчика» живёт в коде: чтобы добавить ещё один источник, нужен релиз. В агенте порядок поиска описан текстовой инструкцией, а модель с набором инструментов решает, какие документы и страницы открывать. Инструкцию правят без переписывания кода, и это главный практический выигрыш.
Цена тоже понятная: меньше детерминизма. Один и тот же набор документов два запуска могут обойти по-разному, поэтому результат проверяют снаружи, а не надеются на воспроизводимость.
Read-only инструменты как способ ограничить риск
Агент в AI Tender Radar получает только инструменты чтения. Он не отправляет письма, не звонит и не меняет данные на площадках, а сохранение карточки и проверку контактов выполняет обычный код. Приём не уникальный: в других агентных системах агент получает статус заказа, правила и историю клиента, предлагает решение, но денег не двигает. Деньги двигает сага, обычный код, после проверки правил (пример такой схемы).
Из каких частей вообще собирается агентский каркас с инструментами и субагентами, видно на примере открытого терминального агента: разбор MiniMax Code показывает состав такого релиза и границы открытой версии.
Защита от выдуманных контактов: зачем телефон в карточке проверяет код
Модель собирает правдоподобный текст из ничего. Контакт, которого не было в документах, выглядит в карточке так же убедительно, как настоящий, а менеджер звонит по нему и теряет время. Поэтому в AI Tender Radar появился шаг, который к генерации отношения не имеет: детерминированная сверка (как она устроена).
Перед сохранением карточки обычный код берёт телефон, имя и почту и ищет их в текстах, которые агент реально прочитал. Что не подтвердилось, удаляется. После сверки карточка получает оценку A, B или C.
Как работает сверка и что она не ловит
Сверка идёт по текстам, прочитанным в этом запуске, а не по всей сети и не по базе прошлых закупок. Встретился номер в документе, он останется в карточке. «Вспомнил» модель контакт из общих знаний, в прочитанном его не будет, и поле вычистят.
Проверка отвечает на вопрос «это было в документе?», а не «это правильный контакт?». Совпадение цифр не гарантирует, что номер принадлежит нужному человеку: в ТЗ может стоять телефон отдела снабжения, общий номер call-центра или контакт из шапки бланка. Добавочные номера код не проверяет, поэтому многоканальный номер с добавочным уйдёт в карточку без уточнения.
Что означают оценки A, B и C для менеджера
Оценка служит сигналом уверенности в контакте, гарантией она не становится. Конкретные правила, по которым выставляются A, B и C, в открытых материалах не раскрыты, поэтому воспринимать их как строгую шкалу достоверности не стоит. Рабочая логика простая: чем выше оценка, тем меньше причин перепроверять номер перед звонком; при низкой оценке стоит сверить контакт с документами закупки.
Для менеджера это разница между «звоню сразу» и «сначала проверяю». Обе ситуации нормальные, плохо только одно: когда карточка выглядит одинаково уверенной всегда.
Ограничения подхода: где AI Tender Radar ломается
Слабые места лучше держать перед глазами до того, как строить похожую систему. Автор перечисляет их прямо, и список стоит прочитать целиком.
- Сканы без текстового слоя не читаются, файл помечается как пробел в данных.
- Архивы RAR и старый формат XLS не читаются.
- Совпадение цифр при проверке контакта не гарантирует, что номер принадлежит нужному человеку.
- Добавочные номера не проверяются.
- Цен и возможностей продавца агент не знает, поэтому условий поставки в карточке нет.
- Агентный подход не гарантирует полноту: если данных нет в прочитанных документах, карточка будет неполной.
Отдельно про неполноту. Агент обходит документы, которые смог открыть, и не знает о том, что осталось за пределами пакета. Пропущенное приложение или ссылка на внешний файл в карточку не попадут, и заметить это можно только сверкой с исходной закупкой.
Что делать с непрочитанными файлами
Непрочитанный файл не выпадает из процесса молча: он отмечается как пробел, и агент ищет сведения в других местах, например в других документах пакета. Компромисс осознанный. Карточка с явно помеченным пробелом полезнее, чем красиво заполненное поле, которого нет в источниках.
Практический вывод для тех, кто повторяет схему: логируйте пробелы и возвращайтесь к ним руками. Если домен критичен, добавьте шаг OCR до агента. Тогда скан превратится в текст, который агент прочитает и который попадёт в сверку контактов.
Инженерная обвязка: дедупликация, ожидание загрузки, защита от повторной отправки и сбои
Агент решает, какие документы открыть, но стабильность системы держится на обычном коде вокруг него.
Дедупликация закупок. Одна и та же закупка приходит из разных источников или повторно при следующем запуске. Без стабильного ключа (номер закупки, ссылка на площадку) менеджер получит дубли и перестанет доверять потоку.
Ожидание загрузки документов. Площадки отдают файлы не мгновенно. Если запустить агента сразу после появления закупки, он прочитает пустой набор и вернёт карточку без потребности. Нужен шаг, который дожидается, пока пакет документов станет доступен.
Защита от повторной отправки. Ретраи при сбоях Telegram или сети не должны превращаться в две карточки на одну закупку. Отправка должна быть идемпотентной: повторный вызов с тем же ключом не создаёт второе сообщение.
Обработка сбоев. Для долгих отказов внешнего API применяют circuit breaker: после порога ошибок вызовы сразу получают ошибку и не ждут таймаута, затем пропускается пробный вызов. Смысл в том, чтобы падение одного источника не растягивало обработку всего потока.
Почему это не задача модели
Дедупликация, ожидание загрузки, идемпотентность отправки и circuit breaker - детерминированные механизмы. Модель не должна решать, дубликат перед ней или новая закупка: на одинаковых входах она ошибается нестабильно, и такую ошибку трудно поймать тестами. Обычный код ошибается предсказуемо, его поведение воспроизводится и покрывается юнит-тестами.
Тот же принцип разбирали на другом примере: при аккуратной обвязке с поиском по документам дообученная модель нужна не всегда, и спор идёт о качестве обвязки (сравнение 1С Напарника с open-source агентом).
Что открыто на GitHub, а что закрыто
Исследовательское ядро AI Tender Radar открыто на GitHub под AGPL-3.0. В открытую часть входят пример инструкции и 726 тестов на синтетических данных. Закрыты подключения к площадкам, боевая инструкция и настройки сервера.
Граница выглядит логичной: открытая часть показывает, как устроена логика и как её проверяют, закрытая содержит то, что даёт преимущество и требует постоянного сопровождения.
Что даёт AGPL-3.0 и 726 тестов на синтетике
AGPL-3.0 - копилефт-лицензия. Если код используется в сетевом сервисе, исходники этого сервиса нужно открыть. Для внутреннего проекта без внешних пользователей вопрос обычно не возникает, для SaaS-обёртки условие принципиально.
Тесты на синтетических данных проверяют логику без боевых закупок и без утечки подключений к площадкам. Ценность в том, что видно, какие случаи авторы считают важными: разбор форматов, поведение при пробелах, сверку контактов. Качество на реальном потоке синтетика не доказывает: она повторяет представление автора о данных, а не сами данные.
Пример инструкции полезен как образец. Порядок поиска описан текстом, а не кодом, и его можно сравнить со своим. Ценность таких артефактов растёт: открытые проекты всё чаще соревнуются описанием процессов, а не только кодом (разбор Hacktoberfest 2026).
Когда брать агента, а когда хватит конвейера
Универсального ответа нет, но есть рабочая рамка. Microsoft описывает лестницу сложности агентных систем: прямой вызов модели, один агент с инструментами, несколько агентов. Совет простой: брать самый низкий уровень, который надёжно решает задачу (обзор подходов).
Агент оправдан, когда заранее неизвестно, какие документы и страницы понадобятся. Структура пакетов разная, релевантный контакт лежит то в ТЗ, то в приложении, то на сайте заказчика. Конвейер лучше, когда шаги стабильны и важна предсказуемость: одинаковый вход даёт одинаковый выход, а поведение легко покрыть тестами.
В обоих случаях результат проверяет код, а не модель. Разница только в том, кто выбирает следующий шаг чтения.
Чек-лист: что проверить перед запуском своего агента
- Агент получает только read-only инструменты, а действия с деньгами, отправка писем и изменения данных вынесены в обычный код.
- Ключевые поля карточки сверяются с текстами, которые агент реально прочитал, а неподтверждённое удаляется.
- У результата есть оценка уверенности, по которой человек понимает, что перепроверять.
- Есть дедупликация по стабильному ключу, ожидание загрузки документов, идемпотентная отправка и circuit breaker для внешних API.
- Пробелы в данных логируются и видны человеку, а не замалчиваются.
- Список нечитаемых форматов известен заранее: сканы без текстового слоя, RAR, старый XLS.
Границы применимости стоит проверять на своих задачах: быстрый прототип ломается, когда в процесс добавляется новое условие (разбор про магазин за два вечера).
Практический старт выглядит так. Возьмите десять реальных закупок своего домена, прогоните их через конвейер и посмотрите, где ветвления в коде начинают мешать. Добавьте детерминированную сверку контактов с прочитанными текстами и логирование пробелов. Агента включайте на том участке, где заранее неизвестно, какой документ понадобится следующим, и не давайте ему инструментов, которые что-то меняют во внешнем мире.