Главная / Статьи / Изучение инженерии агентных ИИ в порядке, который предлагают сами сбои.

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

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

4569 слов

Разработчики, переходящие к созданию агентов, часто пытаются освоить все фреймворки сразу, пробуя LangChain, CrewAI, AutoGen и LangGraph в течение одной недели, не выпуская при этом ничего готового. Проблема заключается в порядке действий: они изучают инструменты, не понимая сначала тех ошибок, которые эти инструменты предназначены предотвратить. В этом руководстве описан четырнадцатишаговый путь в том порядке, в котором навыки действительно развиваются один за другим, от базового Python до выпуска агента, работающего автономно. По пути вы узнаете о трех типах сбоев, влияющих на каждое проектное решение, о минимальном наборе инструментов, достаточном для большинства задач в производственной среде, а также о структурных паттернах (файлы состояния, процедуры проверки, многоуровневая оценка и настройка прав доступа), которые отличают демо-версию от системы, которой можно доверять сразу.

Часть 1: Ментальная модель

1. Инженерия агентов — это не инженерия промптов с новым названием

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

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

Это влечёт за собой три обязанности, которые ранее не требовались при работе с подсказками:

Рассмотрение ошибок как ключевой аспект. Агенты постоянно терпят неудачу: API истекают сроком действия, возвращаемый JSON имеет неверную структуру, модель выдумывает вызовы инструментов, а результаты их работы нарушают установленные схемы. Код, предполагающий успешное выполнение операций, может сломаться в самый неподходящий момент, обычно во время демонстрации.
Управление состоянием. Одинокий вызов большой языковой модели не сохраняет никаких данных. Агенту, выполняющему десять шагов с использованием вызовов инструментов, попыток повтора и вспомогательных агентов, необходимо структурированное и долговечное состояние, которое сохранялось бы даже после завершения текущего окна контекста.
Внедрение механизмов оценки в инфраструктуру. Нет никаких интуитивных признаков, показывающих, правильный ли ответ дал агент. Необходимы автоматизированные проверки, такие как тесты, критерии оценки или модель-судья, которые отклоняют некорректные результаты без необходимости в ручной проверке каждого случая выполнения.

Описания должностей для этих позиций часто напоминают каталог. Здесь упоминаются фреймворки оркестрации (LangGraph, LangChain, LlamaIndex), протоколы (MCP, A2A), функции моделей (вызов функций, структурированные результаты, кэширование промптов), методы поиска (RAG, RAGAS, гибридный поиск, переранжирование, модели эмбеддингов, векторные и графовые базы данных), а также операционные навыки (исполнение в изолированной среде, возможность мониторинга, оценка качества). Обычно после этого проситесь проявлять готовность к быстрой итерации. Список может показаться обременительным, но большинство пунктов представляют собой несколько основных идей под разными названиями. Если вы поймете эти идеи, названия продуктов станут легко узнаваемыми.

2. Три основных способа сбоев объясняют большую часть задач

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

Лень агента. Сталкиваясь с длительной задачей, состоящей из нескольких этапов, модель прекращает работу раньше времени и сообщает о успехе после частичного выполнения. Она решает 20 из 50 задач в списке ожидания и утверждает, что остальные также обработаны. Мерой противодействия является четкое условие остановки, которое проверяется каким-то другим элементом, кроме самой модели.

Самопредпочтительное смещение. Когда модель просится оценить собственный результат, она всегда его одобряет. Человек, вложивший усилия в получение результата, не может оценить его объективно. Мерой противодействия является структурное решение: агент, выполняющий работу, не должен быть тем же самым агентом, который её оценивает.

Смещение цели. По мере выполнения большого количества шагов, особенно после обобщения или сжатия контекста, агент постепенно теряет нить оригинальной цели. Такое ограничение, как «не трогать модуль платежей», может незаметно исчезнуть к 47-му шагу. Мерой противодействия является постоянный файл спецификаций, который читается заново при каждой запуске и содержит ограничения, без которых модель бы их потеряла.

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

