Сколько брать с клиентов за разработку ИИ-агента

Содержание

Опубликовано в августе 2026 года.

TL;DR: Не оценивайте разработку ИИ-агента по часам. Разделите её на две статьи: фиксированную плату за создание системы и ежемесячную плату за сопровождение, которая поддерживает её работу. Плата за разработку покрывает написание кода, тестирование и интеграции. Плата за сопровождение существует потому, что агенты ломаются — промпты «уплывают», API меняются, всплывают краевые случаи — и «готово» не бывает постоянным состоянием для всего, что связано с моделью. Откажитесь от сопровождения — и уже через месяц будете бесплатно оказывать техподдержку.

[Заметка оператора] Я управляю более чем 30 ИИ-агентами в продакшне — для консалтингового бренда и Pickleland, центра пиклбола в Пфлюгервилле, штат Техас, — и на основе этого опыта оценивал работу по созданию агентов для клиентов. Самая частая ошибка, которую я вижу — и у фрилансеров, и у агентств, — это отношение к ИИ-агенту как к сайту: посчитал смету, построил, передал, выставил счёт целиком. Агенты — это не сайты. Это системы, которые постоянно требуют внимания, потому что то, что лежит в их основе (модель, API, рабочий процесс клиента), постоянно меняется. Закладывайте это в цену — иначе оплатите это сами.

Почему почасовая оплата не работает для агентов

Почасовая оплата наказывает вас за то, что вы становитесь быстрее. Чем больше агентов вы построили, тем больше у вас переиспользуемых промптов, тестов (evals) и заготовок — и тем быстрее идёт следующий проект. При почасовой оплате каждый прирост эффективности урезает ваш счёт. Это работает наоборот.

Она же наказывает клиента с другой стороны. Клиент, нанимающий разработчика ИИ-агента, не может оценить, честны ли «12 часов» на рабочий процесс, это быстро или это накрутка. Он покупает чёрный ящик по цифре, которую не может проверить. Эта неопределённость заставляет клиентов торговаться, затягивать согласование или нанимать самого дешёвого исполнителя вместо лучшего.

Решение то же, что работает для любого продуктизированного предложения: оценивайте по определённому объёму и ценности результата, а не по времени. Применительно к агентам это означает два отдельных компонента с фиксированной ценой — потому что разработка и поддержка агента — это действительно разные продукты с разной структурой затрат.

Структура из двух частей: плата за разработку плюс плата за сопровождение

1. Плата за разработку — единоразовая фиксированная цена за проектирование, создание, тестирование и запуск агента. Оплачивается один раз, обычно двумя платежами (депозит на старте и остаток при сдаче).

2. Плата за сопровождение — регулярный ежемесячный платёж, который начинается со следующего месяца после запуска. Он покрывает мониторинг, исправление промптов при изменении модели или стороннего API, а также небольшие корректировки, не выходящие за рамки объёма.

Объединение их в одну цифру — самая большая ошибка ценообразования в этой нише. У клиента, который платит один раз, нет финансовой причины ждать чего-то после сдачи проекта, а у вас нет финансовой причины продолжать следить за агентом, за который вам заплатили месяц назад. Разделение делает стимулы честными: вам платят за то, чтобы всё продолжало работать, — и вы это обеспечиваете.

Это перекликается с фреймворком, который я использую, чтобы решить, стоит ли вообще строить автоматизацию — см. ROI ИИ-агента: стоит ли строить автоматизацию. Та статья написана со стороны покупателя: как бизнесу оценить, окупится ли агент. Эта статья — сторона продавца той же математики: стоимость разработки и налог на обслуживание из того фреймворка — это ровно те две вещи, которые вы здесь оцениваете.

Расчёт платы за разработку

Определяйте плату за разработку по уровню сложности объёма, а не на глаз по часам. Три уровня покрывают большинство клиентских проектов:

Эти диапазоны предполагают чётко определённую границу объёма — ту же дисциплину, что описана в статье как построить продуктизированный сервис: письменный список того, что включено, письменный список того, что не включено, и фиксированное число рабочих процессов или интеграций с инструментами. Клиент, который просит «ИИ-агента для моего бизнеса» без определённого рабочего процесса, ещё не готов покупать разработку — он готов к звонку по определению объёма, который представляет собой отдельный, менее объёмный результат (я оцениваю его как фиксированный аудит за $500–$1,000, который производит документ об объёме, относительно которого затем считается плата за разработку).

