Автономный тестировщик

Автономный тестировщик — это автономный ИИ-агент тестирования Mockarty. Вы даёте ему цель на обычном языке — «прогнать регресс по checkout-API по спецификации и профаззить эндпоинт оплаты» — а он сам разбирается в тестируемом продукте, планирует подход и (в зависимости от того, сколько свободы вы ему дали) выполняет тестирование за вас. Он фиксирует каждый шаг, создаёт артефакты (моки, коллекции, тест-кейсы, аномалии) и отчитывается о результате. Человек может наблюдать за его работой и вмешаться в любой момент.

Про URL в примерах: во всех примерах в качестве адреса Mockarty используется localhost:5770. Если ваш экземпляр работает на удалённом сервере, замените localhost:5770 на его реальный адрес (например, https://mockarty.company.com или http://192.168.1.50:5770). Подробнее — в Полезных функциях и советах.

Автономный тестировщик доступен на тарифах с автономными агентами: в Mockarty Cloud это Team и Enterprise (на Pro и Pro+ остаются ИИ-кнопки, чат и MCP-сервер). Если страница или эндпоинты недоступны в вашем экземпляре — эта функция не входит в ваш текущий тариф.

Что это

Миссия — это одна цель тестирования, которую вы даёте агенту. Исходя из цели, агент:

1. Ориентируется — читает знания, которые вы ему загрузили (документы, спецификации, описания pull-request’ов), чтобы понять, что делает продукт, прежде чем к нему прикасаться.
2. Планирует — решает, какие виды тестирования уместны (контрактное, API, фаззинг, UI, безопасность, нагрузка, тест-кейсы).
3. Действует — в зависимости от уровня автономности либо ждёт вашего одобрения, либо выполняет план и отчитывается о результатах.

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

Уровни автономности

При запуске миссии вы выбираете, сколько инициативы берёт на себя агент:

propose — значение по умолчанию, потому что участие человека безопаснее. Указывайте auto осознанно, когда точно знаете, что за клавиатурой никого нет.

Запуск миссии

Из интерфейса

1. Откройте Автономные миссии в боковом меню.
2. Нажмите Launch mission (Запустить миссию).
3. Введите Цель — опишите на обычном языке, что агент должен протестировать.
4. Выберите уровень Автономности (propose, auto или recon).
5. При желании задайте Бюджет токенов — жёсткий лимит на суммарный расход токенов миссии. Пустое поле не означает «без лимита»: миссию всё равно ограничивает щедрый защитный потолок, поэтому она не сможет бесконтрольно тратить токены. Задавайте бюджет явно, когда нужен более строгий — или, наоборот, больший — предел.
6. Нажмите кнопку отправки (или Ctrl+Enter в поле цели).

Новая миссия появится в списке и начнёт работу (либо в режиме propose спланирует и будет ждать вашего одобрения).

Через API

Отправьте аутентифицированный POST на /api/v1/autotester/intents с вашей целью. В ответе придёт missionId, по которому можно следить за прогрессом.

Передавайте токен в Authorization: Bearer … или X-API-Key; токены в query-параметрах
URL не принимаются. Если API- или integration-токен ограничен полем
allowed_actions, для запуска миссии в нём должно быть действие write.
Токен только для чтения получает 403 до разбора тела запроса и не создаёт миссию.

Токен должен быть привязан к пространству имён. Миссия работает без человека под тем пространством, которому принадлежит её токен, поэтому токен без привязки получает 401 — и параметр ?namespace= в адресе этого не меняет. Создайте токен сразу с пространством:

curl -X POST http://localhost:5770/api/v1/auth/tokens \
  -H "Authorization: Bearer $SESSION_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name":"autonomous-agent","namespace":"my-team","allowed_actions":["read","write"]}'

Если у продукта нет веб-страницы по адресу /, объявите хотя бы одну ручку.
Агент проверяет, что продукт действительно на месте, прежде чем что-то тратить, а
корень, отвечающий 404, выглядит как «ничего не развёрнуто». Объявленная рабочая
ручка доказывает обратное:

"contextRefs": [
  {"kind": "endpoint", "value": "GET /api/orders"},
  {"kind": "spec", "value": "https://api.example.com/openapi.json"}
]

