Паспорт требования для AI-агентов: атомарные требования 2026 | Гид | AiManual
AiManual Logo Ai / Manual.
12 Мар 2026 • Гайд

Паспорт требования: как правильно структурировать данные на входе для AI-агента

Полное руководство по input engineering для AI-агентов. Как создать паспорт требования, разбить ТЗ на атомы и подготовить данные для RAG. Практика 2026.

Почему ваш AI-агент тупит? (И нет, это не баг в Claude 4.5)

Вы загружаете в агента 50-страничное ТЗ, ждете десять минут, а он выдает: "Я проанализировал требования и готов приступить". А приступить-то не к чему. Промпты длиннее «Войны и мира», контекст перегружен, а результат — случайная выборка из того, что модель смогла ухватить.

Проблема не в модели. Не в контекстном окне в 1 млн токенов у GPT-5. И даже не в ваших навыках промпт-инжиниринга. Проблема в хаосе на входе. AI-агент — не человек. Ему нельзя скинуть поток сознания продукт-менеджера и надеяться на чудо. Ему нужен паспорт требования.

Главный миф 2026 года: "Большие модели сами разберутся". Не разберутся. Чем мощнее LLM (Gemini 3.0, GPT-5, Claude 4.5), тем болезненнее она реагирует на противоречивые и неструктурированные входные данные. Мусор на входе — катастрофа на выходе.

Что такое паспорт требования и зачем он вам

Паспорт требования — это не документ. Это структурированный набор атомарных фактов, контекста и ограничений, отформатированный специально для потребления LLM. Он превращает "сделай что-то классное" в машиночитаемый план.

Представьте, что вы даете задание не AI, а новому сотруднику. Вы же не будете читать ему вслух переписку в Slack за год. Вы дадите четкий бриф, KPI, доступы и границы ответственности. Паспорт требования делает то же самое для агента.

1 Вытащите все. Абсолютно все.

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

  • Запустите запись разговора (с согласия). Текст потом отдадите модели для анализа.
  • Задавайте глупые вопросы: "Что будет, если агент сделает все идеально, но в два раза дороже?", "Какой один результат заставит вас праздновать?"
  • Соберите всю сопутствующую дребедень: скриншоты старой системы, CSV-файлы, схемы в Miro, даже голосовые сообщения в Telegram.
💡
Используйте современные LLM (например, DeepSeek Coder-V3 2026) для первичного анализа сырых данных. Попросите ее выделить упоминания сущностей, действий и ограничений. Но не доверяйте слепо — это лишь первый набросок.

2 Атомизируйте. Разрежьте на молекулы.

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

  • Конкретным: Не "быстрый интерфейс", а "время отклика на действие пользователя < 100 мс".
  • Проверяемым: Агент или система мониторинга должны однозначно определить, выполнено требование или нет.
  • Изолированным: Не должно зависеть от других требований в формулировке.
// КАК НЕ НАДО:
{
  "requirement": "Сделать удобный дашборд для анализа продаж"
}

// АТОМАРНЫЕ ТРЕБОВАНИЯ:
[
  {
    "id": "PERF-01",
    "type": "performance",
    "statement": "Дашборд должен загружаться менее чем за 2 секунды при 1000+ записях в источнике данных.",
    "validation": "Замер времени от запроса до полной отрисовки последнего графика."
  },
  {
    "id": "DATA-07",
    "type": "data",
    "statement": "Раздел 'Динамика продаж' должен содержать график с группировкой по неделям и месяцам за последний календарный год.",
    "validation": "Наличие селектора группировки и временного диапазона с 01.01.2025 по 31.12.2025."
  }
]

3 Определите контекст и границы. Жестко.

Агент должен знать не только ЧТО делать, но и в КАКОМ МИРЕ это делать. Здесь многие спотыкаются, думая, что навыки агента решат все. Навыки — это инструменты, а контекст — правила их применения.

Элемент контекста Пример (для агента по работе с клиентами) Почему важно
Бизнес-правила Скидка более 15% требует согласования с руководителем отдела. Предотвращает нарушение процессов и финансовых лимитов.
Технические ограничения Внешний API биллинга отвечает 3-5 секунд. Повторный запрос через 10 сек. Избегает таймаутов и ложных ошибок в цепочках действий.
Правовые рамки Персональные данные клиентов из ЕС нельзя отправлять на серверы вне EU-кластера. Соблюдение GDPR и избегание юридических рисков. Критично для безопасности агентов.

4 Упакуйте для LLM. Язык имеет значение.

Теперь нужно перевести наш структурированный паспорт на язык, который максимально эффективно потребляется моделью. Это не про шаблоны, это про архитектуру информации.

# passport_requirement.yaml
meta:
  project_id: "prj-2026-ai-agent-onboarding"
  created: "2026-03-12"
  llm_target: ["gpt-5", "claude-4.5"] # Указываем целевые модели
  version: "1.2"