Внутри каждого уровня конкретная цифра зависит от трёх вещей: сколько разных инструментов вызывает агент, насколько тестирование приходится проводить на реальных, «грязных» данных клиента вместо чистых тестовых случаев, и насколько допустим режим отказа. Агент, который готовит черновик поста для проверки человеком, может изредка ошибаться с низкой ценой ошибки. Агент, который отправляет письмо с подтверждением или переводит деньги, ошибаться не может — и это меняет бюджет на тестирование сильнее, чем код.

Расчёт платы за сопровождение

Я устанавливаю плату за сопровождение как процент от платы за разработку, а не фиксированную сумму, потому что стоимость поддержки масштабируется вместе со сложностью системы так же, как и стоимость разработки.

maintenance_retainer_per_month = build_fee × monthly_rate

monthly_rate:
  stable integrations, low API-change risk        → 3–5%
  volatile APIs (social platforms, scraped data)   → 6–10%
  multi-agent systems, custom eval suite to keep up → 8–12%

Для многошагового проекта за $6,000 на умеренно стабильном стеке это примерно $250–$400 в месяц. Эта цифра должна ощущаться близкой к налогу на обслуживание, который я применяю к собственным автоматизациям — фиксированным 20% от стоимости разработки в год, что на нижней границе даёт те же 3–5% в месяц. Плата для клиента находится в том же порядке величины, потому что базовый источник затрат — «уплывание» промптов, изменения сторонних API, краевые случаи, всплывающие после запуска — не меняется только потому, что платит кто-то другой.

Плата за сопровождение прямо не включает: новые рабочие процессы, новые интеграции или изменения объёма. Это отдельные новые сметы на разработку. Сопровождение, которое незаметно поглощает «а можете ещё научить его обрабатывать вот этот случай», превращается в неоплаченную разработку функций уже через квартал — тот же провал, что описан в статье почему продуктизированным предложениям нужна жёсткая граница объёма, только применительно к текущей работе, а не к первоначальной разработке.

Привязывайте цену к тому, что она заменяет, а не к тому, во что обходится разработка

Плату за разработку не стоит обосновывать перед клиентом вашими часами — её нужно обосновывать устраняемыми ручными затратами. Перед тем как называть цену, посчитайте для клиента ту же формулу ручных затрат, что и во фреймворке ROI:

manual_cost_per_year = time_per_instance × hourly_rate × frequency_per_year
                      + error_cost_per_year

Если команда клиента тратит 5 часов в неделю на задачу, которую может выполнять агент, при полной ставке $40/час, это $10,400 в год ручных затрат. Плата за разработку в $6,000 при сопровождении $300/месяц ($3,600/год) окупается менее чем за год и продолжает окупаться каждый следующий год. Именно это сравнение — ручные затраты против стоимости разработки плюс сопровождения — и есть настоящий питч. Ведите с него в каждом предложении. Цена без точки сравнения — просто цифра; цена рядом с тем, что она заменяет, — это аргумент.

Это же задаёт естественный потолок: если заменяемые ручные затраты невелики, клиенту не стоит покупать мультиагентную систему за $15,000, а вам не стоит её продавать. Подбор уровня под реально вытесняемые затраты — это то, что делает ценообразование честным в обе стороны.

Условия договора, которые предотвращают расползание объёма

Помимо цены, в каждый договор на разработку агента, который я составляю, входят четыре условия:

1. Письменное определение «готово». Конкретные тестовые случаи, которые агент должен пройти до финального платежа, — не «хорошо работает», а список: «корректно классифицирует 9 из 10 примеров лидов из предоставленного набора данных», «успешно публикует посты на подключённой странице Facebook без ручного вмешательства». Расплывчатые критерии приёмки — главный источник неоплаченной дополнительной работы.
2. Прямо прописанные условия владения. Клиент владеет логикой рабочего процесса и любыми специфичными для него данными. Вы сохраняете переиспользуемые заготовки, шаблоны промптов и тестовые наборы (eval harness), не привязанные конкретно к его бизнесу — та же логика переиспользования интеллектуальной собственности, что описана в статье системы исполнения продуктизированного сервиса. Проговорите это заранее — это избавит от неловкого разговора позже.
3. Определённый порядок действий при отмене сопровождения. Если клиент отменяет сопровождение, чётко пропишите, что происходит: агент продолжает работать как есть без дальнейших исправлений, либо отключается после периода уведомления. Если это не определено, вы остаётесь ответственны за систему, за наблюдение над которой вам никто не платит.
4. Запросы на изменения оцениваются отдельно, письменно, до начала работы. Не «разберёмся по ходу дела» — а ставка или минимум за запрос, прописанные в договоре, чтобы просьба клиента об изменении объёма не превращалась каждый раз в переговоры.