curl -X POST http://localhost:5770/api/v1/autotester/intents \
  -H "Authorization: Bearer $MOCKARTY_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"goal":"Прогнать регресс по checkout-API по OpenAPI-спецификации и профаззить эндпоинт оплаты","autonomy":"propose","budget":{"tokens_total":500000}}'

Ответ:

{"missionId":"m_9f2c…","status":"accepted"}

Для повторяемой приёмочной кампании запрос может содержать rmaAssessment:
ID случая, SHA-256 дайджест корпуса кампании и упорядоченные критерии
oracle:1, oracle:2, …, затем forbidden:1, … . В том же запросе укажите
непустой traceId (до 128 байт UTF-8). Mockarty проверяет объявление и
привязывает точные тексты
критериев, случай, корпус и trace к неизменяемому описанию миссии до запуска.
Сервер не утверждает переданный дайджест корпуса. Это запись ожидаемого
результата, не подтверждение, что миссия прошла
проверки. Смысловой исход остаётся недоступным, пока не записана отдельная
серверная оценка.

Официальные SDK и CLI предоставляют тот же сценарий запуска и наблюдения:

Go

accepted, err := client.AutonomousMissions().Submit(ctx, mockarty.AutonomousMissionSubmitRequest{
    Goal: "Проверить регресс checkout", Autonomy: "auto",
    Budget: mockarty.AutonomousMissionBudgetHint{TokensTotal: 100000},
})
page, err := client.AutonomousMissions().List(ctx, "active", 50)
mission, err := client.AutonomousMissions().Get(ctx, accepted.MissionID)
flow, err := client.AutonomousMissions().GetFlow(ctx, accepted.MissionID)

Python

request = AutonomousMissionSubmitRequest(
    goal="Проверить регресс checkout", autonomy="auto",
    budget=AutonomousMissionBudgetHint(tokens_total=100_000),
)
accepted = client.autonomous_missions.submit(request)
page = client.autonomous_missions.list(status="active", limit=50)
mission = client.autonomous_missions.get(accepted.mission_id)
flow = client.autonomous_missions.get_flow(accepted.mission_id)

Java

var request = new AutonomousMissionSubmitRequest()
    .goal("Проверить регресс checkout").autonomy("auto").budget(100000, 0, 0);
var accepted = client.autonomousMissions().submit(request);
var page = client.autonomousMissions().list("active", 50);
var mission = client.autonomousMissions().get(accepted.getMissionId());
var flow = client.autonomousMissions().getFlow(accepted.getMissionId());

CLI

mockarty-cli autonomy missions submit --goal "Проверить регресс checkout" \
  --autonomy auto --tokens-total 100000
mockarty-cli autonomy missions list --status active --limit 50
mockarty-cli autonomy missions get "$MISSION_ID"
mockarty-cli autonomy missions flow "$MISSION_ID"

Повторяйте чтение flow, пока миссия не перейдёт в терминальный статус done или
failed. Статусы awaiting_approval и awaiting_info требуют участия оператора.

Тело запроса принимает:

• goal (обязательно) — описание того, что тестировать, на обычном языке.
• autonomy — recon, propose или auto. Если не указать, агент использует propose.
• budget — необязательные неотрицательные лимиты токенов и стоимости в USD. Ноль оставляет серверное значение по умолчанию; отрицательные, NaN и бесконечные значения отклоняются.

Сохраните missionId, чтобы опрашивать миссию (см. Наблюдение за прогрессом).

Для ИИ-агентов (MCP)

ИИ-агент может запустить миссию инструментом MCP submit_testing_task (цель + необязательные подсказки по автономности/бюджету/контексту), а затем следить за ней через autotester_mission_flow, который показывает миссию целиком за один вызов. См. ИИ-функции и MCP Marketplace о том, как инструменты предоставляются агентам.

Одобрение плана

В режиме propose миссия строит план и затем ждёт. На странице деталей миссии вы увидите Предложенный план с двумя кнопками:

• Approve & run (Одобрить и запустить) — агент выполняет одобренный план.
• Reject (Отклонить) — миссия останавливается без выполнения плана.

Через API:

# Одобрить предложенный план и начать выполнение
curl -X POST http://localhost:5770/api/v1/autotester/missions/$MISSION_ID/approve \
  -H "Authorization: Bearer $MOCKARTY_API_TOKEN"