context:
  business_goal: "Автоматизация первичного технического собеседования кандидатов на junior DevOps."
  hard_constraints:
    - "Не запрашивать и не хранить паспортные данные кандидатов."
    - "Длительность сессии агента с кандидатом не должна превышать 25 минут."
    - "Использовать только утвержденный стек вопросов из базы знаний 'devops-interview-2026'."

atomic_requirements:
  - id: "AR-101"
    priority: "HIGH"
    description: "Агент должен задать ровно 5 практических задач по теме 'CI/CD Pipeline'."
    success_criteria: "В логах сессии зафиксированы 5 уникальных вопросов с тегом 'ci-cd-task'."
    failure_action: "Если кандидат отвечает на 4 из 5 задач правильно, перейти к теме 'Мониторинг'. Иначе — завершить собеседование с оценкой 'не прошел'."

  - id: "AR-102"
    priority: "MEDIUM"
    description: "После каждой задачи агент должен дать четкую обратную связь: объяснить, что было правильно, а где ошибка."
    success_criteria: "Каждый ответ кандидата сопровождается LLM-генерируемым комментарием длиной 50-100 слов, сохраняемым в лог."

rag_config:
  knowledge_sources:
    - "vector_db://questions/devops-interview-2026"
    - "git://internal/wiki/sre-guide"
  retrieval_strategy: "hybrid" # semantic + keyword search
  fallback_action: "Если релевантный ответ не найден в RAG, агент должен сказать 'У меня нет информации по этому вопросу, я его передам старшему инженеру' и записать вопрос в pending_issues."

Обратите внимание на поля failure_action и fallback_action. Они превращают агента из хрупкой цепочки промптов в устойчивую систему с обработкой краевых случаев. Это то, что отличает прототип от продакшена в 2026 году.

5 Тестируйте на идиотских сценариях. Итеративно.

Скормите паспорт агенту. Но не тому, для которого готовили. Возьмите другую модель (например, если паспорт для GPT-5, протестируйте на открытой Mixtral 2) или старую версию. Зачем? Чтобы найти скрытые неоднозначности.

Запустите симуляцию с абсурдными входными данными: "Кандидат отвечает стихами Есенина на все вопросы", "Внешняя система мониторинга возвращает статус 418 I'm a teapot". Если агент ломается, значит, в паспорте не хватает граничных условий.

Где паспорт требования ломается. Часто.

  • Слишком много атомов. 500 атомарных требований превращаются в шум. Группируйте их в домены (например, «Авторизация», «Отчетность») и передавайте агенту частями, используя архитектуру без роутинга.
  • Конфликт приоритетов. Что важнее: скорость ответа или полнота? Если в паспорте есть требования «Отвечать мгновенно» и «Давать максимально детальный ответ», агент застынет в параличе. Расставляйте числовые веса (priority_weight: 0.9).
  • Тихие изменения. Паспорт — живой документ. Если бизнес-правило изменилось вчера, а паспорт лежит в гит-репозитории с коммитом месячной давности, агент натворит дел. Интегрируйте паспорт с системой управления фича-флагами или хотя бы с вебхуком на обновление Confluence.

Связь с RAG: Паспорт требования — это не замена векторной базе знаний. Это ее схема и инструкция по использованию. В паспорте вы определяете, КАКИЕ источники знаний использовать и ЧТО делать, если ответа нет. Сами же факты лежат в RAG, подготовленные по принципам из гида по упаковке знаний.

Вопросы, которые вы боитесь задать

Какой инструмент использовать для создания паспортов? JSON, YAML, XML?

Формат — вторичен. Выбирайте тот, который легко парсить и валидировать в вашем стеке. В 2026 году YAML и JSON правят бал. Главное — завести схему (JSON Schema) и автоматизировать проверку перед загрузкой в агента. И да, храните паспорта в Git.

А если у меня не один агент, а сотни, как в агентном хаосе?

Тогда паспорта становятся продуктом. Нужен реестр паспортов, система версионирования, канареечные развертывания изменений и A/B тестирование разных версий требований на подмножестве агентов. По сути, это CI/CD для знаний.

Паспорт — это окончательная истина? А если агент найдет более эффективный путь?

Нет. Это договор между людьми и машиной на данный момент. Включите в паспорт пункт "suggestion_channel", через который агент может предлагать улучшения требований. Но последнее слово — за человеком. Иначе вы получите технический долг, генерируемый со скоростью света.

Паспорт требования не гарантирует, что агент сделает все идеально. Но он гарантирует, что когда что-то пойдет не так, вы будете знать, какое именно атомарное требование было понято неправильно. А это в 2026 году и есть главная суть инженерии — не предотвращать все ошибки, а создавать системы, где каждая ошибка становится понятным уроком, а не магическим глюком.

Подписаться на канал

←
На главную