3. Небольшой ядро-набор и четыре вещи, которые стоит отложить

Списки требований длинные, но основная часть работы производственного агента сводится к четырем слоям, которые лучше изучать в следующем порядке:

Core stack (learn these, in this order):
1. Python + async    : the bedrock; everything else builds on it
2. LLM APIs          : Anthropic, OpenAI; understand tokens, context, costs
3. Tool use / MCP    : function calling; how models act on the world
4. LangGraph         : stateful orchestration for multi-step, multi-agent work

Отложите следующее до тех пор, пока у вас не будет выпущен хотя бы один реальный агент:

Тонкая настройка. Ранние проекты почти никогда её не требуют. Способная базовая модель с хорошо спроектированными промптами обычно превосходит тонко настроенную модель с плохими промптами.
Бесконечные размышления о векторных базах данных. Такие инструменты, как Chroma, подходят для локального использования, а сервисы вроде Pinecone — для производственных задач. Не спешите выбирать что-то конкретное, пока поиск информации действительно не станет проблемой в вашем проекте.
Смена фреймворков. Выберите один фреймворк для оркестрации (LangGraph — хороший стандартный вариант), завершите проект, а уже потом исследуйте другие варианты. Постоянная смена инструментов каждую неделю из-за обещаний их простоты не гарантирует завершения работы над проектом.
Агенты голоса и браузера. Это специализированные решения, построенные на тех же основах. Сначала овладейте текстовыми агентами — принципы их работы будут применимы и здесь.

Часть 2: Основные элементы

4. Python и асинхронный код

Вам не обязательно быть мастером Python, но достаточных знаний для отладки ошибок необходимо — а агенты часто допускают сбои. Сосредоточьтесь на следующем:

Классы и модели данных. Агенты передают структурированные данные от этапа к этапу, поэтому их необходимо моделировать. Схема Pydantic служит контрактом между вызовами инструментов и логикой агента; рассматривайте её как обязательную, а не факультативную часть.
Асинхронность с asyncio. Агенты тратят большую часть времени в ожидании результатов от инструментов: запросов к базе данных, HTTP-запросов, вспомогательных процессов. Синхронный код блокируется во время каждого ожидания, тогда как асинхронный код может выполнять другую работу. Медленная работа агента часто связана с синхронным кодом, который ожидает последовательно.

HTTP и REST. Без API агент может только мыслить, но не действовать. Необходимо научиться читать документацию API, соблюдать ограничения по частоте запросов, интерпретировать ответы на ошибки и разумно пытаться выполнить задачу заново. Инструмент, который выходит из строя при коде ошибки HTTP 429, нельзя считать надежным для использования агентом.

Обработка ошибок. Каждый вызов инструмента следует обернуть в блоки try/except. Агенты работают без присмотра, и неразрешенная ошибка, выводящая стек-трейс и прерывающая работу, никому не поможет посреди ночи.

Практический критерий: если вы можете поручить задачу младшему инженеру вместе с чек-листом и быть уверены, что набор тестов покроет его ошибки, значит, у вас достаточно знаний Python, чтобы начать. Остальное можно освоить позже.

5. Основы LLM: токены, контекст и стоимость

Модели вроде Claude, GPT и Gemini очень мощны, но им нужен четкий направляющий принцип, а вы не можете управлять тем, чего не понимаете.

Токенизация. Модели читают токены, а не слова, и один термин может разделиться на несколько токенов в зависимости от инструмента токенизации. Как приблизительное правило для английского языка, контекст из 100 000 токенов содержит примерно 75 000 слов. Всё, что находится за пределами этого диапазона — будь то разговор прошлой недели или файл, который вы забыли включить — просто не существует для модели. Если что-то имеет значение, оно должно находиться в контексте.

Ограничения контекста и извлечение информации. Модели не запоминают; каждая сессия начинается с пустого состояния. Включение всего в запрос требует больших ресурсов и снижает качество по мере увеличения объема информации. Технология генерации с усилением на основе извлечения данных позволяет брать во внимание только релевантную информацию.