# Отклонить план (миссия останавливается)
curl -X POST http://localhost:5770/api/v1/autotester/missions/$MISSION_ID/reject \
  -H "Authorization: Bearer $MOCKARTY_API_TOKEN"

Оба при успехе возвращают {"ok":true}.

Ответы агенту

Иногда миссии нужен факт, который она не может найти сама — базовый URL, имя учётных данных, какое окружение использовать. В этом случае миссия приостанавливается и показывает баннер Awaiting info (Ожидает информацию) с вопросом. Введите ответ в поле на странице миссии и нажмите Send answer (Отправить ответ) (или Ctrl+Enter) — и миссия продолжится.

Через API детали миссии содержат ожидающий вопрос (awaitingQuestion) и идентификатор, который нужно вернуть (awaitingRequestId). Отправьте ответ:

curl -X POST http://localhost:5770/api/v1/autotester/missions/$MISSION_ID/info-response \
  -H "Authorization: Bearer $MOCKARTY_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"requestId":"<awaitingRequestId>","available":true,"answers":{"baseUrl":"https://staging.example.com"}}'

• requestId (обязательно) — значение awaitingRequestId из миссии.
• available — true, если вы предоставляете ответ, false, если информация недоступна.
• answers — набор фактов, которые запросил агент.

Возвращает {"ok":true}, и миссия продолжается.

Наблюдение за прогрессом

Список миссий показывает цель и статус каждой миссии. Среди статусов: active (активна), paused (на паузе), awaiting_approval (ждёт вашего одобрения плана), awaiting_info (ждёт вашего ответа), done (завершена) и failed (провалена).

Выберите миссию, чтобы увидеть:

• Автономность и число шагов.
• Бюджет — потраченные токены относительно лимита (см. Бюджеты).
• Поток миссии — упорядоченный список выполненных шагов (у каждого — краткое описание, время, стоимость в токенах и отметка сбоя, если что-то пошло не так).
• Created (Создано) — артефакты, которые произвела миссия (моки, коллекции, тест-кейсы, аномалии), со ссылками.
• Управление — Pause (Пауза), Resume (Продолжить) и Stop (Остановить).

Страница обновляется вживую по мере работы миссии.

Через API можно опрашивать:

# Полный поток миссии за один вызов: миссия + шаги + артефакты
curl http://localhost:5770/api/v1/autotester/missions/$MISSION_ID/flow \
  -H "Authorization: Bearer $MOCKARTY_API_TOKEN"

Другие эндпоинты на чтение: GET /api/v1/autotester/missions (список), GET /api/v1/autotester/missions/{id} (одна миссия), .../timeline (шаги), .../artifacts (созданные сущности). Эндпоинты управления повторяют кнопки: POST .../pause, .../resume, .../stop. Старый маршрут .../stop работает как совместимый псевдоним durable-отмены Mission, если запуск уже принят общим контуром управления миссиями. После потерянного ответа повторно передайте необязательный заголовок Idempotency-Key; HTTP 202 означает, что отмена принята и ещё доставляется, а не что все удалённые исполнители уже остановились.

Для внешней миссии с объявленными критериями приёмки RMA запросите
GET /api/v1/autotester/missions/{id}/assessment с тем же правом чтения
миссии. Ответ содержит итог сервера по каждому объявленному критерию. pass
означает, что все критерии подтверждены свидетельствами и независимой
проверкой; fail — что хотя бы один критерий доказанно не выполнен;
could_not_verify — что имеющихся свидетельств недостаточно. Отсутствующий
или чужой результат даёт 404. Незавершённая оценка или изменившиеся
свидетельства дают 409, временная недоступность источника — 503. Чтение не
создаёт новую миссию и не повторяет вызовы модели.

Если администратор включил чтение только из журнала, а Mockarty не может подтвердить полноту проекции, запросы flow, timeline и agent-tasks возвращают 503 Service Unavailable, а не показывают устаревшую legacy-историю. Повторите запрос после ремонта или отката переключения журнала администратором.

Загрузка знаний

Агент тестирует лучше, когда сначала понимает продукт. Вы можете дать ему контекст, который он прочитает перед планированием:

• Документы и спецификации — загрузите документы, спецификации или заметки в базу знаний продукта.
• Pull request / merge request — укажите агенту URL GitHub PR или GitLab MR. Он получит заголовок, описание и diff (с вымарыванием секретов) и сохранит их, чтобы агент мог найти обоснование недавно влитой функциональности.