Как отвечать на два возражения, которые возникают каждый раз

«Почему стоит дополнительно платить за поддержку того, что уже работает?» Потому что «работает» — это моментальный снимок, а не постоянное состояние. Провайдер модели может отказаться от неё или изменить её поведение, платформа, куда публикует агент, может изменить свой API, а бизнес самого клиента может изменить рабочий процесс, под который строился агент. Ничто из этого не баг в том, что вы поставили, — это нормальная скорость деградации любой системы, связанной с внешними, постоянно меняющимися частями. Я прямо описываю сопровождение как страховку от этой деградации, а не как постоянную «поддержку» — «поддержка» подразумевает, что что-то уже сломалось, а сопровождение означает, что кто-то следит за этим до того, как это произойдёт.

«А нельзя просто взять no-code инструмент и вообще обойтись без платы за разработку?» Иногда да — и я так и говорю. Если рабочий процесс действительно простой (один триггер, одно действие, без кастомной логики), no-code платформа автоматизации — честный ответ, и я укажу клиенту на неё, а не выставлю смету на разработку. Плата за разработку оправдана, когда есть реальная логика, интеграционная работа или суждения, которые drag-and-drop инструмент выразить не может. Отказ от неподходящих проектов — вот что делает достоверными те, за которые вы беретесь.

Инструменты, которые я использую для этой работы

Notion — здесь живёт документ об объёме: что включено, что нет, список приёмочных тестов и условия владения, — его я передаю клиенту до получения депозита.

Airtable — одна строка на каждый активный проект: статус разработки, дата выставления счёта за сопровождение и когда в последний раз выборочно проверялся результат работы агента.

Claude — на нём я строю большинство таких агентов; расчёт платы за сопровождение выше предполагает стек модели с достаточно стабильной ценой и поведением, и это меняет допущение о волатильности в формуле месячной ставки, если вы работаете на менее стабильном провайдере.

FAQ

Депозит должен быть 50% или другим?

50% на старте, 50% при сдаче по письменным критериям приёмки — самая простая структура, и я использую её по умолчанию. Для более крупных мультиагентных проектов (уровень $15,000+) я разбиваю на три платежа: депозит, платёж за этап при рабочем прототипе и остаток при сдаче — в основном чтобы избежать крупного финального счёта, который приходится выставлять клиенту, переставшему выходить на связь в середине проекта.

Что если клиент хочет платить только за сопровождение агента, который я не строил?

Я берусь за такие проекты, но оцениваю первый месяц дороже, чтобы покрыть аудит: изучение существующих промптов и кода, прогон приёмочных тестов, которые я написал бы сам, и документирование находок. Нельзя ответственно брать на себя плату за сопровождение системы, которую вы не строили и не проверяли, — месяц аудита превращает неизвестность в реальную цифру.

Как понять, что моё допущение о месячной ставке (3–12%) слишком занижено?

Сравните реальные часы на сопровождение за квартал с тем, что покрывает плата за сопровождение. Если вы стабильно тратите больше времени, чем она покрывает, поднимайте ставку при продлении — не поглощайте разницу молча. Формула — это отправная точка, откалиброванная по той же логике налога на обслуживание, что я применяю к собственным агентам; реальная частота изменений API и терпимость клиента к краевым случаям сдвинут её.

Нужен ли отдельный договор на звонок по определению объёма?

Для всего, что выходит за рамки короткого звонка, — да: оценивайте аудит по определению объёма как отдельный небольшой результат со своим письменным выходом (документом об объёме), даже если планируете засчитать его стоимость в плату за разработку при переходе к проекту. Это не даёт самому этапу определения объёма превратиться в неоплаченную продажу.

Следующие шаги: Мой курс AI Agents for Beginners охватывает создание агентов, которые этот фреймворк ценообразования уже считает вашим умением. Программа cowork — для операторов, которым нужна структурированная среда, чтобы строить и оценивать такую работу. Если вы хотите, чтобы аудит и документ об объёме сначала сделали за вас, запишитесь на 30-минутную сессию.