Инференс, а не обучение. Вы почти никогда не будете обучать модель. Вы запускаете процесс инференса на чужой модели и платите за каждый токен. Стоимость состоит из количества входных токенов умноженного на цену входных данных плюс количества выходных токенов умноженного на цену выходных данных, поэтому цикл, содержащий 50 вызовов с контекстом из 20 000 токенов, приводит к значительным расходам.

Формулировка запросов для агентов. Запросы к агентам отличаются от запросов в чате. Самые важные из них — это три подхода: «цепочка мыслей», при которой модель явно рассуждает перед действием; ReAct, представляющий собой цикл рассуждений, действий и наблюдения; и рефлексия, при которой модель критикует собственный проект перед тем, как вернуть его. Большинство других методов формулировки запросов являются вариациями этих подходов. Чтобы узнать больше о цикле ReAct, прочитайте как агенты ReAct сочетают рассуждения с действиями в реальном мире.

6. Использование инструментов и MCP превращают чат-бота в агента

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

Механически каждая функция описывается с помощью имени, описания на естественном языке и JSON-схемы параметров, после чего эти определения отправляются вместе с сообщением пользователя. Модель решает, требуется ли инструмент, и в случае необходимости возвращает структурированный запрос к инструменту с аргументами вместо простого текста. Ваш код запускает функцию, отправляет результат обратно, и модель продолжает работу с ним. Описание имеет такое же значение, как и схема, поскольку именно оно используется моделью для определения того, когда применим инструмент.

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

# Category 1: Read  (agent observes the world)
def search_codebase(query: str, path: str) -> list[str]: ...
def fetch_url(url: str) -> str: ...
def read_file(path: str) -> str: ...

# Category 2: Write (agent changes state)
def create_file(path: str, content: str) -> None: ...
def open_pull_request(title: str, body: str, branch: str) -> str: ...
def send_slack_message(channel: str, text: str) -> None: ...

# Category 3: Execute (agent runs code)
def run_tests(test_path: str) -> dict: ...
def execute_sql(query: str, db: str) -> list[dict]: ...

# Category 4: Verify (agent checks its own work)
def lint_code(file_path: str) -> list[str]: ...
def run_type_checker(path: str) -> bool: ...

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

Протокол контекста модели (MCP) — это новый стандарт, который заменяет специально написанный код интеграции протоколом. Часто его сравнивают с USB-C в области ИИ: вместо того чтобы каждый раз писать отдельный адаптер, когда агенту нужен GitHub, Slack или база данных, достаточно подключить существующий сервер MCP, и приложение-хост само обнаруживает возможности сервера и использует их без дополнительного кода.

Самые эффективные интеграции — это GitHub для управления ветками, pull-запросов и задач; Slack для уведомлений и кратких сводок; ваша база данных для выполнения запросов и контролируемого записи данных; а также система отслеживания задач команды. При связи этих четырех компонентов агент может выполнять большинство операций в рамках инженерного процесса.

7. Получение информации, поскольку объем контекста ограничен

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

Система получения информации состоит из четырех основных компонентов:

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

Оценка — показатель, отличающий реально работающую систему от той, что кажется таковой. Ключевыми метриками являются точность поиска (было ли полученное материал действительно релевантным?), верность (оставался ли ответ в рамках найденного материала?) и релевантность ответа (отвечал ли он на вопрос?). Для оценки этого используются такие инструменты, как RAGAS или модели-судьи. Без измерений улучшения являются лишь догадками.

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

8. Оркестрация с сохранением состояния с помощью LangGraph

Один вызов LLM не является агентом. Агент выполняет несколько шагов, сохраняет состояние между ними, принимает решения на основе полученных данных и восстанавливается после сбоев. LangGraph предоставляет структуру именно для этого.

С точки зрения структуры, приложение LangGraph представляет собой ориентированный граф, узлами которого являются простые функции, такие как агенты, инструменты или шаги обработки. Рёбра определяют, как контроль передаётся между узлами. Каждый узел читает и обновляет общий типизированный объект состояния.