Для ИИ-агентов это доступно как инструмент MCP product_context_ingest_pr (загрузить PR/MR по URL) и product_context_search (поиск по базе знаний). Та же база знаний питает функции Базы знаний (RAG) в Mockarty.

Загрузить PR через API:

curl -X POST http://localhost:5770/api/v1/autotester/context/docs/ingest-pr \
  -H "Authorization: Bearer $MOCKARTY_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"url":"https://github.com/owner/repo/pull/123"}'

Для приватного репозитория добавьте поле token с персональным токеном доступа. Поиск по базе знаний:

curl "http://localhost:5770/api/v1/autotester/context/search?query=правила%20валидации%20payment%20API&k=5" \
  -H "Authorization: Bearer $MOCKARTY_API_TOKEN"

Поиск по трём корпусам

Агент читает знание из трёх источников, и теперь они различимы в каждом ответе и выбираемы в каждом поиске:

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

# Только записи опыта прогонов, без документов продукта
curl "http://localhost:5770/api/v1/autotester/context/knowledge/search?query=payment%20retry&corpus=experience" \
  -H "Authorization: Bearer $MOCKARTY_API_TOKEN"

# Только документы, без находок прошлых прогонов
curl "http://localhost:5770/api/v1/autotester/context/search?query=payment%20retry&corpus=product_context" \
  -H "Authorization: Bearer $MOCKARTY_API_TOKEN"

Значение corpus вне трёх названных (security_kb, product_context, experience) отклоняется с перечислением известных: фильтр либо применён, либо отвергнут — молча проигнорирован он не бывает. Запись, корпус которой определить нельзя, честно отвечает unknown, а не подставленным именем.

Переиспользование опыта прошлых прогонов

Контекст продукта отвечает на вопрос «что написано в документах?», а опыт прогонов — «что предыдущая работа действительно выяснила?». В корпусе опыта хранятся четыре вида наблюдений: pitfall, mission_lesson, product_fact и defect_root_cause. У каждой записи есть источник и происхождение. Это проверяемое свидетельство, а не подтверждённая спецификация.

ИИ-агенты вызывают experience_search, прежде чем заново выяснять адрес, схему авторизации, причину повторяющегося сбоя или прежнее исправление. После конкретной находки они вызывают experience_record. Запись создаётся кандидатом и не влияет на следующие миссии, пока уполномоченный рецензент не опубликует её. Точный повтор того же свидетельства идемпотентен и не заменяет другую запись. Каждая запись отвечает своим корпусом (experience), и корпус назначает платформа по виду записи — тело запроса не может объявить свою запись принадлежащей другому корпусу.

cURL

curl "http://localhost:5770/api/v1/autotester/context/knowledge/search?query=повтор%20оплаты&kinds=pitfall&k=5" \
  -H "Authorization: Bearer $MOCKARTY_API_TOKEN"

curl -X POST http://localhost:5770/api/v1/autotester/context/knowledge \
  -H "Authorization: Bearer $MOCKARTY_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"kind":"pitfall","text":"При повторе оплаты нужен ключ идемпотентности","source":"автономный прогон m-42, ход 17"}'

Go SDK

items, err := client.Experience().Search(ctx, mockarty.ExperienceSearchRequest{
    Query: "повтор оплаты", Kinds: []string{mockarty.ExperienceKindPitfall}, Limit: 5,
})

Python SDK

items = client.experience.search(query="повтор оплаты", kinds=["pitfall"], limit=5)

Java SDK

ExperienceSearchResponse items = client.experience()
    .search("повтор оплаты", List.of(ExperienceApi.KIND_PITFALL), null, 5);

Знание извне вашей установки

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

MOCKARTY_EXTERNAL_KNOWLEDGE — это и есть ваше решение:

MOCKARTY_EXTERNAL_KNOWLEDGE_HOSTS — список через запятую. Запись — либо точный
узел (docs.example.com), либо, если начинается с точки, сам домен и всё под
ним (.example.com).

Любое другое значение отклоняется и трактуется как off, поэтому опечатка не
может расширить доступное агенту. При off инструменты выхода наружу агенту
даже не предлагаются: он планирует без них, а не пробует и получает отказ.

