Агент — не чат с длинным промптом

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

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

Четыре слоя вместо одного промпта

У работающего агента есть как минимум четыре слоя.

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

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

Рабочий цикл

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

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

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

Сначала узкая петля

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

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

Где заканчивается рассуждение и начинается право

Агент может решить, что письмо стоит отправить. Из этого не следует, что он вправе нажать «отправить». Решение о содержании и разрешение на внешний эффект — разные сущности.

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

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

Три частые подмены

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

Память вместо источника. Модель может помнить обсуждение, но статус задачи следует читать из системы задач. Память объясняет контекст; каноническая система сообщает текущее состояние.

Уверенность вместо приёмки. Формулировка «всё готово» ничего не доказывает. Нужен наблюдаемый критерий: файл существует, запись имеет нужный статус, тест завершился успешно, повторный запрос не породил дубль.

Что вы соберёте

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

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

Паспорт, который можно проверить машиной

Свободный текст оставьте для объяснения, а исполнимые границы вынесите в маленький структурированный паспорт. Он не содержит credentials и адресов сервисов:

{
  "agent_id": "weekly-intake-draft",
  "purpose": "собрать черновик разбора новых материалов",
  "owner_role": "project-editor",
  "trigger": "manual_training_event",
  "input_schema": "intake-item-v1",
  "output": "one local draft",
  "allowed_actions": ["read_training_queue", "write_local_draft"],
  "forbidden_actions": ["publish", "delete_source", "read_other_projects"],
  "stop_conditions": ["unknown_item_type", "source_unavailable", "scope_conflict"],
  "proof": ["draft_exists", "source_unchanged", "audit_event_written"]
}

Добавьте валидатор, который требует постоянный agent_id, владельца, один главный выход, непустые стоп-условия и хотя бы одно доказательство. Неизвестные поля отвергайте: иначе опечатка в forbidden_actions станет молчаливо проигнорированным запретом.

Поле	Кто задаёт	Кто проверяет	Когда меняется
purpose	Владелец процесса	Приёмщик результата	При изменении задачи
allowed_actions	Владелец безопасности	Policy-слой	Отдельным решением
input_schema	Автор интеграции	Валидатор входа	С новой версией
proof	Автор и приёмщик	Тестовый контур	При смене результата

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

Практика

Выберите один процесс, который повторяется хотя бы раз в неделю. Создайте папку agent-workshop и файл passport.md. Заполните семь строк:

Кто запускает процесс.
Какое событие считается входом.
Какой один результат должен остаться после работы.
Где лежит источник текущего состояния.
Какое действие пока будет только черновиком.
Как вы проверите результат без слов агента.
В каком случае агент обязан остановиться и позвать человека.

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

Проверка

В passport.md названа конкретная повторяемая работа, а не профессия или образ помощника.
Результат можно увидеть в файле, записи, сообщении-предпросмотре или ином проверяемом состоянии.
Источник правды существует вне памяти разговора.
Есть хотя бы одно условие остановки.
Вы можете вслух разделить: что модель решает, что инструмент делает и что человек разрешает.

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