Приведённый ниже скетч определяет состояние с задачей, планом, результатами, ошибками и флагом завершения, затем регистрирует четыре узла: планировщик, который делиит работу на части, исполнитель, который выполняет один шаг, проверщик, который анализирует результат, и обработчик ошибок, который пытается выполнить задачу заново или передаёт её на более высокий уровень. Условная рёбра после проверщика являются сутью цикла: завершить работу, когда состояние указывает на её окончание, перенаправить запрос к обработчику ошибок при их наличии, в противном случае выполнить следующий шаг. Обратите внимание, что это лишь фрагмент; для работоспособной схемы также необходима точка входа, оставшиеся рёбра и вызов функции compile().

from langgraph.graph import StateGraph, END
from typing import TypedDict

class AgentState(TypedDict):
    task: str
    plan: list[str]
    results: list[str]
    errors: list[str]
    done: bool

graph = StateGraph(AgentState)

graph.add_node("planner", plan_task)       # breaks work into steps
graph.add_node("executor", execute_step)   # runs one step
graph.add_node("verifier", verify_output)  # checks the result
graph.add_node("handler", handle_error)    # retries or escalates

graph.add_conditional_edges(
    "verifier",
    lambda state: END if state["done"] else
                  "handler" if state["errors"] else
                  "executor"
)

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

Проверка состояния. При компиляции графа с использованием механизма проверки состояния оно сохраняется после каждого шага, что позволяет возобновить прерванный процесс (после сбоя ноутбука или перезагрузки сессии) с того места, где он остановился, вместо начала с нуля.
Паузы с участием человека. Установка параметра interrupt_before для критически важных узлов заставляет граф остановиться, показать предложенные действия и дождаться одобрения перед продолжением работы. Именно это во многом отличает демонстрационные агенты от агентов, используемых в производстве.
Параллельные ветви. Независимые шаги могут выполняться одновременно, при этом фреймворк сам синхронизирует их результаты в единое состояние, поэтому достаточно описать структуру, а не писать код синхронизации.

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

Часть 3: Правильная разработка

9. Пять проектов по порядку

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

Агент с одним инструментом. Выберите один API, например GitHub или сервис погоды, и напишите агента, который определяет необходимость использования API, вызывает его и использует полученный ответ в своем ответе. Используйте сырой API Anthropic или OpenAI без каких-либо фреймворков, чтобы увидеть цикл использования инструментов без скрытия его деталей абстракциями.
Агент типа ReAct с тремя инструментами. Добавьте возможности веб-поиска, калькулятора и выполнения кода, а также самостоятельно реализуйте цикл «анализ — действие — наблюдение». Именно здесь обычно впервые происходит ситуация, когда агент замечает и исправляет свою собственную ошибку.
Поиск информации в известной кодовой базе. Составьте индекс реального репозитория, создайте систему поиска в нем и задавайте вопросы, требующие понимания нескольких файлов. Оцените качество поиска и исправьте те фрагменты, которые не сработали. Этот проект показывает, почему разбиение на фрагменты важнее всего остального.

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

Запланированный автономный цикл. Запустите проект четыре по расписанию cron без наблюдения. Дайте ему файл состояния, чтобы он возобновлял работу вместо полного перезапуска, установите жесткий лимит расходов, чтобы он не приводил к росту стоимости API-запросов, и настройте журнал аудита для записи его действий. Именно здесь «работает в демо-режиме» превращается в «работает без участия человека».

10. Файл состояния: агенты забывают, файлы — нет

Это звучит слишком просто, чтобы иметь значение, но именно это является основой любого надежного автономного агента: файл в формате Markdown, документ JSON или строка в базе данных, находящаяся вне рамок диалога и фиксирующая то, что было сделано, и что предстоит сделать.

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