Настройка касается ЗНАНИЯ. Систем, которые вы тестируете, она не трогает:
запросы к указанной вами цели — вызовы API, нагрузка, сканирования — работают
как прежде.

Профиль качества продукта

Тестируемый продукт можно вести как долгоживущую сущность, а не разовый прогон. Продукт накапливает фактуру, которую тестировщику стоит переиспользовать (базовые URL, ссылки на спеки, примеры, известные проблемы), и тренд качества во времени — так каждый прогон стартует с того, что узнал предыдущий (регресс, дельты, скользящий уровень риска), а не с нуля.

Ключи пространств для платформенных сервисов

Эти ручки используют пространство из ключа, если явно не выбрать другое через
?namespace=... или X-Mockarty-Namespace. Ответ 403 о том, что ключ
ограничен другим пространством, описывает права самого ключа, а не подтверждает
существование запрошенного пространства. Используйте API-ключ нужного
пространства. Если один платформенный сервис должен работать во всех
пространствах заказчиков, администратор может создать интеграционный токен с
областью admin в Панель администратора → Интеграции (или через
POST /api/v1/integrations) и использовать показанный один раз токен mki_....
Область admin даёт сквозные права: не используйте её для интеграции одного
заказчика и храните токен как секрет.

Создать или обновить продукт (key — стабильный слаг, уникальный в пространстве имён; тот же key обновляет запись на месте, без дублей):

curl -X POST http://localhost:5770/api/v1/qa/products \
  -H "Authorization: Bearer $MOCKARTY_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"key":"payments-api","name":"Payments API",
       "baseUrls":["https://staging.example.com"],
       "specRefs":["https://staging.example.com/openapi.json"]}'

Прикрепить переиспользуемый факт (пример, инвариант, известную проблему). Повторное добавление того же sourceRef обновляет запись на месте, поэтому загрузка одного и того же PR дважды не плодит дубли:

curl -X POST http://localhost:5770/api/v1/qa/products/<id>/facts \
  -H "Authorization: Bearer $MOCKARTY_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"kind":"known_issue","body":"Оформление заказа отдаёт 500 под нагрузкой","sourceRef":"issue:42"}'

Прочитать тренд качества — текущий score/риск плюс поснимочные данные по измерениям, которые добавляет каждый прогон:

curl http://localhost:5770/api/v1/qa/products/<id>/quality \
  -H "Authorization: Bearer $MOCKARTY_API_TOKEN"

Прочитать всё, что уже известно о продукте, одним вызовом — перед тем как начинать круг доработки. Ответ содержит план тестирования этого продукта человеческим текстом, открытые и закрытые дефекты, покрытие по областям и итог последнего прогона:

curl http://localhost:5770/api/v1/qa/products/<key-или-id>/knowledge \
  -H "Authorization: Bearer $MOCKARTY_API_TOKEN"

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

Что в ответе полезно именно чинящему:

• strategy.brief — как мы решили проверять этот продукт и почему, включая раздел о том, чего этот план не покрывает;
• strategy.history — прошлые версии плана (номер, кем составлен, когда и почему поменялся). Отвечает на вопрос, который текущий план не отвечает: изменилось ли наше понимание продукта с того прогона, чьи дефекты вы чините;
• openDefects[].key — тот же ключ, что приходит в дефекте прогона, поэтому дефект из отчёта и запись в истории продукта — одно и то же;
• openDefects[].where — адрес: ручка, экран или шаг. Разница между «искать» и «чинить»;
• lastRun.sufficiency — хватило ли ПРОВЕРКИ. Отдельно от того, прошёл ли продукт: прогон может не найти ни одного дефекта и при этом быть недостаточным.
• notRecheckableDefects[] — дефекты, поверхность которых эта сборка на этом продукте больше не запускает (план исключил область, или батарея здесь не работает). Их намеренно НЕТ в openDefects: закрыть их своими действиями нельзя, поэтому это не открытые дефекты. У каждого записана notRecheckableReason; дефект вернётся в открытые, как только поверхность снова станет проверяемой и дефект воспроизведётся.

Для ИИ-агентов та же поверхность доступна как инструменты MCP: qa_product_list, qa_product_get, qa_product_upsert, qa_product_quality, qa_product_facts_add, qa_product_delete, product_knowledge.

