ipresale — агент подготовки коммерческих предложений
Агент ЯКомпании собирает требования закупки, рассчитывает предложение, заполняет формы и готовит комплект подачи. Порядок работы, проверки, передача в разработку и границы самостоятельности.
Разработчик: ЯКомпания
Назначение
ipresale — продукт «ЯКомпании», агент её платформы. Он готовит коммерческие предложения и документы для участия в закупках: получает материалы, разбирает требования, рассчитывает предложение, заполняет формы и собирает комплект подачи.
Результатом пользуется руководитель или сотрудник, отвечающий за участие в закупке. Вместо переноса сведений между файлами он проверяет готовое предложение, видит незакрытые требования и принимает решения об обязательствах компании.
Агент работает с b2b-center и bidzaar, а также с материалами прямых сделок вне площадок. Возможности подключения зависят от площадки и доступов: нельзя считать любой маршрут скачивания или отправки универсальным.
Вход
Для закупки на площадке входом служит номер или ссылка на процедуру; для прямой сделки — документы и запрос заказчика. Дополнительно нужны:
- доступ к материалам и личному кабинету, если они закрыты авторизацией;
- профиль компании: реквизиты, налоговый статус, опыт, документы и постоянные ответы форм;
- действующие правила расчёта и ограничения по участию;
- сведения по конкретному предложению, которых нет в профиле: состав работ, условия, исключения и решения владельца.
Повторно запрашивать известные реквизиты не требуется: агент берёт их из профиля. Отсутствующий документ или факт отмечается как незакрытая позиция, а не восстанавливается по догадке.
Можно задать другую цель — изучить закупку ради понимания рынка. Тогда агент готовит разбор и выводы для развития продукта, не собирая заявку на участие.
Порядок работы
1. Получить и подготовить материалы
Агент фиксирует предмет, заказчика и срок закупки, скачивает документы, распаковывает архивы и переводит файлы в рабочий вид. Уже сохранённые материалы используются повторно.
До передачи содержимого модели выполняется механическая проверка ограничений на использование генеративного ИИ. Если найден запрет на передачу документов или штраф за неё, дальнейший разбор останавливается до решения владельца.
2. Собрать требования
Учитываются четыре источника: архив документации, разъяснения организатора, форма подачи и комментарий на карточке процедуры. В последнем могут находиться обязательные условия, которых нет в ТЗ.
Модель выделяет требования, сопоставляет их с документами компании и готовит пакет: что нужно предоставить, чем требование закрывается, чего не хватает. Если часть источников недоступна, это остаётся видимым ограничением разбора.
3. Подготовить оценку и предложение
Агент формирует оценку по объёму работ и условиям закупки. Для первоначального решения нужна достаточная, но не избыточная детализация: состав результата, срок, допущения и риски. Начальная оценка учитывает возможность переторжки и уточнения предложения на следующем этапе; универсального процента запаса нет.
Расчёт зависит от предмета закупки. В проектной работе оценивается результат; в закупке специалистов — требуемые позиции и единицы измерения. Модель помогает разобрать объём, а арифметика и заполнение ценовых форм выполняются скриптами.
4. Заполнить формы и собрать документы
Агент готовит КП, анкеты, опросные листы, приложения и сопроводительные документы. Реквизиты и постоянные ответы берутся из профиля, ответы по конкретной закупке — из её решений.
Шаблоны площадки сохраняют свою структуру. Там, где пересборка книги приводит к отказу площадки, значения меняются точечно в исходном файле. Если для повторяемого действия нет инструмента, агент может написать сборщик, проверить его результат и использовать в следующих закупках.
5. Проверить комплект и подготовить подачу
План задаёт состав отправки и соответствие файлов полям загрузки. Агент собирает отдельную папку подачи, опись и карту ответов на поля площадки. Рабочие версии и промежуточные документы остаются отдельно.
Обычный прогон продолжается до готового комплекта без подтверждения каждого промежуточного шага. Отправка заявки требует явного разрешения владельца на конкретную закупку: подача является офертой. Подготовка формы и её отправка — разные действия.
6. Вести закупку после подачи
При переторжке агент получает места и текущие цены с площадки, пересчитывает предложение по установленным правилам и заполняет актуальный шаблон. Затем обрабатывает ответы и замечания, сохраняет фактически поданные материалы и дальнейшие действия.
Технически процесс состоит из 15 стадий: passport, fetch, extract, pack, documents, price, pricelist, forms, kp, contract, assemble, submit, haggling, errors, handoff. Для каждой предусмотрены вход, результат и проверка.
Выход
Результат ipresale — файлы и зафиксированное состояние закупки:
| Результат | Что в нём находится |
|---|---|
| Исходные материалы | Документы площадки или прямой сделки, доступные разъяснения и сведения о форме подачи |
| Пакет требований | Предмет, условия, состав документов, риски и незакрытые требования |
| Расчёт и предложение | Оценка, допущения, сроки, КП и требуемые ценовые формы |
| Документы | Заполненные формы заказчика и приложения компании |
| Комплект подачи | Только предназначенные для отправки файлы, опись и карта полей |
| Итог работы | Выполненные этапы, результаты проверок, принятые решения и недостающие сведения |
В рабочем пространстве всё по закупке находится в work/<id>/. Исходники хранятся в raw/, извлечённые тексты — в md/, разбор — в pack/, рабочие документы — в build/, комплект отправки — в submission/. Состояние стадий записывается в pipeline.json.
Проверки
- Состав папки подачи сверяется с планом. Файл вне плана вызывает ошибку.
- Обязательное поле без ответа не позволяет считать карту подачи готовой.
- Файлы сопоставляются с конкретными слотами формы, включая случаи, когда один документ закрывает несколько требований.
- Пустые обязательные реквизиты блокируют сборку карточки компании.
- Суммы и связанные показатели сверяются между расчётом и формами; применимые проверки зависят от документов закупки.
- Дедлайн сопоставляется с карточкой площадки. Просроченная локальная запись сама по себе не означает, что приём завершён.
- В PDF проверяются текст, метаданные и шрифты; читаемость и вёрстка требуют отдельного просмотра.
Механическая проверка подтверждает структуру и согласованность данных. Полнота смыслового разбора, корректность оценки и юридических обязательств требуют содержательной проверки.
Связи с другими агентами
Если закупка переходит к созданию продукта, ipresale передаёт документы и пакет требований в отдельный проект. При наличии передаются прототип и ссылки на референсные реализации. Подготовку входа выполняет общий инструмент spawn_project.py.
Дальше требования и разработку ведёт продуктовый конвейер. ipresale не дублирует его стадии и не заявляет, что приложение готово, только потому, что собраны документы закупки.
Автоматическая постановка каждой закупки в iomp здесь не подразумевается. Подготовка проекта из материалов закупки и маршрут разработки через задачи — разные части платформы; конкретный способ запуска фиксируется при передаче.
Ограничения
Модель может неверно понять условие, пропустить требование или предложить неподтверждённый ответ. Поэтому нужны источники фактов, проверки и возможность увидеть, что осталось незакрытым.
Площадка может изменить интерфейс, срок или формат шаблона. Новая форма иногда требует доработки инструмента. Авторизация, недоступный источник или ограничение провайдера модели могут остановить обработку.
Агент не создаёт отсутствующие лицензии, опыт, сотрудников или разрешения. Несоответствие критерию можно показать в заявке; подтверждать несуществующий факт нельзя. Решение участвовать при неполном соответствии остаётся за владельцем.
Отправка, новые обязательства и работа с документами, для которых запрещена передача ИИ, требуют отдельного решения. Наличие агента не даёт компании право передавать ему любые материалы.
ipresale не гарантирует победу, допуск или прохождение следующего этапа. Он готовит предложение и делает состояние работы видимым.
Практический пример
В одной из закупок форма содержала 30 обязательных файловых слотов. Общий список вложений не отвечал на вопрос, какой документ относится к каждому критерию.
В плане подачи для файла стали указывать подпись нужного слота или несколько подписей, если документ закрывает несколько пунктов. Сборщик сопоставляет их с формой и включает только существующие файлы. На выходе сотрудник получает карту загрузки, а отсутствие документа видно до отправки.
Проверка результата: каждому обязательному файловому полю назначены подходящие вложения либо зафиксирован пробел. Это конкретное изменение процесса; оно не является замером точности модели или вероятности победы.
Оценка результата
Сравнивать нужно весь путь до принятого комплекта, включая чтение исходников, исправления и повторные проверки.
| Показатель | Как считать |
|---|---|
| Время подготовки | От получения материалов до проверенного комплекта; отдельно учитывать ожидание внешних ответов |
| Полнота требований | Найденные корректные требования относительно эталонного разбора всех доступных источников |
| Ручные правки | Доля результатов с содержательными исправлениями, отдельно от оформления |
| Критичные ошибки | Пропуски обязательных условий, неподтверждённые факты и неверные обязательства |
| Готовность комплекта | Доля попыток, завершившихся комплектом, принятым ответственным сотрудником |
Для оценки именно вклада модели полезно сравнить три режима: ручную работу, автоматизацию скриптами и скрипты вместе с агентом. Задачи и критерии проверки должны быть сопоставимыми; неудачные обработки также входят в расчёт.
Подтверждённые факты этого описания — наличие стадий, сборщиков и проверок, работа с четырьмя источниками требований и разбор формы с 30 слотами. Проценты сокращения времени и роста побед без отдельного измерения не заявляются.