// STATE.md: what every working autonomous agent needs
{
  "last_run": "2026-07-01 03:00 UTC",
  "items_processed": 47,
  "items_remaining": 12,
  "in_progress": [
    "fix/auth-token-refresh: tests passing, awaiting CI"
  ],
  "completed": [
    "fix/null-check-in-billing: merged, CI green"
  ],
  "escalated_to_human": [
    "src/payments/refund.ts: root cause unclear after 3 theories"
  ],
  "lessons": [
    "2026-06-30: E2E tests require Stripe webhook secret in env. Skip if missing.",
    "2026-06-29: Windows runner has TLS 1.2 issue. Use bash, not PowerShell."
  ]
}

Список уроков заслуживает внимания. Именно он позволяет циклу перестать повторять одни и те же ошибки, а также служит постоянным ориентиром для предотвращения отклонений от поставленных целей. Существует два распространённых формата: файл в формате Markdown, сохраняемый в репозитории, находится под контролем версий, его легко сравнивать, и он прост в использовании, что подходит для отдельных пользователей и небольших команд. Для производственных циклов, наблюдение за которыми требуется несколькими людьми, лучше использовать внешние системы, такие как инструменты для отслеживания задач вроде Linear или базы данных. Принцип прост: агент забывает, репозиторий помнит, поэтому всё важное должно находиться вне окна контекста.

11. Maker-checker: разделение автора и рецензента

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

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

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

# Wrong: one agent does both
result = await agent("Fix the auth bug and verify your fix is correct")

# Right: maker and checker are separate agents, separate contexts
fix = await agent(
    "Fix the auth bug in src/auth/middleware.ts",
    model="sonnet"
)

review = await agent(
    f"""Review this fix against the rubric below.
    Do not consider who wrote it or their intent.

    Fix:
    {fix.code}

    Rubric:
    - Does it handle the null case on line 47?
    - Does it preserve the existing token expiry logic?
    - Does the test cover the regression case?

    Return: PASS with reasoning, or FAIL with specific line references.""",
    model="opus"   # harder model for the harder judgment task
)

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

Такое разделение применимо гораздо далее, чем только к коду: авторы и рецензенты, писатели и проверяющие факты, генераторы и судьи. Как только вы это заметите, вы увидите, насколько часто стандартные инструменты тихо сливают эти две роли.

12. Оценка: звено, делающее цикл надежным

Агент без проверщика — это просто чат-бот, вызываемый многократно. Оценка определяет, можно ли доверять результату настолько, чтобы использовать его, объединить или выпустить. Используйте три уровня, стоимость и возможности которых постепенно увеличиваются:

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

Судья в виде ЯИ. Вторая модель оценивает результаты работы первой модели согласно установленным критериям. Этот подход эффективен, когда критерии четко определены, но теряет эффективность при их нечеткости. Судья должен обладать минимум такими же способностями, как и модель, генерирующая результат, и ему никогда не следует сообщать, кто создал данный результат. Эффективное использование судьи в качестве инструмента является отдельной дисциплиной, о которой рассказано в статье «Управление ЯИ в роли судьи как производственной системы».

Подтверждение человеком. Для непротиворечивых действий, таких как развертывание в производство, обработка платежей, принудительные обновления и изменения архитектуры, требуется подтверждение человека перед тем, как агент сможет продолжить работу. В LangGraph функция interrupt_before обеспечивает такую паузу. Используйте ее только для действий, отмена которых сопряжена с большими затратами, а не для контроля над всеми операциями.

Чтобы понять, эффективно ли происходит оценка, отслеживайте долю принятых изменений. Если агент, созданный для устранения несработавших тестов, решает 70% своих проблем с помощью изменений, прошедших проверку CI и ревизию людьми, то этот показатель составляет 70%. При уровне ниже примерно 50% люди тратят время на завершение работы, начатой агентом, и таким образом затраты превышают экономию.

13. Безопасность: агент без присмотра — это уязвимая поверхность для атак

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