Непрерывное тестирование (каденции)

Продукт можно тестировать по расписанию, круглосуточно — ночной скан безопасности, еженедельный нагрузочный тест, ежечасный smoke-прогон. Каждая каденция запускает автономную миссию по своему cron, с целями по её виду и ограниченным бюджетным конвертом — так расписание 24/7 никогда не перерасходует.

curl -X POST http://localhost:5770/api/v1/qa/products/<id>/cadences \
  -H "Authorization: Bearer $MOCKARTY_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"kind":"security","cronExpr":"0 2 * * *","enabled":true}'

kind — один из security, load, regression, contract, smoke или full (полная матрица). cronExpr принимает стандартный пятипольный cron (0 2 * * * = 02:00 ежедневно) или дескриптор (@daily, @every 1h). В ответе есть вычисленное nextFireAt. Для ИИ-агентов: qa_cadence_list, qa_cadence_set, qa_cadence_delete.

Реакция на работу вашей команды

Когда команда пользуется трекером, вики, тест-кейсами и чатом Mockarty, автономный тестировщик следит за этими сигналами и реагирует сам — накапливает каждое изменение в базу знаний продукта и (где вы настроили правило) запускает из него тестовую миссию. Анти-спам-троттлинг гарантирует, что всплеск активности не превращается во всплеск миссий. Так тестировщик становится непрерывным коллегой, который поспевает за продуктом по мере его изменений, а не только тем, что вы запускаете вручную.

Бюджеты

Вы можете ограничить, сколько миссии разрешено потратить, чтобы она остановилась до перерасхода. При запуске миссии (например, через инструмент submit_testing_task или API) можно задать:

• tokens_total — жёсткий лимит на общее число токенов для миссии.
• tokens_per_day — суточный лимит токенов.
• usd_cap — необязательный лимит расходов в долларах США. Считается по тому, сколько миссии реально списано по вашему прайс-листу. Каждый шаг тоже ограничен оставшимися деньгами, поэтому один длинный шаг не уйдёт далеко за лимит. Когда лимит исчерпан, миссия встаёт на паузу с уведомлением о бюджете; поднимите лимит и продолжите.

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

Коннекторы и триггеры

Миссии не обязательно запускать вручную. Откройте Автономные миссии → Триггеры (/ui/missions?tab=triggers) и нажмите Настроить приём, чтобы подключить внешние системы — например, трекер задач, чат-бот, шину сообщений или подписанный вебхук. Настройте подключение один раз — и входящие события превратятся в миссии тестирования, которые агент подхватит сам. См. Внешние трекеры и инструменты и CI Триггеры о смежных возможностях интеграции.

Подписанный вебхук (HTTP-приём)

Входящий коннектор HTTP Webhook даёт публичный endpoint, на который внешняя система может отправлять задания. При создании коннектора интерфейс показывает URL endpoint’а (он же виден в списке коннекторов, с кнопкой копирования). Отправитель должен:

1. Отправить POST с JSON-заданием (тот же формат, что у /api/v1/autotester/intents — минимум {"goal":"..."}) на /api/v1/intake/<id-коннектора>.
2. Передать целевой namespace в заголовке X-Namespace.
3. Подписать сырое тело запроса HMAC-секретом коннектора — hex-кодированный HMAC-SHA256 — и передать подпись в заголовке X-Intake-Signature.

BODY='{"goal":"Смоук-тест API заказов","autonomy":"auto"}'
SIG=$(printf '%s' "$BODY" | openssl dgst -sha256 -hmac "$INTAKE_SECRET" -hex | sed 's/^.* //')
curl -X POST http://localhost:5770/api/v1/intake/$CONNECTOR_ID \
  -H "X-Namespace: default" \
  -H "X-Intake-Signature: $SIG" \
  -H "Content-Type: application/json" \
  -d "$BODY"

Валидная подпись возвращает 202 Accepted, и миссия появляется в cockpit «Автономные миссии». Отсутствующая или неверная подпись отклоняется с 401.

Смотрите также

• ИИ-функции — чат ИИ-агента и встроенные инструменты.
• MCP Marketplace — как инструменты предоставляются ИИ-агентам.
• База знаний (RAG) — хранилище контекста продукта.
• Агент безопасности — автономное сканирование безопасности.