На разработку ИИ-агента для одной задачи пришли два предложения, и суммы в них заметно расходятся. Выбирать по итоговой цифре рано: возможно, подрядчики оценили разные системы. Рабочий лист ниже приводит оба предложения к одной задаче и показывает, чего в каждом не хватает, что в нём лишнее, что придётся оплачивать после запуска и какой вопрос закрывает каждое неизвестное.
Сначала запишите общую задачу: что приходит на вход, что делает система, что решает человек и чего система не делает. Разложите оба предложения по одним статьям работ. Если подрядчик не включил работу, которая записана в общей задаче, отметьте её «не оценено» и запросите отдельно. Ноль ставить нельзя, раз задача без этой работы не закрывается. Работу сверх задачи попросите оценить отдельной строкой, чтобы её можно было убрать. После запуска известные заранее платежи сравнивайте цифрами, а расходы, которые зависят от объёма работы, — по формуле с допущениями и по тому, кто их платит. Часы своей команды учтите отдельно, если подрядчик их не оценил. Суммы сравнивайте последними.
Почему суммы в предложениях расходятся
Предложение описывает систему, которую подрядчик представил по вашему письму. Если письмо было коротким, двое подрядчиков могли представить её по-разному. Один решит, что агент только раскладывает заявку по полям и создаёт черновик. Другой добавит проверку на прошлых случаях, журнал действий и инструкцию для сотрудников. Тогда суммы расходятся, потому что оценены разные системы.
Для сверки подходит рамка из руководства Microsoft по модели затрат. Там советуют оценивать отдельно начальные затраты, текущие расходы на работу системы и последующие расходы, а в модель включать инфраструктуру, лицензии, работу людей, сопровождение и поддержку. Руководство написано для облачных систем, но разделение переносится и на агента: разработку, ежемесячную работу и изменения после запуска считают разными строками.
Вторая причина расхождений в архитектуре. Инженеры Anthropic различают workflow, где модель и инструменты идут по пути, заранее прописанному в коде, и агента, который сам выбирает шаги и инструменты. Они советуют начинать с самого простого решения и усложнять его, только когда это нужно: за агентность обычно платят задержкой и стоимостью. Поэтому большая сумма может означать систему сложнее, чем требует задача. Маленькая может означать, что в предложение не попали работы, без которых до пилота не дойти. Какой из двух случаев перед вами, покажет рабочий лист.
Условный пример: одна задача, два предложения
Задача, подрядчики и часы в этом примере придуманы. Это не клиентский проект и не рыночные оценки: я задал цифры сам, чтобы показать арифметику сверки. Реальные часы назовёт разработчик, когда увидит ваши системы.
Сверка начинается с общей задачи, записанной целиком. Заявки клиентов приходят на общий почтовый ящик. Система читает письмо, извлекает контакт, позиции и количество, ищет клиента в CRM, проверяет позиции по каталогу, создаёт черновик сделки и назначает менеджера. Менеджер сверяет черновик с письмом и подтверждает. Писем клиентам система не отправляет и сделки без менеджера не проводит. До запуска её проверяют на прошлых заявках, каждое действие пишется в журнал, менеджеры получают короткую инструкцию.
Подрядчик А оценил работу в 60 часов, подрядчик Б — в 140. Ниже оба предложения, разложенные по одним статьям. Все часы условные.
| Статья работ | А, условные часы | Б, условные часы |
|---|---|---|
| Разбор процесса и правил | 4 | 12 |
| Подключение почтового ящика | 12 | 16 |
| Поиск клиента, черновик сделки и назначение менеджера в CRM | 20 | 24 |
| Проверка позиций по каталогу | не включено | 12 |
| Инструкции модели и разбор полей | 20 | 24 |
| Свободный выбор инструментов агентом | не включено | 16 |
| Проверка на прошлых заявках | не включено | 16 |
| Журнал действий | не включено | 8 |
| Инструкция для менеджеров | не включено | 4 |
| Запуск | 4 | 8 |
| Итого в предложении | 60 | 140 |
Объём удобнее сверять в часах, а не в рублях: ставки и способы расчёта у подрядчиков могут различаться. Если предложение почасовое, стоимость строки равна её часам, умноженным на ставку из того же предложения. Если подрядчик назвал фиксированную цену за проект, попросите перечень работ, которые в неё входят, и примерное распределение цены или трудозатрат по этим статьям. Без такой разбивки сверять нечего.
Рабочий лист: приводим предложения к одной задаче
Сверка идёт в три прохода, и каждый отвечает на свой вопрос.
Чего не хватает. В предложении А нет проверки по каталогу, хотя она есть в задаче. Нет проверки на прошлых заявках, журнала и инструкции для менеджеров. Все четыре записаны в общей задаче, так что это пробелы в оценке, а не опции, от которых можно отказаться. Получается четыре статьи с неизвестной стоимостью. Ноль в них ставить нельзя: работа понадобится всё равно, просто её оплатят позже отдельным счётом или временем ваших сотрудников. Подставлять сюда часы Б тоже нельзя. Это оценка другого подрядчика под его архитектуру.
Что лишнее. В предложении Б 16 условных часов стоят на свободный выбор инструментов агентом. Шаги нашей задачи известны заранее: прочитать письмо, извлечь поля, найти клиента, проверить каталог, создать черновик. Для такого маршрута может хватить workflow. Вопрос к Б звучит так: что агентный режим даёт именно здесь и сколько стоит вариант без него. Если подрядчик подтвердит, что строку можно убрать без переделки остального, останется 124 условных часа. Пока подтверждения нет, 124 — только моя арифметика.
Чего нет ни у кого. Часов ваших людей. Владелец процесса собирает прошлые заявки и записывает, каким должен быть правильный черновик по каждой. Администратор CRM выдаёт права только на чтение клиентов и запись черновиков и согласует их с безопасностью. Менеджеры во время пилота проверяют черновики и возвращают ошибки. Эта работа нужна при любом подрядчике, оцените её хотя бы в днях.
Итог сверки по тому же условному примеру:
| Строка сверки | Подрядчик А | Подрядчик Б |
|---|---|---|
| Заявлено в предложении | 60 условных часов | 140 условных часов |
| Работы из задачи, которых нет в предложении | 4 статьи, не оценены | нет |
| Работы сверх задачи | нет | 16 условных часов на агентный режим |
| Сопоставимый объём сейчас | 60 условных часов и 4 неоценённые статьи | 140 условных часов или 124, если Б подтвердит вариант без агентного режима |
| Часы вашей команды | не оценены | не оценены |
Из таблицы не следует, что Б дороже или что А выгоднее. Следует, что сравнивать пока нечего: у А четыре статьи без оценки. Когда подрядчики ответят, лист пересчитывают, и только тогда суммы становятся сопоставимыми. Если вы всё же берёте урезанный объём, сделайте то, что Microsoft советует для бюджета ниже модели затрат: запишите, какую функциональность теряете. В нашем примере это проверка по каталогу, прогон на прошлых заявках, журнал и инструкция.
Что оплачивается после запуска
Разработка заканчивается, расходы остаются. Microsoft в том же руководстве отдельно перечисляет эксплуатационные затраты: мониторинг, тестирование, сопровождение, обновления и исправления. В нашем условном примере добавим допущение: модель оплачивается по фактическому использованию. Тогда к этим статьям прибавляется расход на модель, который растёт вместе с числом заявок. Anthropic пишет, что автономность агента повышает расходы и создаёт риск накопления ошибок, и советует тестировать агентов в изолированной среде и ставить ограничения, например предельное число шагов.
Часть расходов известна до пилота. Фиксированную лицензию или аренду сервера по тарифу подрядчик может назвать сразу, их и просите цифрой. Другие расходы зависят от того, сколько и каких заявок придёт и сколько работы уйдёт на каждую. Пока система не поработала на ваших заявках, такие расходы можно только оценить. Для них просите формулу и допущения: от чего зависит расход, какие значения подрядчик подставил и кто платит. Microsoft называет такие величины драйверами затрат и советует связывать расходы с бизнес-показателем, например со стоимостью одной обработанной операции. В нашем условном сценарии с оплатой модели по использованию формула такая: расход на модель в месяц равен числу заявок, умноженному на средний расход модели на одну заявку. Счёт при этом выставляют по тарифу выбранного поставщика модели, и единицей в нём не обязательно служит заявка. Если модель оплачивается подпиской или работает на вашем сервере, для неё нужна своя формула.
| Статья после запуска | От чего зависит | Что спросить |
|---|---|---|
| Оплата модели | В условном сценарии с оплатой по использованию: число заявок в месяц и средний расход модели на заявку | Какой тариф и способ оплаты, какие допущения о заявках заложены в оценку, есть ли предел шагов |
| Сервер и хранение журнала | Где работает система и сколько хранится журнал | Чья это инфраструктура и кто её оплачивает |
| Поддержка | Часы в месяц и срок реакции на сбой | Что входит в поддержку, а что считается доработкой |
| Изменения в почте и CRM | Как часто вы меняете эти системы | Кто чинит интеграцию и по какой ставке |
| Повторная проверка | Смена модели, инструкции или прав | Входит ли прогон на прошлых заявках в поддержку |
Ни одну строку не записывайте нулём. Нет ответа — пишите «не оценено» и держите в бюджете запас на незапланированные расходы, как советует Microsoft. Повторную проверку после изменений удобно сразу описать в формате записи приёмки: тогда видно, что именно подрядчик прогоняет и за что берёт деньги.
Вопросы, которые закрывают неизвестные
Отправьте обоим подрядчикам одинаковое описание задачи и одинаковые вопросы. Каждый вопрос закрывает одну строку листа.
- Разбейте оценку по статьям из таблицы. Какие статьи вы не включили и почему?
- Как система получит каталог и проверит по нему позиции? Сколько часов на это уйдёт?
- На скольких и каких прошлых заявках вы проверите систему до запуска? Кто готовит эти заявки и что считается пройденной проверкой?
- Что попадает в журнал, где он хранится и кто его читает?
- В каких шагах система выбирает действие сама? Что изменится, если сделать маршрут фиксированным?
- Какие права нужны к почте и CRM? Может ли система что-то изменить без менеджера?
- Что входит в поддержку, а что считается доработкой? Как считается оплата модели? Кто чинит интеграцию после обновления CRM?
- Кто и сколько дней нужен с нашей стороны на примеры, доступы и проверку в пилоте?
Ответы сами работу не сделают. Письмо фиксирует договорённость, а дальше каждый делает своё: администратор выдаёт права, владелец процесса собирает примеры, разработчик окончательно оценивает интеграции, когда увидит ваши системы, а результат принимает тот, кто отвечает за заявки. Когда объёмы сопоставимы, можно считать эффект для самой операции, как в разборе окупаемости ИИ-агента.
Источники и методика
Anthropic — Building effective agents, декабрь 2024 года. Инженерные рекомендации разработчика моделей, а не независимое исследование.
Microsoft — Architecture strategies for creating a cost model, Azure Well-Architected Framework. Методика для облачных систем; цен на разработку агентов в ней нет.
Задача, оба предложения и все часы в статье условные. Я задал их сам, чтобы показать метод сверки. Это не данные клиентов, не рыночные расценки и не прогноз стоимости вашего проекта.