Внедрение через выводы инструментов. Веб-страницы, задачи на GitHub и заявки на поддержку могут скрывать инструкции внутри обычного контента, например строку с указанием агенту игнорировать предыдущие инструкции и удалять тестовые файлы. Карантин является средством защиты: любой агент, подвергшийся воздействию ненадежного контента, получает доступ только для чтения. Необходимо разделять агенты, отвечающие за чтение, и агенты, выполняющие действия.
Постепенное расширение прав. Агент, утвержденный с доступом только для чтения, получает еще одно право на запись «ради удобства», и никто больше не проверяет это. Регулярно пересматривайте права (разумным интервалом является месяц) и предоставляйте только минимум прав, необходимый для выполнения задачи.
Секретная информация в логах. Детальное логирование в долго работающих циклах приводит к разбросу учетных данных в выводах, которые никто не отслеживает. В производственных циклах следует выключить детальное логирование и обработать оставшиеся данные.

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

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

# Safe agent permission model
permissions = {
    "auto_approve": [
        "Read(*)",           # read anything
        "Bash(npm test)",    # run tests
        "Bash(git status)",  # observe state
        "Bash(git diff*)",   # observe diffs
    ],
    "require_human": [
        "Bash(git push*)",   # never push without approval
        "Edit(.env*)",       # never touch secrets
        "Edit(src/payments/*)",  # never touch payments code
        "Bash(*--force*)",   # never force anything
    ]
}

Тест для каждого правила — это один вопрос: если данное действие оказывается неверным, насколько дорогостоящим будет его откат? Если откат происходит легко, действие автоматически одобряется; если же это сложно, решение принимает человек. Решение каждого случая по отдельности — вот как начинается проблема чрезмерного расширения прав.

14. Превращение навыков в карьеру

Путь обучения должен вести к чему-то конкретному. Ниже приведен практический обзор сфер применения этих навыков.

Что следует показать. Избегайте копий учебных примеров. Три реальных проекта, решивших конкретные проблемы, имеют гораздо большую ценность:

Агент с запланированными действиями, результаты работы которого используются на практике, например, цикл, созданный на шаге 9.
Система с несколькими агентами, в которой по крайней мере два агента выполняют разные роли, что по структуре не позволяет одному экземпляру модели выполнять обе функции, как в шаблоне «создатель-проверщик» с шага 11.
Система поиска с задокументированными показателями оценки, демонстрирующая результаты до и после внесения исправлений, а не просто факт её работоспособности.

Сколько времени это занимает. По приблизительным оценкам, человек, уже умеющий писать качественный код на Python и тратящий на обучение 10–15 часов в неделю, может ожидать, что этот путь займет примерно восемь месяцев. Рассматривайте это как ориентир для планирования, а не как гарантию.

С чего начать. Уровень доступности различных позиций для новичков сильно варьируется:

Инженер по автоматизации с использованием ИИ в компании, чья основная деятельность не связана с ИИ. Здесь нужен специалист, который может, например, создать цикл для автоматической корректировки тестов за ночь. Достаточно знаний LangGraph, MCP и основ CI; десятки фреймворков не требуются.
Инженер ИИ в стартапе, продуктом которого является агент. Для этой роли требуется полный набор навыков в области поиска информации, оценки, проектирования многокомпонентных агентов и их развертывания, при этом стандарты выше, а возможности — более широкие.

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

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

Заключение

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

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

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

Для этого не требуется научный бэкграунд или специальные навыки тюнинга. Нужен хороший уровень владения Python, четкое понимание причин ошибок больших языковых моделей и привычка устанавливать механизмы проверки еще до начала цикла обработки. Создайте первого агента, запустите его на ночь и проверьте полученные изменения утром.

Связанные материалы

От одноузлового чат-бота до агента, работающего с MCP в LangGraph — Создавайте приложение LangGraph поэтапно: состояния и функции преобразования, связи между элементами, циклы использования инструментов, сохранение состояния в моментах критических точек, три режима потоковой обработки и инструменты, предоставляемые через MCP.
Проектирование четырехуровневой памяти агента с использованием LangGraph и Amazon Bedrock — Узнайте, как обеспечить агентам на основе больших языковых моделей рабочую эпизодическую, семантическую и процедурную память в средах Bedrock и LangGraph, а также как защитить её от вредоносного воздействия, утечек персональных данных и нежелательного доступа других пользователей.

Все статьи Прислать бриф