Агентная инженерия организует роли, состояние, инструменты и контрольные этапы качества вокруг задачи. Её цель — не максимальное количество агентов, а управляемая ответственность и проверяемые артефакты.
Спецификация служит контрактом. Роли реализации и проверки следует разделять, а результат должен проходить тест, независимый от объяснения агента.
Агент — не персонаж и не автономный коллега, а ограниченная роль, исполняющая контракт. Важны состояние, доступные инструменты, формат артефакта и условия завершения. Дополнительная роль оправдана только тогда, когда вводит независимую ответственность или контроль, которые нельзя столь же ясно выразить в более простом процессе.
Я использую этот раздел как карту практики, а не автоматически собранный набор тегов. Отправная точка — конкретная задача пользователя, допустимый материал и ошибка, которую нельзя пропустить. Выбор модели, поиска и инструментов происходит позже. В каждом описании важно разделять наблюдение, предположение, интерпретацию и решение человека. Так читатель видит не только предложенное решение, но и условия, при которых оно перестаёт быть надёжным.
Доказательство здесь состоит из нескольких уровней: источник и лицензия, структура данных, версия выполнения, сценарий оценки и цепочка ответственности. Проект должен вести к публичному артефакту, а статья — к проекту или исследовательскому материалу. В этом кластере такими контрольными точками служат, в частности, Academic Agent Workspace, Dobrovola Codex TwinLoop. Статус указан явно, а ограничения остаются частью основного описания, а не примечанием после демонстрации.
Начать чтение стоит с материалов Двухролевой процесс Codex: от спецификации до CI, Открытый код как доказательство работы, Codex как персональная операционная среда для офисной работы, а затем перейти к связанным кейсам. Эта последовательность — не воронка продаж; она сокращает путь от понятия к проверяемому примеру. Утверждение о производительности требует бенчмарка. Утверждение о качестве источника — корпуса и негативных примеров. Утверждение о профессиональном решении должно указывать точку контроля и практический способ оспорить результат.
Границы области не менее важны, чем её определение. Не всякая автоматизация требует LLM, не каждый артефакт можно открыть публично и не каждый прототип доказывает готовность к production. Поэтому у материалов есть версия, дата, статус и примечание об области применимости. Диагностика готовности ниже переносит эти принципы на процесс посетителя: до интеграции модели она проверяет источники, baseline, оценку, ответственность и безопасную процедуру изменений.
Обновление раздела должно начинаться с изменения доказательств, а не с желания добавить ещё одну метку. Новая модель, источник или процедура требуют проверить, какие выводы остаются в силе, какие локализации устарели и ведёт ли каждая ссылка к той же версии артефакта. На практике для этого нужны небольшой журнал изменений, дата проверки и явное условие повторного теста. Такой порядок позволяет развивать тему, не скрывая прежние ошибки, и отделять устойчивый метод от разового эксперимента. Читатель может оценить не только текущий результат, но и то, как он изменился после критики или существенного обновления данных.